Padishar

Well, you wouldn't be considered a jerk if you asked in the KER thread for a progress update on a specific feature or bug, as long as you asked in a decent manner. The main KER git repository has an issue tracker though I don't know if there's one in there specific to this problem. To answer the underlying question directly rather than the one you're asking here, no, little progress has been made with this so far. I've been meaning to look into it but most of my recent KSP time has been spent on garbage related issues in the stock game and in other mods. As far as I can see the code should be simulating correctly as long as the root part is one of the parts that doesn't get decoupled. However, it appears to not be firing the next stage until all of the Xenon tanks on the vessel are empty, not just the ones that will be decoupled in the next stage. I'll try to run some experiments over the next few days and see if I can spot the problem but no promises...

No, I haven't ignored it, I just don't believe it's a particularly valid one. Why can't they give something away that they've previously charged for? There's no law against it, it's their program(s), they can do what they like with it. RIC made it very clear that the deltaV readout part of KerbalEdu is only a tiny part of the difference between the products, whereas I don't think it's a particularly valid point in any way at all, plenty of companies have released old versions of their games which they previously charged for (much more than Squad ever did for early versions of KSP) and this has even included full source code in quite a few cases. I don't think it would hurt Squad's business at all if they released every version up to and including 0.90 (at least) for free download. They may not want to host it themselves as the bandwidth might be costly but I'm sure they could work something out, even if they put them up on torrents... A much more likely reason for them not doing so is that it could well considerably complicate the support issues, however, it would be pretty easy to spot people trying to get support for old versions and the downloads could easily be provided on the basis of no support entitlement...

No, just... no, don't even think that might be a sensible way to go. The resource mechanisms are being considerably modified to make them more efficient and it would be far better to design the new code such that it can be directly used by the simulation code required to calculate deltaV, rather than doing what the mods do and basically reimplementing all of the core resource handling mechanisms (with inevitable bugs). A better response is, "Then we'll make the delta-V readout optional and you can turn it on if you want (or if you do the tutorial that introduces the concepts involved and the UI of the feature)". However, I would also have to question both the arguments you gave. In both cases you say that a type of gameplay would suffer from having a deltaV readout available, but you also make the point that "This is an aspect some people find enjoyable,". Surely, if they find either of those aspects enjoyable and would enjoy them less with the readout then they would turn it off (or wouldn't turn it on). In any case, simply knowing the deltaV/TWR of your vessel really doesn't quash the experimental aspect of the game, nor does it give a disincentive to learning about most of the things you mentioned, the only one it uses is Tsiolkovsky and I would definitely add a tutorial (and KSPedia entries) that describe that in detail anyway. No, he isn't posting as a moderator. He's asking why you've basically ignored what he said in his previous post(s), which you haven't answered, sassy or otherwise...

Sorry, I didn't mean to ignore this, I was away from home on Sunday when I read it and then forgot about it. I have considered it in the past but, since the introduction of the editor gizmos, it really needs to work in the gizmo mode too (and the rotation) and this currently requires some rather involved poking about in some of the stock code that I'm not wiling to add to this mod. Squad have indicated that they plan to look at making the gizmo modes more accessible to modders and, if this does happen, then I may revisit it. In the meantime, I believe that the author of "Editor Extensions Redux" has implemented something along these lines so you might want to investigate that...

Yes, it basically tells KSP to create the MonoBehaviour when loading certain scenes (or immediately on startup). PartModules don't need it because they get created when a part that uses the module is created.

Is this not still relevant?

It looks like your GPU decided to reset itself for some reason and Unity got upset about this. I guess the most likely causes would be either a bug in the drivers, an overheating problem or an actual hardware fault. Can you run any other GPU intensive games without problems?

Well, as with any problem in KSP, the best thing you can do is to upload your output_log.txt file (from the KSP_Data folder for 32bit KSP or the KSP_x64_Data folder for the 64bit version) to a file sharing site (e.g. dropbox or similar) and post a link to it. This should allow us to see what is happening during the startup of your game and whether you are having any errors related to part loading or anything else...

If you don't do this bit then all we can do is guess...

