Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Space Shuttle Ultra Support & development threads for Space Shuttle Ultra addon.

Reply
 
Thread Tools
Old 07-18-2018, 11:08 PM   #1906
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by GLS View Post
 Bug found! Surprise surprise, it was my fault... When I added the _DEBUG preprocessor stuff a few weeks ago, I had one line too many inside it, so when not in debug mode, the @ENDSUBSYSTEM line was never written, and when loading = kaput every single subsystem parameter.
Thanks for tracking the down the bug and fixing it. I was starting to think that something was seriously wrong with my system since it was so strange.
DaveS is online now   Reply With Quote
Old 07-19-2018, 12:41 PM   #1907
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by DaveS View Post
 Thanks for tracking the down the bug and fixing it. I was starting to think that something was seriously wrong with my system since it was so strange.
It's my job (and it was my fault...).
GLS is offline   Reply With Quote
Old 07-19-2018, 01:08 PM   #1908
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 It's my job (and it was my fault...).
"We don't make mistakes, just happy little accidents."

And if you don't want to believe in the words of Bob Ross, always remember: SSU is a team effort, in the good times and in the bad times.
Urwumpe is offline   Reply With Quote
Old 07-19-2018, 02:17 PM   #1909
Wolf
Donator
 
Wolf's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 "We don't make mistakes, just happy little accidents."

And if you don't want to believe in the words of Bob Ross, always remember: SSU is a team effort, in the good times and in the bad times.

Guys YOU ROCK
Wolf is offline   Reply With Quote
Thanked by:
Old 07-20-2018, 10:10 PM   #1910
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 "We don't make mistakes, just happy little accidents."
Well, here's another...
Although I'm not totally happy with the current SimpleCOMPOOL, I think the current short comings can be overcome with more code, most of it outside Orbiter. Given that we don't have a list of the COMPOOLs and what variables are in them, I currently can't really justify a move to the structure-type construct. So we are left with the current unsigned short array. A way to have both a way to load/save the variables, and to garantee that the addresses don't everlap (not easy by hand) is to have some sort of script/program/whatever that would take a list of variables (i.e. names) and their types and would generate the addresses and a string of names, so new code in the SimpleGPCSystem can take to name variables for the scenarios files.
BTW: An interesting detail about COMPOOLs is what lifetime do they have? *my head hurts*

What I haven't figured out yet is how to plug the I-LOADs into this... some of them must be placed in COMPOOL variables, to be accessable by multiple modules, and maybe there should be a way to define them per mission file. And maybe they don't need to be loaded/saved from the scenario file.

---------- Post added at 11:10 PM ---------- Previous post was at 10:38 PM ----------

Maybe a .csv file for COMPOOL definition like this:
[name], [type], [I-LOADs as needed/desired]
XDOT,DW,(I-LOAD),,,
AEROJET_FCS_ROLL,W,(I-LOAD),,,
XA,M22,(I-LOAD),(I-LOAD),(I-LOAD),(I-LOAD)
AB_CD,W4,(I-LOAD),(I-LOAD),(I-LOAD),(I-LOAD)
WX_YZ,DW3,,,,

(^^still have to research the types)

...and have the I-LOADs in a separate list that would be used to generate a .h file with all the consts so they can be used by who needs them.

This is already a good detour from the guidance stuff, but I really need to have some I-LOADs in the COMPOOL, and also have them in an matrix so I can access them via index, so something needs to be done.
GLS is offline   Reply With Quote
Old 07-20-2018, 10:10 PM   #1911
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 BTW: An interesting detail about COMPOOLs is what lifetime do they have? *my head hurts*

What I haven't figured out yet is how to plug the I-LOADs into this... some of them must be placed in COMPOOL variables, to be accessable by multiple modules, and maybe there should be a way to define them per mission file. And maybe they don't need to be loaded/saved from the scenario file.

Well, should I really make things overly complicated?



