Test of continuing KER developments [0.24.2]

[Padishar]

Well, I made a few other changes to the simulation code too. One strange bug I had was that the craft sometimes appeared to contain the same Part more than once (I create a Dictionary to lookup my PartSim objects from the core Part objects and the Dictionary complained that a key was already in use).

I also completely rewrote the recursive scan for fuel sources (and setting of the resource drain rates) based on Kasuha's detailed analysis of how the fuel flow works. This fixed a number of infinite loop issues (e.g. with cyclic arrangements of docking ports).

Another really major change was related to multithreading. Sometime between 0.6.1.5 and 0.6.2.3, Cybutek changed the simulation code to run in a background thread (using ThreadPool.QueueUserWorkItem) but the simulation code was still directly accessing the core game objects (e.g. the Part tree). This is totally unsafe as the core game can change the structure of the rocket while the simulation code is running. I changed the code to have a preparation stage that runs in the main thread and copies all required information from the core game objects into my private data structures for the main part of the simulation to use in the background. This, along with some improvements to the exception handling, eliminated lots of issues where the simulation code would either get stuck in an infinite loop or would throw an exception and would never get run again.

Another thing that may have already been fixed in MJ, is that Xenon and Monopropellant no longer use ResourceFlowMode.ALL_VESSEL. They now use a new value of ResourceFlowMode.STAGE_PRIORITY_FLOW which is basically the same as ALL_VESSEL but only the tanks in the highest numbered stage are drained first. I use a Dictionary of StageNumber->HashSet and add the fuel tanks to the relevant HashSet (creating it first if required) and once all the tree has been scanned I look for the highest stage HashSet which isn't empty and use the tanks in that set:

                    case ResourceFlowMode.STAGE_PRIORITY_FLOW:
                        {
                            Dictionary<int, HashSet<PartSim>> stagePartSets = new Dictionary<int, HashSet<PartSim>>();
                            int maxStage = -1;
                            foreach (PartSim aPartSim in allParts)
                            {
                                if (aPartSim.resources[type] > 1f)
                                {
                                    int stage = aPartSim.decoupledInStage;
                                    if (stage > maxStage)
                                        maxStage = stage;
                                    if (stagePartSets.ContainsKey(stage))
                                    {
                                        sourcePartSet = stagePartSets[stage];
                                    }
                                    else
                                    {
                                        sourcePartSet = new HashSet<PartSim>();
                                        stagePartSets.Add(stage, sourcePartSet);
                                    }

                                    sourcePartSet.Add(aPartSim);
                                }
                            }

                            while (maxStage >= 0)
                            {
                                if (stagePartSets.ContainsKey(maxStage))
                                {
                                    if (stagePartSets[maxStage].Count() > 0)
                                    {
                                        sourcePartSet = stagePartSets[maxStage];
                                        break;
                                    }
                                }
                                maxStage--;
                            }
                        }
                        break;

Edited April 7, 2014 by Padishar

[sarbian]

Most of those are already covered in MJ afaik but I'll double check.

Current STAGE_PRIORITY_FLOW uses the same code as ALL_VESSEL so it will need some work later ^^.

[Amaroq]

I'm having a bit of an odd one, I've posted this in the Module Manager thread, but cross-posting here just in case. Mac OS X, KSP 0.23.5., Module Manager 2.0.1., ToolBar 1.7.1, and Padishar's latest 0.6.2.3.x, the following MM config no longer works for me:

@PART[*]:HAS[ @MODULE[ModuleCommand] ]:Final
{
	MODULE
	{
		name = BuildEngineer
	}
	MODULE
	{
		name = FlightEngineer
	}
}

When starting a new build in the VAB or SPH, regardless of which cockpit I place first, I don't get the KER button in ToolBar.

I'm not missing anything obvious, now, am I?

Edited April 7, 2014 by Amaroq

[Amaroq]

The answer is "yes, I was missing something obvious". MM 2.0.1 does not support the spaces I had within the "HAS" tag. Removing them led to immediate success, and a big thank you to ObsessedWithKSP for the fix.

[Padishar]

Most of those are already covered in MJ afaik but I'll double check.

