blizzy78

Is there nothing in output_log.txt that relates to the Toolbar Plugin??

It does, but I don't have a problem doing that Edit: So it looks like there is a fork of kOS that is actively maintained. I should probably have a second look. Yes, I should probably add those Actually the speech recognition engine is quite capable. Right now I'm only using the "commands" part of it, where you define a list of fixed commands, and it tries to match your speech to one of those commands. What I'm not using is its "dictation" part, where it converts free speech to text. Those two modes can also be combined, such that it would try to match a command, and if that fails, it would take your speech as a dictation. I should try to make use of that to be able to ignore unknown voice commands, such as burps. Edit: Also, it may have issues with very short words, for example with "map" only having a single syllable. It should help to use longer commands, such as "open map". Of course I could also tweak the required minimum confidence level.

http://forum.kerbalspaceprogram.com/threads/78067-0-23-5-Research-Them-All-1-1-(April-30)

I think you did. I think I was afraid of adding that in that it might result in some problems, but I can't quite remember. I'll see about those problems when the time comes to implement it. (https://github.com/blizzy78/ksp_toolbar/issues/24) I'm not going to change that. I feel your pain regarding the OCD, I'm suffering from the same at times. If you need pixel-perfect location, you can make a one-time change in the toolbar-settings.dat file. Not sure how that would work. As it is now, you can drag a toolbar's size, which effectively is only its width. If there are too few buttons, it will shrink, of course, but if there are too many, it will grow to the right unless it reaches that width, then it will continue to grow downwards. Right, I should use one of the two version fields in the DLL that will not cause dependencies to break. (https://github.com/blizzy78/ksp_toolbar/issues/23)

I haven't looked into kOS all that much. The latest news I heard is that the original author went MIA, and that's from quite a while ago. I don't know if there is a fork that is actively maintained, but as long as there isn't, I would rather not touch it. Voice Commander supports that if you have MechJeb installed. You don't need to use MJ itself, it just needs to be installed for these commands as a dependency.

Right, I should be uploading it on my own server. Thanks for reminding me.

This would be really easy using a plugin - just delete all maneuver nodes once they exist.

I load/save files directly using ConfigNode.Load()/Save(). I don't have a PartModule that does it for me, because my plugins don't have parts.

Why? In the worst case, the program would just crash. It can't imagine it would permanently damage your computer or any files on it. It would basically just exit.

OnLoad/Save of what? I use ConfigNode directly to load/save my configuration files, which is not the same as part.cfg files.

Mind you, I'm not a Splunk guru. Even though we could use it at work, we don't, so the only experience is what I got from private use on my server. It has an awful lot of searching (filtering) and aggregation commands (see http://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Top, then expand "Search Command Reference" on the left), and it can display all sorts of reports and diagrams. Personally I don't think I'm using even 20% of what it can do. So in that regard, it would be better to ask what info you would want to see, and then try to figure out how to do that with Splunk. (For example, a graph over time that shows the average KSP loading time of users that have plugin X and Y and Z installed. Such a graph would be more on the easier side, I think.) Oh, and you could correlate things with crash reports, even if crash reports and regular statistics are transmitted separately.

I agree, I too feel a little overwhelmed by all those colors. Changing the relevant input fields (prograde, normal, radial) to their respective maneuver node handle colors seems best to me. In addition to that, I also agree with the clicking too much. Especially when you're trying to tweak a maneuver node little by little, it is really distracting to focus your eyes on the buttons to find the '-' button, then focus back to see what your clicks will do, then focus on '+' again, focus back to see the results of clicking, and so on. I was thinking about changing the +/- buttons so that there will be only one button that reacts differently depending on which mouse button you click it with - plus with the left mouse button, minus for right mouse button. Really simple, but I think it helps alot to keep your eyes focused on the map itself.

I'm not sure what this tells us. Is that something like, "the average loading time of users who have plugin X installed is ~Y seconds"? As the list is right now, it is not very useful, because it leads to the wrong conclusions. For example, I can't think of a reason why PartHighlighter should increase loading times by a large amount. Personally, I'd use Splunk for analysis and graphing things. I'm sure there are other neat tools as well. Splunk example:

Dr. Jet, that's quite an exhaustive list, thanks! I'll see through it. Please note that I don't think I will be adding some sort of autopiloting commands. I've already done that with the "execute maneuver node" command, but I don't think I should be adding something like "fly me to planet X and land there." I think that would be just too much.

Just move up or down the ladder. The option will appear eventually.

I remember having problems with that exact issue in my IRC plugin. It's probably best to rename the config file.

Or, what's inside that folder?

I have a Steam copy that I don't use, and an unused Steam key. I just use my separate store copy.

You can also use Blender to generate the normal map automatically, as long as you have a second object that has the more detailed geometry. Blender then can calculate the difference and bake that into a normal map.

I think it would clutter the interface quite a lot. So you'd need a way to temporarily hide those buttons, or actually it's the other way around, to temporarily show them when you want to change the factors. But then you get the problem that each parameter (prograde, retrograde, and so on) uses its own factor, and you may get lost in all of it trying to remember which one uses which factor.

That's why the Linux kernel uses the GPL, right.

Just to note, PreciseNode should display Earth/Kerbin days and durations correctly.

Would it be possible to have a change log in the OP? Thanks.

Like Cpt. Kipard described: Build a part (a single strut, for example), then unwrap it, then duplicate/mirror it the way you want the duplicates to be. All duplicates will share the same texture space then. (For the rules of this thread, you need to move the UVs to different parts of the texture.)

You really need to thank regex for that. He created the plugin, and I'm maintaining it now since April.