whitespacekilla

I made another Kopernicus pre-release. This one includes the tidy up KSC debris + Remove launch sites bug fix that is already integrated into the main Kopernicus repo (but currently unreleased) and a fix to the significant map view performance issue @Poodmund, @DarkGod, and @DuskFall have described. Again - please don't use this unless you know what you're doing. You will not receive support installing, removing, or using an unofficial pre-release. This unofficial prerelease ships with a version number of 1.4.5-999. https://github.com/marr75/Kopernicus/releases/tag/1.4.5-Alpha5-2 I'd be interested in hearing from Poodmund if this improves the situation as drastically as removing the orbital icon customization entirely (it should). I don't have a reliable FPS indicator on my dev install and my "play" install will never hit 165fps for other reasons...

Yes, I knew this and I even created a custom MM config to tweak `reactorSpeedMult` such that all engines with a long spin up and cool down are slightly more responsive (I much prefer a long range probe that doesn't depend on solar and has a little extra thrust even if it's a little more expensive, but, I don't think careful maneuvers of complex engines adds much to gameplay when applied to every long range probe, I think it's a very interesting trade off for a more important vessel like a mothership or some kind of grand tour vessel). If I need to cheese a very precise maneuver, I will just disable the engine entirely. This problem is different in a couple of ways from that: It's present for, as far as I can tell, an infinite time period It stops during warp but resumes out of warp It's only affecting the apoapsis of the orbit, not inclination or periapsis The effect is constant whether the ship is oriented orbital prograde or retrograde disabling the engine has no effect My custom mm config for reactor speed mult, btw, is: @PART[*]:HAS[@MODULE[InterstellarFissionNTR]]:FOR[WarpPlugin] { @MODULE[InterstellarFissionNTR]:HAS[#reactorSpeedMult[<1]] { improvement = 1 @improvement -= #$reactorSpeedMult$ @improvement *= .5 @reactorSpeedMult += #$improvement$ } } @PART[*]:HAS[@MODULE[InterstellarPebbleBedFissionEngine]]:FOR[WarpPlugin] { @MODULE[InterstellarPebbleBedFissionEngine]:HAS[#reactorSpeedMult[<1]] { improvement = 1 @improvement -= #$reactorSpeedMult$ @improvement *= .5 @reactorSpeedMult += #$improvement$ } } @PART[*]:HAS[@MODULE[InterstellarTokamakFusionReactor]]:FOR[WarpPlugin] { @MODULE[InterstellarTokamakFusionReactor]:HAS[#reactorSpeedMult[<1]] { improvement = 1 @improvement -= #$reactorSpeedMult$ @improvement *= .5 @reactorSpeedMult += #$improvement$ } } @PART[*]:HAS[@MODULE[InterstellarMoltenSaltReactor]]:FOR[WarpPlugin] { @MODULE[InterstellarMoltenSaltReactor]:HAS[#reactorSpeedMult[<1]] { improvement = 1 @improvement -= #$reactorSpeedMult$ @improvement *= .5 @reactorSpeedMult += #$improvement$ } } @PART[*]:HAS[@MODULE[InterstellarFissionMSRGC]]:FOR[WarpPlugin] { @MODULE[InterstellarFissionMSRGC]:HAS[#reactorSpeedMult[<1]] { improvement = 1 @improvement -= #$reactorSpeedMult$ @improvement *= .5 @reactorSpeedMult += #$improvement$ } } That should find all the engines with multipliers lower than 1 I knew of at the time and improve them "half the distance to 1" but I wouldn't claim my MM syntax mastery to be perfect. I believe those configs worked without issue at some point. It was a little inconvenient that MM doesn't know anything about the inheritance of the modules it modifies, but this is certainly not your problem or something I think MM can easily address. Related question, would it be possible for technology upgrades to improve reactor speed multipliers? This could be an interesting mechanic since not only do the engines become more "powerful" they also get easier to use.

@singlet have you tried Part Commander? I can see making that menu work on smaller screens being out of the realm of possibility. After updating to the most recent version (I hadn't played in a couple weeks so it looks like there might have been multiple increments) I'm getting tiny amounts of phantom thrust (only really apparent when the orbit is highly elliptical) on an existing craft with a LANTR. I'm going to try new craft and rolling back to the last known working version to narrow the problem a bit but given that persistent thrust was added to these engines, and it stops in warp, my suspicion is that a bug was introduced with that change.

@FreeThinker workin' hard to address every issue I've seen raised in support or dev forum. Good stuff in these releases.

Shows what I know, I've been playing with this mod pretty intensely and have never seen that functionality work. I don't know that I would consider the candle a high-ISP engine, though. It's nuclear, so it's middle of the pack.

Yes, that is normal (though it's inconvenient that instead of refusing to warp, it kills thrust). You heard wrong. Physical warp (2, 3, 4, "alt+.") only unless you use TimeControl (has a more complicated hyperwarp functionality that tries to match a speed you input but will slow down if your computer can't handle it) or BetterTimeWarp (configurable multipliers) for rails and physical warp is a little more brutish and simple but has some bugs and will destroy your ship / perform your burn improperly if you are attempting too high a physical warp. Supposedly, much older versions of KSP had a persistent thrust mod that would calculate orbit changes while the vessel was unloaded/on rails but AFAIK this is not an option in modern version of KSP.

PR is submitted. Until there's a new Kopernicus release, you have 3 workarounds (in order of recommendation): Turn "Tidy Up Debris Surrounding KSC" off in system settings for KSP (the bug is actually triggered when attempting to evaluate if a vessel should be cleaned up) Play without ever leaving ANY vessels in a state where they might be considered cleanable debris, i.e. landed, no command, etc. (KIS aggravates this as it can result in more "vessels" that fit this description, but it's certainly not the only way an object that could be cleaned up might be left lying around) Use my forked Kopernicus pre-release (PLEASE DON'T DO THIS UNLESS YOU KNOW WHAT YOU'RE DOING, YOU WILL NOT RECEIVE ANY SUPPORT INSTALLING, USING, OR REMOVING THIS NON-RELEASE) available here: https://github.com/marr75/Kopernicus/releases Edit: I have gone ahead and taken this down as the PR is integrated into mainline Kopernicus, there's no further testing or confirmation needed, the bug has been around awhile, and compiling for yourself or turning off tidy up debris are good enough alternatives until the next release CC: @Nayah- @Jebs_SY @AnyoneElseWhoEncountersThisBug

So, fun stock bug that Kopernicus can trip up on with its "removeLaunchSites" configuration (which GPP uses) detailed in the quote above (from the GPP thread). I think it can be fixed in `Kopernicus.RuntimeUtility.Start` LN267ish by digging a little deeper into the internal storage of the launch sites and removing from both lists (`PSystemSetup.Instance.StockLaunchSites` and `PSystemSetup.Instance.LaunchSites`). If I don't hear anything to the contrary I will probably submit a PR to fix later tonight (I'm innocent to the ways of the Kopernicus issue and bugfix workflow though so please forgive me if I overstep). UPDATE: PR Submitted https://github.com/Kopernicus/Kopernicus/pull/306 CC: @Thomas P. maybe?

CC: @IgorZ@Nayah- @Pleb it's a stock bug (see: https://bugs.kerbalspaceprogram.com/issues/19510), as I stated (probably in too abstract a manner?). Nayah-'s report confirms that KIS is not the only way to trigger the bug. Before a lot of events can be finished (scene switch, vessel switch, save, exit, load) the code runs a check to see if a vessel is landed in a stock launchsite (not important why it does this, just that it does). There's a mistake in the loop such that it is effectively: for (int i = 0; i < someLaunchSites.Count(); i++) { if (someItemOfInterest = differentLaunchSites[i].SomeItem) { // ArgumentOutOfRangeException thrown here for obvious reasons // do some stuff } } This code is guarded by a clause that requires the expansion be installed and the two different lists of launch sites will be incidentally identical (thus having the same length and avoiding the AORE) if you avoid making certain edits. Update: remove launch sites is really what activates the stock bug here and that's not even GPP functionality, that's Kopernicus functionality. I'm going to see what the Kopernicus devs think and they can either correct on their own or I'll research a fix and make a PR. Any luck this might be fixed for Kopernicus users soon.

Thanks, I'll take a look tonight! Your fork first caught my attention with the battery support, when I find out you had other little gems floating around in local branches I just got more and more curious and the terrainnormal was too specific an ask to pass up ;-)

Just remembered I dropped in originally to say how excited I am to see what the GPP team does with the Kopernicus orbital icons feature!

@Jebs_SY @Galileo I put a bug in for this very issue https://bugs.kerbalspaceprogram.com/issues/19510, the fix can't be distributed but maybe a mod that manipulates launch sites can patch it (kind of hacky, I know, but if someone wants to be a hero). Honestly, traces back to that "performance" recommendation (with dubious results) of switching foreach loops to for loops. Very hard to introduce this bug with a foreach loop... I believe KIS/KAS aggravates the bug by relatively quickly changing the vessel list for the game. I do not see any reason it would activate the bug (as the bug itself is a for loop iterating through a different data structure than the one accessed inside the loop).

@Starwaster any chance you can push your branch of BV where you correct the rover's rotation to Github? Your snippet depends on "GeoUtils.GetTerrainNormal" which I believe you also implemented (it's not in any version of BV I can find online) and a PQS/terrain pleb like me is going to have a really hard time getting this right. Best (only?) example of calculating terrain normal I can find is https://github.com/CYBUTEK/KerbalEngineer/blob/master/KerbalEngineer/Flight/Readouts/Surface/Slope.cs line 68. Don't know if it'll help @maja correct it in the official, too, but it might.