Current STAGE_PRIORITY_FLOW uses the same code as ALL_VESSEL so it will need some work later ^^.

Sorry I couldn't be more help. I've been doing a bit of digging and I can't find anything obvious in my changes that I haven't already mentioned but a couple of other things have occurred to me. Does MJ have problems with all the new engines or just the liquid booster? If it is just the liquid booster then the recursive fuel source scan may simply not be counting the engine part itself as a potential fuel source. A problem with the new solid boosters could indicate that MJ isn't detecting it as a solid booster properly because it uses ModuleEnginesFX and not ModuleEngines...

[sarbian]

In the end it was a just stupid typo in my code ...

Thanks for help and sorry for the bother.

[Baythan]

I think it's really awesome how you guys work together even though some people 'might' consider your mods(or those you work on even if it's not 'your' mod) to be competitors. In the end it makes both of your mods even more awesome.

In other words, this KER simulation code is working quite well in my game, and I'm super stoked that MJ is getting help with some of its bugs because I like that mod too.

[Padishar]

I have just updated the zip linked in the first post to include the max TWR for each stage in the build engineer display.

The way that various edits affect the numbers may appear a bit strange but if you think it through then it does appear to be calculating the correct values. E.g. if you have a simple liquid fuel rocket and you remove half of just one of the resources (the oxidiser or the liquid fuel) then the TWR goes up and the max TWR goes down. This happens because the initial TWR is higher due to the lower mass but the max TWR is lower because not all of the other resource will be consumed making the mass at the end of the stage higher. So, basically, please think carefully about what is actually happening as the stage burns before reporting that the calculations aren't working...

[Woopert]

You've done a fantastic job with this, it does a good job with fixing various bugs/issues.

[zer0t3ch]

Works great, thanks man.

[Baythan]

Having an issue with KER delta-V values changing from the VAB to the launchpad.

Using KER v0.6.2.3 and the dll from this thread(Updated 12:02 08/04/2014) with KSP 0.23.5.464. Only mod installed is KER.

Using this craft in the VAB my delta-V stats are:

S2 = 5,309m/s

S1 = 699

Total = 6,009m/s

but on the launchpad:

S2 = 4,846m/s

S1 = 721m/s

Total = 5,567m/s

I deleted the mod, re-downloaded and re-installed both mod and dlls, and the numbers still changed. If I can provide any other information that would be helpful, let me know.

Edit: I'm starting to think part of the problem may be that the vessel can exceed its terminal velocity(and I have no idea what speed that is), so it's possible to waste d-V on launch.

Edited April 9, 2014 by Baythan

[Superfluous J]

Using this craft in the VAB my delta-V stats are:

S2 = 5,309m/s

S1 = 699

Total = 6,009m/s

but on the launchpad:

S2 = 4,846m/s

S1 = 721m/s

Total = 5,567m/s

I think this is perfectly normal. In the VAB you get Vacuum stats. On the launchpad, you get the stats in 1ATM of air.

There's a button to toggle atmospheric stats. Check those in the VAB, I bet they'll be 5567m/s dV there too.

[KerbMav]

Edit: I'm starting to think part of the problem may be that the vessel can exceed its terminal velocity(and I have no idea what speed that is), so it's possible to waste d-V on launch.

That would have no influence on the numbers shown while sitting on the launchpad.

Apart from what 5thHorseman wrote, the atmosphere option of KER in VAB, do you use any mods that change the engine setting, KIDS Kerbal Isp Difficulty Scaler for example?

[Baythan]

Using KER v0.6.2.3 and the dll from this thread(Updated 12:02 08/04/2014) with KSP 0.23.5.464. Only mod installed is KER.

I will check the atmo options and see if the numbers match up or change.

I would have thought that VAB settings would be Launchpad atmo instead of vacuum, because you have to LEAVE atmo before you reach vacuum, but thats just me.

Edit:

Same craft as last time(yes, I know, its a poorly designed lift stage):

VAB normal settings(vacuum, as Mun and Minmus show the same numbers)

S2 = 5,309m/s

S1 = 699m/s

Total = 6,009m/s

