whitespacekilla

I had noticed funky contract rewards whenever contract slot machine was active, so I deactivated it. Later, I researched how the game calculates recovery funds so I could submit a PR for StageRecovery (SR will now respect modifiers to recovery amounts like the stock game does) and I instantly understood where the Strategia Contract Slot Machine bug might come from. My question to anyone familiar, are you experiencing the same slot machine bug? The bug seems to be tied to modifying the reward once for displaying the contract details and entirely separately on completion but I want to make sure other people are experiencing it before I submit a PR/build a forked release. I don't think it will be all that difficult to ensure the same contract receives the same rewards modifier permanently.

No harm done to me, I've got working configs. Design question, the largest missing history nuclear engine seems like it should have a fission generator, so I added one, but it was really hard for me to discern how you decided/balanced fission generators on engines. What were your basic criteria? How'd you decide how much power converts to how much energy and which engines wouldn't get one?

@Nertea I'm not seeing the updated extras around missing history engines. I had my own customizations similar to Eridan's that I knew I might want to evaluate against the new ones so I compared fairly carefully. it seems like the described update was left out of all of the extras (at least on github, which I generally assume is authoritative). It also appears the last commit to those files was months ago.

@sarbian happy to be helpful. Your original post helped me out on Windows (to such an extent that I probably wouldn't have contributed to any mods if it weren't for your post) and steered me in the right direction for Mac. Just building on Mac OS is a little different challenge that will probably invite more questions, unfortunately. For example, I have to maintain a macos.targets file that I import into my projects only if the platform is mac. That's outside of the scope of debugging so I left it out but I really don't know how many modders will be able to put it all together. If I didn't already know a lot about msbuild, I probably would have bailed on Mac OS before I even got anything to compile. Also, this method on Mac OS seems to fail to contact the SteamAPI. I'm generally okay with that (I've never used the steam features even when playing, let alone debugging a mod) but maybe that will present a challenge for someone?

I decided I want to be able to develop on Mac OSX as well as Windows (for whatever reason) so I figured out how to make this tutorial work for Mac. I'm posting this here as much so I can find it if I need to figure it out again as for someone else's use but here goes anyway. Some items of note: KSP's files are arranged very differently in Mac OSX vs Windows and in fact they are a little "quirky", you will also be browsing inside multiple ".app" files, rendering the finder window less than useful. As a consequence, if you are not comfortable with the Mac OS terminal and paths, this tutorial is not for you and you will not succeed at it. Also, pdb2mdb does not work for PDBs produced in a portable format, which your Mac OSX compiler will almost certainly produce. You will need to either select a compiler that create its own mdb or use a debugger that can decompile on it's own (like JetBrains Rider), because so few plugin developers use Mac OSX, you won't get a lot of help navigating this issue, so besides the steps, paths, and advice I lay out here, you are probably on your own. Install the correct version of Unity (down to the patch). The current correct version for KSP 1.7.2 is 2017.1.3p1; patch releases are available here -> https://unity3d.com/unity/qa/patch-releases; non-patch releases are available here -> https://unity3d.com/get-unity/download/archive (NOT what you need at time of writing) Determine your KSP install path (for me, it's "~/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/") and the correct Unity version install path (for me, it's "/Applications/Unity/") Copy the debug UnityPlayer from your Unity install to your KSP install; As far as I know, this must be done from the command line `cp "[YOUR CORRECT VERSION UNITY INSTALL PATH ]/Unity.app/Contents/PlaybackEngines/MacStandaloneSupport/Variations/universal_development_mono/UnityPlayer.app/Contents/MacOS/UnityPlayer" "[YOUR KSP INSTALL PATH]/KSP.app/Contents/MacOS", for me, this command was: cp "/Applications/Unity/Unity.app/Contents/PlaybackEngines/MacStandaloneSupport/Variations/universal_development_mono/UnityPlayer.app/Contents/MacOS/UnityPlayer" "~/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/KSP.app/Contents/MacOS" Go ahead and rename the UnityPlayer you copied, as far as I can tell, this has no impact on whether it will work or not but it will help you differentiate the process you need to attach to, I ran the following command: mv "~/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/KSP.app/Contents/MacOS/UnityPlayer" "~/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/KSP.app/Contents/MacOS/KSP_dbg" Get this file (it's just a file named PlayerConnectionConfig with contents "listen 3247424759 1 1" if it ever stops being hosted) sarbian provided and put it in the Data directory (it makes the mono debugger starts its listening port, otherwise when you are browsing unity processes to attach to, you will see KSP but it will tell you it's not accepting debug connections); for me, this copy command was: cp "~/Downloads/PlayerConnectionConfigFile" "~/Library/Application Support/Steam/steamapps/common/Kerbal Space Program/KSP.app/Contents/Resources/Data/" Ensure your toolchain will create an MDB for your plugin or select an IDE that doesn't require MDBs; this article from the team at JetBrains helped me understand what I needed to get an MDB file when compiling on Mac OS; if you use monodevelop , the mono included with your unity install will be used so this will be automatic, if you use rider or some other IDE, you will need to set your Mono executable path to the one provided by Unity, I do not know how to do this for VS on Mac and will probably not learn, it's easier to solve than any of the other items of information in this post though so, if you give up before figuring that out, you were probably going to give up anyway *shrug* Launch the debug unity player, the command for me was: cd /Library/Application Support/Steam/steamapps/common/Kerbal Space Program/KSP.app/Contents/MacOS && open KSP_dbg Run whatever command your IDE uses to attach to a Unity process. i.e. in MonoDevelop, supposedly it's "Run" > "Attach to Process", Select "Unity Debugger", find the process, in Rider (what I currently use) it's "Attached to Unity Process...". Select the KSP process and attach.

Nope. Your method of negating a module before editing / creating it again in module manager patches is sound. Any mod that loads after can mess the modules up, though. KSPIE is the only mod I can think of that bundles/requires tweakscale,, and the tweakscale ionEngine patch was causing duplicate attributes so just about every KSPIE user would have the duplicate type and default scale attributes on their ionEngine configs and depending on version, get the tweakscale warning. On top of that, once craft and in-flight vessels based on the flawed part configs are built, I'm pretty sure there's no way to push a config to fix it. The save file will need to be edited (or those in-flight vessels and craft will need to be brought home/deleted). If you wanted to be extra cautious, maybe don't change the tweakscale type in KSPIE's ionEngine cfg. @Lisias would know more about that but from what I understand, the bug actually activates once a vessel that depends on a problem tweakscale config is using a fixed/altered version of that problem config. In the majority of cases, a difference in scale type or scales available would be the most likely trigger.

Duplicate tweakscale attributes are getting applied to a lot of parts from a lot of mods. It eventually causes problems with vessels in flight and saved craft. One of the problems is ionEngines when KSPIE and Tweakscale are installed (I believe tweakscale is a dependency of KSPIE so this would be a problem for all KSPIE users). Because you remove any previous tweakscale module before adding a new one in your config for ionEngine, you've done nothing wrong and don't need to do anything to fix your mod (I believe it's tweakscale's own stock engine config file that is adding the duplicate type and default scale properties). But, if anyone on your KSPIE support posts has an issue with "fatal warning" messages on "ionEngine" parts, you'll know that it is the result of this issue. It can eventually cause size changes in parts for saved craft and in-flight vessels (probably destroying them). Users with this issue should be able to get help correcting it if you send them over here.

Found another one. @FreeThinker's KSPIE more or less redefines "ionEngine". To the author's credit, they start the re-definition by killing any possibly problematic modules they intend to redefine. It seems like the patch provided by tweakscale is running afterward, resulting in the following config: MODULE { name = TweakScale type = stack defaultScale = 0.625 scaleFactors = 0.3, 0.45, 0.625, 0.95, 1.25, 1.875, 2.5 type = stack defaultScale = 0.625 } The first type and defaultscale coming from KSPIE. The second from tweakscale.

Found a duplicate attributes problem related to @OhioBob's BetterSRBs. This was tricky to find, I *believe* it results from the fact that BetterSRBs edits the name of four parts, F:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\BetterSRBs\Parts\Adapter_1p5x1.cfg: 1 +PART[Size3to2Adapter] 2 { 3: @name = Size1p5to1Adapter F:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\BetterSRBs\Parts\NoseCone_1p5.cfg: 1 +PART[rocketNoseCone] 2 { 3: @name = rocketNoseCone_1p5 F:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\BetterSRBs\Parts\SRB_1p875x12.cfg: 1 +PART[solidBooster1-1] 2 { 3: @name = BetterSRB_1p875x12 F:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\BetterSRBs\Parts\SRB_1p875x22.cfg: 1 +PART[MassiveBooster] 2 { 3: @name = BetterSRB_1p875x22 If I've deduced correctly, each of these parts gets a tweakscale patch applied based on their original name, and then gets the tweakscale patch for their new name applied, resulting in the duplication. I also *believe* replacing BetterSRBs z_Tweakscale.cfg with @PART[BetterSRB_1p875x12|BetterSRB_1p875x22]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { %type = stack %defaultScale = 1.875 } } @PART[rocketNoseCone_1p5|Size1p5to1Adapter]:NEEDS[TweakScale] { %MODULE[TweakScale] { %type = stack %defaultScale = 1.875 } } should fix this. Otherwise, the first patch would have to ensure BetterSRBs isn't installed before applying (which seems like an odd responsibility to take on, knowing about the name changes of another mod).

