Server-side Queue

Drauka

The ability to add tasks to a queue server-side, to get past any latency in doing things due to being on the internet and a whole mess of networks. Sub-second timing means a lot in this game.

Iocun

Could you give a bit more details on how exactly you picture that queue? Fires on balance/equilibrium? Other types of balances too? How exactly are several items in a queue being handled? How could you manipulate the queue? Etc.

Just "a server-side queue" is a bit vague.

Drauka

Hrm, I'm not an expert in all the balances and stuff of everyone but if I was tasked with coding it I would probably implement hooks into when balances come back and see if there's a specific item in the queue.

Maybe different queue levels for eq, bal, herb, elixir, moss, eq and bal, and limb. Maybe with a command syntax of:

queue <eq|bal|eqbal|herb|elixir|moss|limb> <command string> 

queueshow [eq|bal|eqbal|herb|elixir|moss|limb] 

queueremove <eq|bal|eqbal|herb|elixir|moss|limb> <command string> 

queueremove <index id>

queuepause

queueunpause

queueclear

queue would add items to the queue.

queueshow would show what's in the queue, with an optional param to show a specific subset of the queue, showing the index number of the item in queue, the balance, and then the command string.

queueremove would remove items from the queue, either by two ways: 1) by balance and command string or 2) by index number.

queuepause would pause the queue processor from processing items from the queue.

queueunpause would unpause the queue processor if previously paused, otherwise it does nothing.

queueclear would clear all items in the queue.

The database schema may look something like this:

create table mortal_queue (

  id serial,

  user_id int referencing user.id, -- assuming all characters are in a user table or something like it

  balance_id int referencing balance.id,  -- assuming all balances are in a balance table or something like it

  command varchar(255),

  when_added timestamp default CURRENT_TIMESTAMP 

);

I'd implement these restrictions: the queue can only have up to 20 items in it, the queue if a FIFO (first in, first out) queue, and all queue items automatically expire after 15 minutes (or whenever is appropriate for cronjob cleaning).

So, when the hooks fire in the server code for a character for balances (assuming there are hooks), they would search the queue table for that user and for that balance and run the command for the first available item sorted by when_added.

Only real thing to sort out, would be in the queueshow and queueremove would be numbering the index from like 1-20 instead of using the database serial id that may reach up into the thousands after a short time. Maybe drop the serial id and index on balance id and user id instead *shrug*

Edit: forgot limb balance, and sure I'm not listing some other balances.

Iocun

I do like the general idea behind lessening the downsides of high ping, but there are still quite a few problems that need to be resolved, mostly revolving about combat balance.

For instance, a herb/salve queue would very effectively circumvent all illusions for herb/salve balance, which can otherwise be very useful. In order to keep them usable, would there be a need to also add a parser for receiving illusioned lines and having them make the queue think you actually got the balance? But if so... what if you have good cause to see that it's an illusion (e.g. through lifevision or timers) and your ping would deny you from still queuremoving it in time? Should lifevision catching an illusion just disable these illusions from being parsed?

It's not quite as big an issue with normal balance/equilibrium, but even then illusions can matter at times when you cannot see the prompt, i.e. in blackout.

It also has the further combat implication of generally speeding up curing, relative to offence: currently it's possible to spam (most) attacks before balance recovery and thus more or less bypass bad ping, while spamming cures generally isn't feasible because pre-eating a herb will actually prolong the time you are off herb balance. So the current balance between afflicting vs. curing speed is actually based around curing speed being affected more by ping than afflicting speed. Making both equally unaffected by ping thus is in many cases a buff to defence (both vs damage and afflictions). So should the defensive balances be slightly adjusted to make up for that?

That's just the first potentially problematic things that come to my mind. I still like the idea in principle, but I believe it may have a multitude of implications which we don't see fully yet and would need careful consideration, so it'd be a rather big change.

Drauka

Great points. I don't have the perspective you do, so that's awesome. Certainly don't wanna gimp the affliction classes.

Table this idea for a while. Too many issues that would need fixes and answers to, before implementing.

Iocun

Eh, I don't think the fact that it has some possible problems attached to it should prevent us from bringing up/discussing the idea. I do believe we should get something along this vein at some point - just wanted to point out that it's not an idea that will be possible to implement immediately and easily.

Nemutaur

I'd love a balance/eq server side queue just like Imperian has. That wouldn't impact illusion based classes all that much while levelling the playing field so that everyone who isn't in America with an amazing ping gets a small buff.

Trevize

I don't see a problem with it. If anything else, it'd give an (more) even field for combat to be balanced around.

Tael

I was sort of worried this would happen if it got split off. This was discussed in much greater length in the "If you were a newbie combatant" thread with a somewhat more nuanced series of proposals (including discussion of things like illusions).

The queueing system described here, for instance, doesn't actually help a huge amount with curing since you still have to wait a minimum of one round trip to cure - you have to wait to get the affliction message, then send the command to queue the cure. It would help in some circumstances, but not nearly so much as a simple, configurable static prio list.

