Jump to content

Optional MechJeb Modules for FAR, NEAR & km_Gimbal 2/3 (July 16)

sarbian

By sarbian
in KSP1 Mod Releases

 Share

Recommended Posts

Wanderfound

Wanderfound

Posted
Posted
I fixed the "breaks due to the new version number" (Also called rewrite half the code) and MechJebFARExt should now work for FAR v0.14.4

I found and fixed a big bug too.

MechJebNEARExt needs some love but I can't do more today.

Thanks.

Loving the new Surface Smart ASS modes, by the way. The horizontal velocity is very handy for VTOL flight and zero-atmosphere horizontal landings.

Link to comment
Share on other sites
Einarr

Einarr

Posted
Posted

Sarbian, I apologize for my previous post. It was not meant to motivate, but more to express displeasure at not being able to use the latest FAR. I remember a time back in 0.23.5 when the MJ RPM plugin needed to be recompiled each time MJ's version number changed, and it couldn't be used with dev builds. For whatever reason, I thought the solution would be simple and quick to implement.

Thank you for your hard work and continued development of these plugins.

Link to comment
Share on other sites
  • 3 weeks later...
Ruedii

Ruedii

Posted
Posted

Ippo yep, seems it's not working right now. There were some changes in FAR (again), and it may need a little more than a recompile (again).

Sometimes build versions aren't a issue sometimes they are. After all mono libraries are dynamically linked, so only if there are actual changes in the API do they need to change such libraries. Sadly, this is often the case.

Link to comment
Share on other sites
King Arthur

King Arthur

Posted
Posted

My apologies for asking this Sarbian, but you'd be the most knowledgable about this than anyone else. Is the km_gimbal extension still compatible with the update to km_gimbal and the SSE pack that you pushed out just a while ago?

Many thanks for maintaining all these mods, gratitude cannot be adequately stated in mere words. :)

Link to comment
Share on other sites
sarbian

sarbian

Posted
  • Author
Posted

No, it will need an update. I'll most likely keep the current one (needed bu the current B9) and add an other for the renamed module I now maintain for SSE. Hopefully B0 will switch to the new one.

Link to comment
Share on other sites
sarbian

sarbian

Posted
  • Author
Posted

Youens was OK with me using the code before he made it MIT. As I stated before I need time to do it and right now free time to code is not something I have. Doing it require adding an abstraction layer to MJ landing sim code and that is time consuming.

Furthermore I hurt my back this morning so I'll most likely spend most of the week in bed, and not the the fun kind of "in bed" :(

Link to comment
Share on other sites
Errol

Errol

Posted
Posted (edited)

I seem to be having some weird phantom control issues while using this with FAR and MJ. At first I thought MJ was broken because SASS just wouldn't work. I just noticed that my craft is actually recieving control input all the time, as if it has SAS with a pilot on board all the time, until I can activate and de-activate SAS. The same is true even if SAS isn't available on the vessel, such as a vessel with only a stayputnik probe core. I posted in the MJ thread about it, and here's what someone had to say about my log (https://www.dropbox.com/s/uv5vulnwdgtr433/mjbug.txt?dl=0):

You're getting a lot of errors from MechJebFARExt.dll (Sarbian's FAR extensions for MJ)

An error at just the wrong time could prevent other functions from being called.

Not sure how your new observations fit into this...

But what I suggest is removing the FAR Extensions and seeing if the problem persists. Or see if there's an updated version of it.

Something else I noticed was a lot of RT errors, but that's a discussion for their thread. I enclose the error below: (the log said it was version 1.5 but there was an AVC log entry indicating it downloaded 1.5.2)


NullReferenceException: Object reference not set to an instance of an object
  at kOS.SteeringHelper.GetThrustTorque (.Part p, .Vessel vessel) [0x00000] in <filename unknown>:0   at kOS.SteeringHelper.GetTorque (.Vessel vessel, Single thrust) [0x00000] in <filename unknown>:0   at RemoteTech.FlightComputer.updatePIDParameters () [0x00000] in <filename unknown>:0   at RemoteTech.FlightComputer.OnFixedUpdate () [0x00000] in <filename unknown>:0   at RemoteTech.ModuleSPU.FixedUpdate () [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

So, coles notes of what I shared over there was that when I get the bug my vessel still responds to my control input. It's just that MJ's SASS appears to be unable to fully utilize the reaction wheel torque and my vessel simply bobbles on the spot. Same with RCS turned on. It's not a craft design issue; these craft work in one instance, then not in the next. At first I thought the bug only occurred when jumping into a vessel as opposed to loading and launching it, but it appears at least somewhat more randomly then that. I am using updated FAR, DRE, RT, MJ and this, as well as the USI suite and a few other convenience/LS/part mods. I have posted about these errors in the RT thread as well.

EDIT: Is this still only supposed to work with the dev version of mechjeb?

Edited by Errol
Link to comment
Share on other sites
Galane

Galane

Posted
Posted

Can you do one for Stock Drag Fix?

What I've noticed with SDF and Landing Guidance is MechJeb tends to under-burn on the initial deorbit, then it has to make a fairly large correction, often it overcorrects and has to make more correction burns. I've had it make so many correction burns (usually with larger, slower turning rockets) that it overshoots KSC and either lands or "lawn darts" into the ocean. SDF has such an effect on landing guidance that with a quick turning craft it can precisely miss the VAB and land in front of it on the pad side every time. Pad landing attempts with SDF tend to end up at the bottom end of the ramp toward the VAB.

All SDF is doing is removing fuel/oxidizer mass from the stock drag calculations, but it seems to confuse Landing Guidance because the rockets don't have as much drag as they're supposed to with stock aero. (Though they have as much drag as they "should have" since fuel inside a tank has no bearing on how much friction their is with the air outside the tank.)

There's not a real problem with Ascent Guidance, rockets use less fuel with SDF, though I've had some rockets where terminal velocity is hit (the text turns green) but it's not throttling back and I get the red heat effects. Probably would use even less fuel if it would throttle back at TV with SDF.

On bodies without atmosphere, SDF does nothing.

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
Can you do one for Stock Drag Fix?

What I've noticed with SDF and Landing Guidance is MechJeb tends to under-burn on the initial deorbit, then it has to make a fairly large correction, often it overcorrects and has to make more correction burns. I've had it make so many correction burns (usually with larger, slower turning rockets) that it overshoots KSC and either lands or "lawn darts" into the ocean. SDF has such an effect on landing guidance that with a quick turning craft it can precisely miss the VAB and land in front of it on the pad side every time. Pad landing attempts with SDF tend to end up at the bottom end of the ramp toward the VAB.

All SDF is doing is removing fuel/oxidizer mass from the stock drag calculations, but it seems to confuse Landing Guidance because the rockets don't have as much drag as they're supposed to with stock aero. (Though they have as much drag as they "should have" since fuel inside a tank has no bearing on how much friction their is with the air outside the tank.)

There's not a real problem with Ascent Guidance, rockets use less fuel with SDF, though I've had some rockets where terminal velocity is hit (the text turns green) but it's not throttling back and I get the red heat effects. Probably would use even less fuel if it would throttle back at TV with SDF.

On bodies without atmosphere, SDF does nothing.

Any inaccuracy is going to be due to resource consumption which will render earlier predictions invalid. You're not taking into account inertia. Less fuel means drag has more impact on the craft.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...