Aerospike

Ok so I ran a few quick tests around KSC today and KISS seems to work just fine with KSP 1.12.3 So I'll update the info here and on spacedock.

Hello, Yes, KISS is still supported, but I didn't have much time/motivation for KSP recently. 1.11.x was the last version that I have tested KISS against, and I have marked it as compatible on Spacedock (that is where CKAN gets its information from) . Guess I forgot to update the thread here. I'm too busy this weekend to do anything, but I will run some tests with 1.12.3 next week and update spacedock and this thread.

I can't reproduce this issue. I tried it with a clean install multiple times, but the config file was always created. I have released a small update anyway. It's just a recompile against KSP 1.9.1, so don't expect anything new.

Thank you for taking a second look! I'm glad that you didn't spot any obvious issues. Still there is a lot of work to do for me, beginning with the old legacy UI and the overall structure of the plug-in. I really should refactor the code quite a bit.

@linuxgurugamer Could you please explain this issue in more detail? I just looked at the code of KISS (haven't really done that in many months...) and I can't find any explicit use of threads. Of course there might be some implicit use of threads by Unity (or System) classes but I would not know where to start in finding any of those "hidden" issues. Also: what gitlab issue are you talking about? My source is on github and I can't find any new issue there...

Thank you for making me aware about the issues. I'll look into it as soon as possible.

Wow! Trip back memory lane! I had a grasshopper II as a kid. Terrible RC car (weak motor, only 2wd, no individual suspension on rear axle, no (oil) shock absorbers (only springs)), but man I loved that thing! Really like your build so far!

Working on a KSP analogue of NASA's SEV (space exploration vehicle) concept. I've been wanting to do this ever since the new MK2 Lander Can came out (and before I even contemplated to create my own model for a "look-a-like" rover cockpit). All Stock (with possibly both DLCs) with the exception of Aviation Lights on the top of the cockpit. Available parts severely limited because of the current progress in my career game. Current problems: 1) I'm not yet satisfied with the looks, especially the bottom "service bay" section with fuel tanks and solar panels. Maybe I need to build it in sandbox or wait until I have more structural parts unlocked in career... 2) Without some serious use of BG robotics (which I haven't used before) to create some arms, it actually has no ingame use for me. A Klaw below the cockpit to grab things would be nice, but it just doesn't fit the scale (it is way to big).

So I have finally been able to try the versions that came up after my little contribution to the whole engine plate issue: * 1.9.1.4: engines are not considered as a part of the same stage as the engine plate and if I remember correctly, now it seems that "ConsolidateStages" is broken, because every one of the 7 engines on my plate is considered as a separate stage. Unfortunately I don't have a screenshot, and now it seems I have trashed the config somehow (see below) * 1.9.1.3: engines are in 1 stage together, but still in a different stage than the engine plate. Engines attached to the plate get no highlight at all (neither red nor green). * 1.9.1.2: can't test it because somewhere in the process of starting and shutting down KSP multiple times and switching out SR versions in between I must have corrupted something, because now the UI for SR doesn't show up no matter which version I use. (button on toolbar is visible). Is there some method that SR uses to remember window positions? So that I can reset it? I can't find any obvious file for this.

Hello @linuxgurugamer I was able to come up with a (crude) fix for handling the engine plates from the Making History DLC. I'm not entirely happy with the solution because it relies way to much on hard coded assumptions about Engine Plates, but I'm not yet familiar enough with the KSP API regarding parts to rewrite the code for determining stages in a cleaner and more robust way. Anyway, I've created a PR on github so you can see how I did it: https://github.com/linuxgurugamer/StageRecovery/pull/2 Best regards and thank you again for maintaining so many great mods!

Hello, I have noticed some irregularities with Stage Recovery (great mod, thank you so much for maintaining it!) percentage calculation in the Editor GUI and the Engine Plates from the Making History expansion. After looking more closely, it seems like stuff attached to the "engine nodes" is seen by SR as belonging to the stage below the engine plate and therefore the mass calculation for the stage with the engine plate at the bottom is incorrect. I poked around the code a bit and at first glance the issue seems to be located in EditorGUI.cs in StageParts DetermineStage(Part parent) {...} where parts are only checked if they implement the IStageSeparator interface, but some logic is missing to correctly handle the 2 different types of nodes of the engine plates. I know you have a lot of work to do with maintaining so many great mods. Maybe I could find some time this week to have a go at it myself (and find a fix and create PR on github) but I can't promise anything.

