programming/projects/stitchkit

repo
2023-09-12
a heartwarmingly joyful to use modding toolkit for A Hat in Time
2023-09-12
philosophy
2023-09-12
- better than vanilla
  2023-09-12
  - the experience of using Stitchkit should always be more pleasant than the vanilla modding tools
    2023-09-12
    if it’s somehow worse, that’s a bug
    2023-09-12
- fix the problems, don’t fear breakage
  2023-09-12
  - applies to MuScript in particular - we are not afraid to make the language better, even if it breaks your code
    2023-09-12
- if it ain’t broke, don’t fix it
  2023-09-12
  - while fixing issues is important, we want the modding tools to remain familiar to existing vanilla users.
    2023-09-12
    for example the syntax of UnrealScript may be a bit dated, but it is perfectly readable without much reason to change it. no need to invent a new language.
    2023-09-12
- be helpful
  2023-09-12
  - people who come to mod AHiT are often not professional programmers to put up with shitty tools that have overly cryptic error messages and terrible user experience across the board.
    2023-09-12
  - we want to help people fuel their imagination instead of hindering it
    2023-09-12
- be lazy
  2023-09-20
  - don’t do work nobody asks for
    2023-09-20
    compiling things the user doesn’t care about is a pointless waste of computer resources
    2023-09-20
    implementing things that don’t matter for Hat modding is a pointless waste of time
    2023-09-20
insanium
2023-09-12
- section for absolutely insane ideas that will never work but fill my inner hackerman with joy
  2023-09-12
  - organized from least insane to most insane
    2023-09-12
- also see MuScript’s insanium
  2023-09-12
- hot reloading scripts in the editor
  2023-09-12
  - in theory if we control the editor process, we should be able to search the address space for various anchor points
    2023-09-12
    scripts can be up to 65536 bytes long - this might not seem like much, but bytecode is much more compact than text!
    2023-09-12
    from my analyses when building Yarnbox, most chunks of bytecode don’t exceed 4096 bytes
    2023-09-12
    the engine loads your bytecode mostly verbatim, so we could include a recognizable signature at the end of every script
    2023-09-12
    I imagine we could use a short string of bytes that’s unlikely to collide with anything yet fast to search for. probably 16 bytes (128 bits) would be enough but we can experiment with less
    2023-09-12
    I say it loads your code mostly verbatim because it actually parses the bytecode to translate archive object indices to
    2023-09-12
    since we can’t reallocate memory, we’ll have to always preallocate all 65536 bytes - but 64 KiB isn’t that much in the first place,
    2023-09-12
    well not until you realize how many functions there are in the engine (I haven’t counted.) but you can’t modify those so no need to support this functionality there
    2023-09-12
    and the typical mod doesn’t have that many functions (what, 200 maybe? that would be ~12.5 MiB of memory, which ain’t much)
    2023-09-12
  - with the bytecode of the script found in memory, we can modify it arbitrarily however we want
    2023-09-12
    except it’s not that simple because scripts contain object references, and we have no way to resolve those to addresses
    2023-09-12
    we could use DynamicLoadObject though, as cursed as that is
    2023-09-12
  - the downside of this is that we could only modify the bytecode of functions.
    2023-09-12
    I imagine there could be some hacks we could do to trigger running arbitrary code inside the context of the editor, but I haven’t thought those through yet fully
    2023-09-12

© riki moe / リキ萌

    \    /
   | \__/ |
 \ /      \ /   ___
--|  _  _  |-- =_  \
 / `------` \    \  \
     |   \        |  |
     |    \      _/  |
    /      |    /  _/
   |        \  / _/
   |         |__/
   \-,,-,,--/