Your favourite client-side script features

Tahquil

Don't think WALK TO should be able to traverse planes  

Tael

Defence defup vs keepup would be really nice.

You can sort of hack together a way of doing it with the current system, but it really ought to just be a thing.

And being able to use abilities in lieu of curatives in general would be nice. Not just thirdeye, but also things like SIGHT and BLIND in kaido/shindo. It's silly to have those neat little flavour abilities, but not have the built-in system know to use them.

Kyrra

Tael said:

Defence defup vs keepup would be really nice.

You can sort of hack together a way of doing it with the current system, but it really ought to just be a thing.

And being able to use abilities in lieu of curatives in general would be nice. Not just thirdeye, but also things like SIGHT and BLIND in kaido/shindo. It's silly to have those neat little flavour abilities, but not have the built-in system know to use them.

I just create aliases to do queue the defs that either can't be put up with other things, or the ones that sort of tend to not want to cooperate. It's just something I hit once everything else is done when deffing up.

Kasya

Pathfinding! I hate not having it in Nexus, I hate having to change landmarks around because I can't just RF a room. 

Yen

If serverside curing were smarter about recklessness ...

Rangor

I'm mostly fond of Mudlet because it supports a powerful programming tool that we can do whatever with.

For things that could get integrated into achaea client.. gmcp.Player.Affs, to see what afflictions I am currently afflicted with to make it easier to do prio swaps.

NDB database that lets me check if people in my area are allies or enemies.

All the mudlet Mapper functions.

Arditi

Automated Tarot inscription is the big one.

Antonius

Rangor said:

I'm mostly fond of Mudlet because it supports a powerful programming tool that we can do whatever with.

For things that could get integrated into achaea client.. gmcp.Player.Affs, to see what afflictions I am currently afflicted with to make it easier to do prio swaps.

NDB database that lets me check if people in my area are allies or enemies.

All the mudlet Mapper functions.

JavaScript is just as powerful as Lua, and has most of the same language features. The only thing it doesn't have is real database support; localStorage is an option but there are limitations there based on browser, if I recall correctly.

GMCP afflictions and defences have been a thing for a while now. Due to the nature of GMCP you do need to use the relevant events to construct your own tracking table(s), though. Presumably the Nexus client already does this somewhere to display afflictions in an info window? Could potentially just use that for any scripts you need to write.

What features of NDB do people actually want/use? I'm pretty sure it tracks a lot more than I actually care about (essentially just which city they live in), how many people are actually making use of that? Implementing highlighting of names based on city client-side should be easy if you have the data (assuming you can programmatically create triggers in the Nexus client). Is IRE/Achaea willing to provide a (JSONP) API to get that data?

Morthif

NDB city highlighter and enemy highlighter are just to convenient and there are a couple good search functions built in that I use a lot

Aesi

