Project

General

Profile

Bug #23003

(BaseServo PartModules) KSPFields showing current servo position aren't usable by mods

Added by Dunbaratu 4 months ago. Updated 3 months ago.

Status:
Confirmed
Priority:
Low
Assignee:
-
Category:
Plugins/Add-Ons
Target version:
-
Start date:
06/25/2019
% Done:

10%

Version:
Platform:
Windows
Expansion:
Breaking Ground
Language:
English (US)
Votes:
Arrow u r green
Arrow d r red

Description

(This is affecting the kOS mod, but perhaps other similar mods like kRPC and Mechjeb might want this changed too.)

(I am making this issue at the advice of SQUAD staff member TriggerAU with whom
I've exchanged a few posts about this on the KSP forums.
)

There exist some informational fields on the PAW panels for the new BaseServo PartModules that come with Breaking Ground DLC which are not being updated if the PAW is closed. This makes it hard for a mod like kOS to obtain the information it needs to "see" where these servo parts are currently set.

Currently, these fields are string values (which is its own kind of problem for kOS as it means a script needs to spend time parsing the string back into its numeric value to make use of it), but more importantly is that to save CPU time, KSP does not update these values if the PAW is closed, which means a kOS script can't read them properly as they get "frozen" at whatever value they previously showed the last time the PAW was open. (or empty string if the PAW was never opened yet since the last scene load).

I have built the following list of all such fields I could find from experimentation:

I give the names as they appear in the GUI PAW panel, which may or may not be the names they have under the hood in the actual KSPFields:

For ModuleRoboticServoPiston, these field names:
------------------------------------------------

  • "Current Extension" - when setting KSPfield "Target Extension", the piston does move, but the value reported by "Current Extension" doesn't change until the PAW is opened.
  • "power" - when setting KSPField "Target Extension", the piston does move, which does draw power, but the value to "power" doesn't say so unless the PAW is open while the piston is moving. This field is also unusual in that it combines two different pieces of information together into the string - the current power draw and the max hypothetical power draw are both in the one string value.

For ModuleRoboticServoHinge, these field names:
-----------------------------------------------

  • "Current Angle" - (same as above for ModuleRoboticServoPiston's "Current Extension".)
  • "power" - (Same as above for ModuleRoboticServoPiston.)

For ModuleRoboticRotationServo, these field names:
--------------------------------------------------

  • "Current Angle" - (same as above for ModuleRoboticServoPiston's "Current Extension".)
  • "power" - (Same as above for ModuleRoboticServoPiston.)

For ModuleRoboticServoRotor, these field names:
-----------------------------------------------

  • "Current RPM" - (same as above for ModuleRoboticServoPiston's "Current Extension".)
  • "power" - (Same as above for ModuleRoboticServoPiston.)

History

#1 Updated by TriggerAu 4 months ago

  • Status changed from New to Confirmed
  • % Done changed from 0 to 10

#3 Updated by Dunbaratu 4 months ago

I occurs to me I should have called this "Feedback" rather than "Bug". "Bug" sounds a bit harsh because from the point of view of stock-only gameplay, everything is fine. This only causes a problem for mods trying to make use of these fields.

But I don't know how Squad's internal tracking system works so I don't know if changing it to "feedback" now will confuse things, so I will leave it as-is for now.

#4 Updated by TriggerAu 4 months ago

Well have a fix for the currentExtension/angle etc soon, but the "power" one may need some other stuff to settle first

#5 Updated by Dunbaratu 3 months ago

TriggerAu wrote:

Well have a fix for the currentExtension/angle etc soon, but the "power" one may need some other stuff to settle first

I don't know if it was intended to fix it yet or not, but the latest KSP 1.7.3 didn't fix this. It did change things like "current angle" from a string to a single-precision float, but that floating point number still never updates if the hinge moves while the PAW is closed. (i.e. if the hinge moves because a kOS script wrote a new value to "target angle" rather than because a user clicked on "target angle" in the PAW, then the KSPField "current angle" still remains unchanged, even though the hinge did indeed move just fine. I just can't have a script query its current position because its current position field is wrong until the PAW is opened by a user.

If there was some way for kOS to just tell KSP "I changed a value, so the PAW is dirty and needs updating", that would be fine. Anything to get KSP to know it needs to update those fields even though the user didn't have the GUI up.

Also available in: Atom PDF