The humble beginnings of my very first space station, creatively named "Alpha" All stock with the exception of some "surface mounted lights" for self illumination. Built for a contract in career mode for a station with a lab that can house 7 Kerbals, still needs a cupola to meet that crew requirement. Currently slightly above 80 parts in a ~101km equatorial orbit of Kerbin

@Yakuzi Wow! Those are some incredibly beautiful designs!

Amazing work @Aerospacer

You are right of course, thanks for the correction. I mixed up the recent part revamp heavy updates. What a great "problem" to have, isn't it?

Yes, courtesy update 1.6

Wow! I can't decide if I like your craft or your screenshots better. Both are very sleek and stylish!

@MaximumThrust Here is a special release just for you (and anybody else still playing in 1.3.1): https://github.com/KerbalSpike/KerbalImprovedSaveSystem/releases/tag/v2.4.0_legacy_KSP1.3.1 As far as I can tell with some limited tests, simply compiling the current version of the mod against KSP 1.3.1 seems to be enough to make it work. No special adaptions required. Hope this helps!

Hello @MaximumThrust Your games are running 100000 years in-game time or longer? Everything else should be padded enough or am I missing something?

Happy holidays to you as well and thanks for taking over KER!

Thank you very much! Just what I needed! I somehow assumed that the orbit would only contain parameters that allow me to calculate the orbital period, but not the period itself... That's why I haven't looked there before.

New release is finally out! I have tried to reproduce the issue with savegames that contain characters like ".", but those load just fine on my machine. @badS & @Gordon Dry I think you should like the new sortable gametime timestamps Let me know what you think about it. Especially if 99999 years is enough for you guys or if your games run longer

Hello fellow developers. My savegame mod provides the option to place timestamps into the savegame names, that use either real time ("yyyyMMdd_hhmmss") or game time in "years_days_hhmmss". Unfortunately there seems to be no formatting method out of the box, to format game time with leading zeroes for years and days, which is a requirement to chronologically sort the savegames based on a gametime timestamp. (Of course I could just use the game time in seconds, but that is rather nondescript for humans.) So I guess I'll have to write my own formatting method for years and days. This method needs values for the length of a day and a year of the games "home" planet (so that people with modded solar systems and/or relocated space centers aren't left out). The CelestialBody class provides the data for the length of the day of a planet, but I can't find values for the length of the year? I have searched the forums and api docs but can't seem to find anything the would be helpful for me. The most relevant thing I could find were discussions about the discrepancies between kerbins solar and sidereal days and years... If someone could point me to some information that helps me to calculate the length of the year of a planet, it would make me very happy.

Thank you @micha! I actually searched for "*kerbal*" in AppData\Local and AppData\Roaming as that is where most apps usually put their stuff. I think I never had any app put anything of interest into "LocalLow". So I didn't bother to search there as well. Doh!

Hey there. Having to update my KSP modding environment after an eternity, I came across a few things that seem to be outdated. Example Unity version: I think the OP could require an update, as KSP 1.1 won't be of relevance for most new developers. For KSP 1.4.x - 1.5.x the correct unity version is Unity 2017.1.3p1 as pointed out by fatcargo above. Finding out the Unity version when a new KSP version is released: the output_log.txt/Player.log. seems to be no longer existent. So no luck finding the Unity version there. Instead, simply right click the KSP.exe / KSP_x64.exe -> Properties -> Details -> the entry "File version" tells you the Unity version, but it tells you something like 2017.1.3.55103. No idea how to figure out the required patch version without trying every possibility? Creating a "junction" using mklink in a command prompt: if you are on windows and like to work with the newest tools, you might have wondered if there is a way to use powershell instead of the old command. Fortunately there finally is one now: New-Item -Path KSP_x64_Dbg_Data -Type Junction -Value KSP_x64_Data (arguably mklink requires less typing ) After a few hours of messing around, I got everything to work again (had downloaded the wrong unity version, not the correct patch version) and now I just have to update my build configurations for the new ksp versions and then I can actually start working on the mod again...