A COMPOOL shares the lifetime of its memory overlay. There is no memory management in the FCOS that is more sophisticated. You can say, everything is determined at compile time. A memory configuration (MC) simply consists of the FCOS overlay (OPS 0) and the application software overlay (For example, the majory function GNC memory overlay + OPS 1 overlay + minimal OPS 3 overlay in upper memory). When a memory overlay is changed, the contents of the new memory overlay are loaded from tape.

Thus, the I-LOADS are simple: They are set at compilation. More specific, the compilation of the tape images from compiled object files. You simply load the memory overlay from tape and the I-LOADS are there.

An I-LOAD is roughly the HAL/S equivalent to a "int x = 1;" statement.

Yes, a CSV file would be one option. I would prefer a minimal HAL/S FC parser there, simply because the input would then be exactly the information we have from NASA, and structured data could be kept structured, just like arrayed data, what CSV can't. Another option would be a XML structure. The data types are explained in the HAL/S language manuals. When loading a scenario, we would need something like a "tape linker" creating the data structures for every memory configuration. Also, for modifications/uplinks after creating the tapes, we would need to store the changes in memory or the changes of data on the tape.

Did you already take a look at the examples or parser trees of the COMPOOLs in HAL/S?

Last edited by Urwumpe; 07-20-2018 at 10:29 PM.
Urwumpe is offline   Reply With Quote
Old 07-21-2018, 12:02 AM   #1912
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 A COMPOOL shares the lifetime of its memory overlay. There is no memory management in the FCOS that is more sophisticated. You can say, everything is determined at compile time. A memory configuration (MC) simply consists of the FCOS overlay (OPS 0) and the application software overlay (For example, the majory function GNC memory overlay + OPS 1 overlay + minimal OPS 3 overlay in upper memory). When a memory overlay is changed, the contents of the new memory overlay are loaded from tape.
I suspected that MCs had something to do with it... and ATM I'm not really interested in going down that road.

Quote:
Originally Posted by Urwumpe View Post
 Thus, the I-LOADS are simple: They are set at compilation. More specific, the compilation of the tape images from compiled object files. You simply load the memory overlay from tape and the I-LOADS are there.

An I-LOAD is roughly the HAL/S equivalent to a "int x = 1;" statement.
That I knew. It's not so much the nature of the I-LOADS but how do we come up with something that works for both modules (our SimpleGPCSoftware classes) and the COMPOOL.
My idea above, of having a I-LOAD list that gets processed into a .h file, and also gets used by the COMPOOL "preprocessor" (that generates the COMPOOL stuff for usage and save/load), doesn't allow for mission specific I-LOADS. Most of the I-LOADs didn't change or they aren't critical enough for "user control" (e.g., the 15s OMS EXEC timer), but user control is needed because SSME max thrust was defined via I-LOAD. Maybe having a I-LOAD list (static) just with the names, and keeping the values in another list (user defined) would work. The values list would be loaded into an array, and then each module, and SimpleGPCSystem for the COMPOOL, would read what they needed for their initializations.

Quote:
Originally Posted by Urwumpe View Post
 Yes, a CSV file would be one option. I would prefer a minimal HAL/S FC parser there, simply because the input would then be exactly the information we have from NASA, and structured data could be kept structured, just like arrayed data, what CSV can't. Another option would be a XML structure. The data types are explained in the HAL/S language manuals. When loading a scenario, we would need something like a "tape linker" creating the data structures for every memory configuration. Also, for modifications/uplinks after creating the tapes, we would need to store the changes in memory or the changes of data on the tape.

Did you already take a look at the examples or parser trees of the COMPOOLs in HAL/S?
Parser trees of COMPOOLs?! I haven't read everything of the docs I have, but I haven't seen that...
Like I said in the post above, we don't know what variables go in which COMPOOL... or do we? And even if we know some, that won't be all, and as accessing then in C/C++ won't be as easy as in HAL/S, why bother with grouping them in the code? We could "group" the variables (and ID the COMPOOL if we have that info) in comments on the "COMPOOL variable list file".
About specifying things in a way that is closer to "the official way": totally agree. Like I said above, I have yet to do a catalog of the types, so that needs to be done so we know the potatos from the onions. Going back to paragraph above, do we have enough info?
GLS is offline   Reply With Quote
Old 07-21-2018, 11:14 AM   #1913
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 Like I said in the post above, we don't know what variables go in which COMPOOL... or do we?

