Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syntax not supported: lock var to heading A by B #2

Closed
Dunbaratu opened this issue Mar 13, 2014 · 4 comments
Closed

Syntax not supported: lock var to heading A by B #2

Dunbaratu opened this issue Mar 13, 2014 · 4 comments
Labels
discussion Not necessarily a problem - Using a Github issue to have a public discussion

Comments

@Dunbaratu
Copy link
Member

This syntax worked in previous versions of kOS:

LOCK someVar TO HEADING expr1 By expr2.
LOCK STEERING to someVar.

The expression "heading expr1 by expr2" doesn't seem to be recognized as valid syntax in this new version. What it used to do was create a Euler rotation pointing at compass heading expr1 pitched up expr2 degrees above the horizon.

@marianoapp
Copy link
Contributor

The syntax "HEADING expr1 By expr2" was deprecated in favor of "HEADING (degreesFromNorth, pitchAboveHorizon)" for a while now, but the old syntax was still supported in the old version of kOS for retrocompatibility.
If you use the new syntax you shouldn't have any problems.

@erendrake
Copy link
Member

looks like there is no Heading mention in the Documentation http://ksp-kos.github.io/KOS_DOC/ lets get something in here so people can use the feature with the new syntax.

@Dunbaratu
Copy link
Member Author

Alright I'll change it to use the new syntax then.

@erendrake
Copy link
Member

Added docs

erendrake pushed a commit that referenced this issue Dec 23, 2014
erendrake pushed a commit that referenced this issue Jan 9, 2015
erendrake pushed a commit that referenced this issue Mar 7, 2015
Merge KSP-KOS/develop recent changes into ZiwKerman/KOS-develop
erendrake pushed a commit that referenced this issue Apr 15, 2015
Pulling changes from main repo
erendrake pushed a commit that referenced this issue Nov 13, 2015
Core inheritance from kOSProcessorFields
gisikw pushed a commit to gisikw/KOS that referenced this issue Feb 15, 2016
Update for animations and better power state
hvacengi pushed a commit that referenced this issue Nov 18, 2017
Dunbaratu pushed a commit that referenced this issue Apr 6, 2018
erendrake pushed a commit that referenced this issue Jul 27, 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 issue 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
discussion Not necessarily a problem - Using a Github issue to have a public discussion
Projects
None yet
Development

No branches or pull requests

3 participants