@Arrowstar seems likely it's more specific than just multiple stars. GPP + GEP works fine but stock + OPM + TWB doesn't work. Would it be that playing with "The World Beyond" results in a setup with no common/root orbit? I changed my setup so won't be adding TWB back in to debug for awhile (there's a couple multiple star/non-kerbin setups I'd like to patch first) but if you don't beat me to it, I might contribute some source code back to KSPTOTconnect. I love using this tool, keep up the good work!

I was actually asking if you had or knew about any other fixes floating around outside of official releases for GPP compatibility issues since I merged your fixes to have a better GPP + CC experience. I named some examples of fixes I was planning to develop myself after LGG asked which mods (I copied LGG and Maja because they both asked a question in regard to my previous). I think LGG probably just misunderstood me because they have a lot of mods to maintain so in most interactions someone is talking about one of their mods (this situation is unique in that most KSP mod code LGG produces is for mods they maintain), not asking if LGG has any other GPP pertinent fixes floating around. I also only started on topic (by thanking the providers of compatibility patches I adopted and compiled into my own setup) and then quickly got off topic. LGG made it clear they're not interested in this particular conversation so I bumped the post and considered the matter concluded. Once I've coded and tested the patches I need for my setup, I'll see if they're useful to anyone else and distribute them in a manner in keeping with license/author's wishes so the need to converse with other modders who make little compatibility patches for the game overhaul we play with isn't as necessary as I imagined when I first posted.