Looks to me like there was a patch update to KSP which caused the old structure of the basic fuel-tank configs to reappear. Restock has a built in warning for it so I took a look and didn't see anything interesting in the configs but I was also not incredibly thorough in my forensics. Deleted the folders (the expected configs are still available at the newer location so they were duplicate definitions), game continued to work fine, no more warning. Don't know if anyone else has encountered anything similar.

If there were, that word would almost certainly be here. Having continued to use and rebuild (for no real reason, none of the API it uses was broken or changed) this version of ShipManifest continuously from 1.4.3 to 1.7.1, I would guess that updating it won't be a high priority if the original author (Papa Joe) does return (because it's already fine). That said, I forked the original, rebuilt it against 1.7.1, and updated the version spec if anyone is interested: https://github.com/marr75/ShipManifest/releases I haven't encountered the issue Lisias cited but would look at fixing it if I did. As far as the conversation preceding about trust, the full source of the forked github repo is there and included. Plus, there are much simpler ways of infecting a much larger audience than to distribute your virus or spyware in a .net DLL (trivially accessible source code) that maybe 10 people will download :-)

I haven't played since last July but the new update looked good enough that I'm getting back in. First mod I checked in on was this one. The version I made had some quirks that required hand-crafted recorded missions, careful avoidance of situations the original couldn't handle, and a little suspension of disbelief because it modeled every orbit as if higher orbits were more expensive (this is obviously untrue for orbits to other bodies, lower orbits are typically more expensive). The only reason I didn't try to make a releasable version of my fork was that I didn't know how to or want to learn UI programming for the game, so I just lived with the quirks. I guess I'm over that hump now and will give it a shot. What I'm hoping to release is a re-imagining of the original concept, instead of recording flights, you'll unlock the ability to send certain masses to certain orbits based on having properly fitted space stations in orbit at start and finish. Maybe ground bases could even play a role. One of the complaints about the base game is the limited role of bases and stations, and I hope this will improve upon that. The recorded missions ended up being difficult to use, I would often have to reload multiple times just to get the process right and even then, still end up with launch parameters I didn't think were fair because of staging quirks game-able, I could record a launch with a sleek, dense payload and then launch a double decker bus into orbit after in-flexible, needing to record a brand new launch just to alter the parameters slightly was a slog I'll dig up my 1.4.5 DLL and pm you how a link to it in the meantime. It may be in a state that depends on USI-LS being installed. I don't remember. I think it will take me a few months to build the mod I'm talking about.

