taslabz / dolphin Goto Github PK

Currently, scripts can register listeners with their respective decorators. Example:

@event.on_frameadvance
def on_frame_advance():
    pass
    
@event.on_savestateload
def on_savestate_load(is_slot, slot):
    pass

Instead, it would be preferable if we could wrap these individual decorators with a generic one. Example:

@event.register(event.Evt.frame_advance)
def on_frame_advance():
    pass

@event.register(event.Evt.state_load)
def on_savestate_load(is_slot, slot):
    pass

Relates to TASLabz/mkw-scripts#28

To make all OSes behave the same, we should remove the Windows ifdef that sets the Python paths.

This error commonly appears when calling functions with event decorators above them, but I am unsure if that is the direct cause. These errors have no impact on how the script runs, however.

While the game is running, if we start a script which performs a memory read, there's a chance a deadlock will occur.

Main Thread:

CPU/GPU Thread:

If you close the script widget after startup, it is not clear how to navigate back. I believe currently you have to click "Show Log", then right click the top of the log widget, and then click Script. Instead, we should have a button under View or Tools to show the Scripts list... Not sure which, argue away :)

Currently, setting buttons/sticks through these functions causes all the items in the dictionary that are not specified to default to False (buttons) / neutral (sticks). This can be a massive headache for script writers when the script is only designed to modify one or two values. There is a workaround, but it is messy, and ideally we would simplify the process.

The functionality is already there in Dolphin, but how would we create a way to download the recommended gecko codes for TASing through the button?

People have suggested a repository to hold all of the config files, and Dolphin would download and overwrite the current .ini file with the new TASing one, but a discussion may be helpful before moving forward.

[Applies to upstream too]

For some reason, the following hotkeys only exist for Wii Remote profiles, rather than GameCube Controller profiles:

• Next Profile
• Previous Profile
• Next Game Profile
• Previous Game Profile

The ScriptingWidget pane is too wide, honestly because of the three buttons at the top. We ought to change these buttons to just a +, -, and refresh icon I think.

PR#10 aims to search for scripts/modules in Load/Scripts folder. We need to make this apparent in the README, along with any other script-related changes, such as the toggle feature we are adding.

• Also need to explain toggle functionality

Just small nit-pick I'm noticing. When clicking on a loaded script in the list, we should be able to clear it from the list with delete key.

This was introduced in 7c555f0.

Steps to reproduce:

1. Set game speed limit to 50%
2. Open TAS Input
3. With TAS Input as window-of-focus, hold down frame advance hotkey
4. With hotkey held down, hold down left-click and circle around the Main Stick
5. Notice latency and delay in both TAS Input window AND the input display
6. Let go of frame advance hotkey
7. Notice TAS Input Window snaps back to full responsiveness.

This is a problem even in upstream Dolphin 5.0-19159. This may be a very tough issue to fix. According to @Gaberboo frame advance is also problematic at speeds exceeding 100%.

I cloned the repo (with --recurse-submodules), made a build folder, went to it, ran cmake .., then make -j24.

Errors:

