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

[GLS]

Added the radar altimeter, with all the "trigonometric bells and whistles" to deal with vehicle attitude. Currently, if turned on, it only outputs the data to the debug string, but it already has the correct format (parity bits and all) and it's just waiting for the GPCs.

 

[Urwumpe]

Added the radar altimeter, with all the "trigonometric bells and whistles" to deal with vehicle attitude. Currently, if turned on, it only outputs the data to the debug string, but it already has the correct format (parity bits and all) and it's just waiting for the GPCs.

Well, the MDMs are also needed along the data path.

Not sure how much I can do this month, the Powers That Be command me to leave Germany for some weeks.

Would a MDM implementation and a I/O API layer be enough for the next steps with the old GPC software format? If not, strike the new GPC implementation from the list for now if it just depends on me. I can't contribute enough to finish the whole component soon.

 

[GLS]

Well, the MDMs are also needed along the data path.

Not sure how much I can do this month, the Powers That Be command me to leave Germany for some weeks.

Would a MDM implementation and a I/O API layer be enough for the next steps with the old GPC software format? If not, strike the new GPC implementation from the list for now if it just depends on me. I can't contribute enough to finish the whole component soon.

We need to centralize data access somehow... it probably could be done with the current GPCs by having a "data collection" class running there. We could have public variables or get functions to make the data available to the rest of the GPC software. But GPC I/O would still be limited to what we have now. The data flow around the IDPs also needs to improve, as most MEDS displays are calling Orbiter functions to get data.

The current GPC/DPS model was good and allowed lots of things to be done, but I think we are at a point were a different model is needed to do more. It doesn't need to be perfect, just needs to be more capable.

About your "absence", shouldn't we get SSU 4.0 out the door before you go? It's seems we are about to release an Orbiter 2010 addon after Orbiter 2016 is out... :uhh:

 

[DaveS]

About your "absence", shouldn't we get SSU 4.0 out the door before you go? It's seems we are about to release an Orbiter 2010 addon after Orbiter 2016 is out... :uhh:

It don't really see the rush for a 2010-P1 release. What exactly does it give us? It seems the longer we keep this branch (yes, I know it's our current trunk version) the longer we keep a lead weight around our necks. I really think that we should focus on 2016. As far as I can tell, 2010-P1 is about as done as it can be. It's only really missing the SWT (which I'll work on) and the CISS bellow animations.

 

[Urwumpe]

It don't really see the rush for a 2010-P1 release. What exactly does it give us? It seems the longer we keep this branch (yes, I know it's our current trunk version) the longer we keep a lead weight around our necks. I really think that we should focus on 2016. As far as I can tell, 2010-P1 is about as done as it can be. It's only really missing the SWT (which I'll work on) and the CISS bellow animations.

I can't yet speak about the latest RC, but the number of known bugs in it suggests that we won't see a final stable release soon. Some support for 2010 would be needed until the stable 2016 version is out.

No need to hurry there or rush things.

 

[GLS]

It don't really see the rush for a 2010-P1 release.

I don't think it makes much sense to release an addon for an Orbiter version that then becomes "obsolete" the next week or month. But this is just my opinion. :shrug:

Some support for 2010 would be needed until the stable 2016 version is out.

And because of this we should release 4.0 ASAP* so we can have people using it while Orbiter 2016 is still being worked on.

*) OK, maybe not today or tomorrow, but next week or so.


In other news, I was updating the beta branch with the trunk, and just discovered something about the "launch position bug": the stack is released and it moves "back" in the Solar System, i.e, it's like it is being left behind by the Earth, although the magnitude of the movement doesn't seem to match the speed of the Earth around the Sun.

 

[Urwumpe]

In other news, I was updating the beta branch with the trunk, and just discovered something about the "launch position bug": the stack is released and it moves "back" in the Solar System, i.e, it's like it is being left behind by the Earth, although the magnitude of the movement doesn't seem to match the speed of the Earth around the Sun.

Could still be the cause - the integrators for propagating the new position likely try to find a stable solution and fail to get one in the first timestep because of bad initial parameters.

