Skip to content

Fixes 1116 feedback#2

Closed
erendrake wants to merge 89 commits intoDunbaratu:fixes_1116_Reference_Directionfrom
erendrake:fixes_1116_feedback
Closed

Fixes 1116 feedback#2
erendrake wants to merge 89 commits intoDunbaratu:fixes_1116_Reference_Directionfrom
erendrake:fixes_1116_feedback

Conversation

@erendrake
Copy link

It looks like this PR also brings in a bunch of fast forward on the develop branch

hvacengi and others added 30 commits August 2, 2015 19:33
SteeringManager.cs
* Moved steering code into a new class in the binding namespace.
* Class is an instance variable, and allows keeping track of history and
orientation individually instead of statically.
* New  implementation is based on angular velocity, and adjusts maximum
angular velocity based on available torque to minimize overshoot.
FlightControlManager.cs
* Steering FlightControlParameter now uses the SteeringManager class.
* Eventually, would like to break SteeringManager into it's own
parameter.
kOS.csproj
* Add reference for SteeringManager.cs
FlightControlManager.cs
* Hide vector renderers if steering is disabled
SteeringManager.cs
* Implement hiding of vector renderers.
* Update dtRoll1 to be more responsive.
* Roll is now controlled by a calculated maximum value rather than hard
coded value.
FlightControlManager.cs
* Call the SteeringManager's Update method on UpdateFlightControl.
SteeringManager.cs
* Add PI controls for angular velocity (rate) and torque
* Add csv logging for the PI controls
* Add new UpdatePredictionPI method for calculating based on the new
controls.  This allows the existing logic to remain for quick fallback
testing.
* Begin the work to calculate torque based on engine gimbal and rcs
thrust (using the new ThrustVector class)
SteeringManager.cs
* Updated vector renderers for engine thrust and gimbaled thrust.
* Fixed calculation for gimbaled engine torque and use it in calculating
the available torque.
* Added some PI output clamping in UpdatePredictionPI
* Update PI logic to properly mitigate integral windup.
* ErrorSum is now reset every time enabled is set to true (any time
`lock steering to ...` is called, even if already locked).
SteeringManager.cs
* Add a minimum available torque to prevent division by zero and sending
NaN into the ksp api, which causes lots of issues.  This was most
evident in realism overhaul, where the user may easily have zero
reaction wheel torque, or in stock with probe cores that don't include
wheels.
Revert changes to VectorRenderer.cs and SteeringHelper.cs accidentally
made in commit 58df5e9
SteeringManager.cs
* Added the RCS torque logic from the SteeringHelper into
SteeringManager class to re-enable RCS based calcs.  Only works for
symmetric placement, may need some tweaking for proper operation.
PIDLoop.cs
* Create new class to expos a kOS structure capable of iterating through
basic PID control schemes.
Misc.cs
* Provide constructor method for new PIDLoop structure.
kOS.csproj
* Include new PIDLoop.cs file.
FlightControlManager.cs
* Implement the new stat control methods from SteeringManager.
SteeringManager.cs
* Implement IDisposable on SteeringManagaer class.  Clear out file
access handles and vector renderers on dispose.
* Implement Structure class, including suffixes to control vector
visibility, debug printing, and direct interaction with the PID loops.
* Implement individual csv file writers for each PID using KSP.IO
classes.  Files are now stored at /Game_Data/kOS/Plugins/PluginData/kOS.
* Use new force vector struct for calculating RCS torque.  Still need to
adapt thrust torque to do the same.
* Adjust the moment of inertia by a factor of 10 if the value is below
4.5.  This is based on experimentation to determine the point where low
MoI is effected less by torque.
* Add new MovingAverage class and use it to filter the current angular
velocity, averaging the value over the last 30 samples.
* Completely rework the drawing of vector renderers so that it supports
toggling by 4 modes.
* Comment out old PI classes to be removed in the next commit for
historical purposes.
SteeringManager.cs
* CodeMaid cleanup
* Remove old commented lines no longer in uses.
BindingsUniverse.cs
* Add public getter for `STEERINGMANAGER` to access the steering manager
for the current vessel stored in the SharedObjects object.
SteeringManager.cs
* Add suffixes to get the overall errror, along with pitch, yaw, and
roll.
SteeringManager.cs
* Add torque adjustment to allow adding an arbitrary torque, for when
kOS does not correctly calculate torque
* Add torque factor to scale the calculated available torque.
* Add constant value for converting between degrees and radians.
SteeringManager.cs
* Update methods to allow swapping steering manager.  This method will
replace the steering manager depending on how a vessel staged.  It will
copy the setting values from one instance to the other.
* Add a debugging output for the average time it takes to update the
steering code.  Mostly there to benchmark as we do the switch, and to
find potential optimizations.
* Vector renderers are not initialized in the UpdateVectorRenderers
method to help streamline and guard against early disposal.
* Removed the HideVectorRenderers method as well and moved function into
UpdateVectorRenderers
FlightControlManager.cs
* Use the new SteeringManager swapping/removing methods.
BindingsUniverse.cs
* Shift to get the instance of STEERINGMANAGER based on shared instead
of shared.Vessel
FlightControlManager.cs
* Switch the call to SteeringManager.RemoveInstance so that it is inside
the Dispose method instead of UnBind (breaking execution causes an
unbind, so ending a script or aborting a script caused a null
reference).
SteeringManager.cs
* Implement a new DeepCopy static method which copies settings and PID
information into a new instance variable.  Mostly for use when a vessel
un-docks and a new SteeringManager needs to be created.
* Fix an error where I was removing elements from a list while
enumerating the list, which throws an exception.
SteeringManager.cs
* Add new suffix MAXSTOPPINGTIME and associated C# member.  This value
is now used when calculating the maximum angular velocity, allowing
users to override the default behavior.
* Use the ForceVector struct within the ThrustVector class to streamline
the calculation of torque.  Also give quick access to the component
forces and torques of the different control directions.
Added suffixes for basic string manipulation. As described in KSP-KOS#270, I
added a subclass of Structure to wrap C# strings which defines suffixes
for most of the basic string operations in C#. I stuck with the C#
function names in general. The wrapper class also adds indexing for
individual characters. Strings are still immutable.

