Question Addon development for Orbiter 2009

[agentgonzo]

Now that Orbiter 2009 has reached the release candidate stage, it's probably time to update some of the addons. I've already noticed that there's a new VESSEL3 class and an MFD2 class (that uses a sketchpad class rather than relying on GDI functions). I would assume that it should now be best practise to update the code to (or develop new addons against) these new classes, rather than rely on the old ones.

What other major developments in the SDK have there been that developers should adhere to?

 

[n72.75]

Now that Orbiter 2009 has reached the release candidate stage, it's probably time to update some of the addons. I've already noticed that there's a new VESSEL3 class and an MFD2 class (that uses a sketchpad class rather than relying on GDI functions). I would assume that it should now be best practise to update the code to (or develop new addons against) these new classes, rather than rely on the old ones.

What other major developments in the SDK have there been that developers should adhere to?

Orbiter 2009 Isn't even close to release candidate stage yet, and correct me if I'm wrong, but I think support for older API's is being discontinued compleatly.

 

[Urwumpe]

I would wait and see. Orbiter 2009 is not even out yet, and without it being released, I won't make prophecies for it. It is likely that the old API will be broken to an extend, but that is no problem for add-ons under activate development.

 

[agentgonzo]

Orbiter 2009 Isn't even close to release candidate stage yet, and correct me if I'm wrong, but I think support for older API's is being discontinued compleatly.

Orbiter 2009 is not even out yet,

Um, Release Candidate 0 is out

 

[Urwumpe]

Um, Release Candidate 0 is out

And that means? Exactly nothing. A release candidate is just a better beta version.

 

[agentgonzo]

And that means? Exactly nothing. A release candidate is just a better beta version.

No, " " means exactly nothing, "Release Candidate 0 is out" means that release candidate zero has been released.

Release candidates are also more than "just a better beta". They are a stage in the development which is generally where all the features and interfaces have been finalised and now new features are going to be added. It's a final bug-quashing stage.

 

[Urwumpe]

Release candidates are also more than "just a better beta". They are a stage in the development which is generally where all the features and interfaces have been finalised and now new features are going to be added. It's a final bug-quashing stage.

Yes, but it is still beta stage. It is also not finalized. If bug fixing and interface testing results in critical design problems, you have to fix this in the release candidate stage, before release. You just add no new features along the way, you are past the feature freeze.

That is why you can test release candidates for development of add-ons well, but you can't develop for them in advance. You develop WITH them. You can be prepared for things to come, and have basic stuff solved, but once the final version is out, you start from std::numerical_limits<float>::min().

 

[agentgonzo]

You develop WITH them.

Which is why I'm moving to develop MFDs for orbiter 2009 now (now that RC0 has been released).

If you stand around with your dick in your hands waiting for the final version to be released before you start development, you get caught with your pants down when it is and everyone else releases addons straight away as they were 95% done during the beta/RC stage and it's only final testing and rework to get it working against the gold version.

Anyway, could we get this back on track please? What new major differences should developers be coding against with the new 2009 version?

 

[tblaxland]

Anyway, could we get this back on track please? What new major differences should developers be coding against with the new 2009 version?

IIRC, you are involved with TransX and LaunchMFD. Either or both may be affected by the planetary axis precession model.

There are some new functions related to global mesh management for compatibility with external graphics clients (see new oapiLoadMeshGlobal signature plus new functions oapiSetMaterial and oapiSetMeshProperty).

The docking behaviour has changed, that may affect those that modified the default behaviour (NASSP and SSU, IIRC).

Those, plus the ones mentioned in your OP, are the main ones I can recall atm.

 

[Brycesv1]

would the changed docking behavior affect the docking autopilots of some ships?

 

[Urwumpe]

And if you started developing for RC0, and the development takes until RC5, you are having a long time to enjoy two development lines - one for supporting the old version, one for the next.

Of course, if you have the urge to masturbate for each support request you get for your add-ons, switching to every next release candidate is a good idea...

Honestly: This is Orbiter. Nobody is going to get killed when people have to wait a week until their favorite add-on is ported to the next released stable version.

 

[tblaxland]

Honestly: This is Orbiter. Nobody is going to get killed when people have to wait a week until their favorite add-on is ported to the next released stable version.

Right, so by the same token, nobody (including you) will mind if he does support parallel development lines, or develop exclusively for RCx.

Brycesv1: I have no idea, but I know of one way you can find out...

 

[Urwumpe]

Right, so by the same token, nobody (including you) will mind if he does support parallel development lines, or develop exclusively for RCx.

This is a free world.