API Question AddExhaust odd behavior based on documentation.

[Zatnikitelman]

Tonight, I was working on my first .dll craft and came across an odd problem when using the first implementation of AddExhaust where you don't have to define the exhaust positions and direction:

//From the API Reference

UINT AddExhaust (
THRUSTER_HANDLE th,
double lscale,
double wscale,
SURFHANDLE tex = 0) const

tex texture handle for custom exhaust flames

To use a custom exhaust texture, set tex to a surface handle returned by
oapiRegisterExhaustTexture. If tex == 0, the default texture is used.

For whatever reason, the compiler didn't like it when I did this:

AddExhaust (th_rcs[0], rcsl, rcsw, 0);

So I changed the 0 to 1. (thanks to Hielor, I've since learned not to include that argument when it has an = 0 or whatever) But when I did, the thrusters all appeared to be located about one or so meters along the dir axis from where they were defined. I got rid of the last argument altogether and the thrusters were thrusting at the correct points. I guess this is also a warning to newer programmers [like me] who may not know not to include that last argument.

 

[Hielor]

Tonight, I was working on my first .dll craft and came across an odd problem when using the first implementation of AddExhaust where you don't have to define the exhaust positions and direction:

//From the API Reference

UINT AddExhaust (
THRUSTER_HANDLE th,
double lscale,
double wscale,
SURFHANDLE tex = 0) const

For whatever reason, the compiler didn't like it when I did this:

AddExhaust (th_rcs[0], rcsl, rcsw, 0);

So I changed the 0 to 1. (thanks to Hielor, I've since learned not to include that argument when it has an = 0 or whatever) But when I did, the thrusters all appeared to be located about one or so meters along the dir axis from where they were defined. I got rid of the last argument altogether and the thrusters were thrusting at the correct points. I guess this is also a warning to newer programmers [like me] who may not know not to include that last argument.

What was the compiler error?

 

[Zatnikitelman]

This:

1>.\SSM.cpp(191) : error C2668: 'VESSEL::AddExhaust' : ambiguous call to overloaded function
1>        c:\orbiter\orbiter06\orbiter060929_sdk\orbitersdk\include\VesselAPI.h(278): could be 'UINT VESSEL::AddExhaust(THRUSTER_HANDLE,double,double,double,SURFHANDLE) const'
1>        c:\orbiter\orbiter06\orbiter060929_sdk\orbitersdk\include\VesselAPI.h(277): or       'UINT VESSEL::AddExhaust(THRUSTER_HANDLE,double,double,SURFHANDLE) const'
1>        while trying to match the argument list '(THRUSTER_HANDLE, double, double, int)'

 

[Hielor]

This:

1>.\SSM.cpp(191) : error C2668: 'VESSEL::AddExhaust' : ambiguous call to overloaded function
1>        c:\orbiter\orbiter06\orbiter060929_sdk\orbitersdk\include\VesselAPI.h(278): could be 'UINT VESSEL::AddExhaust(THRUSTER_HANDLE,double,double,double,SURFHANDLE) const'
1>        c:\orbiter\orbiter06\orbiter060929_sdk\orbitersdk\include\VesselAPI.h(277): or       'UINT VESSEL::AddExhaust(THRUSTER_HANDLE,double,double,SURFHANDLE) const'
1>        while trying to match the argument list '(THRUSTER_HANDLE, double, double, int)'

Ah, that basically means that it couldn't decide between two different versions of the function, because "0" could be a double or an int.

 

[tblaxland]

Ah, that basically means that it couldn't decide between two different versions of the function, because "0" could be a double or an int.

Yes, and when you put the "1" in instead of "0" it resolved the ambiguity to the double,double,double signature. As a matter of interest, that version is undocumented but judging by the description of the third double "lofs" it sounds like it is "length offset", which would be consistent with the described behaviour.

 

[Zatnikitelman]

Makes sense to me! It might be useful somewhere, I just don't know how right now.
LOL four days into programming my first .dll and I've already uncovered an undocumented method!