blizzy78

Ah, I totally forgot about that one. I don't want to get in the way if there has something been done already. Might I instead suggest opening a new thread and making it an official fork? Just take me as an example, I was under the impression that the plugin is totally dead.

I wonder if it would make any sense picking up this plugin and bringing it up to date. If I remember correctly, it had problems with vessel types once space objects were introduced. I would be kind of sad to see this go down the drain. So, is anyone using this?

App Launcher http://forum.kerbalspaceprogram.com/threads/86682

You go first

You can drop that anywhere in your GameData\ since it's a config file for ModuleManager.

Since we're all about this privacy statement: It's missing "current date/time." While that is perhaps not transmitted actively, the server surely knows it.

I like that little trick, but I find it too distracting. If the images were more faded against the background...

It is not possible to assign keyboard shortcuts at this time, but I think it would be nice to have.

I believe something went wrong when you unpacked the archive. The folder's name is supposed to be "000_Toolbar", not "000_toolbar". The same might go on with Kerbal Alarm Clock, leading to the purple "texture not found" button.

"do-while" and "while" loops are not just preference. They work differently.

What makes you think development comes to a halt after a release? Of course they're working on the next version. Not that surprising really.

Did you bring that up with the IR developer?

My guess would be that System.Drawing is not included in the Mono version that KSP uses.

I just realized that "backgrounds for IDrawables in general" doesn't really make sense. The IDrawable mechanism is just a framework so that something can be displayed. The whole drawing is done in the third-party plugin - there's no way I can inject a background there. (Of course the PopupMenuDrawable is a whole other story.) That said, I should probably also add a default "window drawable" implementation. I've been using GUILayout.Window() in a few places now for drawables, and it's a bit of a pain to get it right. So that's where I could help out other developers a bit, too.

Sweet. Now on to some real programming instead of bug chasing

I have finally been getting Texture Replacer, yeah.

Let me just go over your points real quick. I might have turned some of them down in the past, I can't quite remember everything now. So let's instead focus on what I think of them right now. Animations: Okay, I think I'll add support for those (time permitting, as always.) I personally think animated buttons might be stretching things a bit, but on the other hand users will complain if they find it too heavy. So that's more of a concern of the author adding the animations rather than the Toolbar Plugin. Direct texture access: Not going to happen. Not sure where this comes from. Is that backgrounds for IDrawables in general? I think I like it, but not quite sure how that would look like. If you have specifics in mind, please let me know. That's the way PopupMenuDrawable is implemented right now. I can't quite remember if there was a specific reason to do it that way, at least it must have been easier to do (heh, if that's not reason enough ) Back then I agreed that it would be nice to have. Not having added it yet doesn't mean I turned it down. It would be nice to have some specifics, meaning, what would you need? You mentioned that currently it's impossible to see which button opened up some drawable. Anything else?

It says right in the ModStatistics post:

Looks like some bottles of e-cigarette juice to me on the far left.

I still can have negative feelings about the project being forked, no? (Again, I'm not talking about the Toolbar Plugin here, just project forks in general.) When you say "convince you to change or add any toolbar features" - I can only remember one particular thing you wanted changed. It's not that I always decline adding or changing anything in the Toolbar Plugin based on user requests. So it's not exactly "difficult" per se. From the technical view, I agree. But in the longer term, it leads to a user base split, which I think is bad for the existing user base as well as the to-be-established user base of the fork. But in any case, I just wanted to bring that small thing up, not make a whole discussion about it in this thread. That's not to cut off any discussion about it, it's just because it's off-topic. Yes, by maintaining a hard dependency on the DLL, and quite a few plugins do that already. I think it would be best to implement that directly in the toolbar, and as another user has suggested, make it a user setting of some sort. That way, both kinds of third-party plugins could benefit from it, the ones with a hard dependency, and the ones using the wrapper.

I'm not entirely opposed to supporting the App Launcher. I was just stating that it kind of defeats the purpose of my plugin, which I don't think you can deny. Edit: But that's not the point I was trying to make. I was to say that I don't think all the forking is doing much good, and this comment is not specific to the Toolbar Plugin. It's much better to try and get together with the respective developers to combine efforts rather than splitting up the user base.

Or better yet, submit a pull request. All that fork-if-you-don't-like-it nonsense is a bit ridiculuos.

For reference, this seems to be the exception that occurs with Final Frontier installed: NullReferenceException: Object reference not set to an instance of an object at Nereid.FinalFrontier.Ribbon..ctor (System.String imagePath, Nereid.FinalFrontier.Achievement achievement, Nereid.FinalFrontier.Ribbon supersede) [0x00000] in <filename unknown>:0 at Nereid.FinalFrontier.RibbonPool.CreateRibbons () [0x00000] in <filename unknown>:0 at Nereid.FinalFrontier.RibbonPool.OnGameStateCreated (.Game game) [0x00000] in <filename unknown>:0 at EventData`1[Game].Fire (.Game data) [0x00000] in <filename unknown>:0 at Game..ctor (.ConfigNode root) [0x00000] in <filename unknown>:0 at GamePersistence.LoadGame (System.String filename, System.String saveFolder, Boolean haltIfIncompatible, Boolean suppressErrorMessage) [0x00000] in <filename unknown>:0 at MainMenu.LoadGame () [0x00000] in <filename unknown>:0 at TextButton3D+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) So for anyone having problems trying to start a new game or resuming an existing save game, I'd advise to remove Final Frontier and try again.

For good measure, try only Toolbar and FF. If the issue still persists, bring it up to the FF dev.

Do you even care to read the change logs of the mods you use?