The actual wrapping of the string is only done when suffixes are
actually resolved; it doesn't keep the wrapped strings around
permanently. I decided to do the wrapping here because it required the
simplest change and wouldn't break anything. Certainly may be a better
place for it, or maybe there is some advantage to having the wrapped
versions hang around on the stack.

The following operations were added:
[Character Indexing]
CONTAINS
ENDSWITH
FIND/INDEXOF
FINDAT
FINDLAST/LASTINDEXOF
FINDLASTAT
INSERT
LENGTH
PADLEFT
PADRIGHT
REMOVE
REPLACE
SPLIT (Returning a KOS List)
STARTSWITH
SUBSTRING
TOLOWER
TOUPPER
TRIM
TRIMEND
TRIMSTART
Tests all the string manipulation suffixes.
SteeringManager.cs
* For some reason git stored the call to clear vEngines and vRcs on the
wrong lines in commit 43bd2e2, so this
corrects that issue.
pidloop.rst
* Document the PIDLoop structure for kOS.
steeringmanager.rst
* Document the SteeringManager structure for kOS.
DockingPortValue.cs
* fix the spelling of the suffixes for acquire range, force, and torque.
* throw deprecation exception directing the user to use the correct
spelling if they use the old version.
DockingPortValue.cs
* add a suffix `NODEPOSITION` which returns the position of the actual
docking node itself, rather than the part's position
* add a suffix `NODETYPE` to allow you to differentiate between
different types of docking ports, in stock this is how you can tell the
"size" of the docking port.
PartValue.cs
* expose the shared objects as a protected variable so that classes that
inherit (like DockingPortValue) don't need to keep their own handle.
* add new suffix `HASMODULE` which can be used to determine if a part
has a specific module.
PIDLoop.cs
* Add new MINOUTPUT suffix, allowing the minimum value to be controlled
separate from the maximum value.
* Revise the constructor to allow for the MinValue variant
* Update windup logic to match
* Removed the user facing suffix of EXTRAUNWIND
erendrake and others added 23 commits October 18, 2015 00:21
SteeringManager.cs
* Because RemoveInstance is not kept in SteeringManagerProvider, deleted
it from the SteeringManager class itself.
SteeringManagerProvider.cs
* Restructure RemoveInstance to prevent continual circular references.
* Move SwapInstance to the Provider class.
SteeringManager.cs
* Move SwapInstance into the Provider class.
FlightControlManager.cs
* Update reference to SteeringManagerProvider
kOSProcessor.cs
* Add a call to UpdateVessel from FixedUpdate to prevent a rare bug
where the vessel changes after the UI tick but before the physics tick.
DockingPortValue.cs
* Update version to 0.18.0
PartValue.cs
* Remove old debug logging.
DockingPortValue.cs
* Remove another extra debug log.
…g' into issue-1099-review

