--If there is no controller parameter, then all of the buttons are returned as they are stored in the system, just like joypad.set(input) takes button names as is.
--If there is a controller parameter, all of the buttons for that controller are returned without the "PX ", just like joypad.set(input, controller) takes button names without the "PX " and assigns them to the matching buttons for that controller.
--No one approved this change, but seriously, this is common sense. I expect some "change denied" April Fool's stuff tomorrow...
-Implemented a blacklist for ButtonCount. By default, Lag, Pause, and Reset are blacklisted. I don't think any of these buttons should be tracked.
-adelikat has informed me that in FCEUX, savestates contained the button state of the frame on which you saved on. He claims that this is redundant because you could retrieve the state from the frame you're loading on, so BizHawk will not do this.
-As such, I just retrieved the input for the frame you're saving on before associating the data with the state.
--This essentially includes the missing info without having to depend on a movie frame to get the data from.
--In order for this to make sense, I made it so that the main joypad.get() doesn't run on a frame you're saving / loading on.
--Finally, in order to show the data from before the save frame when loading the data, I cached that data as well.
---The two above steps require collecting the data for a state once and using that until the frame is advanced or a state is loaded. Otherwise, I'd be able to increase the count significantly by saving multiple times.
-All this said and done, I think this script is perfect now, and is way more convenient to use than the FCEUX counterpart.
Notes:
-As mentioned before, it seems that the scripts are disabled when the console is reset / a movie begins playing. I don't like this to begin with, but worse yet, I noticed that this somehow makes the button data carry over from before the reset. Why is this?
-It seems that using gui.text in savestate.registersave/load causes the text to be written over the previous text instead of clearing the screen and then writing. Is this expected? How can I avoid overlapping text?
--TODO: Disallow Reset, Lag, and other non-buttons. Pause?
--If this works like adelikat says, my missing load state idea will be possible.
-Made the loading information show up on the console instead of the gui.
Note: Still need savestate.registersave/load!
ListView Refreshes When Loading A Session From Recent
When Clicking On New Lua Session Option, It Now Cleans The CurrentLuaSession String. This Will Prevent Some Unwanted Results When Saving A Session.
-As you'll recall, the script has 3 methods of keeping track of input:
--1. Tracking the button counts in real time. This took some minor adjustments, but seems to work fine.
--2. Parsing the button presses from a loaded, read-only TAS file when starting the script, if possible.
---This works well enough after a good amount of refactoring, but I only have it rigged to work for NES.
---As always, note that this method is very slow for big movies, which is why we only use it once.
--3. Caching the counts when saving a state and loading them when loading a state.
---savestate.registerload and savestate.registersave are not currently supported by BizHawk, so this is not functioning at all.
-I propose that a function called movie.getframe(frame) be added that gets status of all of the buttons, just like joypad.get(), for a given frame of a movie.
--This makes the would make method 2 trivial and fast.
--It would allow me to generalize the function for all platforms easily.
---Certainly there might be some discrepancies about which buttons should be disallowed, if any (Is Reset a button press?), but still.
--If this method could somehow work for non-readonly movies, then I'd be able to use the movie to get the counts when I load a state that doesn't have cached data.
---Trust me when I tell you that this would be immensely useful for minimum button TASing. The process would be seamless, and all of these methods combined would provide perfect accuracy while being fairly efficient and only using intensive routines when absolutely necessary.
Note: Earlier, I came up with the idea for a function that lets you set what frame of the movie you are on, which would be useful for endless TASes like we've already discussed, adelikat. Do you still think this is worth having?
-Line count: 583.
TODO: The one I really didn't want to deal with...Gameboy. Why did you have to make this a NESControllerTemplate instead of a GameboyControllerTemplate[]?
--As it'd be obnoxious to make CONTROLS a string, object dictionary and have casts all over the place, I just made a TI83Controls string array to match CONTROLS["TI-83"].
--Positioned the fields as well as I could.
--The config for ( and ) were switched. Fixed. Yet another example of redundant code failing! :)
-Line count: 741.
-Started merging TI-83 to Do:
--This is going to be difficult because the field names are not the same as the label names, meaning that I'm going to have to use a dictionary for TI-83, if not for all of the controls.
--I have to create a formula that calculates the proper row / column for a given field to be placed. Sounds like fun.
-Because I have been advised not to convert the objects to dictionaries, and because using the equivalent of typedef seems confusing if it isn't outright impossible, I had to implement switch statements to handle certain aspects on a platform to platform basis.
-These will end up being much bigger than I would have hoped, but the entire file will be much, much smaller.
TODO: Implement all of the other platforms using these functions.
Note: It seems that the Enabled checkbox doesn't do anything other than persist its state. I checked the latest release, and the same issue was there, so I didn't break it!
--Created CONTROLS constant which contains all of the controls in one dictionary.
--Shrunk DoNES significantly.
TODO:
-Shrink UpdateNES.
-Generalize both functions and apply to NES.
-Have all of the platform specific functions utilize these generalized functions.
-Combine all of the platforms.
while true do
joypad.set("Up", true)
local buttons = joypad.get()
local result = {}
for index, value in pairs(buttons) do
table.insert(result, index .. ": " .. tostring(value))
end
gui.text(0, 36, table.concat(result, "\n"))
emu.frameadvance()
end
For some bizarre reason, after a while, the ordering of the buttons goes from stable to chaotic, making it impossible to read the buttons pressed. adelikat says not to worry about this because order is meaningless in Lua. Still, this is very curious...
TODO: Set using a ClickyVirtualPadController and Global.StickyXORAdapter.SetSticky(Controller + " Up", false)...whatever that means.
-No info on the control bytes, so I'm not dealing with them right now.
-It seems like there's an extra byte for at the beginning of input for NES that doesn't exist for PCE.
--I think it might be the "1 byte for power-on and reset" that the docs refer to, though I'm not sure why this would exist for NES and not PCE...because NES supports control commands and PCE doesn't?
--Perhaps this will become more apparent if I write the importers for SMS, GG, GB, and GBA. I'll need access to a Linux machine to do these, though.
--FDS commands in ImportFMV.
--Bad ROM checksums in ImportText. TaoTao: There's nothing wrong with using warningMsg; it just is limited to showing the first warning message that occurs.
-ImportNMV
--Nintendulator's Four Score recording is seemingly broken.
TODO: ImportMCM clean-up / expansion, Intellivision research.
-Finished ImportVMV:
--I'm not sure what the following comment means: "For the other control bytes, if a key from 1P to 4P (whichever one) is entirely ON, the following 4 bytes becomes the controller data." I'm going to assume this is a bad translation that is the equivalent of my 4 controllers = 4 bytes comment.
--Nesmock has a block of code that seems to handle, or at least account for, commands (Lines 207 - 239 of virtuanes.hh). I don't do anything about this, but it doesn't seem like Nesmock does much of anything about it either. I'll ignore this for now.
TODO: ImportNMV, clean up ImportMCM, and perhaps support other platforms for .MCM, although everyone thinks it's a waste...I like writing importers! I'm afraid of writing cores!
-Made it so that .tas is appended to the file path instead of changing the extension to it.
-Added default emu/MovieOrigin comments to the importers that don't have explicit ones.
-ImportVMV header / added blank frames
-Moved the MnemonicsGenerator declarations outside of the loops.
TODO: Finish ImportVMV (I don't think the provided documentation explains how the input works...) and figure out if my re-record count is off by one or if TASVideos.org is.
This is (almost, bar some local resource hacks) enough to start the
emulator on Linux/Mono, load a ROM and watch the demo (input and
audio don't work yet).
-Fixed ImportFMV's movie title; before, I mistook it for the game name.
-Made "comment" and "SyncHack" constants.
-Moved the "ControllerDefinition"s outside of all of the loops.
-ImportGMV:
--Emulation Version => Movie Version.
--Added the PAL header.
--Made it so that the 6-button error is a warning; considering that the code already properly handles the controller properly and all that needs to be done is have Bizhawk actually support that kind of input, I don't feel there's a reason to go so far as to kill the conversion in this case.
--Reformatting.
---Notably, I added a player loop to simplify the frame data.
--It seems that 1937M uses a 6-button recording and 1731M has 2-player input...bizarre. Anyway, this means that ImportGMV should be good now.
TODO: ImportVMV, ImportNMV, ImportMCM, ImportSMV, Atari core? :)
zeromus