Orbiter 2016 - RC.3

[martins]

Please try out the third release candidate. (Let's hope there won't be too many more )

It's available as ZIP package (MSI to follow):

• http://mirror.orbiter-radio.co.uk/orbiter/assets/packages/Orbiter_RC/Orbiter2016.zip

This supersedes the RC.2 package. For package details see the RC.1 description which still applies.

For change log see the SVN r.60 announcement.

 

[martins]

And another thing, looks like the MAKEGROUPARRAY points for attachments aren't being updated in the first time step. This is reproducible with Atlantis by grappling something, exiting, and on a new run the attached object will be in the position it would be if the arm was stowed (and the arm is correctly in the saved position). (Starting the sim paused shows the issue better.)

The problem is that the animations (including the MAKEGROUPARRAY points) are updated by the visual, _after_ the logical vessel positions have been set. I fixed that in the default Atlantis code by calling SetAttachmentParams in clbkVisualCreated, to refresh the position after the animation has been initialised.

 

[GLS]

The problem is that the animations (including the MAKEGROUPARRAY points) are updated by the visual, _after_ the logical vessel positions have been set. I fixed that in the default Atlantis code by calling SetAttachmentParams in clbkVisualCreated, to refresh the position after the animation has been initialised.

So, just to finish this, that is the way to do it?

 

[jarmonik]

I am getting a CTD when using the AutoBurn feature of the IMFD. The CTD seems to occur exactly in the same place in Orbiter.exe as the previously reported CTD related to "rotation instability" if I recall correctly, which was addressed in RC2 but there could be still a problem.

The CTD occurs immediately when the AutoBurn starts it's attitude sequence. It's still the same code that's been running with 2010-P1 without problems and compiled with the Orbiter 2016 RC2 API. The CTD seems to occur only with D3D9 and the inline engine shows very strange behavior.

IMFD is downloadable from here:
http://www.orbiter-forum.com/showthread.php?t=37290

The sequence to produce the CTD in "DG Mk4 in Orbit" scenario is:

1.) Open "Interplanetary"
2.) Press "MNU", "Orbit-Eject", "PG", "AB"
3.) Increase time acceleration to wait 3000s seconds. (Reduced automatically)

The CTD occur at T-180 where the attitude sequence is supposed to start. With 100% reliability at-least here.

EDIT1: Debugger shows no third-party code in the call stack.
EDIT2: The CTD is exactly the same as this one. http://www.orbiter-forum.com/showthread.php?p=537701&postcount=66
EDIT3: I wonder, could this be a "large address aware" problem ?:hmm:

 

[Face]

I have noticed that texpack now has the extraction feature. However, it seems like there is a small typo, because the usage page lists '-x' as option, when in reality it is '-e'. In addition, the '-L<x>' option seems to have no effect on it.

My treeman utility also gained the extraction feature now: View attachment treeman.zip
It uses zlib's (1.2.8 statically linked) uncompress() function. However, treeman is twice as fast as texpack unpacking all Earth textures. Do you do some special checks on the unpacked files?

 

[dbeachy1]

Thanks for RC.3! Quick question -- would it be possible for you to package up an RC.3 download version without any planetary textures included? That way users already running with the high-res textures or who already downloaded the low-res textures previously wouldn't need to unnecessarily re-download the low-res textures again (it would also save a ton of bandwidth for both the server and the user). Also, users already using the high-res textures wouldn't need to worry about accidentally overwriting their installed high-res textures when upgrading to RC.3 or future Orbiter 2016 versions or patches.

One possible approach would be to package up three zip files:
1. The Orbiter core files themselves, which includes everything except the planetary textures,
2. The low-res planetary textures, and
3. The high-res planetary textures.

That way users would choose at download time which planetary textures they wanted to use. Granted, that isn't as simple as just doing a single download, but OTOH we could always also have a download that includes both #1 and #2 (as it is now), in which case there would be a total of four.

Anyway, just thinking out loud.

 

[Jordan]

Here is the RC2 to RC3 Patch.
Copy and overwrite these files in your RC2 folder.

OBSOLETE
FILES REMOVED

 

[Ripley]

Differential patches (made with 7-zip):
RC1 --> RC3
RC2 --> RC3

 

[martins]

So, just to finish this, that is the way to do it?

That's kind of strong wording - I would amend that to the slightly more pragmatic "that is the way that seems to be working for now". Given Orbiter's recent release history, it will take me at least a couple of years to break it again.

 

[GLS]

That's kind of strong wording - I would amend that to the slightly more pragmatic "that is the way that seems to be working for now". Given Orbiter's recent release history, it will take me at least a couple of years to break it again.

OK, thanks!
Any words on this? (ignore the first part of that post)
Should we only play with DefSetStateEx in the clbkPreStep call?

 

