* added utility info
* moved info to running script
* fix for RAM cost
* description changes
Co-authored-by: David Walker <d0sboots@gmail.com>
* fixed wrong formatting
* Added parent to ignored fields
---------
Co-authored-by: David Walker <d0sboots@gmail.com>
* EDITOR: Tweak typescript language server configuration to match use.
- We allow importing files with `.ts`/`.tsx` extensions.
- We use an file-at-a-time transpiler, so we don't support features
that require understanding the full type system.
- We use the classic `React.createElement` transform.
* Fix the type declaration of `!!raw-loader!` modules.
Instead of declaring them to export an object with a single key
`default` which is a string, the modules have a default export, which
is a string.
Note, that this doesn't actually change the generated code, just the
types that typescript sees. The code worked before because the only
thing done to the values was to coerce the values to a string, which
turned into a no-op.
* Switch from using `raw-loader` to using a source asset module.
`raw-loader` was deprecated in webpack v5.
To use this, add a line like "ns.ramOverride(2);" as the first statement
in main(). Not only will it take effect at runtime, but it will now
*also* be parsed at compile time, changing the script's static RAM
limit. Since ns.ramOverride is a 0-cost function, the call to it on
startup then becomes a no-op.
This is an often-requested feature, and allows for scripts to set their
usage without it needing to be explicitly mentioned via args or options
when being launched. This also reduces pressure on the static RAM
analysis to be perfect all the time. (But certain limits, such as
"functions names must be unique across namespaces," remain.)
This also adds a tooltip to the RAM calculation, to make this slightly
discoverable.
This adds a way to dynamically change the static RAM limit of a script,
which is also its current RAM usage. This makes it possible for scripts
to dynamically change their memory footprint, opening up new strategies
beyond current ram-dodging.
Calling functions still permanently increases the *dynamic* memory
limit; RAM-dodging is still the optimal strategy for avoiding RAM costs,
in that sense.
This also adds dynamicRamUsage to the info returned by
`getRunningScript`, to allow introspection on the currently needed ram.
This eliminates a hole where spawn was unrelaible, because other scripts
could jump in and steal the RAM. It's not an API break, because 0 used
to be an invalid value.
*All* RAM calculations must take place in units of hundredths-of-a-GB in
order for there not to be issues.
Also adds slightly more verbose logging when the dynamic RAM check
fails.
Michael Ficocelli
catloversg
G4mingJon4s
nobody0
Fireball5939
Nicole
David Walker
Yichi Zhang
Tom Prince
Sphyxis
Albert Llop