If you didn't install ModularFlightIntegrator then you didn't install the mod properly. It requires ModularFlightIntegrator to function. You will need to install the mod as described in the first post and then test it creating a new save. If that works then try an existing save, though you should expect problems if you install a planet pack that modifies any body that you have a vessel at. If you have problems, then post a decent description of what is going wrong, along with logs (e.g. upload the KSP_x64_Data\output_log.txt file to a file sharing site and link it here).

Basically, what he said (though I only see two GameData folders). To fix what you currently have just move everything in the bottom screenshot into the folder shown in the top screenshot and then delete the GameData folder from the top screenshot. This should end up with all the mod folders in the original GameData folder (the one with Squad in), where they are supposed to be.

So, you've done a rather odd down-and-update process resulting in a mixture of versions and you're surprised you're having problems? Your log is full of these: TypeLoadException: Could not load type 'LayerUtil' from assembly 'Assembly-CSharp'. Rethrow as TypeInitializationException: An exception was thrown by the type initializer for Part at PhysicsGlobals.Start () [0x00000] in <filename unknown>:0 ...so it isn't really surprising that the game is crashing. While updating 1.1.2 to 1.1.3 should work correctly, you will probably be best off just making a totally clean install of 1.1.3...

From the OP of this thread:

That wasn't addressed to you, it was a "Doh! I've been ninja'd by Thomas"... It's a very easy mistake to make, especially when using VS as there appears to be a bug (or possibly a misunderstood/badly documented feature) that occasionally causes this option to change without you realising...

It isn't "another" deltaV topic, this thread is over 2 years old and was first dredged up 14 months ago and then again a couple of months ago. So, it could well be the same deltaV topic you remember from before...

Make sure that your project is building against .NET 3.5, not any later version... Doh!

Hehe, it certainly isn't just my account. Yours clearly shows it too, the first three items in your list show Speeding Mullet liking the same post three times when they should be from him, pandaman and Dafni:

It actually appears to attribute them to the first person that liked it that is displayed on the current page. It also appears to give them all the time of that first like on the current page.

FAR includes version 1.1.4 of ModularFlightIntegrator and Kopernicus includes version 1.1.5 which has this bug fixed. You have overwritten the fixed version with the broken one from FAR. Copy the ModularFlightIntegrator folder from the Kopernicus install zip into your GameData folder and tell it to replace any existing files.

It appears there is some kind of bug with the reputation activity page. For example, my page: http://forum.kerbalspaceprogram.com/index.php?/profile/97386-padishar/reputation/&type=forums_topic_post&change_section=1 ...shows the top 6 items (you may need to click the "Posts" item on the left) as all being the same user liking the same post when, in fact, these 6 likes came from different people. The same thing can be seen for other users, e.g. scroll to the bottom of sarbian's first page and you'll see a large number of likes for the same post all attributed to RoverDude. Edit: It was the top 6 items when I posted. Now it is the top 12 items that were apparently all left by RoverDude and Hevak. It appears that all of the likes for a particular post are being attributed to the first person that liked it.

He didn't take anything over. Go and research the whole story and if you still feel the same way and think the likelihood of one of your dependencies being pulled from CKAN in the future is more than you are happy with, then stop using those dependencies. Has the temporary delisting of MM actually caused you significant hassle? If so, then you should blame your users for not complaining in the right place and CKAN for not implementing the dependency checking sensibly so users can manually install a dependency and then have mods that depend on it show up in the listing.

That is obviously true, though you are the ONLY modder I have seen with a view significantly different to his. In any case, even if there were only a single modder who was having problems with CKAN installs flooding his support channels, CKAN would still be in the wrong. These issues have been going on for more than a year with CKAN making no significant effort to address them. It is a shame that it required this much disruption (including a virtual defection by a member of the CKAN team) to convince CKAN to change, but that isn't the fault of the modders...

You really don't get it. That is not what the modders want. They simply want there not to be a tool in existence that causes them increased support headaches and their only recourse being to do more work that they don't want to do, or change to a restrictive license (where that is even possible). I've not seen a single one of your posts that does anything to help resolve the issues. Thankfully, despite your "interference", saner heads have prevailed and the issues are now being sorted.

Please use a little common sense. How do you expect anyone to help you if you give virtually no details of what you've done or what is going wrong? You should be posting your planet config(s), logs and screenshots or people will just have to guess how to help you...

Are you able to read? He clearly said that Kopernicus 1.1.2 is for KSP 1.1.3. There is no Kopernicus 1.1.3 (yet).