Closed pjf closed 10 years ago
The first of these is a known side effect of the aggressive attitude control. You should find if you look at the pitch/yaw indicators that they're oscillating back and forth very quickly (so the thrusters aren't actually firing at once, just alternating at a very high frequency).
I think this bug is too fundamental to fix for 1.4.0, but a simple workaround is to only use reaction wheels with the flight computer.
Second is more worrisome. I've briefly tried reproducing it with a simple probe on a stock + build-develop-13
game, but the node execution worked fine. Can you give more details? For example, do the "executing maneuver" and "remaining duration" displays count down (as shown in the screenshot)? Does it happen in non-RSS games? What kind of ship are you using, anyway?
EDIT: just tried installing RSS and rolling back to build-develop-11
, and I still can't get the engine to overburn a maneuver node.
Organizational note: 2a1cea2a67a7d3643ec9cb814d96582fde3b0a32 should be roughly equivalent to build-develop-11
(diff). a7e0fe8123159f38379b50ed27205e4ca464ca07 is from before we were using CI builds.
So, I've done a bit more investigation. Here we are before the manoeuvre:
But during the manoeuvre (in fact, as soon as it starts):
Where's the flight computer gone? It's irreparably corrupted itself, as it's that little defect above the alarm clock. There's no "remaining duration", in fact I can't even pause the game unless I close what remains of the flight computer, and then any attempt to re-open it just gives me the corrupted version.
The log-files are filled with:
(Filename: Line: 396)
OverflowException: Outside range [MinValue,MaxValue]
at System.TimeSpan.From (Double value, Int64 tickMultiplicator) [0x00000] in <filename unknown>:0
at System.TimeSpan.FromSeconds (Double value) [0x00000] in <filename unknown>:0
at RemoteTech.RTUtil.FormatDuration (Double duration) [0x00000] in <filename unknown>:0
at RemoteTech.ManeuverCommand.get_Description () [0x00000] in <filename unknown>:0
at RemoteTech.QueueFragment.Draw () [0x00000] in <filename unknown>:0
at RemoteTech.FlightComputerWindow.Window (Int32 id) [0x00000] in <filename unknown>:0
at RemoteTech.AbstractWindow.WindowPre (Int32 uid) [0x00000] in <filename unknown>:0
at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0
at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0
(Filename: Line: 4294967295)
GUI Error: You are pushing more GUIClips than you are popping. Make sure they are balanced)
(Filename: Line: 396)
which start immediately after the Execute planned maneuver
debug message.
I'm running 64-bit KSP under Linux, RSS, and more mods than anyone would think is sensible (ie: everything needed for Realistic Progression Lite).
Can you at least tell us what engine you're using? Based on where the exception came from, I've a hunch that may be the culprit.
In particular, whether the engine is ModuleEngines or ModuleEnginesFX (so not just what engine, but if you're using HotRockets or anything else...)
Yes! I can tell you everything! Let's start with a mod list:
You can find the GameData directory I'm using at https://github.com/pjf/ksp-gamedata/tree/rpl (although the repo may not include all auto-generated and config files).
I don't remember installing ModuleEnginesFX, but I'm guessing it's bundled with something, because it shows up in the engine:
PART
{
part = NP.lfe.125m.AerospikeEngine_4293777826
partName = Part
pos = -0.2604792,37.41404,0.01331583
rot = 0,0,0,1
attRot = 0,0,0,1
mir = 1,1,1
istg = 0
dstg = 0
sidx = 0
sqor = 0
attm = 0
link = stackDecoupler-2M_4293775158
attN = top,stretchyTankSuper.MFT.BalloonCryo_4293777868
attN = bottom,stackDecoupler-2M_4293775158
EVENTS
{
}
ACTIONS
{
}
MODULE
{
name = ModuleEnginesFX
isEnabled = True
staged = False
flameout = False
EngineIgnited = False
engineShutdown = False
currentThrottle = 0
thrustPercentage = 100
manuallyOverridden = False
thrustPercentage_UIFlight
{
controlEnabled = True
minValue = 0
maxValue = 100
stepIncrement = 0.5
}
EVENTS
{
Activate
{
active = True
guiActive = True
guiIcon = Activate Engine
guiName = Activate Engine
category = Activate Engine
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
Shutdown
{
active = False
guiActive = True
guiIcon = Shutdown Engine
guiName = Shutdown Engine
category = Shutdown Engine
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
}
ACTIONS
{
OnAction
{
actionGroup = None
}
ShutdownAction
{
actionGroup = None
}
ActivateAction
{
actionGroup = None
}
}
}
MODULE
{
name = SmarterGimbal
isEnabled = True
gimbalLock = False
EVENTS
{
LockGimbal
{
active = True
guiActive = True
guiActiveEditor = True
guiIcon = Lock Gimbal
guiName = Lock Gimbal
category = Lock Gimbal
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
FreeGimbal
{
active = False
guiActive = True
guiActiveEditor = True
guiIcon = Free Gimbal
guiName = Free Gimbal
category = Free Gimbal
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
}
ACTIONS
{
ToggleAction
{
actionGroup = None
}
}
}
MODULE
{
name = ModuleJettison
isEnabled = True
EVENTS
{
Jettison
{
active = False
guiActive = True
guiIcon = Jettison
guiName = Jettison
category = Jettison
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
}
ACTIONS
{
JettisonAction
{
actionGroup = None
}
}
}
MODULE
{
name = ModuleAnimateHeat
isEnabled = True
EVENTS
{
}
ACTIONS
{
}
}
MODULE
{
name = ModuleAlternator
isEnabled = True
EVENTS
{
}
ACTIONS
{
}
}
MODULE
{
name = ModuleAGExtData
isEnabled = True
AGXData =
AGXNames = ‣001Comms‣002Los-res Map‣003High-Res Map‣004Solar‣005Record Data‣006Impact Trail
AGXKeySet = 1
AGXLoaded = True
EVENTS
{
}
ACTIONS
{
}
}
MODULE
{
name = ModuleEngineConfigs
isEnabled = True
configuration = LiquidH2+LiquidOxygen
techLevel = 3
thrustRating = maxThrust
modded = False
EVENTS
{
NextEngine
{
active = True
guiActive = False
guiActiveEditor = True
guiIcon = Current Configuration
guiName = LiquidH2+LiquidOxygen
category = Current Configuration
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
NextTech
{
active = True
guiActive = False
guiIcon = Tech Level
guiName = Tech Level
category = Tech Level
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
}
ACTIONS
{
}
}
IGNORE_THIS_NODE
{
}
MODULE
{
name = FARBasicDragModel
isEnabled = True
EVENTS
{
}
ACTIONS
{
}
}
RESOURCE
{
name = ElectricCharge
amount = 0
maxAmount = 0.1
flowState = True
isTweakable = False
hideFlow = True
flowMode = Both
}
}
The whole craft file can be found at:
https://dl.dropboxusercontent.com/u/9702672/KSP/RemoteTech94/Luna%20II.craft
And my persistent.sfs (containing Luna II in orbit) is at:
https://dl.dropboxusercontent.com/u/9702672/KSP/RemoteTech94/persistent.sfs
(I would have sent these earlier, but I had completely forgotten that KSP produces human-friendly files of all descriptions).
Many, many thanks!
~ pjf
Yep, RT2 doesn't play nice wirh ModuleEnginesFX, IIRC. And as for what it came with, it came with .23 :)
Sent by my thumbs, slowly. On Jun 9, 2014 5:21 PM, "Paul Fenwick" notifications@github.com wrote:
Yes! I can tell you everything! Let's start with a mod list:
- 6S Compartment Tubes 1.2 (with included Firespitter DLL)
- Action Groups Extended 1.3
- Active Texture Management 3.1
- Advanced Jet Engines 1.2
- AIES 1.5.1
- Alternate Resource Panel 2.2.0.0
- Astronomer's Visual Pack V3
- CustomBiomes 1.5
- Deadly Reentry 4.7
- EnhancedNavball 1.2
- Environmental Visual Enhancements 7.3
- ExtraplanetaryLaunchpads 4.1.2
- FAR 0.13.3
- FASA 3.86
- Final Frontier 0.3.9
- HotRockets 7.1
- Infernal Robotics 0.15b
- Kerbal Alarm Clock 2.7.3.0
- Kerbal Attachment System (KAS) 0.4.7
- Kerbal Joint Reinforcement 2.3
- Kethane 0.8.5
- kOS 12.1
- KSP-AVC (Addon Version Checker)
- KSP Interstellar 0.11
- KW Rocketry 2.5.6B
- LAZORS v33
- MechJeb 2.2.1.257 (dev)
- ModuleRCSFX 0.3
- NovaPunch 2.04
- PreciseNode 0.12
- Procedural Dynamics 0.7
- Procedural Fairings 3.01
- Reach for the Stars Pack v2
- RealChutes v1.1.0.1
- RealFuels 5.3
- RealismOverhaul 5.1
- Realistic Progression Lite 19e
- Real Solar System 6.1
- RemoteTech 2a1cea2 https://github.com/RemoteTechnologiesGroup/RemoteTech/commit/2a1cea2
- ScanSat 6.0
- ScienceAlert 1.5
- Simple Part Organiser (SPO) 1.2.1
- Soviet Engines 1.1
- StretchyTanks / StretchSRB v9
- TacLifeSupport 0.8.0.4
- ToolBar 1.7.1
You can find the GameData directory I'm using at https://github.com/pjf/ksp-gamedata/tree/rpl (although the repo may not include all auto-generated and config files).
I don't remember installing ModuleEnginesFX, but I'm guessing it's bundled with something, because it shows up in the engine:
PART { part = NP.lfe.125m.AerospikeEngine_4293777826 partName = Part pos = -0.2604792,37.41404,0.01331583 rot = 0,0,0,1 attRot = 0,0,0,1 mir = 1,1,1 istg = 0 dstg = 0 sidx = 0 sqor = 0 attm = 0 link = stackDecoupler-2M_4293775158 attN = top,stretchyTankSuper.MFT.BalloonCryo_4293777868 attN = bottom,stackDecoupler-2M_4293775158 EVENTS { } ACTIONS { } MODULE { name = ModuleEnginesFX isEnabled = True staged = False flameout = False EngineIgnited = False engineShutdown = False currentThrottle = 0 thrustPercentage = 100 manuallyOverridden = False thrustPercentage_UIFlight { controlEnabled = True minValue = 0 maxValue = 100 stepIncrement = 0.5 } EVENTS { Activate { active = True guiActive = True guiIcon = Activate Engine guiName = Activate Engine category = Activate Engine guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } Shutdown { active = False guiActive = True guiIcon = Shutdown Engine guiName = Shutdown Engine category = Shutdown Engine guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { OnAction { actionGroup = None } ShutdownAction { actionGroup = None } ActivateAction { actionGroup = None } } } MODULE { name = SmarterGimbal isEnabled = True gimbalLock = False EVENTS { LockGimbal { active = True guiActive = True guiActiveEditor = True guiIcon = Lock Gimbal guiName = Lock Gimbal category = Lock Gimbal guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } FreeGimbal { active = False guiActive = True guiActiveEditor = True guiIcon = Free Gimbal guiName = Free Gimbal category = Free Gimbal guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { ToggleAction { actionGroup = None } } } MODULE { name = ModuleJettison isEnabled = True EVENTS { Jettison { active = False guiActive = True guiIcon = Jettison guiName = Jettison category = Jettison guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { JettisonAction { actionGroup = None } } } MODULE { name = ModuleAnimateHeat isEnabled = True EVENTS { } ACTIONS { } } MODULE { name = ModuleAlternator isEnabled = True EVENTS { } ACTIONS { } } MODULE { name = ModuleAGExtData isEnabled = True AGXData = AGXNames = ‣001Comms‣002Los-res Map‣003High-Res Map‣004Solar‣005Record Data‣006Impact Trail AGXKeySet = 1 AGXLoaded = True EVENTS { } ACTIONS { } } MODULE { name = ModuleEngineConfigs isEnabled = True configuration = LiquidH2+LiquidOxygen techLevel = 3 thrustRating = maxThrust modded = False EVENTS { NextEngine { active = True guiActive = False guiActiveEditor = True guiIcon = Current Configuration guiName = LiquidH2+LiquidOxygen category = Current Configuration guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } NextTech { active = True guiActive = False guiIcon = Tech Level guiName = Tech Level category = Tech Level guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { } } IGNORE_THIS_NODE { } MODULE { name = FARBasicDragModel isEnabled = True EVENTS { } ACTIONS { } } RESOURCE { name = ElectricCharge amount = 0 maxAmount = 0.1 flowState = True isTweakable = False hideFlow = True flowMode = Both } }
The whole craft file can be found at:
https://dl.dropboxusercontent.com/u/9702672/KSP/RemoteTech94/Luna%20II.craft
And my persistent.sfs (containing Luna II in orbit) is at:
https://dl.dropboxusercontent.com/u/9702672/KSP/RemoteTech94/persistent.sfs
(I would have sent these earlier, but I had completely forgotten that KSP produces human-friendly files of all descriptions).
Many, many thanks!
~ pjf
— Reply to this email directly or view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/94#issuecomment-45556767 .
Yep, RT2 doesn't play nice wirh ModuleEnginesFX, IIRC. And as for what it came with, it came with .23 :)
Actually, it's not that simple. ModuleEnginesFX support was supposed to have been fixed (#74). I made sure to include the Kerbodyne engines (which also use ModuleEnginesFX) in my testing, and I didn't run into this bug. Didn't try using the Aerospike, though.
@pjf Is ModuleEngineConfigs
from Real Fuels? It looks like something that might tweak engine specs in a way RemoteTech can't follow.
@Starstrider42 : Aye! I'm guessing ModuleEngineConfigs
is from RealFuels, given that it mentions hydrolox and tech levels, although I think @NathanKell may be slightly more familiar with RealFuels than I. ;)
Ok, it took copying your exact setup, but I finally have something useful to say.
ModuleEnginesFX
problem, but your build didn't include the fix for some reason (though, according to the commit tree, it should have).@Starstrider42 : Can I just say at this point that I adore you and your work? I've been involved in a lot of modding communities, and in open source in general, and you are totally rocking this. <3
When you say one of the automated builds, you mean something like build-develop-13? I'll go test that now. :)
~ pjf
I should be thanking you for providing a repository of your entire GameData directory. If I'd had to hunt down and install all of those mods individually, I'd have probably given up.
And yes, I tested it with build-develop-13
.
! I can confirm that build-develop-13 fixes the problem! I apologise I didn't try this earlier; I had assumed the automated releases were roughly equivalent to hand-rolled releases I was using. (I have no idea if the upgraded ModuleManager packaged with build-develop-13 would make a difference, but it wasn't in the hand-rolled releases.)
With regards to RCS, it looks like all the controls do rapidly flip back and forth, but with no change in ship attitude, which may or may not be the known bug you're describing. I haven't tried reaction wheels, notably because I haven't unlocked them in my tech tree yet. (I don't even know if RPL has reaction wheels.) In any case, we may or may not wish to track that in a separate ticket.
Thank you again so much for this! You rock! :D
Hey, I made exactly the same assumption; see my second post.
The ModuleManager doesn't seem to make a difference; I kept it at 2.1.0 in testing. IIRC, though, 2.1.5 is much more stable, so it's a good thing to have just on general principles.
The RCS problem I mentioned is one where the ship slews to the right position but then has trouble settling down. Your problem is one where it doesn't slew at all (in fact, if you turn off RCS, you'll see the controls pull hard over, like they should). So I'm pretty sure now it's a different bug.
Apologies, I was quite out of date!
ModuleRCSFX is derived from ModuleRCS, so you should be able to just cast to ModuleRCS and it will behave fine for you. ModuleEngineConfigs sits besides ModuleEngines/ModuleEnginesFX and updates stats, therefore any stats you pull from ModuleEngines/FX will be correct at that instant. The only thing I can think of that might trip up the flight computer is if it is trying to do a burn in atmosphere, since thrust scales with Isp (rather than fuel flow scaling with Isp) so if you change ambient pressure thrust will change mid-burn, and if you query max thrust at sea level, you'll be incorrect about it in vacuum (and vice versa). Neither of these issues, AFAIK, is relevant to Flight Computer, though?
@NathanKell, the code actually never explicitly refers to ModuleRCS
. There is a single reference to RCSModule
, which is a subclass of Part
.
I'll confirm this evening whether the thruster bug is caused by ModuleRCSFX... assuming it doesn't turn out that half the other mods depend on it.
Well that's a problem, and indeed so is the nearby command module reference. Since .21 (IIRC) KSP hasn't been using separate classes for parts like pods and RCS; instead they're now module = Part and have PartModules that deal with extra functionality (like ModuleReactionWheel). The PartModule ModuleRCS replaced module = RCSModule even earlier.
Ok, so I managed to hack both Realism Overhaul and pjf's save file to make the RCS thrusters use ModuleRCS
instead of ModuleRCSFX
. Unfortunately, I got the same behavior as before: I can slew manually with RCS, but using the flight computer makes the controls go berserk until RCS runs out of fuel. Given how tightly interconnected the various mods are, I'm not sure I can do a more direct test without breaking the save.
So I guess I'll have to settle for removing mods one by one until something changes. :frowning:
There is not a single part in KSP 0.23.5, or all my mods, that uses RCSModule. It was deprecated looooong ago. That code will therefore never execute, AFAIK. What KSP actually uses, and is stock, is the PartModule ModuleRCS, Note the distinction between module= (Part, Winglet, HLandingLeg [deprecated], Strut, etc) and a PartModule (ModuleEngines, ModuleRCS, RT2's modules...)
Apologies if you're already clear on this.
I agree with @NathanKell, if your part logic doesnt extend from PartModule, it is likely inert in game.
I am clear on this, yes. I also know that in mostly stockalike games I can control a ship with RCS, just not very efficiently...
Epiphany: pjf mentioned his ship doesn't have a single reaction wheel on it, not even in the probe core. What if the absence of a reaction wheel is what's confusing RemoteTech? That would explain not only why pjf's ship fails catastrophically, but why in less-modded games RemoteTech tends to overcompensate when it uses RCS.
That would explain it, yes; it might be that RT2 has never worked right with pure RCS, and always relied on reactionwheel torque for torque calculations?
And NathanKell nailed it. Adding a reaction wheel restores "normal" behavior.
I'll post a fix as soon as I've tested it.
And that makes perfect sense from the code, since it was (a) probably borrowed from RT1 with the reaction wheel logic added, and (b) since every craft anyone makes ever, except in RO, is going to have considerable torque, it wasn't a problem. I think (not a C# expert) a ModuleRCSFX, since it's derived, will allow if (module is ModuleRCS) so your fix should fix for both kinds of RCS.
OMFG I love you both!
Ok, created a minimum working example here: https://gist.github.com/Starstrider42/fd05d50738588066122f. This one is for stock KSP + RemoteTech + the included config file, so it loads much faster than RSS/RO/RPL.
You'll have to forgive me as the part module hierarchy and their relationships is still something quite foreign to me, so I can't fully follow the discuss above about ModuleRCS, etc.
So as I understand it, based on the gist by @Starstrider42 and his commit in 7e9cd8f579055feb4d685dea3d7014157a65e1b2, CommandPod and RCSModule have been deprecated and rolled into ModuleReactionWheel and ModuleRCS. Now that the relevant modules are being enumerated correctly, their forces can be combined to determine torque more accurately, even when reaction wheels are disabled or supply very low amounts of torque (as is the case in RSS/RO).
Is that summary accurate?
Yes, that's accurate.
I'm going to go ahead and schedule a fix for this in 1.4.1 but please feel free to give feedback if it should be considered a feature for 1.5.0 rather than a bug.
Definitely counts as a bug. I'd never report "the flight computer now does what you tell it to do" as a feature. :wink:
Anyway, #97 is ready for testing (I've added a link to the DLL in the first post to make things easier), main thing I'd like feedback on is whether the current monopropellant-guzzling behavior is acceptable.
I have this exact same issues in kOS so ill take this issue and kill two birds :)
@erendrake, I just ran my example through build-develop-29
and it seems to work quite well. The smaller ship swung a little too far at first, but it recovered quickly and the motions damped down after a few oscillations (it still uses a bit of RCS, but so does the stock SAS system). I'm willing to consider this fixed; did you find any problems on your end?
I did not. Good job and I'm going to steal the work for kOS ;) On Jul 12, 2014 2:04 PM, "Starstrider42" notifications@github.com wrote:
@erendrake https://github.com/erendrake, I just ran my example through build-develop-29 and it seems to work quite well. The smaller ship swung a little too far at first, but it recovered quickly and the motions damped down after a few oscillations (it still uses a bit of RCS, but so does the stock SAS system). I'm willing to consider this fixed; did you find any problems on your end?
— Reply to this email directly or view it on GitHub https://github.com/RemoteTechnologiesGroup/RemoteTech/issues/94#issuecomment-48822542 .
I think I've had the flight computer work once or twice as intended earlier on in my game, but it never wants to cooperate with me now. I'm trying to use the most basic of features:
In the first case (hitting the NODE button on the flight computer) all the RCS thrusters fire all at once, in all directions. The attitude of the ship does not change, but it burns through RCS fuel nicely.
In the second case (hitting the EXEC button) everything is quiet until the node time, but then the craft fires at full thrust, and does not stop until it runs out of fuel, even if we've imparted sufficient impulse to complete the node.
These mean the flight computer is essentially un-usable. Currently I'm playing with RSS/RPL and RemoteTech 2a1cea2, but I've observed the same behaviour with a7e0fe8 and the community hotfix 2014.01.08.22.30 .