schlosrat

You might try the MechJebForAll mod. https://spacedock.info/mod/1854/MechJebForAll This is what I use to ensure all my command pods have MJ functionality.

After some playing around with it I think I've determined the MechJeb scripting engine simply can't be used for my purpose. It seems there are zero ways to record a variable or do any math (other than what's done for you behind the scenes in the various MechJeb modules). I'm sure it's fine for a lot of things, but this limitation is... well... rather limiting! I've switched gears and moved over to using kRPC and python scripts to control my Brachistochrone trajectory. One cool thing with the kRPC is that it's possible to also use it to send commands to MechJeb! This is really nice since the kRPC autopilot suffers from considerable lag compared to what SmartASS can do in game. I'll be posting my kRPC script on GitHub soon and will post a link back here if anyone is interested. Since it does employ MJ for establishing and cleaning up the final orbit at the destination as well as making use of MJ to control the vessel pointing during the flight maybe it's at least somewhat relevant here. The SW I'm using is kRPC 0.4.9 compiled for KSP 1.12.1 along with kRPC.MechJeb 0.6.1 (which is compatible with MJ 2.8, but seems to work mostly OK with MJ 2.14, minus a few things that have changed in the MJ interface since 2.8)

I've been using it in 1.12.3 without issue

Is there any guidance / instruction / manual for the scripting module? This doesn't appear to be documented in the online manual. What I'm looking to do is set up a brachistochrone trajectory flight. Roughly what I think I want the script to do is this. With a target selected, point towards target Fly towards that target at a configured max acceleration (set via MechJeb utilities, or whatever the throttle limit is for the active engine) At midpoint cut thrust to 0, flip to retrograde, set thrust back to same level as before and begin deceleration burn to the target If the target is a planet, then attempt to enter orbit once within the SOI Set inclination to 0 at fixed time (immediately) Set periapsis to 100 km at fixed time (immediately) Circularize at periapsis If the target is a ship then attempt to perform a rendezvous with it Yes, this may produce some crazy long burns. I plan to use Better Time Warp with up to 20x timewarp to try to keep that manageable, but first I need to figure out how to program things like this in the MechJeb scripting module. Any tips?

Is it possible to use KR&D to improve the converterEfficiency for thins like Extraplanetary Launch Pads workshops similar to what can be done with drills and ISRU? I don't want to change the equation of input resources to output resources so much as I'd like to make the various parts produce things faster with KR&D upgrades. For example, the KS-WS-01-0 Construction Drone is able to take electric charge + metal and output rocket parts + scrap metal. It does this using flow rates much like an engine where instead of thrust we have part production, but the flow rate is fixed. KR&D will let me reduce the mass of this construction drone, or boost its heat tolerance, but those are the only attributes I can affect.

In a situation like this if you really really want that part one thing you could do is launch a sandbox game with tweakscale, then tweak the base (not yet upgraded) part to the size you want and observe its mass, cost, thrust, etc.. From there you can create a module manager script to copy the part you want something like this: +PART[NBlandingLeg1] { %name = NBlandingLeg1_0.75 %title = MRS 3/4 Long Landing Leg %description = A 3/4 scale large landing leg intended for modesly-sized landers, engineered by the most modest of engineers that can modestly engineer such mediocre parts. %rescaleFactor = 0.75 %scale = 0.75 %mass = 0.075 %cost = 337.5 %maximum_drag = 0.15 %minimum_drag = 0.15 %angularDrag = 1.5 } Here my objective was to create a 3/4 scale version of a particular landing leg I liked the design of, but the process is the same. Find the actual part name (it's in the part's .cfg file, and is not necessarily the same or even similar to the part title which is from a game play sense what the name is). Use a text editor to create a MM script file (add_my_new_part_foo.cfg), placing this config file somewhere in your GameData folder (I use a folder called 000_My_MM_Patches) Copy the old part to a new part (with a new name, title, description, and scaled properties): This is the "+PART[OldPartName]{...}" part where you use MM commands to override the old part's properties as needed (google module manager syntax ksp if you're not familiar with this) Launch game and use KR&D on your scaled part

Thanks @darthgently. I've been dealing with it for quite some time now, including numerous restarts of the game, changing scenes, visiting the tracking center, etc. I think the next steps are try it as the sole mod in a game to see if it misbehaves all on its own, then if not start adding my mods back in until I discover the interaction that's provoking this. If others are not seeing this in 1.12.3, then it seems most likely to be a mod incompatibility between ScanSAT and something else I'm running.

Is anyone else having the issue that the ScanSAT vessel location (as well as mouse and waypoint) are significantly offset to the East and North in detail view? By offset I mean that in the large world view it shows my vessel landed where it actually has landed, but in the detail view (the one you get from clicking on the magnifying glass or right clicking the world view) my vessel shows up significantly farther to the right and up on the map from where it actually is. For example, having landed on Tylo inside Tycho crater near the south west part of the crater you can see my vessel correctly placed on the world map, but incorrectly outside of the crater in the detail view where it shows my vessel position outside the crater on the east side and a bit north of the crater center. Similarly, when I'm in the detail view and click on the waypoint icon I get a waypoint tag to move around, but it's not colocated with the mouse pointer - instead it's significantly farther north in the view than the mouse pointer (not the same East + North offset as I'm seeing between the correct world view and the incorrect detail view). I'm running 1.12.3 and frankly a lot of mods, but no mods that mess with maps or celestial bodies AFAIK.

No worries! It's a great mod, lots of fun to play with and well integrated with the tech tree. I love all the detail put into how it reflects what's in the book. You might consider changing the name of the folder to ProjectHailKary (camel case, no spaces). This would better align with how other mods name their folders and also make it easier for anyone who wants to write module manager scripts that rely on it. Cheers!

Oh I agree! I think at one point years ago I made the mistake of giving MechJeb a maneuver command while my warpdrive was active - not effective. The thing is, stock doesn't need to know about the warp drive if it's in a different (later) stage and in a shutdown state. Stock works just fine with motor A (active) in current stage and motor B (shutdown) in a later stage, except when motor B is a warpdrive. In the example above motor A is an astrophage engine, which does have a ludicrous ISP, but is in all other respects like other drives stock does know about. This same thing happens with any other normal drive, chemical, nuclear, ion, OPT Dark Drive, etc. The weirdness is that with a warpdrive that's shutdown and in another stage, stock still can't figure out burn time for the one engine that is activated - but it does so just fine if there's no warpdrive in the vessel. Am I doing something wrong, or is everyone seeing this same effect? Maybe it's some weird interaction with one of the many mods I've got. If others aren't seeing this, then it's time for me to painstakingly cycle through tests until I find which other mod is causing this, but if it's the normal and expected thing then that would be a pointless waste of time and I'll just live with it. Yep, that's exactly what I've been doing. Stage 0 is a reaction motor, and Stage 1 is the warp drive. I use action groups to toggle between them so that both are never active at the same time, but both can be off. It's either motor A, Motor B, or no motors active.

Hey I'm getting a weird issue where any time I've got a vessel with an Alcubierre drive on it and some other "normal" rocket motor my burn times are invariably red. The vessels I see this with have an Alcubierre drive as well as another drive, and I use action groups to switch one off and the other on so that switching on the Alcubierre drive always shutdowns any normal reaction motors, and vice versa - so both are never active at the same time. With such vessels, when the normal motor is on and the warp drive is shutdown, if I plan a maneuver the burn time is shown as red no matter how much fuel/delta-V I've got. When I execute the burn it progresses normally, but the dang things shows red all the way. For ships built without a warpdrive this is not a problem and I get a green burn time indicator when I should. In the shot below you can see my vessel is almost done with its orbit circularization burn, and it's been red the whole time. The tank is nearly full with astrophage (correct fuel for the motor in use). I get this same effect with any type of reaction motor - chemical, nuclear, kerbstein, OPT DarkDrive, etc. Here's a shot that shows the ship, and shows the Astrophage engine working It appears KSP thinks the active engine has 0 deltaV (as shown in the staging on the lower left in the image above), but when I check with MechJeb it shows I've got plenty (as in 302265352 m/s, could burn for up to 238d 2h 6m 29.6s)

