Room parent / exitformat weirdness
-
We have the same flags and she is not on #1.
-
@Seamus Oh, that might be the issue perhaps? @icanbeyourmuse owns almost every other room on grid.
-
TinyMUX doesn't work that way with attribute inheritance. Even if she were #1, I don't think the system would automatically restrict access to the attribute; it doesn't even with attributes set on #1.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos -
@Thenomain said in Room parent / exitformat weirdness:
TinyMUX doesn't work that way with attribute inheritance. Even if she were #1, I don't think the system would automatically restrict access to the attribute; it doesn't even with attributes set on #1.
True I was just throwing it out there as a possible issue. I know with Rhost it can cause havoc.
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.
-
@Seamus said in Room parent / exitformat weirdness:
True I was just throwing it out there as a possible issue. I know with Rhost it can cause havoc.
Meh, not really.
Attribute ownership in Rhost is pretty identical to the TinyMUSH (MUX2) standard.
We do have some additional flexibility where if you set the attribute hidden and a given bitlevel the attribute will be hidden from anything below that bitlevel.
But this isn't set by just setting an attribute. The attribute flags have to be individually set.
For Rhost, the other things that can affect attributes:
If it starts with a '_' it's automatically wiz only.
You could apply an attribute prefix permission mask via @aflags.
The attribute could be set with individual global flags via @attribute.With Rhost, you could identify all the various global permissions via @aflags <attributename>.
You can just do lattr(#obj/attr) to see individual attribute flags on it as well.
Minus the magic foo with @aflags, the above would also work on MUX.
-
I /think/ I found the weirdness in the code. I set an exit in a room @Cobaltasaurus owns and it did the same thing that was happening to her. So, we probably need a builder bit or one of us completely owns all the rooms?
-
Oh! OH! It's ownership of the exits! If you own the exit, then you can see its attribute. If you don't own the exit, you can't.
If the owner of the room also owns the exit, the room should be able to read all (non-dark) attributes.
If the owner of the room doesn't own the exit, it doesn't matter who sets the attributes, the room won't be able to read the exit's attributes.
The only way around this is to set all the rooms themselves "Inherit". Do not do this.
Does that fit the model of the problem?
-
The exit owner did not matter but when i owned the room and set the attribute it went where it should. Even if @Cobaltasaurus owned the exit.
-
It's possible that the room can see the attribute because it's owned by you. I'm unaware if TinyMux works like this. I may test it in the future, but I'll also summon @Chime and @Ashen-Shugar again to weigh in on this one.
-
@icanbeyourmuse said in Room parent / exitformat weirdness:
The exit owner did not matter but when i owned the room and set the attribute it went where it should. Even if @Cobaltasaurus owned the exit.
Double check to see if you, yourself, are not inherit.
If a player is set inherit, it assumes inherit on anything they own.
DO NOT DO THIS.
Another option is setting the exits, rooms, etc with a @power of see_all (I think it is?) which also can be somewhat abusive. Other than that, I'm unfamiliar with anything in MUX that would grant one player full access to everything w/o an inherit for darkish things.
Best bet is what is suggested earlier, just make a central builder character and chown all rooms and exits to them.
Not only does it allow the ownership and permissions to match up, it also keeps things less cluttered as you know who owns what and why they own it.
-
@Ashen-Shugar I am a wizard. The only time the issue crops up is if @Cobaltasaurus owns the room and I set the attribute on the exit or vica versa.
-
Oh, right. If the room the EXIT is off of is owned by Muse and I try to set a flag on the exit it doesn't work right.
-
Are you sure this is true of TinyMUX too? I wouldn't be surprised if this is the first time I've heard of this, but this is the first time I've heard of this.
Edit: I just read more carefully what you said. "If a charobj is set Inherit..." Yeah, that I've heard of, long, long, long ago.
BTW: You're old.
-
@icanbeyourmuse said in Room parent / exitformat weirdness:
@Ashen-Shugar I am a wizard. The only time the issue crops up is if @Cobaltasaurus owns the room and I set the attribute on the exit or vica versa.
Who sets the attribute shouldn't matter. It'd be the ownership of the object/room/exit.
If you, as a wizard, set an attribute on something you don't own auto-hides that attribute, that's a bug. it shouldn't do that unless you expressly set the attribute hidden or if the attribute is pre-defined as wiz only.
-
I know this a million years old but I figured this out:
Both the exit and the room the exit is in have to be owned by the same person, otherwise the parent would not pull the attribute correctly and filter the exits into the right places.
-
@cobaltasaurus I believe you can set the parent itself as wiz and get around that.
Hello! Long time listener, first time caller...
-
@lithium Nope!
-
Weird
-
You're likely going to want to have a non-login Wiz character on the game (I usually give them the name of the game itself) and @chown everything that the game owns to them. That way, things don't break if original builders leave, they can't @destroy stuff in a huff, whatever. Not to mention that @search becomes your friend and not an obstacle.
Just be careful with that inherit flag, as it can introduce security vulnerabilities, as Ashen mentioned. I'd strip INHERIT and the WIZ bit, instead grant the objects/Attributes Visual.
You can do other things, too. Instead of using a normally-private attribute like &BUILD, try flagging your 'Street' exits with a trash flag like NOBLEED or HTML or (if you have them compiled), the MARKER flags? The reason that this should work is because (I believe) that any player can hasflags() an object without special rights.
-
Some games prefer to have player builds on different builder bits.
Mind you, while I’m not a fan of making user functions for every little technical issue, this may be the case for one.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos
