There are 3 counter effects: Disease counters (effect 35), Poison counters (effect 36) and Curse counters (effect 116) Afflictions are spells that have a duration and a counter effect with a positive value - these end up as detrimental buffs on the afflicted player. Cure spells are instant spells with no duration that have one or more counter effects with a negative value. Spells have 12 effect slots (called affects by original EQ devs). The way the spell 'engine' works is convoluted - each of the 12 slots has an effect, base, formula and max value. These are just integers and there is a big tree of if/else/switch statements that use these numbers and the other fields on the spell record in various ways to create all the unique spells in the game. The general idea with afflictions and cures is that an affliction has some number of counters and a cure removes some number of counters, but the actual workings of this are implemented in the spell engine and don't work out quite that simply. There is a check that looks something like this: Code: [ Only registered users can see the bbcode. Click Here To Register... ] So a strong affliction requires a strong cure, that is within 6 counters of it, or it will not do anything no matter how many times it is cast. This is the thing I recently discovered and implemented (not live on TAKP yet). But there is another subtlety to this - if you look carefully, it's using the same effect_index (one of the 12 slots) to evaluate the affliction as the position of the counter reduction effect in the cure spell. That means that this comparison is done against whatever effect is in that spell slot, and not necessarily the counter value. This appears to be an oversight, but this is how the game worked and why some cures just didn't work on some afflictions even though it seems like they should by the number of counters they have. Sometimes this goes the other way too, and a cure works even though it would be considered too weak otherwise. As an example consider these spells: Shiftless Deeds https://lucy.alkabor.com/spell_186.html Code: [ Only registered users can see the bbcode. Click Here To Register... ] Transon's Elemental Renewal https://lucy.alkabor.com/spell_2896.html Code: [ Only registered users can see the bbcode. Click Here To Register... ] When the cure spell (Transon's) is used to heal a pet with the affliction (Shiftless), the effect_index is pointing to slot 2 (0 based so the value is actually 1 in the code). The affliction spell has an attack speed effect at slot 2, and it's a positive value because of how those values are expressed, and the difference between 10 and the haste effect is more than 6, so it does nothing. If it actually considered the counters, 2 casts would work, but they don't work due to the way the slot numbers align. Word of Replenishment is another spell that fails to cure a lot of things due to the slot placement. I think this was changed around the time of LDoN (just speculating I don't know) when they added new afflictions and cures for trapped chests and things like that but I found that it worked this way all through beta and Al`Kabor at least. Because this is hard to wrap my head around, I wrote a program to test each possible cure spell against each possible affliction and listed out any that don't work due "not being strong enough" which includes this slot alignment issue. Here is the data https://www.takproject.net/solar/affliction_cure.txt You can search for the affliction and if your intended cure spell is listed below it, then it can't be used to cure it either due to being too weak or the effect slots not aligning in a favorable way. For stuff like Radiant Cure, there is an additional detrimental cure effect, and my data only considers the counters. That effect works separately so it doesn't mean that RC is totally useless, just the counter part of it. Notably this changes the behavior of the weak cure spells like Cure Poison, Counteract Poison, Cure Disease and Counteract Disease on some afflictions where they previously worked. Pet heals and Word of Replenishment don't work on shaman/enchanter slows.
I can't say I recall this from live: "So a strong affliction requires a strong cure, that is within 6 counters of it, or it will not do anything no matter how many times it is cast." However, I've played here for so long (and on live for a decade before that, after the changes), that the memory is likely fuzzy.
so you can no longer spam Shield of the Immaculate lots of times to cure disease? Black Plague not curable by potion anymore? all pet heal spells are now useless becausae they can never cure any slow? lolz what a lovely nerf
I'm confused. I would expect cure disease to be listed under basically everything here and it's not. Am I misunderstanding that txt file? For example, Forlorn Deeds: 2 Decrease Attack Speed by 67% (L57) to 70% (L60) 3 Increase Disease Counter by 16 And Cure Disease: 1 Decrease Disease Counter by 1 I would expect Cure Disease listed under Forlorn Deeds in your txt output because its cure counters are more than 6 away from the amount of counters AND because the effect slots don't line up (1 vs 3). Yet it's not there.
Yea it's strange, it compares to the effect in that slot regardless of what's there, and if it happens to be a 0 or negative effect then it ends up working even though it wouldn't if it compared the counters. I checked a ~2008ish client and this logic works differently there, by comparing counter to counter and without the 'strength' limit.
So what's the actual value being compared in forlorn deeds? Since it doesn't have anything at all in slot 1 is it just a "0"? and since 1 - 0 > 6 it removes a counter anyway?
does this mean 1 counter cures will cure 16 counter spells now? and the lvl 39 "Remove Curse" spell will cure everything now because it cures multiple slots and Crusader's Touch potentially cure all curses too? and Radiant Cure will work a lot better because of the slots it cures, and could just cure everything with one cast in mosts cases? So any case of counters misaligned with the cures in spell slots just means 100% cure now? eg, lvl 1 cure disease cures Ancient Breath now because it's slot1 vs slot5
What about those with more counters than are available in cure spells? Are those uncurable now where they were in the past? I have to say, it kinda feels like you're trying to implement a bug that they fixed pretty soon after our timeline.
Kind of, yea. I originally started by listing all the permutations of what cures and doesn't cure each thing, but I realized that what was interesting is to point out only things that don't work. So a Cure Disease spell decrements counts by 1, and people expect that if they cast it 18 times it cures an 18 counter spell. In most cases, that still works, unless the affliction happens to have the positive counters in the first slot (like Black Plague) and in that case the strength comparison rejects it. Stuff like haste/slow is weird because you might think of it as negative, but it's a positive value less than 100 in the data so it counts as 'lots of counters'. So in cases where the counters in the cure and the affliction line up, it works as intended with the strength comparison rejecting weak cures for strong afflictions, but in cases where the affliction has something else in that slot, then it works one way or the other by accident. Edit: to clarify, it would still take 16 casts to cure a 16 counter spell. The items I listed are for the case where the counters are not decremented at all no matter how many times you cast it.
Yes, if it's a 0 or a negative value, then the resulting sum is going to be <= 6 for any cure effect because they're all negative by definition, and that particular slot of the cure wouldn't be blocked from decrementing counters. Each slot is evaluated separately for multi slot cure spells.
How does this line up with the cancel magic counters on that line of spells and AEs like Frost Breath?
They don't interact with each other except that an affliction with counters can't be cured with Cancel Magic in the same way that an affliction without counters can't be cured with Cure Poison/Disease spells.
Huh. This is certainly an interesting surprise. Are there logs that can confirm that cure worked this way in practice as well as in theory?
Are we certain this is how it worked on live and not a trick of the client? My memories could be playing tricks, but I mained a druid for ages on live and I feel reasonably confident that I casted weaker cures multiple times to cure higher counter dots, mostly having to because druids didn't get the big cure abilities. Like some pretty solid memories of using radiant cure to get rid of some counters, and then casting a cure after to completely cure it.
Would hope that this is verified with logs. There has been pretty strong evidence lately of the client being wrong about some behaviors. I never questioned the seemingly intuitive nature of counters and can't remember ever having a need to.
I was skeptical as well, but let me see if I can explain it better and convince you guys. From what I can tell, this is how it worked since the very beginning - I find the same code in a beta client and the eqmac client. I think we just didn't know why the cures sometimes didn't work, but they didn't always work. Let me see if I can break it down better because I did a terrible job explaining it above. The important thing to note here is that it matters which cure spell and which affliction you're trying to cure. Many things can be cured with Cure Poison or Cure Disease even though they have a high counter value. Sometimes it will work, sometimes it will not, but even when it works it's not always for the same reason! The game walks through each effect in a spell when it takes effect. The spell we're evaluating is a cure spell, say Antidote, which has slots 1-4 filled with a Poison Counter -9 effect. When the game hits one of these effects, it finds the first buff that has poison counters that can be cured. It then inspects the buff and compares the value of the effect at that slot with the value of the cure effect (-9 in this example). Let's say that the affliction it's trying to cure is Poisoned Flames. Poisoned Flames https://lucy.alkabor.com/spell_3016.html Code: [ Only registered users can see the bbcode. Click Here To Register... ] The comparisons would look like this: Code: [ Only registered users can see the bbcode. Click Here To Register... ] 3 of the 4 effects end up working, but the first one is blocked because it's not 'strong' enough. So the part about the strength of the spell is speculation on my part. This is me speculating and nothing to do with how it works. I think that the intention was to create different levels of cures to match the different severities of poisons. For example we see these in the spell data: Code: [ Only registered users can see the bbcode. Click Here To Register... ] I don't think it quite materialized, and I think that due to this weird way of comparing the slots causing the limit of 6 counters not to be respected, perhaps even the designers didn't know about it because it cured fine when they tested it. We played the game like this for years though, at least through PoP but I don't yet know when it was changed. In most cases the spells do cure things even when the gap is more than 6 because it's comparing whatever effect is in that slot, not the counters. I believe the intention was to require a stronger cure spell for a stronger affliction, but I don't know that. I found what may indicate that the designers did intend to use this mechanic in the following spells: Black Symbol of Agony https://lucy.alkabor.com/spell_1155.html Deathly Chants https://lucy.alkabor.com/spell_2046.html Curse of Sshraezha https://lucy.alkabor.com/spell_2069.html Typhoon Breath https://lucy.alkabor.com/spell_2391.html Touch of Zebuxoruk https://lucy.alkabor.com/spell_2806.html Itraer Vius Touch https://lucy.alkabor.com/spell_2846.html Feeblemind https://lucy.alkabor.com/spell_2899.html Curse of Rhag`Zadune https://lucy.alkabor.com/spell_2925.html These all have a -6 value in the first slot. Effect 10 is CHA and it's usually used as a blank effect, but with a 0 value. I believe that a designer may have used -6 to make sure that it will always pass the cure check, since any number less than 0 added to -6 is less than 6. The CHA itself does nothing useful in the spell but it does interact with this counter comparison logic. I am just making this up though, and it's just my explanation of why I think it does this, not that I'm trying to sell anybody on the idea of this mechanic. I have an AK log here I got from Torven. A player's pet is afflicted with Togor's Insects. The player casts 4 10 counter cures and is unable to cure their pet. We can see the spell wears off on its own eventually. Code: [ Only registered users can see the bbcode. Click Here To Register... ]
Any chance we can put the brakes on these changes pending further investigation/consideration? Game seems nicely balanced at the moment.
Nothing much to add here other than TAKP's mechanics on both cures and dispels have always felt a bit off to me. I'm rarely one to ask devs to make the game easier, but on this particular issue my gut feeling is that TAKP's cure and dispel mechanics (especially dispels skipping buff icons) are wrong, and wrong in the direction of making things harder for players. But of course all the usual caveats apply. Live and AK were ages ago; memory is fallible; TAKP memories muddle up older EQ memories; etc. These client decompiles are really interesting, but it's worth remembering that the client contains all sorts of weird stuff that didn't actually happen on AK. For more significant changes, even those pulled from client decompiles, I'd want higher standards of corroboration from other sources (AK logs > Live behavior > in-era forum posts > trusted-ish memories). YMMV.
I recall on Babnoxis in Fire using Radiant Cure of any rank would remove the buff from your bar but the server would still think you’re afflicted until enough cure counters were removed. There were plenty of disagreements like this where the server kept ticking but your client showed the buff getting removed.
Hmmm. I find it hard to see what would cure what, and what would not. Will be even harder to remember it. Many things will still work if I understand the explaination above correctly. For example, 5 x Counteract Disease to remove Ancient Breath (Vulak) (because no shaman or beastlord near) Others are annoying, for example Affliction 3060 Mists of Enlightenment can't be cured by the following: 3297 Radiant Cure1 3298 Radiant Cure2 3299 Radiant Cure3but Remove Curse (5 times?) will hopefully still do the trick (because we don't all have RGC). Others are plain weird, for example Affliction 2913 Balance of Zebuxoruk can't be cured by the following: 3297 Radiant Cure1 3298 Radiant Cure2 3299 Radiant Cure3 3681 Aria of Innocenceit has 9 curse counters and even Radiant Cure 1 is supposed to cure 9 counters but will no longer do that because - slots? (I don't understand that one but probably looking at the wrong field in raw spell data)
To me, this seems less like an intended thing and more like a developer creating a workaround for a limitation in the spell data. I don't doubt that the client has this code, but I'm not convinced the server had parity on this issue. As people have mentioned above, there are already known areas where client decompiles are not the gospel truth. March 19, 2002 Patch Notes: Looking at the spell data history for Abolish Poison: To me, this looks like the spell was created one way because of the slot targeting Solar has described. But was changed to the more straightforward approach we remember from live. My guess is that this server code change never made it to our client.
I know that sometimes Sony broke their own stuff, but the core of the spell code is built from the same files and is supposed to be identical between server and client. It has to work that way so they stay in sync as best as they can, but admittedly this is a bad design and failed often for reasons beyond the code being out of sync. I understand the skepticism but consider that this is just like the buff stacking - the counters are like buff timers, a property of each buff slot, and they are computed by both the server and client and they are supposed to match so they can compute the same attributes/stats for the player. For TAKP one of the core features is that it can work with an unmodified client from yesteryear with no eqemu hacker mods or malware. If we can't figure out how something works, we don't just hack the client and make it disappear, it stays broken until the server is improved to work with it (like fatigue and food consumption recently). We don't just make it the way we remember, we are running the same client and it can't be wrong/different because it wasn't modified. It is Sony's code and hasn't changed since we used it on AK. I can't study the old server because it's gone, but I can study the client and try to reverse engineer the server code from it and compare the resulting behavior to see if the game state is the same on both sides. There are lots of things like this where it's some deep down detail and we would never figure it out without seeing the code. I don't have packet logs of people curing buffs, the only logs are of spawn captures and not gameplay, so I work this backwards by studying the client code and trying to understand how it possibly could have worked to put a buff up or remove it. I talked to Torven about this and he found an AK log for me clearly showing the interaction I predicted, that the pet heals can't cure shaman slows, which is why I was excited to share this; I feel confident about it especially after seeing an old log behaving this way. What can I do besides try to match the client behavior? I was able to reverse the food consumption and fatigue logic from studying how the client expects it to behave. I did the same with this and other spell things - the entire process of making eqemu work is writing some code, starting the client and fiddling with it, and seeing what it does until it looks right. When we had the server too, we could capture logs and guess at what the data in them was, but today trying to make an emu without the server I'm left with only studying the client code paths in a compiled binary and working backwards what the data in the packets should be. I don't have access to any source code from Sony but the binary code that runs in the client can be studied and poked at with a debugger, which is what I enjoy doing on this project - looking for treasures like this in a bunch of hex bytes. I think a lot of these details are minor and weren't understood or at least not common knowledge, but this behavior is in Sony's code in our unmodified client. What better source can I use to figure out how the game worked? Regardless of any additional things that happened, making buffs appear and disappear in sync with the server has to work first. Maybe there was some additional code that affected buffs on top of this, that was only present on the server, but all I can do is develop to our old client - I can't divine the old server code into existence for me to study. I remember a thing similar to what Darchon is describing on Aaryonar - the debuff icon would show on the client even if you were around the corner, but you didn't actually get mana drained and you could use your jboots to reset spell gems and thus your mana bar. I think this particular thing was a bug with how they sent their spell/damage packet pairings, and it was an error that caused the client UI to look broken to players which sucked. Producing an intentional error like that is always possible, but we need to understand how to do it correctly first, before we can understand what the mistake was and how to make it happen. That particular situation is code that is only on the server - the AE and LoS stuff for counting who it hit. I wish I could see Sony's code but I can't, so the AE spell logic is just made up and likely missing some unknown details. It's good enough to play the game but I'm sure it's wrong.. recently Darchon found his charm pets casting AEs on players, which I tried to fix, but it's made up code based on what feels right, not what it actually was.
From https://www.takproject.net/solar/affliction_cure.txt: Affliction 507 Togor's Insects can't be cured by the following: [...] 2620 Vigor of Zehkes On Live, Vigor of Zehkes was able to cure Togor's Insects in August 2004: [Mon Aug 23 20:39:07 2004] You begin casting Vigor of Zehkes. [Mon Aug 23 20:39:07 2004] You haven't recovered yet... [Mon Aug 23 20:39:07 2004] You haven't recovered yet... [Mon Aug 23 20:39:07 2004] You haven't recovered yet... [Mon Aug 23 20:39:07 2004] You haven't recovered yet... [Mon Aug 23 20:39:09 2004] Your feet adhere to the ground. [Mon Aug 23 20:39:09 2004] Taunting attacker, Master. [Mon Aug 23 20:39:10 2004] Your feet come free. [Mon Aug 23 20:39:11 2004] You have healed Odla`s warder for 860 points of damage. [Mon Aug 23 20:39:11 2004] Your target has been cured. [Mon Aug 23 20:39:11 2004] Your pet's Togor's Insects spell has worn off.
I found a log and client from 2003 that has the same behavior, so I'm guessing it was changed to work that way around LoY/LDoN. The newer way is more intuitive, but we have the 1998-2002ish classic behavior.
I don't mean to speak for solar, but I believe this is a hobby for all of us. So yes, when we are bored, we look for things to fix. Solar enjoys decompiling the client and looking for things that don't match up, it makes the server more accurate and maybe one day everything will line up and we'll have maybe the closest thing to a complete accurate server to our era out there.
And whether or not it is decided that this fix is beneficial for TAKP (AKkuracy is a high priority but not the only one), it is good to have as much relevant information as possible when making that decision.
So to be clear, if I'm understanding this right... If we look at Epoch (https://lucy.alkabor.com/spell_3767.html) with 36 curse counters in Slot 3, Remove Greater Curse (https://lucy.alkabor.com/spell_2880.html) will have no effect because while it removes 45 curse counters, only 9 of them are in Slot 3, leaving >6 remaining?
