Jump to content

[PART, 1.0.2] Anatid Robotics / MuMech - MechJeb - Autopilot - Historical thread


r4m0n

Recommended Posts

Thought it over and you need to use '%name' as well.

@PART

[*]:HAS[@MODULE[ModuleCommand]]

{

%MODULE

{%name = MechJebCore}

}

Are you sure? I've tested the first one, and I don't seem to get double MJCores on MJ parts.

Link to comment
Share on other sites

I had an idea while assembling a space station; it would be nice if I could execute a maneuver node using translational RCS.

Basic reason being that it can be downright problematic to quickly change the attitude of a complex structure, not to mention the CoT/CoM issues all being compounded by asymmetrical arrangements.

General idea is that while executing a maneuver node mechjeb holds the current attitude steady (does not turn to face the maneuver node) and uses the RCS in smart translation to meet the node's vector. Primary purpose I'm thinking of currently is station keeping for stations and satellites that need judge a few nudges here or there to account for docking perturbations, etc.

That is very interesting idea. One of those things you don't realize you need until someone mentions it. I hope the modder(s) take(s) it up.

Link to comment
Share on other sites

Another idea: A true gravity turn mode for ascent guidance.

A "true" mode would cause the craft to pitch to a user set angle, at a user set altitude, and from that on would follow prograde on the pitch plane the craft's pitch reaches a (you guessed it) user set final angle. Steering for the yaw plane would (hopefully) work as normal.

I suppose some sort of crude analysis tool pulling data from the craft's Delta-V chart in order to determine optimal launch profile for each individual rocket would be too much to hope for. :P

Link to comment
Share on other sites

Anybody? nobody? somebody must know

Maybe this will help.

- Open the file: GameData\MechJeb2\Plugins\PluginData\MechJeb2\mechjeb_settings_global.cfg

- Look for "MechJebModuleAscentAutopilot", line 22.

- Find "_autostage = False", and change the value to "True"

- ?????

- Science!

I hope that helps. :)

Link to comment
Share on other sites

Maybe this will help.

- Open the file: GameData\MechJeb2\Plugins\PluginData\MechJeb2\mechjeb_settings_global.cfg

- Look for "MechJebModuleAscentAutopilot", line 22.

- Find "_autostage = False", and change the value to "True"

- ?????

- Science!

I hope that helps. :)

Nope, not that one, Thank you though

Link to comment
Share on other sites

Hey, I got a question. So I'm trying to mod the Mechjeb Ar202 thing so I unlock it at the start of my campaign, and so it has all the modules and functions on it initially as well. When I try to mod it so all the unlocktech fields are set to start, and then load up the game and start a new campaign, it shows that I can't get them in the VAB OR SPH. Any help to get this right? Btw, I like how you put the mechjeb parts in the current unlock places, but I like them unlocked from the start cause I can't fly very well. If I could get help to get it unlocked at start with all its functions unlocked at start as well, I'd appreciate it.

Link to comment
Share on other sites

New set of fix. This time it looks like everything is working as intended. As a bonus I fixed the menu movement when MJ is rescaled (not sure if anyone but me saw that one) and you can move the menu in the editor too now (hold and drag button with right click, as usual).

If nothing bad is found I'll release a new version with those fix and then I can restart work on features (and play other games).

Link to comment
Share on other sites

Wow!....This thread activity has been BUSY the past coupe days!!...

I just read through all the posts since 12/14, before the 0.90 vers dropped....

I am sticking with 0.25.

So I'm just wondering whats the latest dev build that will work with 0.25? I see all the changes in #360, and would like to run at least that version, but I see its for 0.90...??

Thanx a BUNCH for all you've put into MechJeb, Sarbian. :D

PS- I noticed the last couple days, that the windows will widen (a couple almost went 3/4 across my screen), because of text wrap not working? Is that what you meant in your last post?

Edited by Stone Blue
Link to comment
Share on other sites

Are you sure? I've tested the first one, and I don't seem to get double MJCores on MJ parts.

What it will do is created a 2nd 'name' variable in the module and hid the 1st one. They'll have the same value. Minor issue but because 'name' is used to access the modules via MM scripts, it could cause issues.

Edited by Jacke
Link to comment
Share on other sites

Are you sure? I've tested the first one, and I don't seem to get double MJCores on MJ parts.

The best way to avoid duplicate modules when using MM is to add the !MODULE parameter like so.


@PART
[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final
{
MODULE
{
name = MechJebCore
}
}

Or if you want to preserve tech tree progress when adding MechJeb to all command modules.


@PART
[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final
{
MODULE
{
name = MechJebCore
MechJebLocalSettings
{
MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
MechJebModuleSmartASS { unlockTechs = flightControl }
MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
MechJebModuleNodeEditor { unlockTechs = advFlightControl }
MechJebModuleTranslatron { unlockTechs = advFlightControl }
MechJebModuleWarpHelper { unlockTechs = advFlightControl }
MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
MechJebModuleThrustWindow { unlockTechs = advFlightControl }
MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
MechJebModuleRoverWindow { unlockTechs = fieldScience }
MechJebModuleAscentGuidance { unlockTechs = unmannedTech }
MechJebModuleLandingGuidance { unlockTechs = unmannedTech }
MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }
MechJebModuleDockingGuidance { unlockTechs = advUnmanned }
MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }
MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }
}
}
}