On a similar note, I was wanting more astrophage tanks to play with, so here's a module manager script to take every MonoPropellant tank in your game and make an Astrophage variant of it. I'm really winging it on the conversion of MonoPropellant to Astrophage, but this seems to give OK results that line up more or less well with the three tanks this mod ships. If anyone has a better sense for that conversion factor please jump in. Module Manager script to fix a few things with the "stock" astrophage tanks. Note: some parts had a category of Propulsion when they should be FuelTank, also the "stock" large tank had a cost lower than its material, as well as a backwards name ("TankAstrophage" vs. "AstrophageTank" like the other two stock tanks). // Fix the part cost for the large tank so that it's not less than the cost of the materials needed @PART[Size3MediumTankAstrophage] { @cost = 20000 // @category = None } // Rename the large tank so that it conforms the the naming scheme used on all other Astrophage tanks +PART[Size3MediumTankAstrophage]:Final { @name = Size3MediumAstrophageTank @title = Kerbodyne S3-7200 Astrophage Tank @description = A really big Astrophage fuel tank for really big missions! @cost = 20000 } // Fix the amount held in the 1.25m Astrophage tank @PART[1.25mAstrophageTank]:Final { @RESOURCE[Astrophage] { @amount = 10000 @maxAmount = 10000 } } // Fix the amount held in the mini Astrophage tank @PART[astrophageTank]:Final { @name = AstrophageTank @RESOURCE[Astrophage] { @amount = 5000 @maxAmount = 5000 } } // Fix the category and manufacturer for all Astrophage tanks @PART[*AstrophageTank]:Final { @manufacturer = Weir Technologies @category = FuelTank } This module manager script will give you Astrophage tanks as variants to all of the monoprop tanks you've got in your game - plenty to choose from to find the right fit for your craft! // Here we boldly copy each and every monopropellant tank and make astrophage variants! +PART[*]:HAS[#category[FuelTank],@RESOURCE[MonoPropellant]]:NEEDS[ProjectHailKary]:Final { // Change name @name ^= :$:_AstrophageTank: @author = RattPack // Change title @title ^= :^:Astrophage Variant of : // Change description @description ^= :^:Astrophage vairant! : @description ^= :RCS:astrophage: @description ^= :rcs:astrophage: @description ^= :MonoPropellant:astrophage: @description ^= :monopropellant:astrophage: // @description ^= :mono:astrophage: // @description = Astrophage variant adapted from older pre-existing MonoPropellant tank. Pay no attention to the old MonoProellant paint job, we ran out of money and couldn't afford to replaint it... // Change manufacturer %manufacturer = Weir Technologies // Change TechRequired %TechRequired = antimatterPower // As a wild guess, any monopropellant tank design modified to hold astrophage costs 10 times as much @entryCost *= 10 @cost *= 10 // Copy the MonoPropellant resource +RESOURCE[MonoPropellant] { @name = Astrophage // Update name of resource to Astrophage // As a wild guess, astrophage capacity is 70 times whatever the monoprop capactity was @amount *= 70 @maxAmount *= 70 } // Remove the old MonoPropellant resource !RESOURCE[MonoPropellant]{} }

Hey great mod! Loved the book, and can't wait for the movie - but in the meantime I can explore and have some fun with astrophage engines! Quick question: Was it intentional that the the MiniAstrophageEngine have the exact same mass (2.0 tones) and the exact same thrust (10000) as the larger engine? That doesn't make sense to me. The Mini has a rescale factor of 4 making it 1/4 the size in each dimension, so really it's (1/4)^3 or 1/64 the volume. How could it possibly retain the same mass and why would it produce the same thrust? The ISP should remain the same since the fuel and technology are fundamentally the same, but not mass or thrust. Also, why would the engine response time be so very slow? The engine appears to be modeled after ion engines in KSP, which do have a very slow response time of 0.5, but what would give an astrophage powered engine an even slower response time? Big chemical engines like the Mainsail have a response like 0.001 Here's a quick fix for the engines if you happen to agree. Feel free to tailor to suit yourself. I've set the mass of the mini engine to 1/64th of the main, and divided the thrust by 4 (not sure that math is OK). The response time is 10x slower than the Mainsail for both, which seems OK. //Fix the Mini Astrophage Engine @PART[MiniAstrophageEngine]:FOR[ProjectHailKary] { @mass = 0.03125 @MODULE[ModuleEnginesFX] { @maxThrust = 2000 } @MODULE[FXModuleAnimateThrottle] { @responseSpeed = 0.01 } } //Fix the Astrophage Engine @PART[AstrophageEngine]:FOR[ProjectHailKary] { @MODULE[FXModuleAnimateThrottle] { @responseSpeed = 0.01 } }

Bump for science lab alarms! Please and thank-you!

@FreeThinker back in Feb 2021 you replied to a couple users who'd seen problems with their science modules generating null reference errors and not being able to successfully transmit science. I ran across this thread googling the error message I've been getting on some parts I've been trying to make - so, not your parts - but I'm thinking you might have a thought or two for what could cause this? The error I'm getting looks like this: Exception handling event onPartActionUICreate in class ModuleScienceLab:System.NullReferenceException: Object reference not set to an instance of an object at ModuleScienceLab.updateModuleUI () [0x00000] in <46478292153440df94e04a2a2ddd1062>:0 at ModuleScienceLab.onPartActionUI (Part p) [0x00025] in <46478292153440df94e04a2a2ddd1062>:0 at EventData`1[T].Fire (T data) [0x000b0] in <46478292153440df94e04a2a2ddd1062>:0 What I've done is to simply use a module manager script to clone a part I want to use the model of, then remove the modules and resources I don't need and add in the modules and resources found in the Large_Crewed_Lab. This has worked in the past for me to make science labs, but now it's not working and I've been beating my head against it for a few days now trying variations. Since you've seen at least the same effect with a similar sort of error message I'm hoping you might have some insight into what would be a likely culprit and maybe how to approach solving this? Thanks!