Lets put it that way: We know it pretty good (95%) for FCOS and SM. Also I think for some aspects of GNC, we reach around 50% already.
Urwumpe is offline   Reply With Quote
Old 07-21-2018, 01:55 PM   #1914
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 Lets put it that way: We know it pretty good (95%) for FCOS and SM. Also I think for some aspects of GNC, we reach around 50% already.
Let's say we go with that and make separate COMPOOLs, how would the modules access them? Currently we put it all in an array, and then call something to read/write from there in a +/- controlled way.


So, COMPOOL variables in HAL/S format:
Code:
C	runway declarations
	DECLARE X SCALAR DOUBLE;
	DECLARE Y SCALAR DOUBLE;
	DECLARE Z SCALAR DOUBLE;
	DECLARE Z MATRIX(3,3) DOUBLE;

C	other stuff
	DECLARE IGI INTEGER SINGLE INITIAL(1);
What I don't see anywhere is "non-hardcoded" initial values...
The expression I-LOAD (or similar) simply doesn't exist in any HAL/S doc I have. I was expecting the I-LOADs to be centralized in a file (or more) and not to be "scattered" throught the code... and according to this they probably were. Anyway, we'll need a centralized system as we will only know the values during loading.

Anyone wants to write the parser, while I write the variables?
GLS is offline   Reply With Quote
Old 07-21-2018, 04:26 PM   #1915
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

The INITIAL(1) expression is it. As far as I understand the workflow, the classic I-LOAD values are created as INITIALs and compiled into the tape images by the linker for validation and testing.

The program modules refer to the COMPOOL template, which defines the data structure while the memory contents are in the COMPOOL object file.

Last edited by Urwumpe; 07-21-2018 at 04:31 PM.
Urwumpe is offline   Reply With Quote
Old 07-21-2018, 05:09 PM   #1916
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 The INITIAL(1) expression is it. As far as I understand the workflow, the classic I-LOAD values are created as INITIALs and compiled into the tape images by the linker for validation and testing.
Yes, the INITIAL (or CONSTANT) keyword sets the initial variable contents, but that doesn't really work for us, because of the per-mission I-LOAD requirement. So we need a way to load both COMPOOL and modules with values...

Here is a variable definition list, based on the current COMPOOL stuff:
Code:
C	----------------------------------------------------------------
C	SSU COMPOOL definition
C	----------------------------------------------------------------
C	SINGLE => 16b
C	DOUBLE => 32b
C	SCALAR should always be DOUBLE, and implemented in C with a 32b float
C
C
C	outputs to EIUs
	DECLARE EIU_1_CMD INTEGER SINGLE;
	DECLARE EIU_2_CMD INTEGER SINGLE;
	DECLARE EIU_3_CMD INTEGER SINGLE;
C
C	inputs from EIUs
	DECLARE EIU_1_PRIDATA ARRAY(32) INTEGER SINGLE;
	DECLARE EIU_2_PRIDATA ARRAY(32) INTEGER SINGLE;
	DECLARE EIU_3_PRIDATA ARRAY(32) INTEGER SINGLE;
	DECLARE EIU_1_SECDATA ARRAY(6) INTEGER SINGLE;
	DECLARE EIU_2_SECDATA ARRAY(6) INTEGER SINGLE;
	DECLARE EIU_3_SECDATA ARRAY(6) INTEGER SINGLE;
C
C	output to DDU-1
	DECLARE DDU1_ADI ARRAY(14) INTEGER SINGLE;
	DECLARE DDU1_HSI ARRAY(10) INTEGER SINGLE;
	DECLARE DDU1_AVVI ARRAY(6) INTEGER SINGLE;
	DECLARE DDU1_AMI ARRAY(6) INTEGER SINGLE;
C
C	output to DDU-2
	DECLARE DDU2_ADI ARRAY(14) INTEGER SINGLE;
	DECLARE DDU2_HSI ARRAY(10) INTEGER SINGLE;
	DECLARE DDU2_AVVI ARRAY(6) INTEGER SINGLE;
	DECLARE DDU2_AMI ARRAY(6) INTEGER SINGLE;