Maybe the initial parameters are off when you are releasing the spacecraft from a landed vehicle.

 

[GLS]

Could still be the cause - the integrators for propagating the new position likely try to find a stable solution and fail to get one in the first timestep because of bad initial parameters.

Maybe the initial parameters are off when you are releasing the spacecraft from a landed vehicle.

The current code (that worked for some years now) has MLP releasing the vehicle and setting it to it's own position plus an offset.

VESSELSTATUS2 st;
		st.version = 2;
		st.flag = 0;
		VESSELSTATUS2 st2;
		st2.version = 2;
		st2.flag = 0;
		GetStatusEx(&st2);

		DetachChild(ahHDP, 0.00001);

		VESSEL* pV = oapiGetVesselInterface(hShuttle);
		pV->GetStatusEx(&st);
		st.rbody = st2.rbody;
		st.rvel = st2.rvel;
		pV->DefSetStateEx(&st);

The same logic is used for the drag chute which usually sends it into another dimension and it CTDs, and also on the IUS 1º stage which works without issue. Releasing the drag chute in space, in flight in the atmosphere or stopped on the ground changes nothing. The same for the IUS.

Giving that other stange things are happening sometimes (panels not working), it could be a result of a memory corruption somewhere. With that in mind a few weeks ago I started to delete systems, panels, aerodynamics, whatever I could delete until it was pretty basic "flying brick" vessel (and eventually deleted too much and it stopped working :uhh, and still the drag chute issue was there.

 

[Urwumpe]

The code ignores the "landed" or "freeflight" status of the vessel, which could be a problem.

 

[GLS]

The code ignores the "landed" or "freeflight" status of the vessel, which could be a problem.

With st.status = 1; (landed state) the vehicle stays in the same place, but the orientation isn't correct, even when setting it to the MLP orientation (and it's not just a 90º difference). It looks to be a problem with how the pad vessel is landed...

---------- Post added 08-03-16 at 01:13 AM ---------- Previous post was 08-02-16 at 12:42 PM ----------

I wasn't going anywhere in that debugging (other than noticing that some changes I made to some launch scenarios in the beginning of the branch make no difference now), so I changed gears and tried to hunt any memory issues we might have.
Didn't find anything other than a forgotten memory allocation for an animation in the PushButton class and 2 PLB camera animations not calling AddManagedAnimationComponent... and a few complaints about unreleased memory in the MissionFileManagement stuff, for which there are 2 functions (InitMissionManagementMemory and ClearMissionManagementMemory) that are not called. This is probably a stupid question but, these are supposed to be called from the Atlantis constructor and destructor, right? I added them and the complaints went away, but I just want to be sure they are supposed to be used this way as I didn't work in this.
As for memory corruption, I didn't find anything.

 

[GLS]

I was looking at ticket 133 (HUD draws off glass), and noticed that the mesh group on which the HUD is drawn is not hidden as the API requests, thus it was showing a glass that isn't there in the real thing. The source of the ticket issue is that the "render group" is partially buried on the bottom.
As the render group makes the stuff drawn show up too aft (it should show in the middle where the glasses are), I was thinking of moving the render group forward and tilt it so is in the correct place. The problem with that is that the graphics would be visible at an angle, so it would look +/- distorted (aspect ratio of 1:0.7). This is easily correctable with a (stretch) bitblt... but like with the MFDs, that doesn't work in MOGE. :facepalm:
Should we accept the wrong aspect ratio in MOGE (in D3D9 it is correctable), and move/tilt the HUD render group? Or, as the HUD needs to be corrected for whatever changed in Orbiter 2016, should this all be delayed until the vc upgrade is done?

---------- Post added 08-05-16 at 03:01 PM ---------- Previous post was 08-04-16 at 03:54 PM ----------