Interesting. Thanks for the tip! I've found that on a Mac this can be done via System Preferences > Displays> Resolution: Scaled (the default is Resolution: Default for Display). Setting resolution to Scaled, and selecting the second largest option (has the effect of making the resolution similar to 1312 x 848), and then configuring KSP's UI Scale to 140% and graphics to 2336 x 1510 seems to work OK. The downside, and there definitely is one, is that I'm basically throwing away a great deal of the native screen resolution capability of my 2021 MBP just to get a readable font. This is a shameful way to bandaid the problem, but yes - it does get me to a point where fonts are readable. The real solution should be a native thing to KSP where UI scale correctly affects font as well as buttons, icons, etc.

No worries. I misunderstood the purpose of the mod to be something larger than it is. I think it's great that it does what it does, but to be honest the problem is really a KSP problem. I frankly think the scaling of fonts and other UI things should be a basic capability of the game and not left to modes to try to fix here and there. We've had higher resolution monitors for years now - this is not a new thing, and the stock capabilities to scale the UI fall far short of what's needed. Of course, at this point we're done seeing updates to KSP unless maybe someday KSP 2.0 should arrive - and even then I'm screwed since I play on Mac and 2.0 isn't going to come out for OSX. Thanks for all you have done! Seriously. Much appreciated.

More info. Tried again with Blizzy's Toolbar installed and found I can get to the 4ksp button in the Tracking Station - meaning I can configure ToolbarControl to have 4ksp in both stock and Blizzy's, and then configure Blizzy's to include 4ksp, resulting in the 4ksp icon being visible in the tracking center. However when I am at the launch pad with a craft and I tell Blizzy's to include 4ksp I don't get the 4ksp button then. The 4ksp button is apparently not available in the VAB at all. At no time does the 4ksp button show up on the stock toolbar no matter where I am what I do with ToolbarControl and/or Blizzy's. One thing I found disappointing is that while I can get to it in the tracking center and can choose between using the UI scaling for the game vs. scaling via the 4ksp button controls, it has no impact on the tiny text of other mods - just on the text flight scene. Don't get me wrong, it's nice to have the effect it does have - but what I was really looking for was a way to get the tiny text of other mods to be human readable without needing a magnifying glass. Case in point, I'd really like to be using KSP R&D for my endgame use of science, but that mod brings up a microscopic dialog box in the VAB where you can apply science points to improve various parts. Dang, it would be nice to be able to see what I'm doing... Bummer. Maybe in a future version of the mod it will affect the scaling of things displayed by other mods?

OK you can disregard that log. It appears that 4ksp needs ToolbarControl, which in turn needs ClickThroughBlocker. Adding those two to the list of mods installed I can now get to MechJeb in a flight scene (pobably in the VAB/SPH too thought I didn't check). However, there's still no button visible for 4ksp and no apparent way for me to change the scale of text. I've got the UI scaling set to 190% and this has no impact on text scaling, so other than MechJeb (which offers it's own UI scaling) text is nearly unreadable on my laptop. Here's the much smaller log for a test game with Mechjeb, MechJebForAll, 4kSP, ToolbarControl, and ClickThroughBlocker installed. https://www.dropbox.com/s/63j9bzd4rhmxzqy/KSP.log?dl=0

FYI, I'm see this problem with only Mechjeb, MechJebForAll, and 4kSP installed in a 1.12.3 game. Here's a log from a test where I was unable to get MechJeb to display while in the VAB. If I remove 4ksp that problem goes away. With it installed in Game Data I not only do not see a 4ksp button, I also can't access any MechJeb functionality. https://www.dropbox.com/s/63j9bzd4rhmxzqy/KSP.log?dl=0

