steve_v

Please nobody take this as mac bashing... I'm curious: What is the need/want for OSX? I do remember it being a super-sexy UI when it first came out, and it is a unix... but If you want to run *nix why not just run GNU/Linux or BSD on any old hardware? Does OSX have some uber-apps that Windows (still king of app compatibility IIRC) doesn't? I kinda thought people run OSX because they like Mac hardware, rather than the inverse.

Would you like to spend 2 weeks cooped up in a Mk.1 pod? Check the habitation time on that crew quarters. (or turn it off if you don't like it).

Primary consumers are lab, recycler & habs. ~=32EC/sec. See post above for my reaction to needing ~700000 EC storage for 6 hours of this. This cannot be the case, if it is it makes the whole "LS requires EC" thing ridiculous.

Consumers off, producers off: 0.14 EC/sec, 3870 storage, =~7.7 hours.

20 days, according to the LS status window. Should be heaps, but the status window obviously isn't taking generation into account, as it will happily hit zero if I warp for >20 days while the craft is unfocused. That's bit is just a minor annoyance, but if it's also causing my other issues... Wait, no, the LS window is lying to me... it doesn't appear to be accounting for a bunch of load (or much of anything really). Killing the reactors gives me a whopping 121 seconds on batteries. Who came up with that idiotic idea then? So my duna mission can't make do with 2 nuclear reactors, for my 32 EC/sec demand I need >690 thousand EC storage? Donkey balls.

Nope, USILS 0.5.10, fresh vessel, fresh crew, started doing the same thing at ~120 days in. Only thing worth noting is that EC went into "expired" in the tracker while unloaded (USI reactor on board, plenty of EC). This is getting pretty annoying. Trying out 0.5.11 now, but it looks suspiciously like I'll be spending all weekend testing this rather than playing... Ed. Updated to 0.5.11, my kerbals are still taking micro-holidays. At this point, I'm just going to go play something else. Might get back to this bug over the weekend. Ed. I also note that excessive supplies have been consumed over the ~120 day period... much like the recycler was not counted (due to no EC?) This thing is powered by 2 USI reactors, with NFE. It has plenty of generation, but little EC storage. If the bogus lack of EC also stopped the habs, that would have caused the first episode of spontanius tourism, but it still doesn't explain why after it has occured once, it occurs on every vessel load.

WRT not following waypoints: No change. Log. (mods) Well bugger me. Saved in flight, then restarted the game to get a clean (ish) log... and now it's working perfectly (so this log is useless). Go to orbit, dock, undock, re-enter: Nav doesn't work (as mentioned previously). Load a craft from an in-flight quicksave: everything is fine. Odd.

Yeah, I know. In the process of retrieving all my crews, will see what happens with fresh victims tomorrow. Making a stock save will have to be a weekend thing.

Just updated 0.5.6 -> 0.5.10... and got a "refuses to work / returned to work" again on coming into range of my Mun station loading, multiple stations . No errors logged, but back to the old pre patch-storm behaviour, at least on my career save. Back to 0.5.6 again I guess. Seems it's the last version that a) works and b) doesn't stop research labs. Ed. Also, 0.5.10 comes with comunitycategorykit 0.1.2?

@linuxgurugamer: As well as the heading hold issues mentioned above, I can't seem to get the nav function to work at all either. The "xtrk" display just flickers rapidly (often +- the same reading), and the aircraft settles into a gentle left bank plus some twitching. The OSD heading indicator works just fine. The bank controller is working fine too if I set a manual bank angle. Modded (inc. FAR dev build), nothing interesting in the logs. Any ideas? I've used PA extensively in the past, but the nav function here is the main draw...

FWIW (looks similar, but may not be related), I upgraded from 0.5.6 (which worked, and fixed the earlier habitation issue) to 0.5.9 and I'm seeing something like this too. Nothing shown in the LS window, no resources consumed, on a (previously working) station. Going EVA and re-boarding with the sole occupant triggered this log entry a dozen or so times: Then LS magically started working again. So far (and a few scene changes / vessel switches later) so good, no more errors. There's something funny still going on here, but it seems a vessel state change fixes it, at least for me. No EVA possible on an unmanned vessel though. ed. Spoke too soon. It happened again, though this time I spotted the instigator - undocking (in the first case, a spaceplane, and just now with a lander). After undocking, (in both cases the smaller / not station, unaffected vessel became the focus) the station looses all LS functions. Playing about with the lander & station in close proximity, the error is logged on every dock, undock or vessel switch. Undock / dock or EVA doesn't seem to fix it this time either . All this on existing vessels, and with other mods. Really don't have the time to spend on a stock save ATM, barely time to play at all . Bloody day job. Rolled back to 0.5.6 for now, and everything appears to work as expected.

MemGraph, FWIW. And yes, it helps. But padding the heap is a bandaid at best, and a bigger heap means the GC runs less often, but takes longer when it does. Buggered if I know. Not (directly) a Unity customer so have no leverage. I'm sure I've heard this story before: Commercial entity meets open-sorce project... Forks it, makes some money off it, doesn't bother updating it or contributing back to the original. Ends up with an inferior and incompatible version, then starts talking about ditching it and doing the same thing over again with another project. Unity's fork is still open source, so in theory anyone could try to add the Unity changes to a newer mono release, or backport the Sgen GC... but it sure sounds like a lot of work, and the repo is a mess.

I hear ya, time is a bit limited at the moment, but I'll try to produce one this weekend if nobody beats me to it.

Any non-ancient mono version has generational GC, which should improve this situation significantly. The mono Unity/KSP uses is based on a 7 year old upstream release. That we are still stuck with this fossil beggars belief.

It does, but a bigger heap also means longer pauses. Almost as annoying IMO. Yup, sure is. Noticed pretty much zero improvement here. Modded, but pretty much the same mods. See it in stock too, to much the same extent as 1.0.5. As far as I can tell, clean up existing code + add new code ~= back where we started. Reducing garbage creation will help, but it will never fix the problem (Unless you create zero disposable objects, yeah, right.) Rip out that ancient garbage collector already, mono has a much better one now. Yeah, I know. Unity. Third party game engine. yada yada. Heard it lots. Saying it again doesn't fix anything.

@RoverDude: Havin a wee problem with habitation timers on an unloaded vessel, I get a quick "refuses to work" > "returned to work" cycle on load for both kerbals on board. So far only one particular ship, It's been up a while so I suspect it's one that would have expired the hab timers if the habitation multipliers / hab parts were not active. Problem goes away if (and only if) I set habitation effect to 'none' in settings. Not a problem for kerbal survival as they are only tourists for a second or so, but it's long enough to stop research on the lab (no scientists), which is a royal PITA. Any ideas what's going on? The save in question has quite a few mods, let me know if you want it anyway. I don't see anything from USILS in the log but here's a snip from loading the vessel (hab effect on): Ed: A few warps (at space centre) later, more labs are showing the same problem... AFAICT, this only happens if the length of time-warp is greater than the base habitation value (i.e. with all habitats off), so something to do with the "catch up" mechanic for unloaded vessels? Actually, not so sure about that one now...

Better is relative, while you may indeed get more DV out of it, nuke spaceplanes are generally considered "hard" on account of the low TWR of the NERV. I'd persevere with the Rapiers before trying that. On your current problem: The obvious answer is "take more oxidiser (or less LiquidFuel)". The obvious question is: "What are you trying to get to orbit (payload)?" In any case, Can't say much without seeing it. Pics? I don't usually play without FAR, but I built this wee thing to go to Laythe during pre-release (stock aero) - with decent piloting it makes 100KM orbit with ~300m/s DV (plenty for rendezvous with the transfer stage) to play with, IIRC: Only ~2T payload, but about as light a Mk.2 design as I have and pretty fun to fly. Honestly, dunno. Never tried. IMO Spaceplanes are for getting to orbit or landing on Laythe... Suspect it'd be a fair bit bigger.

Because CKAN is better? Because NMM is Windows only, while the game also supports MacOS & GNU/Linux? Because SpaceDock is 9000 times better than NexusMods? Because the KSP community prefers KSP community solutions? TBH, even if all the mods were on Nexus, I still wouldn't use it. Dropping a folder in GameData isn't hard, and if you can't manage that, CKAN is actually not too bad these days. (I'm using PyKAN though )