C
C	output to HUD-1
	DECLARE HUD1_MSG1 ARRAY(31) INTEGER SINGLE;
	DECLARE HUD1_MSG2 ARRAY(12) INTEGER SINGLE;
C
C	output to HUD-2
	DECLARE HUD2_MSG1 ARRAY(31) INTEGER SINGLE;
	DECLARE HUD2_MSG2 ARRAY(12) INTEGER SINGLE;
C
C	TODO MDM FF1
C
C	TODO MDM FF2
C
C	////
	DECLARE OVHD INTEGER SINGLE;
	DECLARE IGS INTEGER SINGLE;
	DECLARE IGI INTEGER SINGLE;
	DECLARE RWID INTEGER SINGLE;
	DECLARE LSID INTEGER SINGLE;
C
	DECLARE SB_SEL INTEGER SINGLE;
C
	DECLARE PRI_ID CHARACTER(5);
	DECLARE PRI_HDG SCALAR DOUBLE;
	DECLARE PRI_POS ARRAY(3) SCALAR DOUBLE;
	DECLARE PRI_G2R MATRIX(3,3) SCALAR DOUBLE;
	DECLARE SEC_ID CHARACTER(5);
	DECLARE SEC_HDG SCALAR DOUBLE;
	DECLARE SEC_POS ARRAY(3) SCALAR DOUBLE;
	DECLARE SEC_G2R MATRIX(3,3) SCALAR DOUBLE;
C
C	TODO Landing SOP
C
C	Aerojet DAP FCS
	DECLARE AEROJETDAP_FCS_PITCH INTEGER SINGLE;
	DECLARE AEROJETDAP_FCS_ROLL INTEGER SINGLE;
	DECLARE AEROJETDAP_FCS_SB INTEGER SINGLE;
	DECLARE AEROJETDAP_FCS_BF INTEGER SINGLE;
C
C	A/L UPP
	DECLARE H SCALAR DOUBLE;
	DECLARE HDOT SCALAR DOUBLE;
	DECLARE V_T SCALAR DOUBLE;
	DECLARE VI SCALAR DOUBLE;
	DECLARE KEAS SCALAR DOUBLE;
	DECLARE VG SCALAR DOUBLE;
	DECLARE X SCALAR DOUBLE;
	DECLARE Y SCALAR DOUBLE;
	DECLARE Z SCALAR DOUBLE;
	DECLARE XDOT SCALAR DOUBLE;
	DECLARE YDOT SCALAR DOUBLE;
	DECLARE PSD SCALAR DOUBLE;
	DECLARE HDG SCALAR DOUBLE;
	DECLARE GAMMA SCALAR DOUBLE;
	DECLARE PHI SCALAR DOUBLE;
	DECLARE COSPHI SCALAR DOUBLE;
	DECLARE THETA SCALAR DOUBLE;
	DECLARE ALPHA SCALAR DOUBLE;
	DECLARE BETA SCALAR DOUBLE;
	DECLARE QBAR SCALAR DOUBLE;
	DECLARE NY SCALAR DOUBLE;
	DECLARE NZ SCALAR DOUBLE;
	DECLARE WEIGHT SCALAR DOUBLE;
C
C	///
	DECLARE TG_END INTEGER SINGLE;
C
C	Autoland
	DECLARE PMODE INTEGER SINGLE;
	DECLARE FMODE INTEGER SINGLE;
	DECLARE NZ_CMD SCALAR DOUBLE;
	DECLARE PHIC_AL SCALAR DOUBLE;
	DECLARE RC SCALAR DOUBLE;
	DECLARE DSBC_AL SCALAR DOUBLE;
	DECLARE DBFC SCALAR DOUBLE;
C
C	////
	DECLARE SB_POS SCALAR DOUBLE;
C
(I not 100% sure on the SINGLE vs DOUBLE bit size...)

