Debugging Orbiter startup issues
GLS-SSV opened this issue · comments
As some might have noticed, recently new users show up in Orbiter-Forum saying that a clean Orbiter installation doesn't start or crashes, and most times the log contains no info about what is happening. Without solutions, the users understandably give up, which is always bad, but especially so for a small community such as ours.
I think years ago, Orbiter had a small test app to confirm the system and installation were ready.... maybe something like that could be added, or even a (config file only?) parameter could be added to generate biblical levels of logging, or some extra tests, during the startup.
Add me a supporter of this, as I have an issue with my KSC Upgrade Project refusing to load. Gone over the config file several times and can't find anything amiss. Absolutely nothing worthwhile in either D3D9Client or the Orbiter log even with Verbose Output enabled and Debug Level set to 4.
In my mind, Orbiter's logging of fatal errors that result in CTDs is beyond atrocious and it has been pretty much since the beginning. It seems to me that only some things are actually coded to output something in the log file while some things are not for whatever reason. This is a golden chance to rectify this.
Another thread, this one with a positive outcome: https://www.orbiter-forum.com/threads/d3d9-client-not-working-on-widnows-11.41496
Do we have ideas on how to tackle this?
I think we can break the errors into 2 classes: CTD and "this isn't right, but we can continue".
The first class would be "can't read files", "can't get graphics handle", "missing vessel", etc, the errors that prevent the sim from running. These would be imediate CTD and error message window (and if possible, log entry), with some indication of what failed.
The second class would be "missing texture" or "wrong param in some config file", things that just degrade the sim. These would result in immediate log entry, and checking a variable, so that at the end of the sim, a error message window can be shown, so these errors are not missed (I think something like this exists already).
The trick here is: everything that can fail needs to be checked, and logged when in error.
I do feel, and have felt for some while, that error handling is more or less absent in the sim. Writing to the log file seems hit and miss; there are too many occasions where the log has some startup stuff in there and then nothing, having crashed out to the desktop.
What I don't know currently for having not looked at all into it is how feasible it is to hook into every time the simulation is closing, regardless of reason, and check if an error happened, so we can both write to the log and present to the user a message to say "the error happened because of this". Does it make sense to most users if we say "couldn't get graphics handle"? I'm not sure it does.
I once had made a little App, that did some checks. But it is long lost and I didn't keep it or kept te sources (reasons later)
It looked something like this:
I "deployed" it to some co-workers (just 5, but hey) to test it and the result was something like this:
- Many users that run it didn't read the instructions and went strait into "asking at the chat anyway" (Mattermost I believe at that time 😉 )
- Even with the "copy to clipboard" feature added (encapsulated in [CODE]...[/CODE] as list gets looong) almost noone did this without explicitly being asked (at chat)
- Finding and running the tool was another challenge ;)
- If Orbiter was "installed" in "UAC-locked" folder in the first place it wouldn't run & hence no check was possible (grrr)
- Providing a "select Orbiter install Path" might have solved that issue.
So after a few iterations I found it not worth the effort (lots of documentation is needed to give "proper" instructions).
And guessing all the possible mis-configurations is another thing - ask someone to intentionally make a stupid install just to check that, never was popular 😜
Never the less, I totally support the idea and intention!