GMCP change?

Caelan

Did they change something w GMCP?

Today, out of the blue, my "butning" aff would cure but it wouldn't be picked up by the GMCP. It was easy enough to fix on my side w a quick line setting it back to nil (homegrown system) but it only happened with one mending aff (burning).  Everything else whether it was applying mending to body or other parts, worked fine.

Just seemed very strange to have happen with one aff and made me waste a bunch of mending.

Armali

Yes, they changed handling for stacking affs to make them more accurate or whatever. Burning is a stacking aff.

Caelan

Stupid question followup: how did it change? GMCP picks it up when I get it, but it doesn't trip on the gmvp.Chat.Afflictions.Remove? Why?

Armali

I never bothered updating my system so hell if I know.

Utianima

Caelan said:

Stupid question followup: how did it change? GMCP picks it up when I get it, but it doesn't trip on the gmvp.Chat.Afflictions.Remove? Why?

My best guess it was inconsistent with other cases of stacking afflictions:

---------------

ANNOUNCE NEWS #5167                                     (01/06/2020 at 19:09)  

From   : Makarios, the Meticulous

To     : Everyone

Subject: GMCP afflictions.

-------------------------------------------------------------------------------

In the past, GMCP messages for stacking afflictions have each had their own quirks, and have been

somewhat inconsistent across different scenarios. We've made some changes that should bring them all 

in line, and stackable GMCP afflictions (and non-stackable afflictions) should behave consistently. 

This may affect your clientside scripts and curing systems, so make adjustments accordingly.

Enjoy!

Penned by My hand on the 1st of Ero, in the year 819 AF.

---------------

Archaeon

There's something weird with certain affs

Ammar

gmcp.Char.Afflictions.Add.name (and remove likewise) have changed such that stacking afflictions now show the level. SO for example you might remove burning (3) and gain burning (2).

This is a good thing as you now should not have to set up weird systems to track your stacks.

Caelan

Ammar said:

gmcp.Char.Afflictions.Add.name (and remove likewise) have changed such that stacking afflictions now show the level. SO for example you might remove burning (3) and gain burning (2).

This is a good thing as you now should not have to set up weird systems to track your stacks.

Ah thanks.  I was bashing and didn't catch the gmcp difference.  Now I will have to cbange that but...  easy enough I guess.

Antonius

Ammar said:

gmcp.Char.Afflictions.Add.name (and remove likewise) have changed such that stacking afflictions now show the level. SO for example you might remove burning (3) and gain burning (2).

This is a good thing as you now should not have to set up weird systems to track your stacks.

Stacking afflictions - perhaps not all of them, but at least some of them - have included the level in Add/Remove for years and years. The original problem was that you didn't get any updates when the number of stacks changed; you only received Add when you gained the first stack(s), and you only received Remove when you lost the last stack(s). That changed quite some time ago - I think early last year, possibly in 2018 - in response to a bug report to the current Add/Remove system (i.e. if you went from 3 stacks to 2, you'd get Remove (3) and Add (2)), but it's possible that wasn't consistent across all afflictions that stack (or working properly even for a given affliction).

This may just be because of the way I implemented my own affliction tracking from GMCP data, but I would have much preferred them adding an Update message rather than sending both Remove and Add for different numbers of stacks when things change. That seems a lot more intuitive and would be consistent with the way Items works. Add when you get the first stack(s) (i.e. you've gone from not having the affliction to having it), Remove when you lose the last stack(s) (i.e. you've gone from having the affliction to not having it), Update when the number of stacks changes but you haven't actually gained/lost the affliction.

Caelan

Yeah that makes sense.. I just don't see why it wouldn't trip on the REMOVE. 

My issue is/was:

You get lvl 1 burning and it trips GMCP and it gets cured, but then it doesn't REMOVE and keeps trying to cure it.  

Kog

It says remove "burning (1)", so your system doesn't recognize that "burning" was removed.

Keorin

Antonius said:

Ammar said:

gmcp.Char.Afflictions.Add.name (and remove likewise) have changed such that stacking afflictions now show the level. SO for example you might remove burning (3) and gain burning (2).

This is a good thing as you now should not have to set up weird systems to track your stacks.

