Starwaster

Members
  • Content Count

    8,977
  • Joined

  • Last visited

Community Reputation

3,226 Excellent

7 Followers

About Starwaster

  • Rank
    Defender of the Sandbox

Recent Profile Visitors

10,911 profile views
  1. 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
  2. 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?
  3. 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.
  4. Yeah I'm doing a 1.10 pass on everything right now
  5. 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 have patches like that and I'm knowledgeable enough to deal with it since I do a lot of modding myself but a lot of players are not. like that. (in point of fact, this was not a chance find on my part; I knew to go looking for just this situation when evaluating if I should switch over to your branch)
  6. @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)
  7. Right, I probably should have specified that but I thought it would be obvious that it was the RF extended engine
  8. That field isn't intended to store persistent engine status. You need to get the ignitions field from the engine itself.
  9. @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/blob/6d648de50261a63fb170f9863106f21ba5131542/Source/DecayManager.cs#L859-L862 It's treating things a bit differently if less than timewarp x100. And the first part of that is scaled by current rate of warp. I would think you would scale it by deltaTime or fixedDeltaTime instead. And why does it only scale the first calculation and not the others? And if it's x100 or greater then GetSecularLANChange is used instead and I didn't notice that before. So what speeds is this actually happening at? Maybe that one needs to be looked at too. It's all a bit inconsistent and again I really wish I had had more time to look at things when I tried to help before.
  10. @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
  11. It doesn’t need revival. It’s a parts mod with no code to be updated.
  12. Load order is an issue if another mod is patching that part. The last one to patch that field is what counts
  13. @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.Tanks.TankWindow.GUITanks () (at <8f51b17657a546bc9d737ed47d61667b>:0) RealFuels.Tanks.TankWindow.GUIWindow (System.Int32 windowID) (at <8f51b17657a546bc9d737ed47d61667b>:0) UnityEngine.GUILayout+LayoutedWindow.DoWindow (System.Int32 windowID) (at <fa6f9762ac624af092525d37c9d516c4>:0) UnityEngine.GUI.CallWindowDelegate (UnityEngine.GUI+WindowFunction func, System.Int32 id, System.Int32 instanceID, UnityEngine.GUISkin _skin, System.Int32 forceRect, System.Single width, System.Single height, UnityEngine.GUIStyle style) (at <fa6f9762ac624af092525d37c9d516c4>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) It looks like you don't have the latest version for KSP 1.8 Get RF 12.8.4.1