linuxgurugamer

It doesn't use it, but does now take it into account (released fix for it today)

New release, 1.16.0.4 Fixed issue with part variants where it wasn't changing the mass of the part variant, resulting in negative numbers on occasion

I'll look at it this evening

Thank you, these specific steps will be very helpful in figuring out what's going on

Why reinvent the wheel? Why not just use the Blizzy toolbar, it works well. You could probably even create a config to ship with this (not sure about that) which would predefine a toolbar with specific buttons Yeah sorry, now some other random mod is causing the error, i think something else is going on here will have to check mod by mod. the reason i posted here is Critical temperature gauge came up first. sorry should have checked in more detail will let you know how it goes! sorry again for the false alarm @Teilnehmer ok this is strange, i remove Critical Temp mod, everything loads just fine on launch, now either it;s a conflict between some other mod or it;s something else, i just cant figure it out here is the log and player-log maybe you can make something out of it i am all out of ideas https://www.dropbox.com/sh/w1mj4wj7le2qqv2/AADgTIb4JhoFBc-JkNXlA7xua?dl=0 I managed to narrow down what is happening, The problem goes away either by removing this mod or KSTS, so either there is a conflict or one or the other mod is causing problems, i raised the issue on KSTS thread with @linuxgurugamer will wait what he has to say so we can find the culprit. I'll take a look at this

KRnD get the info from the part itself at runtime. The problem is that it doesn't know about part variants, and those part variants change the mass of the parts. Sometime the amount it changes the mass is much more than the adjusted part mass, resulting in negative numbers. The solution is not simple, I will have to now read in all the variants (or maybe just the current variant) and include those masses (or negative masses in those cases where the variant is reducing the mass) in the final calculation KRnD is getting the mass directly from the part itself. It does not know about the variants, therefore it stays at 0.075, if you look in the part files, you will see that. The Wiki is taking the variant info into account, which is why the masses are different

New release, 1.3.8.1 Fixed sort by stage ascending/descending from having constant resorting going on

New release QuickSearch 3.3.0.10 Thanks to user @dtoxic for the bug report Thanks for user @tivec for the following fixes: Fix Enter to search Fix history window to only show if allowed

Easy enough, thank you. Will be fixed this evening

Yes. 1.8.1 had a good improvement over 1.7.3, but it did have more bugs as a result of the engine upgrade. 1.9.1 is the same engine, som many of the bugs have been fixed

But then you are suggesting having two different "languages", one for craft/save files and a different one for part files. That seems like extra work and more changes for bugs. And, given that we occasionally have to edit either craft or save files, it would be better IMHO if the syntax was identical, and readable by humans

It all depends on what the code does. Take a look at the parts which do and don't have that button in the PAW. I think you might see a pattern. According to the last commit for it: It's part of the B9PartSwitch, so I'm going to guess that if there aren't any partswitch settings in a part, you won't see it

Wasn't designed for jet engines, their response is too slow for the mod to understand. Was really designed to make it easier to land on a different planet

You might be surprised. 1.9 has significant performance improvements

Yes, please

If you are going to mention an old mod like this, would be better to point them to the current version here: @fragtzack

Please not sqlite. In fact, no SQL. Way too easy to screw up queries and totally bog down a system I could live with JSON. But what I'd like to see would be something like what KSP currently uses, and a JSON translator to take the source file and output JSON. Source file for ease of use, JSON for speed of implementation

Just an FYI, my mod is only used to display partinfo in the editor. It's information only, has no use beyond that

@JPLRepo I'm curious what Ampyear is providing to this mod.

And I just realized what happened. I added a dependency check to ESLDBeacons to make sure the right version of CommNetManager was installed. @Booots's version, while good, didn't match the version it was looking for.

Dropbox, Google Drive, etc. There are many free file sharing sites. I usually use Dropbox, but have used Google Drive on occasion

Here you go: New beta, 1.3.0.1 Fixed reloading a vessel with an activated addon module having PAW set to "activate" https://github.com/linuxgurugamer/ESLDBeacons/releases/tag/1.3.0.1 Given the feedback, I feel comfortable moving ahead with the full adoption. Only problem I have is that @Booots is again AFK and not responding, so until he gets me access to the Spacedock entry for the Commnet Manager, I'll have to create a new one. Not a big deal, I'll update the netkan to point to the new entry. This will probably happen sometime before tomorrow night. As always, feedback is critical to everyone's success Thank you all

That's rather odd, I wonder if it is related to the CommNetManager versions. Could you try it again using this: https://www.dropbox.com/s/nqgu226nmzis7lt/CommNetManager-1.1.0.zip?dl=0 Put the dlls back the same and put this in place of Booot's version and let me know Thx

In case anyone comes to this thread: New release, 2.0.1.1 Fixed "ghost ships" sometimes appearing in flight and in the editor, somehow caused by the thumbnail generation code when used on VAB & SPH craft files Replaced calls to Debug.Log with new class Log, for better control of log messages Would be best to post in the main KSTS thread here:

How about a few screenshots of the problem