| View previous topic :: View next topic |
| Author |
Message |
ixle
Joined: 15 Sep 2011
Posts: 133
Location: United States
|
 Posted: Sat May 12, 2012 12:44 am Post subject: Checking map data for a string not existing |
 |
|
I've set up actions to set room desc and room note data on not being able to use certain movement features of Aardwolf such as entering object portals and using the word of recall spell or home command.
The problem is now the rooms are flagged as noportal or norecall, but I want to find the closest room that I could do one of those things from.
Short of going through and flagging every room as recall/portal, and then changing the flags as it happens, is there a good way to do a #map find for a string not being roomdesc or roomnote etc? |
|
| Back to top |
|
 |
Scandum
Site Admin
Joined: 03 Dec 2004
Posts: 3274
|
| Posted: Sat May 12, 2012 8:22 am Post subject: |
|
|
You could organize your room notes in a matchable manner.
#map set roomnote {note=bla;flag=norecall}
#map find {} {} {} {} {%*flag=norecall}
I can probably extend #map find to include the data field as well. |
|
| Back to top |
|
|
Slysven
Joined: 10 Apr 2011
Posts: 254
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK
|
| Posted: Sat May 12, 2012 11:22 am Post subject: |
|
|
Just a thought, the room terrain field is already searchable, if you are not already using it for anything else you could store say a flag value there?
E.G. 1=norecall, 2=noportal, 4=??? etc. so that | Code: | | #MAP FIND {} {} {} {} {} {{0|4|...other values with the two LSB bit-values false}} |
ought to find a room that you can port to AND from, I'm supposing that it would just be the nearest weighted one, is that how the FIND selects it's result to use?
And Scandum, haven't you argued against adding more fields to #MAP FIND/LIST, perhaps we should consider an alternative with pairs of arguments the first being what field to search in and the second for the value to search for, i.e. something like:
| Code: | | #MAP SEARCH {roomname} {A Dark, Dank Hole} {roomarea} {Mordor} |
Then I could hang my "putting results in to a variable" with a {variable} {MYRESULTVARIABLE} pair anywhere in the arguments list as well in stead of placing it after the last (currently 6th) argument. The advantage of this is that new searching options can be added later without changing existing user scripts, and that the user does not have to carefully count how many empty {} they have to pad what they are searching for - which is a distinct advantage when you quickly need to find a room in the middle of a MUD session and you are paging through the #HELP MAP display to find that the roomarea is the FOURTH argument. 
P.S. Also you could throw in a {count} {COUNTRESULT} option that just enumerates the results but does not need to return them (quick check for duplicate rooms!!!) |
|
| Back to top |
|
|
Scandum
Site Admin
Joined: 03 Dec 2004
Posts: 3274
|
| Posted: Sat May 12, 2012 2:37 pm Post subject: |
|
|
| Slysven wrote: | | Just a thought, the room terrain field is already searchable, if you are not already using it for anything else you could store say a flag value there? |
That's an option as well.
| Slysven wrote: |
And Scandum, haven't you argued against adding more fields to #MAP FIND/LIST |
I'm opposed to adding fields that have a different behavior.
| Slysven wrote: | perhaps we should consider an alternative with pairs of arguments the first being what field to search in and the second for the value to search for, i.e. something like:
| Code: | | #MAP SEARCH {roomname} {A Dark, Dank Hole} {roomarea} {Mordor} |
|
That's probably a better solution than the current system, and I guess both approach can work alongside each other.
| Quote: | | Then I could hang my "putting results in to a variable" with a {variable} {MYRESULTVARIABLE} pair anywhere in the arguments list as well in stead of placing it after the last (currently 6th) argument. |
That's doable as well.
| Quote: | | P.S. Also you could throw in a {count} {COUNTRESULT} option that just enumerates the results but does not need to return them (quick check for duplicate rooms!!!) |
I'm not sure what you mean here.
If you want to see if there are multiple matches for a search you could use #map list, and once this is implemented you can use #Map list {variable} {test} and use &test[] to see how many vnums were found. |
|
| Back to top |
|
|
Slysven
Joined: 10 Apr 2011
Posts: 254
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK
|
| Posted: Sun May 13, 2012 3:56 pm Post subject: |
|
|
That last one meant that with the {count} in the place of "thing to search for" (like "roomname" or "roomnote") it could put the count of matching results into the supplied variable, either as the only result or in parallel to the on-screen results (for the #MAP LIST sort of usage without my "put all matching room vnums into a variable" hack or alongside it OR with the #MAP FIND type usage so the user can quickly establish if the find result is the only one...)
| Scandum wrote: | | If you want to see if there are multiple matches for a search you could use #map list, and once this is implemented you can use #Map list {variable} {test} and use &test[] to see how many vnums were found. |
Considering my hack that produces a ';' separated list of rooms in a variable "MYRESULT" as a result of the #MAP LIST I do have to convert it with a #LIST {testvariable} {CREATE} {$MYRESULT} to count the results using a &{testvariable[]} which is a bit of a roundabout way if I only wanted to check for a single matching room. I believe that being able to get a count directly may be more efficient in some situations.  When I first proposed the code I did want to produce a list result directly but I was unable to get my head around creating the list variable in the code so chickened out and just used those semicolons.  |
|
| Back to top |
|
|
Pedwiddle
Joined: 31 May 2012
Posts: 8
|
| Posted: Sat Jun 02, 2012 11:52 pm Post subject: |
|
|
| I think the point of the question was how to test for a negative - if you are in a noportal/norecall room, how do you find the nearest portal-able or recall-able room? It would seem that the only option would be to go through an explicitly put "flags=recall" in each roomnote (or whereever), but it would be nice if there were another option. |
|
| Back to top |
|
|
Scandum
Site Admin
Joined: 03 Dec 2004
Posts: 3274
|
| Posted: Mon Nov 19, 2012 9:53 pm Post subject: |
|
|
Kind of late, but you could try:
#map find {} {} {} {} {{^((?!flag=norecall).)*$}} |
|
| Back to top |
|
|
mrbigtaco
Joined: 26 Jun 2011
Posts: 35
|
| Posted: Fri Nov 30, 2012 4:46 am Post subject: |
|
|
| Scandum wrote: | | Slysven wrote: | | Just a thought, the room terrain field is already searchable, if you are not already using it for anything else you could store say a flag value there? |
That's an option as well.
| Slysven wrote: |
And Scandum, haven't you argued against adding more fields to #MAP FIND/LIST |
I'm opposed to adding fields that have a different behavior.
|
Revisiting this thread in the context of the changes to #map find / list being implemented with the current beta build - I'm not familiar with the behavior of any of the data fields in a room behaving differently (forgive me, I'm relatively new to this and the documentation is thinner in this area). Is there some historical context for what each of the fields "should" contain, or specific uses? Room area, desc, and note all map fairly easily to concepts on my mud and name is useful for personal short names to recall quickly and run to. Terrain, data, and symbol seem less clear, although I can see that symbol affects the way the room is rendered. I assuming terrain interacts with some kind of feature that defines walking speed?
I too would like the roomdata field to be added to #map find / list if possible, although as mentioned above I'm unaware of a technical design choice or reason why it maybe should not be? I had originally planned on using the roomdata field for sticking client side meta data for searching on and building paths, but since it's not a parameter in #map list, using this field in this way would be rather roundabout. Terrain could be repurposed for it, but it would feel awkward using terrain for something that's not... terrain related. |
|
| Back to top |
|
|
Scandum
Site Admin
Joined: 03 Dec 2004
Posts: 3274
|
| Posted: Fri Nov 30, 2012 8:26 am Post subject: |
|
|
| I'm still thinking of a proper way to deal with the data field. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