The proposal I put forward came in two related parts:

The queue:

(1) An offensive queue associated with each kind of offensive balance (even a queue of 1 element would work).

-the "element" has to be able to be complex though, since you need a means of doing "free" actions like applying venoms, this is true even if you do a multi-element queue

The priority thing:

(1) An inept skill in Survival gives you a priority list for each basic cure.

1a. Whenever the server has an affliction, cure balance, or cure event, it runs the curing subroutine and tries to cure the highest affliction in the prio list that can be cured given known afflictions (so it knows to cure slickness before anorexia).

1ai. Loki and the like are unknown afflictions, but diagnose would add them (and see 3 below).

1b. The priority list only includes afflictions that you have encountered and cured manually at least once.

(2) A later skill in Survival allows switching of the priorities (no balance cost or requirement).

(3) A later skill in Survival allows manually adding or removing afflictions from the list of afflictions the character presently has (no balance cost or requirement).

3b. This lets users implement anti-illusion and active cures like, say, bloodboil.

Illusions are a little bit tricky, but not terribly. The simplest option would just be to run a pattern match against them for affliction lines - since you can't illusion that fast and it's a simple match, it should be pretty viable from a computation speed standpoint. Alternatively, you could give people the ability to directly embed an affliction message in their illusions - so I might illusion something like "conjure Iocun illusion Tael pricks you twice in rapid succession with his dirk\n$anorexia".

There are probably other solutions too - it's a very solvable problem with a potentially huge payoff in terms of evening the playing field ping-wise and making things more accessible for newbies. Also bearing in mind that the idea is to create a basic, IG curing system for people to build off of - once people build anything more complex to manage the server-side priority list and dynamically change it, you can start messing with their systems in more interesting ways again too.

But like I said, there's more written on this (and other proposals) in the other thread.

Tael

Also, you would probably want an ability to turn curing of an affliction on or off.

So, for instance, if there were no kind of Focus priority list (and there probably shouldn't be - it should probably only handle herb, sip, apply, and smoke), then the way you would code focus into your curing would be to turn off server-side curing of focus afflictions, then have your (client-side) system that focuses and then reactivates server-side curing of focus afflictions until focus balance is back.

Vadimuses

Nemutaur said:

I'd love a balance/eq server side queue just like Imperian has. That wouldn't impact illusion based classes all that much while levelling the playing field so that everyone who isn't in America with an amazing ping gets a small buff.

Agreed. Balance/eq is enough for a start, doesn't affect balance and helps more than potentially messing things up unlike other balances. I support a balance/eq server-side queue.

Drauka

I'd love to have it, personally. Svo goes nuts at times when I don't get a prompt back (girlfriend's internet service stinks, DSL more like DSsmell *har*har*).

Anything that removes the issue of network latency I'm all for it, especially if it can be designed around even better.

Iocun

I'd like a server side balance/eq queue, sure!

Froh

Vadimuses said:

Nemutaur said:

I'd love a balance/eq server side queue just like Imperian has. That wouldn't impact illusion based classes all that much while levelling the playing field so that everyone who isn't in America with an amazing ping gets a small buff.

Agreed. Balance/eq is enough for a start, doesn't affect balance and helps more than potentially messing things up unlike other balances. I support a balance/eq server-side queue.

I think you could add other balances (herb, etc.) without causing problems.  Those are more valuable anyway: you lose more momentum (fall behind on number of actions you can execute vs your opponent over time) from having .1 second higher ping on a 1.5 second herb balance than you do on a 3 second regular balance.

As others have said, it's best to keep the actual decisions on the client side, though.  Without a total redo of illusions, otherwise it would get too messy.  Unless they gave us a full scripting language and storage on the server side, there's a lot of illusion-handling that you just couldn't do.

 

Iocun

Froh said:

I think you could add other balances (herb, etc.) without causing problems.

What about the issues I mentioned?

Froh

Iocun said:

Froh said:

I think you could add other balances (herb, etc.) without causing problems.

What about the issues I mentioned?

I'm assuming good scripting, which is what we're approaching anyway. Is it really possible for you to reliably illusion an herb balance recovery within the extremely narrow time window when that illusion is plausible?  I know that you can hit it every once in a while, but is that what makes or breaks your class?

Honestly, I think most of the old-style free text illusioning is doomed in the long run anyway.  Relying on herb balance illusions in their present form has really disparate impact on other players depending on what their ping time is.  If herb balance illusions against a perfectly scripted opponent are in fact both possible and crucial to PvP balance, then they should be a server-coded type of illusion (much as afflictions can cause your prompt to show you as being at max HP) rather than some free text that happens to match a pattern.

 

Iocun

Yes, they only work once in a while. But with the number of things that can prevent illusions from working, making one that works once in a while work never at all makes quite a big difference, since most useful illusions don't always work. And sure, they do affect people with bad/irregular ping more than others, but the fact that everyone has some variation in ping still means that they potentially work against anyone now and then.

Are they crucial to PvP balance? No. Very few things are absolutely crucial to PvP balance. But illusions are one of the most interesting aspects of Achaean combat, and already have a very tough stand, so I feel somewhat justified in being quite protective of them. I do believe that completely removing the ability to illusion such things would be a loss for Achaea's combat environment.

"Old-style free text illusioning" may be "doomed" if a majority of us absolutely can't live without all sorts of new convenience additions that would negatively affect them. But I don't think they have to be. Yes, protecting their utility is a difficult thing and has far-reaching implications for many changes to Achaea, but I do believe it's a worthwhile effort.

All that aside, there's also the second point I mentioned: the issue of slightly increasing curing/healing speed across the board if you do something like that. Again, I'm not saying it's something that can't be worked around (e.g. by increasing all defensive balances by 0.1 seconds) - all I'm saying is that there are issues of combat balance associated with such change that need to be looked at in detail before implementing it.

Froh

Iocun said:

Yes, they only work once in a while. But with the number of things that can prevent illusions from working, making one that works once in a while work never at all makes quite a big difference, since most useful illusions don't always work. And sure, they do affect people with bad/irregular ping more than others, but the fact that everyone has some variation in ping still means that they potentially work against anyone now and then.

 

"Old-style free text illusioning" may be "doomed" if a majority of us absolutely can't live without all sorts of new convenience additions that would negatively affect them. But I don't think they have to be. Yes, protecting their utility is a difficult thing and has far-reaching implications for many changes to Achaea, but I do believe it's a worthwhile effort.

All that aside, there's also the second point I mentioned: the issue of slightly increasing curing/healing speed across the board if you do something like that. Again, I'm not saying it's something that can't be worked around (e.g. by increasing all defensive balances by 0.1 seconds) - all I'm saying is that there are issues of combat balance associated with such change that need to be looked at in detail before implementing it.

I don't know how to break up your quote into sections I can reply to, but I see three points from you:

1) It works sometimes.

2) "Convenience additions" like server-side balance-based queues could damage the utility of illusions

