Howdy, Stranger!
Categories
- 6.2K All Categories
- 3.1K Everything Achaea
- 1.5K North of Thera
- 26 Archives of the Terraformer
- 257 The Matsuhama Arena
- 885 The Golden Dais of Creation
- 299 The Scarlattan Theatre
- 149 The Blank Canvas
- 2K Getting Help
- 412 General Questions
- 258 Quick Class Questions
- 1.3K Tech Support
- 313 Client Help
- 486 Curing Systems and Scripts
- 841 Off-Topic
- 255 The Wander Inn
- 586 The Universal Membrane
- 298 Class Discussions
- 298 Individual Class Sections
- 20 Alchemist
- 9 Apostate
- 30 Blademaster
- 9 Depthswalker
- 14 Druid
- 4 Infernal
- 20 Jester
- 19 Magi
- 34 Monk
- 11 Occultist
- 8 Paladin
- 7 Priest
- 29 Runewarden
- 18 Sentinel
- 26 Serpent
- 20 Shaman
- 9 Sylvan
CONFIG COLOUR, Cities and Enemies.
Kenway
San Francisco
Would be pretty super cool if there was a CONFIG COLOUR option for Cyrene|Mhaldor|Ashtan|Targossas|Hashan|Eleusis, that would colour the names of adventurers. Would be nice if there was also an option for colouring city enemies. Recently started using WunderSys so I could learn how it works to help housemates who use it themselves and more than anything else, I miss Svo's NDB system which, for those of you not aware, keeps track of every single person you HONOURS, where they live, what class they are, their enemy status to your city house or order, and allows you to colour code. The class tracking is definite perk to having access to the coding knowledge that is required for NDB (I assume. I'm no expert on coding of any sort but I know I sure as hell couldn't write NDB and I'm better at scripting than most of the people I interact with IG) But it seems that being able to tell what city someone's in, or at the very least if they're an enemy to one of your orgs, should be a much more widely accessible feature especially given how many places handle fraternization.
TL;DR
CONFIG COLOUR <city> should totally be a thing
CONFIG COLOUR ENEMIES should, even moreso, totally be a thing.
TL;DR
CONFIG COLOUR <city> should totally be a thing
CONFIG COLOUR ENEMIES should, even moreso, totally be a thing.
12
Comments
Definitely is a good idea. I'd add to it as an alternative (something that's been turned down before as well) is just simply a player name color, so you could figure out that Jacen Malorn, Disciple of Kenway is actually Jacen.
- Limb Counter - Fracture Relapsing -
"Honestly, I just love that it counts limbs." - Mizik Corten
Especially given the stated desire to reduce the divide between coders and non-coders. This is something that non-coders can't possibly hope to do. Realistically, it's not even a thing most coders will do - it's mostly just a thing that divides people who spend money on third-party systems from those who don't.
And it also seems more and more important with the increasing focus on factionalizing the cities and making city membership even more important to determining the axes of conflict in the game.
It also shouldn't be particularly hard to implement this in a way that doesn't require a lot of server resources. And I don't think server resources are as scarce as they once were either - I mean we have things like server-side curing systems now so name highlighting can't be too tremendous a thing to ask for.
Thoughts on this? Something you might consider down the line?
- Limb Counter - Fracture Relapsing -
"Honestly, I just love that it counts limbs." - Mizik Corten
I certainly like it, but it would probably be a relatively massive/taxing coding implementation, as it would either require changing code in every message with a name in it, or would require some form of pattern matching run on every line sent to every player. Also, since the color would be different for every player seeing the code, this check would have to be done for every name displayed, for every player, multiplied by every player that sees it. A single market ad, shout, or deathsight, for example, might require a massive loop of color determination and pattern matching, both of which would be CPU burdomesom.
Also, the fact that it's incredibly simple client side is a fair point. Different people tend to have different concepts of how they want name highlighting done, as well. Would require additional options/configurations in the game to implement, which would make color determination game-side, every iteration, even more cumbersome.
Doesn't mean it can't be done though.
I've no idea how taxed the server is, currently, but I would imagine that some of the recent changes (primarily, server curing) are already significant additions to it's task load. Something to keep in mind is that latency and delay can be affected by CPU burdensome tasks.
The main difference there is that for names in arenas etc. the color is the same for everyone logged in.
With this suggestion, the color for names would be different for every name, for every player, and would thus be trickier to code, and could require hundreds of operations per player per name. QWHO, WHO, or CITIZENS would require massive amounts of CPU time, as well as world-messages.
Example: I set personal enemies to blue, Cyrenians to cyan, Mhaldor to Red. Some other guy sets his colors completely differently. Every time a name is used (almost every message in the game), the game engine would have to check MY configurations for THAT particularly person, and send me my own very special message (with correct colors) instead of just sending an identical message to everyone logged in.
So now not only is a deathsight, for example, 100 times more CPU intensive, but the message is actually being sent, individually, potentially hundreds of times (to everyone who can "see" that message), instead of just once.
Be warned though, I've just been approved for the trademark 'Colorzilla'.
It's already been done, and quite well.
Vadimuses has, unlike me, managed to avoid being publicly chastised for selling systems (to virtually the entire playerbase).
b) Vadi doesn't try to sell his systems based on automatic offence. And given that you've complained about people like Ashtan triggering their tactics, you attempting it as a selling point for your system is contradictory.
- Limb Counter - Fracture Relapsing -
"Honestly, I just love that it counts limbs." - Mizik Corten
No. See for explanation: All of my posts in this thread.
To elaborate: the game keeps a list of people to determine what to colour, based on what the person can actually see. Meaning enemies can be seen, due to the person being able to see CITYENEMIES, therefore a colour for those is quite easily possible. Cities of others can be configured simply the same way that HNT is, using the game's list of players.
I tend to doubt it would actually be that big of a difference, if implemented intelligently. Table lookups are usually quite fast, and any potential calculations to check which colour takes priority should be minimal, if they can't be eliminated entirely by semi-intelligent implementation. Decisions on how to colour messages will take longer, but I would be surprised if making those decisions 100th as fast would make them a bottleneck in how quickly things get displayed, or be a noticeable increase in cpu load. But as always, without access to the code, any estimates of such things are just wild speculation.
Edit: There is the question of whether it would actually require a lot more operations for certain messages, like if things like deathsights actually would then require some number of actions per person logged in, instead of some constant number. I doubt that's the case, at least for most things, since there are very few lines that everyone can always see. Deathsights, for example, must already require a check for each person for whether they're able to see deathsights, so adding in the colour checks could presumably be done at the same time. Aside from admin messages, god shouts, and certain world emotes, I can't think of any lines that wouldn't require at least a few operations to decide whether to show them to each individual.
Individual player names are used far more frequently in channels (and are in fact, a part of channel communication lines). I'd venture a guess in the hundreds if not thousands of times more frequent. Many commands also have multiple, or long lists of player names as well.
I've coded/admined on several MUDs, so I might have a little different perspective, but I don't think the average player really understands how much coding can go into a single line that you see, or how much those little things can add up when you have hundreds of people online, walking around, chatting, and fighting, simultaneously.
Player movement, for example, is a massive workload on the game (relatively speaking) and requires a ridiculous amount of checks, variable changes, validations, and so on, even though all you see is a room name and it's exits.
Don't get me wrong, it's a good idea for a feature, and I'd totally use it, and for all I know, the server is nowhere near reaching performance levels that merit concern. That's why this type of thing is purely for @Tecton and his posse to decide on.
I have no idea how the game code works. Everything was purely based on conjecture. Again, might not even be an issue anyways (although would still probably require a ton of coding to implement). Very possible that every message in the game would need manually changed.
Go participate in an arena game, and you'll see that the back end for the colouring is already there.
Lots of times I've looked at something that really should be super simple only to find out that it's so completely overcomplicated that it's actually easier to just redo the whole thing. This may or may not be the same way.
We do know from admin comments that some of the code would make tracing a single spaghetti noodle through a 5 ton barrel look like a piece of cake.
So really any conjecture about what's easy or what's not is about as useful as farting at a wedding - i.e. the only thing it accomplishes is mild distaste from the other guys and somewhat more annoyance from the hosts.
The theoretical difficulty of implementing it is not nearly so unknown. This is not some unimaginably taxing operation, or at least it needn't be.
It may be too difficult to implement in a satisfyingly performant way in the engine without costing too much coder time, but it's certainly not the case that the operations required are just inherently too costly.
Ultimately, it's still just a question of how much coder time it would take and IRE's willingness to spend that coder time.
And this bit is just silly: "It's really almost an entirely pointless subject anyway as basically everybody uses ndb and it's already a solved problem. And if they don't use it, they can make their own triggers or just not worry about it."
Not everyone uses ndb - not by a longshot. And the old argument that "everybody just uses svo anyway" was not a good one either - that's why we have server-side curing, which was a great addition to the game. Having to buy a third-party program is not a "solution". And as for "making their own triggers", that's a lot easier said than done. Most people have no idea how to work with databases, which is the only sensible way to do this, and a lot of clients largely can't make use of databases.
Most likely, you'll store the actual names and colors to be highlighted in memory, and maybe store additional but not always necessary information (what class are they? etc.) in physical memory eg. a database or a file.
However, since it's not like we have a million players, you could just as easily use plaintext files to store names long-term, or .csv files if you want more information. A few thousand names is a bit to go through if you're reading through it, but translates to maybe a few kilobytes. Not that this is the only way to do it, but just merely that it's a perfectly viable alternative to using a database.
Also not to say that any alternative is somehow easier to program in an effective manner!
Correct, and your explanations were more or less correct from an abstracted haven't-seen-the-code point of view. Not sure why multiple people disagreed with @Ernam here.
What the OP was asking for varies widely in terms of whether it's doable and whether it's worth doing.
Assigning a color to every city such that players are always colored the same way based on city may be doable/worth doing, but the key here is that it would be unconfigurable- you couldn't pick your own colors. We couldn't even let you turn this on or off. If you had ansi on, you'd see the colors. If not, you wouldn't. Things like city enemies or personal enemies much more problematic, because they aren't objective, they're relative to the viewer. Whether player X is a city enemy or not depends on what city the viewer is from. Same with personal enemies.
There are two main problems with the latter (viewer-relative player name coloring):
1. It is an n^2 population problem, meaning that the number of calculations that would have to be performed on every message generated goes up roughly as the square of the number of players in a location. This is obviously a major problem when people gather together. This kind of n^2 population problem already exists as everyone who was transformed into a demi-god at Nishnatoba during the Worldreaver event can attest to, both during the movement to Nishnatoba and then with so many people generating combat messages in the same room. Because of the exponential nature of the messaging requirements in that situation, things can go very badly very quickly.
Early MMOs like Everquest and Asheron's Call used to run into this problem frequently because movement in a graphical game is an n^2 problem - every time you move even a little, you have to broadcast that change to every player in visual range (compared to a MUD where you pretty much only have to broadcast movement to people in the room you're leaving and the room you're entering, barring some edge cases). They dealt with it via a portal storm, where when too many players were in an area, people would randomly get teleported away. (Seriously.)
Player messaging is the same issue here, particularly around things like movement into/out of very crowded rooms, deathsights, channel-based communication (potentially broadcasting to many viewers). So while having names auto-colored by city in something like KoTH is fairly easy, because all it requires is assembling the required string and coloring it properly then broadcasting that to everybody, with city enemies, you'd have to assemble a separate string per viewer. If there are 50 people in a room, that's 50x more CPU time for everything that gets broadcast to that room that has a player name in it. Giant events where we have 500 people in a room are extremely rare of course, and assembling strings of text is fairly fast, but a lot of messages get sent out with player names in them. Most of them, in fact.
2. Doing the latter is also a giant code refactoring problem. When we generate a message and expand the variables in those messages to include player names, we don't do it once for every viewer. We do it once, then send that message out to everyone who is supposed to get it. Aside from the n^2 problem above, we'd also have to go back and redo every single place in the game where a player name is expanded into a variable.
So basically, never going to happen. This is best done client-side, however nice it'd be to do it server-side.
I can't speak for anyone else, but I, at least, was disagreeing primarily with @Ernam's argument that this would add an extra layer of algorithmic complexity, in the sense of scaling with the number of players. For example, the argument that deathsight messages would go from constant time to scaling with the number of players, which I just don't see being the case. It would certainly be a potentially significant increase in the number of operations per message, and if that increase is too much to handle, that's a perfectly reasonable statement; that's the sort of thing we can't know without seeing the code. But arguing that it changes the scaling with number of players doesn't seem to make sense in the abstract.
I'm assuming that you mean here that the number of operations on each message goes as the number of players in the room (x operations to decide what message to send to each person) and the number of messages also goes as the number of players, so the total number of operations to color messages is ~n^2. That certainly makes things difficult, and it sheds some light on why things like the Bal'met event can cause such problems, but surely that's already the case? We already have config options for colors for different kinds of messages (says, emotes, etc) which presumably have to be checked each time we see a message, so I would think that the number of operations per second for coloring in-room messages is already O(n^2). Clearly, this idea would multiply the total number of operations by some potentially large number, which could certainly be game-breaking, but not because it's making it O(n^2) instead of O(n) or O(n^3) instead of O(n^2).
Yeah, sounds like that would make it a fair amount of work to do anything requiring coloring parts of messages (but not the whole thing) on a per-player basis.