General Question Copying changes from one .cpp to another

JMW

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
610
Reaction score
51
Points
43
Location
Happy Wherever
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 funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,537
Reaction score
2,272
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
610
Reaction score
51
Points
43
Location
Happy Wherever
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
Code:
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

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,537
Reaction score
2,272
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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:

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

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
610
Reaction score
51
Points
43
Location
Happy Wherever
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:

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

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,537
Reaction score
2,272
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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%. :cool:

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

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
610
Reaction score
51
Points
43
Location
Happy Wherever
Took a shower and prepared lunch during two of them. Passed both tests with 100%. :cool:

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.
:ROFLMAO::cheers:
 

JMW

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
610
Reaction score
51
Points
43
Location
Happy Wherever
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.
Code:
#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)
Code:
 if (hit > 1 &&hit < 9 )
        {   
              
    SetThrusterLevel ((th_smoke[0]) ,1);
    SetThrusterLevel ((th_smoke[1]) ,1);
    if(hspd > 1) PlayChirp();
        }
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,537
Reaction score
2,272
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Is the sound initialized?
 

JMW

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
610
Reaction score
51
Points
43
Location
Happy Wherever
Is the sound initialized?
Do you mean loaded?
Code:
m_pXRSound->LoadWav(CHIRP,        "XRSound\\JMW-F-35B\\Chirp.wav", XRSound::PlaybackType::BothViewMedium);
And it's in "enum MySounds"
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,537
Reaction score
2,272
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
610
Reaction score
51
Points
43
Location
Happy Wherever
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

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
610
Reaction score
51
Points
43
Location
Happy Wherever
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:
Code:
int EngExtPPit05()
{
    m_pXRSound->PlayWav(ENGEXTP, true, 0.5);
    return 1;
}
to replace
Code:
m_pXRSound->PlayWav(ENGEXTP, true, Ppit - 0.5);
XRSound is a compromise already on ORBITERSOUND 5.0 which was
Code:
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
Code:
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].
Code:
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.
 
Top