Investigate any memory leaks. For example, file pointers are not freed, such as TestDirector::m_file.

My guess is that the node search is returning a nullptr for whatever reason.

MapdataFileAccessor::findSection parses an offset into the KMP file as a const MapSectionHeader *, and never actually converts endianness. Then, MapdataAccessorBase::init reads the count in the wrong endianness, causing 256 KartPoint allocations instead of 1.

The TAS community has decided to add arbitrary restrictions to what is considered a valid RKG. Thus, we now need to determine and implement logic to account for them.

If the accelerate and brake flags are not set, the drift flag must not be either. This is to match the hardware controller behavior (of which two have been confirmed and two are speculated).

To avoid Kinoko becoming a subset of the physics engine, run validity will be optional in this context will become optional.

EGG::Archive is wrapped in System::DvdArchive, which is a critical part of System::ResourceManager.

In the base game, RaceConfig can be initialized with boot/menuset.prm. The file does not exist on the game disk, but RaceConfig can theoretically support it.

This is a low-priority item since the command line should not be too hard to navigate, but support should be added for something like this when we support multiple controllers.

We can remove source/egg/Decomp.cc in exchange for adding source/abstract/Yaz0.cc.

Mirrored in https://github.com/stblr/mkw-sp/issues/205.

All executable-level data should exist in the Kinoko folder in the out directory. ResourceManager currently requires Kinoko/Course/<course_name>.szs and Kinoko/Common.szs.

Important

Do NOT include actual archives under any circumstances. Users will have to provide those themselves. A PR solving this should aim to clearly and accurately explain what needs to go where in both README.md in the source root directory and any README files we have in these folders.

User Input

• Send CSVs and ask for metadata
• Send RKGs
• Slash commands

Bot Output

• Receive frame sync information (e.g. 327/1438)
• Receive desync location (e.g. KartPhysics: vel0)
• Receive link to download run frame data

Currently, we're "initializing controllers" and sending pointless arguments into HostSystem. Following a closer hierarchy to the base game will allow us to scale far easier than whatever shenanigans we're doing here.

Split it up into subsystems for scene and memory management, and let RaceConfig do its intended job.

It would be nice to have sample ghosts included with the final executable.

Let's specify code standards and describe the workflow required to contribute.

We should include the following:

class CollisionDirector {
public:
    // Structs
    struct CollisionEntry {
        KCLTypeMask typeMask;
        u16 attribute;
        f32 dist;
    };

    // Lifecycle (N/A)
    // Operators (N/A)
    // Methods
    bool checkSphereFullPush(f32 radius, const EGG::Vector3f &v0, const EGG::Vector3f &v1, KCLTypeMask flags, CourseColMgr::CollisionInfo *pInfo, KCLTypeMask *pFlagsOut, u32 /*param_8*/);

    // Members (N/A)
    // Static Methods
    static void ResetCollisionEntries(KCLTypeMask *ptr);
    static void PushCollisionEntry(f32 dist, KCLTypeMask *typeMask, KCLTypeMask kclTypeBit, u16 attribute);

    // Static Members (N/A)
    // Singleton
    static CollisionDirector *CreateInstance();
    static CollisionDirector *Instance();
    static void DestroyInstance();

private:
    // Structs (N/A)
    // Lifecycle
    CollisionDirector();
    ~CollisionDirector();

    // Operators (N/A)
    // Methods (N/A)
    // Members (N/A)
    // Static Methods (N/A)
    // Static Members
    static std::array<CollisionEntry, COLLISION_ARR_LENGTH> s_entries;
    static size_t s_collisionEntryCount;
    static CollisionEntry *s_closestCollisionEntry;

    // Singleton
    static CollisionDirector *s_instance;
};```

EGG::Heap is critical for memory management in Mario Kart Wii. A similar memory management in the repository would be good to have.

We often skip over implicit padding manually, which is annoying to track.

Discussed a little bit on Discord here: https://discord.com/channels/214574342137315328/1047962335286919260/1237788120297111777

Essentially the idea being is that you'd be able to link via some API to Kinoko then step through the game and get parts of the game state.

For example a naive frontend implementation (again not hung up on specifics or even a lot of the generalities but this is a extremely rough sketch of my idea for thinking about it for 3 seconds) would be something like

Kinoko* k = /* ... */
do {
  k->doFrameStep();
  graphics.updatePos(k->/* ... */);
  waitABit();
} while (!k.raceIsFinished());

Related somewhat to #63.

We want to always support older KRKG versions. If we decide to start verifying sync with extra data points, we should still be able to run older KRKGs with fewer data points through Kinoko.

Our immediate idea is to do the following:

• For every new datapoint to be captured in sync verification, add a new member to TestData struct
• In TestDirector::findNextEntry(), use a switch against m_versionMinor to determine which fields to initialize
• In TestDirector::test, use a switch against m_versionMinor to determine which if-statements to execute

The point of the tests are to avoid regressions. As such, we will need to consider this when we synchronize the first test case. This will likely require a full rewrite for the test director, and perhaps the base system class as a whole.

To accomplish this, we must ensure the race scene is in a good state to destroy and recreate. One way to ensure this is to amplify memory leaks by repeating this process thousands of times.

Due to this application's reliance on external input, whether that be in the form of supplied ghost files or command line arguments, security is an important concern.

This is an ongoing tracking issue - any security concerns should be mentioned in the comments so I can add them here.

• Replace EGG::Decomp::DecodeSZS with MKW-SP's decoding function
• #24

Planned Class Support

• MapdataArea (base/derivatives)
• MapdataCannonPoint
• MapdataCheckPath
• MapdataCheckPoint
• MapdataGeoObj
• MapdataJugemPoint
• MapdataPointInfo
• MapdataStage
• MapdataStartPoint
• MapdataFileAccessor (unique accessor)

Unplanned Class Support

• MapdataCamera
• MapdataEnemyPath
• MapdataEnemyPoint
• MapdataItemPath (could possibly be supported with multiplayer)
• MapdataItemPoint (could possibly be supported with multiplayer)
• MapdataMissionPoint

We cannot directly support CSV files because it's used exclusively for inputs, so a script to convert it from a CSV to an RKG in the repository would be nice to have. Users should supply a CSV, and if it's determined to be valid, the script should ask for metadata involving character, vehicle, etc.

EGG::Decomp::DecodeSZS is currently not returning and is instead crashing. It is not immediately clear why.

This can help improve future integration and maintainability while avoiding annoying pitfalls for at the very least, testing. This can help scenarios where Kinoko is being used in the library scenario rather than through the main CLI frontend.

Instead, main() can simply create an instance of the system and run the system object's main function.

Planned Class Support

• RaceManager::Player
• RaceMode (some derivatives - "RaceModeTimeAttack" primarily)
• TimerManager

Unplanned Class Support

• Random (I mean... we probably won't need this)
• KmgFile
• ElineControlManager (I don't even know what this does)

An argument convention will need to be decided.

It would be nice to have the action determine if a run is closer to synchronizing by running Kinoko and storing the synced frame count.

The action should run configure.py and ninja. No PR should be merged without a successful build check.