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

Mokmo

Mokmo

Posted
Posted (edited)

Toolbar support... Tells me to delete the dll because the MechJeb build (218, today's) supports it.

But no icons show although i kept all the image files, so where should they be ?

EDIT: They're in the full pack! I only fetched 218 dll ! Problem solved

Edited by Mokmo
Link to comment
Share on other sites
loppnessmonsta

loppnessmonsta

Posted
Posted

so i got this to work finally by deleting MJRPM. i think there might be a conflict there. anyway, is there a way to completely hide the mechjeb window on the right? or turn it into a free-floating window? i hate having it there because it's always in the way of my Resources.

regardless, this is fantastic. Thanks!

Link to comment
Share on other sites
  • 2 weeks later...
JeffreyCor

JeffreyCor

Posted
Posted

It seems MM 2.0.3 is causing MJ to not be able to control ship direction any longer or in combination with the latest FAR. Throttle responds as expected but control systems don't move (tested using assent function). MM 1.5.7 with FAR 1.3.2 does not have this problem.

Link to comment
Share on other sites
JeffreyCor

JeffreyCor

Posted
Posted
Sarbian, today's FAR update seems to have further broken the FARExt plugin.


method not found: ferram4.FARWingAerodynamicModel.GetStall

@jeffrey: I have no problem with MJ and MM 2.0.3

MJ with FARext, new FAR, and MM 1.5.7 worked, the same with 2.0.3 did not. However, MJ without FARext, new FAR, and MM 2.0.3 did work. It looks like a problem with then combination together, or yet another problem overall with things going weird in MM 2.0.3

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
MJ with FARext, new FAR, and MM 1.5.7 worked, the same with 2.0.3 did not. However, MJ without FARext, new FAR, and MM 2.0.3 did work. It looks like a problem with then combination together, or yet another problem overall with things going weird in MM 2.0.3

No. Absolutely not. This is in NO way a Module Manager issue. You really need to understand how Module Manager works, and when it works.

It does all its work at one time when the game first starts up before you even get to the main menu. At that time it goes through every single config node (that the game has already loaded up) and looks for config nodes that can't possibly have been parsed by KSP because of their unique Module Manager syntax. Things like '@MODULE[ModuleEnginesFX]{<stuff>}'. It splices things in or removes things as directed. And then it's done. Barring attempts at the debug menu to reload the database it will not execute again.

It's not capable of the sort of interaction where it might cause one plugin from calling another's 'methods'. Perhaps

  • FAR no longer defines the method in question or the method is private now or has otherwise changed how it's accessed.
  • Or has changed enough that Sarbian's FAR Extension simply requires recompiling.

But not because of Module Manager. It simply does not work that way.

Link to comment
Share on other sites
JeffreyCor

JeffreyCor

Posted
Posted

Well that is the result of what actually happened regardless of any ranting of things not being possible you want to put. You don't need to understand Module Manager to understand troubleshooting or conflicts.

Link to comment
Share on other sites
NathanKell

NathanKell

Posted
Posted

This is because stuff in the new FAR breaks with old modulemanager, so of course it's going to behave differently (and in particular, the problematic functions error out before returning, or don't get called). What's *actually* happening is that FAR switched to its functions needing and returning doubles, but MJFarExt expects floats, and so you get problems.

Use latest FAR (.13.2), latest MJ dev build, and delete MJFarExt, which is not up to date and is therefore broken.

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
Well that is the result of what actually happened regardless of any ranting of things not being possible you want to put. You don't need to understand Module Manager to understand troubleshooting or conflicts.

I'm sorry you want to call it a rant but coincidence does not equal causality.

Link to comment
Share on other sites
goldenpeach

goldenpeach

Posted
Posted

I confirm.

I *think* the latest dev build fix(238)(or maybe it's the fact that I redownloaded the v2.2 of mechjeb and used it) the problem for the autopilot(didn't tested for the other modules) but the FAR support break it.

