Zugg Software :: View topic

Posted: Wed Jun 11, 2008 12:49 am

I can almost guarantee it was. Got some rather large maps lying around and the memory footprint used to be massive (atm i just got cmud + a void trigger :( no coding time these days! )

Posted: Wed Jun 11, 2008 6:26 am

Would we be able to declare a local variable in the room script and have it remain in memory as long as you don't leave the room?

Would be nice if gauges could make their own local variable for other settings to adjust as well ... would it be hard to make a local variable dependant on another settings enabled status?

Enchanter Joined: 09 Sep 2007 Posts: 605

Posted: Wed Jun 11, 2008 4:48 pm

Hmm, interesting ideas Arde. I agree that handling the room "type" and allowing generic scripts for all rooms of that type would be pretty powerful. I'll give that more thought.

Also, I wasn't going to make a "room" a true "class"...that would be too confusing. But since it's relatively easy to add new setting types in CMUD (like I have added events, functions, etc), then I can add something called a "room" or a "zone" and give it it's own icon and it's own editor screen. The point is that I want any "settings" associated with the mapper to be available within the normal settings editor. I think it's important to leverage the existing code and the nice script editor rather than making a separate editor just for the mapper settings.

Shalimar: No, local variables only exist during the script that is actually running. If you wanted a variable to exist outside of a running script, then you'd need to create a normal variable within the room. Gauges also cannot use local variables for the same reason. Local variables are just references to the runtime stack and when a script ends, the runtime stack is empty. I think what you need to look at are variables with the "Use Default" option selected...these variables are not saved in your package and are faster than normal variables.

Posted: Wed Jun 11, 2008 5:32 pm

And, besides, aren't variables defined within room scripts undefined when you're not in that room, anyway? If they're not, they should be.

Posted: Wed Jun 11, 2008 6:05 pm

Well yes, but the idea in the new mapper would be that the room settings would be "disabled" when you are not in the room (like a disabled class), which would actually allow you to forcibly access a room variable via //Mapper/RoomID/Varname anyway, just like accessing a variable in a disabled class.

Posted: Fri Jun 13, 2008 5:02 am

As far as additional features I'd like to see go, I guess, the big one would be "speedwalking" options for the mapper (run 2n2e etc) right now i have an alias to handle speedwalks, and a few events that fire when speedwalking (startSpeedwalk (startroomnum), endSpeedwalk (endroomnum), onSpeedwalk (startroomnum, endroomnum)) but it is hardly optimal (looping through the entire list and doing #moves in cscript instead of compiled code where it should be)

That and some work on the portals. In particular ways to specify portal levels, and tell the mapper your current level, autodisabling those out of range. And a way to programmatically delete portals.

An extra field for portals where you can flag special info about them would be nice too, so i can store all the info about my portals in the mapper, instead of relying on a seperate string list that stores things like level, can be used in situationX, etc

A Quicker way to import/export portals separate from the map (having to delete all my friends portals and re-add all my own every time my friend and i swap maps is a PITA)

And zone level locks. Though that may be managable with what you've suggested so far anyways.

Posted: Fri Jun 13, 2008 10:06 am

What speedwalking options did you have in mind? You've not really given anything specific there.

And you can already delete portals. #unportal.

Posted: Fri Jun 13, 2008 12:07 pm

i aid import/export portals, i know you can delete them

Posted: Fri Jun 13, 2008 12:44 pm

Adept Joined: 27 May 2008 Posts: 299

He means currently the sw syntax is .2n3ew3n ... We have to replace that to run 2n3ew3n. It would be nice if we could just define the sw'ing command. Also because we do this, we have to alias run to ~run and then #FORALL expandpath() {#MAP %i}
Thats not the exact code but you get the idea. If we could define "run " in place of . on the mapper side, this would fix all these issues and have it follow 100 times faster.

Posted: Fri Jun 13, 2008 1:08 pm

That's an interesting idea. I'm not sure whether you mean that, for MUDs have a built-in RUN command for server-side quickwalking, then the mapper (instead of using any of its speedwalking options) should send RUN path, or if you mean that when you enter RUN path yourself, the mapper should automatically handle the walking properly, but both are good ideas. The latter is probably doable as things stand, though.

Do bear in mind, though, that paths like .2new5s have absolutely nothing to do with the mapper.

Adept Joined: 27 May 2008 Posts: 299

Both actually would be helpful. Like I said, Its doable with scripting as it is, but it can be a load to run a really large path.

Enchanter Joined: 09 Sep 2007 Posts: 605

I don't know where it would be the right place to post this...

One thing I ask to think about when you will write visualization part of mapper is label placement (both custom-defined and predefined like room name, etc.) Currently, you stick with one scale factor (commonly 75-125%) and you can't change it later easily, because it'll cause a mess with text labels on the map. So you are forced either set the map to a large scale factor or look at a large map but pull down mapper panel with room info.

Suggestions are:
1) CMUD/cMapper must be able to center text label relative to room image.
2) Perform text size scaling while you scale you map. Not quite useful for large scale maps, but may help for low scales to fit info on the screen.
Next 2 suggestions are intended to reduce amount of unnecessary text on the map:
3) Each room should have an additional field in mapper database - minimum visible scale. If map scale is equal or greater that this value, then mapper draws a label. Then, you may set minimum scale value to a very low number (for ex., 10%) for important rooms to be sure their labels will be visible at any scale. For not important ones you will set this value to a higher numbers.
4) I followed the link from the topic nearby and have viewed that "zMUD alike map" screenshot from Pandora mapper. Wink