And the parser would create a .h file with something like this (first 6 variables only):
Code:
// addrs
unsigned int SCP_EIU_1_CMD = 0;// outputs to EIUs
unsigned int SCP_EIU_2_CMD = 1;
unsigned int SCP_EIU_3_CMD = 2;

unsigned int SCP_EIU_1_PRIDATA = 3;// inputs from EIUs
unsigned int SCP_EIU_2_PRIDATA = 35;
unsigned int SCP_EIU_3_PRIDATA = 67;


const unsigned int COMPOOL_SIZE = 99;
const unsigned int COMPOOL_VAR_COUNT = 6;


// name array
const char SCP_name[COMPOOL_VAR_COUNT] = {
	"EIU_1_CMD",
	"EIU_2_CMD",
	"EIU_3_CMD",
	"EIU_1_PRIDATA",
	"EIU_2_PRIDATA",
	"EIU_3_PRIDATA"
};

// addr array
const unsigned int SCP_addr[COMPOOL_VAR_COUNT] = {
	SCP_EIU_1_CMD,
	SCP_EIU_2_CMD,
	SCP_EIU_3_CMD,
	SCP_EIU_1_PRIDATA,
	SCP_EIU_2_PRIDATA,
	SCP_EIU_3_PRIDATA
};

// type array
// TODO define this better
const unsigned int SCP_type[COMPOOL_VAR_COUNT] = {
	1,
	1,
	1,
	2,
	2,
	2
};
It would contain the addresses for general usage, and a list of addresses, names and types for scenario load/save.
The "general usage" would work (as it is now) by calling a type-specific function to read/write, but it could be more controlled (e.g. for arrays) if we take into account the specific variable size. This probably would be a safer bet, but each read/write would need to go to the SCP_type array to get the size info for the checks, and we could maybe use overload functions to avoid calling Read_INTEGER, and sending the address of a SCALAR.
GLS is offline   Reply With Quote
Old 07-21-2018, 05:53 PM   #1917
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Well, remember that there are multiple COMPOOLs to prevent multi-process issues.

Again, I think the process would need something like:

COMPOOL template source --> default COMPOOL + COMPOOL template
COMPOOL mission instance source --> mission COMPOOL + COMPOOL template

Since the template is the same for the COMPOOL we just need it once. Since we use a C++ implementation, the template should better be a C++ header file. The mission COMPOOL is then a matter of taste. a plain binary file would be enough since we can simply address it as object in C++ and just need to deserialize it for the class. Of course, we could then also simply create a XML template for mission COMPOOL instances. But since we also need to get the data into the mission editor, it might make sense to compile the COMPOOL there, create the needed data structures for creating mission data in a format that works best for the mission editor and just let SSU parse and validate a simple line-wise text file: 32 character variable identifier, 16 characters for subscript, 16 for the value, 15 reserved for extensions, one character as checksum. The basic components for describing the COMPOOL as C++ "user model" would then handle the parsing. And with user model, I mean C++ classes that describe HAL/S data types in a COMPOOL in a way that makes it easy to use them in C++ algorithms. Ideally it is just the HAL/S code with C++ syntax.

Also the memory configurations matter a lot, but I can understand why you rather want to have a "one MC for all" solution.

Last edited by Urwumpe; 07-21-2018 at 06:01 PM.
Urwumpe is offline   Reply With Quote
Old 07-21-2018, 07:03 PM   #1918
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 Well, remember that there are multiple COMPOOLs to prevent multi-process issues.

Again, I think the process would need something like:

COMPOOL template source --> default COMPOOL + COMPOOL template
COMPOOL mission instance source --> mission COMPOOL + COMPOOL template

