TriggerAu

You can link an axis to the speed, but what your describing sounds like linking an axis to the playposition which is in the released version and it can play forwards/backwards based on the joystick postion You can do the same part in multiple KALs and play them independently yes. Currently the "last" one will win any setting

Thanks Steve, Ill dig into whats involved in changing those vs new fields vs other plans, etc. For the second one - TryGetFieldUIControl simply replaces the "am I in flight - therefore grab the uiControlFlight logic" casue we us ethe fields in all scenes. Your probably grabbing the right thing already then from above. the minValue/maxValue/stepIncrement of the UI_FloatRange will be the correct values for the range of the UI field, but they can/are modified in game at various points. My guess would be that kOS is scraping the attributes of the Field, or scraping the values before all the partmodules start/setup and its getting the default attrib values. Maybe have a look for that timing? from the description above sounds like how we read/write and use the UI_FloatRange fields in many scenes, those min/max/step values are not "non-changing" by design so the attrib/initial values may not always be the same. As an extra wrinkle/feature, the robotics things like targetExtension are actually KSPAxisFields - this has its own min/max which actually defines the valid range for controller input of the field and you could use those regardless of the UI configuration - we matched all of ours to the UI ones, but no guarantees everyone will do that - and that would involve changes that might not be the greatest for you. See how you go with the timing and Ill get back to you on the others. Can you do me a favor and log a "feedback" in the tracker and list any fields you know are not good for you - like currentExtension on the piston - and I can bundle any work up in one go. Poke the link back here with the number. Ta

I'm pretty sure I understand both of these Problem 1: Is going to be because that is a string field for display and is only worked on when the PAW is open to cut down on the string formatting work, Garbage and processing. My suggestion will be that we expose a "value" that's always updated (if there is not already). Is it easier if these are fields or methods or irrelevant? Problem 2: This one is more interesting, I can understand the use of the UI fields to help with the limits, but it appears that what you've got there is the attributes on the field definition and not the range of the UI Controls themselves. This would be especially common in the robotics parts as the player can change the limits in edit mode. The way we do this in the stock code is to grab the UI_FloatRange control and read its values. Its not a new problem for range controls im sure, but much more obvious with the way they share modules. So a simple method to demonstrate how you could read that sorta stuff is below /// <summary> /// Get the Min Value from a fields UI Control /// </summary> /// <param name="p">PartModule containing the field</param> /// <param name="fieldName">the name of the field</param> /// <param name="minValue">the min Value from the UI_FloatRange</param> /// <returns>True if the field exists</returns> private bool GetRangeMinValue(PartModule p, string fieldName, out float minValue) { UI_FloatRange rangeControl; if (p.Fields.TryGetFieldUIControl(fieldName, out rangeControl)) { minValue = rangeControl.minValue; return true; } minValue = 0; return false; }

Whats the method that kOS etc use to try and read these values? eg. if we exposed the values as Properties, vs fields, vs KSPFields would it make a difference or usage in kOS, etc?

The button has two states - In "scale" mode the position of the points along the sequence is maintained relative to the whole sequence, in "maintain" mode their time position is kept and extra time is added at the end (or cut off if shrinking) For a real world example lets say we have a sequence that is 5 secs long and a points at 0, 2 and 5 secs, and we change the length to 10 secs. In Scale mode the points new time values will be 0, 4 and 10 secs and the sequence takes twice as long (as per KAL does today). In Maintain mode the points will be 0, 2, 5 (the original 3) and a new point at 10 secs to complete the sequence. If you shorten teh sequence in maintain mode the points at the end get clamped inside the time period and not deleted Hopefully that explains it OK

It uses the same "field" set up as the AxisGroups feature, so any field in a partModule that has been classified to say - let me be bindable to an axis can be added. Thus modders can easily add this capability to their parts and they become KAL compatible. eg the light color is controllable in moduleLight. WIll be super to see what people think is good for being bindable too. I'm sure there will be extra fields people think will be useful to do this with and will keep an eye out and our own ideas too Each controller has a sequence, you can bind the same part/values to different controllers and then play them as you want, as opposed to multiple sequences in one controller

This bit in the article has some bits about base game updates

I have a new plan... <humor>I'm soo misunderstood</humor> Nailed it!

Sorry for that - my attempt to add some humour didnt come across right. We of course we want more complex and crazy and look forward to seeing what you all can come up with

For each of the parts we moved out we implemented an UpgradePipeline script to swap the part to its replacement and adjust the vessel on load of the save or craft. If you do want them specifically then copying/moving the files back into gamedata will restore them and the save/craft pre upgrade is stored with a .original extension when the upgradepipeline handles it

Yes sir.

Not sure I'm across the entirety of the above, there's a few bits that feel like assumptions that I can expand on. There wasn't any call during the development cycle aside from using the in-place term - its been that for a super long time and no previous feedback, there's no apparent need for consistency, we aim for consistency as much as we can and the core devs have a significant ratio of native-English speakers (unless Australian English doesnt count ). That expanded, I too like the term intercept as it includes the temporal component better than intersect. It's not been raised before, but hopefully others feel strongly about it and the feedback entry, I know I'll vote for it.

The text in the Maneuver Mode tool was set to match the existing one on the map nodes, if you'd like a change to the text a feedback would be the best way to proceed as we would change all for consistency if we did - I didnt find one for this request in a quick search.

yupp, thats why i mentioned it cause I have vis of extra info I cant find any ref to the PJ comments so cant add on that one

Thanks for the new report and visibility I recall the discussions last time and Sals meaning there was reworked, not revoked (from text I cant share) - which has a slightly different context.

You should be able to just drop in the new DLL, none of the other content changed. In the bigger picture the alarms are in the sfs as LatoMacciato mentioned and settings.cfg is not in the download, so you should be able to just install the new one in your usual ways and not lose settings or alarms - do the usual make a backup and give it the beans I say

Can do

I "think" from memory you can just change the .version file in gamedata as well - it says 1.6, cause thats what I compiled against. The Unity version is the same and I didnt hook any "new" stuff intentionally so like Taniwha says it should be good (but I didnt test it meself). Give it a try and if theres issues yell out, I can probs do an extra build for 1.5 if theres an issue

Quick update from me. KAC is now up to date for 1.6. This one is next...

v3.10.0.0 Released Happy New Year everyone. this one has a few bits in it to get things up to date including a 1.6.0 recompile Recompiled for 1.6.0 (Issue #199, #199) Fix for hyperbolic orbits (Issue #210) - Thanks @taniwha Fix for version check issues (Issue #208) - Thanks @MWerle Removed some compiler warnings and deprecated calls Change the way UI Hiding works (Issue #206) Fix perf issue in TS (Issue #207) Add UI scaling to the app (Issue #204) Add MapUI lock in TS for click through - as much aas can do with current locks (Issue #192) Add prevention of jumping to unowned vessels in career (Issue #154) Change the datetime formatting stuff so its Kronometer compatible (Issue #202, Issue #194, Issue #157) - Thanks @Aelfhe1m Fix for vessel name locazlization Updated some of the common UI calls to reduce GC Churn Updated WarpRate checking to rewmove GC Churn Removed some Triger specific stuff from the build scripts (Issue #196) - Thanks @MWerle The date formatting changes can be reversed via the UseStockDateFormatters value in the KAC settings if you find issues with them in any ways. Download from GitHub or Download from Curse or Download from SpaceDock

That tiny "just saying" made me chuckle

Gonna bring this up to date and look at some stuffs this holidy is my plan, sorry for the lack of comms.

Another thing to check is if you have the reaction wheel disabled - that catches me with every rover I build till I remember to turn it off so the wheels are in control

from memory its default is 32

workin on that over the christmas break