Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3,239 Excellent


About Starwaster

  • Rank
    Defender of the Sandbox

Recent Profile Visitors

11,737 profile views
  1. Sorry guys, no excuses. Gotten way behind on everything. Release page for 12.8.5 has been updated. I'll try to get to the rest of it. (all of it) https://github.com/NathanKell/ModularFuelSystem/releases/tag/rf-v12.8.5
  2. Maybe it GOT corrupted during the download from spacedock. I don't think that happens all that often but it's possible. I redownloaded from Github as it was the surest way but I'll see if I can get around to trying Spacedock again just to see what happens
  3. The zip file on Spacedock is corrupted. Windows Explorer can't open it at all. WinRAR opens it but reports errors in the file. Internally, many folders/file are duplicated with CRC values of 0. What did you use to create the archive?
  4. No, you're right. It's not MY responsibility. It's EVERYONE'S responsibility. It's a shared sandbox where developers inevitably are going to step on each other's toes and the right thing to do is bring attention to these matters when it pops up.
  5. Yeah I'm doing a 1.10 pass on everything right now
  6. It's not passes in this mod that I'm concerned about... There's a lot of mods patching things out there. Just because you haven't found any doesn't mean that none of them were depending on patch order or dependency on Raptor's original mod. It's generally a bad idea all around to make needless changes that can affect Module Manager patches. And that's not even talking about individual players who might switch over to this and then have no idea why things suddenly broke on their end and then they'll be unsure as to what broke or why or who to go to for support. I personally
  7. @ValiZockt Why did you change the mod's folder name? That breaks any Module Manager configs that depend on it. (specifically it breaks NEEDS and it breaks any BEFORE, FOR and AFTER passes)
  8. Right, I probably should have specified that but I thought it would be obvious that it was the RF extended engine
  9. That field isn't intended to store persistent engine status. You need to get the ignitions field from the engine itself.
  10. @draqsko It's hard to say for sure. I wish I had had more time to look through the code. Looking only at the section you've pointed out, it definitely is odd that it is discarding NewLAN like that. Was it meant to return a delta or the absolute new LAN value? The way that return value is used elsewhere makes me think it's not actually meant to be the absolute new value. Maybe @Whitecat106 was going one way and then changed his mind. And changed the code but left that one bit in (NewLAN = ...) Looking at it again and I notice that in https://github.com/Whitecat106/OrbitalDecay/b
  11. @draqsko It wasn't a matter of applying too much change, it just wasn't (or isn't) calculating it properly. The issue is likely to be in this code here but this is as far as I traced it. http://github.com/Whitecat106/OrbitalDecay/blob/master/Source/MasConManager.cs#L1190-L1316
  12. It doesn’t need revival. It’s a parts mod with no code to be updated.
  13. Load order is an issue if another mod is patching that part. The last one to patch that field is what counts
  14. @Iodyne No, you can't copy/paste tanks in the VAB No, the tank window should not disappear when changing values and I have not seen that happen myself nor can I recall anyone having reported it before now. I'll look at your log. Not sure what you mean about patches; please clarify that? EDIT: This is probably what is causing the window to vanish: [EXC 04:13:38.079] NullReferenceException: Object reference not set to an instance of an object RealFuels.Tanks.TankWindow.EnsureFreshAddLabelCache () (at <8f51b17657a546bc9d737ed47d61667b>:0) RealFuels.Tan
  • Create New...