Getting this message in an apparently infinite loop (can’t spacebar past it), interspersed with the occasional
DEBUG: Tried to access invalid map position at grid (1,0,14890784)
This happened a short while previously, though that was an electric SUV rather than a car. I closed the game instance (since I can’t escape) and loaded my previous save, and was able to explore for a while before it happened again.
Version: eea756f
My fault, but fix is already waiting for merge.
Cool. Let me know when it merges?
I keep running in to this one as well. Looks like there is an inconsistency between the vehicle map cache and the actual list of objects when vehicles are created and destroyed especially when wrecks are created. This sort of looks like the changes made in March but I don’t see any pull requests that might fix it. Is this reasonable assumption? Or were you just referring to the zlevel part of the problem which seems to have been merged recently?
I fixed it, at least partially.
In the new versions, you’d get different messages. First you’d get one about a vehicle out of range and then the message would have less crazy coordinates (the third coordinate would be no less than -10 and no more than 10).
If it still happens, I’ll need some more details to reproduce it and then fix it.
To reproduce, I just created a new world with no mods. Create a PrecinctZ scenario with swat (so I’m in the city with armor). Its not 100% reproducible in the first city but eventually it will happen during map generation somewhere. Sometimes I don’t even get out of character generation as it is trying to resolve wrecks. Basically because it cannot properly find and destroy a car the wreck resolution keeps running repeatedly forever. If you do get through map gen then just run around the city blocks so that maps are created and its during dynamic road generation that it breaks. I was testing with code from SHA1 87093bf0ea982c4f92a5c4af0da28fedac3786bc which was yesterday about this time.
I get something like the below log which goes on until I kill the process. The zlevel is zero so its not exactly the same problem I guess but it does go on forever. I do have some customizations mostly around allocating tinymap on the heap rather than stack and some workarounds for compiling under VS 2015 and the mapsize constants so line numbers won’t align. I don’t believe either introduce substantive changes that would cause this problem. If I workaround the problem by returning a true/false if destroy works and then aborting then it will occasionally fail in some other way that I’ve been trying to track down (effectively vehicle_list becomes corrupt with deleted vehicles).
The code looks like it is trying to do the right thing generally so the problem is not obvious but if it does run into problems then it cannot recover due to the recursive nature of add_vehicle_to_map. At best it looks like some sort of cache/list mismatch. I’ll let you know if I find something. I’ll tested with the experimental builds and couldn’t reproduce so I suppose its possible that its compiler related.
13:17:57.499 ERROR : ..\src\map.cpp:6899 Tried to access invalid map position at grid (8,10,0)
13:17:57.500 ERROR : ..\src\map.cpp:333 destroy_vehicle can't find it! name=Mobile Meth Lab, submap:8,10,0
13:17:57.519 ERROR : ..\src\map.cpp:6899 Tried to access invalid map position at grid (8,10,0)
13:17:57.519 ERROR : ..\src\map.cpp:333 destroy_vehicle can't find it! name=Mobile Meth Lab, submap:8,10,0Edit: I rolled back my changes except the ones needed to actually compile and it still happens. The problem seems to be related to vehicles spanning multiple submaps. When the x or y position is near 12 which is SEEX,SEEY and the vehicle is rotated then parts the car can span multiple submaps. The MethLab above is a large vehicle so its easier for it to span. So I suspect that there is some submap mapping mismatch or something going one.
Edit 2: Well guess it was one of my changes after all that i missed in rolling back which led to reuse of an already initialized value in the map. Sorry if you spent any time investigating.
You could PR some of your changes if they’re useful or provide a speed advantage.
A great deal of code isn’t properly optimized and this may need to change relatively soon (3D field of vision will not be cheap).
Seconding the PR suggestion.