Make MechJeb F.A.R. aware
Aquilux opened this issue · 10 comments
I'd like to officially request that MechJeb be made aware of the effects of having F.A.R. installed. To deal with variable drag based on flight geometry I suggest having MJ alter its' predictions based on the current drag coefficient as calculated by F.A.R.
For aerobraking and max. G prediction before entering the atmosphere purposes I suggest including a yaw/pitch/roll from surface motion entry and using this information to request a drag coefficient from F.A.R.
I suggest including this sooner rather than later, considering that it won't be long before squad themselves replace the "placeholder" aerodynamics model before the game is considered "done". When this happens these changes will need to be made anyway, and in my opinion it'd be easier to implement this ability before additional development is layered on top of what is already in MJ's code.
I'll put my +1 here. FAR drives MJ bonkers. Just get a jet, and tell MJ to Initiate a hold, and let the wobbles commence. On that note, the stock ASAS seems to go nuts as well.
[Edit] Considering how many people seem to love FAR, Squad may decide to use FAR as the template, if they don't just get Ferram to let them use FAR's code wholesale. So getting MJ to be FAR aware would probably go a good way towards making any future updates work out of the box with mostly minor adjustment at that point.
1° There is a plugin that add FAR compat to MJ. Search for my post in FAR or MJ thread. BUT for now this plugin may cause small disruption in FAR model with specific plane configuration.
It only let MJ aware of the control surface, but with that MJ stops wobbling.
2° Easier said than done. FAR does not allow to query it for drag coef when given speed/attitude/altitude. FAR can only give it's current state while in flight. I submitted some patch to ferram and he added them in FAR 11, but it's still not enough to do that without disruption of the FAR model.
I want to do it since I play with FAR. But I already spent a lot of time on it, and right now I don't know how I'll handle reentry the simulation with current FAR code.
Just curious, but is it possible to ask the FAR dev(s) to allow it to return the information needed if queried? I may be out of date, but I'd imagine it wouldn't be overly complicated, perhaps return() the value, store it, and make it accessible via some API?
I need to make a proper post about FAR integration and why it's harder than expected.
The FAR dev has already made some change I asked for and is willing to do more it it helps. The problem is that most of FAR is stateful, so I can not ask for "how much drag would I get if the ship was moving at this speed and turned this way" without changing how the ship currently fly.
For some operation I can save the state, do what I need to, and then restore it.
But for some other I can't do that. For example the re-entry simulation run in a separate thread, so if I can not save/query/restore data without totally destroying the flight model. I have some idea on how to overcome this but I don't know if they'll work until I try them.
Ahh ok. I'd you need another guinea pig, could make an alpha branch (so
doesn't interfere with main builds) on the Jenkins. I'm used to testing
things, so I don't mind. Live that you are using Jenkins, wish more would
do that.
This message was sent via phone. Please excuse any typos, as my phone loves
to 'autocorrect' to the wrong words.
On Dec 9, 2013 7:27 AM, "sarbian" [email protected] wrote:
I need to make a proper post about FAR integration and why it's harder
than expected.
The FAR dev has already made some change I asked for and is willing to do
more it it helps. The problem is that most of FAR is stateful, so I can not
ask for "how much drag would I get if the ship was moving at this speed and
turned this way" without changing how the ship currently fly.
For some operation I can save the state, do what I need to, and then
restore it.
But for some other I can't do that. For example the re-entry simulation
run in a separate thread, so if I can not save/query/restore data without
totally destroying the flight model. I have some idea on how to overcome
this but I don't know if they'll work until I try them.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/187#issuecomment-30127987
.
Right now that code live in a extension dll for MJ : http://forum.kerbalspaceprogram.com/threads/60933-Optional-MechJeb-Modules
You just need the current MJ dev version and MechJebFARExt.dll
tagging #1052
FARExt ain't bad, but I have to say the button to make MJ2 use stock SAS is still key.
FARExt on its own, on the B9 Haldeman, diverges on altitude hold at 18k, slowly opening up in oscillation until it stalls.
With 'Use Stock SAS', it holds to less than +-10m.
I really think the solution is to have FARExt included, but as a separate dll, and make the dll unload itself if it cannot find a compatable version of FAR.
