"We don't make mistakes, just happy little accidents."
Well, here's another... :lol:
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* :uhh:
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.