Padishar

The only thing I know of that causes electric charge NaNs is using an engine that has a max EC capacity of 0 but allows it to be tweakable in the VAB. Opening the part menu of the engine will cause it to read NaN/0.0 and this will cause most things that try to get the mass of the part (or the whole vessel) to get a NaN result (including the CoM indicator in the VAB). Fundamentally, this is a stock bug with the resource tweakable sliders but making something tweakable when it can only range from 0 to 0 is not sensible so the engine really should be fixed. It can be temporarily fixed by just dragging the tweakable slider a little which will reset it to 0.0/0.0 and the mass calculations will start working again. Given you are switching between vessels in flight it is unlikely to be related to this. It is more likely that some mod that tries to adjust the EC to simulate on-rails consumption is making a mess of things and setting it to NaN. There isn't much you can do about this other than finding a reliable sequence of actions that can reproduce it with as few mods installed as possible and then reporting it to the authors of those mods that look likely.

The rigidbody mass is what the Unity PhysX calculations use to simulate the physics. I'm not sure you would be able to change this without KSP changing it back on the next physics update (KSP has to update the rigidbody mass each physics update to account for part masses changing when the amounts of resources it holds change). It is "possible" though it will probably cause all manner of strange bugs as it really isn't logical and writing code to handle negative masses "correctly" (whatever that means, have you ever seen anything with negative mass?) would be a waste of effort. Also, at some point as the resource drains, the mass will be very close to (or actually at) zero which will cause other issues (see below). I assume you mean what is the best way to read the mass from a Part. This has changed and been extended several times but basically, part.mass should be the dry mass. I'm not at home at the moment so can't look it up but I know you can add up the mass of the resources yourself or you should be able to call Part.GetResourceMass(). There is also a mechanism for PartModules to modify the mass of a part but I'll definitely need to look up the details of that later to be sure if it is included in Part.mass directly or you need to adjust. I'll try to update this post sometime this evening (GMT). a = F / m Something would probably break inside the PhysX calculations (at least). Almost anything could happen, from nothing untoward to "infinite" acceleration being applied to that part resulting in spontaneous disassembly of the vessel and/or it disappearing off to Alpha Centauri at, or well above, the speed of light... A part floating one the sea is in equilibrium with the weight force balanced by the buoyancy force. If you suddenly change the mass to a significantly lower value then the forces will no longer be in equilibrium and the part will accelerate upwards. I'm a bit surprised it actually takes off but I guess that depends on how much you are changing it by. You should probably reconsider what you are trying to do as directly messing with part masses (especially during flight) is probably not the best way to achieve what you are actually trying to do. I would suggest asking for advice about what you are actually trying to achieve rather than about how you think you might be able to do it. In general, doing something to a part during flight that breaks the laws of physics is likely to cause several obvious issues and quite likely to cause several much less obvious (but potentially just as dangerous) ones.

This is true for all the (stock) rocket engines (which seems to be the main focus of your question) but the various jet engines do vary the thrust with the velocity which indirectly affects the effective Isp (Isp = F / (g * dm/dt)). E.g. the thrust of the basic jet engine falls off almost completely above mach 1 but it still uses the same amount of fuel per second for the same throttle position. Similarly, the turbojet has quite low thrust when stationary, really gets going once you get up above mach 1 and then falls off again at higher speed. This will become an important consideration if/when you start trying to build planes and, especially, spaceplanes.

It sounds like FloatCurve must be storing intermediate values for the calculation in a member variable and this causes an issue for simultaneous calls, though I can't see why they would want or need to. I could understand if it generated coefficients for each section of the curve lazily but it would be better to store them for all the sections separately if you're going to bother storing them at all. Edit: Also, is FloatCurve a Unity thing? It isn't mentioned anywhere in their documentation. Are you sure it isn't a KSP thing...?