I would (and correct me if it isn't there) like the ability to serialize tables to HTML5 localstorage (key,value). Not sure if it works currently the way your functions and scripts get sandboxed.

Also, some utilization of background workers or something to process incoming data quicker. In raids the HTML client seems useless as it chokes on a ton of input coming down the pipe.

Rohai

Bulk handling of enemies and allies would also be nice, especially with multi-class on the horizon. If there was a way to UNENEMY CITYMATES without using namedb, or even just ALLY PERSONA PERSONB PERSONC, it would be really helpful.

Antonius

Jhui said:

Also, on the same lines as the pipe changes, if we can make all defs that require balance/eq but don't use it get automatically put up before queueing.  Stuff like parrying, mounting, summoning breath.

@Makarios: Has this one been done? I've noticed things working slightly differently to before, but it also seems to be applying to (at least some) defences that consume balance/equilibrium to put up. Should I be filing bugs on some or all aspects of this?

Morthif

Antonius said:

Jhui said:

Also, on the same lines as the pipe changes, if we can make all defs that require balance/eq but don't use it get automatically put up before queueing.  Stuff like parrying, mounting, summoning breath.

@Makarios: Has this one been done? I've noticed things working slightly differently to before, but it also seems to be applying to (at least some) defences that consume balance/equilibrium to put up. Should I be filing bugs on some or all aspects of this?

Yes check rants section. @Makarios commented. Post incoming.

Trevize

One note on the system - it appears to stops curing affs you have based on affs that would prevent it - even if the system 'doesn't know' that you have them.

For example, loki giving paralysis and you get knocked down - happened in hunting a few times, system didn't try to stand (which would have alerted it to paralysis) because I was paralyzed, but didn't 'know' I had paralysis.

Antonius

Antonius said:

Jhui said:

Also, on the same lines as the pipe changes, if we can make all defs that require balance/eq but don't use it get automatically put up before queueing.  Stuff like parrying, mounting, summoning breath.

@Makarios: Has this one been done? I've noticed things working slightly differently to before, but it also seems to be applying to (at least some) defences that consume balance/equilibrium to put up. Should I be filing bugs on some or all aspects of this?

@Tecton @Makarios This is probably the single worst change to the game for quite some time. Can we either change it to only put up defences which require, but don't consume, balance/equilibrium before running queued commands, or simply change it back to the way it was before? Give us a CURING/CONFIG option to pick how we want it to work?

Right now using server-side curing for handling defences which consume balance is just a huge liability.

Jhui

I get what you're saying, but why are you using 1 system (queueing) to override a 2nd system (defence keepup)?

Shouldn't you just not have any bal or eq defences on your keepup?  Essentially, if queueing weren't a thing, you'd be hoping your ping put your commands before the server put the defence up if it were still the old way.


I'd be fine with them changing eq/bal defences to not prepend queueing right now, because there just aren't any eq or balance defences i'd want to override my queueing, but that doesn't mean that won't change in the future.

Tael

I think more than anything this really highlights the necessity of having separate defup and keepup.

So:

1. Keepup always prepends queued commands. (so if you want a defence to actually be kept up and override queueing, you can do that)
2. You can just keep balance-taking defs out of your keepup so they don't interrupt you. (if you want to put one up, you can just queue the command to put it up like any other command)
3. You still have the convenience of putting up all of your balance-taking defs via a defup command.

Also, the system will use thirdeye now, and that's great - but could we please get it to also use the kaido/shindo sight/blind/deaf/hearing abilities too?

Jhui

ya think the big thing is no defup/keepup separation

Sena

Tael said:

Also, the system will use thirdeye now, and that's great - but could we please get it to also use the kaido/shindo sight/blind/deaf/hearing abilities too?

Kaido/shindo blind/deaf have 6 second delays, while bayberry/arsenic is instant and hawthorn/calamine is much faster than 6 seconds (even if you add herb balance). So always preferring the abilities makes sense for defup, but not for keepup.

I can't think of any reason not to always prefer sight/hearing over epidermal whenever possible, though.

Antonius

That wouldn't actually help me at all in the situations I have most issues with it, which is not being able to get out of the room after I burst because it's redeffing a load of defences that keep me permanently off balance until I die again. That was a non-issue before because I could just queue commands that ran before it tried to do so.

The best solution, I think, would be to allow queueing to be assigned a priority the same way that defences and afflictions are. So I could assign queueing to, for example, 20. Then I could have non-balance/equilibrium using defences at 19 and balance using ones at 21+. That seems like a lot more work than reverting to the old way though. I could work around it, but seeing as the point is to reduce the need for client side code, that seems kind of backwards.

Makarios

We'll do something here.

Tael

Even if queueing gets a slot in the def priority list, I think there's still a serious problem.

I don't want to have some long balance def in my def list at a lower priority than queueing, then queue a move or some other thing that doesn't take balance, then get stuck waiting for that def's balance to go before I can move again. Allowing us to give a priority level to the queue doesn't solve the problem. If you're trying to run, unless you put the commands in very, very quickly, the system is going to insert one balance-taking action between each movement (if you need to move more times than you're able with the hasty message, it doesn't matter how fast you input the moves), which is pretty far from ideal. Regardless of the priority I set for queueing, my only solution there is to put up that defence (and all the other ones I don't care about spending time to keep up during combat) manually, which is not totally trivial as soon as you have a fair number of such defences.

