General Question Copying changes from one .cpp to another

[JMW]

Hi All,
I have two .cpp files.
One is for a 2016 Release addon, and another for Open Orbiter (diff. being one uses OrbiterSound 5.0, the other XRSound)
I want to automatically copy any changes I make (apart from sound related of course) from one to the other (at least one way).
Any help how I can set this up please?

 

[Urwumpe]

Not really, not the way you want. You could solve this by architecture and/or preprocessor statements.

For example, move the source code for sound behind an interface and into separate source files, so that everything behind that interface doesn't affect your common source code. And then use different build configurations for Orbiter 2016 and OpenOrbiter.

In one, you use the include directories and source files for OrbiterSound, in the other the include directories and source files for XRSound.

 

[JMW]

Not really, not the way you want. You could solve this by architecture and/or preprocessor statements.

For example, move the source code for sound behind an interface and into separate source files, so that everything behind that interface doesn't affect your common source code. And then use different build configurations for Orbiter 2016 and OpenOrbiter.

In one, you use the include directories and source files for OrbiterSound, in the other the include directories and source files for XRSound.

Thank you Urwumpe for prompt reply.
If I've got it correctly you mean that the include (and lib. directories?) are segregated, but the "source files"?
If the calls/functions of the .cpp relating to XRSound have to be separated out, and vica-versa, I can't see how I can do that because they're so tied to the rest of the code.
eg: basically

if( canopy < 0.0 ) {
                canopy = 0.0;
                m_pXRSound->StopWav(LANDEDWIND);//SoundOptionOnOff(MySoundID,PLAYWINDCOCKPITOPEN,FALSE);
                m_pXRSound->SetDefaultSoundEnabled(XRSound::AirConditioning, true);//SoundOptionOnOff(MySoundID,PLAYCABINAIRCONDITIONING,TRUE);
    //           
                animactive11 = 0;
                                
            }

Or am I missing your point?

 

[Urwumpe]

A bit, sorry, I am currently forced to pass some trainings at work and have to listen to boring videos to finish them, instead of just letting me shortcut to the test questions at once. Maybe I was a bit hard to understand.

what I mean is: You group the sources into three folders : common, OpenOrbiter and Orbiter2016. OpenOrbiter build and 2016 build share the common folder with everything common to the releases.

In common, you don't comment out the lines for each version, but instead create an abstract function, that is implemented in the 2016 or OpenOrbiter folder sources and that does not refer external dependencies at all in your common source code.

For example in your example code:

if( canopy < 0.0 ) {
    canopy = 0.0;
    disableLandedWindSound();
    enableAirConditioningSound();   
    animactive11 = 0;
}

And these disable... enable functions are then implemented in the specific source files for 2016 or OpenOrbiter. Also, as you see, your common module is suddenly much easier to read without having to know XRSound or OrbiterSound.

 

[JMW]

A bit, sorry, I am currently forced to pass some trainings at work and have to listen to boring videos to finish them, instead of just letting me shortcut to the test questions at once. Maybe I was a bit hard to understand.

what I mean is: You group the sources into three folders : common, OpenOrbiter and Orbiter2016. OpenOrbiter build and 2016 build share the common folder with everything common to the releases.

In common, you don't comment out the lines for each version, but instead create an abstract function, that is implemented in the 2016 or OpenOrbiter folder sources and that does not refer external dependencies at all in your common source code.

For example in your example code:

if( canopy < 0.0 ) {
    canopy = 0.0;
    disableLandedWindSound();
    enableAirConditioningSound();  
    animactive11 = 0;
}

And these disable... enable functions are then implemented in the specific source files for 2016 or OpenOrbiter. Also, as you see, your common module is suddenly much easier to read without having to know XRSound or OrbiterSound.

Thankee!
I think I've got it.............
I'll give it a go, see what mess I can get into, n report back.
Thanks again for your patience.
Don't drop off in the videos

 

[Urwumpe]

Thankee!
I think I've got it.............
I'll give it a go, see what mess I can get into, n report back.
Thanks again for your patience.
Don't drop off in the videos

Took a shower and prepared lunch during two of them. Passed both tests with 100%.

Its about all Agile Development, I do that for 9 years now, am certified Scrum Master (PSM-I) and Product Owner (PSPO-I) and the only people who don't believe this are some corporate bureaucrats some 1000 km away.

 

[JMW]

Took a shower and prepared lunch during two of them. Passed both tests with 100%.

Its about all Agile Development, I do that for 9 years now, am certified Scrum Master (PSM-I) and Product Owner (PSPO-I) and the only people who don't believe this are some corporate bureaucrats some 1000 km away.

 