[martins]

I am getting a CTD when using the AutoBurn feature of the IMFD. The CTD seems to occur exactly in the same place in Orbiter.exe as the previously reported CTD related to "rotation instability" if I recall correctly, which was addressed in RC2 but there could be still a problem.

The CTD occurs immediately when the AutoBurn starts it's attitude sequence. It's still the same code that's been running with 2010-P1 without problems and compiled with the Orbiter 2016 RC2 API. The CTD seems to occur only with D3D9 and the inline engine shows very strange behavior.

IMFD is downloadable from here:
http://www.orbiter-forum.com/showthread.php?t=37290

The sequence to produce the CTD in "DG Mk4 in Orbit" scenario is:

1.) Open "Interplanetary"
2.) Press "MNU", "Orbit-Eject", "PG", "AB"
3.) Increase time acceleration to wait 3000s seconds. (Reduced automatically)

The CTD occur at T-180 where the attitude sequence is supposed to start. With 100% reliability at-least here.

EDIT1: Debugger shows no third-party code in the call stack.
EDIT2: The CTD is exactly the same as this one. http://www.orbiter-forum.com/showthread.php?p=537701&postcount=66
EDIT3: I wonder, could this be a "large address aware" problem ?:hmm:

I've started debugging this, and have traced it back to calls from AttitudeControl.dll to VESSEL::IncThrusterLevel_SingleStep. At about T-180, IncThrusterLevel_SingleStep starts getting called with -1.#IND and 1.#QNAN for the second parameter (dlevel) for some of the thrusters, causing Orbiter to panic and die. These values could of course be generated in response to some earlier problem in Orbiter that gets handed over to AttitudeControl, but until I know what that is, I'm stuck. So for the time being I'll have to hand the debugging-baton back to you ...

 

[jarmonik]

I've started debugging this, and have traced it back to calls from AttitudeControl.dll to VESSEL::IncThrusterLevel_SingleStep. At about T-180, IncThrusterLevel_SingleStep starts getting called with -1.#IND and 1.#QNAN for the second parameter (dlevel) for some of the thrusters, causing Orbiter to panic and die. These values could of course be generated in response to some earlier problem in Orbiter that gets handed over to AttitudeControl, but until I know what that is, I'm stuck. So for the time being I'll have to hand the debugging-baton back to you ...

Thanks about checking that. After doing a lot of debugging over night I finally found the problem from my own code.:facepalm: I am sorry I bothered you with this issue. We can close this one.

I am not sure if it would be good idea to add some parameter validity checks like assert(_finite(x)!=0); in same key places to throw an error when jumping in NAN space. But anyway, those checks are now added in AttitideControl.dll to check the input parameter passed to the Orbiter.

 

[martins]

I am not sure if it would be good idea to add some parameter validity checks like assert(_finite(x)!=0); in same key places to throw an error when jumping in NAN space.

I guess it would improve robustness to check all inputs (valid handles, index ranges, parameter ranges, etc.) but it could potentially also add a fair amount of overhead and thus impact performance.

I was thinking of generating a "debug and test" build that performs all those tests at the API interface, separate from the "production" executable. Users could run this to analyse problems, and addon developers can run their dll's against for testing.

Anyway, it will take me a bit of time to implement that, so it's a project for after the next release.

 

[Urwumpe]

I guess it would improve robustness to check all inputs (valid handles, index ranges, parameter ranges, etc.) but it could potentially also add a fair amount of overhead and thus impact performance.

I was thinking of generating a "debug and test" build that performs all those tests at the API interface, separate from the "production" executable. Users could run this to analyse problems, and addon developers can run their dll's against for testing.

Anyway, it will take me a bit of time to implement that, so it's a project for after the next release.

Sounds like a good idea, at least something like a parameter check and sequence check that is optionally activated.

But yeah, another version, I already have a hard time testing all the new features in 2016 :lol:

Maybe, instead of doing a big leap like 2016, there could be a smaller stabilization release as next one.

 

[Enjo]

How about using such template:

#ifndef SAFENUMBER_H
#define SAFENUMBER_H

class IHasNumber
{
public:
    virtual double GetNumber() const = 0;
};

template<class T>
class SafeNumber : public IHasNumber
{
    public:
        SafeNumber(T val = 0);
        virtual ~SafeNumber();

        SafeNumber operator / (const IHasNumber & other) const;
        void operator /= (const IHasNumber & other);
        std::ostream & Write(std::ostream &os) const;
        double GetNumber() const override { return val; }

        T val; /// Use any other mathematical function

    protected:

    private:
};

template<class T>
std::ostream &operator<<(std::ostream &os, SafeNumber<T> const &m) {
   return m.Write(os);
}

