blizzy78

Well congratulations on your successful missions

I'm not after attention, I just want this to work

Right, you were pointing that out to me on IRC. Depending on release dates, I should be changing the required path to remove "000_".

Another followup on the issue of how to deal with the dependency on the Toolbar Plugin: Without going into any of the complicated details here (many thanks to Majiir for tossing lots of ideas at me), I think I will be going for the following approach: Third-party plugin authors can grab a copy of the Toolbar.dll, reference that in their project as usual and compile against it. That of course will create a hard dependency on the plugin. In the third-party plugin's download, the Toolbar.dll must be included. This ensures that the hard dependency can be resolved, and there will be no need to have some sort of "fallback" because the DLL is always available. In the third-party plugin's download, the Toolbar.dll must be located under the path GameData\000_Toolbar\Toolbar.dll This serves two purposes: 1) The path starting with "000_" ensures that the Toolbar.dll will be loaded as early as possible, so that dependent plugins will not fail to load. 2) Using always the same path to install the Toolbar.dll in players' installations, this prevents all sorts of complicated problems when there is more than one copy of the DLL. I will be working hard to ensure that the API will be upwards-compatible, so that a third-party plugin compiled against an older version of the Toolbar Plugin will work fine with a newer version of the plugin.

A follow-up on this aspect: As I understood ModuleManager's code, every instance of it looks at all assemblies that have been loaded. If it finds one that is ModuleManager, and is a newer version, it would disable itself and leave the hard work to that newer version. This approach works fine for ModuleManager, because it does all by itself. In the Toolbar Plugin, things are a little different: Third-party plugins would invoke a method to add new buttons, and register with an "on click" event handler for those buttons. I haven't tested anything yet, but I think the ModuleManager approach will be rather difficult here. Of course, not all is lost. The simplest approach would be to not include the Toolbar Plugin DLL into third-party plugins' downloads, but to require the separate installation of the Toolbar Plugin by the player. Of course, that puts the burden on the player, which I see as a barrier to entry for third-party plugin authors here. Good point, I'll have to test that. Here's to hoping the plugin loader will ever be fixed.

I don't see a flamewar here at all, just the stating of facts. But yes, I'm afraid this thread will go nowhere. It has all been discussed to death. To answer your original question, I don't think there is any other mod out there that adds new celestial bodies. And as far as I have seen, it looks like it is quite a complicated task, so I wouldn't expect such a mod for a while (with no prior source code to learn from, of course.)

OP is talking about preventing players from using those features, which certainly has its applications.