Topic title made me imagine a ship with Kerbals lashed to the front for use as heatshields ala Reavers in FireFly. What you actually meant is a good idea but still, am disappoint.

I find, debug, and fix errors in my own install based on both logs almost every week. The correct output log would be helpful but the sheer volume of CollisionFX errors in your logs is not going to do you any favors (the game is spending a lot of time and resources just logging those). There's also many ProgressParser errors in there I think DMagic fixed in his latest release. You've got a lot of mods and they don't seem to be designed such that you chose THE BEST MOD to improve any particular aspect. Example: you have [x] science and science alert. [x] science churns memory pretty hard (it creates thin wrappers around just about every object it needs rather than just using the objects as they are and it loops through the bodies, biomes, and experiments frequently without preserving past work or using events) so I'd be loathe to have it open at the same time as another mod that detects science situations. I'm betting you don't have an up to date 1.4 fork of Ven's stock revamp, also (the most easily found ones were updated for 1.2 or 1.3). If you're not a modder, you really need to only use mods that are maintained by someone. I'd recommend updating to 1.4.5, re-evaluating whether you *need* every mod on that list carefully, and checking each and every one of them for an update. If you cut mods with parts or bodies in them, you will probably lose ships. If you don't, you generally won't. Places to search for updates for each mod: forum, curseforge, spacedock, github, forks on github. That's a lot of work, so cutting mods cuts how much work it takes to keep the list in good shape. Netkan kind of does this for you but many mod authors aren't bought into it (because mod management in KSP is just file management...) and often the metadata is just updated (or not) by a 3rd party. Netkan works best for lightly modded setups with popular mods.

Well, possible upshot, FreeThinker does accept pull requests with graciousness and poise and some of what you're outlining is just moving files or writing descriptive text...

BonVoyage doesn't work with multiple stars (it snags the first celestial body and calculates from there) and HyperEdit doesn't appear to be able to do any surface manipulations on Gael. cc: @maja @linuxgurugamer

