Room parent / exitformat weirdness
-
Okay so my ExitFormat on my room parent separates the exits into two categories: Buildings and Exits. It knows an exit is a 'building' by my putting 'build' attr on it.
For some reason /a single/ building exit is not sorting out the way it should. Any thoughts?
Angel Tower;AT;angel;tower(#197E) Type: EXIT Flags: Owner: Cobalt Key: *UNLOCKED* Pennies: 0 Zone: *NOTHING* Parent: Exit Parent(#95Y) Powers: RxLevel: TxLevel: Created: Sat Aug 27 18:47:59.028991 2016 Modified: Sat Aug 27 18:50:58.538882 2016 BUILD: 1 Source: Downtown - Lewisville - City(#135R) Destination: Angel Tower -Downtown -Lewisville(#165R)ExitFormat: [if(filter(%!/fil.building, lexits(%!)), [divider(Buildings %([words(filter(%!/fil.building, lexits(%!)))]%))]%r [itemize(iter(filter(%!/fil.building, lexits(%!)), name(%i0) %([extract(fullname(%i0), 2, 1, ;)]%) [ansi(hx, %(%i0%))], , |), |)].%r)][divider(Exits %([words(filter(%!/fil.notbuilding, lexits(%!)))]%))]%R [itemize(iter(filter(%!/fil.notbuilding, lexits(%!)), name(%i0) %([extract(fullname(%i0), 2, 1, ;)]%) [ansi(hx, %(%i0%))], , |), |)]%r[footer(get(%!/coord))](An exit that is sorting correctly)
Guild Headquarters;HQ;guild(#356E) Type: EXIT Flags: Owner: Cobalt Key: *UNLOCKED* Pennies: 0 Zone: *NOTHING* Parent: Exit Parent(#95Y) Powers: RxLevel: TxLevel: Created: Mon Aug 22 20:13:29.66209 2016 Modified: Sat Aug 27 18:49:09.124525 2016 BUILD [#66]: 1 Source: Downtown - Lewisville - City(#135R) Destination: Guild Headquarters - Lewisville - City(#355R) -
What's the filter look like? Waht does it search for (I assume it looks for BUILD=1?)?
-
FIL.BUILDING: hasattr(%0, build) FIL.NOTBUILDING: not(hasattr(%0, build)) -
I did &build hq=0, and &build hq=1 again and ... now its not sorting the hq exit either.
-
Try changing it to match(xget(%0,build),1) for fil.building and see what happens? Are there any other odd attributes on the room?
-
Nope, and nope no attributes on the room.
-
@Cobaltasaurus
Hrm. I'm not sure then. When I had this issue on Penn, it was not grabbing the attribute correctly due to an error on the parent sort (which is why I ended up going through and having it grab the attribute and determine where it put it based on that). -
if i remotely do the fil() it works fine.
-
@Cobaltasaurus
Do you need to set the attribute(s) visual (or equivalent on MUX)? -
Hm, let me try that -- I shouldn't have to because the room parent is inherit, but maybe??
-
scratch head ...that worked. Going to see if it has something to do with me setting it, and get my builder to set it on some exits.
-
The child room has no access to the filter attribute (the attribute, not that it's a filter) on the parent. I'm not kidding and it's a design feature for security. Here's one of the few times I'm going to say: Use iter() to build your own inline filter.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
@Cobaltasaurus
Yeah, once we'd ruled out the code looking at it correctly, it had to be visibility permissions. I don't know how inherit works on MUX in depth; generally if I have something that a non-permissioned something might need to see (like form tags for a Transformers game showing what mode), I'll globally set that attribute visual via @attribute/access so that any time that attr is set, it's automatically VIS. -
@Thenomain said in Room parent / exitformat weirdness:
The child room has no access to the filter attribute (the attribute, not that it's a filter) on the parent. I'm not kidding and it's a design feature for security. Here's one of the few times I'm going to say: Use iter() to build your own inline filter.
But why did it work before? It worked but stopped working for only objects that I recently messed iwth.
-
@Cobaltasaurus said in Room parent / exitformat weirdness:
@Thenomain said in Room parent / exitformat weirdness:
The child room has no access to the filter attribute (the attribute, not that it's a filter) on the parent. I'm not kidding and it's a design feature for security. Here's one of the few times I'm going to say: Use iter() to build your own inline filter.
But why did it work before? It worked but stopped working for only objects that I recently messed iwth.
A great mystery of life. This has been bugging me too. It isn't to do with attribute ownership unless you either used Wizard (#1) to set the value—where it still shouldn't matter—or accidentally set
&_build, which you normally would catch by now. -
@Cobaltasaurus said in Room parent / exitformat weirdness:
@Thenomain said in Room parent / exitformat weirdness:
The child room has no access to the filter attribute (the attribute, not that it's a filter) on the parent. I'm not kidding and it's a design feature for security. Here's one of the few times I'm going to say: Use iter() to build your own inline filter.
But why did it work before? It worked but stopped working for only objects that I recently messed iwth.
Unlike Penn, MUX and Rhost are more inheritance based.
If the object was owned to a wizard and set inherit, it likely would have worked as it inherited those wizard powers from the owner.
Likewise, even for non-wizard, it would still require inherit to access anything not itself.
Exceptions to this, like as you saw with the visual flag (or you can set the attribute visual) and various other things are likely possible depending on what codebase and what version of that codebase you have.
-
@Ashen-Shugar I'm just super stumped as to why it was working perfectly before, but then I made a new room and it didn't work-- and then unsetting and resetting the attribute on an exit made it stop working. The rooms weren't inherit, but the room parent is. The only thing I changed on the roomparent recently was I put in a @descformat.
Does anyone know a way to globally set an attribute as visual? Like is there a way to in the config file say 'build' is a visual attribute?
-
@Cobaltasaurus
I looked at the TinyMUX help but there doesn't seem to be help on just a general @attribute command. On Penn, it's @attribute/access/retroactive attr=flag list here; it will set the attr to have those flags going forward, and the /retroactive makes all already-set copies those flags.Many games I've been on that required things to be locked (wizlocked stats, etc.) used an attribute locker that went through and redid them after each shutdown, since Penn used to not carry those between shutdowns, and I find it easier in case I do miss something (or need a mass list), or need to add something quickly to just keep the locker object and chuck attrs on it.
ETA: Looking at the TinyMUX wizhep online, it looks like it might be a configuration directive...
& attr_type
Config parameter: attr_type <pattern> [!]<privilege> [[!]<privilege>]...All user-named attributes whose names match the wildcard pattern <pattern>
will receive the default attribute flags specified by the privilege list,
rather than the default attribute flags specified for user attributes
by the user_attr_access conf directive (defaults to none).Directives given later take precedence over earlier ones. For example,
if you want all attributes on your game that start with '_' to be
set only by Wizards, except for attributes that start with '_RPG',
which should be set only by Wizards and also not copyable by @clone,
you should do:attr_type _* wizard attr_type _RPG_* wizard no_cloneSee also: @list attr_types, attr_access, user_attr_access
-
Also confirmed it: It only stops working if I set the build attr on it. I had my build person set it and it worked fine again.
-
You might out rank the build person and it might be inheriting your rank, or if the room is owned by someone with lower permissiins. That is why I build all rooms but charge with a single builder. It prevents permission errors
Pay no attention to me. I'm old, jaded and generally unfriendly. I am prone to fits of stupidity, but I am still unique, just like everyone else. ~~ Current President of the Anti-Faraday fan club.
