Jump to content

[1.3.x, 1.4.x, 1.5.x, 1.6, 1.7] MechJeb and Engineer And kOS forAll


Recommended Posts

@mrvice

GameData\MechJeb2 Embedded\MechJebEmbedded.cfg

all from start

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA]]:NEEDS[MechJeb2]:Final
{
	%MODULE[MechJebCore]
	{
		%MechJebLocalSettings
		{
			%MechJebModuleCustomWindowEditor { %unlockTechs = start }
			%MechJebModuleSmartASS { %unlockTechs = start }
			%MechJebModuleManeuverPlanner { %unlockTechs = start }
			%MechJebModuleNodeEditor { %unlockTechs = start }
			%MechJebModuleTranslatron { %unlockTechs = start }
			%MechJebModuleWarpHelper { %unlockTechs = start }
			%MechJebModuleAttitudeAdjustment { %unlockTechs = start }
			%MechJebModuleThrustWindow { %unlockTechs = start }
			%MechJebModuleRCSBalancerWindow { %unlockTechs = start }
			%MechJebModuleRoverWindow { %unlockTechs = start }
			%MechJebModuleAscentGuidance { %unlockTechs = start }
			%MechJebModuleLandingGuidance { %unlockTechs = start }
			%MechJebModuleSpaceplaneGuidance { %unlockTechs = start }
			%MechJebModuleDockingGuidance { %unlockTechs = start }
			%MechJebModuleRendezvousAutopilotWindow { %unlockTechs = start }
			%MechJebModuleRendezvousGuidance { %unlockTechs = start }
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[FlightEngineerModule],!MODULE[KerbalEVA]]:NEEDS[KerbalEngineer]:Final
{
	MODULE
	{
		name = FlightEngineerModule
	}
}


career mode

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA]]:NEEDS[MechJeb2]:Final
{    
	%MODULE[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 }
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[FlightEngineerModule],!MODULE[KerbalEVA]]:NEEDS[KerbalEngineer]:Final
{
	MODULE
	{
		name = FlightEngineerModule
	}
}

 

Link to comment
Share on other sites

53 minutes ago, mrvice said:

wait.... do we have a missunderstanding here?..... should this mod not replace mechjeb completly? 
i thought you just continued it and updated it for the latest version but i think i missunderstood this mod.

This mod does not replace MechJeb. Its just a Module Manager patch for command pods, so that you don't have to add the Mechjeb part to your craft. You still have to have MechJeb installed.

Link to comment
Share on other sites

  • 5 weeks later...

There is also a mod "kOS for all", which adds GameData/XyphosAerospace/Tweaks/kOS-CommandPod/kOS-CommandPod.cfg:

@PART[*]:HAS[@MODULE[ModuleCommand]]
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 100000
		ECPerBytePerSecond = 0
		ECPerInstruction = 0.000004
	}
}

My comments:

  • @PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[kOS]:Final
    is better than 
    @PART[*]:HAS[@MODULE[ModuleCommand]]
  • The diskSpace is smaller, and I actually prefer a smaller diskspace in command pods, and I'll have to add a real computer core part if I want something bigger.. But that is personal preference of course
  • ECPerBytePerSecond = 0
    is the default value anyway, so can be left out.
  • ECPerInstruction = 0.000004
    is also the default value.

So what am I going to do:

  • Uninstall "kOS for all".
  • Change the diskSpace value in GameData/MechJebForAll/MechJebAndEngineerForAll.cfg
Link to comment
Share on other sites

  • 1 month later...

Hi guys,

is there a chance to get a Mechjeb Verion for 1.6.1 or is this the end of the lifetime of this mod ?

Honestly said this would be a "knock out" criteria for me for anything above version 1.5 as especially docking and landing is, if one has done it several times, becoming boring and I never was able to land as precise as Mechjeb. And frankly said, if one is able to fly to the Mun, the civilisation should be able to produce a computer that can automate certain things. Of course starting in Kerbal is good as it currently is.  A good way to learn. But as from a certain level on there should be something like MechJeb.

Anyway thanks a lot to Sarbian and LinuxGuruGamer.

Edited by JoeeoJ
Link to comment
Share on other sites

  • 3 weeks later...
20 hours ago, Ahmed Kerman said:

doesnt work in 1.6.1, gives the warning on game launch and even though it is still working in making any vessel have mechjeb, any manned vessels will require a pilot, which is frustrating, i never realised how much i needed this mode before

What warning?  I'm using it without any problems in 1.6.1

Please provide a log file 