I think I finally made some solid progress in the "drag chute does to another dimension" issue! The problem appears to be related to WHEN the drag chute vessel is created. We were creating it in the clbkPostStep, and when I added a key shortcut to create all the drag chutes I wanted at a key stroke lol, I noticed that in 0.1x time acceleration there was no problem maybe 90% of the time, but in normal time or with the normal code the problem was pretty much as certain as taxes or death. So then I decided to move the drag chute code to the other step call (clbkPreStep) to see what would happen... and no more issues.
Now, is this an Orbiter 2016 bug, or is it a feature and we were creating vessels at the wrong time?

---------- Post added at 03:07 PM ---------- Previous post was at 03:01 PM ----------

...and a quick check of the code shows that (surprise, surprise) is in the post step callback that the stack is released from the MLP, and SRBs and ET are released (haven't done any testing on this yet).

 

[Urwumpe]

Now, is this an Orbiter 2016 bug, or is it a feature and we were creating vessels at the wrong time?

I would call it a bug in Orbiter 2016, because the documentation for the function does not ban it.

The behavior sounds like Orbiter reacts iffy if the vessel has no data about the previous timestep as recorded BEFORE the propagation step. So, when you create it in preStep, it works fine. if you do it in post step, after propagation, the processing operates on uninitialized data.

 

[GLS]

I would call it a bug in Orbiter 2016, because the documentation for the function does not ban it.

The behavior sounds like Orbiter reacts iffy if the vessel has no data about the previous timestep as recorded BEFORE the propagation step. So, when you create it in preStep, it works fine. if you do it in post step, after propagation, the processing operates on uninitialized data.

It makes sense.
There were changes from 2010 in the time step logic. One change that affects SSU is the setting of the attachment parameters for the first time step, which Martin hasn't explained if it is intended or not and I can't tell because the default Atlantis has a similar implementation to ours in the attachment stuff (and it also doesn't work).

 

[DaveS]

It makes sense.
There were changes from 2010 in the time step logic. One change that affects SSU is the setting of the attachment parameters for the first time step, which Martin hasn't explained if it is intended or not and I can't tell because the default Atlantis has a similar implementation to ours in the attachment stuff (and it also doesn't work).

In that case, I'd say it worth reporting, especially if a default vessel has issues. Those should be solid performers.

 

[GLS]

In that case, I'd say it worth reporting, especially if a default vessel has issues. Those should be solid performers.

I already posted the issue in the beta thread a few weeks ago, and posted a link to that in one of the RC threads recently.

 

[DaveS]

I already posted the issue in the beta thread a few weeks ago, and posted a link to that in one of the RC threads recently.

Are you sure? I just checked and there's no mention of this issue either in the official issue tracker or any of the RC or beta threads.

 

[GLS]

The last post, that links to the previous http://www.orbiter-forum.com/showthread.php?p=538332&postcount=6

---------- Post added at 06:59 PM ---------- Previous post was at 06:57 PM ----------

I didn't create a ticket because I can't tell if it is a bug... right now I just have a "request for comments".

---------- Post added 08-06-16 at 12:36 AM ---------- Previous post was 08-05-16 at 06:59 PM ----------

To the graphics department: "ICO sphere". I just found this "concept" and I am wondering if this wouldn't be a good idea for the ADI ball mesh? Would this get rid of the distortion near the poles?

 

[GLS]

I just committed the necessary changes to fix the attachment positions that are connected to the animations. It should all be in the correct place in the first frame.

 

[DaveS]

Not sure if this has been noted yet, but on the GNC 305 HORIZ SIT screen, the runway line is not connected to the HAC circle:

 

[GLS]

Not sure if this has been noted yet, but on the GNC 305 HORIZ SIT screen, the runway line is not connected to the HAC circle:

Totally normal as the HAC is a cone not a cylinder. The displayed diameter is related to the orbiter altitude, and the OGS line is at 10Kft where the diameter is smaller.

---------- Post added at 01:41 AM ---------- Previous post was at 12:28 AM ----------

I've been playing around with ball meshes for the ADI and the ICO thing doesn't really work. The nature of the point placement is such that it's not adequate for latitude and longitude lines... unless we go full bananas and use over 10000 vertices.
Another issue is the seam of the texture which "loops around" leaving a band that has all the texture. I think this might be related to not using the full area of the texture.