* MISC: Refactor coding contracts for type safety
This refactor does three things without any behavior changes:
* Adds type safety by introducing generic type parameters to the coding
contract definitions, so they can use concrete types instead of
"unknown". This also eliminates a bunch of boilerplate casts.
* Removes the unneeded CodingContractType class. We can use the metadata
type directly.
* Introduces a new hidden state to coding contracts. Instead of
generating and storing the data (which is what is shown to the user as
the problem's input), the state is stored instead. This allows
problems to (for instance) generate the answer up-front, and check the
solution directly against the answer, instead of needing to embed a
solver in the problem (which can then easily be ripped from the source
code).
For compatibility, state == data by default. I plan to make use of this
feature in a followup, but it is unused currently.
findRunningScriptByPid needlessly took a "server" argument. This caused
there to be a "getRunningScriptByPid" version that did *not*, and it was
looping through all servers in order to function, which is needlessly
inefficient.
By removing the parameter and the needless inefficient helper method,
the following changes:
- Many Netscript functions such as isRunning() and getScript() become faster.
- The terminal "tail" command now works by pid regardless of the current
server. Note that "kill" already worked this way.
I also improved the docs around "tail", since the pid argument wasn't
in the help.
There are a bunch of React components that update at the same rate
that the game engine processes cycles. Rather than have each place
that does so start its own timer to update that often, add a new
react hook that triggers an update shortly after the engine completes
a cycle.
Our IndexDB handling did not have very good error handling. It wasn't
reporting the actual errors that occured, nor was it using actual Error
objects. In some cases it also had overly convoluted Promise use, and it
didn't need to be .tsx either.
The biggest issue was that if any problem occured during the main
load(), this would end up as an unhandled rejection and so it would only
be logged to the console. This extends the previous catch to also cover
this, so that the recovery screen is activated.
We are getting some more error reports coming in that don't have enough
info in them. It turns out that populating the stack trace was gated
behind the dev flag; in reality, production builds are where we need it
most. Even if it ends up being obfuscated (source maps should prevent
this), we can figure out the actual source lines with enough effort if
need be.
This also changes to using the actual stack trace, rather than the
"component" trace (the tree of JSX objects), since knowing where the
code failed is far more valuable. Also, it ensures we get the full error
details when things go wrong in savefile loading.
catloversg
Michael Ficocelli
G4mingJon4s
Nerdpie
gmcew
Yichi Zhang
David Walker
Tom Prince
robofinch