The following warnings occurred:
Warning [2] Undefined variable $unreadreports - Line: 66 - File: global.php(961) : eval()'d code PHP 8.0.28 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/global.php(961) : eval()'d code 66 errorHandler->error_callback
/global.php 961 eval
/showthread.php 28 require_once
Warning [2] Undefined property: MyLanguage::$thread_modes - Line: 43 - File: showthread.php(1617) : eval()'d code PHP 8.0.28 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/showthread.php(1617) : eval()'d code 43 errorHandler->error_callback
/showthread.php 1617 eval

Solved & Confirmed 0.8i - Crash directly after starting a new game!
Added to the list of Bugs/Issues & Crashes!
I merged two crash threads together that was both describing a crash at the startup. As these crashes are so hard to separate from each other I think it is better to keep on reporting crashes when starting a new game here.
I did have one crash after starting a new game of Dwelvers, attaching my crash file.

Attached Files
.txt   DwelversCrash115-5-15-17-46-37.txt (Size: 1,2 KB / Downloads: 3)
I have found an issue that could have been the cause to these crashes. One of the threads that loads some of the textures at start up also loads some 3d models, and it shouldn't do that, the reason is that another thread that run parallel to that one does some initialization to make it possible to load 3d models. So if the 3d models are loaded before the second thread initialize the 3d model loading the game will crash.

In most cases the 2: d thread does initialize the 3d model loading before the first thread loads them, but I can imagine that on some computers with less cores this could be the other way around.

I will take my chances on this one and say solved with the next version. If not we will have to open up it again with the new debugger Smile
Do you know if the game crashed or if it froze?
It did crash, I got the Dwelvers closed unexpectedly in the Debugger..
I merged your crash at start up with this thread. Let me know if it comes up again, I got some hints about what was going on with the crash file you sent me, thank you for that Smile

Thanks to your crash file I have located where in the code the crash occurred. To be honest, I don't know why it would crash at that location, but for the safe side I have moved that part of the code to the initiation of the game instead, this makes it a little bit safer.

Solved with the next version!
I had another crash, this time it was about 15 minutes into a Sandbox game. I was selecting areas to dig, I did have some Visual C++ runtime errors but was unable to capture them.

Here's my crash file.

Attached Files
.txt   DwelversCrash115-5-16-0-17-11.txt (Size: 1,17 KB / Downloads: 2)
2nd Crash, Sandbox game and I included a screencap of the Visual C++ runtime error along with the crash file.

[Image: full]

Attached Files
.txt   DwelversCrash115-5-16-1-36-9.txt (Size: 1,17 KB / Downloads: 3)
Yeah, these two are related to this issue:

This applies to if you get a error with a thread that looks like this:

____THREAD X____

This also proves that my debugger is working as it should Tongue
The Assertion StorageBuildingSystem Line 285 in shows the location in the code the game crashes but it don't give me any history. What the debugger does is showing me the path the program has walked in the code before it crashed, which could be even more informative (in some cases) Smile
Solved with the 0.9c version, now it needs confirmation Smile
Who is able to confirm this crash does not appear anymore?
Spec: Win 10, ATI 7800 HD, res: 1280x1024x75. I support The Venus Project & Resource-Based Economy
Wish I could help, but I've never had this issue even after creating quite a few new games.

Forum Jump:

Users browsing this thread: 1 Guest(s)