@lunaris69 USI LS is interestingly coded and looks for hardcoded astronaut names to exempt from life support processing in what I remember to be a fragile/inflexible way. I haven't played since the updates started coming too frequently for my tastes so I'm running on a little bit of long term memory here but I know I worked around this and it was either by a) trying name strings until it worked or b) custom compiling USI LS to not hardcode a last name onto your veteran list before checking. I was working on a mod that could move ships, astronauts, and cargo around the system once you had the technology and strong enough infrastructure at both endpoints for a dynamic cost and USI LS gave me a really hard time. It's interface was not friendly to interrogation or use by other mods and many of its pieces that could have been useful to call on their own or override were jammed into rather large methods that couldn't be broken apart without recompiling, so, making the veteran name checker more flexible would have been a pretty simple fix at the time for me. If you were planning to depend on your veterans for pioneering/long range missions, thus circumventing the hardest part of USILS, maybe lighten up the settings instead and just deal with it on even the toughest/longest range missions?

This is a bug in the stock code (it's actually from the really bad optimization advice they handed out a while ago to modders about preferring for loops over foreach loops, this caused them to loop through a different array than they were accessing which can't happen if you use a foreach...). It's actually going to occur for any Kopernicus pack that removes launch sites using a Kopernicus before 1.50-1. Update Kopernicus and you won't experience this bug any longer. As for the launch sites in random places, I have not experienced that issue.

It was the first time in KSP I felt a real feeling of "discovery". It was the coolest moment I've had playing the game.

All of this XXXX discussion is a little spoiler-y so I'm assuming maybe it gets deleted or cleaned up someday. I found it in a blind (no reading documentation of bodies) playthrough with ResearchBodies enabled with my first probe to [Body XXXX Orbits]. The visual context in which it orbits that body make it a reasonably easy but delightful find and will provide seasoned rendezvous'ers a good frame of reference to line up a rendezvous mission. I think you can even target/focus it using KER once you know there's another body in the system.

The cause was discovered and documented in the Kopernicus/Kittopia forum: Tradeoff is listed there. Seems like this improvement to memory will probably get reverted in favor of fast switching but who knows when. I investigated mainly to see if this was related to one of my contributions. Instead, related to some optimizations and improvements Sigma's worked on. Poodmund already entered a github issue for it: https://github.com/Kopernicus/Kopernicus/issues/323

