Skip to content

Sadly, many fixes in one PR #3005, #2596, #3018, #2902, #2925#3043

Merged
Dunbaratu merged 8 commits intoKSP-KOS:developfrom
Dunbaratu:fixes_2925_logspam_slowness
Feb 13, 2022
Merged

Sadly, many fixes in one PR #3005, #2596, #3018, #2902, #2925#3043
Dunbaratu merged 8 commits intoKSP-KOS:developfrom
Dunbaratu:fixes_2925_logspam_slowness

Conversation

@Dunbaratu
Copy link
Member

@Dunbaratu Dunbaratu commented Feb 13, 2022

I got sloppy over the last few months about keeping each change in its own independent PR, so multiple commits ended up in this one PR instead of being separate PR's one each.

I will try to iterate them all below:

Fixes #3005 unsafe to use setsuffix on a locked identifier.

Fixes #2596 don't allow locking a built-in identifier like HEADING(). (But allow it with new compiler directive @CLOBBERBUILTINS)

Fixes #3018 Some compiler exceptions not showing the filename correctly.

Fixes #2902 Alt radar sometimes wrong.

Fixes #2925 A race condition made IsWaitingForCommand() spam the log with a few exceptions on scene changes when kOS starts running its Update()s before the "Physics Easing" has finished. In most cases the race condition would resolve itself a second or so after the scene loads so it wasn't a big priority given that I couldn't reproduce the race condition myself reliably. But I found out that in some people's cases the exceptions didn't just stop after a few seconds, so the lag from the logspam made the game un-usable for them. That was my primary motivation for getting this PR done. Thank you to user @arrowmaster for being my Guinea Pig to test my attempts to fix the bug. Since I couldn't reproduce it myself I couldn't test if I'd fixed it without outside help.

Fixes KSP-KOS#3005 - The discussion of the problem is long, see the issue KSP-KOS#3005.

There was logic in the compiler that handled this situation:

When in the context of compiling the lefthand side of a SET assignment,
if that lefthand side is a function name, it should suppress the "invoke
even when no parentheses are present" logic, like so:

```
  set x to { return 1. }. // x is now a delegate function.
  print x. // Should call x() the function, even with the () missing.
  set x to 3. // Should NOT call x() when replacing x with a 3.
```
The problem was that this same logic that tries to handle that was
partly firing off when the 'x' in question was followed by a suffix,
when that should not be happening in that case:
```
  set x to { return ship. }.
  set x:name to "hello". // Here x() DOES need to be called, to return
                         // SHIP, which then gets its suffix :name set.

```
It was partially skipping half the work of setting up for the function
call because it failed to realize one was coming.  The part it skipped
was the part that inserts the KOSArgMarker on the stack before the call
happens.
The eventual plan is to be able to toggle this feature off
in two ways - one is the CONFIG:CLOBBERBUILTINS setting for the
default, and the other is a compiler directive @CLOBBERBUILTINS
that can override the default on a per-file basis.  That compiler
directive isn't there yet in this PR, but you can test turning
the feature on and off via the CONFIG option.

What's needed for me to make the PR merge-ready:

[ ] Add @CLOBBERBUILTIN directive, which requires some
grammar file changes which is why I didn't tackle it yet.

[ ] Add user-facing documentation about this, which means
mentioning it in several place through the docs, and
mentioning how older scripts you find on the internet
might break because of it unless you change the setting,
etc, etc, etc.
When Compler.cs throws KOSCompileExceptions, it tends to
print the filename/line/col now.

However, KOSNumberParseException, which is also thrown
from the compiler, still doesn't show the info.  That's
because it's not derived from KOSCompileException, and
gets thrown by StringValue.ToNumber(), which also gets
called from contexts that aren't the compiler, so it
can't contain the file/line/col info.  Fixing that is
a bit more complex, but what this commit does is still an
improvement over what it was doing before, so it's still
worth checking in.
@Dunbaratu Dunbaratu added the bug Weird outcome is probably not what the mod programmer expected. label Feb 13, 2022
@Dunbaratu Dunbaratu merged commit 2c95ab2 into KSP-KOS:develop Feb 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Weird outcome is probably not what the mod programmer expected.

Projects

None yet

1 participant