• iter != m_ghostMap.end() Client Crash on Rev 53

Posted: **Fri Jan 11, 2008 1:52 pm**

I have spawned the Queen's Island, with some floaters and dupes due to grabbing the same NPC on different runs. Going off Odin's post that he cannot move 20' without crashing, he is right. I used to be able to run around with the zones spawned a few (20) revs or so ago, but I just got back from holiday and compiled 53 and tossed it up. This is the first m_ghostMap.end() I've seen in a while.
The World screen was spawning NPCs as I approached them, if that's any clue where this is happening. Not sure if it's my data, because I am 99.9% confident this does NOT happen in empty (unspawned) zones.

Code: Select all

Adding Spawn To Player, Spawn ID: 6450
Adding Spawn To Player, Spawn ID: 6457
Adding Spawn To Player, Spawn ID: 6458
Adding Spawn To Player, Spawn ID: 6459
Adding Spawn To Player, Spawn ID: 6703
Adding Spawn To Player, Spawn ID: 6708
Adding Spawn To Player, Spawn ID: 6742
OP_MapFogDataUpdateMsg Received 0x0172
   0: 01 00 00 00 00 11 00 74 - 75 74 6F 72 69 61 6C 5F  | .......tutorial_
  16: 69 73 6C 61 6E 64 30 32 - 00 00 A5 C3 00 80 92 C3  | island02........
  32: 00 00 3E 43 00 00 9B 43 - 2E 36 16 78 DA FB FF 7F  | ..>C...C.6.x....
  48: A8 83 F7 10 EA 31 84 FA - 43 17 3B F9 01 BD 3A 34  | .....1..C.;...:4
  64: BA 00                                              | ..
Adding Spawn To Player, Spawn ID: 6702
Adding Spawn To Player, Spawn ID: 6706
Timeout up!, state=0
Client disconnected in Client::Process
Removing client from ip:192.168.1.1 port:4593
Timeout up!, state=2
Removing connection

Posted: **Fri Jan 11, 2008 3:30 pm**

I tried to login to your server but I was unable to login so that I could grab a packetlog. From the packetlog I did get, it looks like your opcodes are outdated. Your codes might be outdated as well.

Posted: **Fri Jan 25, 2008 8:07 pm**