template<class T>
SafeNumber<T>::SafeNumber(T val) : val(val){}
template<class T>
SafeNumber<T>::~SafeNumber(){}

template<class T>
SafeNumber<T> SafeNumber<T>::operator / (const IHasNumber & other) const
{
    if (other.GetNumber() == 0)
        throw std::runtime_error("Divison by 0");
    return SafeNumber(val / other.GetNumber());
}

template<class T>
void SafeNumber<T>::operator /= (const IHasNumber & other)
{
    *this = *this / other;
}

template<class T>
std::ostream& SafeNumber<T>::Write(std::ostream& os) const
{
    return os << val;
}

#endif // SAFENUMBER_H

Example calling sequence:

#include <iostream>
#include "SafeNumber.hpp"

using namespace std;

int main()
{
    const SafeNumber<float> nom(5), denom(10), zero(0);
    SafeNumber<float> nonconst(100);
    const SafeNumber<int> integer(2);
    cout << "Res div = " << nom / denom << endl;
    cout << "Res mul = " << nom.val * denom.val << endl;
    cout << "Res int = " << nom / integer << endl;
    nonconst /= denom;
    cout << "Res non const = " << nonconst << endl;
    cout << "Res zero = " << nom / zero << endl;
    nonconst /= zero;
}

Naturally, you'd have to provide a few try / catch scopes to make it work, but when I think about it, wouldn't it be about time for that? (I'm also talking about the next release, but let's start early please)

 

[martins]

I have noticed that texpack now has the extraction feature. However, it seems like there is a small typo, because the usage page lists '-x' as option, when in reality it is '-e'. In addition, the '-L<x>' option seems to have no effect on it.

Thanks, I'll fix that.

My treeman utility also gained the extraction feature now: View attachment 14694
It uses zlib's (1.2.8 statically linked) uncompress() function. However, treeman is twice as fast as texpack unpacking all Earth textures. Do you do some special checks on the unpacked files?

Not really. I am using the inflate() function. Is that in any way different to uncompress()? Do you set any particular flags when configuring the decompression stream? Maybe yours is using multiple cores and mine isn't, or something of that sort.

 

[martins]

How about using such template:
[...]

Ok, this is worth thinking about. My concern is however that this is quite a low-level approach, that catches problems at the last possible moment, just before an operation that would generate a nan. This would provide a good debugging start for me, but may not be much help for an addon developer who wants to find out why his dll is crashing Orbiter. I still think that parameter checks at the API function entry points would be useful in that respect.

 

[Enjo]

My idea only partly addresses the NaN issues, and only if somebody cares about them. Think about it as an addition.
Parameters checking in API functions would definitely add much more. I have no data to confirm it, but I'd bet that most of the crashes result from trying to call functions which return NULL pointers. Maybe you could be returning references (or pointers like now) only if the objects exist and throwing exceptions otherwise? The parameter validity check would have to be checked via functions returning bool like -
bool HasVessel(const char * vesselName) const;
Only if true is returned, it would be safe (without throwing) to call:
VESSEL GetVessel(const char * vesselName);

I addressed this in this rant, but then I insisted on references. Now I'd say that it doesn't matter that much, as long as the above calling sequence is kept.

Of course, the exceptions would have to be caught in above the oapi::MFD2::Update() and printed in the MFD, similarly in oapi::Module refresh methods, but then you'd have to print them on screen somewhere.

 

[Face]

Not really. I am using the inflate() function. Is that in any way different to uncompress()? Do you set any particular flags when configuring the decompression stream? Maybe yours is using multiple cores and mine isn't, or something of that sort.

I think inflate() uses streams, whereas uncompress(dest, &destlen, src, srclen) uses memory directly. treeman directly loads, uncompresses and saves with a 512kB buffer.

I use the CreateFile() API to open the tree with the sequential read flag, but the fopen() API for writing to the disk. Perhaps this makes a difference? I don't use threading, forking or any concurrency framework at all.

One more thing: I've compiled the static zlib myself, but without any special setting.

Did you try it? Perhaps it is only faster on my machine? :shrug:

BTW, some thoughts about that time-stamping we discussed earlier: what about putting another list at the end of the archive, holding file-modified-time (64-bit) and a sha1 20-byte hash for each file, with the same order as non-dummy nodes.
This way your loader shouldn't have a problem with it, and management tools can easily extract the information by jumping over the archive and running down the linear node list.
It would cost a second file open and 32 bytes per node (e.g. high-res Mars Surf would grow by approx. 1MB = 0.03% ), but that is a small price to pay for advanced diffing between archive and tree (or another archive). In addition, this info can later be stripped off again pretty quickly.

 

[Enjo]

Just a side note for completeness sake:
I've made it possible to mix types of the SafeNumber template.