steve_v

Funny you should mention that, I swear I saw some space in the game too, mostly after flying a space-plane to get there. I also feel the lock hammer looming, but maybe that's just me.

This is a game about whatever Squad wants it to be about. Is this thread about anything but "I don't like building planes"? If you don't like the aircraft parts, just don't use them. If you think that one part slows down your loading so much, delete it. Problem solved. As far as performance impact and memory use, there are much bigger fish to fry.

If you mean "less polished" as in less like a functional spaceport and more like some re-purposed but still reasonabe looking buildings, then I agree. If you mean less polished as in 'hastily thrown together out of random stock-asset junk', not so much. While I hear you on the "work in progress" point (as regards the images that were released), not everybody is going to get this and showing something in that appalling state is simply asking to get slammed. As Bac9 says it better than I ever could, I'll just leave this here (should be linky, lets see if it works): It's not the concept that I dislike per-se, it's the execution. Sure, I wasn't a huge fan of the 'barn' to begin with, but it's the mismatched, misplaced texturing and obvious modelling mistakes that killed it. TBH, even the space centre we have now is not much to look at - it's full of model issues, obviously tiled textures and z-fighting. Fortunately nobody has to look at it for long.

Well, the point of that was simply to show that the frequency of GC runs is not static. 80 fuel cells may be a lot, but extreme conditions make for an extreme change in GC behaviour, and therefore a clear example.

Perhaps not, but the obvious change in GC frequency when there is much garbage being generated might. Example. This is also an example of Squads code rapidly generating garbage, and reducing such would certainly improve matters, if only in this specific case. Casual observation does not data make. Also, as Padishar points out, this has nothing to do with PhysX. GC not interrupting the physics thread is irrelevant if no managed code can allocate memory - everything else will still have to stop.

This is not what I wanted to hear, but they do mention improvements to the GC problem, so... maybe some optimism? Ouch, we all know what happens if you use that.

The suggestions I made (with the exception of --force-opengl) are relevant only when it's the 32bit address space limit you're running into. How much physical RAM do you actually have? KSP really needs 4GB installed to run properly, given that the OS will also use some of that.

This gells with my own experimental tinkering with Unitys mono build - the 'mark' (heap crawl) phase is the main culprit. Giving it something to collect does however exacerbate the problem. The properly frustrating thing is that this has been much improved in upstream mono, and quite some time ago. Unfortunately Unitys build has diverged too far to backport those features, or drop in a more recent runtime. As usual, commercial entity forks open-source code for their own purposes, and promptly makes it incompatible with and inferior to the original project.

There's a mod for this. Seems to work ok in 1.0.5, though I find rotation a little jittery. And yeah, stock EVA controls are hopeless. The ladder-ejection thing has been an issue as long as I can remember, IIRC StockBugfixModules prevents the exiting craft catapult effect, but I still get it sometimes on grabbing a ladder.

IIRC, (it's been a while, due to another irritating bug) you should never attach docking ports to IR parts, it drives the game nuts. To quote the OP: Do not attach docking ports directly (or indirectly) to IR parts. It will make your life miserable. You have been warned!

@SessoSaidSo I take it you are referring to this thread? If so, I am also waiting for some news. It's been a long time now with no improvement. I think you are wrong. Go read the thread I just linked, and try one of the easy tests mentioned there. ----- If this is, as I suspect, caused by the brain-dead GC code in the ancient version of mono that Unity uses... that has not changed in U5. If it's the GC at fault (and I'm pretty sure it is), the only solution short of unity upgrading their mono runtime is to create less garbage. This is something Squad could, and should be doing.

It's really not that hard, it's literally a copy-paste job. Assuming you have ModuleManager installed (many, many mods use it, so you probably do): Copy this: @PART[*]:HAS[@MODULE[ModuleEngines*]]:FINAL { @MODULE[ModuleEngines*],* { %shieldedCanActivate = True } } into a plain-text file with the extension '.cfg' (make sure Windows doesn't insist on .txt) anywhere in your GameData directory. That's all there is to it. And yes, I too think this needs to be stock - as is apparent from my posts earlier in this thread.

I may not have worded that quite how I wanted... I was thinking more "where do they keep the reaction mass". Particle accelerators are kinda plausible I guess, but you still need a whole lot of particles to accelerate. I see radiation shields around the engines, but I don't see no tanks. Yeah, RCS is not often seen on space battleships for some reason... I guess most of them must use KSP style reaction wheels.

If it is indeed an OOM crash (and your logs will tell you), the only solutions I know of are: Use --force-opengl, use the unsupported Win64 hack, run on GNU/Linux, or wait for KSP v1.1 and the port to Unity 5. Also, this is a rather old thread - I'm pretty sure the search feature (hopeless as it is) will reveal more recent discussions on the subject.

Pretty, but highly impractical. Like most TV Scfi ships it falls squarely into the "rockets are not boats" category. Space carriers don't make much sense (unless they're missile carriers), because space fighters don't make much sense. I don't recall what those big turrets fired, but if it's any kind of projectile... turreted projectile weapons don't make sense in space either. Putting the "bridge" up on top like that is also a sure-fire way to get the command staff killed. For TV Scifi, my vote has to go to the human ships in B5: They have centrifugal AG, fighters that are at least semi-plausible (not designed like aircraft) and the heavy weapons are generally aligned with the main axis, so as not to throw the ship around. While the CIC is often at the front (still silly) at least it's not sticking up like a giant target. They also, as is proper, pay little heed to "up" and "down" as design considerations. OTOH, B5 has handwavium powered engines, hyperspace, and implausible plasma weapons... 'tis rather hard to find "realistic space battleships" on TV.

Thought #1: You're probably going to have to do some detective work, and remove mods a few at a time until you find the culprit. I suggest a binary search. Thought #2: Posting your log and/or inspecting it yourself may expedite this process.

Indeed, what matters to most players is how well (or not) the game runs, irrespective of why. If increasing the unload distance tanks performance, it's only fair to show this. Mind sharing how?

To add to this, (yeah yeah, I know, 2 in a row) a "search this topic" facility at the top of the page would be real handy for those monster threads we have here... every other forum I use has one. Gah, nevermind, found it. It's just hidden by some silly little animated whatsit. Here's where the ability to delete one's own posts would be somewhat handy. As it is, google with a site: term is far, far better than the forum's own search. This is a little embarrassing, no?

Do you have USI life support installed? Did you remember to feed him?

Just in case it hasn't already been mentioned, can we be rid of this "answer voting" thing in the various subforums that have it, or at least change the default sort order to "by date"? On the (extremely rare) occasion that someone actually uses it, it only serves to make the thread difficult to follow.

I note, with a certain amount of glee, that the idiotic and fundamentally broken mime-handler installation (which I suggested be taken out back and shot some time ago) is still causing application breaking problems...

Yeah, that's my guess too. Nevermind, just a passing thought.

Out of curiosity, how is this applied to a joint between dissimilar node sizes - i.e. a 1.25m part connected directly to a 2.5m part? On KJR, I got tired of strut-spam and engine shimmy long ago. I hear it's much improved now, but I kept KJR for it's other benefits - such as physics easing for fewer launchpad explosions.

Depends how you define "sensible", and the craft in question. It's going to have the same effect on any manoeuvre requiring MJ to assume or hold an attitude, most of the time I find the default values work just fine. MJs attitude PID controller is self-tuning to a certain extent, but if that isn't working for a particular craft you can tune it manually in this window or fall back on the (somewhat more primitive) stock SAS.

Make ignored users/posts also ignored in activity feeds - If I ignore a user, I don't want to see their stuff anywhere.