Major problem: Bulletproof rerecording is not working at all. Loading any savestate invalidates all later savestates, and makes them give an "inconsistent state" desync warning even when recording. That warning indicates this change is intentional or at least anticipated, but I can't find any option to re-enable bulletproof rerecording.
>Loading any savestate invalidates all later savestates, and makes them give an "inconsistent state" desync warning even when recording.
This sounds exactly like a problem I reported to Upthorn earlier. He suggested I must accidentally have activated read-only, because the "inconsistent state" warning should not occur in read-write mode.
Major problem: Bulletproof rerecording is not working at all. Loading any savestate invalidates all later savestates, and makes them give an "inconsistent state" desync warning even when recording. That warning indicates this change is intentional or at least anticipated, but I can't find any option to re-enable bulletproof rerecording.
Well no, deactivating bulletproof rerecording change was not intentional, or anticipated. I just rearranged the if statements after all the import functions so that there wouldn't be so many repeated conditions.
I must have screwed up the logic somewhere. That's a high priority fix right there.
Truncated wrote:
>Loading any savestate invalidates all later savestates, and makes them give an "inconsistent state" desync warning even when recording.
This sounds exactly like a problem I reported to Upthorn earlier. He suggested I must accidentally have activated read-only, because the "inconsistent state" warning should not occur in read-write mode.
While it's true that you must have accidentally activated read-only, it looks like Nitsuja has reproduced the problem you were having. Now that I know what the circumstances are, I can find it and fix it.
Edit: Oh, you weren't in read-only, it's even worse than I thought.
How fleeting are all human passions compared with the massive continuity of ducks.
While it's true that you must have accidentally activated read-only
It happens even when read-only is off, so he might not have. That's why I thought it seemed intentional, because that warning should only happen in read-only mode, and the warning actually correctly informed me of when I was going to have a desync. But I can see now how both of those could be accidental consequences of some code rearrangement.
Nitsuja reported a fairly major bug with RAM search to me, this has been fixed, redownload the zip file.
I really don't know how I missed this one. I apologize to all those of you who were trying to use RAM Search and having difficulty.
How fleeting are all human passions compared with the massive continuity of ducks.
Confirmed that bulletproof re-recording is still broken. In a way it got worse, because the warning is gone and it still desyncs.
EDIT: More specifically, it doesn't work correctly if the current movie length is less than the movie length in the state being loaded. Here are some easy steps to reproduce the desync when recording a movie:
1) Save slot 1
2) Walk right for 5 seconds
3) Save slot 2
4) Load slot 1
5) Walk left for 2 seconds
6) Load slot 2
7) Toggle mode to read-only
8) Load slot 1
The result should be that you see the character walk right for 5 seconds. Instead, you will see the character walk left for 2 seconds, then turn around and walk right for 3 seconds and stop. This was working correctly before...
Upthorn, so how about calling it differently? With your eager desire to finish version 9 and move on to version 10, we've run out of letters, and now successfully have eight or nine "9z"s. ;)
I suggest calling it gens_9z_bugfixN, where N is the number incrementing with each zip update.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
It's practical if the zip name stays the same though, so we won't have to run around and fix the links.
Thanks for refixing it again. I forgot to mentioning it, but RAM search and watch seemed to work correctly last version also.
Bug: If you change the data type or size (or misaligned checking) while the RAM search has results shown, their addresses all get reset to starting from 00A00000.
Bug: If you change the data type or size (or misaligned checking) while the RAM search has results shown, their addresses all get reset to starting from 00A00000.
I've noticed this myself, but I can't work out the cause.
How fleeting are all human passions compared with the massive continuity of ducks.
Well, after 9z should come 9aa then 9ab etc.... Yes, no!!?
Or, if there are still bugfixes and whatnot pending before a revision increment, you could add the build date as part of the filename (ie gens_9z_20061130, gens_9z_20061203 ... etc).
Makes it easy to discern if you have the latest version :)
Well, after 9z should come 9aa then 9ab etc.... Yes, no!!?
Or, if there are still bugfixes and whatnot pending before a revision increment, you could add the build date as part of the filename (ie gens_9z_20061130, gens_9z_20061203 ... etc).
Makes it easy to discern if you have the latest version :)
Good idea.
upthorn wrote:
nitsuja wrote:
Bug: If you change the data type or size (or misaligned checking) while the RAM search has results shown, their addresses all get reset to starting from 00A00000.
I've noticed this myself, but I can't work out the cause.
I've worked out the cause, and now fixed this issue, a long with a pretty major RAM leak that I can't believe noone noticed before.
Also a bug where it went into an infinite loop if someone opened a new ROM without closing the RAM Search and Watch windows.
Uploaded the new version to the old location But this time I've dated the exe contained inside.
Edit: fixed capitalization on link
9z is obsolete, link removed
How fleeting are all human passions compared with the massive continuity of ducks.
getting a 404 when I try to access http://upthorn.mspencer.net/Gens_Movie_9z.zip
(It B0RKED :P)
In case people don't like dated executables, you could also just place a build timestamp in the about dialog, so that people can still figure out what version they're using (since checking a file timestamp is ever so difficult o_0)
The release prior to this exposed a surprising number of bugs in RAM search, which were all being blocked from occuring by the bug Nitsuja alerted me to.
They have now been fixed.
Among about a dozen minor problems,
RAM search will no longer cause Gens to freeze if the final value is eliminated.
RAM Watch will properly update values which have had the eliminated flag set
Telling RAM search to check for misaligned values will no longer cause searches to behave oddly, (although there is no guarantee that the values it sees will be correct, which is why it's optional.)
[EDIT]
Removed broken links to obsolete version
How fleeting are all human passions compared with the massive continuity of ducks.
Another ?bug?;
When using the input splice It does not input correctly, any 2P / 3P input becomes 1P input!
Odd. I haven't seen that happen when I use it. It can be fixed by inserting one byte of FF in a hexeditor, just before where the input gets spliced back in
How fleeting are all human passions compared with the massive continuity of ducks.
It would be great to have a feature to ignore addresses that you don't want to view at all in the search menu. For example, if I'm searching for a value that differs from the past value, and I get a heap of values/addresses that does the same, I want to hide some of the addresses to suit my needs better. Preferrably by selecting multipple of them and choose hide.
Also, the reset should still hide the hidden values/addresses, and an additional unhide button would be a must. :)
It would be great to have a feature to ignore addresses that you don't want to view at all in the search menu. For example, if I'm searching for a value that differs from the past value, and I get a heap of values/addresses that does the same, I want to hide some of the addresses to suit my needs better. Preferrably by selecting multipple of them and choose hide.
Also, the reset should still hide the hidden values/addresses, and an additional unhide button would be a must. :)
I like that idea, I'll try and get it into Gens10.
How fleeting are all human passions compared with the massive continuity of ducks.
