CONFIG COLOUR, Cities and Enemies.

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.

- Limb Counter - Fracture Relapsing -
"Honestly, I just love that it counts limbs." - Mizik Corten

Comments

  • The funny thing is, this already happens with Arena and World events.  I don't know why it can't also be done for, at least, coloring the names of city citizens.
    ~Kresslack's obsession~
  • Although Svo already includes this exact functionality + underline/bold/italic city/house/order enemies at will, putting something like that in the actual game rather than a third party utility would make a decent amount of sense.
  • Has been dismissed before as a waste of server resources, being something that can be done client-side. Many things have been turned down and later implemented though, so don't lose hope until an admin weighs in on it.

    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.
    image
  • KenwayKenway San Francisco
    Indeed, the intention is that only the name is highlighted. Otherwise the ADVENTURERS option would be rather redundant.

    - Limb Counter - Fracture Relapsing -
    "Honestly, I just love that it counts limbs." - Mizik Corten
  • edited November 2014
    Jacen said:
    being something that can be done client-side
    This is a good example of something that is ludicrously hard to do client-side though. You have to actually create, update, and maintain a database of every adventurer in the game and silently parse a number of different messages in a number of different formats. And it can become outdated quickly if you aren't constantly updating it manually.

    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.
  • KenwayKenway San Francisco
    @Sarapis @Tecton‌
    Thoughts on this? Something you might consider down the line?

    - Limb Counter - Fracture Relapsing -
    "Honestly, I just love that it counts limbs." - Mizik Corten
  • edited November 2014

    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.

  • I'd be surprised if it'd take a lot more resources to do a look-up to see what color to put before someone's name (though who knows, IRE's scripting language could be THAT BAD that it would!) The refactoring would most likely be the biggest drawback to an effort like this, even if there is existing functionality like this (arena teams/CTF).
  • edited November 2014

    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.
  • edited November 2014
    You could always make a new add-on to sell.

    Be warned though, I've just been approved for the trademark 'Colorzilla'.
  • edited November 2014

    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).
  • KenwayKenway San Francisco
    I fail to see how that's so much harder than clans/CT/HT/Order? Isn't that the same deal basically?

    - Limb Counter - Fracture Relapsing -
    "Honestly, I just love that it counts limbs." - Mizik Corten
  • Kenway said:
    I fail to see how that's so much harder than clans/CT/HT/Order? Isn't that the same deal basically?

    No.  See for explanation:  All of my posts in this thread.

  • edited November 2014
    That doesn't make any sense though because the game already outputs different colours for every single individual based on their preferences in CONFIG COLOUR. How is letting them colour the names of people depending on their city any different?

    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.
  • EldEld
    edited November 2014
    Kenway said:
    I fail to see how that's so much harder than clans/CT/HT/Order? Isn't that the same deal basically?
    The difference is that with channels, everything on that channel gets a single colour (for each person), so when the game needs to send your client '(Cyrene): Scarlatti says, "I'm so fab."', it just needs to do the one lookup to see what colour that should be, whereas if you were colouring names differently depending on affiliations, enemy statuses, and whatever else, then whenever you see someone's name (in communication, in-room actions, or whatever else), it needs to do a potentially large number of lookups to find the right color. So it's more lookups, from having to check more config options, and happens more frequently.

    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.
  • edited November 2014

    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.
  • Except that most of what you're talking about is calculated via the Rapture engine already. All that colouring would need, is to add in a table to check against as Eld said. Sort of like how all the various GMCP items are coloured. (room, exits etc)


  • 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.

  • edited November 2014
    No.

    Go participate in an arena game, and you'll see that the back end for the colouring is already there.

  • Rather than arguing endlessly about a backend that none of us really know about and being completely self-righteous about how it must be how we think it is, why don't we just agree that we don't know. If the admins want to comment on this, they will. If they don't, they won't. 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.

    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 Truths hurt. Always.
  • edited November 2014
    Hmm, noticed some other comments. Will reserve this.

  • The difficulty of implementing it given the existing engine is unknown and any comments on that are conjecture.

    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.
  • Agreed with everything but the last part. Although a database might be good for long-term storage, if you're using this functionality to potentially highlight every single line of text, do you really want to do an SQL query for every line?

    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!
  • And that says it all. Thank @sarapis for explaining in such a clear manner.
    Light prevails, always
  • Sarapis said:

    Ername wrote:
    Kenway said:
    I fail to see how that's so much harder than clans/CT/HT/Order? Isn't that the same deal basically?

    No.  See for explanation:  All of my posts in this thread.

    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.

    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.

    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).

    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).
    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.




    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.
Sign In or Register to comment.