SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[STS]

...
I just check what could be the start into adding mission control functions to SSU.

With optional disabling please, as I have human controllers...


After dinner I´ll post my thoughts about the tickets I saw this afternoon. Many could be closed...

---------- Post added at 10:49 PM ---------- Previous post was at 09:21 PM ----------

Tickets than can be closed:
#170 PLB bay 13 holes/covers

#141 Centaur piping holes in PLB in are transparent in D3D9

#20 Stack is too low at SRB sep

#79 Incorrect Flight Controller Power switch configuration on panels F6 and F8



Tickets to assign milestone:
#201 Middeck improvements

Could we move this to 5.1 or leave it as is until we decide where to put it? (Not for 5.0). Also, one question: Why a dialog window to fold the seats? I think that they can be folded/unfolded if you just click on them.


#205 Add video camera displays

#206 Mesh changes to eliminate flight deck window issues (Assign to 5.1)
#34 Pre-launch aerosurface check (I think this one is urgent, as it´s there since 2014... Assign to 5.0?)
#115 Background visible thru side hatch window (Assign to 5.3)
#99 Panel A8 doesn't work under certain conditions (Assign to 5.1)


Tickets to update (what is the story on them?):
[Bug] #192 OMS burn target Ha/Hp changing evry 20/30 seconds

[Dev][Research] #120 Update ODS docking port interface
[Dev] #166 Propellant resource allocation

[Dev] #167 TV ROLL parameter implementation
[Dev] #174 ODS sleeves

[Dev] #189 PLB radiator supply hoses not animated (Move to 5.3)
[Issue] #186 ET rotates during ascent with angled attachment point

[Issue] #184 ODS guide plates (Move to 5.3)
[Issue] #158 OMS burn state not saved
#74 Edwards lakebed runways

[Issue] #182 HUD not fully visible (Move to 5.1)

 

[Urwumpe]

Could we move this to 5.1 or leave it as is until we decide where to put it? (Not for 5.0). Also, one question: Why a dialog window to fold the seats? I think that they can be folded/unfolded if you just click on them.

I am not even sure if it makes sense to let the player control this at all. How much player workload do we really want during the already pretty full post-insertion checklist?



I would even go so far to assume, that the player is always the commander of the mission (with all the priviledges) and all other crew members are AI.


Of course - a cooperative multiplayer option could also be nice. But terribly much work to implement with a small dev team.

 

[STS]

I am not even sure if it makes sense to let the player control this at all. How much player workload do we really want during the already pretty full post-insertion checklist?



I would even go so far to assume, that the player is always the commander of the mission (with all the priviledges) and all other crew members are AI.


Of course - a cooperative multiplayer option could also be nice. But terribly much work to implement with a small dev team.

Yeah I agree...


So we leave #201 as is until we can attack it on the future.

 

[Urwumpe]

Yeah I agree...


So we leave #201 as is until we can attack it on the future.

I think so, yes. It wouldn't be terribly much work to implement, but we have terribly much C++ work to do already.



Also, maybe we have more ideas regarding the middeck soon, then it might make sense to cluster the tickets into one epic and put the epic on the roadmap.



Also, I think it might be a good idea to "cheat" some OTC communication into SSU during the countdown to tell the player, when the final 9 minute count will begin and which part of the launch checklist can now be executed. Right now, it looks like we can only see the L-time in the LCC vessel by LCC MFD, we essentially have to guess the time by looking at the GMT.

 

[jarmonik]

There is a small problem with the "Absolute animations", they are not fully backwards compatible with the incremental animations. But it's very easy to toggle them "On" and "Off" in a per vessel basis. Due to compatibility the default will be "Off".

In incremental animations the current state is incremented by small amount to the next state in the order in which the user applies the increments. In absolute animations where the reference state is the default state therefore an order of operations problem may appear that can corrupt the animations since the animations are applied in the order in which they are defined/declared in animation structure.

BTW, We have a custom camera API implemented in the D3D9 that can easily provide a video feed to the displays use to control/monitor the robotic arm. The camera rendering surface can be attached directly to a mesh. No MFD needed.

 

[Urwumpe]

BTW, We have a custom camera API implemented in the D3D9 that can easily provide a video feed to the displays use to control/monitor the robotic arm. The camera rendering surface can be attached directly to a mesh. No MFD needed.

Yes, I read a ticket about it. Not much details about the API for that. Do you need a project to test this?

 

[DaveS]

Priority ticket for a 5.0 release: https://sourceforge.net/p/shuttleultra/tickets/99/


This is something we can't live with. We must be able to operate the RMS properly which includes being able to toggle the various modes. Usually when I encounter a dead panel like this, a simple exit&reload brings it back to life. But not this time. I was in the middle of doing the STS-31 and now I can't release the telescope from the RMS as the END EFFECTOR MODE switch stuck in the OFF position, so I can't operate the EE to release the telescope and perform the sep burn.

 

[Urwumpe]

Priority ticket for a 5.0 release: https://sourceforge.net/p/shuttleultra/tickets/99/


This is something we can't live with. We must be able to operate the RMS properly which includes being able to toggle the various modes. Usually when I encounter a dead panel like this, a simple exit&reload brings it back to life. But not this time. I was in the middle of doing the STS-31 and now I can't release the telescope from the RMS as the END EFFECTOR MODE switch stuck in the OFF position, so I can't operate the EE to release the telescope and perform the sep burn.

I tend to disagree there - we are hunting ghosts on this bug. If you want to give this priority, we will waste a lot of time fixing the bug for user A and see it again on user B.



