Zugg Software :: Search

To Vrah, and others.. I've gotten rid of using any buttons as gauges.. it slows down CMUD more than you would expect it would.. especially if you have many of them ( I originally had a ton of them, on ...

make sure "FORCE REMOTE MXP" is enabled in your mxp options

I thought it was just my totally messed up map, but I get this too... another thing I forgot to make a bug report about :/

I am using Windows XP, SP3

I normally gag my prompt but sometimes it doesn't work always and for the first time I saw this echo type ERROR in my main window

3783h, 3623m, 17750e, 17815w exkdb- ...

for some reason in a past version this was no longer a problem but it reappears in 3.30..

after accidentally resetting the underline option when I try to unset it again.. it ignores the setting sa ...

MXP <send> respects the style option for URLs in the SESSION window, but NOT in the STATUS window

(I have underline disabled for URLs in my style options, but this does not apply in the statu ...

I've repeated it a ton of times with my Achaea package, but I can't figure out what exactly is causing CMUD to hog an entire core of my CPU -- gets stuck at 50% total cpu usage, even AFTER I close the ...

I don't know if it matters or not, but what I'm trying to do is capture the AB list which you can do with #var whatever %gmcp.char.skills.list.list but only after you do AB skillname, which is annoyin ...

You have to first enable the receiving end of it in settings of gmcp to get the response, and then use #sendgmcp TYPE MESSAGE for the client end of it

so for this:
Char.Skills 1

add that to the ...

Not a big priority and I don't know if this is even a bug or the way its supposed to be, but using #MXP for the main window are completely ignored if its called from within a GMCP trigger (I am using ...

whats even weirder is that I don't even think "disabling the buttons" fixes it either.. you have to actually delete them

I just checked and this still is persistent in 3.29b

Zugg thanks for fixing the mapper slow walking bugs.. its working perfectly now .. only this weird bug showed up dealing with buttons and gmcp triggers and the room events

took a while to find out ...

#SLOW will automatically move the first step no matter if all autoconfirmation is disabled and no #OK issued....

in Achaea
from a blank session, load map with vnums, and set following map opts:
...

I've found this ONLY happens when using set wait for prompt in slow speed walking and only when sending directions manually (Without #slow or clicking on map)

in Achaea
from a blank session, load ...

No in the LAST dump I posted that was for a brand NEW room created ... and the room name was perfectly fine in the gmcp info, as you can tell from debugging.. but this happens randomly in both instanc ...

keep in mind that I am doing my own room confirmation scripts..and so I have actually disabled the "USE VNUMS" option as well as any matching at all...

but when this happens the roomkey is the same ...

You can check if the vNum flag is set via the %roomload function. I think bit #4 is the vNum loaded flag.

One thing I could do is to prevent CMUD from issuing it's own #OK for rooms with vNum set ...

like I said its pretty random, here is it with EVERYTHING enabled, I tried disabling as much as possible .. so this time I put all my gmcp info code inside a #IF (0) so it wouldn't execute.. so there ...

edit ignore this

There is nothing that should be changing it though..

the ORE is just the OnRoomEnter event message I used for debugging:
#DEBUG ORE: %roomkey @room_name
where @room_name holds the room name set ...

I was referring to the original post... where when I'm updating old rooms vnums, somtimes the map creates a new room for no reason even though there is an existing room.. and the room name assigned i ...

EDIT: nevermind I thought I fixed this but.. I still have this problem...
When I look in the debug window I see my #OK going through find and Loc being changed correctly, and then OnRoomEnter fires
...

Slow mode is better?

I am doing my own room name matching....

The problem is GMCP does issue an internal#OK when the map has the correct vnums this isn't the problem... the problem is What to do ...

when using match rooms with VNUMs option, and slow walking to a room that has been already automatically confirmed by the mapper using VNUMs, %walkconfirm has not been set...

this makes it impossib ...