Diazo

Not something I've seen myself, but there have been other posts on the forum about mirrored control surfaces working correctly, but animating backwards. You could test with two separately (non-mirroed) attachments and see if the behavior stays the same? No clue how to go about fixing it, but that would at least confirm it's an issue other people are seeing as well. D.

I'm certainly planning to look at doing it. The catch is all my mods also need updating to the new UI still and I'm actually rewriting my oldest mod from scratch as the crazy code I keep coming across in it got to me and I can't take it anymore. So any updates on this front are going to be slow, but I'm planning to. D.

That is part of the solution, yes. What is boils down to is that in my current setup the data storage is baked into the KSPAddon modules so I didn't have a separate data object I could pass to the GUI, hence having to make a middle-man data object (and the associated overhead). In my current version the GUI is actually baked into the KSPAddons also, there's a reason I'm rewriting this mod from scratch. So I was trying to find a way around that. My grand realization was the fact that I could make a Data storage class and use an instance of that inside my KSPAddon modules so I can just pass my data to the GUI without having to worry about any sort of middleman data object. I still have to write separate KSPAddon's for flight and VAB, but that has to happen anyway because the scenes are so different. D.

Note that in stock, there is no relation between the state of the action group and the state of the actions in the group. When you activate (or deactivate) an action group, KSP tells all actions in that group to turn on (or off), and that's it. If the action can't do so, or if the action is in multiple action groups, you can get a situation where the action group is activated but the actions (or some of the actions) in the group are not. This is what causes the first press of the Gear button to do nothing sometimes when a vessel is first launched. It sounds like that will not be an issue for what you are right now, but if you get more involved later on (or for others finding the thread), it is something to be aware of. D.

Those are actually part of the Auto-Pilot/SAS system and are used to "hold heading". It uses the available reaction wheels and RCS if enabled to hold the heading. I have made a mod called ModActions that allows assigning those hold heading commands (and several others) as actions and so can be activated by the action group system. D.

Oh, that should be straight forward, just have to find where that is saved on the part. No promises on time, but it's not big deal to do.

@JOHNMKNIGHT While I have no suggestions on your mod itself, could I ask you to start a thread in the Plugins sub-forum about your experiences with (and how to) localize KSP? That's something I want to look at supporting in my mods, but I don't have the faintest idea where to start and I (and probably others) would appreciate any help you could give us. D.

Oh, I'm using lists all over the place in code. Lists don't really work with the UI though, you have to size the UI to handle some arbitrary number of actions and hope you guess right and the user is stuck with a scroll window if they go over that number. @fatcargo On the moving groups issue, what I'm looking at doing is swapping two groups, so all actions assigned, group name, visibility, etc. would be swapped between two groups. Note that this would not include the keybind. Due to how keybinds are tied to the keyset, not to the craft, being able to move keybinds around like that would have unintended consequences once you start changing vessels that are being controlled. D.

Deployment direction? Do you mean add an "Open" and "Close" action? That's easy to do. Do you mean change the direction on the same action? That's iffier and would need more details for what exactly you are after. (Which direction changes in what way?) Now you say stock, but which parts specifically are you after? I need to make sure I hook into them correctly. D.

I'm just going to add a if(flightglobals.ActiveVessel == vesselmodule.vessel) check at the start of my logic and call it good enough. That way the VesselModule only "runs" when it's attached to the focus vessel. Alternatively, you can check against the OffRails state for VesselModules that you want to run on vessels that are loaded and within physics range. Note you need to minimized the usage of the built-in Unity methods though, those still run every frame and you don't want to call them if you don't need to. Compared to everything else running, a single IF statement isn't going to matter in terms of load. D.

Not at present there isn't. As part of the UI rework I am probably going to add a few presets where you can save/load configurations like that across ships. D.

Alright, looks like there's no nice clean answer here. How I am going to proceed is with the data storage object. However, rather then being a "middle-man" object that resides between VesselModule and my GUI, I'm going instantiate a copy of it in every VesselModule and just have it as my data storage as a sub-class. However, for this to work there is one other thing I need to check my assumptions about, if I pass one large data storage object around I'm not wasting memory over multiple smaller data objects right? I have multiple GUI windows that each need some of the data in my DataObject. If I understand how referencing works, I'm not wasting memory by passing a GUI window my DataObject with a whole bunch of data it won't use correct? I'm not actually making a copy of the DataObject inside the GUI window, just passing it a reference to the DataObject instance inside the VesselModule. D.

