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

[Urwumpe]

Look here:

http://www.stroustrup.com/bs_faq2.html#constraints

The newer idea of concepts in C++ make this much simpler and readable - but we lack the compiler for it.

 

[GLS]

Look here:

http://www.stroustrup.com/bs_faq2.html#constraints

The newer idea of concepts in C++ make this much simpler and readable - but we lack the compiler for it.

So there's no point in me reading that? :lol:
Anyway, the AddMesh() call (to Vessel) doesn't work in BasicPanel. Moving that to AtlantisPanel (replacing an Atlantis class forward declaration with the include) works... but somehow doesn't look pretty.

 

[Urwumpe]

Is AddMesh public or protected for VESSEL? :hmm:

 

[Wolf]

I noticed after updating to rev.2774 the switches on Panel R1 and R2 don't work anymore..
Have they been disabled intentionally or could it be something went wrong recompiling?

PS I know they actually don't do anything in SSU but I use them when running through the FDF Checklists

 

[Urwumpe]

I moved this here, looks like a new issue related to the current panel changes, so its likely better answered and fixed here than making a new ticket about it.

I noticed after updating to rev.2774 the switches on Panel R1 and R2 don't work anymore..
Have they been disabled intentionally or could it be something went wrong recompiling?

PS I know they actually don't do anything in SSU but I use them when running through the FDF Checklists

 

[GLS]

Is AddMesh public or protected for VESSEL? :hmm:

Here are the changes I made:
BasicPanel.h

template <class TVessel>
class BasicPanel
{
	/*more stuff*/

protected:
	// mesh handles for panels with own mesh
	MESHHANDLE hMesh;
	UINT mesh_idx;
	VECTOR3 panelofs;

	bool bHasOwnVCMesh;

public:
	/*more stuff*/

	virtual void DefineMesh( const char* meshname ){};
	virtual void DefineMesh( const char* meshname, const VECTOR3& panelofs ){};
	virtual void AddMeshes( const VECTOR3& ofs ){};
	virtual void SetMeshVisibility( bool visible ){};

	/*more stuff*/
};

AtlantisPanel.h

#include "..\Atlantis.h"

class AtlantisPanel : public BasicPanel<Atlantis>
{
public:
	AtlantisPanel(Atlantis* _sts, const std::string& _name) : BasicPanel(_sts, _name) {};
	virtual ~AtlantisPanel() {};
	Atlantis* STS() const { return V(); };

	[COLOR="SeaGreen"]void DefineMesh( const char* meshname )
	{
		const VECTOR3 panelofs = _V( 0.0, 0.0, 0.0 );
		DefineMesh( meshname, panelofs );
		return;
	}

	void DefineMesh( const char* meshname, const VECTOR3& panelofs )
	{
		hMesh = oapiLoadMeshGlobal( meshname );
		mesh_idx = (UINT)-1;
		this->panelofs = panelofs;
		bHasOwnVCMesh = true;
		return;
	}

	void AddMeshes( const VECTOR3 &ofs )
	{
		if (mesh_idx == (UINT)-1)
		{
			VECTOR3 _ofs = ofs + panelofs;
			mesh_idx = STS()->AddMesh( hMesh, &_ofs );
			STS()->SetMeshVisibilityMode( mesh_idx, MESHVIS_VC );
		}
		return;
	}

	void SetMeshVisibility( bool visible )
	{
		if (mesh_idx != (UINT)-1)
		{
			if (visible) STS()->SetMeshVisibilityMode( mesh_idx, MESHVIS_VC );
			else STS()->SetMeshVisibilityMode( mesh_idx, MESHVIS_NEVER );
		}
		return;
	}[/COLOR]
};

