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.
* IPVGO: Explicitly link the generated API documentation in the algorithm design doc
* IPVGO: Fix missing factions in netscript docs
* IPVGO: Linting
* IPVGO: Ensure resetBoardState() logs that a new game has started
New function returns post-install ascension ratios.
* Add ascension penalty to Gang constants
* Improve wording of Gang install message
* Add GangMember#getInstallResults()
* Update prestiging to use getInstallResults()
* Add ns.gang.getInstallResults(memberName)
* Update definitions
* Add ram cost for ns.gang.getInstallResult()
* Fix typo
* More specific wording in documentation
* Fix another typo
* Run prettier
* Rename getInstallResults to getPostInstallPoints
* Update Prestige.ts
* Update Gang.ts
A significant portion of players who use ports are passing objects through them. Currently they are required to handle that themselves via JSON serialization. This PR adds better support for passing objects; which is more convenient, extensive, and optimized (probably, more on this one later).
This adds zero overhead to existing (or when passing any primitive types) port usage, and also isn't a breaking change. The questions to debate here are:
Should objects be supported in the first place?
If so, how exactly do we want to serialize objects?
Based on an extensive discussion in Discord, the overwhelming majority answered "yes" to question one. As for question two, that has been much more hotly contested.
Ultimately, `structuredClone` was used, despite less-than-stellar performance, because other options were worse either in safety, speed, error-handling, or multiple of the above.
