• Content Count

  • Joined

  • Last visited

Community Reputation

31 Excellent

About whitespacekilla

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. 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.
  6. 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 :-)
  7. 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.
  8. @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?
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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.
  14. 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.