Given that DarkKobold has taken over the run and hasn't posted a WIP yet, I don't think there is one. Last time I checked he was still in the planning stages which, obviously, for a game like this will take a while.
What are you using to debug this game if I may ask? Currently I use a combination of MESS and pSX to debug playstation games, is there something more useful out there? Thanks.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Is it ok if a verification movie is over 15 hours long? (eg, verification movie is required when starting from savestate)
Ok. found epic glitches, game is broken:
^These are 'initial' stats, what you start with in 'new game'
Also, this kind of heavily glitched game won't be very entertaining as I can escape from all battles (including bosses). In some cases you must escape before the game crashes. It's interesting/weird enough for me to complete this when I have time though. As far as I know there will literally be 0 battles. I don't know wat will happen when items are required from bosses, etc. I may have to return to normal at those parts in the game.
I'll update with info once I've figured this out properly.
I guess there no problem with the verification movie lenght, if your new movie starting from savestate do a "console reset" right at the beginning. I think this is the standard for run with newgame+.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Hmm ok.
It seems that you cant exit battles with characters that dont have screwed up limit breaks.
Aeris gains level 1.2 and level 3 limit breaks after her first battle with a general enemy. Stats can be glitched to 'almost' any value. But it doesn't seem to work with Cloud. Cloud's stats are quite low, but this doens't matter as he can exit battles due to screwed up limit break (demi3 or comet).
Maybe I missed something, but why do you need to start from a savestate?
Assuming you meant "sram" instead of "savestate", I don't think the length of the verification movie matters, but IMHO start from sram is only acceptable when using a save file that a regular player might create. If you're using weird glitches to create a broken save file, creating the save file should be part of your TAS. IIRC both the chrono trigger and symphony of the night TASes use save corruption, but they do it within their TASes, not beforehand.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Might be SRAM, I don't know. I just need to go very far in the game in order to perform the glitch. Then I can start a new game which will be the part that people want to watch.
No save corruption though. In fact it doesn't require any saving. This is more interesting :D
Do you mean resetting the game with L1+L2+R1+R2+Start+Select after performing the glitch ?
If yes I'm not sure it would be allowed since it's not from power on : /
Joined: 3/18/2006
Posts: 971
Location: Great Britain
No soft-reset either.
I just know that the verification movie is from power-on.
I don't mind if it is not allowed here. I'm just wondering what the rules are. I will make it anyway.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
So how do 'start from SRAM' runs usually work?
Or you mean at some point I have to use a hardware reset?
Confused by this.
I just want to aim for in-game time anyway. I don't mind that it takes 12 hours to set up the glitch.
I can't reveal exactly how it works yet as someone may make the TAS before I do, and I'm actually planning on doing this when I have time to spare :p
whatever = true ;
while whatever do
memory.writebyte(0x62D18,1);
emu.frameadvance();
end;
memory.writebyte for 1 byte
memory.writeword for 2 bytes
memory.writedword for 4 bytes.
Simply set whatever on false when you want it to stop.
Assuming you're using psxjin you can also use the cheat editor with CTRL+C.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Brutalal has created a spreadsheet that plots the optimal path (in terms of number of steps needed to run through a field). It details exactly when you will encounter a random battle and allows many configurable options on how to avoid them.
The problem is there are many ways of getting away from a battle:
1. Accept the battle and instant escape (685 frames)
This also reduces the danger counter to 0 (you get more battles as the danger counter rises)
2. Menu glitch (83 frames)
This glitch avoids a battle but the danger counter remains (eg, if you do 20 menu glitches in a row, you'll be getting a battle every few steps)
3. Stutter Walk (x frames)
This is clearly the fastest way to avoid a battle. The danger counter remains. The spreadsheet calculates how much stuttering is needed. You lose time for every stutter, but it is a tiny amount.
So we know that the battles are entirely deterministic and we even have a spreadsheet which shows the field lengths and when the battle will occur.
This is a segment in the game. The X axis are the steps and the Y axis is the danger counter. The white lines are the battles. You get a battle when the red line hits a white line.
What we need help with is in calculating the fastest way to avoid battles. In other words, should I menu glitch, stutter (sometimes not possible, easy to see when it is or not possible) or accept+escape a battle.
So, I want to know the fastest way through the segment I just posted above. Ideally we will need to optimise the data not just for one segment but for the entire game.
Anyone that can give ideas on how to accomplish this?
You are also forgetting the confound of the double-boss-battle glitch (you discovered!)
I honestly have no idea how to optimize that function.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Weird, I wonder why that glitch doesn't occur when you escape from the boss battles.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
So when you stutter walk the red line rises less quickly like in the first part of the spreadsheet ?
What does the menu glitch exactly do ? Remove the next white line ?
When danger reach 6000 it's an automatic battle ?
Also I'm assuming it's like FF9, danger is reset to 0, when you change screen ?
How long are these segments typically? I am afraid that finding the optimal solution probably has an exponential cost, but this does not need to be prohibitive if the naive number of encounters in a segment is less than about 20. I also have an idea for a greedy algorithm that scales much better, but which is not guaranteed to find the optimal solution. It is also more complicated, so if possible I would go for the optimal one. I will make an example implementation of the optimal solution to illustrate. I'll update the post when it is done.
Edit: Ok, I have implemented my idea now. The implementation (C++) can be found here. I had to guess some of the factors needed, and I didn't have the encounter sequence available, so I generated one randomly in the program. This means that you can't just run the program and use it directly - you have to fill in the correct encounter sequence and costs. So really, this is just a demonstration of an algorithm that solves the problem brute force, but hopefully still fast enough.
It produces two outputs. One is a list of between-actual-encounter segments:
Here, the first encounter happens at step 561, and before that there have been 377 steps of stutter-walking and 3 menu-tricks, for a total cost of 1311 frames above the theoretical no-time-loss time for that distance. The next segment is from step 562 to 1277 with 677 steps of stutter-walking and 4 menu tricks, etc.
The other output is a graph like this one (or rather the text file on which it is based), showing the danger level vs. potential encounters:
Of course, I may well have misunderstood your problem here. But perhaps this will give you some ideas at least. I hope the program isn't too unreadable - I tried to include useful comments, but I didn't have time to polish it. As I said before, this is a brute force implementation, and it scales exponentially with the number of steps. The above example was 2500 steps long and took 3 seconds on my laptop. 3000 steps would probably take more than a minute, and I wouldn't go much further than that. But looking at your example, it seems like your segments will be shorter than this.