Well, yes. But a link was posted to it, which, according to mods, was not allowed without source code, either. So the links got removed. And then, quite a discussion ensued, with thread locks handed out. (I'm not judging any of the actions taken, just stating facts.)

It's not the mod per se that is controversial, but to publish a mod on these forums, you simply have to play by the rules. Which the author didn't.

No need to bump just over three hours later.

Every button has a Visible property to control whether it is currently visible or not. You could simply check which scene the game currently is in, then set the Visible property accordingly.

I may have forgotten to tell everyone how to move buttons around, so here goes: At the start of the plugin, every new button that hasn't been positioned by the player is auto-positioned on the screen. Also, every button is locked into position. To unlock a button, simply right-click it. You can then move it around freely. While unlocked, the button cannot be clicked in the regular way. To lock button position again, right-click a second time.

At this time, a button's text, icon, and text color (if there is text) can be changed at any time. So this allows a plugin author to change button appearance.

Actually, I personally like the default Unity style more. But I don't see a problem to let the player decide which style they want.

I have updated the OP to include links to full source code (having inline documentation), links to classes relevant to plugin authors, and a link to a fully compiled test installation that you can simply drop into your KSP installation to test the plugin. You can also use that DLL to compile against it. Please note that although all of that is available now, this plugin is not yet ready for distribution to players (aside from testing.) Please DO NOT include the DLL into your plugin's download.

I've not been doing anything on the mod since 0.6.1 has been released, so...

They are saved directly in your save file. To reset all achievements, you can simply clear the "achievements" block: SCENARIO { name = EarnedAchievements scene = 6, 7, 5, 9, 8 achievements { ... delete all lines here ... } }

Yes. For now I have only concentrated on making things work. There is no support yet to control in which scenes your buttons are visible. Yes. That I haven't decided yet.

Hi, there are quite a few plugins now that add various GUI buttons to the game. Right now, every plugin author has to implement button behaviour themselves. Also, there is no consistent button style between different plugins' buttons. I have written a plugin that is targeted towards those plugins. Specifically, it provides an API for third-party plugins to provide GUI buttons to a toolbar. Those buttons then can invoke an arbitrary action specified by the plugin's author, such as opening a new window. The ultimate goal of this plugin is the separation of specifying a button's contents (such as text or image) and its action from the actual display style and position of the button. The player should be free to position buttons anywhere they please. Please see this (older) video demonstrating some of the features: Feature List A draggable and resizable toolbar holds all buttons Buttons have a texture (icon) Custom button order can be maintained Unlimited number of toolbars per game scene Custom button folders can be created to improve organization Toolbar position is saved between KSP restarts Toolbar will auto-clamp to screen area so that it cannot be dragged off-screen Toolbar may auto-hide itself if positioned at screen edge Clicking a button invokes an arbitrary action specified by plugin author Every button looks the same, no need for plugin author to provide any styles Resources Download Toolbar Plugin 1.7.13 Source code: https://github.com/blizzy78/ksp_toolbar (The Toolbar Plugin is licensed under the BSD 2-clause license.) Classes relevant to plugin authors: ToolbarManager (ToolbarManager.Instance field only) IToolbarManager (interface to the toolbar manager) IButton (interface to a button once created by the toolbar manager) IVisibility (fine-grained control over button visibility) GameScenesVisibility (button visibility controlled by current game scene) Full example code: https://github.com/blizzy78/ksp_toolbar/blob/master/TestButtons/TestButtons.cs (This is placed into the public domain for obvious reasons.) How to Integrate Into Your Plugin There are two ways to add Toolbar Plugin support to your plugin: Create a hard dependency on the Toolbar Plugin and bundle it with your download Download the pre-compiled archive linked above. Copy the folder GameData\000_Toolbar\ into your KSP installation that you use for development. Make sure your project is targetting .NET 3.5. Add a dependency on Toolbar.dll to your project. Use the Toolbar Plugin's API (example code). Heads-up: Make sure to call IButton.Destroy() when your plugin is unloaded. If you don't do this, your buttons will stay around while your plugin is long gone. When publishing your plugin, be sure to include the folder 000_Toolbar\ in your download's GameData\ folder. Do not modify anything in the 000_Toolbar\ folder. Do not rename this folder. Use the Toolbar Plugin wrapper to provide optional Toolbar Plugin support Download the pre-compiled archive linked above. Copy the folder GameData\000_Toolbar\ into your KSP installation that you use for development. Make sure your project is targetting .NET 3.5. DO NOT add a dependency on Toolbar.dll to your project. Copy the ToolbarWrapper.cs file into your project. Edit the namespace in ToolbarWrapper.cs to match your plugin's namespace. Use the Toolbar Plugin's API (example code). You can use ToolbarManager.ToolbarAvailable to check if the Toolbar Plugin is actually available. Note that you must not call any other Toolbar Plugin API methods if this returns false. Heads-up: Make sure to call IButton.Destroy() when your plugin is unloaded. If you don't do this, your buttons will stay around while your plugin is long gone. When publishing your plugin, you can optionally include the folder 000_Toolbar\ in your download's GameData\ folder. Do not modify anything in the 000_Toolbar\ folder. Do not rename this folder. Change Log Please see the addon release thread for a list of changes.

I have made in-game tutorial plugins for both rendezvous and docking. Perhaps you might want to give them a try. (see signature)

Care to let us in?

Made an Apollo-style mission to landing on Duna, ascended back up, exited Duna's sphere of influence, only to notice that I don't have enough dV to make it back to Kerbin. So I sent out a rescue mission to rendezvous in Kerbol orbit, which went just fine. The next problem was that the rescue vehicle had room for enough Kerbals, but only one of the pods had parachutes. So I had to send another "rescue" mission up into Kerbin orbit to get the last guy out of his misery. They all made it back home safely.

Internet Relay Chat Plugin 0.6.1 is now available for download, fixing a rather small but embarassing bug.

Personally I've given up on launch windows. I just go out of Kerbin's sphere of influence, then create a node on my Kerbol orbit to see the closest approach markers. Drag the node around and/or fiddle with the node to get them closer together. If they are too far apart from one another, I just timewarp a complete orbit and try again. It's really simple actually.

@OP: I've made an in-game rendezvous tutorial that should help you getting within docking distance, without zipping by the target vessel. (see signature)