CURING ON GMCP

Tael

The title is not intended to be yelling.

It would be incredibly handy if the new CURING ON system had GMCP events.

Specifically, if we could get:

1. The information in CURING STATUS (and could we please add whether health or mana is being prioritised to this list?)
2. The information in CURING PRIORITY LIST
3. The information in CURING PRIORITY DEFENCE LIST
4. The information in CURING QUEUE LIST
5. The information in CURING PREDICTIONS

Obviously these should not be sent all the time, only when requested by the client (and maybe on things like diagnose?).

All of this is information already available off-balance and none of it gives any unfair advantage, it's just a pain to parse the strings by hand.

This would go a long way to making it easier for new players to start building on top of the CURING ON system.

Klendathu

Been asked before, been denied before.

Tael

Oh

I searched to try to find any mention of it, assuming it might have been. Can someone link it and the reason for denial?

Ernam

Has yet to be stated why we can't have it.  I'm assuming it's simply due to coding complexity, since there doesn't appear to by any visible reason to deny this.

Herose

Thought they said it was because it would give to much of an advantage to those who can code vs. those who can't.

Ernam

I recommended GMCP along with a simple: show afflictions command to show what you currently have, which would respect masked afflictions until diagnosed (the same list Curing uses to determine what to cure).

That command would completely alleviate the coding problem, and would get rid of one of the biggest reasons that server curing still requires a system.

Antonius

Herose said:

Thought they said it was because it would give to much of an advantage to those who can code vs. those who can't.

They did. Personally I don't agree with that assessment, but not my decision to make.

Tael

Herose said:

Thought they said it was because it would give to much of an advantage to those who can code vs. those who can't.

That can't be the reason. It's the exact same advantage anyone who can code already has - all they have to do is parse the output of those commands. It's inconveniently formated, but it's far from impossible. Pretty much everyone who fights with a "system" already tracks afflictions even more accurately than those commands allow for.

Rom

Tael said:

Oh

I searched to try to find any mention of it, assuming it might have been. Can someone link it and the reason for denial?

Ernam said:

Has yet to be stated why we can't have it.  I'm assuming it's simply due to coding complexity, since there doesn't appear to by any visible reason to deny this.

Answer:     Edit: (Oh, this totally got answered already, guess I skimmed over it. This text is trapped in quotebox hell.)

Tecton said:

Creates too much of a divide between the people who do and do not have the coding knowledge to utilise the functionality.

Ernam

It simply isn't true.

Addama

I mean, isn't there already a huge divide between people who can and can't code?

Nim

Also especially if they code the HTML 5 client to use it. Right now, it's the opposite of what they want; hardcore coders benefit the most, since what's being asked is still completely possible to code, just time consuming and a bit complex to manage.

Ernam

At this point I wouldn't say that any client is "best" for hardcore coder types.  Neither client really seems to limit what you can do.

Addama

Nim said:

Also especially if they code the HTML 5 client to use it. Right now, it's the opposite of what they want; hardcore coders benefit the most, since what's being asked is still completely possible to code, just time consuming and a bit complex to manage.

That, and the documentation is very lightweight, so you have to poke and nudge people to get relatively basic information about how things work.  If you don't already have the initiative and the know-how to code, getting anything more elaborate than highlighting done is not happening.

Eld

Herose said:

Thought they said it was because it would give to much of an advantage to those who can code vs. those who can't.

That was in response to a request for affliction info in GMCP, though, which is not what this thread is asking about. I don't recall having seen any requests for any of the curing system status info, but there may have been. @Klendathu, do you have a link to a previous request, or were you also thinking of the affliction info question from the Ask Your Producer thread?

Klendathu

Re-reading the OP, @Eld is correct in that something different is being requested. I have already hackneyed something together to work off the system messages, but would love a GMCP type thing so I don't get spammed out every time I change my curing defence prios!

Jonathin

Addama said:

I mean, isn't there already a huge divide between people who can and can't code? 

Daeir said:

Yep.

Yes and no. I can't speak for the other coders out there, but I personally try to bridge the gap by giving away scripts for free (without exception) and helping to teach others how to do basic things. I know that Wundersys is great for people that can't afford or don't want to buy Svo and there are other people who give away their scripts for free as well (like Sohl).