While I would also like the vessel types to be more dynamic and moddable (and the resource flow modes too, but that's another story), they are pretty hardcoded into quite a few areas of the game at the moment (as are the resource flow modes) and even making simple changes to the system (such as adding a new type to the existing enum) would be quite likely to cause some unintended consequences, so I expect a total redesign of the vessel type mechanism to make it moddable would be considered too dangerous to make it a high priority...

Ahh, thanks for that. That was a very recent change that Cybutek made to support a new feature in KSP 1.0.5. That will need changing to copy that flag in PrepareSimulation...

As I understand it, the issue isn't because the mods call Unity code from other threads (KER doesn't access any Unity objects from the background thread) but that initialisers get run in a different thread in the development version of the Unity player and this causes the errors that happen. There is a post in the debugging thread that mentions exactly the problem you are having in the same situation so the poster of that may have found a solution. This may involve changing and recompiling FAR or it may involve a modified version of the KSPDevModePatcher configured to patch the necessary bits of the FAR dll. I haven't looked into the patcher but that way may be easier than trawling through the FAR source. Alternatively, it may be enough to compile a debug version of FAR as that may do something different with where the code gets put.

Thanks very much for that workaround, more mouse work but at least it's possible. They really should indicate it more clearly that the whole quote gets selected when you click the icon. Another thing that really irritates me is when you edit a post and click cancel. It shows a confirmation dialog asking "Are you sure?" and it has Cancel and OK buttons. This is a cardinal UI sin, no mention of what it is confirming and potential confusion about whether the cancel button will cancel the cancellation or the edit. Also, to make it even worse, the OK and Cancel buttons are the opposite way around to most other dialogs.

I believe that both of those mods use a background thread to do various calculations. This is definitely true of KER (the vessel simulation code that calculates the deltaV is run in a background thread) and is probably also true of FAR. I don't know why they work fine in release and not in debug but I do remember something related to this in the thread about setting up the debug environment. If you find that there is something in KER that could easily be changed to avoid this issue then please post about it in the KER thread.

You've messed up the second link a bit but I managed to find it. There are so many exceptions in your log that I'm not surprised you're getting nasty crashes. They start during part loading when Procedural Parts gives an exception for several of its parts. Then there's an exception from Scatterer while trying to destroy something though it looks like most other plugins are just being initialised about then. Then there are a couple of null reference exceptions from KAC when going from the tracking station to the space center. Then the same Scatterer exception happens again when switching from space center to flight followed by an argument exception from DeadlyReentry (calling a GUI function from OnStart). There are a number of exceptions from MJFARExt because it can't load the FAR dll. I assume this would be normal if you don't have FAR installed but you do appear to as FAR also gives an index out of range exception when trying to build its voxel stuff. There are then ~28000 lines of "Transform error" followed by, what appears to be FAR, getting upset about stuff being NaN. Then there are also lots of other exceptions from other mods and bits of stock code presumably because the earlier exceptions have prevented some stuff from being initialised correctly. I can't see anything obviously wrong in the .sfs but, if I had to guess at the underlying cause, I would say that the installations of either or both of Procedural Parts and FAR are broken and this is causing exceptions during the initialisation of the flight scene that causes everything to break... Edit: Also, the exception from Deadly Reentry could be causing something nasty so that should be reported to the author as it should be fairly simple to fix.

Without seeing the persistence file and a log file (output_log.txt or player.log) it's impossible to tell...

All the Unity 5 documentation on the Unity site lists all the old UI classes as supported.

Actually. it's 100% sure...

That page contains contradictory information (though the bits concerning creation and destruction are probably correct ). This bit: FixedUpdate: FixedUpdate is often called more frequently than Update. It can be called multiple times per frame, if the frame rate is low and it may not be called between frames at all if the frame rate is high. ...says that FixedUpdate may not be called between two calls to Update but the flowchart further down the page doesn't allow this.

No, it makes creating quotes that are split fairly easy. It doesn't allow you to split an existing quote. I often want to quote the entire message but have it split into 5 or more parts and having to do each part using a mouse driven interface is slow and cumbersome, especially when the post is a way up the page and you have to keep scrolling back up to it to quote the next bit (and the editor sometimes sticks the quote in a stupid place that requires more mouse work to correct). The old BBCode system was much easier, quote whole post, easily delete chunks of the quote using just the keyboard, split the quote using just the keyboard by copying and pasting the quote tag, edit content of quotes using just the keyboard (this editor doesn't reliably let you move the caret into and out of quotes with the keyboard forcing you to click with the mouse instead). Also, you can't edit a post and add new quotes to it, they get added to the "thread reply" editor rather than the "edit post" editor. This makes it more trouble than it's worth to avoid double positing, e.g. if I post a reply to someone's message and another message is posted while I was typing, then it is much easier to post a new quoted reply to the new post than try to get a quote from it into the original reply. Creating a decent WYSIWYG text editor on the web is difficult and most of them out there aren't really worth using. This is especially true since the shift towards making things more usable on touch devices. If there is a "plain text with markup" alternative editor then I will almost always use it in preference.