Strange merge conflict on pure whitespace line that made no sense
why it conflicted.  Had to manually change it.

Conflicts:
	src/kOS/Suffixed/Part/PartValue.cs
…snt_break

Opcodes can now abort execution
…spelling

Issue 1099 dockingport spelling
…8-loaddistance' into issue-1079-1128-loaddistance
VesselTarget.cs
* Add a new suffix "UNPACKED".  I went with unpacked instead of packed
(which is the KSP stored value) because it keeps the same implied
meaning of the boolean as with LOADED.  So the return value is true if
the vessel is unpacked, paralleling the true value if loaded.
In addition to the below, my text editor deleted trailing spaces on
lines, and I did not undo it.

kuniverse.rst
* a couple of changes to be consistent in line breaks within paragraphs.
* change the DEFAULTLOADDISTANCE detailed paragraph to remove the
reference to the vessel being loaded, and instead clarify that changes
won't effect vessels that already exist in the scene.
* Change example to reference CANREVERTTOEDITOR
loaddistance.rst
* Combine paragraphs discussing the common understanding of "on rails"
and add the comparison to timewarp.
* Removed unnecessary wait commands from the examples.
Dunbaratu pushed a commit that referenced this pull request Nov 14, 2015
Core inheritance from kOSProcessorFields
@Dunbaratu Dunbaratu closed this Dec 27, 2015
Dunbaratu pushed a commit that referenced this pull request Feb 19, 2016
Update for animations and better power state
Dunbaratu pushed a commit that referenced this pull request Nov 22, 2017
Dunbaratu pushed a commit that referenced this pull request Apr 6, 2018
Dunbaratu added a commit that referenced this pull request Jul 1, 2018
Change #1:

AddTrigger opcode will now treat steering
lock triggers as the same if they come from the same
point in the program, like they're supposed to (and
like they used to do).

My pilot.ks program was bogging down very very
slowly, to about 3 FPS with the new interrupt
priority code.  I found the cause:

When a program did ``lock throttle`` in a loop,
like so:

```
until false {
  lock throttle to 1.
  wait 0.
}
```

Then each time the "lock throttle" statement was visited,
it would insert a NEW trigger for it because it failed to
recognize that the previous one was already pending in the
trigger list.  (The Equals() test was calling it a new
trigger, because it was getting a new instance ID in the
OpcodeTrigger.Execute() logic.  Because it wasn't "Equal"
to the existing one, the uniqueness test for inserting a
trigger failed to deny the insertion.)

Therefore after the program runs a while instead of having
like 1 throttle trigger there were hundreds of them, clogging
the execution, and making the trigger logic itself rather slow
(doing sequential walks through the trigger lists between each
opcode with hundreds of triggers in the list instead of typically
about 10-ish like there should be in a typical program).

Change #2:

The new logic on how triggers move from the active list to the
callstack means they no longer execute in reverse order because
they don't all get stacked up at once (instead they move over one
at a time, waiting for the prev one to finish, unless a higher
priority one is there that is supposed to stack on top).  What this
means is that when moving from the trigger list to the stack, it
shouldn't be doing so in reverse order like it used to.
Dunbaratu pushed a commit that referenced this pull request Jan 12, 2020
Merge base repository in
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants