-
Notifications
You must be signed in to change notification settings - Fork 250
/
Plans.txt
163 lines (114 loc) · 7.98 KB
/
Plans.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
* Engines new thrust curves
* Replace the Ressource loaded Shader used by the arrows by an AssetBundle
DONE * Docking port can now double as decouplers
* Module mass modifier to check
* Check the use of Time.FixedDeltaTime vs TimeWarp.FixedDeltaTime/esselState.deltaT
* Stop the throttle limiter from limiting when min thrust = max and other related case for RO
* prevent the node execution flipping
* finish node on RCS
* Redo the config load/save to ignore the deep config Node issue and remove the clumsy hack I added in 1.x
* Convert to VesselModule
- Turn MechJebCore into its own PartModule
- Need load/save calls. wait for KSP 1.1 ? Or use the old PartModule config (might be necessary to keep backward compat)
- Improve the PartModule order problem. MJ would always run after/before all the module (check which)
* Configurable "Forward" vector (VTOL, Shuttle)
- Gimbal rest correction to lower torque
* Check if adding the current accel is needed to handle RCS properly.
- Require the VesselModule convertion to be finished
* Redo whole UI to use Unity "new" UI
* Split MJ in multiple DLL (core info / Basic AP / Landing / ...) ?
* Check the Launch at interplanetary window code to make sure the returned value are stable (it was not the last time I looked into it)
* KeyBinds for some call (Smart ASS, ...)
- Use Attribute to make a call bindable ?
* Bring Back LUA and/or Python
- see https://github.com/gfoot/kopiluainterface
* Landing Guidance
- Option for re entry attitude
- Option for re entry orbit shallowness
DONE - long sim ( 1 orbit ) ?
DONE - In view landing trajectory ?
* Landing Sim
DONE - Object pool to lower memory pressure
- FAR support
- RealChute Support
DONE - Lifting body ? (check how they work now)
* Way to recreate the basic info windows without deletying the whole config
* Convert to PartModule
DONE - Turn MechJebCore into its own PartModule
- Can we do all necessary cleanup in OnDestroy?
Should work, though there are times that strong references are kept around and the part becomes a zombie. We should move cleanup to it's own function and call it from OnDestroy, register on Vessel.OnJustAboutToBeDestroyed and wherever else looks good.
- Turn the classes that handle part animations into separate PartModules
* Split up MechJebCore?
Core has the following parts:
- GUI
DONE - ComputerModule callbacks
DONE - stuff that figures out which MechJebCore is controlling the vessel
DONE - attitude controller
DONE - thrust controller
DONE - warp controller
DONE - autostaging controller
- settings saving
DONE (mostly) * Split existing modules into ComputerModules and DisplayModules
* Explicit support for third-party ComputerModules and DisplayModules?
* New settings system? The old one works reasonably now, but N3X15 coded some functions to work with setting a bit better, may be worth trying... And we could work something in for Vessel-specific saving too.
- Does N3X15's PluginConfiguration actually have any benefits over our SettingsManager?
- for vessel-specifc info the OnSave/OnLoad ConfigNode system is worth trying; it
should save any vessel-specific info we have directly to the SFS
* New GUI
- Protractor-like icon?
Look for a 2D artist
- Choose either a new GUIStyle or create one from scratch.
* Customizable info-windows: make lists with all the variables/titles, and allow the user to build his own windows
- possible implementation: define an InfoItem class with virtual two methods:
- void DrawItem() to draw the info item within a GUI window
- string GetDescription() to get the description to show in the list of possible info items.
Then make a little subclass of InfoItem for each possible item to display.
This seems like it would be pretty flexible, but perhaps a separate class for each item is too bulky.
It would let us use reflection to find all InfoItems, though.
DONE * Add a system for DisplayModules to easily have in-VAB GUI windows
DONE - Maybe just a drawEditorGUI() in addition to drawGUI()?
- Figure out good way to make sure settings are saved if they're modified in the editor
(OnUpdate/OnFixedUpdate don't get called there, and that's where MechJebCore used to save settings)
We should move to Update/FixedUpdate on the core (which runs independent from the Part being active), to avoid all kinds of problems
DONE * Change (most) orbital operations to create maneuver nodes
- Split orbital operations into:
DONE - A calculation class that computes required burns for operations
- This class can be reused elsewhere, e.g. by the landing autopilot
- A ComputerModule that performs operations under autopilot
DONE - A DisplayModule that creates maneuver nodes for operations
* Make the Core control more streamlined, and add RCS translation control
DONE * Create PartExtensions and VesselExtensions classes
DONE (mostly) * Allow a "no-autopilot" mode (enabled/disabled via part.cfg?)
- Requires separating all autopilot functionality from information displays
- Split Ascent Stats into its own ComputerModule
DONE - Split landing AP simulations from autopilot
DONE - Split orbital operations dV calculations from autopilot
DONE (mostly) * Move everything in ARUtils somewhere else:
DONE - Move staging functions into staging controller
DONE - Move vessel-related functions into VesselState and VesselExtensions
DONE - Move part-related functions into PartExtensions
DONE - Move random utilities into MuUtils
DONE * Finally figure out multithreading to offload the FuelFlowAnalyzer and landing autopilot simulations to their own threads
DONE - Then make separate ComputerModules just to do the simulations. Other classes can
DONE turn these ComputerModules on or off. When they're on they periodically rerun the simulations
DONE and update their results, which other classes can read off.
DONE Check out the old MechJebModuleAscension.cs/optimalAscent.cs for a threaded implementation of a module, it works well enough (the threading, the calculator isn't very good XD)
DONE * Add a check that will throttle down to prevent overheats during any sort of autopilot operation
- Moved ascent AP code into thrust controller
DONE * Allow auto-staging during any sort of autopilot operation
DONE - a toggle like in the ascent AP, but in the main menu?
DONE We need an options screen, but we may want to add the auto-staging thing in multiple places so the user can disable it as needed? Maybe having some options directly in the menu may be indeed an option.
* Move Core (ThrustController) landing function into landing autopilot, since nothing else uses it?
* Have a "factory restore" button for all settings? (that just deletes the settings file?)
DONE * Split ascent AP path into a separate class & a separate display module to edit ascent paths
- Then add a type of ascent path that evalutes a user-entered C# or Lua expression
DONE - Add a Computer/DisplayModule to provide ascent path guidance on the navball, but no autopilot
* Add a guidance version of the docking autopilot that just gives suggested velocities
- I'm thinking: a Texture2D velocity gauge for each coordinate, with mark for the desired and actual velocities
- Maybe also a 2D graphical display of the lateral position & velocity
- Implementation: A switch in the docking autopilot that determines whether it actually sends commands to the RCSController?
DONE * Automatic orbital rendezvous and docking
DONE - Automatic orbital rendezvous can just auto-execute the steps from the Rendezvous Guidance module
* DisplayModule interface to the RCSController
* If there are any tunable parameters in the attitude controller, expose them to the user somewhere so
they can play with the tuning.