One that is obviously false and could be considered libelous so the publishers (Steam) have every right to pull it for that reason alone. Also, what "bullying" are you referring to? The only bullying I can see there is the people being insulting to the OP (called "stupid", an alien and "mental") and the locking of the thread stopped that.

It is unfortunate that Part Angle Display doesn't do what you want but it works by using an existing feature of the editor code to handle all the rotation and, when it was originally written, the editor code didn't allow node attachment at anything but the "correct" orientation. To be fair, it does say the following (emphasis added) in the first sentence of the mod's forum thread: In 0.90, when the rotate gizmo was added, it became possible to rotate a node-attached part but detaching the part and reattaching it loses the rotation (and various other things can also confuse it) and the gizmo code wasn't exposed for modders to easily access it. I have experimented with doing the part rotation myself rather than letting the editor do it but it requires a lot of work to make it behave sensibly and I haven't found the time (or, if truth be told, the inclination) to finish it off. Hopefully, I will get some time to work on it during the upcoming public 1.1 beta phase so I can fix it for the new version and fix some of the issues it has but this will probably not include being able to rotate attached parts except possibly that I may enable the rotation hotkeys in the stock rotate gizmo mode if I can work out a simple way to do it. It is also not possible to create a complete ring of node-attached parts because the vessel is a tree structure that can not contain loops (except for special cases like struts and fuel lines which are surface attached and contain a special reference to the part the other end connects to).

Doh, I meant to post this hours ago but got distracted by work... Nice job tracking this down (and especially nice that it can be fixed in the engines rather than KER)...

Firstly, please don't post large logs in spoiler tags, there are plenty of file upload sites that would be much better. Second, yes, this crash has happened because the program has run out of virtual address space (4 gig limit for 32 bit process) and was unable to allocate memory.

I'll need substantially more info than that to work out what's wrong. That log extract is only a small part of what the verbose simulation should output. Please upload the craft file concerned, the full output_log.txt (or player.log) file, a screenshot with the KER all stages button selected and, preferably, a full list of the mods you have installed. It sounds like something about the engines doesn't get set up correctly in the editor. Does KER give different values if you go to launch? Does MJ give correct values (either in the VAB or in flight)?

Well, you have, almost certainly, installed it incorrectly. You should read (and follow the instructions in) the How to get support sticky thread in this sub-forum, especially the bits about providing a log file and a list of the mods you have installed or there is little anyone can do except guess at your problem...

That isn't what a quaternion is, you can't specify both a point and a direction with only 4 numbers. A quaternion is a 4d analogue of a complex number that just happens to be very useful when dealing with rotations. It basically specifies an axis about which the rotation happens and the angle of the rotation about that axis though there isn't a direct correspondence with the w, x, y and z component values. You may be confusing it with a Unity Transform which is a point in space and a rotation (specified by a Vector3 and a Quaternion).

Also, if you don't want to write it all out then you could just use: double speed = orbit.getOrbitalSpeedAtDistance(orbit.ApR); ...which also just uses the vis-viva equation... Edit: though you should check how that behaves when there is no Ap and a general check for a NaN return value would be a good idea too...

Using an intermediate time makes this quite a bit less efficient than it can be. All you need is vis-viva: https://github.com/CYBUTEK/KerbalEngineer/blob/master/KerbalEngineer/Flight/Readouts/Orbital/SpeedAtApoapsis.cs#L53-L62

There certainly hasn't been any mention of it in any dev notes and this release is mainly for the upgrade to Unity 5 so, while it is true that some work on multiplayer has been done, I will eat a recovered Falcon 9 engine if it gets included in 1.1...