Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
Well done!
EDIT: Something I've discovered in my SQ3 WIP that may potentially save you a few more frames on this run (if you haven't already done it)...
When, after text input, a dialogue box pops up that requires an <enter> press to clear; it is often possible to type the necessary <enter> command on the same frame as the rest of your text. Using the mouse click to then submit the command before the <enter> is read by the game allows for the fastest clearing of these dialogue boxes, as the enter command has already been submitted but not executed until after the mouse click.
It's only a couple frames here and there, but it maybe enough to increase the time saved compared to the original from 1.8 seconds to above 2 seconds (hopefully requiring less wait time for Elsa to jump over the desk).
Thanks for the suggestion, DrD2k9. Yup, I found that too, and I took advantage of that everywhere I could. Please let me know if you discover any other potential savings!
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
slamo wrote:
There does seem to be some differences in the original movie file and the movie file that results from the .tas file.
Unfortunately, it's not completely accurate, and will be off by a frame every once in a while. I've improved it as much as I can at the moment, though if you or others would like to take a crack at it, please feel free.
In the meantime, fixing the desyncs isn't a huge issue; much better than hacking the movie file for sure. Comparing the original movie file to the desynced movie file is usually the best way to find out exactly where the desync is. I've created a script (generatemovieabs.lua) that converts a movie's relative values to absolute values (.abs file). Here's how to use it:
First, convert your original movie to an .abs file. Then, whenever your run desyncs, save a movie, and then convert that movie to an .abs file. Finally, use a file-diff program to compare the two .abs files and see where the absolute times start getting consistently off just before the desync. That should be where you'll need to adjust it. Usually it's solved by simply adjusting a frame advance by one.
Unfortunately, this method stops working if you've inserted any new instructions, or removed any. Then it's a matter of observing frame-by-frame and deducing where the desync is.
slamo wrote:
There seems to be a significant difference when the first KEYEDGE event starts.
That "significant difference" is actually just one frame. It varies (which is what makes JPC-rr annoying), but often a frame is roughly 14,000,000 nanoseconds, which is what the movie file counts in.
I took your files and it took me about 10 minutes to get it syncing the boot up properly to get the right RNG seed. After that, it went smoothly until the room where you pick up the laser (22 seconds in). Then it desynced. I spent another 10 minutes fixing that room (two places needed fixing), that got me to the room with the balls (5 seconds further), where it desynced again. It's slow, but much faster than working from scratch.
Here's the tas file up to the last desync I mentioned. I suggest creating a save point there, then running your script from that point onwards (everything after savestate 682).
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
creaothceann wrote:
What is used to calculate time, ints or floats?
Lua doesn't have ints or floats, just reals. That said, all times are whole number values, so there should be no issue with any floating point addition rounding.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
slamo wrote:
I keep having to add extra frames every couple of seconds to get it to resync, so it seems like the script's definition of a frame is slightly shorter than what the game considers a frame. How do the scripts determine how many nanoseconds a frame is, and are there any adjustments I can make to line it up better?
Huh, that's odd. It doesn't convert nanoseconds to frames. The recorder first parses the movie file and converts all relative time entries to absolute times by adding them up as it goes. Next, it steps through the movie, frame by frame, and compares the current time (jpcrr.clock_time()) with the last processed line of the movie file. If the current time is greater than the last processed time, then it processes the lines until it catches up. If the current time is less than the last processed time, it records a frame advance and advances the frame.
A quick question, how are you replaying the tas file? Are you letting JPC-rr run, or are you stepping frame-by-frame? Sometimes I've found stepping frame-by-frame ends up giving different results then letting it run freely.
If you can send me your tas file, movie file and disk image, I could try it out on mine to see what I can find.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
slamo wrote:
This looks amazing. I was just working on something where I need to change the starting RTC and re-sync to deal with the new RNG - this will massively improve that process. I'll try it out when I have time and let you know how it goes.
Great! I’d love any feedback or suggestions. FYI, my copy of JPC-rr sometimes stalls when running or recording long tas scripts. It just means I have to try again until it doesn’t stall. I’m curious to see if it stalls on others’ computers
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
One of the biggest pains working with JPC-rr is the fact that the movie files are so hard to refactor. To patch in a change into a finished movie is nearly impossible, as the movie files are stored with very specific relative time values. Changing any one of these values has a ripple effect that impacts all the others, and can often lead to invalid values and desyncs everywhere.
After thinking about the problem for a while, I decided to try and create a set of lua scripts to make this process easier. Once finished, I tested it out on my Hero's Quest TAS, and was happy to find out that it was a great success. The scripts I created convert the complicated movie file format into something readable and easily editable. And although it's not perfect and does cause some desyncs, fixing them is a lot simpler now. To give some perspective, it took me about eight hours to refactor the Hero's Quest TAS and remove the resyncs. It would have taken me 3 - 4 times that long redoing it from scratch. When I found another possible improvement at the end of refactoring, it took me just two hours to refactor it from the start again and remove the resyncs a second time.
I think it's at a state where I can share it with the rest of the community now, so without further ado, here is what I've named "TAS Scripts".
Step 1: Record a TAS script
The first step in refactoring the code is to convert a movie file to a TAS Script.
1) Download the recordtasscript.lua and fileio.lua files and put it in your lua directory.
2) Put the movie file you want to convert into the lua directory
3) Edit the recordtasscript.lua file in a text editor and update the moveFile variable with the name of the movie file you want to refactor, and the TASScriptFile variable with the name of the TAS Script file you want to create. Save.
4) Open JPC-rr and load the movie file
5) In the Lua window, run recordtasscript.lua. Wait until it has parsed the movie file and says you can start your movie running.
6) Run your movie to the end. The script will convert the movie to a TAS Script as it plays.
7) Terminate the script once the movie has fully played.
If successful, your movie file which looks something like this:
The TAS Script
The TAS Script has the following commands (case-sensitive):
FAdv:#
This command tells the script runner to frame advance # number of frames. You'll most likely be editing these values whenever you run into a desync.
MXMove:#
This translates to an XMOUSEMOTION command that moves the mouse along the X-axis by #
MYMove:#
This translates to an YMOUSEMOTION command that moves the mouse along the Y-axis by #
MClick:#
This translates into an MOUSEBUTTON command that clicks the # button on the mouse (0 for left button, 1 for right)
Type:abcde
This creates KEYEDGE commands for all the letters after the colon. Note that special keys are bracketed in '<' and '>' brackets (see fileio.lua for list of keys) and normal keys are represented by their un-shifted values. In other words, to type an exclamation mark, you need to put "<lshift>11<lshift>". Also note that usually you will type every key twice, once for the key press and once again for the key release.
Save:#
This represents a save that was made in the movie, along with the save number as #. When running the TAS file, it can't save, so it does a XMOUSEMOTION 0 instead. The save number can be useful to quickly find how far you are into your TAS file when you're running it.
Pause:
This is a very useful command that pauses playback when you're running your TAS script. Good for when you want to hone in on a particular section, or want to set up a savestate.
You can also add your own comments to your TAS file, either by starting a line with a colon:
: This is a comment
or by adding a colon to the end of an existing line:
FAdv:4:This is a comment
Step 2: Running and Editing your TAS Script
To run your TAS Script, first you need to download runtasscript.lua and save it in your lua directory. You also need the aforementioned fileio.lua file.
Open runtasscript.lua in a text editor and change the scriptFile variable to be the name of your TAS Script file. Now assemble your game from scratch, then in your Lua window run runtasscript.lua. Wait until it has parsed your TAS Script file, then start JPC-rr running. You'll see it playing the commands listed in your script file.
At some point in time it will desync. To better look at what is causing the desync, throw a Pause: command in somewhere before the desync, then step your movie frame-by-frame. Once you've identified where it's desyncing, you can update your TAS Script file to try and get around the desync. To test your changes, terminate the Lua VM, reassemble your game, and run runtasscript.lua again. Note that it is important that you do it in that order. If you're correct, you will have fixed the desync. If you are wrong, then you'll have to try something else to fix it.
Soon you will get far enough that you don't want to start from the beginning every time. Throw a Pause: command in just before you desync. It will run one frame advance after the Pause: command and then stop. Create a save state, then delete everything from your script file from the start to the next FAdv after the Pause: command you entered (subtract one from that FAdv). Save it as a new TAS Script file (as you'll probably want to keep your old one around). Edit runtasscript.lua to point to your new TAS Script file and save. Then terminate the Lua VM, load your save state, and then re-run runtasscript.lua (again in that order). You should now be able to start running from your save state.
Inserting new commands into a TAS Script file works the same as fixing desyncs, except instead you're now inserting new commands. Type what you want to type, move the mouse how you want to move it, and put frame advances where you want them. Then rerun and see what impacts your changes have.
That's basically it. Let me know if you have any questions, and I'll leave you with two TAS Scripts that run the boot sequence for you. This one skips Config.sys and Autoexec.bat:
at the end
Finally, it only seems to work if TAS files are saved in UNIX format. It doesn't like the line endings in PC format. I'll look into that sometime when I have more time.
I also looked back at some old messages from Ilari. First, JPC-rr 11.2 doesn't work with general MIDI. You have to go with 11.6 or higher for that. That's not a problem if you need to. Use the upgraded 11.2 to create the movie file, then run the movie file on 11.6 or higher to get a dump of the midi audio.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
First things first, definite yes vote. I'll try and see later this week if I can figure out what's going on with the sound. I think I recall you ran into the same problem with your first SQ1 submission as well.
PLANET wrote:
Tho I'm kinda scared of the technical side of TASes, too.
I can understand it, but don't be. We all started as newbies. The most important thing is to pick the right game to start off with. Choose one that doesn't require too much technical knowledge, and don't do one that has already been optimized to death. Most importantly, pick one you know well.
There are many here to help, so post your WIP in the appropriate forum, and people will be happy to offer suggestions.
If you're planning a dos game, JPC-rr is one of the more rough emulators out there, with not nearly as many useful tools as the others. That said, while most well known (and no-so well known) console titles already have TASes, the dos library has barely been touched, giving you a breadth of choice to start from.
I think state 3 is the start of his punching sequence, state 6 is blocking, state 11 is walking backwards, state 14 is walking forwards.
From what I can tell, at the start (state 2) is a 1 in 2 chance of punching (the other is being walking backwards). After a punch, state 5 has a 21 in 100 chance that the bad guy will punch again immediately.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
c-square wrote:
Nice! You know, this has a shot at a Speedy TAS award. At least it should get a nomination.
We've been nominated for Speedy TAS!
Hopefully someone will also nominate this run for Lucky TAS considering how much we all put into completely reverse engineering and the RNG mechanism for optimal use.
Woo hoo! I’m curious what the competition is like. A Lucky TAS nomination would be cool too.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
I can confirm that the only thing random about the buckets is which graphic it uses (dirt or metal garbage). Everything else is the same.
I checked out the enemy robot actions for the 2048 rng loop:
RNG Action
2048 -> Back up
26624 -> Punch
18432 -> Back up
43008 -> Back up
34816 -> Punch
59392 -> Back up
51200 -> Punch
10240 -> Punch
Note that every time a punch lands, it calls another random call for the damage.
Oh, and an interesting thing happens at the robot battle if you set the rng seed to 16384:
Link to video
It's a zero input win!
EDIT: Also interestingly, it seems the space battle at the end has no random calls in it at all.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Looks like the 2048 set gives you two shots at a 2/2 combo (Terminator appears and delay of 2 seconds). You just need to then adjust your starting value to line up one of the combo.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Okay, I think I've found it.
Memory addresses 273824 and 1322400 seem to follow the RNG pattern. Use this code to track the memory values:
wordOld = {}
searchList={273824,1322400}
while true do
a, b = jpcrr.wait_event();
if a == "lock" then
if nowTick ~= jpcrr.clock_time() then
nowTick=jpcrr.clock_time()
for i,v in ipairs(searchList) do
wordValue = jpcrr.read_word(v)
if wordOld[v] == nil or wordOld[v] ~= wordValue then
print("@" .. nowTick .. ": " .. v .. " -> " .. wordValue )
wordOld[v]=wordValue
end
end
end
jpcrr.release_vga();
end
end
Note, because the seed removed the +1 from the calculation, interesting things can happen at certain numbers. Specifically, if the rng seed is 16384, the next seed will also be 16384 (and every seed after that). The rng seed generator also gets stuck on numbers 32768 and 49152. If any of these numbers is advantageous to you, it may be worth starting the game on one of these numbers, as you're guaranteed the seed will never change.
I'm particularly curious what the robot battle would look like with the random number generator stuck on one number that always means you hit for damage on every blow.
Unfortunately it desyncs right on the first screen. Looks like I need to work at getting the same file setup as you first.
EDIT: I have all the files except my resource.cfg is a different size and I don't have default.cfg.
FYI: I'm about 2 seconds improved by the time the Aluminum Mallard finds Phleebhut on the Navigation scanner. Better, but not by alot.
Still, it's nice to see the improvement.
DrD2k9 wrote:
I'm also doing what I can to keep the mouse pointer out of the way of the action (something I didn't do last time). I may have missed a place here or there though.
Use 'j' and 'k' shortcut keys to send the mouse pointer to the bottom-left or bottom-right of the screen. Performs a single frame advance to move it.
Send me a save file and I'll try finding the rng address.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
Great. Is there an easy way to modify C-Square's lua for displaying the random seed that will work with the SCI games?
First we need to figure out the memory address for the seed. I could do that if I could get the game to run in Jpc-rr (which I’ve been unsuccessful so far) and then get a save game file from you.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
I still think you stand a good chance of getting your original run published if you want. You’d just need to calculate how much the missed savings are (0.1 seconds x number of command entries) and then explain that, since splicing in the changes is not possible, redoing the run from scratch is not worth it for a couple seconds saved that are invisible to the viewer.
Take a look at my QFG 2 submission it had known flaws but was accepted even so.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
c-square wrote:
I commend you for your dedication. It may have been acceptable as is, but I understand not wanting to publish a sub-optimal run.
Do you think I should un-cancel it and see what a judge does? I'd be very surprised if one accepted it given the known improvement potential.
Even before that, have you done a quick test to see if what FF says is true? I was just trying the game on DosBox, and clicking on the command box does absolutely nothing.
If you can't get it to work either, then your run is optimal and you can submit it!
Oh, and BTW, the wait for the surveyors to leave is hard set to 30 something (cycles? seconds? both?).
EDIT: The Two Guys' whining is somewhat skipable! This should at least be worth investigating since it's right at the end of the run. Also, I noticed that in the video he shot even before it was locked on and it hit. You could try taking shots before lock on too.
https://www.youtube.com/watch?v=AinqPF6qE2s&t=910
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
And now I'm back to square one on this run. FractalFusion pointed out a faster way to input text commands.
It unfortunately affects every single text input in the run meaning I have to start from scratch. But it also means it could save a significant chunk of time.
EDIT: Radiant, are you interested in helping dig into the RNG some more since I have to start over anyway?
Wow, that sucks. It also means both my QFG TASses are sub-optimal too. But I don’t have the patience or time to redo them at the moment. As you said, even with the emulator improvements, TASsing these is tedious.
I commend you for your dedication. It may have been acceptable as is, but I understand not wanting to publish a sub-optimal run.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
Temp Encode
The last input happens at the text flash just before the black hole of the endgame cut-scene.
Great job! I’m surprised how fast the robot battle was. I wonder if the wait for the surveyors to leave is random. I’ll check when I have a minute. I’m guessing the Two Guys’ text bubbles can’t be skipped.
Are you thinking of hitting the KQ series next?
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Ideally you should be able to do it without any extra screen transitions. Also, the order you buy the orat and undies may make a difference as the sales dude’s animations call random too.
