Update Multistage2015 Update to OpenOrbiter2024

Can anyone test this scenario?
Tested with the latest .dll, (single booster grp, no complex flight) works perfectly all the way to LEO. Can't confirm payload jettison because I don't have Spacecraft3 installed.
Side note, the booster meshes need swapping, wrong way around.

Edit: Also tried the same .scn with complex on and get a CTD at booster jettison. Actually just after jettison, they do fly away for a second. So it's something being initialised just after sep?
 
Last edited:
Tested with the latest .dll, (single booster grp, no complex flight) works perfectly all the way to LEO. Can't confirm payload jettison because I don't have Spacecraft3 installed.
Side note, the booster meshes need swapping, wrong way around.

Edit: Also tried the same .scn with complex on and get a CTD at booster jettison. Actually just after jettison, they do fly away for a second. So it's something being initialised just after sep?
Yes, I experienced the same thing. There's a problem when removing the thruster groups associated with the boosters and changing the new maximum rocket power value.

This is the line that fails:
SetThrusterMax0(stage[currentStage].th_main_h[i],newMax);

And this is the complete function:

C++:
void Multistage2015::ComplexFlight()
{
    UpdateComplex+=oapiGetSimStep();
    if(UpdateComplex>=1)
    {
        UpdateComplex=0;

        for(int i=0;i<stage[currentStage].nEngines;i++)
        {
            
            double newMax=(stage[currentStage].thrust/stage[currentStage].nEngines)*(1+(stage[currentStage].engine_amp[i]*sin(2*PI/stage[currentStage].freq[i]*MET+stage[currentStage].engine_phase[i])));
            SetThrusterMax0(stage[currentStage].th_main_h[i],newMax);
            /*double test=(1+stage[currentStage].engine_amp[i]*sin(2*PI/60*MET+stage[currentStage].engine_phase[i]));
            sprintf(logbuff,"MET:%.1f engine:%i TEST:%.6f",MET,i,test);
            oapiWriteLog(logbuff);*/
        }
        if(wBoosters)
        {
            for(int j=0;j<booster[currentBooster].N;j++)
            {
                double newMax=booster[currentBooster].thrust*(1+(booster[currentBooster].engine_amp[j]*sin(2*PI/booster[currentBooster].freq[j]*MET+booster[currentBooster].engine_phase[j])));
                SetThrusterMax0(booster[currentBooster].th_booster_h[j],newMax);
            }
        }
    }


    return;
}

https://github.com/MatiasSaibene/Mu...urces/Multistage2015/Multistage2015.cpp#L2673
 
I need to check the parser too...
I found errors in the parser that were causing the boosters to not be counted correctly. Now I'm also adapting it to the C++ STL (again) and reusing some of the previous work because I think that's the mysterious (at least to me, as an inexperienced novice) cause of the booster overflows in ComplexFlight.

I'm confident I can get Multistage working, but what I don't think I'll be able to answer is why it worked perfectly in Orbiter 2016.
 
I'm confident I can get Multistage working, but what I don't think I'll be able to answer is why it worked perfectly in Orbiter 2016.
The why is not so important!;)
Only the initialization of variables seems to be checked more stringent in 2024. If all initializations are done properly, everything works fine.
This is what I thought. I'll take it as a positive "thumbs up" that it's the only major difference causing problems.
Good luck on the bug hunt!:)
 
Note regarding the development of Multistage2015 for OpenOrbiter 2024: My hard drive is nearing failure, and my Windows partition has started to malfunction. Therefore, I'm going to wait for my new SSD to arrive and install Windows and VS Community to resume development.
The shipping system indicates that I should receive the SSD on December 11th or, at the latest, the 16th.

Thank you all for your patience.
 
Maybe if you have some program, like say Hard Disk Sentinel, that won't happen that sudden, and you have some time to back up your data
from the first hand experience :)
 
Maybe if you have some program, like say Hard Disk Sentinel, that won't happen that sudden, and you have some time to back up your data
from the first hand experience :)
It was already showing signs of failure, and Gnome Disk Utility was warning me, but I didn't have the money to buy an SSD.
Anyway, the hard drive was already 8 years old.

Windows and Linux backups are now complete.
 
Note regarding the development of Multistage2015 for OpenOrbiter 2024: My hard drive is nearing failure, and my Windows partition has started to malfunction. Therefore, I'm going to wait for my new SSD to arrive and install Windows and VS Community to resume development.
The shipping system indicates that I should receive the SSD on December 11th or, at the latest, the 16th.

Thank you all for your patience.
Update: I'll be resuming development soon. I've already installed Windows 11 on my new SSD.
 
Okay, the parser is working now... almost. I coded the default values in case there were no values, but I need to tweak how it detects them from the INI file.

Otherwise, the result is this:
Captura de pantalla 2025-12-06 174134.png

images.jpg

The changes have already been uploaded to the repository on GitHub.
 
I kept investigating the code, but I still haven't found the error. And the project is very large.

I'm going to do the following: create a Multistage2026 from scratch, adding functions from the original until I find the error. And while I'm at it, modernize the code a bit to use the C++ STL.

For now, I've already started with the boom module (which handles the explosions) and I came across some if statements that didn't have any code inside; they were just commented out. It seems that Multistage2010 had support for OrbiterSound, but then Fred disabled it when preparing it for Orbiter2016.

C++:
void boom::clbkPostStep(double simt, double simdt, double mjd) {
    //sprintf(oapiDebugString(),"deltat1 %.3f",deltat1);
    //oapiWriteLog("first frame");
    deltat1 += oapiGetSimStep();
    //oapiWriteLog("first frame before play sound");
    if ((deltat1 > 0) && (deltat1 < 2)) {
        //        PlayVesselRadioExclusiveWave3(MyID2,1);
    }
    //oapiWriteLog("first frame before th0");
    SetThrusterLevel(th_h[0], 1);
    //oapiWriteLog("first frame after th0");
    if (deltat1 > 20) {
        oapiDeleteVessel(GetHandle());
    }
    //oapiWriteLog("first frame after if-delete");
}
 
Oh my God! I forgot that again, I have a worse memory than the Commodore 64.
😅 Don't worry, me too...
I'm following your work with great interest. :hailprobe:

I'll soon finish upgrading my Ariane 6 rocket.

I haven't used the [BOOSTERS_ ] (I'm using the [STAGE_ ] ), so when you're done (it's a lot of work for you), I'll have to do another upgrade! ;)
(Normally, Ariane 6 has 2 or 4 boosters.)
 
😅 Don't worry, me too...
I'm following your work with great interest. :hailprobe:

I'll soon finish upgrading my Ariane 6 rocket.

I haven't used the [BOOSTERS_ ] (I'm using the [STAGE_ ] ), so when you're done (it's a lot of work for you), I'll have to do another upgrade! ;)
(Normally, Ariane 6 has 2 or 4 boosters.)
I had an idea to get out of this rut:
Recreate all of Multistage piece by piece, using the C++ STL. That is, create a mini Multistage module with new code that does the same thing as the original, and gradually add all the features. I'm encountering memory corruption in some functions, but I can't find the source.

So now I'll start Multistage2026 with std::array, std::string, and all the modern paraphernalia. Obviously, in a separate repository and also in a separate thread.

->Here you can find the new source code: https://github.com/MatiasSaibene/Multistage2026_for_OpenOrbiter <-
 
Back
Top