Since the template is the same for the COMPOOL we just need it once. Since we use a C++ implementation, the template should better be a C++ header file. The mission COMPOOL is then a matter of taste. a plain binary file would be enough since we can simply address it as object in C++ and just need to deserialize it for the class. Of course, we could then also simply create a XML template for mission COMPOOL instances. But since we also need to get the data into the mission editor, it might make sense to compile the COMPOOL there, create the needed data structures for creating mission data in a format that works best for the mission editor and just let SSU parse and validate a simple line-wise text file: 32 character variable identifier, 16 characters for subscript, 16 for the value, 15 reserved for extensions, one character as checksum. The basic components for describing the COMPOOL as C++ "user model" would then handle the parsing. And with user model, I mean C++ classes that describe HAL/S data types in a COMPOOL in a way that makes it easy to use them in C++ algorithms. Ideally it is just the HAL/S code with C++ syntax.
Hmmm, why are we talking about "mission COMPOOLs"??? As we only have one version of software, the COMPOOL stuff is fixed, and the only thing that changes are the initial values. So IMO we just need a file with the I-LOADs, and that should work both for COMPOOL and internal module variables.
If I understand you correctly, but maybe only partially, you want to have separate COMPOOLs and implement them as classes? I thought of that a few days ago, but somehow "pCOMPOOL_GNC_whatever->varPOS" doesn't look much better than "WriteINTEGER( SCP_POS, 4 )", even though it would provide "direct access" to the variables. ...I ran out of brain power to write more...


Quote:
Originally Posted by Urwumpe View Post
 Also the memory configurations matter a lot, but I can understand why you rather want to have a "one MC for all" solution.
Everything matters, but I don't want to spend tons of time on this as I still have a big list of TODOs: A/L to finish, some work in the HUD, and then TAEM and Entry, plus CRT displays, and let's hope getting the new things to the IDPs isn't hard because I don't want to work those busses now.
Anyway IMO we should push the DPS architecture as far as it is needed, otherwise we'll spend years just setting up shop, and then we'll still have to code the software to use it.

My head hurts.... and I feel like I did nothing today...
GLS is offline   Reply With Quote
Old 07-21-2018, 07:49 PM   #1919
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Well...... you know how a classic linker works, right? I think the one used for the PASS Software was called PILOT (DaveS might correct me)

When I write MISSION COMPOOL, I meant the COMPOOL object file used for creating the tape image for this mission, which is written on the MMU tape.

Thats how it works - especially in GNC, there are no configuration files, no data files. everything is hardcoded into the binary data (memory overlay) that is loaded from tape into the GPC memory. In SM, there are at least configurable tables, that are still hardcoded into the memory overlay, but easier to prepare for the mission.
Urwumpe is offline   Reply With Quote
Old 07-21-2018, 09:16 PM   #1920
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 Well...... you know how a classic linker works, right? I think the one used for the PASS Software was called PILOT (DaveS might correct me)

When I write MISSION COMPOOL, I meant the COMPOOL object file used for creating the tape image for this mission, which is written on the MMU tape.

Thats how it works - especially in GNC, there are no configuration files, no data files. everything is hardcoded into the binary data (memory overlay) that is loaded from tape into the GPC memory. In SM, there are at least configurable tables, that are still hardcoded into the memory overlay, but easier to prepare for the mission.
Yes, I know inside the shuttle it was all 0s and 1s. But before, in the code-writing part, there might have been one, or several, I-LOAD lists. I have difficulty believing there wasn't some sort of centralization of all those constants.
Regardless of all that, we can't compile a dll for each mission (at least I don't think we can, or it wouldn't be easy), so the changeable parts (the I-LOADS) have to be defined somewhere and loaded at run-time.
As for the COMPOOLs, they don't need to be user defined, so we define that in the code, period. IMO we could/should have a tool to generate one or several headers with the COMPOOL variable names and stuff for scenario load/save.
Now, the "I-LOAD stuff" and the "COMPOOL stuff" intersect when I need to index the X0 variable (steep aim point) with the IGI variable, so I get the correct number. X0 is I-LOAD and must be in a COMPOOL, as it is also needed for TAEM (and maybe for Entry) Guidance. This prompts me to change the SimpleCOMPOOL to incorporate I-LOAD loading, and while at it add the load/save to it as currently things are saved by the SimpleGPCSoftware classes and that isn't a good arrangement.
Until the shuttle source code is made public, I don't think we should worry much about knowing HAL/S, but maybe follow variable sizes and types is a good idea for consistency with whatever logic parts we find here and there.
GLS is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 01:05 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.