The problem is that mechjeb don't control the attitude anymore. It only control the thrust.

Link to comment
Share on other sites
JeffreyCor

JeffreyCor

Posted
Posted (edited)
I'm sorry you want to call it a rant but coincidence does not equal causality.

Not only was it shown to be a combination of the plugins to cause the problem, MM had a critical update as well addressing further problem. Given this I call it what it is and and your statements to in fact be wrong. I believe it is long past time for the end of the useless response you posed to be dwelled on.:mad:

Edited by JeffreyCor
Link to comment
Share on other sites
TheWampa

TheWampa

Posted
Posted

Just delete the Mechjeb FAR plugin. It just adds some control surface info in Mechjeb, but Mechjeb will work just fine with FAR installed and without the optional module.

Link to comment
Share on other sites
JeffreyCor

JeffreyCor

Posted
Posted

That is exactly what I did, and the new version of MM since 2.0.3 fixed all other problems being experienced so they are all working very well together. Though of course Starwaster will view it to only be a coincidence.

Link to comment
Share on other sites
goldenpeach

goldenpeach

Posted
Posted
Just delete the Mechjeb FAR plugin. It just adds some control surface info in Mechjeb, but Mechjeb will work just fine with FAR installed and without the optional module.

I did that, but the mechjeb FAR plugin give the correct terminal velocity(without it, I saw a terminal velocity of more than 1km/s on a rocket); I would like to have it in order to make more efficient launches

Link to comment
Share on other sites
AndreyATGB

AndreyATGB

Posted
Posted
I did that, but the mechjeb FAR plugin give the correct terminal velocity(without it, I saw a terminal velocity of more than 1km/s on a rocket); I would like to have it in order to make more efficient launches

You won't touch terminal velocity with FAR. You can always use FAR Data for that if you insist.

Link to comment
Share on other sites
  • 5 weeks later...
Jivaii

Jivaii

Posted
Posted
You won't touch terminal velocity with FAR. You can always use FAR Data for that if you insist.

I seem to hit high dyn pressure well before hitting terminal velocity. Fortunately I can lock MechJeb into limiting my acceleration to 18 m/s and staying both below terminal and that high dyn pressure

Link to comment
Share on other sites
NathanKell

NathanKell

Posted
Posted

High dynamic pressure is meaningless for rockets. Of course you're going to hit it. The question is, are you losing more to drag than you're gaining in lowered gravity losses? The answer is, 99.99% of the time, NO.

Link to comment
Share on other sites
Ratzap

Ratzap

Posted
Posted
High dynamic pressure is meaningless for rockets. Of course you're going to hit it. The question is, are you losing more to drag than you're gaining in lowered gravity losses? The answer is, 99.99% of the time, NO.

Maybe that is what it should be doing but I have a number of rockets currently that will break due to high dynamic pressure (generally at the first decoupler) if taken more than 2 or 3 degrees from vertical in lower atmosphere. It's not really a problem since I know what is causing it from the log message and avoiding it is easy enough but it will break rockets if you're not careful.

Link to comment
Share on other sites
timmers_uk

timmers_uk

Posted
Posted
Yes, I need to fix it but It always seems to slip my mind ...

Hey,

If you're interested (and I can get my head around GIT), I took a quick look at the MechJebFARExt plugin to see whether I could do anything to stop mechjeb playing Disco Stu with my control surfaces under FAR - it looked to be pretty straightforward - just a couple of vars in FAR going from float to double, and one of the fields which was protected/private being visible again.

Probably quicker for you to do the fixes directly than deal with a pull request (is that the word in GIT land? I'm more an SVN/Perforce person ... heck I used to be an SCCS/RCS/VisualSourceUnSafe person), but I can give it a poke if you want.

I'm 99% sure it is as working as the old version was, before FAR changed - the last 1% because a spaceplane I was having trouble with in orbit was doing persistent crazy stuff when given simple SmartASS commands, but I think that had more to do with something wierd with the ship, as I've not seen it repeated.

Timmers

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