3) If those convenience additons are made, rebalancing in other areas would be required

Response:

to (1) and (2), True in the present form of illusions.  I would suggest that illusions which are supposed to represent direct game mechanics (fake HP, fake balance regain, etc.) should be specifically handled server-side and affect prompts, GMCP, etc.  The present method of spoofing that via free text is both highly ping-dependent and subject to script skill rather than player skill.

In that light, the twitch factor of "I know what command I want executed; when should I hit send" is presently a game played by computers rather than people and hence isn't fun per se.  Yeah, for me it is since I mostly write systems I don't bother to use but I'm strange.  It's also not particularly balanced by player skill or character abilities so it's hard to defend as a valuable game mechanic.

to (3), this is a bit dependent on what the point of balance is supposed to be.  In the "old days", things were supposed to be balanced between tritrans folks without much in the way of artifacts. Is ".1s ping with essentially zero deviation for any given packet" the point at which healing and affliction/damage speeds are supposed to be balanced against?  And yes, I agree that changing the way the server processes commands without assessing secondary effects is a bad idea.

 

Tael

Iocun said:

all I'm saying is that there are issues of combat balance associated with such change that need to be looked at in detail before implementing it.

I agree completely. I also think it has enough upsides in terms of both ping and newbie learnability that it's really something worth considering.rather deeply - to the point that these comparatively minor (though of course still extant) issues might warrant examiniation and solutions, rather than saying "there are potential problems so we shouldn't do it".

The only thing I can think of that illusions with either a pattern-matching or an affliction-line-embedding token couldn't do against a basic prio-based cure system is fake cures. But really, that's a pretty small loss and, while I've heard you talk about using them, I haven't heard anyone else talk about using such illusions in literal years since most systems have half a dozen failsafes to make sure they only accept cures they requested. I understand being protective of illusions, but this shouldn't have a particularly substantial effect. Since every other aspect of the system would have to be client-side, every other kind of illusion should be just as vulnerable. If anything - a pattern-matching/token approach to afflictions would actually make them harder to anti-illusion since it would catch the illusion and use a cure balance before you had time to do any sort of AA.

Iocun

I don't really want to go into too many details of combat balance, illusions, and whatever here, because that's all a bit besides my point. My point wasn't that having some sort of server-side curing or queuing is bad - I did say that I liked it in principle. My point is that it has a multitude of combat implications (which, according to the above posts, it seems most people are agreeing on) and is thus probably beyond the scope of a simple Golden Dais idea.

I was merely arguing against the claim "I think you could add other balances (herb, etc.) without causing problems." - not against trying to find ways to implement such a thing anyways in the long term.

Since the Golden Dais is meant for ideas with no or only limited combat implications, let's just cut it back to the request for a normal balance/equilibrium queue and discuss all that other stuff elsewhere. That sort of queue still has some combat implications of course, but I think we can agree on the fact that they're probably not quite as problematic.

Drauka

Well said