TASLabz / mkw-scripts

Python Scripts for use with Dolphin Emulator. Scripts cover various utilities for creating Mario Kart Wii TASes .
7 stars 6 forks source link

Add Info Display #35

Closed ximk closed 1 year ago

kierio04 commented 1 year ago

Would it be more beneficial to have an additional .py file to allow for further customisation using presets? For example:

I'm aware a lot of these have very few differences for now, but as more stuff gets added to infodisplay, more stuff will only cater to certain people/environments, making it useful to have presets to switch between.

ximk commented 1 year ago

Would it be more beneficial to have an additional .py file to allow for further customisation using presets? For example:

  • Default (Very basic info; only anything that a beginner might want - Frame Count, IV XYZ, Charges and Boosts, Checkpoints and Completion, Miscellaneous)
  • TASing (More info than Default; what a more experienced TASer might want - Default + Speed, EV XYZ, MRV XYZ, MWV XYZ, Position)
  • Micro (Info specific only to micro-optimisation - Frame Count, Lap Splits, Speed, Checkpoints and Completion, Position)
  • Glitch (Info specific only to glitch hunting - Frame Count, Speed, IV XYZ, EV XYZ, Charges and Boosts, Checkpoints and Completion, Miscellaneous)
  • Custom (Whatever is defined in the ini file, which is shipped with the same settings as the Default preset)

I'm aware a lot of these have very few differences for now, but as more stuff gets added to infodisplay, more stuff will only cater to certain people/environments, making it useful to have presets to switch between.

Personally, I think an external guide of recommendations for certain scenarios (and just common sense) would negate the need for presets.

vabold commented 1 year ago

I like the idea of presets. May be out of the scope of this PR.

malleoz commented 1 year ago

I agree that presets are nice, but also agree that it is out of scope. Let's try to get this merged with this basic .ini config file.

I believe we are in agreement that the plan is to populate the config object with a ['DEFAULT'] configuration. Upon setting this object, we should then check to see if the config.ini file has been created. If not, we should copy the DEFAULT configurations to the file. Afterwards, the user will be able to see the default info display in-game, and now be able to edit the generated config.ini file to make the appropriate changes.

kierio04 commented 1 year ago

In that case, I still think we should remove some of the things from being displayed by default. I believe there should only be; Frame Count, Speed, EV XZ/XYZ, Charges and Boosts, Checkpoints and Completion, and Airtime. This means:

Also, we should decide on some consistency regarding the speed/velocity sections. I believe the following should be our layout:

malleoz commented 1 year ago

Applied all changes from my review to xi's branch. I've limited the digits config so that it will be a max of 7 digits. Awaiting @vabold opinion on if we should change the time functions to a dataclass still.

vabold commented 1 year ago

Applied all changes from my review to xi's branch. I've limited the digits config so that it will be a max of 7 digits. Awaiting @vabold opinion on if we should change the time functions to a dataclass still.

The base game has a timer class, tracking minutes, seconds, milliseconds, and whether or not the timer is active. It's created on the stack frequently, so I'd say it's a good idea to allow the same thing here.

malleoz commented 1 year ago

Updated to include a dataclass that abstracts away time manipulation.

malleoz commented 1 year ago

Added a commit to address the info display flickering for the frame a savestate is loaded.