Link to comment
Share on other sites

I mainly play in Ubuntu 14.04 and when using MechJeb in both the 0.25 and now 0.90 beta releases using MechJeb causes an immediate crash to desktop upon staging of any kind. I cannot reproduce the bug in Windows.

Is this a known bug?

Link to comment
Share on other sites

I mainly play in Ubuntu 14.04 and when using MechJeb in both the 0.25 and now 0.90 beta releases using MechJeb causes an immediate crash to desktop upon staging of any kind. I cannot reproduce the bug in Windows.

Is this a known bug?

If you can provide logs that would help immensely in figuring out the problem.

Link to comment
Share on other sites

personally still waiting for the thing to be updated officially for .90 as i am not a coder, i feel very skittish about mucking about in code, best to leave it to the mods current author imho.

Link to comment
Share on other sites

What it will do is created a 2nd 'name' variable in the module and hid the 1st one. They'll have the same value. Minor issue but because 'name' is used to access the modules via MM scripts, it could cause issues.
The best way to avoid duplicate modules when using MM is to add the !MODULE parameter like so.


@PART
[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final
{
MODULE
{
name = MechJebCore
}
}

Or if you want to preserve tech tree progress when adding MechJeb to all command modules.


@PART
[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final
{
MODULE
{
name = MechJebCore
MechJebLocalSettings
{
MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
MechJebModuleSmartASS { unlockTechs = flightControl }
MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
MechJebModuleNodeEditor { unlockTechs = advFlightControl }
MechJebModuleTranslatron { unlockTechs = advFlightControl }
MechJebModuleWarpHelper { unlockTechs = advFlightControl }
MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
MechJebModuleThrustWindow { unlockTechs = advFlightControl }
MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
MechJebModuleRoverWindow { unlockTechs = fieldScience }
MechJebModuleAscentGuidance { unlockTechs = unmannedTech }
MechJebModuleLandingGuidance { unlockTechs = unmannedTech }
MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }
MechJebModuleDockingGuidance { unlockTechs = advUnmanned }
MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }
MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }
}
}
}

You guys do god's work. I'm ashamed to receive such attention, and thankful to have such effort done. Thank you very much for your time. :)

Messing with the MM codes are really fun, and understanding them properly is even more.

Speaking of which, out of curiosity, would you care to explain what does the ":Final" term affects there?

And how different would the result be if I replaced that comma by an "&", between ModuleCommand and MechJebCore on the top?

And finally... What's the difference between "@PART

[*]:HAS" and "PART:NEEDS" (as found in the wiki)? Thank you once again!

Edited by Kowgan
Link to comment
Share on other sites

:Final means the patch is run after all other patch are done. It's a good idea for user made patch as it avoids that your patch is undone by a mod patch.

The comma and "&" works exactly in the same way, you can replace one fo the other. I find the comma a bit easier to read since you can't add space

@PART[*]:HAS check if the part currently has some specific content (Module, value, ...).

PART:NEEDS make the patch run only if a specific plugin or mod is installed. It's so a patch does not run if that mod is not present

Edit : apos I see nothing bad in the log. Crash of the game are not often really created by the mod but by other factor. MJ may just trigger something less commonly used in the game. Did you have a look at the Linux thread ?

Edited by sarbian
Link to comment
Share on other sites

@Sarbian: Thank you very much, that was very clarifying.

@CardBoardBoxProessor: I think Sarbian does, although it's not said in the OP.

-edit-

Sarbian, I noticed you've packed two files into the last dev builds. The complete mod and the MJ dll. Does that mean the only modified file is that DLL, and if we're updating, we don't need to replace the whole folder - but instead, only that single file?

Again, your effort is much appreciated. I won't ever get tired of saying this. :)

Edited by Kowgan
Link to comment
Share on other sites

Anyone else experiencing maneuver node editor window popping up for every new launched vessel even though I never opened it manually since 0.90 update (and started a new save if it affects anything; though I kept old MJ window config)?

Link to comment
Share on other sites

I just now tested MechJeb Rendezvous Planner, Rendezvous Auto-pilot, and Auto-Docking, using dev build #366. It was a thing of beauty.

In an earlier post, I mentioned that the released version of MJ/Rendezvous_Auto-Pilot did not fire rockets when it was supposed to do so. This time, each firing was on-time and for the right duration.

Auto-Docking was flawless. It not longer continuously spewed mono-prop and trying to adjust itself. It fired RCS three times: once to place itself in position for docking, once to go forward to dock, and once to cut closing speed when bumping the target. Perhaps I just happened to balance my vessel perfectly with RCS jets. I doubt it; I placed the RCS jets at CoM of a full tank. By the time I got to docking position, that tank was half empty. Regardless, MJ-AutoDock handled it. Total monoprop used: 20

I'm still using SMART A.S.S->TGT->-Par for docking, but I wanted to test MJ/Auto-Dock with KSP 0.90 and dev build #366.

Awesome work, guys!!!

Edited by Apollo13
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...