I thought that fading out of unnecessary labels would be cool, but as always, cool stuff will take more time to implement it than Zugg can afford himself. Sad

Beginner Joined: 05 Nov 2007 Posts: 14

I'm having troubles getting my head around how to map the various areas in the mud I play on.
One wizard added an area with "3D" exits, such as "northwestup" - meaning you go northwest and up, and to make matters worse, exits like "southdowndown" or "northupup". And as if this was not enough.. we've also gotten a new dungeon system in place, which is generic and can be randomly recreated every reboot - and has exits like forward, left, right, backwards, turn around, and so on. Is there a snowballs chance in hell something like this would work in the mapper? I'm getting tired of mapping these manually. :)

Apprentice Joined: 18 Feb 2007 Posts: 190

from most to least important
way to read and write path ahead, map queue and path behind (that one dont need to store directions twice any more too... Razz

)
%nextdir should finally return direction that will be sent by next #step
#step adding properly to both queue and pathahead (like #slo s2w3s;#step;#step;#step sn -> pathahead=.nw3s not .n;.w3s)
%inwalk getting updated to 0 without having to do empty #step
%walk no longer creating abominations like .ened;.(open south;s)sw;.ws2wd so it can be used with #slow without extensive reparsing (w;.w part)
function to grab mouse selected room(s)/and highlighted paths
Cool

Posted: Tue Dec 09, 2008 6:19 pm

Sorry to resurrect an old post, but I wanted to remind people about a feature that is in the 3.02 beta version regarding having multiple "other" exits from a room.

Remember that the "command" for an exit always overrides the "direction" of the exit. In other words, if you have an exit in the "north" direction, but assign it a command string of "out", then typing "out" will move you through that exit.

Now, as mentioned, you are allowed to have multiple exits in the same direction. So you can have multiple exits all marked in the "north" direction that have different and unique command strings. In the past, all of these exits would overlap on top of themselves.

However, if you look at the Exit tab of the Room Properties in the v3.02 mapper, you will see fields for X and Y "Offset" values. These values allow you to manually move the start location of the exit line. For example, if you have two exits in the "north" direction, set the X Offset of one of them to -20 and the X Offset of the other to +20. Now you will see both exit lines separate on the map display.

This feature was actually in the old version but only worked with zMapper (and had several bugs). But it works properly in the 3.02 version, even without zMapper.

Using this feature you could have a huge number of exits from the room, all with different offset values so that each line is separate from the others. So this should give you a lot more flexibility on displaying a large number of custom exits.

On the discussion of automatically creating stubs for non-standard exits: the problem is that when you use a non-standard exit (like "out"), the mapper has no way to determine where to place the new room. That is why zMUD and CMUD have always used the syntax:

>out>n

to create a non-standard direction and to tell the mapper to place the new room to the north of the current room. Do you want the new room for the "out" exit to the right of the current room, or to the left of the current room? CMUD has no way to read your mind on this. And on most MUDs, the placement for this room isn't consistent. For example, if I'm walking down a street on the MUD, the "in" direction to enter a shop might have the shop on the left or right side of the current window and it might be different for every shop. So again, there is no way for CMUD to guess where you want the room created.

CMUD will create stubs automatically for any direction that is listed in your View/Directions dialog. So if you want exit stubs for "in" and "out" to be created automatically, simply create custom directions in the View/Directions screen and enter "in" and "out" as the commands for the exits. Then in the Map Direction dropdown, select the type of stub direction you want to create. Select "Other" to create a stub for a non-standard direction.

When CMUD parses the Exit list from the MUD, it looks for words that match the direction command words. It is completely customizable. CMUD doesn't have any "hard coded" direction names. The way CMUD knows that "north" is the name of an exit to be placed above the current room is because the Direction for "n" has a command word of "north" and is assigned to the North mapper direction. You can customize this direction list however you want to add more words that are auto-detected and added as stubs.

Anyway, I think the new mapper has everything you need for custom exits now. If I am mistaken, feel free to create a new post to discuss what other features you need for custom exits.