Iocun

I try to bridge the gap by including bugs in my scripts, so they make me die occasionally.

Addama

The gap is there, players who can/will code will sometimes code for those who can't.

Adding GMCP functionality will not widen this gap in a palpable way.  It's already there.  It's the Grand Canyon.  But it might enable players who can/will code to help players who can't/won't code. 

Tael

Eld said:

Herose said:

Thought they said it was because it would give to much of an advantage to those who can code vs. those who can't.

That was in response to a request for affliction info in GMCP, though, which is not what this thread is asking about. I don't recall having seen any requests for any of the curing system status info, but there may have been. @Klendathu, do you have a link to a previous request, or were you also thinking of the affliction info question from the Ask Your Producer thread?

Yes, I was very specifically avoiding asking for actual affliction info, and trying to be clear that only information that is already available to us is included.

Right now, the divide between coders and non-coders is, if anything, widened by the current system. Anyone can learn to work with GMCP in an afternoon and it's largely the same for every client. Learning to write an actual line parser to get the data without GMCP is a much taller order, though still well within the realm of possibility for a competent coder.

As another upside to this idea, if it were sent via GMCP, it would be fairly trivial to add new panels to the default HTML5 display for afflictions, priorities, predictions, etc. So this could even provide non-coders with a pretty significantly easier time in combat.

Ernam

It should be pointed out that GMCP exists to make things easier for people who can't code.  Almost everything that's sent by GMCP can be filtered out via other methods (a core design concept of the GMCP system itself).

The only reason GMCP was added was to make information (like inventory tracking, prompt variables, vial contents, etc) much easier to access.

Still requires basic scripting, but much easier to do, and it should also be mentioned that "systems" that utilize them are generally simple enough to be freely distributed (see: refill scripts, pre-caching scripts, etc).


The same exact reasoning was used for implementing (and later, improving) the in-game show <stuff> command.  Core design concept is to make "trackable" but tricky information more simple to access (and therefore, script).

Jonathin

Ernam said:

The only reason GMCP was added was to make information (like inventory tracking, prompt variables, vial contents, etc) much easier to access.

I just want to correct/add to this because iirc, ATCP and GMCP were created for the web clients and being able to use it with other clients was just a byproduct. 

Ernam

Ernam said:

It should be pointed out that GMCP exists to make things easier for people who can't code.

Jonathin said:

I just want to correct/add to this because iirc, ATCP and GMCP were created for the web clients and being able to use it with other clients was just a byproduct. 

Not to be argumentative, but web clients were designed to make things easier for people who don't want to code, or use client software at all.  Thus, GMCP was added to Achaea to assist people who aren't interested in being coding gurus to get into the game.

The whole point of mentioning it is just to state that I do believe that IRE is trying to (in case it isn't obvious) shift the game away from being a coding-intensive hobby, and make essentially every aspect of the game more accessible to newbies, midbies, etc.  (See: nearly every change in the last 2 years)

Since that seems to be the direction IRE wants to go, I firmly believe that Server Curing needs to be augmented to the point where it doesn't require client-side systems to run it in order to function at even basic levels.

There are a long list of problems with it currently, but the lack of affliction output is probably the biggest and most limiting.  Personally, I still use a highly modified version of SVO purely for affliction tracking.  I recommend the same to virtually every player who asks "What system should I use?".  Fact is, the vast majority of the playerbase still has to pay credits for curing systems, or settle for (IMO) extremely poor free substitutes, even if they choose to use Server Curing.

_____

PS: Big props to @Makarios and @Tecton, as well as everyone else involved in Server Curing.  I always like to include a disclaimer when I bash the current state of Server Curing, because I do truly think it's awesome, and great for the game.  I don't want to come off as ingrateful, because I use it and love it, I just want to see it come to fruition, or would at least like to have a bit more transparency on why certain decisions are/were made.  It seems like it was a firm decision to not allow affliction output, but I think that it has been universally agreed upon that it's necessary and balanced to have it.  Therefore, if there is a good reason other than balance concerns (coding complexity, other projects, or otherwise) I think it's at least fair to state what it is.  We are paying customers, afterall.