Hmm. I usually update the structs files with the source (Common hasn't changed since 12/7/2007, World (now) is 1/25/2008). Right now, it's source code as of today. I'll try it again, but feel free to drop in

Posted: **Fri Jan 25, 2008 8:20 pm**

You still have problems? I took care of quite a few spawn update errors in the past week.

Posted: **Fri Jan 25, 2008 8:55 pm**

Actually, I just figured out all sorts of crap. Mostly, when I am away from the project for weeks at a time, I need to really review the changes made.

Apparently, LoginServer.ini has new stuff in it. Hehe! Now that it knows the update server port, things are getting updated properly.
Also, I didn't even notice the new EXE build dir was no longer Source/Build, so I my update script was copying over a 1/3/2008 World.exe ~DOH~
I have replaced the spawns on the Queen's Island, and seem to be moving around fine right now at normal speeds. I'll add more spawns in other zones once this looks ok again. I think it's good all along, sorry for my short-sightedness.

Posted: **Sat Jan 26, 2008 9:15 am**

I won't start a new thread, but stick here for now.
LE, if you got time, can you again attempt to login to my server, head to qey_village01 after running around a bit in tutorial_island02, and see if you encounter any JIT debuggers? This time there was no little popup telling me there was an error somewhere, just that Everquest2.exe crashed - and VS2005 wanted to debug it. :/
Also, one more thing (possibly) about proximity and speed - I know you once said that if you /speed 100, the proximity code might not work. Well you are right. I ran towards some previously visible NPCs at 100, they were not there. I turned speed back to 0, started moving and got another crash (I'll reproduce it to get the exact error). So there still might be something there to address with /speed vs proximity(?).
-J
PS: Rev 60, 1/25/08 structs
PPS: I don't think the zones matter to make this happen - those are the two I used. I have most of the Qeynos data loaded up for testing atm.

Posted: **Sat Jan 26, 2008 12:57 pm**

Yah sure, I'll take a look in just a bit.

Posted: **Sat Jan 26, 2008 1:48 pm**

I couldnt get a crash, but I did see all the rats everywhere. geez

I also noticed that your spawns dont have the correct location_id set in your spawns table (which is why you can't click them). I fixed a few of them, like Lakosha Maera I fixed her location id, her difficulty, and her attackable status. Now she should be like live (and you can click her!).

I'll keep trying to get a crash.

Posted: **Sat Jan 26, 2008 2:01 pm**

I did find a problem with it when it was sending delete spawn packets. Give me a few and I'll upload a new version for you to try. Be sure to update your structs when you get it.

Posted: **Sat Jan 26, 2008 3:28 pm**

kk, can you grab the latest now and let me know when it is up and running? Be sure to update you structs too.
As you mentioned earlier, running at twice the normal speed causes issues with spawns not spawning until you are right on top of them. The issue is that we don't send new spawns to the client unless they are within 80 'feet' of the client and we only check every 5 seconds. When running at twice the normal speed, you are traveling that entire distance in 5 seconds. We could increase the distance at which spawns are sent (which increases the network traffic considerably for small zones) or we could decrease the time it checks if the player is within range (this would cause a lot of unnecessary processing because every spawn in the zone would have to be checked to see if they are within range). Either way changing it to accommodate people that are running at twice the normal speed is going to cause problems. Either processing power or network traffic. That is why use /speed 100 is not recommended.

Posted: **Mon Jan 28, 2008 9:29 am**

I would agree /speed 100 is not the norm, but since it's likely just an Admin or GM that would move that fast, is it possible to dynamically change the proximity spawner to take note of the players speed and adjust accordingly? Even if it costs CPU or bandwidth, it should be just the one player running that fast that causes it.
Not sure how spawns appearing for my fast moving toon would effect others not moving so fast tho.
I am updating TessEQ2 now. As for my "rat problem", that goes back to the original collects, that apparently everytime I came near the rat if it had moved, I captured it again. Same goes for any wandering NPC I "revisited".
Lastly, location ID... where is that in the collected data? I'll repopulate my tables with this ID once I find it.

Posted: **Mon Jan 28, 2008 4:04 pm**

grid id

Posted: **Tue Jan 29, 2008 9:51 pm**

Got it, and all my data has a location_id now. Updated my Raw-to-Live PHP scripts, so soon as I get some more raw data, weee!
Thanks for your patience.

Posted: **Wed Feb 06, 2008 4:13 pm**

LE, if you got time, can you again attempt to login to my server, head to qey_village01 after running around a bit in tutorial_island02, and see if you encounter any JIT debuggers? This time there was no little popup telling me there was an error somewhere, just that Everquest2.exe crashed - and VS2005 wanted to debug it. :/

I hate to bring this up again (no I don't hee hee hee!) but I just had the same crash mentioned in this thread again - now on my Linux server, running the latest SVN (64? 65?)
I popped into Queen's Island where I have been tooling around for days without incident, ran from Ebik towards Mannus, and boom - crashed the client. World is fine, as usual.
No valuable exception information, just the JIT to debug the client - which of course, I cannot do. Seems to happen relatively repeatedly if I run between the 2 sets of Qeynos Guardians on the Mannus side of the banker. Just happened a 3rd time as I was writing this.
Pretty sure this didn't happen on the windows exe, but I can try that if you do not have time to witness this yourself.

Posted: **Wed Feb 06, 2008 5:18 pm**

NM trying to get on my server with this problem. It was so bad, I went back a few revs and to Windows.

I'll try again after my work is done... at least i know it's reproducable.