Mudlet - Forum

Haven't been able to verify this myself but this is from Dunn in Achaea.

(x): Dunn says, "Hrmm. 3.0 doesn't seem to recall the window size on reload."
(x: Dunn says, "Keeps loading on full."
(x): Dunn says, "Full screen whenever I load it."
(x): You say, "That's interesting, Windows 8?"
(x): Dunn says, "7."

He auto chooses the profile so there's no profile choosing he has to do himself, not sure if that's relevant.

Confirmed, thanks

When you export a trigger or an alias with 3.0 Delta (on OS X) and just name it something like 'testtest' you will end up with a file named testtest.xml.xml . So two .xml endings to the file name.

Belgarath wrote:I've noticed that using permGroup("prompt", "trigger") is creating an empty trigger, not a group folder.

That's how it is, until you put triggers into it. Not an issue in 3.0 and fixed behaviour from 2.1 even, where it didn't give the trigger a name you specified but its ID as the name instead.

Nemutaur wrote:When you export a trigger or an alias with 3.0 Delta (on OS X) and just name it something like 'testtest' you will end up with a file named testtest.xml.xml . So two .xml endings to the file name.

Confirmed, thank you.

Reposting this here because I realized I'm dumb and this is most likely a better place for it than its own thread.


Recently finished a marginally-working mapper script for Aardwolf, and it's mostly going okay. However, there are a couple rooms in the main city hub area that didn't appear mappable via GMCP.

When you enter a room normally in Aardwolf it sends the room information for the new room and fires the gmcp.room and gmcp.room.info events. However, when entering these specific rooms, it fires these events, but does not actually change the gmcp.room.info table to the updated information, so they only contain the information from the previous room. As a result, the mapper doesn't even recognize the room exists!

I checked in another client and it works perfectly fine, the GMCP info is updated correctly, and I noticed the only thing different about the rooms compared to all the other rooms in that city was that their names were colored. I'm thinking potentially the color information in the name of the room might be throwing Mudlet for a loop.

Here's the GMCP info of the problem room in question:

room.info { "num": 32460, "name": "[1;33mWelcome to Grandmarket Boulevard![0;37m", "zone": "aylor", "terrain": "hellfountain", "details": "", "exits": { "n": 32459, "e": 32587, "s": 32469, "w": 32461 }, "coord": { "id": 0, "x": 30, "y": 20, "cont": 0 } }

I was vaguely aware that some Servers had started using ANSI colour codes in some of the OOB channels but I thought someone had fixed that (not a regression as 2.1 won't take it either)...

Nemutaur wrote:Hi,

I'm not sure if this is a Vyzor bug or a 3.0-delta bug but since it only happens on 3.0-delta and not on 2.1 I figured I'd post it here.

When I draw a map with Vyzor it will add a white element to the top left corner. I have no clue what it is and never saw this in 2.1.

Here's a video (http://ge.tt/77NCnU92/v/0) to demonstrate, I will draw the tabbed chat first and then the map. Ignore the mudlet resizing obviously, that's a whole other issue.

Thanks!

Hmm, so after Uninstalling Vyzor and using only Geyser again this still showed up. So I checked if it was the mapper itself and it is. The code for that is:

mapper = Geyser.Mapper:new({
name = "mapper",
x = "75%", y = "50%", -- edit here if you want to move it
width = "25%", height = "50%"
})

Highlighting text and right clicking for a copy is... Too fast. It disappears instantly before you can click on anything. This is on OSX Yosemite.

I may have found a bug. At some point, Mudlet stopped being able to load my profile, except the triggers. But when I look inside of the xml file, everything is there. I've attached the profile xml file that fails to load anything but the triggers (plus an automatic backup of the profile which behaves the same way).

edit: I found the problem. I had used a special character in the pattern for a trigger, which apparently breaks the loading process.