Starwaster

Members
  • Content Count

    8,897
  • Joined

  • Last visited

Community Reputation

3,155 Excellent

6 Followers

About Starwaster

  • Rank
    Defender of the Sandbox

Recent Profile Visitors

9,462 profile views
  1. Are you saying it would crash on OS other than what it’s built on or that it would crash on a specific OS but not another?
  2. @linuxgurugamer I’ll recode it so it doesn’t do that in a future update but I think you might overstating the severity of the issue
  3. No it’s not either of those. You’d probably see that even if there were no constructor and I said why that was. The question is why is this happening NOW? These things don’t happen randomly. What is going on in your KSP environment? You didn’t answer my questions.
  4. @linuxgurugamer This is strange as technically I'm not doing anything in the constructor which would trigger that. It's possible that the way I declared the field could be construed as a constructor call (even if there wasn't a constructor) but in that case it should doing it all the time for everyone. I should see that in my own logs or the recently submitted logs by Gordon Dry. Is this a build you compiled yourself or is there anything else unusual about it? What versions of DR/KSP are you using? (if you had submitted the entire log I wouldn't have to ask that or chase anything down....)
  5. I don't think any of those parts are addressed by Deadly Reentry so maybe you want to look at their thermal characteristics Here's an example of what DR does with space plane parts: https://github.com/Starwaster/DeadlyReentry/blob/master/DeadlyReentry/DeadlyReentry-OPT.cfg Note though that I do think even 2706 is a little too high for stock sized planets. It should be just high enough to withstand a shallow LKO reentry (but probably not return from Mun and definitely not Minmus) Note also that I take the exact opposite approach from stock which increases thermal mass for plane parts. I modeled after Shuttle tiles which have low thermal mass. Really, increasing thermal mass just means you hit thermal equilibrium slower. If you can hit equilibrium without the part being destroyed then it doesn't matter what the thermal mass is. It's just more energy to dissipate.
  6. Not necessarily harder. If you design a sensible craft and reenter with a reasonable trajectory then you'll be ok. Just be aware that most parts have had their temperature tolerances reduced to reasonable levels. (instead of acting like they're made of tungsten). Space plane parts assume an inner material similar to aluminum with the skin being modeled after space shuttle tile thermal qualities. (they have no ablative shield but are designed to resist shallow reentry heating)
  7. None of which even remotely indicates a cause or even that Deadly Reentry itself was the cause. All of the parts are indicated by your log as having been successfully processed by Deadly Reentry at which point it ceases to do anything at the Main Menu. It doesn't do anything else at that point and other non-Deadly Reentry procedures begin to occur. (player.log had more to say on the subject than ksp.log)
  8. Because KSP 1.8 - not because MJ Coincidence does NOT equal causality. By itself, it is vaguely, remotely possible that a mod might work with KSP 1.8 that wasn't explicitly recompiled for it. In the past updates KSP updates usually haven't been game breaking for mods (mod version checker code notwithstanding) But when you start throwing multiple mods at it then sooner or later some function call is going to throw an exception somewhere which breaks things for other mods later on down the chain. There are two reasons why version mismatching is more problematic this time around. One is Unity itself. KSP updated the version of Unity it's using and some Unity code either has been deprecated or split off from UnityEngine.dll into a multitude of other libraries. Where previously a mod might have to reference 2-3 Unity libraries it now might have to reference a dozen. A second is that the 1.8 update is using .NET 4.x instead of .NET 3.5 - this is huge because it affects everything. There's plenty of information (more detailed than my intentionally vague explanation) about this on the forums already and it hasn't done a thing to stop false rumors. TL;DR it's more important with KSP 1.8 that you use mods explicitly updated for KSP 1.8 but it's a quadrillion times more important that ALL your mods are updated for KSP 1.8 - don't try to mix and match because you will run into trouble.
  9. @Hungry_Dragon265 regardless of how long you’ve played @raidernick is correct. Your GameData folder is a mess. You clearly have things improperly installed and a screenshot of the folder is not going to be enough. (@everyone STOP DOING THAT. Do not ask for screenshots of a folder. Ask for logs instead. Log + ModuleManager.ConfigCache has 5000% as much information and is text searchable) Hungry: ksp.log + ModuleManager.ConfigCache NOW.
  10. If you’re talking about manually editing the MJ files then you’re doing it wrong. Do it as a patch instead. Migrate that patch whenever you update KSP and you won’t have to do anything else ever again.
  11. Uninstall RealismOverhaul and stay on stock KSP. You are not ready for RO
  12. @Hungry_Dragon265 they work exactly the same as in stock except that they have limited ignitions and have throttle limitations. (can't be throttled or can't be throttled below a certain point). How are you having problems with them? You stage them and you throttle up. Or you use the PAW to activate/deactivate them.
  13. I see. Ok, so the whole thing is a dead end unless more people pop up with this problem. It's not even an edge case at this point
  14. I need to know more about your system. You've got a player.log in there but the log indicates a windows OS. (player.log usually means *nix or Mac) The logs themselves aren't really telling me anything unfortunately. They both cut out at different points without logging anything problematic.