[JMW]

Thankee!
I think I've got it.............
I'll give it a go, see what mess I can get into, n report back.
Thanks again for your patience.
Don't drop off in the videos

Hmm, as predicted I'm obviously doing something wrong.
When compiled as shown, Orbiter ctd on actuating the sound..........
Haven't tried it in 2016 yet.

"Sound Code" file, compiled with module source.

#include "XRSound.h"
class XRSound* m_pXRSound;

enum MySounds
{
    SystemReset, // value 0
    WARNING,    //value 1
    WARNING1,
    WARN,
    WARN2,
    BEEP,
    GEAR,
    BRAKE,
    BRAKESQUEAL,
    CANOPY,
    CHIRP,
    COVER,
    AFTER,
    AFTER_INT,
    RAM,
    RAMI,
    RAMCAST,
    RAMCASTOFF,
    SONIC,
    LAND,
    LANDEDWIND,
    MainEngines,
    ENG,
    M_ENGEXT,
    ENGINT,
    ENGEXT,
    ENGEXTP,
    ENGSTART,
    ENGSTOP,
    //SomeOtherSound,

};

bool PlayChirp()
{
    m_pXRSound->PlayWav(CHIRP, false, 1);
    return 1;
}

Source code (works fine with standard code)

 if (hit > 1 &&hit < 9 )
        {   
              
    SetThrusterLevel ((th_smoke[0]) ,1);
    SetThrusterLevel ((th_smoke[1]) ,1);
    if(hspd > 1) PlayChirp();
        }

 

[Urwumpe]

Is the sound initialized?

 

[JMW]

Is the sound initialized?

Do you mean loaded?

m_pXRSound->LoadWav(CHIRP,        "XRSound\\JMW-F-35B\\Chirp.wav", XRSound::PlaybackType::BothViewMedium);

And it's in "enum MySounds"

 

[Urwumpe]

Well, thats is the first that I would check on a CTD: Uninitialized variables. For example, can PlayChirp() access a different variable named m_pXRSound or is that variable containing garbage? Also, I am not 100% sure there, but I think in your case, m_pXRSound must be declared static.

 

[JMW]

Thanks for reply.
Can't find any uninitialised variables.
Not sure how PlayChirp could access other m_pXRSound variables...
Isn't m_pXRSound created static ?
(excuse me if I'm talking rubbish. Knowledge pretty limited)

 

[JMW]

Thanks for reply.
Can't find any uninitialised variables.
Not sure how PlayChirp could access other m_pXRSound variables...
Isn't m_pXRSound created static ?
(excuse me if I'm talking rubbish. Knowledge pretty limited)

Hiya,
Urwumpe, thanks for the nice idea -
Suddenly everything linked
So, I've been creating functions/calls for 2 days now, but there are brick walls I can't scale.....
eg:

int EngExtPPit05()
{
    m_pXRSound->PlayWav(ENGEXTP, true, 0.5);
    return 1;
}

to replace

m_pXRSound->PlayWav(ENGEXTP, true, Ppit - 0.5);

XRSound is a compromise already on ORBITERSOUND 5.0 which was

PlayVesselWave(MySoundID,ENGEXTP,LOOP,190,prop_pitch - 800);

That gave an increase in pitch based on throttle levels.
I know we can simulate this by

m_pXRSound->SetPlaybackSpeed(ENGEXTP, Ppit);

but it doesn't give the same effect.

Anyway, the problem is I can't transpose this into a function cos it doesn't recognise Ppit from the source code.
If I try to reproduce the formula for Ppit in the specific" Open Orb" file it doesn't recognise the GetThrusterLevel function, let alone thg_main[0].

double Ppit = ((GetThrusterLevel(thg_main[0]) * 2));

even though I #include "VesselAPI.h" in that file,
So I'm going down a line that's going to end up reproducing the whole source file again.
Am I missing something here cos of my limited coding skills?

Not only is it blowing my tiny mind to transpose all this info, it's really defeating the whole point of the exercise which was to save work transfering every change made in OO version to 2016 version or vica-versa.
Does anyone know of a "linking process" that would alleviate all of this?

I really do miss OrbiterSound 5.0, the doppler effect (so realistic), "surround sound" through attenation (cone effect), and superb flexibility to code to immersive sound.

DanSteph, if you're alive and well, it would be wonderful if you could update 5.0 to work with OpenOrbiter.
Or better still, release the code so it could be adapted as OO progresses.

Thanks to all, and hope there is a work around for this in the interim.