Mudlet features and API requests

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet features and API requests

Post by Vadi »

Right, I don't mean the entire area - I only mean 2-3 rooms in.

So if you have main area A, and it connects with B via an east (A) -> west (B) exit - draw 2-3 rooms from B in A, with the first room starting to the right of A's exit.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet features and API requests

Post by Heiko »

SlySven wrote:At present a room in a map belongs to one area. Looking at the structures involved it seems that it would be theoretically possible to modify things so that one could place a room in more than one area. I would see that this could be useful for a couple of situations:
  • Detailed "City" maps could be done with more space between rooms, yet the same rooms could also be drawn much closer together for a "Country" map.
  • Border regions between two map areas could be shown on BOTH maps so if you are using something that locates other players/item/smobs and they are close to you they don't disappear/appear as you cross the boundary between one area and the next.
I'm sure that there is code that returns the area that a room with a specific ID is in, this would have to change to return list of areas instead. I did see that someone has also asked a question about changing the area a room is in on another branch of these forums recently, this proposal would affect an answer to that I guess - instead of just moving a room from one area to another you also would need functionality to both copy a room from one area to another as will as the move one that "cuts" that he is asking about. Of course you also need a room "delete" or perhaps it should be more properly be a room "unlink" function which only destroys the data for that room if it is not allocated to ANY area. Also, the map painting code will have to determine which area to display which will be a bit more convoluted when the current room is allocated to multiple areas, perhaps it will have to track the area that the room before the current one was in...

Am I talking off the top of my head here or does anyone else see any other potential bonuses with this?
The concept of "areas" used in the mapper is that areas represent individual sub maps to overcome spatially illogical maps e.g. given room coordinates on the country map represent a single room in the country map and an entire city with hundrets of rooms on the city map -> you create a submap aka a new area to represent the city map and switch in between maps as you walk in and out of the 2 areas. There is no general layout solution to this problem - and if there were you woudn't need to split up the map into 2 different areas in the first place.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet features and API requests

Post by Heiko »

Vadi wrote:Right, I don't mean the entire area - I only mean 2-3 rooms in.

So if you have main area A, and it connects with B via an east (A) -> west (B) exit - draw 2-3 rooms from B in A, with the first room starting to the right of A's exit.
This is also impossible as these rooms may overlap other rooms in the current area - and even in those cases where it would work by accident people would ask why we don't draw the rest of the area also.

This really is a user layout problem. If people can visually merge areas they should do so of course. Why have different areas if you can have a nice unified map?

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet features and API requests

Post by Vadi »

One of the reason is that functions that operate on areas won't work. For example, getRoomArea will be the same, and telling "areas" apart can be very useful.

User avatar
Oneymus
Posts: 321
Joined: Thu Sep 17, 2009 5:24 am

Re: Mudlet features and API requests

Post by Oneymus »

The general MUD definition of "Area" and Heiko's definition of "Area" are not exactly coherent. They may share similar properties, in that most MUDs don't have logical coordinated grids, but the purpose of Areas in a MUD is not necessarily to allow for illogical grids.

Areas in MUDs are used (in all cases of which I am aware) to provide logical semantic and thematic distinctions between collections of rooms. Therefore, one might not want a unified map if they wish to preserve a MUD's division of Rooms into Areas.

As a personal note, Heiko's definition of "Area" is a completely new concept to me with respect to MUD design; this suggests a potential disconnect between implementation and usage. Or, to put another way: a potential disconnect between the programmer's presumed usage and the user's presumed usage.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet features and API requests

Post by Heiko »

The concept "area" as used in the mapper is well defined: An area is an individual stand alone map.

The mapper offers multiple features to address semantic and thematic collections of rooms within a given map:
- room user data tables to add multiple room attributes of any kind
- customizable room highlight function
- group based foreground and background room color schemes
- map labels
- background images for groups of rooms to mark deserts, forests or whatnot

There is no generally accepted useage of the term "area" that is used consitently across games. The most commonly used terms are areas, zones, domains, planes and sub-divisions. Only very few games make this information available to their players in the first place. In many cases information on the internal domain and sub-divisions or file path of a given room is considered top secret because it could be abused by players.

The motivations behind area/zones/sub-divisions etc. as far as game creation and game organization are concerned are irrelevant for the use of the term "area" within the mapper. We could call it maps, zones, sub-divisions instead but the potential for confusion will remain the same as there sadly is no consistent useage of any of these terms.
Note that in most games players have to create their own maps and areas and get no information on the room data, let alone its internal domain/area/zone or sub-division's name. The mapper is primarily a general purpose user tool to help create a visual representation of the abstract nodes & edges graph of the game.

Stephen (SlySven) has proposed that we should allow for a non unique room/area relationship in order to make things more flexible. Stephen has contributed c++ code to the mapper himself and knows what he talks about. His feature request is perfectly fine and can be implemented easily, but we'd need to find a way to do this in a way that doesn't break the current API or any older scripts. His second request (to draw surrounding areas), however, would require area vectors (area coordinates in a world map) which is against the area concept of the mapper and practically impossible in most games due to partly highly illogical maps.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet features and API requests

Post by Heiko »

Vadi wrote:One of the reason is that functions that operate on areas won't work. For example, getRoomArea will be the same, and telling "areas" apart can be very useful.
You can use other means to preserve the specific "area" attributes of your game. If you find a way to layout an area into a wider area context then merge the areas and use custom room data to keep the game's "area" attributes. You can then visualize these room attributes with color schemes, background images, labels, room highlights and whatnot.

Areas are individual maps that cannot be visually merged because they is no such thing as an area vector which would be a requirement for such a feature (and this requirement is a practical impossiblility in most games).

Merge areas that you like to be drawn together. This is trivial in most cases given the visual map editor tools.

User avatar
Akaya
Posts: 414
Joined: Thu Apr 19, 2012 1:36 am

Re: Mudlet features and API requests

Post by Akaya »

Replacement of text in a script. Perhaps done in unison with the search bar. So you can change every instance of what you search for to something else. This could be useful for things like changing the namespace or fixing a repeated error.

Finn
Posts: 3
Joined: Sat Sep 11, 2010 6:19 pm

Re: Mudlet features and API requests

Post by Finn »

A function to determine if timestamps are showing (are active) so that gui elements can be adjusted as needed.

User avatar
demonnic
Posts: 884
Joined: Sat Dec 05, 2009 3:19 pm

Re: Mudlet features and API requests

Post by demonnic »

It would be nice if there were an easy way to select everything a substring trigger might match, similar to selectCaptureGroup(). This way you could easily set up substring triggers which select and replace something without having to run it through the regex processor. This is especially helpful for unprintable characters where you are unsure what the ascii code being sent is. You can match these as substring triggers, but I'm having the darnedest time getting it to selectString() with the same paste.

ETA: I did try just using a regex match for the ascii NUL character, pattern (\x0) and selectCaptureGroup(1), but this did not work. So even though it's being displayed as the box character, it's coming through as something other than NUL.

Post Reply