Padishar

@goldenpsp, sorry I was a bit needlessly picky at you there, the previous post annoyed me... However, the paragraph that you pulled that quote out of is talking about modders having to update their mods. It is the job of the QA and Experimentals teams "to help find bugs" in the stock game. The "select group" of modders that are mentioned help to find bugs specifically with how a new version of KSP interacts with mods and suggest changes to the core game to make modders' jobs easier. This requires them to update their mods to find out and it requires other people to run with the mods. Even with your interpretation of that quote, it still doesn't say that "we are all supposed to be helping find bugs". It says that everyone has the opportunity to do so if they feel like it. If they don't, and instead, they feel like just playing it, and they can accept that there will be bugs, then that's fine too. Some people find the process of game testing and bug hunting fun but a lot of people don't (or don't actually know how to do it "properly"). I suspect that Squad would rather they still gave 1.1 a go and just played it normally as that is what most players will do when it is released. If they can then give reasonable feedback about their experience then great, but if not, then there's no harm done. Anyway, your last paragraph is spot on, the update to this mod (and every other) will be available for testing with 1.1 when it's ready. Just wait, do not annoy modders whether you intend to help test their mod or just play with it. Back somewhat more on topic, one issue this mod may have to deal with is that direct messing with the mass of parts is no longer supported and mods must use the IPartMassModifier mechanism to do this. I'm not sure what will go wrong if you do mess with part.mass directly but various things could.

Stop spreading incorrect information. KSP 1.1 doesn't use the old UI API but that does not mean it isn't still supported. It most definitely is still supported and quite a few mods that use it have been updated to work with KSP 1.1 already. The issues that break most mods are simply that things have been moved around between the assemblies and quite a lot of old UI related classes have been replaced with new ones. FTFY. You should never "expect" a mod to be updated at all and the only reason for the pre-release that was explicitly given in Ted's original announcement of the pre-release was to give all modders more time to get their mods updated before the actual release so Squad definitely want people to run it with mods...

