SQUAD staff
  • Content Count

  • Joined

  • Last visited

Community Reputation

3,407 Excellent

About TriggerAu

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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; }
  4. 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?
  5. 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
  6. 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
  7. This bit in the article has some bits about base game updates
  8. I have a new plan... <humor>I'm soo misunderstood</humor> Nailed it!
  9. 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
  10. 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
  11. 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.
  12. 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.
  13. 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