Keyboard does work, but that's not quite fun/effective for playstation games.
{500, 1000, 1500, 1921, 2000, 2500, 2685, 2804, 2828, 2947, 3000, 3072, 3197, 3326, 3356, 3453, 3500, 3578, 3705, 3831, 3961, 4000, 4090, 4217, 4344, 4469, 4500, 4596, 4725, 4852, 4880, 4977, 5000, 5105, 5235, 5360, 5500, 5612, 5741, 5868, 6000, 6122, 6247, 6279, 6377, 6431, 6500, 6543, 6662, 6787, 6916, 7000, 7043, 7170, 7295, 7422, 7500, 7549, 7695, 7735, 7823, 7950, 8000, 8075, 8202, 8329, 8456, 8500, 8583, 8710, 8835, 8891, 9000, 9147, 9266, 9401, 9500, 9520, 9649, 9774, 9899, 10000, 10024, 10151, 10279, 10407, 10500, 10532, 10659, 10786, 10911, 11000, 11038, 11165, 11290, 11417, 11500, 11543, 11669, 11794, 11919, 12000, 12044, 12169, 12294, 12419, 12500, 12544, 12669, 12721, 12795, 12819, 12887, 12941, 12981, 13000, 13045, 13100, 13243, 13303, 13386, 13410, 13500, 13529, 13553, 13593, 13672, 13698, 13748, 13815, 13839, 13958, 13982, 14000, 14036, 14101, 14125, 14245, 14373, 14397, 14500, 14572, 14659, 14683, 14735, 14749, 14802, 14826, 15000, 15019, 15073, 15112, 15174, 15311, 15375, 15500, 15530, 15554, 15614, 15628, 16000}This is like the first battle, but harder. Just use Incendio as your main spell, and you might need to heal. Also, as Harry, using Diffindo works EXTREMELY well. I got a Critical Hit with it and it did 102 SP damage!
I believe I've seen this before and it was due to loading the state while the game is not rendering from the initial game load, so loading a bit later fixed it.
Just to make sure, the savestates made are always from TAS SPU, and not Eternal SPU, right? Might be another misunderstanding, but using savestates from Eternal SPU will probably cause more desyncs, hence why I am making sure...
Note1: All green bar are also desync
Note2: Some major desync will only be fixed by a savestate at desync, in such case... we might just have wasted all the previous savestate trying to bypass the desync himself.
So yeah, the best matchup at some point would probably to anticipate if there a specific "strategy" pattern to favorise. Some strategy would be
-Use the backward tas-savestate for minor desync,
-Use eternal-savestate(that is actually processing frame from a backward tas-savestate) for minor desync point
-Use tas-savestate directly for major desync point
Note: the difference between major and minor desync would be, that the game is likely to desync in the next "few" frame(let's say max 15 frames)
Also, keep in mind that our goal is trying to make plan for getting an efficient "list of savestate" to load while replaying the at last pass of the run in an automated way.
For testing purpose I'll just make the workflow as simple as possible using savestate at desync point, but step by step and while testing with several game, we should be able to enhance the workflow to make it better, while using the best strategy avalaible, avoid possible issue, etc..
---
// The filename was allocated using malloc. Do something about that.
free(filename);Even at setting of 1 for tolerable desync, the script should be going backwards at most 15 frames to cover the sound delay.
With the Peops driver 1.4 you should be able to see your input on the top-left corner, but you should also be able to see the input in the lua console. Here's a screenshot. Note: Actually, your movie desync around frame 3000 for some odd reason, thought before I'm sure I was able to sync all the way(even with the "no sound" spu plugin and a previous pcsxrr version, the movie didn't sync)Language: luawhile true do lastButtonPolled = input.getlastbuttonpolled(); lastPad1Polled = lastButtonPolled["pad1"]; lastPad2Polled = lastButtonPolled["pad2"]; print("[" .. emu.framecount() .. "] " .. lastPad1Polled) pcsx.message("[" .. emu.framecount() .. "] " .. lastPad1Polled) pcsx.frameadvance(); end
So yeah, still need a load savestate in order to get immediate result, but I think this is a pretty good result. @Aktan: I'll need to look exactly what's up with the loading screen a bit more before answering you. But, I just want you know that the "tolerable desync" is a required concept for now and as we keep testing different game, we might lower the value for those tolerable desync. Last point, I should probably start thinking on how to redesign the whole script efficiently(in order to make it easier to maintain the script) now that I don't have to bother with some basic issue FROM pcsxrr. edit: using only using SPU_freeze while switching plugin seem to make the sound working between TAS sound plugin to eternal and vice versa. We will need one more fix to make sure switching plugin doesn't force lua to exit directly his current script.Language: pseudo-codeat frame 2600 : make a savestate(using "spuPlugin#1.dll") call emu.switchspu("spuPlugin#2.dll") loadstate to frame 2600 call emu.frameadvance()
In your example, the save state for frame 2601 was where though? I think that matters. If it is 50 frames back, you need to get a save closer to frame 2601.
And by going back I mean going 11 frames back during "suspending process", checking earlier frames states.
Why won't they happen?
Aktan reported that we were doing it wrong all the time. It appears we don't need to jump farther and farther back for each savestate creation. More than that, if the fix point is really close to desync point, it may be at all skipped by our too long jumps. Say, if it's only needed to load the state 5 frame back, we will never be able to fix it by going backwards.
3.1. Load slot 1 in eternalSPU instance and verify hashes. If it fixes the picture, emulate ahead (step 6), otherwise do: 3.2. Load state 2, verify. 3.3. Load state 3, verify. ............ Repeat for each available slot. 4. If even state at slot 10 (frame 995) doesn't fix it, use it for rollback frame and create a few more states: 4.1. Save frame 996 to slot 1. 4.2. Save frame 997 to slot 2. 4.3. Save frame 998 to slot 3. 4.4. Save frame 999 to slot 4. 5. Load each of these states and verify. It MUST be fixed. 6. Proceed to the next desync.
