Posted: 10/8/2020 7:08 PM
Post subject: Not sure if this is classified as a bug or just a problem.
Quote
TheAlmightyGuru
Joined: 5/4/2012
Posts: 10
There is a problem with how cheats are stored across multiple versions of the same game in version 2.5.1. I'm not sure if it counts as a bug, but it definitely causes undesired behavior. How to reproduce the problem: 1.) Open the NTSC release of Little Nemo: The Dream Master in BizHawk 2.) Click Tools -> Cheats to open the Cheats dialog. 3.) In the Settings menu, activate "Always load cheats," and "Autosave cheats." 4.) Enter the following cheat, Name: Infinite Keys, Address: 008C, Value: 09, and click "Add." 5.) You can verify this cheat works by starting the game and seeing 9 keys. 6.) Close the Cheats dialog, and close BizHawk. The following file will be created: ".\NES\cheats\Little Nemo - The Dream Master.cht" 7.) Open BizHawk and load the PAL version of the game. 8.) Click Tools -> Cheats. 9.) The Infinite Keys cheat will appear in the list. 10.) Start the game, and notice that you start with 0 keys. Why this happens: When BizHawk auto saves the cheat file, and it was able to correctly identify the ROM, it uses the game's title as the name of the cheat file. However, it doesn't include the region in the cheat file name. The NTSC and PAL versions of Little Nemo: The Dream Master use different memory addresses for several variables, including keys. This is also true for a lot of games that have a different version for their Japanese/USA/Europe regions, as well as games with multiple revisions like Zelda, SMB3, etc. Because BizHawk doesn't distinguish between the different versions of the ROMs in the cheat file name, it doesn't store different cheat files for each unique ROM, and loads the same cheats for each ROM even though they won't work. Potential Solutions: Work-Around: Don't use autosave or autoload. You can still manually load and save your cheat files with a unique name, although, you probably won't know which regions are compatible and which aren't. Simple Fix: Always use the name of the loaded ROM file as the file name of the cheat file. This guarantees a unique file for every individual ROM. This solution should be easy to implement since the code is already written for ROMs that are not identified. This also has the benefit of consistency since all ROMs (identified or not) will function the same way. Alternate Fix: Include the region and revision number in the file name of the cheat file for identified ROMs. You could also add the ROM's hash to the end of the file, though this would make it harder to determine which cheat when to which ROM.
Posted: 10/12/2020 7:34 PM
Post subject: Can't add multiple cheats to the same address
Quote
TheAlmightyGuru
Joined: 5/4/2012
Posts: 10
This is another issue I discovered with BizHawk's cheat system and I don't know if I should classify as a bug or usability issue. You can only store a single cheat per memory address. How to reproduce the problem: 1.) Load the USA release of Little Nemo: The Dream Master. 2.) Open the Cheats dialog by going to Tools -> Cheats. 3.) Enter the following cheat, Name: Start on Stage 2, Address: CAB9, Value: 01, Compare: 00. 4.) Click Add and the cheat will be added to the list. 5.) You can test the cheat by doing a soft reset and starting the game. You will begin in stage 2. 6.) Enter the following cheat: Name: Start on Stage 3, Address: CAB9, Value: 02, Compare: 00. 7.) When you click Add, instead of the cheat being added to the list, it will overwrite the previous cheat. Why this happens: BizHawk uses address as a unique identifier and prevents multiple cheats from being added on the same address. Even if you add multiple cheats on the same address manually to a .CHT file, the moment you load them into BizHawk, only the last one in the list is added. Unfortunately, this makes it impossible to add multiple cheats to the same address, and there are several reasons for why you would want to have multiple cheats on the same address (though not active at the same time). In addition to having a cheat for each starting level, you might want multiple cheats on the same address for different weapons, to have different items in your inventory, etc. Potential Solutions: Work-Around: For every cheat you want to use that is on the same address as another, you can store it in a unique cheat file on disk. So, if you wanted to have a cheat in Super Mario Bros. for starting levels, you would need seven different cheat files. Fix: Stop using the address as a unique identifier. If it's being used as a unique id for the cheat, consider using the line number from the cheat file as a unique id. I've checked FCEUX and Mesen, and they both support the ability to store multiple cheats on the same address.
Posted: 10/12/2020 8:22 PM
Quote
DrD2k9
He/Him
Editor, Judge, Expert player (2220)
Joined: 8/21/2016
Posts: 1090
Location: US
Arcade TAS of 2023 Exotic platforms TASer of 2020 First edition TAS of 2020 Gameboy TAS of 2020 Exotic platforms TASer of 2019 Computer TASer of 2017
To add to the above post regarding allowing multiple cheats for a given memory address: Another reason to allow it would be for setting two different cheats on the same address that would allow for different results depending on the 'compare' value. The following (while not exactly practical) is a valid example: In Super Mario Bros., the RAM address for lives is 0x075A. Cheat #1 could watch for a compare value of 0x00 at that address and set the value to 0x01. This would effectively produce infinite lives while still allowing the displayed number of lives to change when displayed between lives/stages. The lowest value displayed would be 2. Cheat #2 could then watch the same address for the value 0x09 and write a value of 0x08. As the above code produces a minimum number of lives, this code would limit the upper boundary of number of lives so that the displayed value could not surpass 9 when shown between stages/lives. While not really impacting gameplay, this code could be used for aesthetic reasons to prevent a crowned/glitched lives count. Even thought they are for the same address; as these two codes watch for different 'compare' values, their effects would never conflict. Therefore when these two cheats are utilized together, the displayed number of lives on the screen between stages/lives would never be outside the range from 2-9.
Posted: 10/21/2020 4:16 PM
Quote
TheAlmightyGuru
Joined: 5/4/2012
Posts: 10
For those who like playing around with NES cheats, the NES Hacker Wiki has just been given a major cheat update. There are now over 3,300 cheats spanning 300 games, and the cheats have been refactored to work with assorted emulators. http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?title=Cheat_Archive These can be very helpful for anyone trying to make a TAS since they include the addresses for a lot of values in memory. Unfortunately, because it doesn't support multiple cheats per address, a lot of them won't work properly BizHawk . Also, because BizHawk doesn't include region or version in their cheat file naming conventions, there might be some confusion as to which cheats will work and which won't as I mentioned above, but this is still a good start. If you use FCEUX, Nestopia, or the other supported emulators, they should all work correctly.
Posted: 11/24/2020 9:43 PM
Quote
TheAlmightyGuru
Joined: 5/4/2012
Posts: 10
Now I've found something that I am confident is a bug: The cheat interface allows you to specify how you want your cheat values to be displayed (unsigned, signed, hex, or binary), and the cht file format has a column which saves this value which is represented as a u, s, h, or b. This way, it knows how to convert the number when it's loaded from the cht file. However, when you save your cheats, all of them are saved as type h, but the compare column is saved as the display type, which causes problem when the cheat file is reloaded. This problem only occurs when saving a cheat. If you manually alter the cht file to have the proper display type, it will load correctly. I tested this in version 2.5.2.