steve_v

The fins appear to break FAR, as in the dreaded "COL arrow re-appears". Ripping out ModuleLiftingSurface fixes this, looks like this mod isn't handled in FerramAerospaceResearch.cfg as the stock wings are. - - - Updated - - - To make them work as fins, they're going to need FARWingAerodynamicModel inserted as a replacement too. Any ideas on reasonable values to plug into that module? For the time being, I'm ignoring these parts in favour of the stock "Basic Fin", which behaves correctly. FAR support? Please?

Which is why I don't use the claw, it's still kraken bait. Another of those "features" that's still as buggy as the day it was introduced.

IIRC, FAR had issues with engines that don't use IntakeAir (used for ducted area calcs). I believe it's fixed in the dev build. Might be worth a shot.

Ta. 10char

Putting docking ports on robotic parts has been a no-no for IR for a long time, IIRC. It's tempting I know, but weird things happen... Best bet, IMO, is to use KIS/KAS. It really does do everything you could want for surface operations.

Might as well close this, as no real answers received & I give up.

This gets my vote too, the stock heating system is un-playably buggy. It's not that it doesn't do what I want it to, it's just plain broken. I would like nothing more than a retro-DRE that implements re-entry heat itself, much like it did when there was no stock system at all. Any way to necro that code? OTOH, I realise that this is a pretty big ask.

Arduino is kinda like the Lego of microcontrollers, easy to work with and many prebuilt addons available. A hardcore electronics nerd will probably prefer a custom micro, but in reality either will do the job just fine. USB seems overly complicated to me, my day job involves joysticks etc. (cranes mostly) but they all use ruggedised microswitches and discrete inputs. Since the demise of the simple joystick port, USB is what we have to work with - so you need some kind of micro to do the interfacing. - - - Updated - - - And boy do I miss those old interfaces (JS/LPT/RS232) - there doesn't seem to be a "just hook up some switches / pots" interface to PCs nowadays I even have an old ISA prototyping board - what an awesome piece of hardware that is... if only I had a PC to put it in.

Suggest replacing "towel" with "seal skin coat"... so the polar bears have something to overcome the nasty taste.

Again, I often 'have or want' to install Windows for games, and I don't complain about it. I still hate using it, but if that's what it takes to run the game I want to play, so be it. In a perfect world all software would run perfectly on all platforms... this is not a perfect world, and we just have to deal with it. I even have a pre-installed image (called "Wintendo 7") that I can dump onto a drive when needed... For me, Windows is only for games, and I don't find that at all mad.

Great to hear from you again Chris, and welcome back. On the topic of ongoing support for 1.x, I wasn't even aware there was a want. It still works just fine. I'm certain v2.0 will be wonderful, whatever surprises you have in store, 'twill be christmas all over again.

I strongly recommend backing up the entire KSP directory before upgrading, if only to have a point of reference for restoring any customisations or mods that got borked. It's also an escape hatch in case the new version has grave bugs... *cough*mystery overheating*cough*. - - - Updated - - - This should have been fixed ages ago, rsync is not that complicated. Not impressed, Squad.

I don't, which may have something to do with it. It's at the point in a save where I have a bunch of off-world bases and stations in play that the stutter drives me away - I'm at this point again now, and it's all but unplayable for me. Hence the playing forum-kerbal and moaning about this issue. As I have commented in one of the other (numerous) threads on this issue, it appears to scale with size of save - i.e. number of active flights and debris (at least in my case, YMMV). Even having flags scattered around the system seems to contribute. Mods make a big impact, particularly MechJeb*. But even in a bone-stock game I see the stutter, once I have a few missions in progress. Deleting all my debris makes for some improvement, albeit a short-lived one. I have been suffering with this as long as I can remember - at least as far back as 0.16. I'd happily suffer a while longer in an early-access or beta game, but it's getting beyond a joke now - we're at 1.x and the game still feels like a tech-demo, creaking away on an outdated engine with memory leaks, bugs, and performance problems everywhere. I'm still thinking this must be a perception / expectation issue, I've seen it on two radically different hardware configurations myself, and many more configurations via the forum. Once noticed it cannot be un-noticed. * I did poke sarbian about this at some point, complete with frame-time graphs 'n stuff. He indicated he would look into it, and this may well be what motivated the development of GCMonitor. - - - Updated - - - The audio-stutter was fixed some time back, but I have a suspicion that the root cause (GC issues) has not been addressed - rather the audio playback moved out of the loop, so to speak.

Good plan. I've gone back to 1.0.2 until this mess is sorted out.