I dream too... 1.3: Major existing bugs fixed (e.g. terrain seams), no new bugs, all game engine physics jankiness and performance problems sorted. Console port updated to same status. Core game becomes a stable platform, mass mod-disruption and slew of new bugs on every release stops.

I too have noticed the delay on loading the save list, and it most definitely scales with number of saves - I've been watching it grow as my game progresses. Freezing the game for >15s to scan 146 saves, totalling 165MB, on an SSD that can do >400MB/s read is ridiculous. This behaviour is new for 1.2, and it's extremely annoying. In <1.2 I was regularly running at >400 save files, and opening the load list took no more than 2s. Removing saves does indeed reduce this effect, however as doing this from the in-game UI also causes it to freeze, it means deleting the files manually.

Cursory glance says at least 3, two of which were filed before 1.2 was released.

It is. Spent some 2 hours driving a tiny rover about on Mun. Crashes due to reckless driving = 1. Crashes due to terrain seams = 6. Never exceeded 15 m/s. There's a clear winner here. The problem is not that there's an irregularity, it's that it's an instant transition. Combined with the obviously-not-wheels, clearly-not-round behaviour of "wheels" in KSP this results in getting stuck or flipping end-for-end when hitting seams head on, and sudden roll-overs when hitting them at an angle. A heavier vehicle helps in damping the violent not-suspension shenanigans , but given that the defining trait of space rovers is that they tend to be light... fun fun fun. This was raised in the pre-release (at least the seams on Kerbin / runway). SQUAD, y u no fix?

Obvious as it may be, also test without the overclock. KSP seems to be very sensitive to this - I've had it crashing on an OC that I couldn't fault with the usual stress-testing stuff.

While it sounds simple, splitting something like MJ into stand-alone modules will add considerable complexity, particularly if you have many interdependent modules and/or common code. For example, the landing guidance is going to need the orbital info, needs to know TWR & DV, relies on the maneuver autopilot to do it's burns, SmartASS to hold orientation, etc. etc. So how do you ensure the user has all those installed? Or do you duplicate all that code in every module? Much easier to bundle the whole thing and allow the user to hide things at the UI level... Which MJ already does. Most of the mods in question are open licensed, so feel free to set an example rather than just back-seat coding. Show us some of this "tidy programming". (then try maintaining it & dealing with users not installing all the parts). Modularisation has hidden costs, both in code complexity and maintenance overhead. There's a reason the architecturally beautiful, highly modular GNU Hurd microkernel is still not ready for prime-time, while messy, monolithic Linux is everywhere... So you roll up with a "grand idea" for what others should be doing, no code to show how it's done, and pre-emptively squash any argument with "If you don't agree with me, you just don't get it". Right.

Read up a couple pages, this should fix it: