blowfish

Might want to check what you quoted ... I don't think @Sgt Charlie will actually see this because that post was formatted incorrectly.

General update: After a couple of minor changes, AJE seems to be generally working in 1.1. No release version is available yet, but the changes are pushed to Github. @Ser I added a field to jets: throttleResponseMultiplier, which should affect how fast the jets respond. I still want to implement a long-term solution, but hopefully this will satisfy your needs in the interim.

It doesn't look like display is actually used. Maybe this was intended to be a more human-readable form of options, but it hardly matters if you're using it on an integer field (it can be used on an int or string field).

It can be changed with code ... see Porkjet's habitat pack. IVAs wouldn't really work though, and it's hard to get things like windows and airlocks to look right on a procedural part.

It's not checked now. Win64 builds of KSP are now supported by Squad, and all indications are that they are now stable, so it makes sense.

I can probably write a script to pull them from all the stock parts if you want, but I figured it was easier to just look at similar parts.

Thanks for offering to do this! I'd say just stick to the stock format - use the stock tags and keep them alphabetical if possible.

General update on the state of things: Root part bug fixed without mercy. It required a lot of code changes but I think everything is in a better state now. I managed to integrate the new UI_ChooseOption into the part switching. The UI is much cleaner now. You can see a screenshot here (even though it's meant to showcase a bug) Gimbals seem to work on the new module without any changes. So yay. This means we can get rid of KM_Gimbal as a dependency (it's not going to be updated anyway) All parts now have tags to aid searching, and honestly this is a lot of work that I'm probably not going to get to. If someone wants to help with this, it would be much appreciated Still waiting on updates from RPM and Smokescreen.

Oh, and something else to note: onFieldChanged will not fire for symmetry counterparts. The field's value will update, however (if affect symmetry is set).

I didn't notice onFIeldChanged before (was it added in a recent build?). I think that might solve the problem actually. Maybe the reason it doesn't work for you is that you can't set its value in the attribute (since only basic types are allowed as attribute parameters). I've updated the code above with something I believe will work, will be testing shortly.

Created a bug ticket here: http://bugs.kerbalspaceprogram.com/issues/8295

It's a UI control just like UI_FloatEdit, UI_Toggle, etc [KSPField(guiActiveEditor = true, isPersistant = true, guiName = "Subtype")] [UI_ChooseOption(affectSymCounterparts = UI_Scene.Editor, options = new[] { "None" }, scene = UI_Scene.Editor, suppressEditorShipModified = true)] public int subtypeIndexControl = 0; suppressEditorShipModified prevents onEditorShipModified from being fired (the default is that it is fired). Set this if you're going to fire it yourself after doing whatever update is supposed to happen. If you know what the options are beforehand, you can set them there. In my case, they're dynamic, so I have to set them in OnStart() public override void OnStart(PartModule.StartState state) { // ... BaseField chooseField = Fields[nameof(subtypeIndexControl)]; chooseField.guiName = switcherDescription; UI_ChooseOption chooseOption = (UI_ChooseOption)chooseField.uiControlEditor; chooseOption.options = subtypes.Select(s => s.title).ToArray(); } You can listen for the value being changed using onFieldChanged public override void OnStart(PartModule.StartState state) { // ... chooseOption.onFieldChanged = UpdateFromGUI; } private void UpdateFromGUI(BaseField field, object oldValueObj) { int oldValue = (int)oldValueObj; // If you actually care about it UpdateSubtype(); GameEvents.onEditorShipModified.Fire(EditorLogic.fetch.ship); } (modified a bit from my actual code for clarity)

UI_ChooseOption seems to have oddities when displaying option names - if they are too long to display at the default font size, some are truncated, but some are displayed at a smaller font size.

I might update after I update B9, which isn't until after KSP 1.1 final is released.

That's more or less correct, rotor thrust depends on not just throttle but density, vertical and horizontal speed, and maybe some other stuff that I'm forgetting. In general with AJE there's no way to know how much thrust you'll get at a particular throttle level and flight condition without actually running the solver there. So calculating backwards from thrust to get a particular throttle is impossible - if you want this kind of control it needs to be done with a PID.

You could use the bi-coupler or adapter.

This isn't really MM related, but make sure the model actually has originalTexture and that myFolder/myTexture exists.

Not sure what the problem is, but it probably isn't ModuleManager's fault. Check the log and see if something on the part is throwing an exception somewhere. And welcome to the forums

If you're on the prerelease, why did you expect things to work? I stated pretty specifically that they don't. Even if the part switch and animation plugins work, there are still a huge list of broken things.

Update on the general state of things: B9AnimationModules seems to work in KSP 1.1-pre without any code changes, B9PartSwitch required only a few. I'm currently working on fixing the bug with B9PartSwitch and root parts. This is not 1.1 specific, but a reasonably serious problem that needed to be addressed. It's proving a lot more complicated than I thought and requires refactoring a lot of the code. I think I'll have a solution that will work but that's what I thought about the last two before I actually tried them. So we'll see. The heavy landing legs never had suspension anyway (just an animation) so they're working as they always have. Might look at adding suspension at some point in the future. FSWheel is decidedly broken, and thus so are the legacy landing gear. I messaged bac9 to ask for the source files, if he gets back to me I'll take a look. But they're legacy anyway, so I'm not going to spend a huge amount of time on it. KM_Gimbal needs to be replaced as Sarbian won't be updating it. The stock module might require changing the orientation of the gimbal transforms though, so this might require re-exporting the models. Some plugins still need updates to work at all, in particular RPM and Smokescreen.

I think that's called a credit card

@Shadowmage Makes sense. Just for reference, enabled affects whether Unity events fire, and isEnabled affects whether KSP events fire (OnUpdate, OnFixedUpdate, etc. Note that OnStart happens regardless).

@Shadowmage Any idea how you're going to implement the module switching yet? There are two options I see: Hold the ConfigNodes in memory (as strings because they serialize) and actually create/destroy modules as needed. Might cause a bit of overhead when switching. Not sure if action groups would survive. Set enabled and isEnabled on each module, which prevents updates, and disable/enable the part action UI elements. Might lead to unexpected weirdness in some situations.

The ones bundled with B9 are equivalent. You are on 1.0.5 and not the prerelease, right?

Thomas P submitted a fix a while ago ... colliders can still be concave, just not on a part (statics are fine) - they just have to be forced to be concave in code since KSP forces them to be convex when loading the model.