@faraday said in Better Places Code:
@ixokai The cluster idea is similar to what I was thinking. If poses and emits were automatically color-coded with the regular pose/emit commands, and all it did was change the color (or add a prefix or something) it would probably be pretty low-hassle.
I'd be careful of using color, because what people like and dislike in color is so variable and up to personal preferences. The prefix thing I wouldn't hate (and the prefix can be color coded, I mean we tolerate channel names having colored text).
On BSP the space code did emits kinda like that:
[RAPTOR_108: Trajan] Trajan's raptor is consumed by a brilliant flash of light. Only empy space remains.
[RAPTOR_216: Sunny] 216 turns into formation of a triangle as the three Raptors make their way and the countdown begins. The time for butterflies and jitters are pushed aside, this one is all or nothing. A fold in space begins as Sunny follows in tandem with 108 and the bright flash of light is all that is seen, then they are gone from sight.
Yeah, that's not so bad. But does it actually improve anything? The scene will still be spammy and hard to follow if its got a bunch of people in it. And if it doesn't make the scene less spammy, you're going to end up with these little magic perfect bubbles of privacy in a room with crickets between them. Unless you add in mutter. (shudder)
I dislike mutter code but it's just a peeve. I prefer transparency, especially for the monitoring and logging reasons others have mentioned.
Agreed.
@Thenomain said in Better Places Code:
@ixokai
I'm not going to give you permission or not to opine, but your post was entirely "I don't code it nor use it", which doesn't answer the original question: How can we make it better.
You're forgetting to read what came before "I don't want to code it or use it", and I can't tell anymore if you're doing it on purpose just because or if you missed it.
I said I coded LA's clusters code, and explained how it worked (and its features are what I'd consider the bare minimum of a places system). To say in more general terms and use more words then I think are strictly nessecary but since you couldn't really get it out of the original post:
The 'place' as the unit of players talking is one we didn't like for all kinds of reasons, for one requiring them to be established before hand, for two their fundamental limits of the model (what places exist on a football field?). So we ditched that but kept some backwards compatible support for using pre-defined places if someone could be bothered to put them in a room.
The real abstraction we called a cluster, and defined it as basically an arbitrary group of players who self-determine if they're in, or not in, a given cluster. Cleanly exiting (either by moving to another room, joining another cluster(WITHOUT having to depart, I should have mentioned in my first response), or via 'depart') is as important as cleanly joining (either by join # or join person: if person is sitting at a 'place' named Table, then 'join person' should be functionally identical to 'join 1').
Supporting being in a place secretly, and detecting spies, should be general enough but able to hook into a random RPG system.
If you can manage to make it easy enough to talk into a place without significantly changing the UI of talking on the mush, I'd call it a miracle, but I'm not holding my breath. I find getting tt | right to be painful. But no one could think of a better idea that worked with the mush on LA.
That's what we had on LA for solving the place problem.
I'm still betting on: you can't make it better. You're reinventing rooms.