I've popped in before. I will search. Thank you!

I have poked around in a lot of mods where it could be useful (KSPTOT, X-Science) so if there's any "WIP specification" or working group info I can peek at, would love to. Not trying to build anything based on it personally yet but very interested in the future of that project.

I'm still running my unofficial build against 1.4.5 but, yes, the performance improvement was substantial during my testing and the updated code is definitely incorporated into the new releases. Mostly made the above notice to GPP users because the new release has a lot of love for the GPP playerbase that other planet packers might not notice.

@Thomas P. There are probably some new(ish) features the community could use help in using, i.e. Orbital Icons, KSC transform injection, UBIs, etc. Let me know how I can help. I think I understand Orbital Icons best (and an example in the example repo might be the easiest way to document), UBIs second, KSC transformation least.

With the newest update of Kopernicus, the locked out of saving, loading, or exiting and orbital icons FPS fixes are both in the mainline releases of Kopernicus. Both of those bugs had large impact on GPP because: a) GPP manipulates launch sites, activating the first bug b) GPP has a lot of celestial bodies, exacerbating the second issue c) GPP has a big subscriber base Happy exploring!

Eh, I guess that's true from a certain point of view (in the "Star Wars" it's not really true way... ). I described the way their source code works accurately. They don't set home status based on any events, they set it based on a looping sub-routine that scans all current flights for crew and determines if they're orbiting Kerbin at an altitude below the "home altitude". There's no requirement that launches have to occur from Kerbin (in fact, in the fork of this mod I use, they can go to and occur from other bodies and be used with KSTS). USI-LS was just built around that assumption. It's not really a big deal, others have listed the same workaround I used for a long time. USI-LS could be more compatible and better performing if it used event emissions instead of Update/FixedUpdate callbacks for some of its logic. There's no requirement that a mod maker has to make their mod compatible or performant and USI-LS is a great mod. As far as "fixing the bug here" I do so in my custom fork but it's suboptimal because it has to take advantage of .NET Reflection (fragile), read and write undocumented data structures of USI-LS, and doesn't quite set the times exactly as I'd like, so I probably won't publish a binary release in that state. Requiring KSTS launches to start from the ground/some lower orbit isn't a workable fix for this mod.

Note: FT beat me to this response. It's a feature. It's actually based on a stock feature that no stock engines use. Many of the KSPIE engines work that way. Adds additional challenge to take advantage of the thrust/isp/megajoules or electricity they produce and realism. Doesn't make a huge difference on long burns and just requires a little experience with the engine for short burns. Bigger challenge is how long it takes to halt thrust at the end of a burn, you can shut down the engine manually and eliminate this, though. While I don't mind the concept, I don't like how the stock formula works (it calculates change in thrust based on a constant fractional capacity of the engine for change from current to desired, so small desired changes take as long as large ones which is silly). Spinning down is therefore even worse, especially because I'm probably just feathering the throttle at that point and yet it still seems to carry over for a relatively long time (doesn't "spin down" from feathering the throttle like I'd expect). You can also just break the realism by shutting the engine down and not suffer this effect at all. Seems like spin down could use some work (which is unsurprising because while it's a stock mechanic, I don't know of any stock parts it's enabled for...). If you want to modify it with a modulemanager patch, the variable is `reactorSpeedMult`. The unit is "inverse seconds" (although there's a tech bonus that AFAICT divides by ~10 if it's unupgraded) and the highest and lowest I've seen are 10 (MIF) and .25 (NERVA/LANTR). The code has a lot of constants that are oddly defined and/or could be reduced, but if I'm reading correctly, the unupgraded NERVA (reactorSpeedMult = .25) takes 40 seconds to reach desired thrust. MIF takes 1 second. @FreeThinker I noticed that there is a .2 base acceleration and a .4 base deceleration. There is also a constant "5" being multiplied in. I think it would probably make sense to eliminate the constant and set the base acceleration to 1. You could then eliminate that variable entirely. The deceleration is then just a multiple of the acceleration. It's currently 2 but, because stock KSP thrust acceleration/deceleration is such a crap formula (it should use the engine's warm up / cool down capacity from current to *full/no throttle*, not between current and desired) maybe a higher deceleration multiple is necessary (4-10x?).

@askminjae RSS for 1.4.X was just released -> https://github.com/KSP-RO/RealSolarSystem/releases Prior to that release, you could use RSS with 1.4.X but had to make a slight tweak to the config for Kerbin, detailed here -> https://github.com/Kopernicus/Kopernicus/issues/283, just took a while for that tweak to make it to RSS