I'll try to get the old code working that allowed to check which panel was intercepting the mouse clicks, I need this anyway. but so far, the bug appeared and disappeared every other compilation.

 

[DaveS]

I'll try to get the old code working that allowed to check which panel was intercepting the mouse clicks, I need this anyway. but so far, the bug appeared and disappeared every other compilation.

For me it is consistent. Dead A8 panel always with payload attached to the RMS.

 

[Urwumpe]

For me it is consistent. Dead A8 panel always with payload attached to the RMS.

Then you should better verify that it is really the same bug and not something wrong with the RMS code. I discovered a similar problem when getting into a limit that the panel completely stopped responding, while the switches still worked.

 

[DaveS]

Then you should better verify that it is really the same bug and not something wrong with the RMS code. I discovered a similar problem when getting into a limit that the panel completely stopped responding, while the switches still worked.

I'm pretty sure it is the same bug, it matches the description to a "T". I've attached a scenario where I have experienced the bug consistently. BrianJ's HSTEx is required.

 

[Urwumpe]

Your HST-EX configuration file does not seem to be part of the add-on, did you mod something there?

 

[DaveS]

Your HST-EX configuration file does not seem to be part of the add-on, did you mod something there?

I thought I needed a separate cfg file to account for SSU's differing vertical offset in attachment points of the PLB but it turned out not to be needed, so all you need to is delete the "_SSU" suffix and it will load. I'll check in amended mission and launch scenarios.

 

[Donamy]

There is a small problem with the "Absolute animations", they are not fully backwards compatible with the incremental animations. But it's very easy to toggle them "On" and "Off" in a per vessel basis. Due to compatibility the default will be "Off".

In incremental animations the current state is incremented by small amount to the next state in the order in which the user applies the increments. In absolute animations where the reference state is the default state therefore an order of operations problem may appear that can corrupt the animations since the animations are applied in the order in which they are defined/declared in animation structure.

BTW, We have a custom camera API implemented in the D3D9 that can easily provide a video feed to the displays use to control/monitor the robotic arm. The camera rendering surface can be attached directly to a mesh. No MFD needed.

How do you set this feature ?

 

[DaveS]

How do you set this feature ?

Direct coding is required. Urwmupe inquired about this in this reply: https://www.orbiter-forum.com/showthread.php?p=606060&postcount=2946

 

[Urwumpe]

I thought I needed a separate cfg file to account for SSU's differing vertical offset in attachment points of the PLB but it turned out not to be needed, so all you need to is delete the "_SSU" suffix and it will load. I'll check in amended mission and launch scenarios.

Can reproduce the bug with some editing, interestingly the panel right next to it, A7U, is working fine. The clock on the right is also working.


Will check if the event handler is ignored.

 

[DaveS]

Can reproduce the bug with some editing, interestingly the panel right next to it, A7U, is working fine. The clock on the right is also working.


Will check if the event handler is ignored.

There's an similar bug where a random panel is similarly dead to the simulated world and can only be cured by the exit&reload procedure I described earlier. More of than not, it is one of the aft panels, either A7U or A1U. Never seen it with A6U which is very strange, only those two aft panels. Another similar bug is one where the Orbit DAP PBIs refuse to change when you click on them, happens most often after changing to FREE and you try to change back to one of the other modes.

 

[Urwumpe]

I can tell now that clbkVCMouseEvent is not called for it. Is there a maximum limit to the number of event areas?

---------- Post added at 22:55 ---------- Previous post was at 22:31 ----------

Much worse, RegisterVC is also never called for it in the test scenario. So there is no region to call.

---------- Post added at 23:37 ---------- Previous post was at 22:55 ----------

Ok, RegisterVC is called now, like any other panel as well. Changed the order of the panel groups to see if a hard limit in Orbiter is a problem, but it had no effect yet.

---------- Post added 15th May 2020 at 00:01 ---------- Previous post was 14th May 2020 at 23:37 ----------

OK, the bug is not caused by the area IDs. Using an enum to define them does not change the behavior.

---------- Post added at 00:15 ---------- Previous post was at 00:01 ----------

Changing the order, how the Areas are registered, has no effect at all. When A8 is called before A7U, A7U registers its panel area, A8 doesn't.

---------- Post added at 00:24 ---------- Previous post was at 00:15 ----------

After flipping the coordinates of the area, the panel A8 reacts to events again, but the switch positions are now off.


Could this be related to D3D9Client?

 

[STS]

I wanted to create a ticket about Body Flap PBI not lit during launch/ascent, but I don´t have permissions yet.


If I am understanding NASA´s documentation correctly, the Body Flap PBI should be 'on' during Launch until the dump is complete, but on SSU right now it´s currently off. This also happens on 4.2. On previous versions it was working.

Also, I wanted to close TT´s #141, 20, 170 and 79, if possible, as I understand that as PO I can do that, as I manage the product backlog.

 

[STS]

The following video shows the difficulties I have faced during landing with the current SSU, don´t know if it´s normal...



I don´t know it it´s an issue on my side, but when landing I a big difference on the handling of the shuttle, version 4.2 and earlier were more 'docile'. I don´t expect the shuttle to feel like a fighter jet, but I noticed a big difference.


I don´t know if it´s Orbiter 2016, something that I am doing horribly wrong, or me in need of some sessions on the STA :lol:

​

Video is recorded after I changed my deadzone to 0 on Orbiter´s joystick settings, when I starded to have slightly better results.



Also, the rudder doesn´t work, and I can´t switch Speedbrakes or Body Flap to manual.


Wind is disabled.