Stacking afflictions - perhaps not all of them, but at least some of them - have included the level in Add/Remove for years and years. The original problem was that you didn't get any updates when the number of stacks changed; you only received Add when you gained the first stack(s), and you only received Remove when you lost the last stack(s). That changed quite some time ago - I think early last year, possibly in 2018 - in response to a bug report to the current Add/Remove system (i.e. if you went from 3 stacks to 2, you'd get Remove (3) and Add (2)), but it's possible that wasn't consistent across all afflictions that stack (or working properly even for a given affliction).

It was actually a -lot- weirder than this, in my experience. Different stacking affs (pressure, fractures, humours, burning), all had slightly different rules around them. Some would show the level only on gaining a level, some on losing a level. When I did my own aff tracking, I basically had to write different rules for all of them.

I haven't gotten mine updated to this new system yet, but if they've actually made them all consistent, that would be damned fantastic.

[Deleted User]

Keorin said:

Antonius said:

Ammar said:

gmcp.Char.Afflictions.Add.name (and remove likewise) have changed such that stacking afflictions now show the level. SO for example you might remove burning (3) and gain burning (2).

This is a good thing as you now should not have to set up weird systems to track your stacks.

Stacking afflictions - perhaps not all of them, but at least some of them - have included the level in Add/Remove for years and years. The original problem was that you didn't get any updates when the number of stacks changed; you only received Add when you gained the first stack(s), and you only received Remove when you lost the last stack(s). That changed quite some time ago - I think early last year, possibly in 2018 - in response to a bug report to the current Add/Remove system (i.e. if you went from 3 stacks to 2, you'd get Remove (3) and Add (2)), but it's possible that wasn't consistent across all afflictions that stack (or working properly even for a given affliction).

It was actually a -lot- weirder than this, in my experience. Different stacking affs (pressure, fractures, humours, burning), all had slightly different rules around them. Some would show the level only on gaining a level, some on losing a level. When I did my own aff tracking, I basically had to write different rules for all of them.

I haven't gotten mine updated to this new system yet, but if they've actually made them all consistent, that would be damned fantastic.

I had triggers for all the stacking ones (+ diagnose lines for if they were even hidden), pretty much because they all seemed to follow their own damn rules.

But yes, they are all consistent now with gmcp adding/removing.

Icarius

It's great that they did this change but why does'nt unweavingspirit work this way? Each tick should trigger gmcp.Char.Afflictions.Add with unweavingspirit (x).

[Deleted User]

If it doesn't you should probably bug it.

Archaeon

I have

[Deleted User]

Archaeon said:

I have

4 more times and it might get fixed

Caelan

Another stupid gmcp question...

Is there gmcp for the curing balances. i know bal and eq have them but wasnt sure if I was missing a module that has it.

Also..  if not, why not?

[Deleted User]

Nope. The only game that doesn't have those, either. They always seem hesitant about adding more things to gmcp.

Caelan

@Makarios not to be a pest but, is there any way we can get gmcp on curing balances?  I am sure this has been asked and answered at some point but I don't see it

Iaxus

IIRC the last answer was "That will cause lag issues in large scale battles" which also makes sense why the smaller playerbase games have it. 

Archaeon

As a huge advocate for making your own system with gmcp, I gotta say that tracking cure bals is pretty easy

Caelan

Archaeon said:

As a huge advocate for making your own system with gmcp, I gotta say that tracking cure bals is pretty easy

I have already built my curing system and it does track it.  I was just curious if there was a way to do it with gmcp because I'll be in the hospital for 5 days at a minimum and was considering re-writing some older stuff that I find I don't need as much and updating some of the curing where I could.

Icarius

The curing balance is easy enough to keep track on yourself.

What is a real problem with having your own system IMO is stun.. Unconsciousness has gmcp. But stun does not. Which means unless you want to just ignore it and have your system spam stuff while being stunned you have to change this from triggers which makes illusions a great deal deadlier.. Only if you have your own system rather then using the inbuilt curing system.

Iocun

I always ignored stun and just had the unstun message re-try failed cures. Same for enlightenment. A bit less spam isn't worth risking being caught by illusions or needing anti-illusion tests (even if that, too, is quite simple for stun).

Caelan

Yeah mine does something similar Iocun.

I use a handful of timers to keep everything running smooth. Just figured w gmcp balances I could dump the timers.