SSU V1.25 Release

[DaveS]

BTW, does this mean we're dumping the use of the WING_NAME parameter?

 

[Urwumpe]

Would be nice to have the right insignia, also. NASA worm and no black OMS tiles, for STS-1 as an example.

Can be done, just give me the texture. The same code which can be used for swapping the ET texture can also be used for replacing the Shuttle hull texture.

Theoretically, we could also replace the wing names by textures, but this would IMHO be inflexible for alternate history missions.


-----Post Added-----

BTW, does this mean we're dumping the use of the WING_NAME parameter?

We could already dump it IMHO, as I think we should use the vessel name instead.

 

[Donamy]

Is Marg7 still around ? He had all the historic textures, AFAIR.

 

[DaveS]

Is Marg7 still around ? He had all the historic textures, AFAIR.

Well, lately xmariox has been working on some upgrades: [ame="http://www.orbithangar.com/searchid.php?ID=3742"]Shuttle Fleet textures[/ame]

Most upgrades were initially done for SSU which were the later transplanted to the Shuttle Fleet.

 

[Urwumpe]

Well, if you just give me the textures, I can give you a hard coded solution to swap them according to vessel name and date, later we could also allow overriding this in the mission file.

Will test the ET code in some seconds.
EDIT: OK, testing code which worked on another add-on with the ET does not work, but ends with an error condition by oapiSetTexture... need to investigate tomorrow.

 

[SiameseCat]

Orbiter freezes during launch. As far as I can tell, the freeze happens just as teh roll program is about to be initiated.

The launch works fine for me, including the roll. Doesn't freeze at any point.

 

[DaveS]

The launch works fine for me, including the roll. Doesn't freeze at any point.

Weired. Both Donamy and I experience the freeze(he experiences it just a second or two after lift-off).

 

[SiameseCat]

Just tried it again, and I still can't reproduce the bug. What scenario are you using?

 

[Donamy]

RSLS test

 

[SiameseCat]

Tried that scenario, and it still works fine.

 

[DaveS]

Well, it's there even if you don't experience it. I'll check if AP off makes any difference.


-----Post Added-----


OK, having the AP off made a difference until I started the roll program. That was a recipe for insta-freeze! As soon as a steering command is given, Orbiter freezes on the spot.

So I would recommend that you remove the PID controller from the ascent part and put back whatever you used before. I have a hunch that this is the source of the insta-freezes. If the freezes are gone when the PID controller is, I guess you need to take a closer look on it to see if there's anything, anything at all that could cause a freeze of the sim when a steering command is given.

 

[Urwumpe]

So I would recommend that you remove the PID controller from the ascent part and put back whatever you used before. I have a hunch that this is the source of the insta-freezes. If the freezes are gone when the PID controller is, I guess you need to take a closer look on it to see if there's anything, anything at all that could cause a freeze of the sim when a steering command is given.

PID-T1 controllers usually don't have any loops or mathematical constructs which can cause it to lock-up. I can do a review of the code, but I expect no surprises there.

I suspect more, something triggers a formerly hidden bug at another location.

 

[DaveS]

Any review of code would be appriciated.

 

[Urwumpe]

Any review of code would be appriciated.

Found a small "bug", which could be related to the problem. It is a sequence of code, which behaves different as it should be intended, but I can't be sure what the intended behavior is.

Heading=atan2(wingHorizon.x,wingHorizon.z)+PI/2;
while(Heading < 0)
     Heading += 2 * PI;

The Heading value is always bigger than 0 (atan2 goes from -π to +π, so Heading will be +π to +3π), if the code was intended to have the heading between 0 and 2π, this will fail this way, and could cause problems in later calculations, which assume a range from 0 to 2π.

Also, I have terribly low FPS again, we had been far better once.

For the navigation and the roll program, would it maybe be better for us, to have an accurate simulation of the IMUs ready before we release 1.25? I notice that we have many repetitions of navigation calculations inside the autopilot codes. Even if we simulated 4 IMUs, this could be better.

 

[SiameseCat]

DaveS, what are your framerates like? Mine are fairly low during launch, so I'm wondering if high framerates are causing problems. I've checked in code with the gimballing completely turned off; see if that fixes the freezing.
I don't think there's anything in the PID controller that could cause a freeze. Also, the gimballing code is active from launch, even if there are no steering commands issued.


-----Post Added-----

Found a small "bug", which could be related to the problem. It is a sequence of code, which behaves different as it should be intended, but I can't be sure what the intended behavior is.

Heading=atan2(wingHorizon.x,wingHorizon.z)+PI/2;
while(Heading < 0)
     Heading += 2 * PI;

The Heading value is always bigger than 0 (atan2 goes from -π to +π, so Heading will be +π to +3π), if the code was intended to have the heading between 0 and 2π, this will fail this way, and could cause problems in later calculations, which assume a range from 0 to 2π.

Also, I have terribly low FPS again, we had been far better once.

For the navigation and the roll program, would it maybe be better for us, to have an accurate simulation of the IMUs ready before we release 1.25? I notice that we have many repetitions of navigation calculations inside the autopilot codes. Even if we simulated 4 IMUs, this could be better.

As far as I can tell, the code snippet above works fine; the heading is only incremented if the value is less than 0, so it should be in the range of 0 to 2π. I'm also getting low framerates, although I'm not sure why this is.

 

[Urwumpe]

I have 17-19 fps, which I consider fairly low, and I also have the freeze at the initiation of the roll program. I think I am close, I have some strange suspicions about us feeding garbage into Orbiters functions.

Does somebody know how to produce a special ASSERT macro/function which writes failed assertions into Orbiter.log?


-----Post Added-----

As far as I can tell, the code snippet above works fine; the heading is only incremented if the value is less than 0, so it should be in the range of 0 to 2π. I'm also getting low framerates, although I'm not sure why this is.

No, it is already PI to 3*PI after the first line, the while loop condition is always false.


-----Post Added-----


Also: NormZ can fail if you input a vector with x² + y² > 1.

This will very likely cause trouble as I am not sure the PID controllers do always return small x and y values.

 

[SiameseCat]

No, it is already PI to 3*PI after the first line, the while loop condition is always false.

It's adding PI/2, not PI*2; after the first line, it should be -PI/2 to 3*PI/2.


-----Post Added-----

Also: NormZ can fail if you input a vector with x² + y² > 1.

This will very likely cause trouble as I am not sure the PID controllers do always return small x and y values.

In this case at least, they should return small values; the values returned represent changes in the x and y components of the thrust vector. If x² + y² > 1, something is really wrong.

 

[DaveS]

I've checked in code with the gimballing completely turned off; see if that fixes the freezing.

Fixes the freeze.

 

[Donamy]

No gimbaling ?

 

[SiameseCat]

DaveS: Try it now. The PID code is running now, but the code that actually gimbals the engines is still disabled.