Howdy, Stranger!
Categories
- 4.8K All Categories
- 4.3K Life in Lusternia
- 453 Announce Posts
- 75 Event Posts
- 1.7K Common Grounds
- 589 Q&A
- 83 Combat Overhaul
- 1.5K World Library
- 86 Combat Logs
- 870 Event Scrolls
- 403 Mechanic's Corner
- 329 Ideas
- 314 Last Chance Trading Post
- 478 Life Outside of Lusternia
- 9 Forum News
- 275 The Real World
- 94 Meet and Greet
- 37 The Funnies
- 63 Mafia Hideout
Server-side Curing
Hi again, everybody!
So, in the coming weeks, we're going to be taking a good, hard look at implementing server-side curing. This is going to be a huge project and, as such, we're generally am interested in hearing the player's voices on the matter and gathering ideas about specifics.
First, though, I would like to iterate a few things.
* This is not an update of FirstAid: I intend for this to be a competitive solution that doesn't require equilibrium and a diagnose every usage, and will be tracking afflictions from hidden sources and random sources into account as it exists to ensure it does not feel like it has a godlike overhead view for curing.
* This is not fully intended to replace client-side systems: While I want it to be competitive, it should not be an end-all-be-all; a finely tuned system geared toward the player using it should be able to outcure it, and I am not going to cover every single case that may pop up.
* It should be customisable: With focus as it exists, players should be allowed to set a number of focusable cures if they need it, and even be able to swap these on the fly.
* It should be interactive: Lusternia's combat system is heavily based around hidden afflictions in many places, and while best guesses can be made, the built-in curing will not handle all cases, so we will be providing a way for players to 'predict' what afflictions they have and the system will attempt to focus on those, benefitting the correct and possibly wasting balances of the incorrect.
* It will not be done in a week: This is a large undertaking, and to ensure the game continues to run smoothly, we will likely need to optimise the system - even if it is coded in a week by some miracle, it will likely not be released until we are happy with the performance underneath the hood.
* It will not handle defenses (yet): Lusternia's defense system is, underneath the hood, still covered in cruft. We have plans to look into this, but it will take a lot more time and may even be beyond the scope of this system in general anyway. A few exceptions may be made on a case by case basis for ones that are considered vital (insomnia, truedeaf, trueblind), but no promises.
* Yes, we are coding envoy reports first. Stop asking me every time I reload the code or open my mouth if succumb is fixed.
So, given that, we would like to hear any input you may have. Are there things you want to see in the system? Things you feel should work certain ways? Do you feel we should emulate a standard latency with curing like some other games do? Let us know!
- Ianir
So, in the coming weeks, we're going to be taking a good, hard look at implementing server-side curing. This is going to be a huge project and, as such, we're generally am interested in hearing the player's voices on the matter and gathering ideas about specifics.
First, though, I would like to iterate a few things.
* This is not an update of FirstAid: I intend for this to be a competitive solution that doesn't require equilibrium and a diagnose every usage, and will be tracking afflictions from hidden sources and random sources into account as it exists to ensure it does not feel like it has a godlike overhead view for curing.
* This is not fully intended to replace client-side systems: While I want it to be competitive, it should not be an end-all-be-all; a finely tuned system geared toward the player using it should be able to outcure it, and I am not going to cover every single case that may pop up.
* It should be customisable: With focus as it exists, players should be allowed to set a number of focusable cures if they need it, and even be able to swap these on the fly.
* It should be interactive: Lusternia's combat system is heavily based around hidden afflictions in many places, and while best guesses can be made, the built-in curing will not handle all cases, so we will be providing a way for players to 'predict' what afflictions they have and the system will attempt to focus on those, benefitting the correct and possibly wasting balances of the incorrect.
* It will not be done in a week: This is a large undertaking, and to ensure the game continues to run smoothly, we will likely need to optimise the system - even if it is coded in a week by some miracle, it will likely not be released until we are happy with the performance underneath the hood.
* It will not handle defenses (yet): Lusternia's defense system is, underneath the hood, still covered in cruft. We have plans to look into this, but it will take a lot more time and may even be beyond the scope of this system in general anyway. A few exceptions may be made on a case by case basis for ones that are considered vital (insomnia, truedeaf, trueblind), but no promises.
* Yes, we are coding envoy reports first. Stop asking me every time I reload the code or open my mouth if succumb is fixed.
So, given that, we would like to hear any input you may have. Are there things you want to see in the system? Things you feel should work certain ways? Do you feel we should emulate a standard latency with curing like some other games do? Let us know!
- Ianir
Forum Avatar drawn by our lovely Isune.
25
(c) Iron Realms Entertainment 2012.
Comments
Can we implement the chain cure setup though? cures <cure> <cure> <cure> <cure> Or something that allows location? Maybe allow an aff to trigger a focus? CURE ANOREXIA SLICKNESS DAMAGEDTHROAT, and it would try all those in focus.
Edit: But yeah, will it have latency coded into it? My system is pretty great, but I can't ever overcome my .3s average latency. If you want clientside to be competitive, you'll have to include a built in lag.
What are your thoughts on that?
I mostly just want something that I can actually use. If it's hamstrung with limitations to the point that it's better to have your own system, then people will still feel required to have their own system and that kind of defeats the whole point.
Off the top of my head, allow for toggling ignoring afflictions.
Balance queueing, i.e.:
QUEUE SMOKE STEAM [FOCUS <aff>] etc. (To control what the serverside curing does next, and chase balance without having to completely turn off serverside curing)
Automatically instantly react to/ignore an affliction, i.e.:
AUTOCURE [AFFLICTION] ON/OFF
Adding afflictions/removing afflictions manually.
I'll keep thinking on it.
Being able to toggle afflictions seems fair, as well as being able to "override" what it wants to cure next with what you want it to via the Focus command.
@ianir - Some purely informational commands would be very useful to help us build our own systems around this, such as a way to see what affs ssc thinks we have.
I'd also love it if the curing was smart enough to auto-disable during places it needs to disable, eg teleport, flinging soulless, etc. I mean, we're going to be manually disabling anyways for that stuff, why even have the newbcheck of coding in a disable?
Just food for thought. I'd recommend something like a .4-.5s delay in recognizing general command failure, and I guess a .2-.3s delay in recognizing specific command failure. (Normally serverside would already know that you have anorexia and not sip, but if it was given under blackout, it'd have to simulate figuring out that you have the affliction).
Blackout is trickier, though-- do you have it just not do anything except sip health until you diagnose (and you could then do a simple client-side script for what you want it to "assume")? Do you have it just try each of the cures on each balance? Do you give it a toggle to let you do one way or the other?
Tradeskills can be done via reports (a special report if required for certain ones), imo. Most aren't going to really have that much of a problem, only a couple (alchemy and possibly herbs).
I feel like, if your goal is to keep player created systems viable, the goal should be to keep parity between the tools that you're providing and what players can already do.
If you are the make an alias and spam it type server side will suit you fine, but at the top tiers of combat having your own system will be a noticeable difference.
For instance there are all sorts of alternative cures and unless serverside, and it just might be, is accounting for every variable of special cures, shrine cures, org potions, and what not then you will only get that indepth in client side.
Monks, no public comment at this time. However, stay tuned.
Tradeskills, envoys can handle. However, we already have a plan for alchemy which is just waiting on the last of the old non-overhaul afflictions to be moved over (which I spent some hours last night going over with envoys and will be fully handled along with the next batch of envoy reports).
And to preempt the next bit of 'unfinished project' nitpicking, factions are coded. We're waiting on org stuff now.
Unfinished projects are quickly being completed as several have mentioned, and I am more than capable of gauging project progress and resources to be put toward said projects. Prioritisation is something I take very seriously, and I don't start a new project lightly without heavily scoping it out, which I have already begun, and the purpose of this thread is more to get input and figure out where I'm missing things in my scope, as well as to get input on the one or two parts I am entirely unsure how I want to handle (i.e. emulated latency in curing and something I haven't mentioned but have actually seen brought up already in responses).
If you disagree with my choice in prioritisation, that is of course your prerogative, but I hope I haven't disappointed with such thus far in the few months I've been here in that regard.
Potentially, and that's what I'm interested in finding player thoughts on. Danquik brings up a good point about skill-based curatives, which I will not be handling internally except in rare cases (springup, summer/tipheret). However, I will also point at Achaea (and I believe Aetolia) which have a 100ms latency on all server-side curing. Personally, given the way Lusternia's prevalent skill-based curing exists (every class has some form of it, some multiple), I am unsure this is actually a concern, but this is of course why I ask player opinion.
Specific command failure is something I already have scoped to account for. General command failure was actually something I overlooked and will be adding to my plans formally tonight - I agree a command retry wait will be necessary for general command failure, and while numbers will need to be fine-tuned, .4-.5s does seem to be a good buffer for that.
Blackout, I'm likely going to mark them as hidden afflictions internally without incrementing the player's hidden affliction counter. Given how this should work, that will likely solve the situation 100%. I may also include a configuration to automatically diagnose after a blackout ends, but this is up in the air.
1) Should be doable - I'll look into it.
2) I'll look into it!
3) Yeah, that's fair. That may actually involve recoding some of these, but it can possibly be implemented for some interruptible actions.
Ignoring will be included from the get-go. It's kind of necessary.
As for the queueing, agreed. I'll see what I can do.
CURING will likely just be moved over to this. Not sure what to do about FIRSTAID.
The future of aeon in this depends on the report for it that was just finalised. Stay tuned.
Messages can be done.
Generally, skills will be handled on a case-by-case basis. Consumable standard curatives should all be included consistently.
This should be breadcrumbed, yes. As CURING is already consistently breadcrumbed to in both as a general rule, it'll likely just replace that. Even use the same verb.
Didn't even consider that as a benefit!
I will throw you into the giant weed pile in the centre of Brother Sun. May you burn with the fury of a thousand fires and your smouldering corpse be lost to the ages.
100ms delay to emulate latency sounds reasonable to me, if we want to standardize serverside curing with other IRE games. I know we usually try not to do the same things, but this really should be an IRE product (like Nexus, or the Flash client), and not a game-by-game product. That said, I know that it's impossible to ask for IRE to standardize their server-side curing systems all the same way, as the meta for combat in each game can be quite different and warrant different considerations. Latency, though, I believe would be one of those aspects where following the best practices of oither IRE games is a wise choice.
Regarding things like stupidity and jinx, you can simply have it emulate general best practices in player code. Pick one of the systems out there, see how it tries to code for command failure, and have the server-side system follow that thought process. For example, if it's a tempTimer check (send a command, start a tempTimer of 0.5s, after which resend command if there is no confirmation message) then simply have the serverside system resend failed commands after 0.5s, or something like that.
2) The idea that if you use server-side you are not using client-side or vice versa is a false dichotomy. There will likely exist a space for both to be used in tandem. In fact, I wouldn't be surprised if this is what the top tier "systems" will end up doing - a client-side system that works in tandem with the server-side system, effectively taking the best of both worlds.
To echo what others are saying, ideal system should be client-side tweaking the server curing on an as-needed basis ("Shuyin just walked in with claws and started wailing on me, better shift transmology and paradigmatics affs up the prio list.", "I just switched from Healing to Hexes, gotta throw the old curelists in the rubbish bin and start over.", "Maligorn just dropped Westwind, I should lower the priority on a couple of those affs.") while letting the ssc deal with the 'heavy lifting'. It would also likely be tied in to your movement and offense too (things like Scentgo, mapping, sprinting, and accounting for Furrikin Roll/Wriggle, pausing your attack queue so you can fly/run/shield, etc.) in ways that ssc either can't or shouldn't account for.
That said, a couple questions, O Unusual One:
Will SSC have the ability to remember priority sets?
Will it be able to account for artifacts you own/are loaned?
Can we dispense with the newbcheck LIGHT PIPE mechanic yet?
After SSC is a thing that exists, will we revisit the collegia that currently have curing/healing 'courses'?
Who is John Galt? Will SSC be able to work properly while locked into an aether module?
It will likely check inventory, not artifact ownership, in these cases. This is more a speed thing than not.
I'll get back to you on 'LIGHT PIPE' - Not a decision I can make myself.
Regarding collegiums, we'll see. I'll keep that in mind, but that's more up to the patrons of each org.
Don't see why it wouldn't re: aether module.
Accountability is necessary.
That seems quite high. Right now certain american folks can get a back and forward latency of like under .1 so they've failed the command and tried it four or five times again in the space of a server side curer doing it.
Also as a kind of link in to that its pretty common for people to code mutli entry systems when they know they are afflicted with stupidty/amnesia etc. So like could the server side system have something similar in attempting to eat/smoke any type of cure twice when under a command denial effect.
Discord: Pharanyx#4357