Author Topic: 2015/11/03 - Blockland r1972  (Read 38961 times)

I was speaking in context of what Pecon said of it being caused by torquescript-sided blocking of player detection.
wha? getFocusDistance() just has the wrong type masks. Fyi, raycasts work on both ends but the torquescript function calls it with the wrong container when called on the client. Of course this is easily fixed by changing a few bytes with olly or any generic hex editor.

I was speaking in context of what Pecon said of it being caused by torquescript-sided blocking of player detection.
My post was only speculation. Seems I was wrong.

Zeblote sent me a picture of what the stack looks like when the game crashes with the pure virtual call error. It seems to occur in octTree::castRay_r, and the call to the only virtual function referenced calls on an item from a big container (seems to be octTree::smServerTree)

Maybe it calls on an object in the tree (with the type being an abstract base class) that hasn't quite initialized yet?

So this is what the runtime R6025 is about?

also now dealing with R6025

Code: [Select]
MasterChief_S117: wow
Sentry: beach?
Got Connect challenge Request from [IP]
Got connect request from [IP]
  net name = Xeidious
AUTHCHECK: Xeidious = internet client -> internet server, regular auth
Auth Init Successfull: Xeidious
CADD: 27277 [IP]
 +- bl_id = 13927
 +- no auto admin
Sentry: wot
Xeidious: uhg
PrinnyLeHero: bikini lmfao
MasterChief_S117: XD
Xeidious: ff
CIA: Back.
DragonoidSlayer: 10/10
Client 27277 disconnected.
Issuing Disconnect packet.
CDROP: 27277 - Xeidious - [IP]
Posting to master server

had ~21 players on at the time, download freezing was also rampant

Yeah, seems to have a higher risk when player count is higher than 18

also now dealing with R6025

had ~21 players on at the time, download freezing was also rampant
This is similar to the console logs I get. It just happened again with only one player in my server. He was loading, he disconnected, and it crashed (without displaying the disconnect message). Last lines of the console are identical in format.

Code: [Select]
Client 27277 disconnected.
Issuing Disconnect packet.
CDROP: 27277 - Xeidious - [IP]
Posting to master server
I'll get right on that as soon as anyone gives me any kind of information to work with whatsoever.
Can you tell us if any of this information is helpful at all? Multiple people have reported the same circumstances for which the error occurs (player loading), and someone even provided a potential lead for the function itself.

I managed to find a server folder I haven't updated yet, it's still on r1967 if anyone wants it to host with for the time being.

Can you tell us if any of this information is helpful at all? Multiple people have reported the same circumstances for which the error occurs (player loading), and someone even provided a potential lead for the function itself.
He can't find the error just by looking at the code, but, someone did find the cause of it. I'll bring it up again.
Zeblote sent me a picture of what the stack looks like when the game crashes with the pure virtual call error. It seems to occur in octTree::castRay_r, and the call to the only virtual function referenced calls on an item from a big container (seems to be octTree::smServerTree)

Maybe it calls on an object in the tree (with the type being an abstract base class) that hasn't quite initialized yet?
I hope this helps Badspot.

It's probably not exclusive to just that spot either. A big chunk of objects with a large amount of pure virtual functions that can be called from anywhere makes a lot of places potentially responsible, but just one location should be enough.

Regardless, it's helpful to report what the stack looks like when you get the error. Open blockland, attach ollydbg, click debug->run to resume execution, and wait for it to happen. Once the error occurs you'll want to navigate to the bottom right window (which is the current state of the stack):



Then right click edit->select all, edit->copy as table, paste into a text file/pastebin and report back here.

The stack is important because it holds a chain of return addresses eventually leading to the culprit function. It's very useful when tracking down exactly what situation caused the crash.

Did anyone try reinstalling their visual C++ redistributable and reproducing the error? visual C++ has a notorious history of breaking for no reason.


Did anyone try reinstalling their visual C++ redistributable and reproducing the error? visual C++ has a notorious history of breaking for no reason.
Blockland uses an ancient C++ redistributable (seems to be associated with VS 2005), installed in the executable's directory, that will overwrite the effects of installing a newer one/reinstalling the same one since windows loads libraries from the executable's directory first before anything in System32.

I can only imagine that would do anything if some dependency required the newer libraries but most are windows libraries and therefor use the standard library that ships with windows (which isn't updated by reinstalling, either)

Anyways, it's pretty much never the redistributable's fault for breaking. Thousands of applications use the C++ standard library and it's almost always the misuse of the API instead of the API itself.

Guys, help, any server i try to connect to, it gives me the "could not verify you BL_ID (key)".
I got the game in Steam.
Please help

Guys, help, any server i try to connect to, it gives me the "could not verify you BL_ID (key)".
I got the game in Steam.
Please help
Please don't cross post like this because you'll get different answers, I already answered you in help