Zugg Software :: View topic - [3.03a] Mapper

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

I somehow can't see room properties. Nothing happens if I press the properties button or if I try doing the same from the menu.

I've also accidentally posted a few other problems with the mapper here in the general discussion.

Magician Joined: 17 Apr 2005 Posts: 496

Make sure the room properties dialog is not already open. It could have accidentally been joined to another window, possibly as a tab which is behind some other tab.

Otherwise, I'm completely unable to duplicate this bug, so we'd need more information.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

I really can't find it anywhere. Is there a way to make sure it's killed?

I just converted the map from the old type. One of the reasons I changed from 2.x to 3.x was that for some reason I was not able to edit the map anymore. Perhaps my map is bugged in some way. Any way to tell?

I mentioned in another thread that I can see my map in the package editor and that it seems there is a lot of inactive rooms. Exactly what does this mean?

Posted: Wed Jan 21, 2009 11:45 pm

The Room Properties is a dockable window, so if it's hidden somehow, you can look for it in the Windows menu, or you can hold down the SHIFT key and select the Open Offline action for your session to reset the window layout. This should reset the room properties to it's default as a floating window.

The inactive rooms in your Map object is where CMUD puts all of your various Room Scripts. Each Room is a class folder that represents a room on your map that had a script. If you click on one of these rooms and click the Enable Script tab for the class, you will see the script that is executed when the class is enabled. As you move around the map, CMUD disables the Room class folder for the previous room and then enables the Room class folder for the new room.

For example, if you move from Room 1 to Room 2, CMUD will disable the Room1 folder and then enable the Room2 folder. The act of enabling/disabling a class folder causes the Enable or Disable script for the folder to be executed. So when the Room1 folder is enabled, it's Enable script (your original room script) gets executed. Since enabling/disabling classes is much faster than creating/deleting scripts, this makes movement faster in the new mapper.

So all Room class folders will be disabled except for the current room folder. So it's normal to have a lot of disabled room objects.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Wizard Joined: 22 Mar 2007 Posts: 2320

Actually, things can indeed be enabled or disabled 'behind your back'. It is quite common for scripts to enable or disable classes. One reason is that it is faster to enable a trigger than to create a fresh temporary one. Also, cmud may disable a trigger if it causes an infinite loop or some other problem.

The method Zugg has devised for v.3 map rooms is quite clever, and opens a whole range of possibilities even outside the mapper. You can now have *any* class do special things whenever they are enabled or disabled. And within the context of the mapper, you can have entire sets of triggers, aliases, and variables that only become active when you enter a specific room, or type of room, or zone, simply by putting them in the right class. And you can modify room scripts in the package editor rather than the map window.

In general, it would be a bad idea to consider every inactive class and trigger to be eligible for deletion. There are lots of reasons things might be disabled legitimately.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Wizard Joined: 22 Mar 2007 Posts: 2320

Disabled is disabled. Why should it look any different than any other disabled class? You can enable and disable it yourself, too, the normal way. And cmud can disable and enable other things on its own too. It is exactly the same as any other disabled class.

You should refine your definition to say that disabled means unless you OR CMUD enables it, it won't run. That has always been the case.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Posted: Fri Jan 23, 2009 6:32 pm

Unfortunately, it's a limitation in the Tree View. There isn't any other good way to show that something is disabled. In the past I used to use a "dim silver" color instead of the strikeout, but then people complained that it was too hard to see. All I can control is the font color and style. And the strikeout has been used for several years now in CMUD to show disabled classes, so I think I'm going to stick with it unless I hear about a much better idea. But I think it's just something new CMUD users need to get used to.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark