FlowerChild

Well, I dunno man. My (again limited) understanding is that FixedUpdate() is a Unity engine function that handles physics updates, while OnUpdate() is specific to parts. Thus, my assumption would be that if there's any game specific updates that need to be done, such as handling any cleanup that happens when parts are destroyed, it would occur on (or after) OnUpdate(). If performed outside of that, I would theorize that perhaps the game's update loop isn't even aware that a part has been removed and thus an invalid state may result. It's all just guesswork on my part since we don't actually have access to the code base, but that's what my instincts are saying. I know that when I created my module I just naturally leaned towards updating within KSP updates rather than the engine's because they seemed to be happening at a higher level. Anyways, crossing fingers that's what is going on here. I must admit it's rather odd to be coding without being able to see the code base or at least having access to documentation on what's occurring under the hood

From my (admittedly limited) understanding, loss controls how fast your ablative shielding is consumed at specific temperatures, while dissipation controls how much heat is dissipated at certain temperatures. At temperatures in between, the rate of loss and dissipation are interpolated between the values specified, so in other words they will be somewhere in between. With the example you provided above then, the part begins dissipating heat above 300 degrees, and your ablative shielding starts getting worn away above 650. While both values appear as zeroes, that's the point at which any further temperature increase will start slowly increasing the values until the next specified temperature is reached (so between 650 and 1000 degrees, your rate of loss is somewhere in between 0 and 64 in the above example). Basically, as temperature increases your rate of loss and dissipation also increase until they hit the specified maximums.

Well, with my limited knowledge of the DR code (and KSP modding in general...I just started poking around in this code base a couple of weeks ago), the only real difference I can see is that the DR code seems to be operating on FixedUpdate() as opposed to the OnUpdate() override of partModule that I'm using. Is it possible this is causing the parts to get destroyed outside of the regular KSP part update loop and thus is being handled differently? Also, I just noticed that in this portion of the DR code: public void FixedUpdate () { if (dead || !part.Rigidbody || part.physicalSignificance == Part.PhysicalSignificance.NONE) return; Fields ["displayShockwave"].guiActive = ReentryPhysics.debugging; Fields ["displayGForce"].guiActive = ReentryPhysics.debugging; Fields["gExperienced"].guiActive = ReentryPhysics.debugging; Vector3 velocity = (part.Rigidbody.GetPointVelocity(part.transform.position) + ReentryPhysics.frameVelocity); part.temperature += ReentryHeat (velocity); displayTemperature = part.temperature; CheckForFire (velocity); CheckGeeForces (); } It's possible for CheckForFire() to blow up a part, and then the CheckForGeeForces() function will still be executed on it regardless. Again, no idea if that would be related, but seems to be a similar source of potential issues to what I pointed out earlier today. And yeah, I get the UI freeze 100% of the time when a vessel burns up on reentry, but have yet to ever run into it when my cockpits explosively decompress, so it looks like there's something funky going on here

It's a part module, and the fields tested within OnUpdate() are fields set within the part config file: public class BTSMModulePressurizedCockpit : PartModule { [KSPField(isPersistant = false)] public float minSafePressure = 0.5F; [KSPField(isPersistant = false)] public bool explodeOnFail = false; }

Ok, just ran the above test with my cockpit code, and no, it didn't trigger the UI bug. Very strange. I'm basically doing the same thing the DR code is, checking for low atmospheric pressure in the update function of a partModule I've added to the cockpit, and blowing it up with a part.explode() call if it drops too low. Just in case you spot something I'm doing differently that I didn't, here's my code for the cockpit: public override void OnUpdate() { base.OnUpdate(); //print( "BTSMModulePressurizedCockit: On update" ); Vessel currentVessel = FlightGlobals.ActiveVessel; if ( currentVessel != null && currentVessel == vessel && currentVessel.state != Vessel.State.DEAD ) { if ( currentVessel.orbit.referenceBody.bodyName != "Kerbin" || FlightGlobals.getStaticPressure() < minSafePressure ) { //print( "BTSMModulePressurizedCockit: Below safe pressure of " + minSafePressure + " at pressure of " + FlightGlobals.getStaticPressure() ); if ( explodeOnFail ) { ScreenMessages.PostScreenMessage( part.name + " failed due to explosive decompression.", 10F, ScreenMessageStyle.UPPER_CENTER ); part.explode(); } else { KillContainedKerbals(); } } else { //print( "BTSMModulePressurizedCockit: " + "at pressure of " + FlightGlobals.getStaticPressure() + " With safe pressure of " + minSafePressure ); } } }

Oh, I didn't mean to imply there was any offense taken man. Sorry, my writing becomes rather blunt when I'm talking about coding matters which tends to be easy to interpret as something other than my intent No, and that's something I was thinking about as well. It's only the cockpit itself which I'm blowing up in my code, with the rest of the craft quickly following by whatever vanilla code causes that to happen. The other thing I've been wondering about is whether it's actually the DR code which is destroying parts on overheating, whether the vanilla code for doing the same kicks in, or whether there's some weird overlap between the two. Since you mention the last part bit, one thing I might try with my cockpit code is running a test where I use stack separators to make the cockpit the only part left on the vehicle when it hits vacuum to see if it triggers the bug.

Fair enough man. I didn't think it was necessarily related but just wanted to pass it along in case it was causing any other issues. The clicking bug is a rather odd one, as I'm blowing up parts in my own plug-in, and it doesn't seem to cause the same UI problems. Specifically, I'm blowing up pressurized airplane cockpits when they enter vacuum, and I'm always able to return to the KSC UI without issues afterwards. Other than the above though, I couldn't find any notable differences between the way DR is doing it, and the way I am.

@Nathan While trying to see if I could figure out what was causing the frozen interface issue when a rocket blows up due to overheating (it's getting rather tiresome as I run repeated tests to balance values), I dug into the DR code a bit and noticed this: if (damage >= 1.0f && !dead) { dead = true; FlightLogger.eventLog.Add("[" + FormatTime(vessel.missionTime) + "] " + part.partInfo.title + " exceeded g-force tolerance."); part.explode(); } You'll notice that unlike the overheating code, it doesn't bomb out of the function after the call to explode, and then potentially goes on to process g-force effects on any contained crew. Not sure if it's directly related to the interface freezing effect, but I thought I should point it out as I suspect it could result in now invalid data in an exploded part being processed further, which likely isn't a good thing

Cool, thanks for the info guys. At least I can stop worrying that it's something I may have messed up.

Strange. I can replicate it 100% of the time burning up on reentry and have run repeated tests to make sure that's the source, whereas vessel destruction from other causes doesn't seem to trigger it.

I'm running into a bit of an issue here where it seems like the UI for the game stops recognizes clicks on buildings and such after a vessel burns up on reentry and you click on "return to space center". Afterwards, the only button that seems to still work is "quit" and when you return to the main menu, all controls are frozen as well. Anyone else encountering this? I am trying to figure out if it's a local issue, a known vanilla bug, or something to do with DR.

Ok, after playing around with multiple values last night, I'm finding that a value of 1.09 for shockwaveExponent makes for a good "game" (not realism) setting with stock KSP. Parts begin to really start to burn up around the same time as the vanilla reentry effects kick in (they still heat up significantly before then but the "danger zone" really kicks in around the same time as the effects) , and you'll still tend lose all your unshielded parts even on a decent reentry angle returning from LKO, so the gameplay considerations of having to deal with reentry remain largely intact. Higher values tend to result in your ship burning up higher in the atmosphere (I think you were right there Nathan and there's an atmospheric pressure dependency on the effect), while lower values tend to result in some unshielded parts surviving reentry (particularly engines which have a higher heat tolerance, and can be used as improvised heat shields as a result). Now to start playing around with the shield values to find a corresponding balance

Hehe...that's kinda my thing. I tend to play the crap out of games I love and modify them incrementally to get the precise results I want, so entirely my pleasure A small bug report: it appears that you can't enter decimal values into the tweaking window you have. Whole numbers are accepted fine, but trying to type a period in to create a decimal has no visible impact. Saving the results, closing, and reopening the window, also doesn't display any typed decimals, so it doesn't appear to just be a visual thing.

You're the man Nathan! That would be absolutely awesome, and since this thing isn't even close to a public release yet, I'm certainly willing to play around with multiple approaches to get it working while I work on tweaking values. If there's anything I can do on my end to facilitate this, please don't hesitate to let me know.

Huh...strange. I'll poke around in the code a bit and see if there's anything I could do there. Ultimately I'd like players to get that kind of visual feedback when their craft is really in danger. Yup, and I do very much want to get unshielded craft to burn up on entry, I'm just running tests on unshielded craft multiple times to try and tweak the numbers so that it "feels" right in stock, before moving on to tweaking the shield values so that when you *don't* burn up also feels about right I plan on doing a rather extensive tweaking pass on the values today to try to get them where I want for a good "game" feel with a stock install, and I'll definitely share the results. What I'm basically aiming for is "if Squad implemented reentry effects into stock KSP, what would it be like?". If I do my job right here, hopefully it will provide decent values for "vanilla" players that are just looking for a little more challenge and to make reentry an actual gameplay consideration. Fair enough. What I'm aiming for is to make the project I'm working on as little of a hassle for players to install as possible, so that they can just plop in the required mods, and run it as is without tweaking any values themselves. I guess it would help if I described it a bit so you'd have an idea of what I'm aiming for: basically my plugin/mod (it's a bit of both) is a rebalance of vanilla to provide meaningful career mode progression in gameplay terms, but is not at all realism centric. I just want to include certain aspects of realism such as reentry effects for the gameplay considerations they provide like "don't try to reenter the atmosphere with a landing module". To that end, I intend to have a number of "realism mods" as required installs to go alongside of it, Deadly Reentry being the first. I guess you could look at it basically as if Squad decided to make career mode less of a tutorial, and more of an extended gameplay experience (which is what I was hoping it would be), but done in the spirit of stock KSP where it's a very "soft" form of realism and the focus is more on gameplay. Kinda semi hardcore but not all the way. Since I'm balancing everything relative to each other to achieve that effect, I'd very much like it if players could just install everything as-is and go. Anyways, if you're interested in learning more, I have a WIP thread going for it on my own forums ( http://www.sargunster.com/btwforum/viewtopic.php?f=8&t=8146 ) as I'd prefer not to do a public release until I've at least done a first past at balancing the whole tech tree. Right now, I'm only up to tech level 6, where I intend to focus on Mun landing, which is why the whole landing vs command module question is coming up. So yeah, to make a long story short, if there's any way I could modify those final values from a config file in my own plugin directory without requiring players to manually mess with them, that would be awesome

BTW Nathan, I tried it out last night at 1.17 and with stock, and I think that value might be a tad high in terms of getting desirable gameplay results. What it's tending to result in is unshielded craft on a reasonable reentry trajectory burning up in the upper atmosphere way before the stock heat effects kick in (the flames surrounding your vessel), which becomes rather confusing as you're not really getting much visual feedback that you're in danger. Just wanted to let you know about this, as I suspect you will likely be dealing with a lot of people asking questions about this kind of thing. I'll play around with some additional values to see if I can get a number that feels intuitive with stock, while perhaps not being entirely realistic, and report back with my findings. Also, is there any chance that you would consider making some of these values non-final? In a remarkable coincidence, when you answered my question about such things in the MM thread the other day, one of the plug-ins I was hoping to tweak was this one

Thanks a million for this man. Will give it a go.

Ah, fair enough. Thanks for the answer! I was getting it to run just fine, I just couldn't get anything to burn up on reentry for the life of me, no matter how steep and fast I came into the atmosphere with no shielding. So yeah, at present beyond not being that hard, it basically has a non-existent impact on stock I did manage to burn up (rather quickly) by setting temperatureExponent as high as 2.0, so I do know it's working.

Quick question here Nathan: The exponent you're referring to above, is it the one represented by the following line: @temperatureExponent = 1.03 In the current version's config file, or is it something that isn't actually in the plugin yet? Like the global multiplier you were considering adding above? I'm a little confused how to get DR to work right with an otherwise stock game, or if that's even possible at present.

Ah! Thanks a million man! I just checked back over the OP as I hadn't noticed that in my last read through, so my apologies for the brain-fart that resulted in me asking a question that was already clearly answered there

I was just wondering if there was a way to specify the order in which various .cfg files are processed by MM. I'm currently working on a mod/plugin that's intended to be played alongside others but which will likely need to modify values that others are also modifying through MM to get the whole thing to be balanced between the individual mods involved. So, is there any way to specify a change as being a priority one? Are the directories involved reliably parsed in alphabetical order for example where I could just plop my .cfg files in a "zzzMyMod" directory to ensure it gets processed last? Any help would be appreciated.

On the contrary, you seem to be missing the point about us talking about how *0.22* affects probe design, as opposed to whatever features may come in the future.

Errrr...isn't that what sandbox is for? To my mind, career is meant to put a layer of gameplay on top of that and provide gameplay reasons for why you're doing any of this stuff. We can get philosophical and say there's also no need to play the game or take it even further and say there's no need to keep on breathing. However, I don't think dissecting and invalidating the concept of "need" is a particularly constructive approach to this kind of conversation I'm simply trying to clarify why people in this thread seem to be saying they feel an increased "need" to build probes with the new release, when I've found the exact opposite to be true. Within the context of sandbox we were doing everything "just because", but in career we are operating within certain defined constraints. I just don't get how any of those constraints serve to encourage the building of probes rather than discourage it (which is what I'm finding it's doing).

Well, one of those limitations is that you don't have access to probes early on in the tech tree, so I don't really see your point there. Also, there's no *need* to rescue your Kerbals, you can just leave them wherever they are and they'll keep on smiling, so I guess they're cool with it. Maybe if some kind of cost is eventually associated with losing Kerbals this will work a little better, but at present, I just don't see any need for probes other than whatever roleplaying justifications we ourselves create as players.

Well, there's no *gameplay* reason at present to care, no. Kerbals are an infinite resource, and better at accumulating science than probes. The "manned before probes" tech progression also encourages us to treat Kerbals as expendable, so it's something that's being reinforced by the design as well.