Space Shuttle Ultra development thread

[Urwumpe]

So has anyone checked out this yet? Orbiter.log doesn't have any clues to what's causing the CTD.

I have done some differential debugging this afternoon, looking what changed in the code in the last days. I suspect the code which adds the MPM meshes to the visual is not robust, but I can't tell exactly what is wrong currently.

 

[DaveS]

I have done some differential debugging this afternoon, looking what changed in the code in the last days. I suspect the code which adds the MPM meshes to the visual is not robust, but I can't tell exactly what is wrong currently.

Whatever you did now, have fixed the problem! Thank you!

 

[Urwumpe]

Whatever you did now, have fixed the problem! Thank you!

I have not yet fixed anything, my next commit will add the payload system. If it disappeared, it was sure not my work.

 

[DaveS]

I have not yet fixed anything, my next commit will add the payload system. If it disappeared, it was sure not my work.

Hmm, will check the log then. Seems like SiameseCat did a commit earlier this afternoon.

I look forward to the payload system! Have a few items I would like to test!

 

[Urwumpe]

Hmm, will check the log then. Seems like SiameseCat did a commit earlier this afternoon.

I look forward to the payload system! Have a few items I would like to test!

Yeah, you are not the only one. The earlier we have the save game state fixed, the better.

 

[DaveS]

Yeah, you are not the only one. The earlier we have the save game state fixed, the better.

Speaking of that, I reported a similar problem earlier in this thread: http://orbiter-forum.com/showthread.php?t=2898

I tracked it down to these lines:

  SSME1 953.464300 4 0.000000 0.000000 0 0 0 -1.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 0.000000
  SSME2 953.464300 4 0.000000 0.000000 0 0 0 -1.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 0.000000
  SSME3 953.464300 4 0.000000 0.000000 0 0 0 -1.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 0.000000

It seems to be related to GLS' MPS stuff.

 

[Urwumpe]

It seems to be related to GLS' MPS stuff.

Yes, it is. The loading and saving of the MPS should work robust IMHO, even if we currently only use it test wise - Until we have TVC and MPS SOP, it makes no sense replacing the existing working code by the new MPS.

Instead, the MPS should run in parallel for a while until it replaces the existing SSME code completely. Loading and saving is important for debugging.

 

[DaveS]

Yes, it is. The loading and saving of the MPS should work robust IMHO,

Yes it should but it is not as having the lines present causes CTDs and it's a pain to remove the lines every single time you exit the sim.

 

[Urwumpe]

Yes it should but it is not as having the lines present causes CTDs and it's a pain to remove the lines every single time you exit the sim.

Exactly. I want to make the savegame format more similar to NASSP, so these hard to parse lines can be dropped, but as we currently have only few subsystems which save their state, it is not too important.

 

[DaveS]

Exactly. I want to make the savegame format more similar to NASSP, so these hard to parse lines can be dropped, but as we currently have only few subsystems which save their state, it is not too important.

So they're going away for now? It don't see any reason to keep them i they cause CTDs and won't load.

 

[Urwumpe]

So they're going away for now? It don't see any reason to keep them i they cause CTDs and won't load.

I say the format can be kept, but when the loading code for this subsystem crashes, it should be disabled or fixed.

 

[DaveS]

I say the format can be kept, but when the loading code for this subsystem crashes, it should be disabled or fixed.

Yes, done that now and checked in an altered version of BLOCKII.cpp with the saving routine disabled.

 

[SiameseCat]

Hmm, will check the log then. Seems like SiameseCat did a commit earlier this afternoon.

I look forward to the payload system! Have a few items I would like to test!

The commit I did earlier added a scn file entry to include the MPMs. Try adding 'MPM' to one of the SSU scenarios. If it causes a CTD, there's something wrong with the MPM code.

 

[Donamy]

Dennis,

Are you waiting on me to finish all of the panels for the next release, or just some of them ? I still have,O5,O9, O13-17 to do.

 

[DaveS]

The commit I did earlier added a scn file entry to include the MPMs. Try adding 'MPM' to one of the SSU scenarios. If it causes a CTD, there's something wrong with the MPM code.

Confirmed. MPM causes CTDs when added to scenario file.

 

[Urwumpe]

Dennis,

Are you waiting on me to finish all of the panels for the next release, or just some of them ? I still have,O5,O9, O13-17 to do.

I think some many can still be left open for the next release, It is just important that we have enough panels around for connecting the subsystems we have.

O5 and O9 are not too important, but close to the view of the pilots, that's why I would say these should be finished for the next release. O13-O17 become more important when we have a working electrical power subsystem.

 

[GLS]

Speaking of that, I reported a similar problem earlier in this thread: http://orbiter-forum.com/showthread.php?t=2898

I tracked it down to these lines:

  SSME1 953.464300 4 0.000000 0.000000 0 0 0 -1.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 0.000000
  SSME2 953.464300 4 0.000000 0.000000 0 0 0 -1.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 0.000000
  SSME3 953.464300 4 0.000000 0.000000 0 0 0 -1.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 0.000000

It seems to be related to GLS' MPS stuff.

Oooops..... the problem is probably in the SetThrusterLevel call... anyway good move removing the oapiWriteLine call!
I'm still replacing the old valve mess by new shinny command tables (although I'm not that happy with it...) I think late next week I'll be shooting up a new (bug free) version...

Urwumpe, I took a look at the a NASSP .scn file and I have to ask: is the *NASSP format* one line, (just) one parameter???:sorry:
And also about the ET class what do you want in there? Level sensors, press sensors, vlvs, and a prop resource???

 

[Urwumpe]

Urwumpe, I took a look at the a NASSP .scn file and I have to ask: is the *NASSP format* one line, (just) one parameter???:sorry:

Not always, but it structures the save game quite nicely by subsystems, and something along the way would be nice to have.

And also about the ET class what do you want in there? Level sensors, press sensors, vlvs, and a prop resource???

Not really decided yet, as it would be some sort of subsystem container, which we currently don't have. But the logical propellant resource would not become part of it. It not making sense like that, as we can't control the order of the propellant resources in the save game then.

 

[Donamy]

I think some many can still be left open for the next release, It is just important that we have enough panels around for connecting the subsystems we have.

O5 and O9 are not too important, but close to the view of the pilots, that's why I would say these should be finished for the next release. O13-O17 become more important when we have a working electrical power subsystem.

Hope to get a good portion done this weekend.

 

[SiameseCat]

DaveS: Can you try the latest version? The MPM code works fine for me, so I'm not sure what's causing this bug.