Frogisis
innn spaaaaace...ace...ace...!
- Joined
- Aug 13, 2008
- Messages
- 185
- Reaction score
- 0
- Points
- 31
- Location
- Chicago
- Website
- www.frogisis.com
I'm currently creating a little cartoon UFO to teach myself how to make ships for Orbiter, and after much wailing and gnashing of teeth I'm pretty close to getting it in the simulator, but I've hit a snag that is beyond my ability to figure out and untangle:
Whenever I try to load the scenario with my new ship, I get a CTD if Orbiter tries to render the mesh at all, and when I start in the cockpit, the HUD loads, but it's filled with dollar signs and other funny symbols and doesn't actually work.
I did some checking around before posting, so I'll make a list of relevant details:
-The (Clean install) Orbiter log's only error is the familiar
"Module spacecraft3.dll [API v.050206]
**** WARNING: Mesh not found: .\Meshes\.msh
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
**** WARNING: Mesh not found: .\Meshes\.msh"
-Orbiter Diagnostic shows all OK, except for that Florida surface tile we're all missing.
-I am running Windows XP 32-bit, and I have installed msvcrdt.dll
-I can get the mesh to load by itself when I rename it to, say, Dragonfly.msh and then load a scenario involving that ship.
-But if I take a .ini (and .cfg) file from a ship I know works and simply change the MESHNAME line to the new mesh's regular name, it's CTD-city.
-Nor, of course, does the .ini that I wrote myself work, although I've tried several different times to copy another one and just change the parameters, as well as written one from scratch based on Vinka's manual.
So it seems like something's going wrong with the .ini, in that for whatever reason it just can't call up the mesh, but a .dll can if the mesh is renamed so that it's within that .dll's scope. I tried reinstalling spacecraft3.dll, as well as its two predecessors, and I'd rather not have to go into writing .dlls on my own yet if I can avoid it; firing up a compiler is scary but exciting, like trying to learn to ride a motorcycle. But my modest sense of computer competence depends on my getting this ship to work. Does anybody have any ideas?
-----Post Added-----
Never mind.
I still don't know what was causing the problem, but I've solved it by a kind of "jacob's ladder" of changing the pointers in copies of other people's .ini and .scn files until it finally clicked.
I've completely rewritten them into something new, though, so I'll feel honest enough posting it on orbithangar later tonight once I finish the details on the textures, since none of the original content remains beyond Vinka's code.
As near as I can figure out, it must have something to do with the filename of the mesh, which was just "lumufo", the same as all the other files associated with it. No spaces or funny marks... I don't know what the problem could have been, but it seems to have worked itself out through a little .ini copy/paste work.
Whenever I try to load the scenario with my new ship, I get a CTD if Orbiter tries to render the mesh at all, and when I start in the cockpit, the HUD loads, but it's filled with dollar signs and other funny symbols and doesn't actually work.
I did some checking around before posting, so I'll make a list of relevant details:
-The (Clean install) Orbiter log's only error is the familiar
"Module spacecraft3.dll [API v.050206]
**** WARNING: Mesh not found: .\Meshes\.msh
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
**** WARNING: Mesh not found: .\Meshes\.msh"
-Orbiter Diagnostic shows all OK, except for that Florida surface tile we're all missing.
-I am running Windows XP 32-bit, and I have installed msvcrdt.dll
-I can get the mesh to load by itself when I rename it to, say, Dragonfly.msh and then load a scenario involving that ship.
-But if I take a .ini (and .cfg) file from a ship I know works and simply change the MESHNAME line to the new mesh's regular name, it's CTD-city.
-Nor, of course, does the .ini that I wrote myself work, although I've tried several different times to copy another one and just change the parameters, as well as written one from scratch based on Vinka's manual.
So it seems like something's going wrong with the .ini, in that for whatever reason it just can't call up the mesh, but a .dll can if the mesh is renamed so that it's within that .dll's scope. I tried reinstalling spacecraft3.dll, as well as its two predecessors, and I'd rather not have to go into writing .dlls on my own yet if I can avoid it; firing up a compiler is scary but exciting, like trying to learn to ride a motorcycle. But my modest sense of computer competence depends on my getting this ship to work. Does anybody have any ideas?
-----Post Added-----
Never mind.
I still don't know what was causing the problem, but I've solved it by a kind of "jacob's ladder" of changing the pointers in copies of other people's .ini and .scn files until it finally clicked.
I've completely rewritten them into something new, though, so I'll feel honest enough posting it on orbithangar later tonight once I finish the details on the textures, since none of the original content remains beyond Vinka's code.
As near as I can figure out, it must have something to do with the filename of the mesh, which was just "lumufo", the same as all the other files associated with it. No spaces or funny marks... I don't know what the problem could have been, but it seems to have worked itself out through a little .ini copy/paste work.
