So, Macroquest is crashing you?
If you are having problems with random crashes the first step is to get a solid idea of what is causing the crash. This can be frustrating, but simply stating you are randomly crashing won't help resolve the problem. Take some time to figure out exactly what action is crashing you. For example, when I open the in game map I crash every time. If you really can't figure out what is crashing you it may be best for you to attach a debugger and get a dump of the crash.
Once you know what action in game is crashing you, we'll need to figure out now which plugin is causing the problem. To do this follow these steps:
- Locate and backup macroquest.ini in your root macroquest folder.
- Edit the original (not the backup). Find the keys that tell MQ which plugins to load at startup. They will look like MQ2Chatwnd=MQ2Chatwnd or MQ2Chatwnd=1 You want to remove all of those entries.
- Start EQ, Start MQ. Because of your alterations you will only load MQ2Main.dll.
- Once you are in game, do whatever action causes you to crash. If you crash at this point simply come back here and report that mq2main.dll seemed to cause you to crash and we'll probably set you up to debug.
- If you still running start loading up your plugins one at a time by typing "/plugin mq2chatwnd". Between loading each plugin repeat your crash test. We are hoping that eventually you will crash, when this happens make a note of which plugin crashed you.
- Now... edit macroquest.ini again, and ONLY have the plugin that crashed you load. Reload EQ and MQ, and see if you can generate a crash with the 1 singular plugin loaded. This will fairly conclusively prove that it is that one plugin alone that is causing the problems. If you don't crash it may be a combination of that plugin with another.
- report back here with your findings.
Last edited by Maudigan on Thu Nov 14, 2019 7:21 pm; edited 3 times in total
Fri Aug 27, 2010 9:04 am
Project Lead
Crashing to desktop
I am using MQEMU_Classic_SOD.zip. I installed and loaded into X5 Funhouse and everything worked fine for the first hour or so. Then I was going to use #flymode 1 on my ranger, but did #flymode 11 on accident and it crashed my character to the Desktop. and now whenever I try to log him on I am crashed to desktop after character select.
I have loaded it up with no plugins and I can play fine, Loaded them 1 by 1 and I crash when MQ2Melee is loaded. I have tried this 10 times now and it is always MQ2Melee that crashes me to desktop.
I can log other characters in no problem with all plugins running, only this one character crashes to desktop.
Thank you for your help.
I have now tried to load the ranger on a second computer using the same programs, and I get the same error with that character. I can log others on tho with no problems. I removed MQ2Melee from list on second computer and he was able to log in fine.
Thu Feb 03, 2011 1:07 pm
I don't know what #flymode is, i'm assuming its a serverside command to make you fly, but I don't know what the 1, or 11, in this case, does. As you can load MQ2Melee on a normal server or a character that you haven't done this #flymode 11 on it makes me want to assume that it is the problem.
If it really comes down to the #flymode issue, I don't know that there is anything I can do for you. You'd have to contact the servers admins and see if they can reset whatever it is that #flymode changes. Maybe it is zone gravity or something? I'm not sure.
I can only speculate that the #flymode triggers the server to push a particular value to the client. The client parses and stores this value, whatever it is, maybe zone gravity, maybe something with water or feetwet, then MQ2Melee improperly handles this value that is set to a non-standard or unexpected range. Can you not do a "#flymode 1" to reset it?
If it really comes down to the #flymode issue, I don't know that there is anything I can do for you. You'd have to contact the servers admins and see if they can reset whatever it is that #flymode changes. Maybe it is zone gravity or something? I'm not sure.
I can only speculate that the #flymode triggers the server to push a particular value to the client. The client parses and stores this value, whatever it is, maybe zone gravity, maybe something with water or feetwet, then MQ2Melee improperly handles this value that is set to a non-standard or unexpected range. Can you not do a "#flymode 1" to reset it?
Thu Feb 03, 2011 2:45 pm
Project Lead
I see the #flymode command in the default eqemu list, so its a standard command. I'm trying to get the source to come up right now but having trouble with google code. If I see anything tell-tale in there i'll let you know.
Thu Feb 03, 2011 2:50 pm
Project Lead
Crashing
I logged in and reset #flymode to normal without MQ2Melee running. but as soon as I reload MQ2Melee it crashes again.
Thu Feb 03, 2011 3:24 pm
This is the eqemu code for flymode
The first condition will check to see if the data is bad. If it evaluates to a "TRUE" then it aborts the command and sends an error message to the client.
This checks the length of the string, which in the case of '11' would be a 2. So the first part, "strlen(sep->arg[1]) == 1" would evaluate to "FALSE".
The 2nd part, "sep->arg[1][0] == '0' || sep->arg[1][0] == '1' || sep->arg[1][0] == '2'" checks to see if the first character of the string is a 0, 1, or a 2. The first character of 11 is, indeed, a 1. So this part would evaluate to (FALSE || TRUE || FALSE) so with 1st and 2nd part combined we get:
FALSE && !(FALSE || TRUE || FALSE)
then we evaluate the parenthesis
FALSE && !(TRUE)
then we evaluate the NOT, "!"
FALSE && FALSE
then we evaluate the AND, "&&"
FALSE
and that is a bad value. If we put in a "3", which IS actually a string length of 1, but it isnt a 0, 1, or 2, we get this:
TRUE && !(FALSE || FALSE || FALSE)
then evaluate the parent
TRUE && !(FALSE)
then the NOT
TRUE && TRUE
then the AND
TRUE
It is apparent that it is indeed letting through bad values if they have a length longer than 1.
It should look like the following code. This will abort if the string length is NOT 1 long, OR it will abort if the first character is not a 0, 1, or 2. This should handle all bad data.
OR they could use strcmp, probably with a little more overhead.
even still, they could simply cast it as an integer, and then check to see if it is in range. This wastes time casting it as an integer before validation is done, but i'd assume that this doesnt get used frequently, and when it is used people probably use it correctly most of the time.
So it was assuming your flymode of 11 was a good value, when it obviously isnt, then it packs this up into a network packet and pushes it out to the user, maybe even other users standing around.
The atoi() function turns the "string" of "11" into a number 11. The SendAppearancePacket sends a "Levitate" packet with a value of "11" in it. The client probably is only expecting to get a 0,1, or a 2, so jamming this erroneous value in there could cause unexpected behavior, from a crash to nothing. It doesnt seem to be saving the value though so why it would permanently screw your character up is unclear. I'm not super familiar with mq2melee but perhaps it's put some bad data into an INI file. I'd suggest removing that characters mq2melee settings. You might also contact the server admin and let him know he is running some code that has the ability to crash people. Although, I could have misread it.
c++
The first condition will check to see if the data is bad. If it evaluates to a "TRUE" then it aborts the command and sends an error message to the client.
c++
This checks the length of the string, which in the case of '11' would be a 2. So the first part, "strlen(sep->arg[1]) == 1" would evaluate to "FALSE".
The 2nd part, "sep->arg[1][0] == '0' || sep->arg[1][0] == '1' || sep->arg[1][0] == '2'" checks to see if the first character of the string is a 0, 1, or a 2. The first character of 11 is, indeed, a 1. So this part would evaluate to (FALSE || TRUE || FALSE) so with 1st and 2nd part combined we get:
FALSE && !(FALSE || TRUE || FALSE)
then we evaluate the parenthesis
FALSE && !(TRUE)
then we evaluate the NOT, "!"
FALSE && FALSE
then we evaluate the AND, "&&"
FALSE
and that is a bad value. If we put in a "3", which IS actually a string length of 1, but it isnt a 0, 1, or 2, we get this:
TRUE && !(FALSE || FALSE || FALSE)
then evaluate the parent
TRUE && !(FALSE)
then the NOT
TRUE && TRUE
then the AND
TRUE
It is apparent that it is indeed letting through bad values if they have a length longer than 1.
It should look like the following code. This will abort if the string length is NOT 1 long, OR it will abort if the first character is not a 0, 1, or 2. This should handle all bad data.
c++
OR they could use strcmp, probably with a little more overhead.
c++
even still, they could simply cast it as an integer, and then check to see if it is in range. This wastes time casting it as an integer before validation is done, but i'd assume that this doesnt get used frequently, and when it is used people probably use it correctly most of the time.
c++
So it was assuming your flymode of 11 was a good value, when it obviously isnt, then it packs this up into a network packet and pushes it out to the user, maybe even other users standing around.
c++
The atoi() function turns the "string" of "11" into a number 11. The SendAppearancePacket sends a "Levitate" packet with a value of "11" in it. The client probably is only expecting to get a 0,1, or a 2, so jamming this erroneous value in there could cause unexpected behavior, from a crash to nothing. It doesnt seem to be saving the value though so why it would permanently screw your character up is unclear. I'm not super familiar with mq2melee but perhaps it's put some bad data into an INI file. I'd suggest removing that characters mq2melee settings. You might also contact the server admin and let him know he is running some code that has the ability to crash people. Although, I could have misread it.
Last edited by Maudigan on Thu Feb 03, 2011 3:40 pm; edited 1 time in total
Thu Feb 03, 2011 3:31 pm
Project Lead
The other possibility, which is probably less likely, is the that the first crash was simply a client crash, not related to MQ at all, but because the client received this value of 11. That crash could have caused bad data in the mq2melee ini file which is causing the later crashes. Either way the remedy would be to delete your ini settings for that character.
Alternatively, if you aren't attached to anything in your MQ folder, you could simply delete the folder and redownload it and start fresh.
Alternatively, if you aren't attached to anything in your MQ folder, you could simply delete the folder and redownload it and start fresh.
Thu Feb 03, 2011 3:38 pm
Project Lead
I have deleted the old MQ2, and re-downloaded from your site. And I am still crashing when trying to load the ranger into game with a fresh copy of MQ2.
And I have tried loading the character in from 3 different computers now and he Crashes every time when I load MQ2Melee on either computer.
I was wondering if you wanted me to give you acct info so you can try to log the character in to see the crash first hand so you can see what is happening?
If so please Email me at Tenolian65@hotmail.com for info, as I dont want to post it on a public forum, thank you again for your help.
And I have tried loading the character in from 3 different computers now and he Crashes every time when I load MQ2Melee on either computer.
I was wondering if you wanted me to give you acct info so you can try to log the character in to see the crash first hand so you can see what is happening?
If so please Email me at Tenolian65@hotmail.com for info, as I dont want to post it on a public forum, thank you again for your help.
Thu Feb 03, 2011 4:27 pm
I could do that as long as you promise to change you PW afterwards. I can't open my email at work, its mqemulator@gmail.com, or you can send a PM to me.
Thu Feb 03, 2011 4:38 pm
Project Lead
I got a crash dump and traced it to the paladin/sk challenge ability. One of the default evaluations is ${Me.Book[challenge for blahblah]}. It appears as though your spell book is bugged somehow, and when mq2melee tries to parse and see if you have a spell it crashes you because of the bad data. I'm doing a little more looking at it to see if i can figure it out.
If it is ok with you I may move your spells around in the book to see if I can find what exactly is screwed up.
If it is ok with you I may move your spells around in the book to see if I can find what exactly is screwed up.
Thu Feb 03, 2011 7:16 pm
Project Lead
You have 38 pages of spells. Only 6 on the last page. So you have 302 spells.
I ran the following plugin.
it loops through the clients spells book and dumps the spell id for the slot into the debug window. Here is the output
To make sure its right, i randomly looked at a spell in your spell book, page 12, first one. Is spell id 9917, page 11 * 8, plus 1 to get us onto page 12, and then - 1 since the list starts at 0 is 88. If we look at the list, Slot: 88, is indeed spell 9917.
So our output from the plugin is good. If you look at the list though there are some odd values after your last spell, 302.
I ran the following plugin.
c++
it loops through the clients spells book and dumps the spell id for the slot into the debug window. Here is the output
Debug
To make sure its right, i randomly looked at a spell in your spell book, page 12, first one. Is spell id 9917, page 11 * 8, plus 1 to get us onto page 12, and then - 1 since the list starts at 0 is 88. If we look at the list, Slot: 88, is indeed spell 9917.
So our output from the plugin is good. If you look at the list though there are some odd values after your last spell, 302.
Thu Feb 03, 2011 7:42 pm
Project Lead
Ok, I added the code to cause a crash to see which spell is causing MQ to crash. Basically when you do a ${Me.Book[anytext]} it will loop through every spell in your spell book searching for the spell you wanted. Eventually it gets to the bad data and causes EQ to crash. Here is the output now with the crash code added.
So 301 made it through, but 302 crashed, its the first one in that 25000 series of ID numbers. Is that where the custom spells start? It may crash on a different spell for you if you have the spell file, but it was the loading of MQ2Melee, like you said, that caused it for me too. Specifically when MQ2Melee tries to parse:
Those are some default macro values that are hard coded into MQ2Melee. Anyway, I'd suggest logging him back in with your version of the spell file and go through your spell book and make sure you actually have 410 spells showing up. If you have less, then its those "hidden" spells that are probably the culprit. Unless we were crashing for different reasons.
Debug
So 301 made it through, but 302 crashed, its the first one in that 25000 series of ID numbers. Is that where the custom spells start? It may crash on a different spell for you if you have the spell file, but it was the loading of MQ2Melee, like you said, that caused it for me too. Specifically when MQ2Melee tries to parse:
c++
Those are some default macro values that are hard coded into MQ2Melee. Anyway, I'd suggest logging him back in with your version of the spell file and go through your spell book and make sure you actually have 410 spells showing up. If you have less, then its those "hidden" spells that are probably the culprit. Unless we were crashing for different reasons.
Last edited by Maudigan on Thu Feb 03, 2011 8:08 pm; edited 1 time in total
Thu Feb 03, 2011 7:58 pm
Project Lead
ok, sounds like a plan, I have work i need to do now tho, I will check in later and report back tomorrow, thank you again for all your help.
Thu Feb 03, 2011 8:02 pm