steve_v

Yeah, I should'na yelled. Sorry. It's not the same playing without IR but every time I install it, sooner or later something like this happens. That pic of yours looks very much like what happened to one of my rovers recently.

'tis not just that the IR parts move beyond the intended range, that I could deal with. Rather that _other_ parts end up in weird positions - the latest (and most extreme I have seen) example was a vessel consisting of: [transfer stage engine][transfer stage tank 1][transfer stage tank 2][octagonal strut][decoupler][folding plane with 2 rotatrons] I make the mistake of opening the wings to expose solar panels, and... After switching back for a mid course correction I find that the [transfer stage tank 2][octagonal strut] section is now ~100M away from the rest of the vessel, yet somehow still connected to it. Camera thinks COM is somewhere in the empty space between. Get annoyed, hyperedit same craft into orbit, go fly a probe for a bit, return: wing joints look like the ziggurat Don't stress, I'll live without it. Was kinda looking foward to flying that thing on Duna tho. EDIT: a bit more than 100M actually: http://imgur.com/GIvd4jw

It varies, right now the list is pretty long: MechJeb2 AGExt TweakScale ThrottleControlledAvionics HabitatPack R&SCapsuledyne OpenResourceSystem SelectRoot FMRS NearFuturePropulsion EditorExtensions NearFutureSolar ShipManifest PartAngleDisplay AutoSave SpaceplanePlus ImprovedChaseCamera FerramAerospaceResearch StageRecovery ProceduralWings ProceduralFairings RPM Kerbaltek KerbalJointReinforcement KAS KSPStockTweaks Firespitter TACLS RCSBuildAid NearFutureElectrical FShangarExtender RealChute KerbalIspDifficultyScaler ProceduralFairings KSPX Achievements CrossFeedEnabler TweakableEverything AntennaRange AlignedCurrencyIndicator CustomBiomes NearFutureSpacecraft KAX NavInstruments NearFutureConstruction KAC ScienceAlert DeadlyReentry KerbalEngineer VesselView B9_Aerospace (R5 prerelease & its deps) KWRocketry MKS/OKS DockingPortAlignment SH_mods FinePrint SCANsat That said, IIRC I've been having this issue since ~0.20 and the list was a lot shorter then Can't remember if the same was happening with Damned Robotics way back when or not.

Believe me, if I knew how to reproduce it I would let you know in a flash. As for debugging it myself, as much as I would like to I simply don't have the time to a: learn a new language, totaly useless in my day job & b: figure out someone elses code from scratch. Unhelpfull as it is, all I can say for sure is that it only happens to vessels with IR parts & only happens when I'm not looking I agree that many do appear to be using it without issue, however isolated cases have been appearing for a good long while now. So be it I guess.

And just found another. BYE BYE IR. guess I'll come back in another year, or whenever the dreaded lousing up part attachment bug is sorted.

And again, another vessel trashed, another save file corrupted. This time a fuel tank ~100m away from the rest of the craft and somehow still attached. Hell, the displaced parts weren't even directly attached to any IR part. Once again, nothing in the logs. Only common thread: IR parts not in rest position when switching away from craft. What gives man? This just isn't usable in this state.

FWIW, I get this too & I'm also using tweakscale. Will test without, tomorrow - 'tis 3AM here, damn KSP time sucking wormhole.

Hrm, maybe drop heatproduction in closed cycle a tad more, I'm still not getting full throttle in vac with the original values... EDIT: seems "@MODULE,0[ModuleEnginesFX]" flat out isn't working according to the (awfull) MM docs it should. "@MODULE[ModuleEnginesFX]:HAS[#engineID=AirBreathing]" doesn't work either, WTF? Nope, not @MODULE[ModuleEnginesFX],0. this is ridiculous. That said, simply leaving the b9 values alone (maxtemp = 3600) does solve the overheating - bit unrealistic though. Buggered if I know.

