blizzy78

It is actually the same plugin. Scott Manley just didn't get the latest version from this thread, but chose to use a bundled version instead.

I don't think this is a good thread start to begin with. Yes, there are bad mods. But I just don't think pointing fingers and naming names is a good move. It's better to inform the authors of those mods what could be improved, or what you don't like about their mod in particular.

I can access the download page just fine here.

I'm pretty sure you can change the part config and use KER. Sweet, I've never seen that one before.

This sounds like you didn't install Kerbal Alarm Clock at the right location. Please see your output_log.txt and check for any "button texture not found" messages.

Hi, so I've made my first KSP part. I've always wanted a smaller MechJeb case that is more suited for tiny probes than the default AR202 case, which is why I made this: The part should behave just like the AR202 part, just with a different model. Please note that the screen is static and does not change. It's quite tiny after all. Download tomtom.zip (Source files included: Blender project file and texture image.) I'm hereby placing all of this into the public domain. Do with it whatever you like. Just send me a note so that I can have a look

This sounds like there is an exception occurring. Please see your output_log.txt when that happens.

If it's so much that it bothers you, there's always the possibility to use a hash map in the Toolbar Plugin.

I wonder what kind of CPU time waste you are thinking of here. I don't know the specifics of the animations you are doing, but I can't imagine they're beyond the 5-10 FPS range.

The way you describe it makes it apparent, of course. It didn't occur to me to place textures into that list directly, because that list should have been private from the get go. So this is where my previous statement comes in, that is, Squad is doing something wrong there. Access to an internal list like that should never be granted directly. I know that. Still it doesn't mean I need to open up specific API. If you want to modify it by fetching it from the GameDatabase first, please do so. If you want to use reflection to put it directly into the Toolbar Plugin's structures, then by any means, please do it. But don't complain later if something breaks for any reason. Not quite, but you're kind of pressuring to open up API to accomplish things that "can be achieved using different tools anyway" (my words.) As stated above, I am aware that the textures can be changed without me ever noticing it. I'm not happy about that, quite to the contrary - I'd rather have them be immutable, or have developers jump through some other hoops to be able to change them. But at least I can make Toolbar API users go into some direction by not allowing access to the textures directly.

Shouldn't this be "MonoBehaviour?" (note the U)

Not the way you make it seem with "thousands of unnecessary string reference comparisons per second." Of course I'm holding onto the Texture2D object as long as the IButton.TexturePath does not change. I'm not looking up all buttons' textures every single frame. That is correct. But that doesn't mean I have to open up API that I don't want to open up. I can, but that doesn't really help because I don't have the source of GetTexture() to look at. If you believe Squad doesn't use some sort of hash map there and is hurting performance, you should file a bug report with them. You can modify the texture's contents directly.

Because there is no way for the player to turn stuff down if it gets annoying. If I go and add a nice button icon animation feature to the Toolbar, I'm almost 100% sure we'll see blinking and flashing buttons in no time. The next thing I see me adding then is an option for players to turn off animations. Of course not for all buttons at once, but for specific buttons. Things tend to spiral out of control pretty quickly if there are no restrictions. It doesn't do that. It uses GameDatabase.Instance.GetTexture("..."), and if that method doesn't use a hash map, then Squad is doing something fundamentally wrong. It does not care. I just don't like things like these being changed behind my back.

That is correct, and I'd agree that this needs to be worked on (in the Toolbar Plugin itself.) That's not what I actually meant. I was under the impression that you didn't use the PopupMenuDrawable because one of the reasons was that its positioning was not always the same. So I was trying to point out that the positioning is not done by the PopupMenuDrawable itself, but the drawable mechanism as a whole, regardless of what actual drawable you're implementing. Anyway, I see your point there. The current positioning mechanism is meant more for sporadic use, which in its current implementation gets in the way when the drawable gets interacted with more often (such as in your case with the experiments buttons.) I think I should modify it to some sort of "prefer last position" kind of way. It would position things like it does right now, moving them if they don't fit. But the next time the drawable needs to be displayed, it would position it the same way as before, as long as it fits there, only moving it if necessary. Actually I don't really see the point with animated toolbar buttons, but that's maybe just me. I'm perfectly fine with buttons that permanently change their icon to represent some state to notify the user, but I think doing animations is going overboard. I haven't looked at the code you did for animations, but you could also use some sort of state machine that uses ints instead of strings to represent the current animation frame. As for not allowing access to the actual Texture2D object, that is one of the things I mentioned keeping private at first. I don't like the idea having developers modify random textures without the Toolbar Plugin noticing. I'd rather make them go through a well-defined API.

Ah, I see. Perhaps I should add some code to the drawable positioning so that it will never block the altimeter (and other important GUI features.)

Positioning is determined by the drawable mechanism itself. It doesn't matter what the actual drawable is displaying. Not sure what you mean here. Are you talking about the "Available Experiments" label? It is indeed intended to be recreated every time you need something changed. I usually make things private/internal from the start, then gradually open up once I figure out what's necessary. So just speak up and we'll see

I think that is because the toolbar button does not get assigned an icon when it is created by the plugin. Rather, it gets assigned some text.

Thanks, I haven't added it yet because it looked like it was still a work in progress. It seems to be more complete now on a closer look. I just wish he would make use of the new PopupMenuDrawable feature instead of rolling his own drop-down menu :-/

I'm sorry if my previous comment sounded harsh, I certainly didn't mean to offend. I just don't think this is the right place or thread to seek help in programming KSP plugins, even with the mild Toolbar Plugin relevance.

Perhaps so, but to be honest, I don't want to maintain older versions.

I'm getting the same: NullReferenceException: Object reference not set to an instance of an object at MuMechModuleHullCamera.Awake () [0x00000] in <filename unknown>:0 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) Part:AddModule(String) Part:AddModule(ConfigNode) PartLoader:ParsePart(UrlConfig, ConfigNode) :MoveNext() Also, it looks like the link to the source files is outdated, linking to the source of 0.2.7 instead of the latest version.

I think you should seek help in creating KSP plugins in the appropriate forum.

The Toolbar Plugin does not do anything with action groups.

Do you have any plugins installed that are using the Toolbar Plugin? The plugin does not do anything on its own, it needs to be told.

To not break compatibility for players that have been using the part. I've mentioned that in the change log as well. If you did not ever use it, yes you can.