0 m/s, you forgot the Xenon... (And no, neither KER or MJ would try to do this, they don't run fuel cells during the simulation, they just assume you have all the EC you need).

Well, the calculations are done using Quaternion.eulerAngles which returns the results in degrees and then messes about with 180 and 360 so the result is definitely in degrees. How fast is it actually spinning? Could it be that the value just isn't being divided by the physics frame time, e.g. would 50 times that number make more sense with what you can measure the speed as?

Yes, you could, and it would still be just as pointless. This thread isn't about whether or not it is needed, that has been discussed time and again in this forum. Squad have said that they plan to add some kind of deltaV readout, we just have to wait...

Well, I can't see anything obviously wrong with the code. Could it be that the roll angle is changing so much between updates that it is reporting a aliased value (e.g. like a prop when viewed on film appears to run at various wrong speeds and even backwards)?

Your sequence of if (engineModuleType == xxx) statements don't use else if so, for all values except 4 it is also running the bit in the final else and trying to use PartmoduleModuleEnginesFX which has only been set up when engineModuleType is 1 (or when you have multiple engine modules of different types). You would probably be better off changing all the lists of if (engineModuleType) statements to switch (engineModuleType) instead. Edit: also, testing if a boolean value is equal to true is pointless, e.g. you can just write: if (PartmoduleModuleEnginesFX.throttleLocked)

I'm sorry, could you possibly explain this in more detail? Do you mean the input to the FloatCurve is the current amount of resource (well, ratio current:full)? Is this the ratio of all the resource accessible to the engine? Does the fuel flow rate change or does that stay constant and the effective Isp change? Does this take into account partially filled tanks or just assume that means a different starting thrust? It sounds like this is going to complicate the calculation of TWR...

As for any bug report, please provide a complete output_log.txt/player.log file and a list of the other mods you have installed. The error in the log is probably to be expected but the deltaV calculations should still work.

No, my opinion on the matter is irrelevant, it is Squad's opinion that counts. Given at least 3 posts had already said it and you were still asking I had to assume you were blind or just not paying attention...

That has been answered several times in this thread already, have you not been reading it. They have better things to spend their dev time on.

Your understanding is wrong. As I posted, MJ did use the KER code for a while but switched back to its own code quite some time ago. It isn't a matter of whether Squad could cope, it is whether the player base would accept a stock feature with very easy to provoke issues. No, it wouldn't. However, the issues with the licensing I mentioned are real and, given that I'm pretty sure that at least one of the contributors to the code hasn't been seen for well over a year, it may be impossible to get permission to relax the license. In any case, the various bits of the code in KER, despite my fixes, cleanup and optimisation work over the last couple of years, could be done in better ways with access to the core game code so it would make sense for it to be rewritten anyway. Also, making claims about the "vast majority of players" is not recommended, the majority of KSP players have never even heard of KER let alone installed it.

I've not seen any mention of it so far but I would expect it to work in exactly the same way. It will almost certainly require (lots of) changes to the MoveInitializerIntoAwake calls and you will obviously need to use the correct version of Unity (5.2.4f1). You may be able to use the mdb2pdb supplied with that Unity for VS2015 (or you may still need to get a newer one from a newer version of Mono).

Because, firstly, the KER code is licensed as GPL so Squad would either have to GPL the whole of KSP or would have to negotiate an alternate license (which, given several people have contributed code to it, would be complex, if not impossible). Secondly, as I mentioned above, the code in KER has various issues that make it not work correctly as soon as your vessel and/or mission plan deviate from a fairly restricted, linear, staged progression (MJ did use it for a time but reverted to its own code that also has similar issues). Gargling sand is also hard but I'm not going to be trying it any time soon... That example should work correctly if you turn on the "Simulate using vectored thrust values" option in the settings.

Gaming in a VM is a rather optimistic thing to do. Do you really mean a virtual machine?

Huh? I think you'll find it is...

Welcome to the forum. Please read this thread: ...and provide the logs (and probably DxDiag output) it talks about as it is virtually impossible to offer you any help without more information...

Do you mean that right-clicks don't cause the function to be called at all or just that Input.GetMouseButtonUp(1) returns false?

Given that they have said that they plan to do it, the reasoning can only really be one of: They have changed their minds about doing it at all and just haven't told us to avoid the toxic fallout that would ensue. I think this is highly unlikely. They consider the Unity 5 upgrade much more important to spend developer time on especially given the complexity of the problem and the availability of mods that already provide the feature.

That's a non-argument. There have always been bugs reported on the tracker containing mods. The reason there appear to be more for the pre-release is almost certainly due to the larger number of users that are reporting bugs because the tracker has been explicitly advertised and people are being actively encouraged to report issues directly on the tracker rather than having a discussion in a forum thread first as usually happens. Another non-argument. There are over 1400 bugs on the public tracker, many of which have been there for years, so the game as a whole is "bug-ridden" as you put it. In actual fact, the pre-release isn't very much buggier than 1.0.5, yes there are some issues but there are surprisingly few serious issues Of the 230 currently on the pre-release tracker, I would expect the majority of them to still be present when 1.1 ships. Yes, further development is capable of breaking things but it really is not at all likely at this stage. I will be very surprised if my 1.1 compatible version of Part Angle Display even needs to be recompiled for the release version let alone have anything actually fixed. Curse will have to add the option at some point and it will be annoying if it isn't present the instant that the release ships so it makes sense to implement it early. If they (or Squad) really feel strongly about not hosting mods for 1.1 until the release then the Curse moderation people can simply reject any mods with the flag set (or turn it off if the upload also has an earlier version indicated, i.e. it works on 1.0.5 and 1.1). However, I fail to see any real argument for not just doing it now...

Indeed I would. While the basic equation for calculating the deltaV of a single burn is pretty trivial, a general solution needs to account for every possible vessel design and all the different fuel flow modes etc. You can judge for yourself, the code is all in here: https://github.com/CYBUTEK/KerbalEngineer/tree/master/KerbalEngineer/VesselSimulator Even with that amount of complex code it still doesn't handle some things "correctly" (e.g. decoupling the root part from the rest of the vessel)...

Errr, no, Squad have also stated that the pre-release is intended to allow modders to get their mods updated before the official release so it makes total sense to make the official mod hosting site support it as an option. The current pre-release build is not "highly buggy" and any mod updated to "work" with it is almost certain to also work (at least as well) with the official release when it appears. Also, the mod upload page on CurseForge allows uploads to be flagged as alpha, beta or release so this could easily be used to indicate further updates are likely once the release happens.

CurseForge needs to be updated to allow modders to choose KSP 1.1 as the version their mods are intended for. I PM'ed JadedCat about it but haven't had a reply so thought I'd better post it here too in case she is away at the moment.

There has been a change to the stock root select functionality which may make trying to get this working not really important anymore. What is the code actually trying to do?

Version 0.3.1.1 for KSP 1.1.0.x has now been officially released. There are likely to be further changes in the near future. I am contemplating removing the Mod-P shortcut that adds the PYR values directly to the part's Euler angles as it isn't particularly useful (at least I don't find it so). I may also combine the PYR increment fields into a single "V. Fine" value. Does anybody find the individual PYR values useful? I am working on a toggle to switch the angle display into absolute mode (i.e. "building relative") and also hope to enable the part rotation hot-keys in both the rotate and translate editor modes (though this may be awkward without changes in the stock editor code).