Jump to content

FlowerChild

Members
  • Posts

    754
  • Joined

  • Last visited

Everything posted by FlowerChild

  1. Gratz on the stockitude man. I've been tempted on several occasions to add support to BTSM for Fine Print, and I think it'll be a great addition to stock.
  2. On the "things that affect BTSM" front, it would be awesome if there was a config file setting to remove/disable that button or ignore the selection. I've basically balanced the mod for a single set of values, and I've already had a player expressing confusion in my thread as to which DR difficulty option is supposed to be selected with BTSM. I realize the button is not yet active, but it gives me an indication of the tech support that will come from it
  3. It's strange because I was under the impression that fuel lines reinforced in the exact same way as struts. I was wondering if the FuelLine class might actually be a child of StrutConnector, but visual studio is telling me it inherits directly from part. If it isn't a child, it's possible though that it has a more robust explode function (or onDestroy() ) than StrutConnector which appropriately detaches the joint.
  4. Yup, my fix appears to work well. Changed the following: if (damage >= 1.0f && !dead) { dead = true; FlightLogger.eventLog.Add("[" + FormatTime(vessel.missionTime) + "] " + part.partInfo.title + " exceeded g-force tolerance."); // FCMOD if ( part is StrutConnector ) { ((StrutConnector)part).BreakJoint(); } // END FCMOD part.explode(); return; } and if (!dead) { dead = true; FlightLogger.eventLog.Add("[" + FormatTime(vessel.missionTime) + "] " + part.partInfo.title + " burned up from overheating."); // FCMOD if ( part is StrutConnector ) { ((StrutConnector)part).BreakJoint(); } // END FCMOD part.explode(); return; } And it appears to work perfectly. Turns out I was wrong about my assumption that this would apply to fuel lines as well. I anticipated having to add another test for them, but just ran my test case with the above, and all parts detached appropriately despite some fuel lines being burned up along the way.
  5. Unfortunately no. I'm testing all this with BTSM, and a good number of the parts have modified values as a result.
  6. I just put together a potential fix which I'm testing out right now. Will let you know how it works out. I have a good test case here for something that I suspect may be hard to generate one for, and I suspect I know how to resolve it, so I figured I'd lend a hand with it
  7. It feels to me like whatever physics connections are created by the struts aren't being destroyed when DR destroys the struts due to heat, but when the decoupler separates, since struts are no longer connecting the two pieces, it isn't deleting those connections as it normally would. I suspect the same thing applies to fuel lines BTW. I had both on that vessel, and some connections were "fused" that didn't have any fuel lines attached, so it happens with struts alone, but I can't confirm it happens with fuel lines alone given all the connections I had with them were also strutted. It does make some sense though since struts are physicless parts that automagically apply physics through their connections. They must be a big exception case internally within Squad's code, and may have their own data structures which govern those connections. EDIT: Checking the strutConnector class, I notice a "BreakJoint()" method, while the FuelLine class has a corresponding "BreakLine()" method. Not entirely certain, but I strongly suspect that calling those methods right before destroying struts or lines would do the trick.
  8. Just noticed a small issue: It turns out if struts are destroyed during reentry, any decouplers within the area the struts previously connected cease to function (like if you strut a radially attached tank to the main body with a radial decoupler in between and the struts connecting the two burn away). You can trigger them, the sound effect is played, but the parts refuse to separate, although they no longer seem to be considered part of the same vessel. This seems to apply to docking ports within a previously strutted area as well. I just noticed this on the same ship I previously posted screenshots of as I was giving my old Jool aerobrake test a go with the new release. On one hand, it's kinda cool, as it almost feels like the parts were fused together or something. On the other hand, it can definitely feel buggy depending on where it happens on a ship. EDIT: Another small one: In the space center view, a small sliver of an icon appears (just a few pixels wide). If you click on it, then what appears to be a WIP DR difficulty menu appears.
  9. I definitely will, but at the moment I'm looking forward to a break from all the aerobraking tests I was doing the past couple of days and want to be able to provide an answer for BTSM players as to which version of DR is meant to be installed with it And yup, found the config setting in the source. Don't worry about the GUI, at least not on my account, as all of BTSM's changes go through the config files via ModuleManager, so the way it is now is ideal for me.
  10. Yup, absolutely man, and I very much appreciate the consideration BTSM is primarily about a tightly balanced experience, where every change made tends to affect 10 other things, so pretty much anything is bound to affect it one way or another and require a certain amount of tweaking on my part. Nothing that can really be done there other than me adapting to changes as they are made, as I can't really expect you to hold back development of DR on BTSM's account. I run into the same thing with pretty much every vanilla update as well. Knowing why something is of benefit however always helps in that department, at least with regards to my own sanity, so I hope you forgive me if I pop up here every once and awhile asking that question. I think Rowsdower is getting fairly used to me asking Squad the same thing pretty regularly
  11. Thanks for the detailed explanation man, and it makes a lot more sense for me now. I'm a big fan of being able to bring more diversity to each individual planet, so if these changes expose variables that make that a greater possibility, I'm all for it. Yup, I can definitely understand that as well, as I'm of course interested in trying to ensure that stock sized Kerbin, stock aero, and by extension of that, BTSM, don't get left out in the cold either
  12. I feel compelled to ask "why?" on the point of having different densities with stock aero man. Does it really bring anything to the game or is it just realism for realism's sake in a way that won't really be noticeable and may introduce additional bugs? It's not like stock is in any way realistic in the first place. Any chance for a config file setting to disable that and just use the old vessel.atmDensity bit? Don't get me wrong, I really appreciate the work you've put into resolving issues here, but I'm admittedly a little leery of additional changes in this regard given the problems that have arisen.
  13. Cool cool. Thanks for that. I'm currently testing my Jool aerobrake with your latest version and everything seems to be working as intended. Just as a small note about the above though: you might want to consider changing it to the part's vessel rather than the active one, as it's possible to have multiple vessels within physics range (particularly shortly after separation), with some in the atmosphere or not, or at varying altitudes. Might generate some weird effects to have them all drawing pressure from the active vessel then
  14. Ah, ok, I misunderstood your post then as I thought you were saying that you were just bounds checking on absolute zero in order to prevent the NaN's but this was causing no reentry heat to occur in those situations. From the current code on GitHub, I'm also seeing this density = (float)(part.vessel.staticPressure * 101325 / (287.058 * (part.vessel.flightIntegrator.getExternalTemperature() + CTOK))); Whereas locally I have replaced it with this: density = (float)vessel.atmDensity; for testing purposes, which as far as I can tell reproduces the old behavior.
  15. Is the idea with this to use vessel.atmDensity when FAR isn't installed Nathan, similar to how it used to function? Just wanting to compile a version locally so I can continue testing BTSM in the meantime. BTW: I also wanted to put out a specific thanks for the following: if(hit.rigidbody != null && hit.collider != part.collider && hit.collider.attachedRigidbody != part.Rigidbody) Was funny, as I just went into the game to test heat on welded parts as I was going to propose a similar change to the above so that heat would be applied to them, and much to my confusion found out they were already working right
  16. Hehe...yeah, in hindsight I probably should have clued into the fact that the ambient temperature was dropping below absolute zero. Didn't even think of it at the time Thanks a bunch for looking into this guys. Much appreciated.
  17. Hmmm...perhaps, but it really just flickered on like a light. There was none of the slow buildup you usually get, they just popped on full force out of nowhere at precisely 70Km. Might be down to the NaNs messing with things though. Yup, will do. Give me a few minutes and I'll reproduce it again and post the log. EDIT: Sorry man, that file contains way more info about my system than I'm comfortable posting, and after reviewing it I'm fairly certain it doesn't contain any more relevant information than what I've already posted. Hopefully you have enough info to be able to reproduce it, as to me it really looks like it just comes down to "aerobrake around Jool and get a NaN" If it helps any on the confirmation front, another user reported the exact same thing in my mod thread as well after I posted about it here: Report post link
  18. You could always have it shooting out of the tail end of the capsule as a red R, like it's the center part of the flame effect.
  19. And one more piece of info on Jool Reentry visual effects kicked in very briefly at exactly 70Km (I'm sending a probe down into the atmo) before fading out again, so them not appearing may not be related to the NaN thing I'm experiencing (which is still present down at these depths as well). Are they now tied to the height of Kerbin's atmo or something? The 70Km seemed a little coincidental.
  20. As a follow up on my previous, tried restarting KSP and going in on the same approach, with the exact same result: Nan soon as I hit the outer edge of the atmosphere. Then on a hunch that it might have something to do with being on the night side since ambient temperature is now a factor, I restarted KSP again, and changed my trajectory to approach on the day side. Result was once again the same: So unless there's something very particular about my ship, looks like it's just Jool in general that's causing this. Oh, and since I know from experience that people love to leave this crucial detail out: yes, I'm on 32 bit KSP
  21. Turns out I have a quicksave right before the aerobrake, so I was able to grab a screen of the exact trajectory for you: BTSM also modifies DR's config settings, so I'll include those here in case they're relevant as well: @REENTRY_EFFECTS[Default]:Final { @shockwaveMultiplier = 1.0 @shockwaveExponent = 1.09 @heatMultiplier = 25 @temperatureExponent = 1.03 @densityExponent = 0.85 @startThermal = 250 @fullThermal = 1150 @gToleranceMult = 2.5 @parachuteTempMult = 0.5 @crewGClamp = 30 @crewGPower = 4 @crewGMin = 5 @crewGWarn = 300000 @crewGLimit = 600000 @crewGKillChance = 0.75 @ridiculousMaxTemp = 2500 @maxTempScale = 0.5 } Let me know if there's any other relevant info I can provide. I'll try to reproduce and narrow down what might be causing it. EDIT: This appears to be the relevant portion of output_log.txt where it occurred: [PlanetariumCamera]: Focus: T8 AP07 Jool Orbiter + Low Atmo Probe (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Camera Mode: AUTO (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [PlanetariumCamera]: Focus: T8 AP07 Jool Orbiter + Low Atmo Probe (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 2.7273878455162, E: 0, M: 0, T: NaN (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 5.82159781455994, E: 0, M: 0, T: NaN (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 5.48077416419983, E: 0, M: 0, T: NaN (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 5.563809633255, E: 0, M: 0, T: NaN (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 5.27694606781006, E: 0, M: 0, T: NaN (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) dT is NaN! tA: 2.91831557452679, E: 0, M: 0, T: NaN EDIT 2: And watching the values closely this time, reproduces and seems to go to NaN soon as you hit the outer bound of the atmosphere at 130Km. Will try restarting KSP and reloading the save to see if it reproduces in that case as well.
  22. Not sure if it's particular to Jool (I haven't seen this elsewhere), but when pulling an aerobrake around it, temperature display on all parts seems to read NaN, and I experienced no visible heat effects either: Installed mods: DR (latest version), PreciseNode, Chatterer, and BTSM. I had launched a Jool mission a few days before 0.25 came out as well, and everything worked as expected, so this appears to be something new. Aerobrake was performed on the night side of Jool with a periapsis of around 110Km if that affects things.
  23. Oh...I guess so. I delete version checker locally and for the version of ATC I distribute with BTSM, so I've got no issues there Guess I get the first "told you so" in on that one SirJodelstein
×
×
  • Create New...