Space Shuttle - Development

[MariuszXC]

Ah, in that case disregard. From what you wrote I understod there are two sources of data, being chosen depending on some condition. Obviously I misunderstood.

[TheEagle]

@Thorsten: If it's a Nasal timing issue, why don't you just move it into a property rule / autopilot ???

[Thorsten]

If it's a Nasal timing issue, why don't you just move it into a property rule / autopilot ???

Because while there is conceptually a 1:1 correspondence between both as both are Turing-complete frameworks (I think), in practice some things get really royally messy in property rules - and we do not know whether the timing of property rules is assigned in a deterministic fashion up-front, so it's not even clear that the outcome will be an improvement.

[eatdirt]

Hello there,
with some delays, due to real life things, just wanted to say that I did a few TAL to Morron, insertion orbit to HST, and they went fine, your last pushes seem to have fixed the issues I was having a while ago.

I've found another bug though within the failure scenarios. If I am getting an engine electric lock, and switch to manual throttle transiently to actually cut-off one engine to avoid too much gs, then when I switch back the other engines to AUTO, they seem to not throttle anymore. More dramatically, the electric failed engine never switches off at MECO, and does not even responds to the cut-off switches. I'll try to debug this on my side, but if one of you guys already have a good guess where to look at, please tell me!

cheers,
Chris.

[GinGin]

I did a few TAL to Morron, insertion orbit to HST, and they went fine, your last pushes seem to have fixed the issues I was having a while ago.

Perfect, thanks for the feedback.
No idea for the other issue, I didn't try those scenarios.
I will have a look.

On an other matter, I pushed the last changes I wanted to do for the Ascent Insertion guidance before a Stable Release test phase (Advanced MECO parameters https://forum.flightgear.org/viewtopic.php?f=87&t=40190)

Any feedbacks and bugs are welcomed

[legoboyvdlp]

Keeping my eyes on the rdv windows after the HST disappeared, I did see rare but transient jumps in the estimated distance, by a few hundred of meters. So at last, I have a tail, if these transient jumps are also there in the conditionals of proximity zone, clearly they would be enough to trigger all that mess!

I have something similar - reaching where the ISS should be, I discovered that it was jumping +- a few km, quite rapidly -- with the following being repeated constantly in the console:

Code: Select all

Placing ISS model!
12054.62 [INFO]:nasal      Coordinate differences proximity:
12054.62 [INFO]:nasal      -569.6767997315138 268.3498893050148 -3817.751274108887
12054.62 [INFO]:nasal      ISS alt2 before: 322048.8335177837 prox_z: -3817.751274108887
12054.62 [INFO]:nasal      ISS alt2 aft: 325866.5847918929
12054.90 [INFO]:nasal      Post Burn Loop!
12055.41 [INFO]:nasal      Post Burn Loop!
12055.95 [INFO]:nasal      Post Burn Loop!
12056.01 [INFO]:nasal      ISS explicit simulation ends

[GinGin]

@EatDirt: I pushed a commit with the HUD flight director assigned to the correct parameter for Pitch guidance during TAEM.
Tell me how it goes with manual flight and a joystick, I only tested it with keypad and it went ok.

I did many tests on the current dev; for me it is smooth enough for a stable release.

[eatdirt]

Hi Gingin,
thanks! I did some tests today (with 2020.4). The vertical diamond guidance is back, thanks!

But I do still have problems with the horizontal one, the diamond and the alignment cone do not seems to match for me. This is a series of snapshots, made with perfect navigation, during which I fly CSS while trying to be always on the HAC. Doing so is the only way for me to actually arrive in front of the runway, so the HAC display on SPEC 50 looks good. But as you can see in these pictures, the guidance diamond is always shifted too far towards the inside of the cone.







Of course, if I follow the guidance diamond instead, I am turning too steep and end up in a minimal energy condition, the cone starts to shrink, then I turn more and so on and so forth

This was over KTTS and I started with this only:

Code: Select all

fgfs --fg-aircraft=/home/chris/.Aircraft --aircraft=SpaceShuttle-TAEM --disable-terrasync --airport=KTTS

Then go to SPEC 50 and ITEM+41+1 to set KTTS as the landing site, then a bit of AUTO pilot till Mach 1 and then CSS.

I'll make more tests about that!

Cheers,
Chris.

[TheEagle]

Congrats for hitting 99000 views on this thread !

[GinGin]

@EatDirt: I will check that. I think I need to filter the bank commanded for the roll error like I did for the roll AP channel.

[wlbragg]

I'm trying to identify who, if anyone has pushed any mesh changes to cockpit.ac?

If you have, would you please contact me in a private message.

It appears that the cockpit.ac mesh has possibly lost all the Group assignments which is a real problem if it is the case.

All blend changes, really in all models, should be done in the blends that are located in the resource blends, not by importing cockpit.ac or any of the other .ac files in the development repository.

I'm not as concerned with any of the smaller .ac blends such as HTS or RMS stuff. But cockpit.ac and cockpit-detailed.ac needs to always be generated from the master blends in the resource blends. For one it can be problematic to use newer versions of Blender or even problematic versions of the ac import/export script.

I need to replace cockpit.ac with a new export from the resource blend but I am afraid I might not have any recent mesh additions that might have been added directly to the .ac files. I would rather figure this out beforehand, but it is going to need to be done as we can't have the .ac without the Groups as the master. Hours and hours of work went into the creation of the blend and the organization of the same, it's just to complicated to try to use it without the groups.

[wkitty42]

I'm trying to identify who, if anyone has pushed any mesh changes to cockpit.ac?

git, itself, can/will tell you this...

eg:

Code: Select all

git log --follow -p -- path/to/cockpit.ac | grep -E -e "^(commit|(Author|Date):)"

the above will tell you the commit, who did it, and the date it was done... if you want to see the actual changes, remove the pipe and grep command but be warned, it can be a LOT of output...

FWIW:
in the development branch, since 2020 May 4, your name is the only one i see as having done anything with SpaceShuttle/Models/cockpit.ac going all the way back to 2016 Feb 18...
in the master branch, since 2017 Apr 17, your name is the only one i see as having done anything with SpaceShuttle/Models/cockpit.ac going all the way back to 2016 Feb 18...

[wlbragg]

Thanks, wkitty42, that is a big help. I don't understand why the ac in the development repository is missing the group folders. I checked the production model in addons and it is correct. I didn't think anyone had edited the two "big" ac files, but also can't explain where the groups went. It's possible a bad exporter script crept into my workflow along the way, but I don't know. You established I am ok to use the master to update and add any additions, that's all I really needed to know. Thanks.

[Thorsten]

Technically we're on milestone 13, but same picture here - you're the last comitter, Wayne

[wlbragg]

Thanks for verifying Thorsten. It's a mystery why the groups are not showing up when importing cockpit.ac from the development branch. I'm still using Blender 2.79b in order to keep compatibility and it is working as always with all blends and .ac files except that one file.
Mystery not solved but I think everything is OK so long as no one uses cockpit.ac as a base for making changes.

FYI: for anyone concerned, the actual blend file for cockpit.ac is not cockpit.blend but cockpit-ste5.blend.