Alright, watching the discussion the past few posts things are getting a bit scattered and straying from the original question asked. (My last post was guilty of this actually too.) To answer @sal_vager's original question, I believe a rule change along the lines of adding the following rules: 1) A mod must post the version of KSP it supports. 2) A mod must post in the opening post in the forum a list of any other mod's it bundles, including a link to the appropriate thread and the version of the mod bundled. 2a) A mod can not support a newer version of KSP then all the bundled mods do. 3) Any changes made by the mod maker, either entirely new content, or modified content, must have their source available as per usual under the already existing rules. I think this covers @sal_vager's concerns, I would expect that the majority of the "modpacks" that run afoul of the mods and get removed would fail rule 2 and the mods can just infract without having to download and inspect. edit: And @sal_vager beats me to it, pretty much has what I suggested anyway, with the exception of the KSP version supported being required. I know that seems like a no-brainer, but if a modpack says it supports KSP 1.0 and KSP 1.2 is current, you'd like to think it would at least cut down on the people downloading it. I also like the idea of a modpack not claiming to support a newer version then all included mods do, but that's more variable as some mods do work fine after updating. D.

There are two angles of attack here: the license the mod author applies and the rules of the forum. Now, the license is the first thing that has to be considered as it is what states what the mod author is allowing people to do with their mod. The issue at hand falls under the redistribution clause I believe. Do you allow others to redistribute your mod? Yes, great, others can host your work on CKAN, Spacedock, etc. for you. Not so great it is perfectly legal for someone to zip your mod up in a modpack and redistribute it that way. In my understanding, if you maintain your own CKAN or Spacedock mod listing, that is you "distributing" the mod, not CKAN or Spacedock "redistributing" it in legal-speak. This goes hand-in-hand however with the derivatives clause, which is what covers a mod being abandoned and then another person updating it for a new version of KSP. However there is significant gray area here, the CC license uses the term "passed along unchanged and in whole" to define if something is a derivative or not which means that legally speaking if someone changes a single character in a MM config file and then re-uploads the mod with no other changes, the derivatives clause applies as the mod is changed, even if only very technically. Now the rules of the forum are both more flexible as the moderators are around to enforce them, and also more limited as they only cover the forum, not all methods of distribution. In short, the moderators can define a modpack as they see fit and ban them, the question then comes back to "what is a mod-pack"? And at this point I'm going to leave it, I'm actually not sure what my feelings on this subject are. As my mods are utility rather then gameplay or visual/thematic mods, I am somewhat insulated from this issue as it doesn't seem to happen to me. Taking a look at my own license, I typically use GPL-3, it has a clause that "For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions." This is interesting because it could be taken to mean that the creator of a mod-pack must indicated that my mod has been changed and that all problems are with the modpack are taken to him. It's arguable how well that would work and it's still reactionary in that it is action taken after the modpack is put up, not before, but an interesting thought. D.

Wow, umm, that is strange. The overlap must be tripping something in the stock button code, I don't deliberately interact with the staging buttons in any way so I don't even know where to start guessing as to what is causing that. However, since the new version uses the new UI, and so totally different code, hopefully it won't be an issue any more once I can get it out. D.

@fatcargo One of my long term goals is to actually make a decent manual for this mod, everything has been added in piece meal and the first post in this thread doesn't cut it anymore. It's being put off until the next major update because I'm redoing the UI to move it to the new UI system implemented in KSP 1.0 and everything is going to look different then, although I'm trying to keep the usability the same. As for your reported issues, they should be fixed in the next update as I'm redoing the entire UI so the issues you reported will be running under entirely new code and hopefully they will be fixed. If they aren't I will look into them at that time. (Can I get a screenshot of the overlapping toolbar button though? Not 100% what you are describing.) Unfortunately, I have no ETA on the new version, I'm moving to a new house at the end of March and my KSP modding time for the next while is going to be limited at best. D.

Alright, first a bit of background for context. I am redoing my AGX mod pretty much from the ground up to use the New UI and VesselModuels to significantly steamline how it works. However I want to use the same GUI objects in the VAB as well as in flight which gives a problem because there is no "VesselModule" I can hook up to in the editor. How I have done this previously is I made a data holding object that I passed to the GUI window's instantiate method and so it didn't matter what scene I was in, I was making the object I passed myself so I could keep it consistent across game scenes. Now, I'm trying to get away from having to do that and just directly pass the object I am using, but in flight I'm going to be working inside a VesselModule which causes issues in the editor as there is no VesselModule present. I can think of 3 options: 1) Instantiate a fake VesselModule in the editor somehow and use that. 2) Code my GUI instantiate to take multiple input types so it takes VesselModule in flight and something else in Editor (probably a custom data object). 3) Code my GUI instantiate to take a middle-man data object so it doesn't care what scene I'm in, my scene specific code takes care of the problem. I have a pretty good idea how to do #3, think I know how to do #2 and wouldn't know where to start on #1. However #3 is also the most complicated to implement, I'd really like to do #1 but don't have a clue how at the moment. Note I don't need any of VesselModule's abilities or uses, I just need an object I can pass to my GUI. Thoughts? D.

Hmmm, never actually had a request to move groups before. At first glance, I'm not sure about it. What should move? Do only the actions move? The keybind? The group name? Now, what is in the mod is visibility. you can show/hide action groups. In the main window are the little green 1 through 5 buttons. Those are on/off (green/red) buttons that control when a group shows. Then when in flight, the top right button of the flight window, "Group1" by default, controls which visibility setting is applied. So you could have liftoff groups in visibility setting 1 (1 is green, rest red), orbital maneuver stuff in 2 (2 is green, rest red). Then on the launchpad it applies visibility 1 by default, then once you reach orbit you change it to visibility 2. As indicated by the 1-5 buttons, there are 5 visibility settings and they are saved on a per-vessel basis. D.

You are correct in recent versions of KSP, antennas have moved to using ModuleDeployableAntenna. I was pulling from the fact that the last time I had worked with them they were still on ModuleAnimateGeneric and I was using them as an example of how this mod can't be limited to "just these parts", this mod adds the actions for every part in the game that carries a given partModule. D.

On the VesselModule, I wouldn't expect it to function in the editor, rather I'd expect that .NonFlightScenes flag to control whether it runs in other scenes where time passes, such as the main KSC view or the tracking station. Have not tested that, but with what I know of how the editor works, I'm not sure how a VesselModule would work correctly.... So I would not expect VesselModule.OnSave() to do anything (as I don't think it runs) in the editor. Can't help on the physics connection question, never touched that myself. D.

This is concerning, I'm currently working on converting all my mods over to use VesselModule as it offers me some nice options. Now I'm also moving to the new GUI when I do this so I won't be calling OnGUI, but is there any trick for determining code that will cause garbage? I don't want to get everything finished and the profiler show me I'm spilling memory everywhere. D.

That is a legacy of the fact that the original concept for this mod way back when was to add a lot more actions for people who were building sim pits, it wasn't to add a "few more groups for complicated vessels" it was "add dozens of groups for those big complicated sim pits" and the UI design reflects that. Since this mod is the only mod (that I am aware of) that adds more action groups, it also became the "few more action groups for complicated vessels" mod as well, but that was a later development. Anyways, I'm currently redoing the entire mod to move to the new UI system so I'm thinking about tweaking the UI to reduce the size on screen, including showing fewer groups at once, but it's going to stay generally the same as it currently is. Due to how actions get assigned and all the other information tied to a group, add/removing action groups as needed is not something that's going to happen. Rather, I'll probably make it so you can configure how many groups show at once (probably in multiples of 10), rather then the hardcoded 50 groups that show now. D.

Weird, it's split for some reason. Some use the AnimateEngine, some use the ModuleAnimateGeneric. That's an issue for this mod as it works off PartModule, I'd have to code this twice to support both types of engines. Probably doable still, but still need to actually look at it to see. D.

Alright. Looking at that most recent version of that mod (linuxgurugamer's maintenance thread), those engines don't actually use ModuleAnimateGeneric, they use AnimatedEngine from BD Armory. I'd have no problems hooking into that module as it is dedicated for engines and doesn't pose the issues that ModuleAnimateGeneric does. The catch is I'm not familiar with that module so I'm not as certain how I'd handle the code. I'll see if I can at least poke at it this weekend, but real life is pretty busy already. D.

Hmmm, I'm not sure about doing that. It is probably technically possible for me to code that, the issue is that it would have significant overhead and that I'd be worried about breaking something. Module Animate Generic is what controls the animation, it is usually triggered by other code on the part which checks what state it is in. Take a stock antenna. 0 is stowed, 1 is deployed and decimal values happen in between. Now when you give the game a "send data" command, it commands the antenna to deploy, waits until fully deployed, sends data, then retracts the antenna. If you set an animation limit, the antenna never fully deploys so your send data command hangs on "waits until fully deployed". I'm not sure what this would do to the game. What do you need this for? Is there another way to accomplish it? D.