Introduces the basis for a language system to allow the UI to be translated to any language and/or have the text changed by mods.
A lot of things would require more work but, for a proof of concept, this PR makes all randomizer trick names & descriptions translatable (currently not re-loadable at runtime as that would require deeper changes and this is already merge conflict hell every time a trick is touched).
The system works by passing it a "translation path" which is resolved in the .json including object indentation. If the resulting json object is a list of strings, instead of a string, they get concatenated (purely for organization/QoL).
With the new imgui OTR generation flow, macOS would crash when Ship
was run for the first time unless com.shipofharkinian.soh had already been created.
Move the call to CheckAndCreateModFolder() earlier in execution to prevent crashing.
Looking into fixing warnings about commands already being bound,
LUS initializes a console window which we ignore,
but it registers global command handlers,
SohConsoleWindow does this again, but that's also where mInputBuffer/mFilterBuffer get set
Proper fix would be removing SohConsoleWindow, but it exists to have mono font
Before I had the change back to the placeholder actor id the Dummy
Player actors were spawned with, but since we grabbed the actorDB
entry before Actor_Destroy was called it didn't matter. Move it
and the requisite log statement to after Actor_Destroy.
Adds an enhancement that changes targeting behavior, allowing
Switching targets with the chosen button combo
(In Switch mode) Untargeting by just pressing Z
The sampleDataStartPad and aligned variables existed solely to satisfy
the N64 RSP DMA requirement that source addresses be 16-byte aligned.
On PC, aLoadBuffer is a plain memcpy with no such constraint.
The alignment dance caused aLoadBuffer to read up to 15 bytes before
sampleData and up to 8+ bytes past the end of the sample buffer. On
platforms with strict allocator guard pages (e.g. OpenBSD), this
triggers a SIGSEGV.
A second issue remains after removing the alignment dance: nFramesToDecode
is derived from sample counts (loopEnd), but size is not always a multiple
of frameSize. loopEnd and size are derived independently during encoding
and can disagree on the final partial frame, leaving nFramesToDecode *
frameSize exceeding the remaining bytes in the buffer.
Remove sampleDataStartPad and aligned entirely. Clamp the load to
min(nFramesToDecode * frameSize, audioFontSample->size - sampleDataOffset).
The ADPCM decoder operates on DMEM, so a partial last frame in DMEM
produces at most a negligible artifact at sound termination.
