Starwaster

Talk to RBray, I think he did something along those lines; I'm not sure if it was a standalone shader or if it depended on this....

Granted, except that you retain your velocity vector and instantly incinerate ... oh wait... this isn't the corrupt a wish thread? Edit: bug report update Got it Stupid Chris. It's definitely a stock bug and not Real Chute at all. I can reproduce it with at least one stock part, the large nose cone. Doesn't the cone chute part actually use a model that was based off of the nose cone mesh or do my eyes deceive?

Only the advice from the front page, start with shockwave exponent, begin increasing until you have the desired level of deadliness. Press alt-D+R, that opens the debug menu. You'll find shockwave exponent and temperature multiplier among others. An RSS Kerbin shockwave would typically be ~7700 or more, depending on circumstances. Stock Kerbin is going to be around ~2000. If you start getting too high you're going to need those RSS shields.

Then you should check in those forums for updates.

If you just updated to 0.24.1, you can probably ignore it. The version number changed so it's setting off warnings. Assume that it's ok but watch out for new bugs to appear.

That should make e-dog happy. And Chris, I have totally removed the RC plugin itself and can still crash the game placing the RC parts symmetrically. Sometimes I have to work it a bit, and it might take more than one part. i.e. it triggers on the second part I try with. They're also very hard to place symmetrically at all and I'm just not seeing why. I thought it might be the MODEL node, where only parts with MODEL{} would crash so I changed the stock parachute (mk16) to use a MODEL{} and that didn't do it. I thought maybe it was the missing surface attach node that was doing it so I tried removing Mk16's and adding one to the RC cone chute, to get the stock part to crash and RC cone chute to not crash but neither one worked. I just can't see what's different about those parts but there's something there... Maybe it's because it has more than one MODEL{} node but I've seen other parts that have multiple MODEL and they don't do that. So weird.

Chris, I am about 99% sure that it's not a Real Chute issue; at least not with the plugin. I'm still not quite sure where the cause lies but it's something about the parts themselves, because if I remove the RC modules from one of the RC parts, it still breaks symmetry somehow and crashes the game. Just to be sure, I'm removing the RealChute.dll file itself outright and running the game again. Suddenly got tired and fell asleep so I'm a bit fuzzy right now and something might have been flawed in my methodology but it actually seemed like it might have been surface attachment being enabled without a surface attachment node specified. And... wait WHUT??? 24.1? new procedural costs whut?

Ioncross specific resource usage is tracked. I'm not sure kill checks are run against inactive ships though... I thought they were but they might not be. I'm going to be checking on that.

Actually it's a version checker that each individual mod has incorporated. (or not incorporated) If a mod does't use the version checker then there won't be any warning displayed that that mod might have compatibility issues.

That could be a reasonable amount to assume for a Kerbal, but that figure would have to be uncompressed, 1 atm pressure. How much would a 1 liter tank in TAC actually hold? (and yes, I know I'm not phrasing it well)

Reposted log, pretty sparse and the only unusual thing I see is that at one point it says Windows 64 bit build detected even though I'm on a Mac.... OS X. Fortunately, the bug is easy to work around; it only happens if I place the RC part symmetrically. If I put it instead on a single part and then place that part (the parent) symmetrically, that causes no problems.... https://www.dropbox.com/s/m695kpn57qjpye7/Player.RealChute.Symmetry.CRASH.log (excerpt) [Versioning]: Windows 64-bit Build Detected. (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Launcher Settings File doesn't exist (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Launcher after checking file: True (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Load(Assembly): RealChute/Plugins/RealChute (Filename: /Applications/buildAgent/work/d63dfc6385190b60/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) AssemblyLoader: Loading assembly at /Applications/KSP_osx_0.24.0 TROUBLESHOOTING/GameData/RealChute/Plugins/RealChute.dll

Ok almost-new install. I left a few mods on like toolbar, MM and parts only packs and it still did it. However, it's not just any RC equipped part, like MM patched stock ones dont do it. Only the 'stock RC' parts. I tried a stack chute this time... I'm taking it down all the way to RC.. Candidate mods at this point... (just because they're still installed) toolbar module manager MyTweaks folder (I'll count that but I don't think it was doing anything to the parts in question... it's going bye bye on the next test run) RCS Build Aid SDHI (better not be that one...) SPD (THSS clone, parts only) StageRecovery StockDragFix TriggerTech (alarm clock) Packrat rover zzz's greenhouse Edit: Just crashed again with ONLY Real Chute. To refine my testing technique a bit further; same little probe thing, same structural fuselage things Put a RealChute part on top of one of the four outer parts and then started mashing the X key a buncha times. (real scientific here) The first time, four ghosted RC parts appeared, 3 of them red. Second keypress and I could sort of tell that there was more than one RC part occupying the target part. Probably all four. Then crash. Reposting player.log (maybe it'll be more informative with no other mods) That's the other thing though.... I'm on a Mac. Maybe it's Mac specific:( Can any other Mac users try testing that out? Just plop a probe core, an empty structural fuselage (it has literally no part modules) on top of or under the core. Then four more symmetrically placed. Then put one RC part on one structural piece and go crazy on the X key (symmetry)

Thanks for demonstrating that! That Could be a boon or a curse. It could offer more flexibility but it also makes means that :NEEDS is less reliable in determining if a mod is really installed or not. Any config containing FOR will make future NEEDS invalid. Yeah, curse, not boon. Does it do it for BEFORE and AFTER? Ok heres the thing, Bison Steve. If you come in to any thread asking others for help or reporting a bug, then You will let us decide if we need logs or not and which logs we need. Nobody cares if you crashed or not. I'm not trying to be mean and that's candor and not sarcasm. output_log.txt (or player.log for linux or mac) contain too much useful information to do without. Period. Clarification: Logs are always left behind. Crash or not. If you don't know where to find your log then say that and we'll tell you where.

And the error is non-specific as to any mod at all. great. going to have to pull things off one by one. I'll start with RF, I think its the only other mod I have thats really active in the VAB. Oops and Procedural Fairings and RCS build aid but I doubt the latter

Ok Stupid Chris (I want to call him Real Chris for some reason...) Sorry I gotta do this to you but it's bug reporting time. Symmetrical bugs! (everyone else feel free to try to repro this when you get a chance) Log file! (See what I did there? He needs me to provide a log and not just say 'it's broke') What I did to trigger this: Went into the VAB Put down a probe core Added a structural component underneath Added four more (using symmetry mode) Took another structural piece in single mode, put it on top of one of the four outer parts (did not drop, just hovered the part over until it turned green) Then I pressed X for symmetry mode. The image below depicts this. Then I clicked to place. That's just the control group so you can see what I did with the Real Chute immediately after. However, repeating that with a real chute threw a KSP crashing error on step 7. (unhandled null exception)

The problem with implementing that is that the system is really generic as far as the code goes. It only knows that it can successfully request or successfully add a resource and if it is unsuccessful, can Kerbals die from it. So what's happening behind the scenes is that CO2 reaches capacity, Ioncross tries to add more CO2 and is not successful. So it looks at the CO2 definition which says 'Kerbals can die' so it rolls its virtual dice to kill them. I don't think it's really threshold aware. I'll have to look at it and see what can be done to it.

That habitat had a kerbal head peeking...

It's better than the reindeer with the creepy $&@ digits wriggling and writhing....

maybe. we'll see

I had a thought though, I'm not sure if that 10% is by volume or density.... that needs to be researched.

Right, so new update coming. Nothing very big, no new parts as I still have no modeling capabilities. Hoping to have a new machine one of these days but things are tight So, this is what was added: GingerCorp as an agency that you will see offering contracts. GingerCorp 5/8 poittnt hub parts now have a testing testing module so that you can get part testing contracts from GingerCorp. This last part I'm still in the midst of testing; I can't make them show up, at least not through config file alone but if I've interpreted how the system works, hub testing contracts should show up from time to time.

When picking an agency for a contract, it depends to some extent on the agency's mentality that you set up for it. Some mentalities are suited to certain contracts and some aren't Also, if you further want to influence your agency showing up, I think it helps to have some parts whose manufacturer is the same as the agency name. I'm not sure if this next part helps or not but I added this to GingerCorp's station hubs so they could show up in part testing contracts. So far, it hasn't but I think it will help. We'll see. Some of the fields I found from looking at similarly configured parts and some from trying to set one up in code and seeing what fields it had. (those are commented out; I'm not sure they can be configured in parts, they might be internal only or manipulated through contract code) MODULE { name = ModuleTestSubject // nowhere: 0, srf: 1, ocean: 2, atmo: 4, space: 8 environments = 9 //TestNotes = Give the hub a thorough checkout. Check plumbing and wiring conduits for leaks and shorts. //isTestSubject //isExperimentalPart useStaging = False useEvent = True }

I'm using them...