Try this dirty hack: b9_r5.patch --- DeadlyReentry_B9.cfg.orig 2014-08-28 17:30:55.255283485 +1200 +++ DeadlyReentry_B9.cfg 2014-08-28 18:15:31.193226732 +1200 @@ -1220,19 +1220,16 @@ reflective = 0.25 // 10% of heat is ignored at correct angle } } -@PART[B9_Engine_SABRE_M] +@PART[B9_Engine_SABRE_M] //Nicked from the config for rapiers { @maxTemp = 1800 - @MODULE[HydraEngineController] + @MODULE,0[ModuleEnginesFX] { - @primaryEngine[ModuleEngines] - { - @heatProduction = 225 - } - @secondaryEngine[ModuleEngines] - { - @heatProduction = 275 - } + @heatProduction = 225 + } + @MODULE,1[ModuleEnginesFX] + { + @heatProduction = 275 } MODULE { @@ -1242,19 +1239,16 @@ } } -@PART[B9_Engine_SABRE_S] +@PART[B9_Engine_SABRE_S] //Nicked from the config for rapiers { @maxTemp = 1800 - @MODULE[HydraEngineController] + @MODULE,0[ModuleEnginesFX] + { + @heatProduction = 225 + } + @MODULE,1[ModuleEnginesFX] { - @primaryEngine[ModuleEngines] - { - @heatProduction = 225 - } - @secondaryEngine[ModuleEngines] - { - @heatProduction = 275 - } + @heatProduction = 275 } MODULE {

Has anyone updated the .cfg for the upcoming B9 5.0 release yet? A fair bit looks to have changed, esp. regarding engines... It's not released yet, but when it hits there's going to be some demand for an update here too

This is looking very shiny indeed Thank you. Words fail to describe how annoying this issue is. I have had a .cfg to drop sidewaystiffness in place for some time, it doesn't 'fix' it as aircraft design is needed too. It does help though, rather a lot. On a side note, the Sabre precoolers (and possibly some other parts, haven't tested extensively yet) don't update dry mass when *attatch with symmetry* -> *switch tank mode*. The fuel values are mirrored to symmetry counterparts, but not the dry mass. It's easy to fix by cycling through modes, but has to be done after every .craft load. *Correction - only if removed, then re-attatched in symmetry, much like action groups are lost when doing this.

Cheers boss, exactly what I was after. Might have a crack at it tonight It's not that SP+ is missing anything important, but it does make the issues with B9 stand out. @Space Cowboy; That's a damn fine looking ship. How are you recovering the mothership? it would be a shame to leave it to crash...

With that in mind, (and yes, I know it has nothing to do with SP+) has anyone a handy MM config to fix the B9 parts? Or are we all just hoping it'll be fixed in the 5.0 update? I'd do it myself, but I'll need instructions

Too true, although disabling various default stupidity (like autorun) helps. I cringe every time someone grabs that usb drive from their keyring... where has that been? is it clean? are you sure? etc. USB ports and floppy drives (yep, still need em sometimes) on mission critical systems are generaly inside locked cabinets, along with the rest of the machine. Usualy with some scary looking electrical stuff just for good measure , this has the added benefit of protection from human interference. Some of the systems I have to deal with are so old that updates / antivirus is simply not available anymore so the only option is to isolate the hardware. - Try finding a box that can accept ISA cards AND run a supported OS, I dare ya. You have the key, you plug in the foreign device, you had better know what you're up to. I will dig out the disk image if you screw it up, but it will cost you lunch ;-) My preferred solution would be to... NOT run Windows, or DOS for that matter. But what can you do. I know of a recent incident where someone.. not naming names, but higher up the food chain than me, decided to use a SINGLE micro SD card as the only backup for critical automation programs... you can guess how well that turned out.

Antivirus? what's that? My one and only Windows install is entirely expendable these days (i.e. the last 10 years or so), has no write access to network resources and simply gets nuked & restored from image if anything nasty* happens to it. *Most often a botched update, haven't seen a virus / malware in years. Any Windows boxen I have to work with professionaly are airgapped and/or 'not my problem' AFAIK the only production ready 'next gen' filesystem is ZFS on BSD or Solaris - the GNU/Linux port is stable, but still slowish. I'm waiting patiently for the rest to catch up, but with todays disk capacities bit-rot is becoming a problem, likewise rebuild times on traditional RAID. On the other hand, backups become simpler as large externals get cheaper - tape drives are / were pretty horrible if you ask me. I even used CDRs for backups for a while, bugger that for a joke, 'oh noes, disk 19 of 47 has a scratch...'