Atmospheric settings(Kerbin as reference body just to be sure)

S2 = 4,719m/s

S1 = 538m/s

Total = 5,257m/s

Launchpad:

S2 = 4,846m/s

S1 = 721m/s

Total = 5,567m/s

So the numbers still don't match up. Now my best guess is that the Kerbin settings assume you start from 0m(sea level), because they show as WORSE than launchpad settings. Though these numbers are better for what I was trying to do, which is design vessels that have just enough fuel in each stage that nothing gets left floating in orbit(a tad bit of OCD, I don't like space trash).

Edited April 9, 2014 by Baythan

[AlexinTokyo]

Yes, the VAB "atmospheric values" shows the value at sea level, but the launch pad is slightly higher than sea level, so you get a very slightly better Isp and better ÃŽâ€v.

[Padishar]

The S1 numbers don't make sense to me but I haven't looked at your craft yet...

[KerbMav]

Huh ... so strap a rocket onto a rover and drive down to the beach for further testing?

[AlexinTokyo]

Tested with Baythan's craft file.

There's a huge discrepancy in the mass reported by KER in the VAB and on the pad.

The TWR and ÃŽâ€v seem to be accurate for the displayed mass.

	VAB	Pad	Diff
Full	82302	81462	840
LV-909	2993	2313	680
Top	1880	1200	680

If you remove all the lights and batteries, everything works out.

Looks like a core game bug, as certain parts which should have mass appear not to.

Edited April 9, 2014 by AlexinTokyo

[Padishar]

Thanks for that. I'm a bit busy with work right now but I'll enable the logging code in my dev build of KER which dumps out the part tree details and work out exactly which parts it is. There are various bugs with the size 3 decouplers caused by them having been (incorrectly) set to have no physical significance so possibly other parts have been broken in 0.23.5 too...

[sarbian]

I can help a bit here : https://github.com/MuMech/MechJeb2/blob/master/MechJeb2/FuelFlowSimulation.cs#L323-L330

There are other part with PhysicsSignificance = 1 since 0.23.5 that don't report the same value in the editor and in flight. Like the longAntenna ( Communotron 16 )

[Padishar]

I can help a bit here : https://github.com/MuMech/MechJeb2/blob/master/MechJeb2/FuelFlowSimulation.cs#L323-L330

There are other part with PhysicsSignificance = 1 since 0.23.5 that don't report the same value in the editor and in flight. Like the longAntenna ( Communotron 16 )

Thanks. That bit of code is only doing special checks for launch clamps and landing gear. KER probably should be ignoring the landing gear in the editor so I'll fix that but AlexinTokyo seems to be implying that other parts (batteries and lights) are "broken" too...

[sarbian]

Yes, any part with "PhysicsSignificance = 1" in their .cfg don't report the same part.physicalSignificance in the editor and in flight. I did not find a workaround yet but I am looking into it now.

[Padishar]

Part has 2 members:

public Part.PhysicalSignificance physicalSignificance;

public int PhysicsSignificance;

The second one is the .cfg one and the first one can be different. I think we need to determine if this is a deliberate and intended change in KSP. Does anyone know if the core mass readouts ignore the mass of these parts too? E.g. put a craft that is mostly "broken" parts on the pad in a stock install and check the readout in map/tracking station view to see if the ship mass includes the parts...

[sarbian]

Oh, stupid majuscule/minuscule thing

Here is how I changed my code. I now get the same result in editor and in flight.

            bool physicallySignificant = (part.physicalSignificance != Part.PhysicalSignificance.NONE);

            if (HighLogic.LoadedSceneIsEditor)
                physicallySignificant = physicallySignificant && part.PhysicsSignificance != 1;


            if (part.HasModule<ModuleLandingGear>() || part.HasModule<LaunchClamp>())
            {
                //Landing gear set physicalSignificance = NONE when they enter the flight scene
                //Launch clamp mass should be ignored.
                physicallySignificant = false;
            }

[Padishar]

I have now updated the link in the first post with a fix for the physical significance issue. All parts that have PhysicsSignificance set to 1 in their part.cfg will not be included in the mass either in the build or flight engineer.