Is it just me, or is your camera focus dropping behind the craft at ~6KM? I've seen this issue before, and it's not the heating bug discussed here. At that time it was Realchute, that particular issue was fixed long ago but I do recall similar reports on the forum more recently. Sorry I can't be more helpful, I can't recall which mod was causing it this time around. Tweakscale? Maybe? Dunno. Have a look in your log, it may be obvious. Any non-stock parts on that craft?

This. This x1000. Yeah, I'm pretty confident that I know the cause... and the solution. I'd be really surprised if Squad didn't know it too. The real question is: Why hasn't it been fixed yet? [rant] I'm not Unitys customer, I'm Squads customer. And I'm not happy with the state of the product. It's not up to us to complain to Unity, Squad made the decision to license that particular engine, Squad is responsible for the "finished" (yeah, right) product. End-users hassle Squad, Squad hassles Unity. Same as any other industry. If Unity cannot be moved, work around it - the methods are well documented. There seems to be an awful lot of head-in-sand attitude here. Guess why I'm whining on the forum: Because I can't play the frigging game with this rubbish performance and stuttering. Enough. Stop. No more "features". Fix the damn foundations first. [/rant] A response from the team is all I'm after at this point also. It will not be ignored, and neither will this glaring issue. As Padishar rightly points out, there are areas of Squads code that create huge amounts of garbage thrash, I suspect this particular example is just the tip of the iceberg. So, again I ask: Any news on a code-cleanup and optimisation to address this? I'd really like to get to playing the game, without all the frustration this brings. I'd love to do some profiling, to attempt to find the worst offenders and contribute to a solution. But I don't have the source, or the tools. Squad does.

I don't think you're doing anything wrong... But the new heat system is pretty naf if you ask me. I guess that's just the way it is now. No more aerocapture unless you pack totally OP heatshields. There was a poll about this some time back... the options mostly boiled down to cheat or avoid.

"Autoland" does what it says on the tin, but it pays to get close to the runway and roughly lined up first. "Hold" IIRC, is a fairly basic altitude hold - it adjusts pitch to make climb rate == 0. Throttle control is still up to you, try not to stall And yeah, MJ can't handle the whole re-entry -> landing sequence by itself (yet?), you need to get through reentry and deceleration first. Re-enter, get into stable flight, then use MJ for the cruise to KSC and the landing.

You'd think that 'enhanced thermal' is the kind of stuff they'd actually test in beta, rather than pushing it out in a "hotfix". Hot, yes. Fix, no. What the hell happened QA on these new "features"?

There are many threads on this already, so I guess you could say it's a known bug... but I have seen no answers, and no acknowledgement by the devs. About all one can do at the moment is mitigation - turn conduction factor right down in physics debug. It breaks Squad's shiny new thermal system, but it's clearly broken anyway. As for how many ships will be affected... roll the dice. I've taken to using the "Ignore max temp" cheat and disabling conduction every time I get within physics range of a large ship, otherwise things randomly explode. Am I right in thinking those are all stock parts? Besides KER, what other mods are you running? Dunno what to do about this TBH, it's killing the game for me. Maybe if we make enough noise Squad will take note?

How about Dated QuickSaves? doesn't tick all the boxes, but at least it's a bit easier to work with than 'quicksave #'

As far as the BSD folks are concerned, Linux is the new kid on the block and most Linux users are not nearly bearded enough They also get a fair bit of "Why isn't it just like GNU/Linux, this is too hard" etc. etc. Sound familiar? In reality, they're not too different. Just don't directly compare BSD to Linux in certain company... red rag and all that.

FWIW, AVP (via CKAN) runs just fine at max-res on GNU/Linux x86_64... and consumes a gig or so of RAM by itself, even with ATM. Getting it to run on 32bit will be hairy. The only way to know for sure is to look in the logs, where memory crashes are blindingly obvious.

KSP should have been written with an in-house engine, in a real programming language - by which I mean native C. The fascination with these new-age lazy languages eludes me. Java? why? Call me old-school, but I can't think of a more inefficient way of doing business. OTOH, given the size of the dev team and available resources, Unity was probably the only viable solution at the time. Warts and all. The whole argument is flawed, why would Java make the game better? It's the engine architecture that's limiting here, not the programming language it's written in. You want faster? KSP should have been written in x86 ASM. Any idea how much work that would be?

I'm using your mod, and I've simply removed your FSFuelSwitch patch in favour of a global InterstellarFuelSwitch patch that applies to any and all LF/O tanks. Works a treat.So no, no objections at all My humble suggestion would be optional support - if IFS is installed, patch your tanks. Otherwise leave them stock-like. I take it these will operate like stock tanks if no fuel switcher is present?