Zugg Software :: View topic

Posted: Mon Jul 16, 2012 7:20 am

Okay, so i was thinking of script to show where i have recently been, and so far i have come up with something like...

Wizard Joined: 22 Mar 2007 Posts: 2320

An alternative would be to keep a stringlist of {numbers=|color=|time=} values, and a single looping alarm that checks the variable for expired times every so often. But that isn't necessarily "better", just an alternative.

Or you could keep the last N values in a stringlist like that, and have it reset the Nth value when you enter a new room. That would eliminate alarms completely.

Posted: Mon Jul 16, 2012 5:45 pm

The main problem i am finding now is that with the mapmode constantly toggling, the #LOC doesn't keep up if i spam alot of direction commands at once (safe speedwalking set).
Potentially I can see it accidently creating rooms as well.

Why does mapmode even need to be toggled? I can manually change the colors with mapping off, but not scriptomatically.

Wizard Joined: 22 Mar 2007 Posts: 2320

Here's an idea that shouldn't require toggling mapmode. Instead of changing the colors, set up a set of (say) 6 Locations. These will be placed in the last 6 rooms that you have visited. You can change the room for each Location without toggling mapmode. Have the color of the dot be something other than your current Location. You could have the first Location be "previous room", the second be "second previous room", etc., and update all of them each time you move. Or you could simply keep a list of the locations, and when you move you pop off the top (oldest) Location, update it, and add it to the end again.

Posted: Tue Jul 17, 2012 4:06 pm

I need to allow for a LARGE number of rooms to currently been passed through, the mud in question is very large, and sometimes the path ones takes is convoluted.. being able to avoid where i have been is a must.
(thin tron with the trails left behind you can crash into)
I went for room color because of the visibility, though i would rather change/apply a border, but see no means to do so via script.

Sorcerer Joined: 15 Apr 2011 Posts: 809

Perhaps setting the "do not enter" flag would be a better option? It's visible for you, and the mapper will also avoid those rooms itself if you use it to speedwalk.

Wizard Joined: 22 Mar 2007 Posts: 2320

I think the Do Not Enter flag also requires toggling the mapmode, so it's only a little better. You're right, Shalimar, there isn't a way to change the border by script (except by direct %sql manipulation, and the change won't show up until you close and reopen Cmud). Hm, a large number of rooms? Ugh. Sorry, out of ideas. Can't think of anything else that wouldn't require toggling mapmode.

Sorcerer Joined: 15 Apr 2011 Posts: 809

Hmm, just tested it and you're right. That's another thing that you can change in the properties window in follow mode, but not by script. Is that intentional?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Most of the Room Properties window (at least among the pieces you can script) is by design allowed to make changes in off/follow mode. While the Room Properties window exposes all of the scriptable properties, the window itself is not subject to scripting. It doesn't make sense to have it limited to map mode.

Posted: Wed Jul 18, 2012 2:54 pm

is there a way i could trick #PATHHIGH into doing this for me?

Wizard Joined: 22 Mar 2007 Posts: 2320

Hm...there's a thought! Make a variable storing your starting room, and keep a stringlist of your movement commands, appending each move to the end of the list. After every move, you run %pathcompress, and run the result through #PATHHIGH, starting from the starting room.

If it is too difficult to detect movement commands (for instance, if there are non-obvious Other-type exits), you just test all exits from the previous room to figure out which one leads to the current room, then record the current room as the new "previous" room. Add the direction to your stringlist and proceed as above.