/home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:248:14: error: ‘Info’ does not name a type 248 | extern const Info<ShowCursor> MAIN_SHOW_CURSOR; (repeated lots)
and
In file included from /usr/include/X11/Xlib.h:44, from /usr/include/X11/extensions/Xrender.h:28, from /usr/include/X11/extensions/Xrandr.h:33, from /home/saltq/dev/pycore-dolphin/Source/Core/UICommon/X11Utils.h:10, from /home/saltq/dev/pycore-dolphin/Source/Core/UICommon/X11Utils.cpp:4: /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:235:3: error: expected identifier before numeric constant 235 | None, | ^~~~ /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:235:3: error: expected ‘}’ before numeric constant In file included from /home/saltq/dev/pycore-dolphin/Source/Core/UICommon/X11Utils.cpp:19: /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:234:1: note: to match this ‘{’ 234 | { | ^ In file included from /usr/include/X11/Xlib.h:44, from /usr/include/X11/extensions/Xrender.h:28, from /usr/include/X11/extensions/Xrandr.h:33, from /home/saltq/dev/pycore-dolphin/Source/Core/UICommon/X11Utils.h:10, from /home/saltq/dev/pycore-dolphin/Source/Core/UICommon/X11Utils.cpp:4: /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:235:3: error: expected unqualified-id before numeric constant 235 | None, | ^~~~ In file included from /home/saltq/dev/pycore-dolphin/Source/Core/UICommon/X11Utils.cpp:19: /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:240:19: error: ‘OutlineRes’ was not declared in this scope; did you mean ‘Config::OutlineRes’? 240 | extern const Info<OutlineRes> MAIN_IMGUI_OUTLINE_RES; | ^~~~~~~~~~ | Config::OutlineRes /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:233:12: note: ‘Config::OutlineRes’ declared here 233 | enum class OutlineRes | ^~~~~~~~~~ /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:240:19: error: ‘OutlineRes’ was not declared in this scope; did you mean ‘Config::OutlineRes’? 240 | extern const Info<OutlineRes> MAIN_IMGUI_OUTLINE_RES; | ^~~~~~~~~~ | Config::OutlineRes /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:233:12: note: ‘Config::OutlineRes’ declared here 233 | enum class OutlineRes | ^~~~~~~~~~ /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:240:19: error: ‘OutlineRes’ was not declared in this scope; did you mean ‘Config::OutlineRes’? 240 | extern const Info<OutlineRes> MAIN_IMGUI_OUTLINE_RES; | ^~~~~~~~~~ | Config::OutlineRes /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:233:12: note: ‘Config::OutlineRes’ declared here 233 | enum class OutlineRes | ^~~~~~~~~~ /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:240:19: error: ‘OutlineRes’ was not declared in this scope; did you mean ‘Config::OutlineRes’? 240 | extern const Info<OutlineRes> MAIN_IMGUI_OUTLINE_RES; | ^~~~~~~~~~ | Config::OutlineRes /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:233:12: note: ‘Config::OutlineRes’ declared here 233 | enum class OutlineRes | ^~~~~~~~~~ /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:240:19: error: ‘OutlineRes’ was not declared in this scope; did you mean ‘Config::OutlineRes’? 240 | extern const Info<OutlineRes> MAIN_IMGUI_OUTLINE_RES; | ^~~~~~~~~~ | Config::OutlineRes /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:233:12: note: ‘Config::OutlineRes’ declared here 233 | enum class OutlineRes | ^~~~~~~~~~ /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:240:19: error: ‘OutlineRes’ was not declared in this scope; did you mean ‘Config::OutlineRes’? 240 | extern const Info<OutlineRes> MAIN_IMGUI_OUTLINE_RES; | ^~~~~~~~~~ | Config::OutlineRes /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:233:12: note: ‘Config::OutlineRes’ declared here 233 | enum class OutlineRes | ^~~~~~~~~~ /home/saltq/dev/pycore-dolphin/Source/Core/Core/Config/MainSettings.h:240:14: error: ‘Info’ does not name a type 240 | extern const Info<OutlineRes> MAIN_IMGUI_OUTLINE_RES; |

Also warning while running cmake:

CMake Warning at CMakeLists.txt:684 (find_package):
By not providing "Findfmt.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "fmt", but
CMake did not find one.

Could not find a package configuration file provided by "fmt" (requested
version 8) with any of the following names:

fmtConfig.cmake
fmt-config.cmake

Add the installation prefix of "fmt" to CMAKE_PREFIX_PATH or set "fmt_DIR"
to a directory containing one of the above files. If "fmt" provides a
separate development package or SDK, be sure it has been installed.

This may need to be bisected. It would be surprising if whoever wrote this never tested it.

Currently, the Python version the scripting engine uses is 3.8.5. On 3.10, the most notable changes would be the addition of match case statements, along with supporting the use of | for type unions natively. Mac and Linux(?) versions use whatever Python version is installed on the user's computer, but on Windows, it forces the use of 3.8.5. With the deprecation of Py_SetPath in 3.11, I believe 3.10 is our best option at the moment.

When reading large data structures, it's a bit annoying to have to create a for loop to iterate on memory.read_u8 calls to read a certain number of bytes. It would be better (and less resource intensive) to have a new ABI function which returns bytes in some form (possibly a char array).

The if-statement here is to prevent writes from occurring twice in a frame. If the same writes happen twice in a frame, there is a chance that the addresses will not get translated in MMU::WriteToHardware because m_ppc_state.msr.DR == 0. This can also happen for some reads. Not immediately sure how to handle this.

Already, we are starting to introduce features that invalidate features outside of the scope of this project (e.g. #26). Netplay is certainly an uncontroversial removal for a TAS-focused emulator, and it may be worthwhile to eliminate other features from this fork. This could lead to reduced build times with the removal of entire files (assuming compilation errors that would arise are fixed), simplify the UI, etc.

There are a few questions here:

1. Is this a good precedent to set forward?
2. What is the full scope of Dolphin's feature set?
3. Do we remove these files from the project entirely or simply remove the option for them to be selected?

Related to TASLabz/mkw-scripts#12.

The current MKW implementation looks like this:

from dolphin import memory


def chase_pointer(base_address: int, offsets: List, data_type: str):
    current_address = memory.read_u32(base_address)
    for offset in offsets:
        value_address = current_address + offset
        current_address = memory.read_u32(current_address + offset)
    data_types = {
        'u8': memory.read_u8,
        'u16': memory.read_u16,
        'u32': memory.read_u32,
        'u64': memory.read_u64,
        's8': memory.read_s8,
        's16': memory.read_s16,
        's32': memory.read_s32,
        's64': memory.read_s64,
        'f32': memory.read_f32,
        'f64': memory.read_f64,
        'vec3': vec3.read,
        'mat34': mat34.read,
        'quatf': quatf.read,
    }
    return data_types[data_type](value_address)

While vec3, mat34, and quatf are part of the EGG and nw4r libraries, the data_types dict should be extendable dynamically for game-specific implementations. The ideal usecase of this dict is for reading a datatype regularly created on the stack.

We should have a global data_types dict that scripts can append to.

Not sure if this is even necessary.

The function would serve the same functionality as unticking a filled checkbox in the Scripts tab.

The current behavior is to invert the current on screen text color. If the color is set to 0xFF00FFFF, the outline color is 0xFFFF0000. This means the outline is red and the text is blue, which looks horrible.

• MBPs can be set with an empty dictionary (MBP will be set at 0x00000000)
  • This is fixed on my feature branch malleoz/mbp_fixes (also prints error to log in this scenario)
• on_memorybreakpoint and on_codebreakpoint do not work
  • The event was never emitted

Pressing the "Remove Selected Script" button on an active script causes it to run indefinitely.

This can probably be addressed alongside #52

If I have a script that just dumps ghost data to a .RKG file, the script will end execution, yet it will remain checked and "active" in Dolphin.

https://github.com/dolphin-emu/dolphin/pull/ 12193
(Link broken so it is not linked to within the PR)

This module should allow for the creation (and modification?) of instruction/memory breakpoints.

The arrow keys control both the selected script in the ScriptingWidget and also my Gamecube controller in the game widget. Navigating through MKWii main menu causes me to change what script is selected. We need to investigate if it is possible to prevent this behavior.

When running Mario Kart Wii, it is pointless to see TTYD or other game scripts. We propose the following:

• With no game running, show every script in the Scripts folder and its children directories
• When booting up a game, change the ScriptsWidget view to only show scripts for that particular game
• Implement this by retrieving the current game ID without the region (RMC for MKWii, G8M for TTYD, etc.) and navigate to /Scripts/[GameID] directory, if present, otherwise show nothing
• For mkw-scripts repository, we'll have to move MKW scripts to the new /Scripts/RMC folder.

Currently, Python scripts have the possibility of desyncing/freezing for a frame, which is especially noticeable with scripts that require frame perfect inputs. Games played without these scripts are able to sync with other Dolphin versions, so it is believed to be an issue to the way Python and Dolphin communicate. The reason behind these desyncs appears to be related to the frame count stopping at random intervals for a frame and resuming updates the frame after, or something related to how set_gc_buttons processes inputs.

This wasn't apparent in the preview build given to us by @gitrinitas at the start of the PyCore development process, but somehow found it's way into the build that we based it off of. No one has any clue how this happened to "reappear".

event.on_frameadvance() parentheses must be removed, and we need to specify global frame_counter

While most users will avoid this issue entirely, the Native File Dialog .vcxproj file does not build correctly when building the entire project. Rather, the NFD library has to be built individually before returning to the main project to compile fully.

Multiple ideas have been presented, but the general idea is to create a setting to select the path the scripts should be retrieved from in Game Config in Properties, and then autoload the contents of the folder chosen on the boot of that game.

As these require multiple movements to perform, it may be tricky for scripters to create functions that replicate this. It also would remove the need of potential "hacks" to create these motions.

I assume you could use something to replicate how shake/swing hotkeys output these results, but I am unsure if that's possible.

Repro steps:

1. Create a new emulated Wii remote. Assign the controller extension to either Nunchuk or Classic Controller.
2. Open the TAS Input window - this should work fine.
3. Go back into the controller window and assign the controller extension to the opposite one.
4. Open the TAS Input window - the controller does not refresh.