blizzy78

It doesn't. It looks like there is some way to restrict the mouse pointer to the window, but it's OS-specific. I really don't want to go that route.

I think they very much do, because they add challenge, even in sandbox. Of course you need to kind of roleplay the whole thing, but if you don't like to carry around heavy lifters and big transfer stages, you can set up shop on another planet where you can refill. Just look at Kethane, it is *incredibly* popular.

Because I can. Now seriously, I also like to see the resources system get implemented at some point in the future, but I think it is moot to discuss whether it will be in a DLC, in stock, or will be canceled (please not.) What's more, just adding a poll to your post because you can?

I'm missing an "I don't care" option. No really, I find the point you are trying to make quite moot.

That's odd, because all the Toolbar Plugin really does is create a regular Unity button, then listen to button clicks, which it routes through to the respective plugins. So unless Unity sends a button click event for whatever reason, the toolbar does nothing on its own. Also, it doesn't know or care what the third-party plugin will do once it receives a button click event. But I'll see what I can find. I think I read about that over on sarbian's new thread. At first glance I'd say that must be a MechJeb bug (or rather sarbian's new toolbar-related DLL) because the Toolbar Plugin doesn't care about switching vessels. The toolbar itself is global, so a button will be held on to for as long as the plugin that created it wishes. In the case of MechJeb, it needs to take care that it may run multiple times on different vessels (within physics range), but only a single button should be created. I haven't checked sarbian's source code to see how he handles that.

This is not possible without a mod's support for it.

I'm sorry, but I consider the Kraken a game bug, not actual gameplay. So, no achievement related to it.

Remember, though, it's "it's", not "its". (Not that any of this matters to OP and their question.)

It's worth noting that you don't need to get into a high parking orbit so that you can use max timewarp. You can always max timewarp with any landed vessel, including one still being on the pad.

Oh, okay. That I don't know, but I'm pretty sure someone else does

I'll try and answer this using data from the Wiki: http://wiki.kerbalspaceprogram.com/wiki/Kerbin The rotational period is 21600 sec (6 hours.) The orbital period is 9203545 sec. So that's ~426.1 Kerbin days per orbit. Since a Kerbin day is only 6 Earth hours long, that translates to ~106.5 Earth days.

Toolbar Plugin 1.1.0 is now available for download, with a new toolbar-specific drop-down menu that allows to configure the toolbar. I've added a download link to the OP so that players may update their installation independently from third-party plugins' releases.

Toolbar Plugin 1.1.0 is now available for download, with a new toolbar-specific drop-down menu that allows to configure the toolbar.

Looking good, glad to see you could animate it the same way as you did with the native button. I'd suggest changing the tool tip text to just "Kerbal Alarm Clock".

Right, for now the toolbar stays at the same position in all scenes. It should never display when there aren't any buttons visible, though. Then again, I think I know what the bug is that does it. Edit: Fixed it for the next release.

I've edited the OP to put up a new video that shows the current state of development. (yet to be published)

I've edited the OP to put up a new video that shows the current state of development. (yet to be published)

This will be easier with the next version of the Toolbar Plugin.

Right. As I already wrote over in the players' thread, I have plans to improve on that. Right now I'm in the middle of adding a toolbar-specific dropdown menu, which is coming along quite nicely. In that menu there will be an option to lock/unlock the toolbar's position and size. Unlocking will make the complete toolbar draggable.

Correct. The Toolbar Plugin doesn't really care what it is, except for maintaining button order. In early versions I had everything installed under GameData\blizzy\Toolbar\, so that's where this is coming from. Don't pay too much attention on the actual texture paths in TestButtons.cs, they will always depend on the actual installation. Right, but I'd really like to encourage everyone to actually include the Toolbar Plugin into your plugins' downloads. Of course I can't make anyone do my bidding if that's not your thing

https://github.com/blizzy78/ksp_toolbar/blob/master/Toolbar/IButton.cs#L70-L73

To drag, you need to click and drag anywhere in the toolbar's rectangle except for buttons and the resizing area. That is, dragging at any edge should work. I agree that the areas are extremely narrow. I have plans to make it easier for players to position/resize the toolbar by adding a toolbar-specific dropdown-menu with options. It will look like this: (note the little arrow button in the toolbar) This will also allow players to reorder buttons in a later version.

I'm not doing anything special with the texture, loading it as usual through the GameDatabase: GameDatabase.Instance.GetTexture(TexturePath, false) The error you see does not stem from the texture size, it will put a different error into the debug log if you exceed that size. Yes, there's a minor bug in there that those buttons still show up while they shouldn't. Text buttons are no longer supported. I chose to leave it in there though because I'm planning to use it for drop-down menus. No, you only need to do that once. It doesn't matter where, because that code doesn't really do much. The actual work will be done much later during ToolbarManager's OnGUI method. For example, the TestButtons example code constructs all its button in its constructor. Edit: I see that you're using "[KSPAddon(KSPAddon.Startup.Flight, false)]", so that shouldn't cause any problems with the GameDatabase not being ready for use. Please do not use "MainWindow" as your namespace. It's better to use your plugin's name. 1. Nope, it's your call 2. Will look into that. For now I chose to put it there because of fear that players might overwrite their settings. But after all, other plugins do it the same way, for example MechJeb. If you overwrite MechJeb's settings, you're in for lots of frustration. So I guess I should be moving that file. 3. Thanks, good idea. I think I will be doing that when I come around to implement (optional) auto-hiding at screen edges.

Right, I didn't post a link in this thread because it doesn't really make sense. Instead I was trying to show off what exists and can potentially be used by third-party plugins.

Not sure if it is intended, but I'd consider it a minor bug: The transparency slider in the settings also modify the transparency of the settings windows themselves. I think it shouldn't do that.