With the struct defined as it is currently, my memory dumping script (which matches the C header exactly) prints output that looks like the following, for example:

"TActor_0": {
  "name": "Krystal",
  "address": "0x806ED020",
  "fields": {
    "rotation": [-25166, 0, 0],
    "unk0x6": 2,
    "scale": 0.0494999997317791,
    "position": [2108.28564453125, -41.19002151489258, 16808.6328125],
    "positionMirror": [2108.28564453125, -41.19002151489258, 16808.6328125],
    "speed": [0, 0, 0],
    "ptr0x30": "0x00000000",
    "unk0x34": 65535,
    "linkedActor": "0x800EC398",
    "unk0x3c": [68, 255, 0],
    "unk0x44": 68,
    "unk0x46": 18432,
    "ptr0x48": "0x00000100",
    "unk0x4c": 520094208,
    "ptr0x50": "0x00000000",
    "ptr0x54": "0x00803981",
    "unk0x58": 3900731102,
    "ptr0x5c": "0x7C000000",
    "ptr0x60": "0x00806286",
    "ptr0x64": "0x08806ED9",
    "ptr0x68": "0xD8806EDE",
    "ptr0x6c": "0x38802529",
    "ptr0x70": "0xD0806EDF",
    "unk0x74": 545287903,
    "positionMirror2": [-2199023255552, 0, 1.1794696944357306e-38],
    "positionMirror3": [2.3158967801400164e-36, -1.2252182749418445e-27, -4.008937194294739e-26],

however, since positionMirror2 and positionMirror3 are actually always the same as position and positionMirror when the game is running, clearly that's not correct output. Looking into it in the debugger, I realized that the actual amount of space between linkedActor and positionMirror2 in practice is 68 bytes (or 44 if using hex format values, as shown in the image I've attached) whereas the C header definition currently only adds up to 55 bytes across the following section:

u8 unk0x3c[3];
UNK_TYPE_16 unk0x44;
UNK_TYPE_16 unk0x46;
void* ptr0x48;
UNK_TYPE_32 unk0x4c;
void* ptr0x50;
void* ptr0x54;
UNK_TYPE_32 unk0x58;
void* ptr0x5c;
void* ptr0x60;
void* ptr0x64;
void* ptr0x68;
void* ptr0x6c;
void* ptr0x70;
UNK_TYPE_32 unk0x74;

After adjusting my script to reflect what I was actually seeing in memory, it then produced output that looks like this, which has the correct values for positionMirror2 and positionMirror3, as well as what look to me like more meaningful values for the surrounding fields:

"TActor_0": {
  "name": "Krystal",
  "address": "0x806ED020",
  "fields": {
    "rotation": [-25166, 0, 0],
    "unk0x6": 2,
    "scale": 0.0494999997317791,
    "position": [2108.28564453125, -41.19002151489258, 16808.6328125],
    "positionMirror": [2108.28564453125, -41.19002151489258, 16808.6328125],
    "speed": [0, 0, 0],
    "ptr0x30": "0x00000000",
    "unk0x34": 65535,
    "linkedActor": "0x800EC398",
    "unk0x3c": 17663,
    "unk0x3e": 0,
    "unk0x40": 17480,
    "unk0x42": 0,
    "unk0x44": 65567,
    "unk0x48": 131072,
    "ptr0x4c": "0x00000000",
    "ptr0x50": "0x803981E8",
    "ptr0x54": "0x806EDE7C",
    "ptr0x58": "0x00000000",
    "ptr0x5c": "0x80628608",
    "ptr0x60": "0x806ED9D8",
    "ptr0x64": "0x806EDE38",
    "ptr0x68": "0x802529D0",
    "ptr0x6c": "0x806EDF20",
    "ptr0x70": "0x806EDFD4",
    "ptr0x74": "0x00000000",
    "ptr0x78": "0x00000000",
    "ptr0x7c": "0x806ED104",
    "positionMirror2": [2108.28564453125, -41.19002151489258, 16808.6328125],
    "positionMirror3": [2108.28564453125, -41.19002151489258, 16808.6328125],

If you want, I can make a PR that updates the C header definition with the same adjustments I did for my script. Figured I'd open an issue for it first though as there was a fair amount of background info that needed explaining.

Split out a bottom chunk of segment_D280.c that looks like all input related functions.

Also includes some minor updates to main.c related to input function usage.

This was figured out by the examining the output of the dump-actor-lists-to-JSON script I posted on the coding-reverse-engineering Discord channel yesterday (I'm ssds there, to be clear).

Specifically, for example, if you look at this partial snippet from an entry for Krystal:

"TActor_0": {
  "name": "Krystal",
  "address": "0x805F8018",
  "fields": {
    "rotation": [-31233, 0, 0],
    "unk0x6": 2,
    "scale": 0.0494999997317791,
    "position": [971.0263671875, 431.73724365234375, 17771.861328125],
    "positionMirror": [971.0263671875, 431.73724365234375, 17771.861328125],
    "speed": [0, 0, 0],
    "ptr0x30": "0x00000000",
    "unk0x34": 65535,
    "ptr0x38": "0x80101C18",

The ptr0x38 field for her there is the address of another TActor object for which the relevant snippet looks like this:

"TActor_2": {
  "name": "TriggerArea",
  "address": "0x80101C18",
  "fields": {
    "rotation": [21760, 0, 0],
    "unk0x6": 2,
    "scale": 1,
    "position": [1151.096435546875, 367.7933044433594, 17801.52734375],
    "positionMirror": [1151.096435546875, 367.7933044433594, 17801.52734375],
    "speed": [0, 0, 0],
    "ptr0x30": "0x00000000",
    "unk0x34": 65280,
    "ptr0x38": "0x800F9950",

which in turn has a ptr0x38 field set to the address of a third TActor object for which the relevant snippet looks like this:

"TActor_3": {
  "name": "TriggerPlane",
  "address": "0x800F9950",
  "fields": {
    "rotation": [-8192, 0, 0],
    "unk0x6": 2,
    "scale": 1.875,
    "position": [1129.2900390625, 348.3329162597656, 17473.705078125],
    "positionMirror": [1129.2900390625, 348.3329162597656, 17473.705078125],
    "speed": [0, 0, 0],
    "ptr0x30": "0x00000000",
    "unk0x34": 65280,
    "ptr0x38": "0x00000000",

So in that case, it goes Krystal -> TriggerArea -> TriggerPlane, with TriggerPlane being "the end of the road" so to speak as it does not have a meaningfully initialized ptr0x38 field.

• Updated progress.py to account for DLL functions and to provide an option for outputting the current progress as a JSON file
• Sped up DLL function analysis by ~30%
• Fix Dockerfile build failing when setting the UID to an existing user (e.g. root)
• Add progress shield to README

Switching to Ninja sort of broke support for decomp-permuter, this PR makes adjustments to the build system to support permuter and patches permuter to work with DLL code.

• Added permuter_settings.toml
• Replaced GCC during build with custom header_deps.py script (also lets Ninja see .asmproc.d dependencies)
• Added decomp-permuter as a Git submodule (a forked version that works with DLL assembly)
• Added dino.py shortcuts for permuter
• dll.py now emits R_MIPS_CALL16 relocations as needed

This PR introduces support for building partially decomp'd DLLs.

• GLOBAL_ASM support for DLL C files.
• Ability to link the original .data, .rodata, and .bss sections of a DLL.
• Ability to specify symbols per DLL.
• Ability to write custom linker scripts per DLL.
• dino.py extract will now 'split' DLL code similarly to splat.
• New dino.py setup-dll <dll> command to init an environment for decomp'ing a DLL.
• New tools for inspecting DLL-related binaries:
  • tools/dlldump.py
  • tools/dlltab.py
  • tools/dllimports.py
• Fork of asm_processor with asm .reloc directive support.
• Updated version of elf2dll with minor bug fixes.
• A few newly decomp'd DLLs:
  • 82
  • 83
  • 223 (CannonClaw)

• Prevent Dockerfile usage creating files as root
• Small config clean up
• dino.py now generates expected/, which contains matching object files for each source. Needed by diff.py to diff by object file.
• Add --use-cache flag for ./dino.py extract
• Fix ./dino.py diff not passing arguments to diff.py correctly
• ./dino.py extract now automatically re-configures the build script

This isn't everything, but it's a bunch that easily matched from libreultra. I noted any changes that I had to make to get it to match. I also tried following the file names and folder structure of libreultra for consistency.

Some other notable changes:

• The makefile now supports building files with -O1 and -O2 -g0 depending on the name of the parent folder (O1 and g0 respectively).
• Renamed _bcopy to bcopy.
• Renamed _sqrtf to sqrtf.
• Renamed _bcmp to bcmp.
• Renamed matrix_perspective to guPerspectiveF (as far as I can tell, it's what that is, but I wasn't able to get it to fully match from the libreultra version).

• Matches remaining functions in crash.c
• Fixes OSThread and OSSched definitions (there was 128 unknown bytes defined in OSSched that were actually part of the OSThread field before it)
• Matched find_executing_dll (aka func_8000BD1C, which is called by a crash function)

I noticed progress.py didn't have the proper dependencies listed in requirements.txt. I added them so that they are installed during first-time setup.

This adds a CONTRIBUTING.md file explaining how the decomp works, what to know beforehand, and how to contribute. Also includes a list of resources like the MIPS and N64 manuals.

My goal here is to make it easier for new people (especially those who have never done a decomp before) to come onboard and get started.

Leaving this as a draft for now because I think there's probably better ways to word some of this and hopefully others have some suggestions 😄.

Edit: I think this is in pretty good shape for a first iteration, can always change this later!