Padishar

I have already implemented the fix for the Xenon (and monopropellant) fuel flow changes but it hasn't been tested at all so the release won't happen until this evening sometime. The changes are available in my GitHub branch if you're desperate but, as I knocked up the fix in a spare 10 minutes during lunchtime, don't be surprised if it doesn't work properly...

Thanks very much for this, it should be fairly easy to implement in the KER simulation code though the decision of when to stage may also need changing to get more sensible numbers (e.g. it currently won't simulate staging until all the engines that will be decoupled run out of fuel). Do you have a link to where HarvesteR said that? Sounds like something I should be keeping an eye on...

Does anyone know for definite what this line from the release notes means? From the ResourceFlowMode enum I would guess that they now use a different mode. They used to use ResourceFlowMode.ALL_VESSEL but now it looks like they use a new STAGE_PRIORITY_FLOW value. I'll try to work out the exact rules later this evening unless someone has already done so (or someone from Squad could just tell us how it works)...

How do you expect bugs such as this to be fixed if you don't bother reporting them? What exactly do you think is wrong with the rendezvous panel? That you can't target asteroids? Incidentally, I have updated the test version in the last half hour with a fix for the strut fuel flow issue.

I have just updated the download link in the first post. The main change is to fix the strut fuel flow issue reported by zepplinmage and AlexinTokyo. There are also some other tweaks and the beginnings of the RealFuels support (no visible change yet but it should detect RF correctly).

You can also "fix" it by simply dragging the electric charge slider on the tweakable window. When you do this the value will change from NaN back to 0.0 and the calculations involving mass will work again.

Thanks for the detailed report, it should make it much easier to work out where the problem is. It looks like, in flight (or on the pad), the struts are allowing fuel to flow so stage 3 burns all the fuel from the central tank first and then burns the radial tanks. After staging there is no fuel left in the ship so no more stages show up... I'll check it out later this evening. I haven't seen this in 0.23 but there have been some reports of strange asparagus behaviour so it may be a core game change but is probably just an oversight in the new simulation code...

Nice job... now try to drop it on top of the VAB...

Thanks, zepplinmage, I noticed something similar myself last night. I was running a special version that outputs lots of logging but it was in the middle of quite a long session (4 trips to asteroids), my output_log.txt was over 70 meg in size and it was a bit late to go hunting through it to find the problem. I'll try and take a look at it later today...

The updated test version in this thread works fine...

Yes, I can confirm this. The new code doesn't suffer from the problem with the LFBs in 0.23.5 (and is generally more stable in a number of other areas).

Though if a gram is equivalent to 21 kilotonnes then 1 microgram would be equivalent to 21 kg of TNT and I wouldn't want that going off anywhere near me, let alone in my hand... Also, when annihilating in this way you have to add the mass of the normal matter, so you're doubling the energy released...

Theoretically there is no reason why antimatter should look any different to normal matter, however, a chunk of antimatter of a visible size would do significantly more than blow his fingers off. One gram of antimatter being annihilated would liberate slightly more energy than the Fat Man atomic bomb used in WWII (21 kilotonnes)...

This is not true. Your time does not slow down as you travel faster. Your time as seen by an outside observer slows down but this is not the same thing. Relativity, while logically consistent and backed up by experiments to a very high accuracy, is not intuitive and the usual descriptions of time dilation effects usually only introduce further misunderstandings. However, the standard twins paradox is true, if one twin leaves on a fast ship and returns many years later then the twin that stayed home will be much older than the one that went and this can effectively be used to travel into the future "faster" than you would normally. Another example is when approaching and crossing the event horizon of a black hole. As you approach the event horizon (carrying a clock that can be seen by an external observer), your clock will appear to that observer to run slower and slower until, at the point you cross the event horizon, your clock (and you) would appear to freeze. As far as you are concerned you would not notice any odd time effects at all and would, with a sufficiently massive black hole (where the event horizon is many light years across) continue to travel towards the singularity with no ill effects (until the tidal gravitational forces stretch/squash you into nothing).

Well, it should certainly be possible to keep track of the selected part rotation and detect when it is rotated (and in which direction) and then change the rotation but this is an awful lot of hassle (and may be less than perfectly reliable) when the core editor code could very easily expose a couple of variables to control the rotation increments. If it took longer than 10 minutes for one of the core developers to add this "feature" to the core game code I would be shocked... I posted this in the suggestions and development forum a week or two ago...

Basically, the foreach statement should not be used if the thing being enumerated over is going to be changed during the enumeration. You should use a plain loop with an integer index instead (either a for loop or a while loop) and make sure that you correctly handle the index when removing an item.

The reason, if you're interested, is that HotRockets adds an extra ModuleEnginesFX module to the stock engines that defines the effects but has zero thrust. The old code in KER doesn't correctly handle engines with multiple engine modules. It first looks for the module for the Rapier engine and, if it is there, it tries to handle the two engine modules. Next it looks for any ModuleEnginesFX module. If it finds any then it gets the first one and uses it for the thrust/isp etc of the whole engine. If it doesn't find one then it looks for a ModuleEngine and if it finds any of those then it gets the first one and uses that for the engine. When HotRockets adds a ModuleEnginesFX to an engine that has a ModuleEngine, then instead of KER finding the ModuleEngine (that has the correct thrust values) it instead finds the ModuleEnginesFX (which is just an effect generator) and uses zero values for the engine calculations. Glad to hear it is working for you. I've still got a few more tweaks to make to the code but I've been ill for the last week. Hopefully I'll be able to get back to it now and finish up the RealFuels support (and a few other things)...

The test version I linked to in the post above should work...

There are some issues with rapiers in the current code and I suspect there are also issues with engines that have been shutdown. I have been working on various changes to the KER simulation code though I haven't done anything specifically for rapiers yet. You may like to try the test version posted in this thread. I'll have to have a play with a similar craft to find out exactly where and how it is going wrong...

This looks very helpful, thanks. I use VS at the moment so I'll need to switch over to MonoDevelop before I can try it but I will definitely be giving it a try at some point soon. I actually had a dream the other night about implementing a replacement mono.dll for windows that uses the .NET runtime and (in my dream) it made KSP run much quicker and allowed direct debugging in VS. I had a bit of a look at how feasible this might be and, well, I don't think I'll be trying it any time soon...

Sorry, I didn't see this the other day. Don't worry, I have no plans to remove TWR (Throttle) and I doubt Cybutek would want to do that either. The "initial and max" TWR thing is for the build engineer. At present it just give the initial TWR of the stage and the plan is to keep track of the TWR during the simulation so a max value can be displayed as well.

Interesting... The first little dip after initial takeoff looks very much like you took off, crashed into the water just after takeoff and then reverted (maybe data from a previous run?). The much larger dip at the right end looks like you strayed back out over the ocean. The bit about 2/3rds of the way when the terrain comes out of the water to ~180m and then drops suddenly to the flat value (presumably the runway) is strange. I can't think of any good reason for that unless the surroundings of KSP had some odd features back then. It looks like you landed back on the runway from over the water and then took off for a bit of a fly around KSC. While I was testing I found that heightFromSurface was always -1 even in orbit around Mun. heightFromTerrain also always read -1 in orbit around Mun. A rocket launch from KSP (staying over land) starts reading -1 for heightFromTerrain once you get into the upper atmosphere (about 50km). Landing on Mun from 40km up the value reads -1 until just over 20km and then reads correctly though it switches to -1 if you timewarp.

I'm not suggesting that vessel.pqsAltitude isn't "correct" (for bodies with a pqsController) but I suspect that terrainAltitude was changed at some point to simply call pqsAltitude. As for not disregarding tips from the creator of something (and you can stick your tongue out all you like) but I've seen far too many cases over the years where official documentation and/or direct advice from the creators of an API has been plain wrong. In this particular case, you are suggesting that terrainAltitude is inaccurate but terrainAltitude is not part of PQS, it is a property (or member variable) of the Vessel class and could easily have been changed at some point without the creator of PQS knowing or changed since he gave you that advice...

Personally I think the hold f9 to quickload is a silly way to do it. It would be much better if, when you just hit f9, it pauses and brings up a dialog that tells you details about the quicksave (what vessel you were controlling, when it was saved etc) and lets you confirm or cancel the load. No more problem. Edit: It could even keep multiple quicksaves and show you a list in the dialog and let you select one...

Well, I've spent a couple of hours flying and driving various craft around various hilly places on Kerbin, Mun and Minmus and terrainAltitude is always the same as pqsAltitude. I suspect that Squad have changed something since your early RealChute version... I will continue to use terrainAltitude as I suspect the only time it will not equal pqsAltitude is when the body doesn't have a pqsController (I suspect pqsAltitude will be -1 in that case but terrainAltitude may still have a "correct" value).