Link to comment
Share on other sites

  • 2 weeks later...

 I find myself in need of guidance, if you could spare a moment of your time. In my career playthrough I'm using mechjeb, and mechjeb/engineer for all. I have decided that in my game, I want the mechjeb rover autopilot window to be available when my first true rover bits start to appear, for my game, with my mods, that's in space Exploration tech. I've edited the mechjeb config to support this. The rover tech shows up in the tech tree at the correct spot, and any rover I build that has the actual mechjeb case part on it, has the rover autopilot window available. However parts that do not contain the mechjeb parts, but contain mechjeb abilities from this mod, do not. I have gone into the mechjeb and engineer for all mod, Kerbal Space Program/Gamedata/Mechjebforall/mechjebandengineerforall config file, and changed the following line: MechJebModuleRoverWindow { unlockTechs = spaceExploration } < spaceExploration being where I want the roverwindow to appear, but as I said above, it's not working. Could you point me to what I've missed? I've cleared the module manager cache, and let it load fresh, just to be sure that isn't wrongly applying old settings, but no dice. Thank you for any help.

EDIT: I discovered there was another file in the main mechjeb folder, Mechjebnocommandpod config, that also needed changed to reflect my changed position on the techtree, and now all command pods are getting the rover autopilot control window. Sorry to bother.

Edited by vardicd
Link to comment
Share on other sites

9 hours ago, linuxgurugamer said:

No problem @vardicd, I'm glad you found the issue.

Can you post your solution for others to see?

 

the file in {Kerbal Space Program/Gamedata/Mechjeb2/parts/Mechjebnocommandpod} has backup configs for the mechjeb mod, you'll need to open that file, edit it in my case, change :

MechJebModuleRoverWindow { unlockTechs = Fieldscience } to: MechJebModuleRoverWindow { unlockTechs = spaceExploration }

I don't entirely understand why this file in mechjeb has an effect on Mechjeb and engineer for all, but it seems too, and in my testing failing to adjust here, whatever you adjust in the main mechjeb2_ar202 config will throw off mechjeb and engineer for all.

 

Link to comment
Share on other sites

  • 1 month later...

kOS for all settings seems to be overpowered, especialy early in career game. At least to my personal preference.
Is there a way to tie kOS integration in command module with respect of regular kOS part unlocked trough tech tree ?

It would be better to tie with specific part, if possible, rather then tech tree node, because of diffrent placement of parts in various science tree node available for career. That way would be easier to maintain compatibility.

For example, if I have unlocked KR-2042 CPU, I got it's values integrated in command module. When better part is unlocked then values of better part is integrated in command module up to best part available KAL9000.

Issue is that early part of career game is overpowered with integrated kOS while at same time in late career game when you have unlocked most of parts and have unlimited weight/size/part count on launchpad/runway it become tedious to add kOS CPU on each craft.

Link to comment
Share on other sites

3 hours ago, kcs123 said:

kOS for all settings seems to be overpowered, especialy early in career game. At least to my personal preference.
Is there a way to tie kOS integration in command module with respect of regular kOS part unlocked trough tech tree ?

It would be better to tie with specific part, if possible, rather then tech tree node, because of diffrent placement of parts in various science tree node available for career. That way would be easier to maintain compatibility.

For example, if I have unlocked KR-2042 CPU, I got it's values integrated in command module. When better part is unlocked then values of better part is integrated in command module up to best part available KAL9000.

Issue is that early part of career game is overpowered with integrated kOS while at same time in late career game when you have unlocked most of parts and have unlimited weight/size/part count on launchpad/runway it become tedious to add kOS CPU on each craft.

This mod is basically just ModuleManager configs, is that right?

If so, is it possible to have ModuleManager detect how complex the SAS settings for the probe core can be, and trigger different variants of the kOS module settings based on that?  The probe cores that let you do stability SAS only are typically lower on the tech tree than the ones that let you do prograde/retrograde lock, which are lower than the ones that let you do normal/antinormal, and so on, so this might work as a generic trigger that will also work on probe cores from mods too (rather than having to make it hardcoded by probe core name, which wouldn't accommodate mods well.)

 

Link to comment
Share on other sites

10 minutes ago, Steven Mading said:

This mod is basically just ModuleManager configs, is that right?

If so, is it possible to have ModuleManager detect how complex the SAS settings for the probe core can be, and trigger different variants of the kOS module settings based on that?  The probe cores that let you do stability SAS only are typically lower on the tech tree than the ones that let you do prograde/retrograde lock, which are lower than the ones that let you do normal/antinormal, and so on, so this might work as a generic trigger that will also work on probe cores from mods too (rather than having to make it hardcoded by probe core name, which wouldn't accommodate mods well.)

 

Yes, it is only MM config and currently looks like this:

@PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 10000000
	}
}

