almagnus1

You have more information on that?

IIRC KSP 1.1 is coming with a Unity upgrade, right? Assuming that's the case, that version might be changing as 3.5 is what we're using right now. The game changer is .NET 4.5, and what can be done with plugins (as we can potentially leverage everything in the System.IO.Compression assembly as seen https://msdn.microsoft.com/en-us/library/system.io.compression(v=vs.110).aspx ). Many of the classes (and methods in existing classes) are .NET 4.5 ONLY. In a more practical sense, it means that .NET gives us a better ability to work with zip files without having to use 3rd party DLLs (like the ones for 7zip for example), potentially allowing for mod files to be read from a zip file without need for extraction, which can greatly simplify mod management as you'd need to extract the mod loader mod, then just drop zip files into a directory. That is, assuming that a stream created from the zip file for an entry can be hooked into KSP. There's still a lot of unanswered questions there, but it is something that merits further investigation. Most of this is theorycrafting, so some (possibly most or all) of the above may not be possible.

Unfortunately I have not. That's something I'm going to look into next week, as I'll have ample free time to dedicate towards things like CKAN and other KSP related projects (among other things).

Ok, assuming that I'm following the docs right, and http://www.mono-project.com/docs/about-mono/compatibility/ is valid documentation for the GitHub repo, then the answer is .NET 4.5 (mostly), correct?

What's the .NET Framework version that KSP 1.1 is slated to use?

I'd rather have the game flag give you a UI that gives you a choice on the matter to either delete the vehicles and continue (basically what it does now) or abort the load and dump you back out to the main menu WITHOUT altering the save data. That way the vehicles don't get screwed with, and the player has a chance to fix the error before loosing crewed vessels, stations, probes, and/or bases that may have taken a lot of work to play. The losing of things is the part that's just bad UX, and should be avoided, especially since KSP allows for mod support.

The issue here isn't the removal of the mod (as Remote Tech was used as an example, really), but the base behavior of the game because it's very unforgiving when parts aren't there between loads. The same happened with the latest UKS update because CKAN had a bug (which should be fixed now) where CKAN didn't properly install UKS due to changes in the UKS file structure, rendering a mod uninstalled despite the user thinking it was. S. A. V. E. is a valid workaround for the time being, but it's not a long term solution, as KSP itself shouldn't delete craft just because there's an invalid part on them.

What's the link to that mod? Sometimes it's not that simple, as (in the case of remote tech), I would need to adjust a whole legion of satellites, which is a lot more work than one would think (get engineer to rendezvous, do work, goto next). A UI based way to easily remove the offending parts (or replace them with compatible parts) would be ideal. IMO, the game shouldn't delete invalid craft from the save if they aren't loaded to begin with. Instead, the game should leave the craft there so players have an opportunity to fix the error, rather than risk losing craft when something with mods go sideways.

So I was in the process of pulling out Remote Tech from my save, and loaded up my save, and about half of my vessels (including a space station) were eaten by the kraken on load, as the game failed to load most of them due to missing parts. Unfortunately, these were all crewed vessels. So after closing down the game, restoring Remote Tech, and loading it up again, I saw that all the missing vessels were truly gone. This leads me to my question: Is it possible to engineer in better safeguards with crafts that are missing parts so when the above happens (or CKAN derps after a mod's folder structure changes), we don't irrecoverably lose craft?

IMO, weapons feels out of place in stock; however, I'm fine with mods like BD Armory that add in that mechanic. Explosions in stock are usually the result of not doing something right (ie: RUD), or just being careless (as is the case with the MANY separators I've exploded).

From the description, it sounded like you were describing adding clocks to all of the ships and calling it a day (that's not helpful). Actually looking at the mod, there's a UI element that's separate from everything else, which is actually a viable alternative. Eh, it's a less than perfect solution =/ Anytime a work around involves "hack the config files", that's an imperfect work around. The solution to a UI deficiency should never be "hack the config files", because while the technical users know how to do this just fine (like most of us in the thread), the non-technical users will invariably screw this up, and corrupt the config file. The correct solution is to make sure the maximize button on the window bar chrome (at least the one in Windows) is enabled and works like it should. That the maximize button is not enabled, but present, is actually a bug with KSP.

Here's a thought: Why not change habitation into morale? When you get down to it, an unlivable space would cause low morale, and as the space degrades, it would also cause morale to drop. This way you can still require <appropriate resource> to still maintain vehicles, you still maintain the mechanic, but you also eliminate the concept of things wearing out. While the concept of things never actually wearing out is unrealistic, it's kind of essential to KSP with your approach to USI-LS, as you don't kill kerbals by default (unlike TAC-LS), which means things wearing out and breaking shouldn't occur because that's the equivalent of killing structures. It's definitely a feature that could be enabled, but one that's off by default. What's not sitting well with me is that I am no longer in control of when things need to be replaced, as the habitation mechanic is usurping that control (as I currently understand it). That will creates more unnecessary work, whereas a morale mechanic makes sense, as that's a direction that things should go, and (to me at least) fits with the general USI-LS approach to life support. The other advantage to morale is (for vanilla at least) happier scientists can get a productivity bonus to the mobile processing lab, and that mechanic also works well with the various productivity mechanics of UKS. The creation of uncessary work is also why I recently pulled Remote Tech from my mod install, as it was making pre-communication network gameplay less fun that I really wanted it to be because you need to be high enough in the tech tree to get the solar panels so you can loft the satellites to geostationary orbit, which basically added too much busywork, and it's something I'd like to avoid as there's enough stuff to do with the various USI mods as it is.

Shouldn't that be: Why DID they? All three games already have a real world clock in them.

Why should I need to hack the settings file when other games allow you to click the "maximize" button on the window chrome when the game is in windowed mode, and they adjust the viewable area for you automatically? Because this functionality is in other games that I play (like FFXIV, Diablo 3, and Hearthstone). If it was completely without precedence, I wouldn't be asking for it. If Blizzard and Square can do this, why can't Squad?

Same here, which is why I'd rather have one on the UI, as it helps with time tracking. Windowed mode looks ugly, because I can't get the Window to an odd resolution (so the task bar is visible) because there's no maximize functionality on Windowed mode (at least, not on the DirectX 11 forced mode). That's why I want the time stuck up near the mission clock, so it's not eating into the rest of the display. And for those of us that don't have a Steam copy? That's an impartial solution, because having the clock visible all the time allows you to plan to get off at a certain time, versus getting the alarm in the middle of what you're doing, swatting it away, and then staying on longer than you should.

KSP is an excellent game, probably one of the best I've played in my many years of gaming. Therein lies the problem, KSP is a bit **TOO** good, leading to lots of hours just vanishing to KSP. Something that would help alleviate this issue is having a real world clock (using the computer's local time) in the KSP interface, preferably next to the game clock when this feature is enabled.

Touching back on the habitation values with the top tier stuff, is that rated for decades, centuries, or millennia of use? Given how many gameplay hours it takes to get through the tech tree, it feels like there should be a part (or mechanic) in the end nodes that negate the habitation mechanic, or at least reduce it to a slow draw of parts needed to maintain the facility, but has a rated lifespan of a century or so.

So, hypothetically speaking, what if you throw full USI catalog and the EPLP binaries into the equation, and I've built a fully sustained base on Lathe, crewed with Kerbals complete with with the minimum needed to generate the manufacture the rest of the base in-situ, so the base is completely self sustaining. Would it really make sense to force the players to return those kerbals back to Kerbin at some point in the future? Wouldn't it make more sense to have something deep in the tech tree that allows the kerbals to stay afield indefinitely? If I have a goal of completely colonizing the entire Kerbol station (as long as THAT would take), the habitation mechanic seems like something that's going to force a ton of necessary crew rotations in that scenario, as I would expect some way to reverse the ill effects of being afield once I'm far enough down the tech tree.

Touching on the hab stuff, I should (in theory) be able to keep a station in KEO up indefinitely with the appropriate supply runs, as having to rebuild a station/replace hab modules is not fun gameplay because it introduces tedium that should largely be solved by supply shipments. Within the scope of stock + USI LS, that's going to make maintaining bases all the harder, as there needs to be a simplistic way to go from ore => hab stuff. Granted the conversion rate should be abysmal compared to what UKS/MKS Lite can do, but it's a necessary concession so that stock + USI LS can function without needing another mod beyond what's necessary for USI-LS's dependencies.

Any thoughts into adding in an exercise mechanic? If so, will you do it with giant hamster wheels for exercise equipment? It would be most hilarious to see random kerbals using the wheel =D

Cool! =) When you get time, I would definitely love to see an extension of this mod to work with the 2m lander can and stock lander legs, as that seems like a logical next step. If done right, i could also see that integrating well with FTT and the other lander thingy that I'm forgetting the name to >.>

Any thoughts to making a packrat that will unfurl (or at least, allow the user to expand wheels, then unfod so it can right itself if ejected in an awkward position), and then a 2m part that can detach the packrat (possibly with fuel and/or other stuff to act as a lander base)? That would give us an alternative to either shipping the packrat prebuilt, or requiring KIS/KAS to construct the vehicle on site. PS: You need to flag this thread as a USI one =)

I think the quote you are looking for is: http://forum.kerbalspaceprogram.com/index.php?/topic/91479-ksp-demo-mods/&do=findComment&comment=1551982

You may want to keep in mind that basically all of us want KSP to succeed so we're going to want you to buy a copy of KSP, rather than encouraging you to keep experimenting with the demo without actually getting a copy.

If you guys really want to prove a memory leak exists, go hunt down the Windows Performance Analyzer (or one of the other Windows profiling tools from Microsoft like xperf - i think), profile KSP when the leak occurs, then bring the data back here. Until you show data, and your analysis can be verified, no one is going to take the claim of a memory leak seriously.