Not IME. Most consumer RAID cards, GNU/Linux/BSD soft RAID (Never used Windows soft RAID but I assume it's the same) do _no_ consistency checking until you run a 'scrub'. A bad sector can go undetected until it needs to be read - i.e. during a rebuild, this can ruin your day in a big way. Files aren't checksumed either, so data integrity checks are up to you. ZFS, BTRFS and ReFS solve these issues RAID (any level but 0) is more about availability, i.e. you can still use the array while a disk is hot-swapped. As such you still need a backup in case things go really pear shaped. I once had a dodgy sata connector (I snapped the plastic 'tongue') that would silently corrupt data on a software RAID1 Had fun with RAID5 back in the day too - it's just a matter of time until 2 drives fail within the rebuild window... Backups are not optional if you value your data. My current setup, FWIW: OS array: 2x160GB, 10K RPM as software RAID1 (daily scrub + checksums of OS files) Data pool: 8x2TB, 7.2K RPM as ZFS RAID-Z6 (checksums on, compression on, daily scrub) with 1x60GB SSD as cache. Hourly & daily inceremental snapshots of data pool - snaps are virtually free with ZFS, neat. Daily snapshots of _critical_ ZFS subvolumes + OS array rsync'd (incremental nightly, deleted files purged weekly) to external USB3 4TB drive. Remaining ~6TB of data pool is not backed up as it's all replaceable. A bit OP for a home server perhaps, but I like shiny toys.

Bugger. I just knew you were going to say that. Anything I can grep for in the logs while waiting for it to happen again? i.e. debug prefix specific to IR?

I take it you're not running FAR / NEAR / AJE then? With the current release of FAR basic jets won't go much beyond mach 1 so while reaching those altitudes is possible, staying there is another story.

I'm seeing this too, also happened to me with 0.23 & 0.23.5. Stopped using this mod for that reason. Thought I'd give it a go with new 0.24.2 game, still the same. I _hate_ using hyperedit to replace bugged craft, does anyone know what's going on here? This always seems to hit while I'm flying some other vessel - I switch back to my rover only to find e.g. wheels several meters from the chassis yet still somehow attatched. I just did a couple of quickload / save cycles with robotics parts in various positions, ditto vessel switch. I can't seem to reproduce it, so I can't provide a relevant log at this point. I did see NullReferenceException: Object reference not set to an instance of an object at Part.force_activate () [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 Just after loading a bugged craft (the only error in log file) but I don't know if it's even related as I can't pin down exactly _when_ this happens - by the time I realise, it's too late. Any help narrowing this down would be much appreciated.

My android is old, slow and cheap. It's not shiny or bling, it's scratched and glued. Most of the software on it has been recompiled, modified and hand picked by *me*. 98% of that software is free - not just as in beer, as in *freedom*. (bar those damn binary cell modem drivers) It's 3+ years old and has 1.5x the battery life it had new. It's overclocked and runs everything I need it to as fast as I like it to, despite being 'only' a single core. Google does not have my data, I ripped that bit out pretty quick. I run my own server, I vet my own apps, I store my own data. In short, its *mine*. Because it's *hackable*. The Linux kernel is just icing :-) If you like being limited to what Apple (or any other vendor for that matter) thinks you should be able to use your device for, knock yourself out. I couldn't stand it. When Apple opens the OS code and stops using anti-tamper screws, I might just buy an Iwhatsit. Maybe. Oh, and enough with the patent war BS, not buying anything from a company that pulls that crap.

Or run GNU/Linux Rock solid at 6.5GB RAM usage here - actually I don't recall a *single* crash that wasn't my fault. Of course it'll only be a matter of time 'till the Windows build catches it.

This is one seriously slick mod, small spaceplanes just got a whole lot more interesting Jeb approves, and so do I. Quick question: Is there a reason the mk2CrewCabin has crashTolerance = 6 breakingForce = 200 breakingTorque = 200 whereas say, mk2Fuselage_L, has crashTolerance = 50 breakingForce = 50 breakingTorque = 50? Experimental testing (read: droping on the runway) confirms; the crew cabins are indeed far more explosive than any other fuselage part

Read through the thread, a fix you will find.

I thought as much, seems people are using the git version of FAR and wondering why it doesn't work.. sigh.

Vertical stabilisers with comparable lift / area to the main wing will cause serious problems with roll stability - at least with real planes (or so I have read ;-) @ferram4: Please do remove the COL vector indicator, I for one have been ignoring it for some time.