Yes, it would be nice if it is not hardcoded by part name, so it can work with probes from other modes, not only stock module commands.
Also, my personal preference on this is to not have kOS inside of maned command modules. On craft with several maned command modules kOS CPUs raise too quickly even when you don't need one.

Thinking more about it, probes that are capable of holding prograde/retrograde are earliest that should be capable to have kOS equivalent KR-2042 CPU built in. Probes with normal/antinormal ability might even be able to have KAL9000 CPU integrated. At that point of playtrough craft mass is no longer of ultimate importance as well as craft part numbers, so it becoming just unnecesasry obstacle in late part of game playtrough.

Have no idea how to write down such MM patch,for myself, though. Have yet learn a lot more about MM syntax.

Link to comment
Share on other sites

OK, I think I have found solution that is more balanced trough career game, regarding kOS for all config:

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],@MODULE[ModuleSAS]:HAS[#SASServiceLevel[3]],!MODULE[kOSProcessor]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 300000
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],@MODULE[ModuleSAS]:HAS[#SASServiceLevel[2]],!MODULE[kOSProcessor]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 20000
	}
}

So, higest end probes have build in kOS disk of 300000. That is slightly more than KAL9000, most powerful kOS CPU part. And with tweakscale you can extend capacity even more if you need it. Midlle level probes have capacity of 20000. This is double than heaviest kOS CPU offer. So, this patch does not exlude kOS parts completely, but makes late game playtrough slightly less tedious, without need to add any kOS CPU on craft.

Edited by kcs123
Link to comment
Share on other sites

2 hours ago, kcs123 said:

OK, I think I have found solution that is more balanced trough career game, regarding kOS for all config:


@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],@MODULE[ModuleSAS]:HAS[#SASServiceLevel[3]],!MODULE[kOSProcessor]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 300000
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],@MODULE[ModuleSAS]:HAS[#SASServiceLevel[2]],!MODULE[kOSProcessor]]:NEEDS[kOS]:Final
{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 20000
	}
}

So, higest end probes have build in kOS disk of 300000. That is slightly more than KAL9000, most powerful kOS CPU part. And with tweakscale you can extend capacity even more if you need it. Midlle level probes have capacity of 20000. This is double than heaviest kOS CPU offer. So, this patch does not exlude kOS parts completely, but makes late game playtrough slightly less tedious, without need to add any kOS CPU on craft.

wouldn't it be simpler (and more efficient) to use MM math to set the diskSpace?

 

something like this:
  diskSpace = 10000
  diskSpace *= $SASLevel$

(module manager pseudo code) (and depending upon MM math handling - might set SAS0 to 0 diskSpace)

 

just a thought. @kcs123

Edited by zer0Kerbal
Link to comment
Share on other sites

5 minutes ago, zer0Kerbal said:

wouldn't it be simpler (and more efficient) to use MM math to set the diskSpace?

 

something like this:
  diskSpace = 10000
  diskSpace *= $SASLevel$

(module manager pseudo code) (and depending upon MM math handling - might set SAS0 to 0 diskSpace)

Didn't think about using that, to be honest I'm new with MM syntax and it is only 3 levels of SAS. I see few issues in your aproach.

SAS0 actualy don't exist, there is missing variable for those probes in part config file. That would also add kOS CPU on craft with 0 disk space that is almost useless, can't put even boot file on it. It would only create more confusion as you would need additional CPU on that craft. I don't desire CPU on that probe level at all.

Second issue, it is not linear function. Highest level is set to 300,000 while second is 20,000. I have choose "3" and "2" multiplications to easier check out MM patch within game, not necesasry have to stay like that. So, if anyone want to tweak it further, I think that it would be easier and more understandable for noobs to just change exact number to desired level.

Thanks to let me know about possible other solutions, might be more useful in one of my other personal MM patches that I started to create for myself.

Link to comment
Share on other sites

  • 2 weeks later...
39 minutes ago, ZEROX said:

would it be possible to make it unlocked trough tech tree? lso it would be a upgrade trough the tech tree(unlocked with the mechjeb pod) ?

I'm not certain is it possible to achieve that only trough MM patches. I don't know if MechJeb have something hardcoded in plugin or it use only data from config files is something is unlocked or not. If it require additional piece of code in kOS plugin, then no, it is not possible. Only if that can be done trough MM patches and config files.

There is issue with unlocked tech tree node logic. It can only work with stock and maybe Ctt tech tree. Other tech trees might be unbalanced. Therefore, I have followed Steven's advice, to bind this to probe SAS level.

 

Link to comment
Share on other sites

  • 4 months later...
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...