Thanks @taniwha, I suspect that whatever change you made resulted in my needing to rotate my micropads so the yellow arrow is up - that was easily done and really trivial. The other matter (vessels dropping in ) is more perplexing. I began this 1.12.3 game by bringing in some pre-built craft of mine from KerbalX that have in the past always worked perfectly. They happen to use the FASA launch clamps since I like the look of those, and they also include ladders so my kerbals can easily get back in. Those are the only parts that should intersect the ground, and the as-built craft are being built so high up that the ladder doesn't even come close to the ground. When I strip off the FASA launch clamps and put on landing legs, then they're also built quite high, but are gently eased down to the ground. The craft I've been seeing this with are all part of a modular base set of craft that incorporate FASA launch clamps and micropads allowing easy base extension. The main parts are all PlanetaryBaseInc parts plus a few lights, radiators on some, etc. Really not a lot of parts and the root part is generally the PlanetaryBaseInc part. So far, my work around is to build my base core on landing legs, then extend using parts supported by FASA launch clamps until it's supported well enough that I can remove the landing legs if I like.

Thanks @Lisias I'm really not sure what ELHelper is. sounds like it might be a config file, but who knows. I read the post you linked and didn't see any info on ELHelper there either, other than to mention it. I've tried googling that and not turned up anything that way either. I don't think this is a mod, but it might be a config file that comes with a mod. I've tried searching in my Game Data folder and nothing is coming up that way. So far my effort has been a dead end to find this. Can you point me to where you found a reference to needing ELHelper? Was that from a log file?

Are there dependancies for this mod I should be aware of? When I've got it installed I can't find the button on the stock tool bar or on Blizzy's. I can configure Blizzy's to show it (there's a checkbox for it), but no icon appears. This is in Flight Mode. Also, this appears to be breaking MechJeb some how in that I can't get the MechJeb window to come up when this is installed. Hopefully that symptom is related to not being able to get the button to appear. Looking in my ksp.log (searching for '4k') I see these relevant entries: [LOG 02:08:16.290] Load(Assembly): 4kSP/Plugins/4kSPExpanded [LOG 02:08:16.290] AssemblyLoader: Loading assembly at /Applications/KSP_osx 1.12.3/GameData/4kSP/Plugins/4kSPExpanded.dll 4kSPExpanded v0.2.1.6 4kSP [LOG 02:08:17.011] [AddonLoader]: Instantiating addon 'Startup' from assembly '4kSPExpanded' [LOG 02:08:27.841] [4kSP] Version 4kSPExpanded, Version=0.2.1.6, Culture=neutral, PublicKeyToken=null 4kSPExpanded 0.2.1.6 0.2.1.6 a89d756e30a9895394481a91f89dadaf473f117b37a3a5127eed147978f33062 4kSP [LOG 02:08:41.626] :BEFORE[4KSP] pass [LOG 02:08:41.626] :FOR[4KSP] pass [LOG 02:08:41.626] :AFTER[4KSP] pass [LOG 02:08:41.626] :BEFORE[4KSPEXPANDED] pass [LOG 02:08:41.626] :FOR[4KSPEXPANDED] pass [LOG 02:08:41.626] :AFTER[4KSPEXPANDED] pass [LOG 02:14:58.760] [AddonLoader]: Instantiating addon 'InstallChecker' from assembly '4kSPExpanded' [LOG 02:14:58.761] [AddonLoader]: Instantiating addon 'RegisterToolbar2' from assembly '4kSPExpanded' [LOG 02:15:00.245] [GameParameters]: Loaded custom parameter class _4kSP. [LOG 11:18:04.454] [AddonLoader]: Instantiating addon 'FourkSP_TrackingStation' from assembly '4kSPExpanded' [LOG 11:18:23.256] [AddonLoader]: Instantiating addon 'FourkSP_FlightL' from assembly '4kSPExpanded' Do I have two conflicting versions of 4ksp trying to run? Why are there both 4KSP and 4KSPEXPANDED? Is that normal?

AVC is reporting that there's a 0.2.1.7 version out there, but I can't find it. Is 0.2.1.6 still the latest? If so, why would AVC be reporting there's a newer version.

Hi all, Still trying to figure out why a first vessel comes in so dang high. This happens with both vessels built using launch clamps (shown in post quoted above) and those that employing more traditional launfing gear where the vessel will appear above the survey stake and then slowly drop in a la Vessel Mover's Place Vessel. On the odd chance this was something that could be controlled via settings I've poked around a bit in settings.cfg within the PluginData folder. Is it correct to understand these are the only user configurable settings? What's making craft start so high nd then drop in? Can this be switched off to go back to the old way when needed. The settings I've found in settings.cfg look like this: UseKAC = True KACAction = KillWarp PreferBlizzy = False ShowCraftHull = False DebugCraftHull = False WindowManager { MainWindow { position = -574.324829,292.618164 visible = False } SettingsWindow { position = 0,0 visible = False } ShipInfo { position = 0,0 visible = False } } What's the SettingsWindow and how do I get that up on the screen?