1 2
Posted: 5/2/2011 12:20 PM
Quote
diggidoyo
Experienced player (580)
Joined: 1/27/2011
Posts: 427
Location: Oregon
First edition TAS of 2015
Yeah, steps 5 and 13 are the same and they are both optional. It's mostly just for insurance against a bad save state. Sad it didn't work. In all honesty, we shouldn't have to go back this far to rerecord. And although it worked for me, I only made a little progress before it locked again later on. I have another idea I'm going to try and you should try it to. When you load the state in another instance, instead of closing it and exporting it from the original instance, try exporting from the new instance. Maybe repeat the process one more time before recording. My thought process is I'm just trying to eliminate any possibility of the old inputs to make their way into new file. I'll let you know if this works. I know this all seems a little farfetched, but I can't really think of any logical reason for the this problem to occur, so I'm willing to try anything.
Posted: 5/2/2011 3:15 PM
Quote
Toad_King
Joined: 3/20/2009
Posts: 87
I'm using this unfortunate turn of events to go in and try to rewrite major parts of the movie code in Dolphin. The way it's done now is by swapping around multiple temporary and final movie files and can lead to file corruption, as you've discovered. I'm currently rewriting to no longer use temporary files, but ran into a couple weird bugs. Hopefully I can commit this change in the next couple of days.
Posted: 5/2/2011 3:34 PM
Quote
diggidoyo
Experienced player (580)
Joined: 1/27/2011
Posts: 427
Location: Oregon
First edition TAS of 2015
You'd be my hero. Although this would mean I'd finally have to move up to the latest revision, it will be a welcome change. I'll keep an eye on the SVN changes.
Posted: 5/2/2011 10:24 PM
Quote
Toad_King
Joined: 3/20/2009
Posts: 87
Well, the good news is I have most of the rewrite working and it should be ready to commit later tonight or tomorrow. The bad news is I discovered a bug that reset the rerecord count for movies for each recording "session". That means all movies you made up to this point will only have the number of rerecords since the last time you started recording, not total overall. While not a huge bug, it's still upsetting that it effects basically all movies made so far.
Posted: 5/3/2011 4:18 AM
Quote
diggidoyo
Experienced player (580)
Joined: 1/27/2011
Posts: 427
Location: Oregon
First edition TAS of 2015
I didn't even know the Dolpin was counting rerecords. Where is this number located?
Posted: 5/3/2011 5:07 AM
Quote
Toad_King
Joined: 3/20/2009
Posts: 87
diggidoyo wrote:
I didn't even know the Dolpin was counting rerecords. Where is this number located?
In the .dtm file at offset 0x2D as a 32-bit unsigned integer.
Posted: 5/3/2011 7:21 AM
Quote
diggidoyo
Experienced player (580)
Joined: 1/27/2011
Posts: 427
Location: Oregon
First edition TAS of 2015
Since I have no idea what that means, any chance you can tell me the number of rerecords in my file? I know its probably wrong since I've been using r7302, but I'm curious. www.megaupload.com/?d=5NJHCME8
Posted: 5/3/2011 2:30 PM
Quote
Toad_King
Joined: 3/20/2009
Posts: 87
The file you posted says there's been 0 rerecords. I'm guessing you just opened the game and exported what you had so far, so it reset the count once again. The latest revision has my new rerecording code in it, so that should keep track of the number of rerecords in the future. I would like you to be careful when using it because I can't be too sure that it still syncs everything correctly. My tests says it does, but I don't do the level of rerecording people here do.
Posted: 5/3/2011 4:47 PM
Quote
diggidoyo
Experienced player (580)
Joined: 1/27/2011
Posts: 427
Location: Oregon
First edition TAS of 2015
Haha, figured as much. Glad you noticed and corrected this problem so fast. Since I still have 4 stages left, I'll just take the rerecord count and multiply it by three. Should give a good enough approximation. And I'll let you know how the syncing issue is now. ::EDIT:: WOW! Not only did it "unlock" my file and allow rerecording again, it actually correctly synced with the input that I put into that file (which the old revision did not). Also noticed you fixed the crash on stop bug. Fantastic work! In my experiences, the only bug that is left, is an unrelated issue where saving a state sometimes results in an input locked state. Meaning, upon loading the state, the Dolphin will ignore all input and continually press the inputs that were being pushed when the state was saved. For example, if you save a state while jumping right, loading that still will have have jump and right eternally pushed and it wont do anything else. Happens more often than I'd like, but not all the time. @admin Could you move the past 20 posts into this thread since the information is more relevant to Dolphin as a whole than Mega Man 9. Thanks.
Posted: 5/3/2011 7:34 PM
Quote
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
diggidoyo wrote:
Could you move the past 20 posts into this thread since the information is more relevant to Dolphin as a whole than Mega Man 9. Thanks.
Done.
Posted: 5/4/2011 6:19 AM
Quote
DDRKhat
Player (36)
Joined: 9/9/2006
Posts: 388
I haven't tried it yet so I'll post this then amend this if I find it addressed. Loading a savestate always seems to go into write mode, despite having "read-only" mode toggled in the emulator, this is a nuisance if I want to go back and confirm my input was done. Another thing I can think that I would like is the ability to ignore SRAM for certain games, I am trying to provide a input file that starts as if you've literally just installed the WAD onto the wii (fresh savefile etc). A earlier revision would fail to write SRAM if I set folder permissions so it could not but recent revisions complain about the inability to write and the emulation dies, so I have to keep going into the folder to delete the data. In regards to my recording it doesn't cause de-syncs but it does make the start look sluggish (because of the screen number difference pressing "+" to start MegaMan9 seems to take a bit, rather than happening instantly if those screens HAD been loaded) The issue of DOWN/RIGHT disabling HOTKEY usage still seems to exist. --EDIT-- I've gone ahead and flagged these up as issues with their Issue tracker. Issue 4463: "Read Only" DTM ignored. Issue 4464: Hotkey Kill-Switch Issue 4465: Saves forced Issue 4466: Multi-Track Recording
A whisper in the wind~~
1 2