I added another offset parameter, unused for now, so we can place a panel mesh in another location if we need.
Initially I had the idea of forcing separate panel meshes (makes sense to have separate meshes if we have separate classes :shrug, but that would mean breaking up the vc mesh in the Crawler... and as I'm currently not interested in that, I just streamlined the code to allow easier use of individual meshes.

---------- Post added at 12:27 AM ---------- Previous post was at 12:19 AM ----------

I noticed after updating to rev.2774 the switches on Panel R1 and R2 don't work anymore..
Have they been disabled intentionally or could it be something went wrong recompiling?

PS I know they actually don't do anything in SSU but I use them when running through the FDF Checklists

I had the R1 switches "declared" in the R2 click area... :facepalm: Committing the correction.
Panel R2 works here... that could be the "click area not working problem" I reported to Martin and mentioned here several times.

 

[Wolf]

I had the R1 switches "declared" in the R2 click area... :facepalm: Committing the correction.
Panel R2 works here... that could be the "click area not working problem" I reported to Martin and mentioned here several times.

Sorry, I just meant R1. R2 seems to be ok here

 

[GLS]

So, are the changes "approved"?
The DefineMesh() members could/should be protected as they are called from within the panels, but the other 2 must be public as they are called from the PanelGroup.

---------- Post added at 09:32 PM ---------- Previous post was at 12:37 PM ----------

...and now in the correct thread :shifty:

Committed 96 files at once... that's gotta be a record (except for branch mergers).

Anyway, I found this interesting document with a flight deck diagram with MEDS panel area IDs, which helps in labeling the F6 and F8 panel switches. Now we only need the switch IDs, but even without them we now have half of the equation.

 

[Wolf]

Potential ATT issue:
I noticed one thing about OMS burn attitudes, in particular I am referring to deorbit burn:
If after loading the targets (PEG-4) for the maneuver (ITEM 22 EXEC) I save/close the scenario and then I restart it what happens is that the orbiter orient herself in the wrong burn attitude (of course after ITEM 27 EXEC is inputted). I think this is possibly due to the State Vector Software section data saved in the scenario file: as a matter of fact deleting those lines solves the issue.
Is that normal or could it be a bug?

 

[GLS]

Potential ATT issue:
I noticed one thing about OMS burn attitudes, in particular I am referring to deorbit burn:
If after loading the targets (PEG-4) for the maneuver (ITEM 22 EXEC) I save/close the scenario and then I restart it what happens is that the orbiter orient herself in the wrong burn attitude (of course after ITEM 27 EXEC is inputted). I think this is possibly due to the State Vector Software section data saved in the scenario file: as a matter of fact deleting those lines solves the issue.
Is that normal or could it be a bug?

It's probably another effect of the lack of a proper OMS burn "life-cycle" (ticket 158) and/or not having the correct/good enough module division between OrbitDAP, OMSBurnSoftware and StateVectorSoftware to implement things.

 

[Urwumpe]

Maybe it would be a good idea to have a "COMPOOL" scenario state handler around for such data, to simplify this.

 

[GLS]

Maybe it would be a good idea to have a "COMPOOL" scenario state handler around for such data, to simplify this.

Yes, your new GPCs will need to dump all the "pools" to the scenario, otherwise they would have to guess things. :lol:

 

[Urwumpe]

Yes, your new GPCs will need to dump all the "pools" to the scenario, otherwise they would have to guess things. :lol:

Well, we could also make it like now and let each software save its data - but this could get messy with shared data.

 

[GLS]

Well, we could also make it like now and let each software save its data - but this could get messy with shared data.

Internal variables should be the responsability of the owner, but for shared variables, due to the "shared" feature, they need to be saved outside the owners/users.
It shouldn't be hard to dump an array into the scenario. :shrug:

 

[Urwumpe]

Internal variables should be the responsability of the owner, but for shared variables, due to the "shared" feature, they need to be saved outside the owners/users.
It shouldn't be hard to dump an array into the scenario. :shrug:

Yeah. But I think it might be better dumping structured data there, for easier debugging. You know, I think already for a longer time to add a vessel-specific "DPS Debugging MFD" to SSU for displaying such information during runtime, because the DPS is getting pretty complex already.

 

[GLS]

Yeah. But I think it might be better dumping structured data there, for easier debugging. You know, I think already for a longer time to add a vessel-specific "DPS Debugging MFD" to SSU for displaying such information during runtime, because the DPS is getting pretty complex already.

There are displays with the status of lots of things in the DPS/IDP/MDU (95% of them are not done in SSU...). We could always "invent" a few on a temporary basis. :shrug:
So what's the current status?

 

[Urwumpe]

So what's the current status?

Nothing good yet. But at least, I found some hours for coding despite having a full family life now from 7:00-22:00 ...

Also, for debugging internals of GPC, MMU or MDM, I think a custom display would be smarter than abusing empty space on "defined displays". The full diagnostic data of a GPC can usually only be read on the ground.

 

[GLS]

About the payload latches and the upper stages: as the A6U panel controls are wired to where the mission dictates, we could have the panels connect the latch controls to the upper stages support structures, allowing their latches to be simulated. This would leave 1 of our 3 our payload active latch classes "headless" as it wouldn't be wired to controls, which shouldn't be an issue...
This doesn't solve every problem in this department, but IMO it alows more functionality at no expense of future changes. Does anyone see any issues?

---------- Post added 01-10-18 at 03:54 PM ---------- Previous post was 01-09-18 at 09:32 PM ----------

The regular payload latches have the motors powered* via the Pl Bay Mech Pwr switches on R13L.
As I don't have any electrical diagrams of the IUS ASE or the CISS, I'm going to have their latch motors powered* via (existing) power switches on the respective systems.


*) as we don't have electrical systems, this is done by depending the motor "operation" on a switch position.

---------- Post added at 04:39 PM ---------- Previous post was at 03:54 PM ----------

Scratch that.
I just remembered to look in the IUS deploy checklist and it has the crew use the Pl Bay Mech Pwr switches like the "regular" latches so... :shrug:

---------- Post added 01-11-18 at 01:15 AM ---------- Previous post was 01-10-18 at 04:39 PM ----------

The latches on the upper stages are done!
I only wired 2 for the IUS as even though the checklist as the crew check 3 latches, only 2 are operated. :shrug:

Also, the CISS boxes on the tilt table hit the GH2 vent pipe.

 

[DaveS]

Also, the CISS boxes on the tilt table hit the GH2 vent pipe.

I know. Would be nice if the actual PRLAs could be added like the bridge rails are currently. This way we could place them at their historically accurate positions.

 

[GLS]

I know. Would be nice if the actual PRLAs could be added like the bridge rails are currently. This way we could place them at their historically accurate positions.

The problem is that while the bridge fittings are in fixed positions, the PRLAs are not, so the user would have to specify where they go, and that needs a new architecture to handle payloads... and I've been thinking recently about this, but didn't come up with anything... :uhh:

On a more productive note: I found the source of the progressive fps slowdown we get at increasing time accelerations: a step subsampling feature in SubsystemDirector. Each time step it must do 3 calls to each subsystem, and it must do them (step length / 40ms) times, so as the step length increases with time acceleration the number of times those calls are done skyrockets. :compbash:
No subsystem is currently using this (only the AP101S class gets one of the 3 calls and it does nothing... for some years) so it might be a good idea to disable it... for now... is this going to be needed for the new DPS?