As for how you solve the problem of not being able to move after bursting because it's redeffing - there's a pretty clear solution: the keepup list doesn't activate until you do the DEFUP command. So when you die or logout, all of your defence stuff disables, and then you do DEFUP at some point and it both enables your keepup and does your defup. That's probably the right way to do it anyway, so people can, for instance, log in to check messages or read news quickly without wasting resources putting up their defences like they do right now.

So:

1. Keep the new system where queueing gets overridden.
2. Separate DEFUP and KEEPUP lists.
3. KEEPUP is disabled on death and logout.
4. CURING DEFUP puts up all of the defences in the DEFUP list and enables the KEEPUP list.

Antonius

I think we want different things and/or have different problems we want to solve. For me, personally, I have no issue with the system putting up balance using defences, provided I can override that and get out of the room. That's literally all I need. If it stops me from immediately running to the other side of the world that's less of an issue (for me, personally).

If they wanted to separate DEFUP and KEEPUP then great, but that would just be a nice to have for me. By no means required to solve the particular problem I have.

Krypton

Trevize said:

Klendathu said:

Even Mudlet Mapper doesn't use Gare, so I think that one's a bit of a stretch, but duanathar(an) would be great

Warp and swimming already take balance into account and such. It doesn't sound difficult at all.

What systems integrate warps for auto-walk already? Would be great for the home client to have this!

Kyrra

Krypton said:

Trevize said:

Klendathu said:

Even Mudlet Mapper doesn't use Gare, so I think that one's a bit of a stretch, but duanathar(an) would be great

Warp and swimming already take balance into account and such. It doesn't sound difficult at all.

What systems integrate warps for auto-walk already? Would be great for the home client to have this!

Mudlet Mapper does this.

Sabiru

From the perspective of somebody sizing up the prohibitive hurdles to restarting, which I guess isn't too different to just starting: if you truly want to reduce the need for people to use client side curing, you have to change the way priorities are viewed by the serverside curing.

At the moment (from my limited understanding) curing works like this:
You set priorities, and the first affliction which is cured is the highest priority which can be cured.
Eg. Your (greatly simplified) priorities are 1: hellsight, 2: paralysis, 3: asthma, and you have all three.
You eat bloodroot.

It's a fair design decision, but the above situation is clearly undesirable, and even in this very basic scenario it becomes necessary to have a client-side script working in parallel to constantly adjust priorities.

You could, instead, just about do away with the necessary clientside bolt-ons if you slightly changed the way you viewed the priority system to a philosophy where the server will attempt to cure the highest priority affliction by any means necessary before moving on down the list, even if that involves curing a different affliction (usually one of impatience, paralysis, asthma, slickness, but occasionally right arm, webbed, etc).

In the previous example, you would eat kelp and smoke.

This change in approach would allow your average player to carefully tailor and maintain more static priority lists which are changed according to opponent/strategy rather than dynamically in parallel to accommodate the current serverside behaviour.

This is the approach (though the implementation of course varies per system) that clientside systems have had to take* - hence the emergence of Wundersys - to be at all effective, and so will serverside if your goal is to eliminate their need for the bottom and possibly middle tiers.

So that it's clear where I stand, I think that if the line is drawn at this point and never ventures into countering strategies rather than situations (the difference between curing perfectly out of a near-lock and avoiding a vivisect by pointedly not curing an affliction), then the elimination of systems for bottom and even middle tiers is a very good goal.

*from the death of Vadi-M onwards, though Oregano, Tanris's, Omnipave and Sage (I think Sage wasn't initially, but later was) were doing this during the time of VadiM.

Antonius

There's a big difference between your example and curing perfectly out of a near lock, in my opinion. One is simply pushing asthma above paralysis on your priorities, the other is making an intelligent decision about what the best affliction to prioritise actually is based on all of the afflictions you have; I'd be fine with it essentially doing the former (so it would implement the very few basic priority switches that systems like Svo and WunderSys come with) but not with it doing the latter.

Sabiru

You're right, it definitely wouldn't go into counting kelp afflictions and things like that - I'm essentially referring to simple automatic priority switching, though I worded it as a slightly different approach to the priority list (where highest priority is in fact the highest priority).

I would have it take outrifted herbs into consideration, though, for bumping up mending to arms, for example.