-
You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋
Bug - Parsing issue
- Thread starter woobs
- Start date
It is turned on, but I had your previous test cases in the list of tests that ran and those did not fail. Your other code was the reason I turned off the ability for people to use an escape character and went back to the original find brace code. So, this is a bug that didn't happen before because that test case works.
Can you send me an example that doesn't rely on NetBots that I can use to reproduce the issue?
Can you send me an example that doesn't rely on NetBots that I can use to reproduce the issue?
You could probably substitute "${Me." for "${Netbots[soandso]." (except Me.Cursed is a string whereas Netbots[x].Cursed is an integer). I don't know which part of the code above is causing your parsing issue, so I don't know how I am supposed to find a similar example without NetBots in it.
For the example above, without actually going in-game, I believe:
tBotClient would contain a list of names like..... Player1 Player2 Player3
AQSpellCureType would contain something like..... Poisoned Diseased Cursed
I use the Builder (not VV), so I do not really shake out ModBot when you make these changes. I just see reports from other ModBot users using VV that are suddenly dead in the water (because we can't code around a parser issue). Which also means that a particular player can only find one error at at time. Once one occurs, they are dead. So they can't send a list of all the possible errors that they could encounter in a session.
@Redbot maybe we could get different versions of VV made available while these parsing changes are being tested? A 'backup' version that has the new parser off so that players could switch to it and continue to play while Knightly is fixing issues?
For the example above, without actually going in-game, I believe:
tBotClient would contain a list of names like..... Player1 Player2 Player3
AQSpellCureType would contain something like..... Poisoned Diseased Cursed
I use the Builder (not VV), so I do not really shake out ModBot when you make these changes. I just see reports from other ModBot users using VV that are suddenly dead in the water (because we can't code around a parser issue). Which also means that a particular player can only find one error at at time. Once one occurs, they are dead. So they can't send a list of all the possible errors that they could encounter in a session.
@Redbot maybe we could get different versions of VV made available while these parsing changes are being tested? A 'backup' version that has the new parser off so that players could switch to it and continue to play while Knightly is fixing issues?
It's just that it's very hard for me to find and fix if I can't reproduce it (or even know under what scenarios it happens) and since I don't use NetBots, I was hoping to find a way to reproduce your same issue without having to go through a full Netbots setup. If the issue only happens with Netbots in a particular scenario, it would be good to know what that scenario is so I can track down what's happening.
When you say you can't code around a parser issue -- the other issue you had was easy to code around by putting quotes around the braces. But I fixed that so you don't have to do that because you were able to show me what you were doing and explain what the expected output was. In both of these scenarios, all of the test macros worked, so tracking down these edge cases is important. My preference is, I'd like for everything to be backwards compatible.
When you say you can't code around a parser issue -- the other issue you had was easy to code around by putting quotes around the braces. But I fixed that so you don't have to do that because you were able to show me what you were doing and explain what the expected output was. In both of these scenarios, all of the test macros worked, so tracking down these edge cases is important. My preference is, I'd like for everything to be backwards compatible.
While I am sure you are trying to improve things, breaking things along the way is not good. It should definitely be backwards compatible, unless you are specifically asking macro writers to change something to conform to new/deprecated rules. This is not a NetBots issue, it is a parsing issue, which is why I mentioned the Me TLO as a workaround.
Relying on current macros to find these issues doesn't give me a good feeling. It would be too easy for me to be running OK today, then change my macro and introduce a new 'test case' that you hadn't thought of before. Where it would have naturally worked under the old parser, but confused the new one? Not good for the macro writers that are trying to debug their errors without realizing it is the parser, not the macro.
If there was an option in the builder for me to build with and without the new parser, I would be willing to try out the new parser with my bot army. But I would like to be able to easily roll that back with a rebuild while you are working on fixes.
Relying on current macros to find these issues doesn't give me a good feeling. It would be too easy for me to be running OK today, then change my macro and introduce a new 'test case' that you hadn't thought of before. Where it would have naturally worked under the old parser, but confused the new one? Not good for the macro writers that are trying to debug their errors without realizing it is the parser, not the macro.
If there was an option in the builder for me to build with and without the new parser, I would be willing to try out the new parser with my bot army. But I would like to be able to easily roll that back with a rebuild while you are working on fixes.
I'm still at a point where I don't know what the actual issue you're reporting is, though. Like, what is breaking right now, expected output vs actual output? You're saying it's a parser issue and I get that because your code hasn't changed, but what is the issue?
As for the methodology -- if you have a better suggestion versus testing it against the current set of existing macros, I'm all ears. There's not a way I can think of to test scenarios that macro writers haven't thought of yet though.
As for the methodology -- if you have a better suggestion versus testing it against the current set of existing macros, I'm all ears. There's not a way I can think of to test scenarios that macro writers haven't thought of yet though.
I really can't tell you what the issue is, but I can try to explain the intent...
tBotClient has a list of clients.
Netbots[client].xxx (like Cursed, Diseased, etc) has an integer value.
AQSpellCureType also has a list of items (which would match the xxx in the above NetBots[client].xxx).
So, it is looping through the clients and checking to see if any of their xxx counters (which match the Cure Type list) have a value greater than zero. But it has to be able to build the ${NetBots[].xxx} dynamically based on the CureType list.
/for a 1 to ${AQCount} <-- this is the number of ini entries in the Cure section
.
.
.
/for b 1 to ${tBotCnt} <-- This is the number of clients on NetBots at the moment
.
.
.
/for c 1 to ${Math.Calc[${AQSpellCureType[${a}].Count[ ]}+1]} <-- This is the number of items in the CureType list. For instance "Diseased Cursed Poisoned" would loop 3 times checking each of the NetBots values for them
/if (${NetBots[${tBotClient.Arg[${b}]}].${AQSpellCureType[${a}].Arg[${c}, ]}}) {
/varset tSpellFound TRUE
/break
}
/next c
tBotClient has a list of clients.
Netbots[client].xxx (like Cursed, Diseased, etc) has an integer value.
AQSpellCureType also has a list of items (which would match the xxx in the above NetBots[client].xxx).
So, it is looping through the clients and checking to see if any of their xxx counters (which match the Cure Type list) have a value greater than zero. But it has to be able to build the ${NetBots[].xxx} dynamically based on the CureType list.
/for a 1 to ${AQCount} <-- this is the number of ini entries in the Cure section
.
.
.
/for b 1 to ${tBotCnt} <-- This is the number of clients on NetBots at the moment
.
.
.
/for c 1 to ${Math.Calc[${AQSpellCureType[${a}].Count[ ]}+1]} <-- This is the number of items in the CureType list. For instance "Diseased Cursed Poisoned" would loop 3 times checking each of the NetBots values for them
/if (${NetBots[${tBotClient.Arg[${b}]}].${AQSpellCureType[${a}].Arg[${c}, ]}}) {
/varset tSpellFound TRUE
/break
}
/next c
You could probably create a similar situation with Spawn members.
tBotClient = John Joe Sam
AQSpellCureType[a] = Ducking Feigning
/if (${Spawn[${tBotClient.Arg[${b}]}].${AQSpellCureType[${a}].Arg[${c}, ]}})
Or something like that. Those spawn members are bools, but that shouldn't matter.
tBotClient = John Joe Sam
AQSpellCureType[a] = Ducking Feigning
/if (${Spawn[${tBotClient.Arg[${b}]}].${AQSpellCureType[${a}].Arg[${c}, ]}})
Or something like that. Those spawn members are bools, but that shouldn't matter.
Yes, I thought I could try something like that to reproduce it. If it's a parser issue, it should bomb out in any scenario (because it means the parser couldn't parse what it got). The below is the test case I tried to use to duplicate it.
Unfortunately, this returns everything correctly.
Code:
/echo \arWoobs Test Cases - Round 2 - Even Woobsier
/declare tBotClient string local John Jacob Charname Heimer Schmidt
/declare AQSpellCureType[5] string local null
/declare a int local 1
/declare b int local 3
/declare c int local 1
/varset AQSpellCureType[1] Ducking Feigning
/echo Spawn: ${tBotClient.Arg[${b}]}
/echo AQSpellCureType: ${AQSpellCureType[${a}].Arg[${c}, ]}
/echo Combined: ${Spawn[${tBotClient.Arg[${b}]}].${AQSpellCureType[${a}].Arg[${c}, ]}}
/if (${Spawn[${tBotClient.Arg[${b}]}].${AQSpellCureType[${a}].Arg[${c}, ]}}) {
/echo You are Ducking Crazy
} else {
/echo You are still ducking crazy but you are not Ducking
}Unfortunately, this returns everything correctly.
I'm sorry, but I can't get it to break. I installed NetBots and ran through a lot of different scenarios outside of the test above. I'm hopeful you can give me some more information on what is breaking or what conditions cause it to break so that I can reproduce it.
If you're not able, is there one of your users I can work with directly to try to reproduce it?
If you're not able, is there one of your users I can work with directly to try to reproduce it?
Very Vanilla (no parse) can be downloaded here:
https://www.redguides.com/community/threads/very-vanilla-mq2-live-servers.66784/post-385160
https://www.redguides.com/community/threads/very-vanilla-mq2-live-servers.66784/post-385160
It seems like whatever the issue is, it's in cure routines. Curse, Poison, Aids, it really doesn't matter. I can be in a trivial zone, something casts a debuff on my group they move into the sub cure routine and it shuts down every healer of mine and 2 other people I play with.
I know there was a parser change, and a netbots rewrite in the last update so there was a lot of things that changed and it's not easy to say it's this but I have now tried it on two different clients (Parser / NoParse (*copying .dll files to my folder*) and it still ended my macro once it hit the string. I can confirm this across any class with a cure (I have them all)
I know there was a parser change, and a netbots rewrite in the last update so there was a lot of things that changed and it's not easy to say it's this but I have now tried it on two different clients (Parser / NoParse (*copying .dll files to my folder*) and it still ended my macro once it hit the string. I can confirm this across any class with a cure (I have them all)
we've used three different build dates and the special no parse now.
As soon as a detrimental spell of any kind goes out with counters, it causes the macro to end then I have no healers and you can guess what happens from there.
I'm not sure why it's working for you, and not me though. I have 2 other people and we're all getting the same issue. Like I said above, there were some major changes all around MQ2land last patch so it's hard to put a finger on if it's a parse issue or netbots issue. I just don't understand why it's working for you.
I can turn cures to false and I will never have an issue, but I can't cure 24 dt's manually. I wasn't born with that skillset.
It's possible Redbot posted the wrong screenshot. If you download the version of VeryVanilla that he posted above (the one that says noparse) it doesn't have the parsing changes. The parsing changes are very easy to turn on and off because they're all wrapped in an #ifdef. If you're not familiar with that, it means that if you:
"#define KnightlyParse" prior to compiling then you'll get the parsing changes. If you do not do that then nothing in the parser code changes.
The easiest way to tell if you have the new parsing engine turned on is to echo something with a ${Parse[ in it. The new parser knows how to handle that, while the old parser doesn't.
For example, I downloaded the version that Redbot posted in the VV thread and tried to run:
/echo ${Parse[0,${Me.Name}]} is ${Me.Name}
Under the old parser, this will return:
[MQ2] NULL is Knightly
While under the new parser this will return:
[MQ2] ${Me.Name} is Knightly
In the version that Redbot posted above, it returns NULL so you know for sure that the parsing changes are turned off. (Even though Redbot probably knows because he's the one that flipped the switch, he was giving you a way to prove it).
Last edited:
I do not know, but he will have to confirm. Plus, others that play with him using ModBot are having similar issues since the last release. It seems odd that they all would have modified their .ini with similar errors.
@FriedFryz can you share one of your cure .ini entries that are causing a problem?
@FriedFryz can you share one of your cure .ini entries that are causing a problem?
Assuming he's using the version without my parsing changes, posted above (which can be confirmed with the echo that I showed), and if it's not the issue where it's bad data in, bad data out (via the ini), then the only other thing I know that changed was the NetBots code.
But my money right now is on ini.
But my money right now is on ini.
Last edited:
assholes
Alright, so FriedFryz sent me over a copy of his ini which contains this line:
and I asked that he change it to this and test:
The way that he has it now is because of the wiki here: https://sites.google.com/site/modbot4/#TOC-Cure-Section-AdvCure- which has this to say:
My reading of that is that those are just a list of options, but not necessarily how they should be in the ini. However, I could be reading that wrong. From the modbot code in modcure.inc I see that it is set like this:
The way I read the modbot code further down in that file, it's splitting based on the space so regardless of any parsing functionality, the comma is going to be included. Please correct me if I'm wrong as I don't use modbot personally.
In the meantime, FriedFryz is going to give it a shot. My preference for now is to test it on the version of code that has parsing off since that is a known quantity and if it errors there we know it's not related to the parsing engine.
Code:
SpellCureType=Cursed, Diseased, EnduDrain, LifeDrain, ManaDrain, Blinded, CastingLevel, Charmed, Feared, Healing, Mesmerized, Resistance, Rooted, Silenced, Slowed, Snared, SpellCost, SpellSlowed, SpellDamage, Trigger
Code:
SpellCureType=Cursed Diseased EnduDrain LifeDrain ManaDrain Blinded CastingLevel Charmed Feared Healing Mesmerized Resistance Rooted Silenced Slowed Snared SpellCost SpellSlowed SpellDamage TriggerThe way that he has it now is because of the wiki here: https://sites.google.com/site/modbot4/#TOC-Cure-Section-AdvCure- which has this to say:
My reading of that is that those are just a list of options, but not necessarily how they should be in the ini. However, I could be reading that wrong. From the modbot code in modcure.inc I see that it is set like this:
Code:
/call LoadINIVar AdvCure AQSpellCureType${a} "Cursed Diseased Poisoned Corrupted EnduDrain LifeDrain ManaDrain Blind CastingLevel Charmed Feared Healing Mesmerized Resistance Rooted Silenced Slowed Snared SpellCost SpellSlowed SpellDamage Trigger All" AQSpellCureType[${a}] ${IniFile}The way I read the modbot code further down in that file, it's splitting based on the space so regardless of any parsing functionality, the comma is going to be included. Please correct me if I'm wrong as I don't use modbot personally.
In the meantime, FriedFryz is going to give it a shot. My preference for now is to test it on the version of code that has parsing off since that is a known quantity and if it errors there we know it's not related to the parsing engine.
I can't reproduce the situation where I get different results in the two different parse engines. Using the following test code, I should be able to reproduce a situation where I get what you get:
But, outside of the difference in the parsing test line, the output is the same.
Old Parser:
New Parser:
Note the comma on both results which is what I would expect based on the existing modbotcure.inc file and all of the results we've seen earlier in this thread.
Unless someone can point me in the right direction for "Expected Output" vs "Actual Output" and show me that it's different between the two parsers, I'm sorry to say that I'm going to have to give up on trying to track this down. Everything that I can see looks like the ini shouldn't have commas in it in either the old parser or the new parser (since modbotcure.inc is splitting based on space, the expected result is what I see).
Code:
/echo \arWoobs Test Cases - Round 2 - Even Woobsier
/declare tBotClient string local John Jacob ${Me.Name} Heimer Schmidt
/declare AQSpellCureType[5] string local null
/declare a int local 1
/declare b int local 3
/declare c int local 1
/varset AQSpellCureType[1] Ducking Feigning
/echo Spawn: ${tBotClient.Arg[${b}]}
/echo AQSpellCureType: ${AQSpellCureType[${a}].Arg[${c}, ]}
/echo Combined: ${Spawn[${tBotClient.Arg[${b}]}].${AQSpellCureType[${a}].Arg[${c}, ]}}
/if (${Spawn[${tBotClient.Arg[${b}]}].${AQSpellCureType[${a}].Arg[${c}, ]}}) {
/echo You are Ducking Crazy
} else {
/echo You are still ducking crazy but you are not Ducking
}
/echo \arWoobs Test Cases - Round 3 - The Woobsiest Woob
/echo Confirm which parser we're on: ${Parse[0,${Me.Name}]} (NULL/Me.Name)
/varset AQSpellCureType[1] Ducking, Feigning, Sitting, Standing
/echo This should be "Ducking,": ${AQSpellCureType[${a}].Arg[${c}, ]}
/ini "testmodbot.ini" "MySection" "AQSpellCureType" "Feigning, Ducking, Sitting, Standing"
/varset AQSpellCureType[1] ${Ini["testmodbot.ini","MySection",AQSpellCureType,NOTFOUND]}
/echo This should be "Feigning,": ${AQSpellCureType[${a}].Arg[${c}, ]}But, outside of the difference in the parsing test line, the output is the same.
Old Parser:
New Parser:
Note the comma on both results which is what I would expect based on the existing modbotcure.inc file and all of the results we've seen earlier in this thread.
Unless someone can point me in the right direction for "Expected Output" vs "Actual Output" and show me that it's different between the two parsers, I'm sorry to say that I'm going to have to give up on trying to track this down. Everything that I can see looks like the ini shouldn't have commas in it in either the old parser or the new parser (since modbotcure.inc is splitting based on space, the expected result is what I see).
I think the issue is resolved Knightly. I think something broke an error in some peoples modbot .ini's i'm going to reach out to woobs to clean up the wiki for the cure section to eliminate confusion. I stole the Cursed, Poisoned etc. from someone else's .ini so I'm not the only one that misread that documentation.
Thanks for all the help everyone.
Thanks for all the help everyone.