@Pleb @linuxgurugamer I just switched over to GPP and encountered the same issues as both of you. Really appreciated your fixes! They were hard to find and obviously required building from source and I think there's probably a large population of users who might benefit. My 2 cents. On a related note, I'm going to be working through some things in Bon Voyage and Hyperedit to make them work better with GPP/Kerbin replacement planet packs, if for no other reason than I want them to work for me. But, if you've stumbled across or created your own fixes for these problems, it would keep my "meddling with other peoples' mods" todo list a lot shorter...

@etmoonshade probably a good idea, I keep a backups of the zip archives of all my mods and my first step for a KSPIE release is to extract, delete the extras (which I don't want or want to get direct from the source) and re-archive. I think this will be a little more time intensive that it might sound, and it can't leave novice mod users out in the dark without the minimum they need to enjoy the mod or they'll just uninstall. Tweakscale could actually be refactored to be a softer dependency while if you don't have IFS or CRP and haven't procured some other method of filling in the fuels these engines need, you'd be SOL. All to say, KSPIE is a big project and unknotting / repackaging these dependencies is a bit of an ask, you might have to be the change you want to see in the world. Also, PersistentRotation and KJR Kraken my vessels to pieces so are banned from my install and TU with any wide reaching configuration makes it so that I can only enter or exit the VAB a limited number of times before I get an access violation crash. Besides, it requires you run in d3d11 or opengl which is a pretty big ask for an optional mod that comes with a fairly unrelated mod.

@eddiew there's a fix for this in an unreleased commit in the GPP github repo. I think a new version is coming out soon to complement 1.4.5 kopernicus update but if you want the config fixed now: https://github.com/Galileo88/Galileos-Planet-Pack/blob/master/GameData/GPP/GPP_Configs/GPP_Strategia.cfg btw, @nightingale, GPP makes very cool use of Strategia and Custom Barn Kit. Could probably feature in your OP as an example of what's possible.

@OhioBob GPP and GEP work for me using Kopernicus LandControl fix (and there were no bugs beyond the pink shader that I could see before that) so that's at least one data point that the plan you lay out will go just that smoothly. Sounds like TWB might need a release (haven't tested myself so could be pbkac error). Anyway, I wasn't speculating on any particular planet pack, just the general state, i.e. be kind to your mods' authors, don't pester them, follow their advice if you want things to work. Btw, the unreleased fixes already available in the GPP repo are working nicely for me and I feel a lot better about using Strategia on my new career with the creases ironed out. Keep up the great work!

@4x4cheesecake no prob. Wasn't at all trying to chastise or dissuade you, I just can't predict how long until the planet packs update and I don't want my observation to encourage anyone to pester the planet pack modders.

@4x4cheesecake I had the same GPP, pink Gael issue as you. I fixed it for myself just now but a) I made 2 updates at the same time and don't know which one really contained the fix b) it requires you to build Kopernicus from source c) I don't know what new issues are introduced d) if the Kopernicus build from source fixed the issue, we should all consider Kopernicus 1.4.5-1 a "release to manufacturer" so to speak and generally not assume it will work for ANY planet pack until the planet pack author tells us otherwise. The two things I did to fix: - Pulled latest kopernicus, it has a PQSLandControl patch that sounds pertinent. Built it (there's no release available) replaced my Kopernicus dlls. - Pulled latest GPP, the only pertinent update to the gael pink shader problem I could see was that the gael planetary cache was updated. You don't need to be able to build to apply this fix. Just download https://github.com/Galileo88/Galileos-Planet-Pack/blob/master/GameData/GPP/Cache/Gael.bin and replace your version with that one. To cut off any controversy discussing iterations of mods not supported by their authors might cause: this is COMPLETELY unsupported. Don't ask any of the mod authors about any of this. Don't start an argument on this board or any other board related to this post or fix, yadda yadda yadda. Anyway, I'm playing a stable 1.4.5 with correctly colored Gael right now after only those two adjustments. 1.4.3 with GPP was crashing frequently for me, this is probably because I took a circuitous route to GPP with 1.4.3 because I had been playing stock + opm + TWB on 1.4.5 with a debug build of Kopernicus before. I don't see why anyone else who wants to use ANY planet pack should switch to 1.4.5 right now if your 1.4.3 game functions in any sense of the word. PS as a developer who frequently digs into the source and even history behind KSP mods, I gotta say, the Kopernicus and GPP teams are a cut above. Be cool to them. Update: can confirm it was the Kopernicus build, everyone's gonna have to sit tight for a patch release