TinyMUX: How to set default player attributes?

[skew]

I have no idea how to set the default player attributes.

Some things (like, the stupid flag that makes jobs actually mark themselves 'read') need to be set as an attribute on the player bit, and I have no idea how to set it as the default. Best idea I have right now is to tie it to the landing room, so when you type "ACCEPT" to agree to our basic terms, it applies the attributes.

Any other solutions?

(Again, I'm on TinyMUX.)

[Cobalt]

Create a character parent, and then in the server set the player_parent to that dbref. So all players are automatically parented to it.

[Ashen-Shugar]

@Cobaltasaurus said in TinyMUX: How to set default player attributes?:

Create a character parent, and then in the server set the player_parent to that dbref. So all players are automatically parented to it.

That'd honestly be the best solution, but barring that like you mentioned something in the starting room when they do ACCEPT or maybe the master room when a player connects check the existence of the attribute, if it doesn't exist, set it.

Times like this makes me kinda wish MUX had some more features from (shudder) TinyMUSH3 or RhostMUSH.

Basically a global_clone_<type> so when a new type of that type is created, all attributes are copied from the clone to the target. I think Penn has work arounds with their action lists and other methods, but with MUX you're more limited by options.

So off the top of my head with MUX you're limited to:

1. Set the attribute via global master room code.
2. Set the attribute based on the player starting room
3. Set the attribute via a $command or exit movement or some other method of trigger
4. Set up a parent like mentioned above via @Cobaltasaurus
5. @hook on @pcreate and enforce pcreating new players (ugly and not suggested)

And with MUX2 (the latest) that... would be about it.

[skew]

@Ashen-Shugar @Cobaltasaurus Thank you both.

Is there any conflicts between setting a parent player object and having the players themselves set attributes? Example: If I set &jobsn XX=1 on the parent, then a player sets &jobsn XX=0, would it respect the player's settings?

[krmbm]

Unless TinyMUX is hugely different from MUSH, it will use the child's attribute.

In your example, the child's setting of 0 should be respected.

[Rook]

@krmbm Uh... what is 'MUSH' in regards to server?

[krmbm]

...TinyMUSH?

[skew]

@krmbm Thanks!

[Thenomain]

If you use @parent, you need to lock it against people overwriting it. It's unlikely in games where people can't create their own objects, but a crap shoot otherwise.