Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
Also, something for Technickle:
People in this thread are helping you improve your TAS and even made it faster! They're also asking questions so that you can ask them yourself and improve as a TASer.
You don't need to know or have everything be perfect instantly. Just like you, people who helped you tried the game out, taking steps and making mistakes. It's okay to say "I don't know" or "I didn't try that", and we can approach it together and improve.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
I like the idea of tiers being remade in general, as well as the whole entertainment thing.
How the culture is: right now Moon is "the default", so Vault is kind of pejorative: some people on the forum said your run wasn't entertaining, so it gets an ugly black icon and it's listed lower on the site.
However, people that only know TASVideos from the youtube channel don't care. They watch what interests them and entertains them, not what we have decided is entertaining. Some vault runs are some of the most highly watched TASes on the channel.
How does someone feel when they submit their first TAS on the site, and it goes to Vault, which they learn is the dumping ground? How do they feel when they get 2 answers on their thread before judgment, one saying "Sorry, this wasn't entertaining, voting No"?
Runs shouldn't have to be judged on entertainment to have the default tier, or else get a subpar treatment on the site. They should just be runs, without any tiers.
If it gets good or stellar feedback, they get a special badge like Moons/Stars, gets promoted to Newcomer Corner etc.
This way the audience can decide for themselves, and when they come to the site, we can nudge them towards runs that are found to be entertaining, and remove the whole notion of "these TASes are bad, because they aren't 'entertaining, don't watch them.", from the judging process to publication.
Instead of putting people and runs down, let's encourage them to do better. Let's accept whatever they have for us. If it's suboptimal, we'll them they why. If it's not entertaining to us, then let's leave the entertainment to others who will be entertained and move on.
(I didn't read the rest of the thread so some points may already have been made.)
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
X2poet wrote:
Without the second playthrough?
I was doing this one last years. As I know I must complete it just like Ghouls'n Ghost. Then I stopped it at level 2 boss battle with 2 players. I planned how to manipulate the weapon before it and give up to complete it for years. And then I saw this one and surprised.
At first I had the opinion that you would need to complete the second loop for a TAS as well.
Here's what it looks like: https://www.youtube.com/watch?v=Z0uIDbCK5tg (2nd loop gameplay starts at 14:36).
There is no major content difference between the two loops: enemies and stages are the same, but enemies are much faster. The ending between the two loops is the same as well: there is no "true last boss" if you complete the second loop.
Because of this I wasn't motivated to do the second loop, as in my opinion it would make the run drag on and be less entertaining. So I stopped here when I made this run 4 years ago, and since it would have been unsubmittable under the rules back then, I didn't submit it. But the rules have changed so I'm submitting to see if it could be accepted now.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
I've uploaded a verification movie that goes through Ketsui Death Label and unlocks extra mode. The file is 50 min long and syncs on my end but I'd like others to try it out as well:
http://tasvideos.org/userfiles/info/68688106105809099
The movie should stop on a menu with all options unlocked, and "Extra" at the bottom of the menu. Thank you!
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
Bumping because this really needs more views. Using the tool makes DS TASing way less painful in every way, especially touchscreen TASing. Many DS tasers still don't know about it (I showed it to Really_Tall just today.)
Also, the source is available at https://github.com/SuuperW/DeSmuME-Movie-Editor
Here's what it looks like:
The tool is somewhat similar to TAStudio. It allows non-linear editing, and branches.
Most of all, it doens't restrict traditional TASing: you can use it alongside, using its features when needed.
You can jump to and edit any frame of the movie, and it reloads instantly. (No more Read+Write to edit a mistake 3 frames prior!)
You can edit stylus coordinates with granular precision and modify them from their old states. (No more manual stylus TASing or AutoHotKey scripts!)
You can do bulk editing and even insert new frames in bulk.
The movie editor also features something similar to branches, called parts. You can take any segment of the currently edited movie and keep it in memory. This creates a partial input. This can be then saved to disk, reloaded later on, and even inserted into the movie at a different frame point.
Parts allow for a workflow similar to TASeditor branches, starting many parts from a starting frame to compare different strategies, for instance.
But they also allow easy splicing. There is no limit on a part length: it can be used to capture entire long segments of a movie. This means you can do certain segments independently of each other and splice them all together at the end, or while developping a TAS to copy-paste common parts.
The movie editor warns for most desyncs, however you should keep an eye out for them.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
Great TAS, impresses at every turn. It has been great to see the progress over the months come to fruition, and it definitely shows your TAS skills, WarHippy. Yes vote.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
It has been a good three months since this project was started, with three TASers on it, although we have been mostly working in secret since we started.
Currently, about 80% of the game is TASed - 83 out of 108 (bonus levels nonwithstanding). We track all known records (be they human or tool-assisted) and have as such beaten them on these 83 individual levels.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
Utilise une MV (VirtualBox) avec accélération physique. Sauf si tu as un ordinateur vieux de 10 ans, ca tournera. Enlève la connection internet sur la MV si tu veux pas d'activité réseau inutile.
Je recommende BizHawk aussi, il est supérieur à Gens car l'émulation est plus fidèle et tu as beaucoup plus de fonctionalités (ne serait-ce que pour utiliser TAStudio qui est un moyen plus rapide de faire des TAS).
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
I have a game that has unlockable content in form of stages. You start with one stage, and each time you finish a stage, the credits roll and another stage is unlocked, with one exception. There is no end point defined by the game, as each credit roll is the same, even on the final unlocked stage.
However, unlocking the last stage normally has a ~20 minute cost and is really repetitive, since it would be adding 20 minutes of boring content to a ~15-20 minute run. I can use a completed save file to skip this unlock, and using one gives no other advantages gameplay-wise (it makes the game load a few frames faster, which is irrelevant).
Two questions:
- Is an acceptable end point beating all stages (as in, all new content) of the game and ending the movie on the last credits?
- Is it allowed to use SRAM in the way described above, to skip a long unlocking process that makes my TAS less entertaining?
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
Mainline/upstream DeSmuME has had the ability to upscale games for a while now, which is remniscent of the old X432R japanese build. Since DeSmuME hasn't had an official release in three years, here's r5447 by feos:
https://sourceforge.net/projects/feos-tas/files/DeSmuME-HiResAVI.7z/download
The main appeal of this build in comparaison to X432R, is that you can actually take screenshots and record AVI at the upscaled resolution, something that X432R was unable to do. The upscaling very largely benefits 3D games, making possible encodes like this:
Link to video
Sync is not guaranteed between 0.9.11 and r5447, be careful!
To enable upscaling, go to Config > 3D Settings, then change the HD prescaling box to 4. This will give you a resolution of 1024*768.
Here's a simple way to encode it (and how I did the above encode):
Use Spike's second avs script. This allows you to hit 1080p60fps without the PointResize at the last line. With the PointResize, you can hit higher resolution, though encode times will become much longer.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
Well, suddently a lot of people got interested in TASing for this game. Silverbawxer did the below:
Link to video
Here's a few more observations based on my speed script.
- Every frame that the ape spends in the air, he will gain a specific amount of negative Y speed due to "gravity". There is no reasonable cap to this speed, like for X and Z speed (except the cap of a 32-bit integer). I'll call this gravity: a gravity of 10 means that the ape gets negative 10 Y speed each frame. Speed values here are the teal values on my script.
At base value (without any input) it is 10 gravity, meaning the ape gains 10 negative Y speed each frame, or gets substracted 10 y speed from his Y value each frame to word it differently. What's interesting is that doing inputs actually changes this gravity. In particular, exact center input will still apply -10 gravity, but the farther you get from the center, the lower gravity gets!
By deduction we know how boosting works now:
* When falling into a level, we bounce due to being dropped from an elevated position. This puts us in the air.
* We accelerate faster in the air than on the ground. Accelerating faster gives us more speed.
* We deduce that the longer we stay in the air, the more speed we get. Put in another way, we want to stay in the air for as much frames as we possibly can; worded differently, we want to get as much air time as possible, while still going in the right direction (it is no use for speed it doens't direct us towards our goals).
* We can influence gravity and make it lower.
* Lesser gravity means the ape's Y speed is reduced less each frame.
* If the ape's Y speed is reduced less each frame, then we stay in the air longer, because the effect of gravity isn't as important.
We now know that we can get more air time than usual. But remember our goals; we want the most speed.
* Gravity is the smallest in inputs that are the furtherest away from the center of the touchpad: these are up-left, up-right, down-left and down-right.
* Reducing gravity makes our bounce take more time, thus we gain more air time, thus we gain more speed.
We now know that the objectively best inputs for speed, and speed alone, are up-left, up-right, down-left and down-right when boosting. But we want to be going in the right direction. Indeed, if we get most speed by going up-right solely while boosting, then the ape ends up being angled further away from where we want to go.. in most cases. This is where it starts becoming situational. But, given that we drop and that the target is in a straight line in front of where the ape is facing:
* Going up-right and up-left gives us the most speed but skews our angle. This means it gives us more overall speed, but less effective speed towards the direction we actually want to.
* We have a way to redirect speed, which is called turning. By holding up-left or up-right, the ape turns to the left or to the right.
How to resolve this situation? It seems in this case, that holding up-right to get air time gives less effective speed even though it gets more speed. We need a way to redirect speed, which also does not compromise on getting gravity as low as possible.
The answer is to apply this by first going up-left, then, while the ape is still in the air, turn to up-right. So we both keep the benefits of changing gravity AND get to change the ape's angle at the same time! Perfect.
And this is how boosting works. So, this movement which looked really unintuitive at first glance: going up right then up left or vice versa, is very logical when you look at it. The question that should follow is when do we swap back to the opposite direction? It depends. And this is a direct tradeoff: the more we wait before doing the swap, the more speed we get, but at the cost of a worse angle. This should be rigorously kept in mind when optimising initial boosting.
The last thing is that changing direction slows up down in the air. I have an idea of why this happens but I can't advance anything for now. We can do exactly one direction swap during a boost and still get the maximal air time, any more and you lose 1 or more frames of air time (very very bad.)
- In the same line of thought, what happens if the situation is reversed? What if we want to fall as fast as possible? Then the answer is simple, make gravity max by inputting dead center. Of course, if you have to move then this becomes suboptimal, but in cases where it's almost or just a straight fall using this is crucial.
Note that doing no input and doing center input have the same effect, it sets gravity to 10. However, switching from input to no input takes time and wastes speed, while switching from input to center input does not waste speed because the change is instant. I haven't figured out why this happens either.
- Probably, some other SMB1/2 TAS tricks work like air boosting, need to be looked at in detail.
Sure! Here's a movie that beats WR by a frame: http://tasvideos.org/userfiles/info/49089997547856064Link to video
5265 rerecords
Here's a slightly updated lua script (I will probably set up a repo for it because this is not the best source control): http://tasvideos.org/userfiles/info/49090278993160476
It now shows position in white, position derivatives in green (how much the position changed last frame) as well as the game's X, Y and Z speed values in teal. The last value is the total speed.
There are a few observations I've made that seem to confirm my initial hypotheses, so I'll write them down here. As expected, TASing this game is not trivial and there are a lot of hidden delicaties.
Before that, I'll talk about optimisation boundaries. This is something that emerges naturally when TASing pretty much anything, and applies to any game. What I mean by boundaries is "what goal you want to optimise". If we're TASing a simple platformer, then our optimisation boundary is go right as fast as possible. So, if we TAS two different "routes", end both at the same frame (ideally a well defined end point), and see that on one of these routes our character is farther right in the first route, then we can say that the first route is unequivocally faster. Rarely are things this simple in any game, though. I call these boundaries because they mark easy to divide sections of a TAS.
In this game our principal boundary is to get to the goal as fast as possible. This boundary is position gated; this means that if we're even 0.01 X units off the goal, then we lost a frame, so we need to agressively optimise for position. To accomplish this we want as much speed as possible, because if we gain more speed we travel faster and thus get closer to the goal. We also want this speed to be aimed towards the goal.
In cases going directly to the goal isn't possible, or there is another route that would let us gain more speed and thus reach the goal faster, then we take a detour. The biggest way to gain speed in this game is to get in the air, so we will seek detours that let us gain as much air time as we can.
Let's take a more concrete example. In this level, we start in an elevated position. There is a slope we can get air time off, compared to if we went straight to the goal. This slope gives us enough speed that reaching the goal is faster with it. There is also a corner we can get air speed out of at the end that
we'ill be using.
So, here are our boundaries:
- Fall off the starting platform as fast as possible.
- Hit the ramp and get a bunch of air time. This is more important; we will neglect the first boundary if it means we can hit the ramp with a better angle and get more speed out of it, even if we fall off slower.
- Go straight to the corner.
- Get a bunch of air time out of the corner and go straight to the goal.
We can't judge accurately how important each of these are compared to another; should we spend some extra frames on the starting platform to get more speed off the ramp? Only testing tells us this. Once these boundaries are acknowledged, then we find the best input (and this creates a lot of other things we must optimise as well in order to fulfill these boundaries).
- Optimal movement. Here's a slight correction regarding my earlier post. While in the air, diagonal input is optimal (up-left or up right); while on the ground, up input (127, 0) is optimal.
- Boosting. At the start of the level, the ape falls from the sky and bounces twice. This is free air time, so we can use it by going diagonally. Swapping input instantly (going from up-right to up-left input) wastes some speed, but it's needed because we would not get a good angle otherwhise, so the later we do it, the more speed we get out of the boost. Boosting right then left is always faster, but by a minuscule amount, so always boost right then left in symetrical levels.
- 2-frame gap. This is a really wierd thing that I don't fully understand yet. In certain situations, such as when taking a sharp turn or just before doing a collision, there are two frames where altering the input only alters two of the speed values and not three. In these situations, the optimal input becomes much different. You can see an example in this run at emulator frame 1150 to 1152 (where I hold up-right to abuse this).
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
(If you are wondering how to hide the top bar like I did here, Tools > View Layer > uncheck Main OBJ)
This took a bit of time to do due to some DeSmuME quirks, but here is an initial lua script for this game, which should be pretty easy to understand if you look at the script: http://tasvideos.org/userfiles/info/49023977547981422
I included the adresses for X, Y, Z position and speed, as well as a time counter; the number in square brackets being the number of frames before the next second. It will work on every level.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
The DS uses fixed-point numbers for floats with the Q number format, with the sign value stored in m.
DeSmuME supports reading and writing to these, but there are two issues:
- 0.9.9 only allows for Q20.12 formatted numbers, and not for other values of m or n.
- Looking at the DeSmuME lua documentation, there is no function to read these floats, which is sure inconvenient for making a script.
Either I hacked in something and backported it to 0.9.9, or used something on the lua side. I chose the latter, but nobody had written something for this, so I wrote it myself: here is the code I used (sorry, it's a bit messy.) Assumes Lua 5.1.
Download qlib.lua
Language: lua
-- Simple binary packing function
-- To unpack, tonumber(num, 2)
function toBits(num,bits)
-- returns a table of bits, most significant first.
bits = bits or math.max(1, select(2, math.frexp(num)))
local t = {} -- will contain the bits
for b = bits, 1, -1 do
t[b] = math.fmod(num, 2)
num = math.floor((num - t[b]) / 2)
end
return table.concat(t)
end
-- https://en.wikipedia.org/wiki/Q_(number_format)#Characteristics
-- Here, the sign bit is included in m, because n+m = 32, which is equal to
-- the length of the DS adress bus
-- Unpacking function
local function Q(number, m, n)
local max = m+n
local packed = toBits(number, 32)
local sign = tonumber(string.sub(packed, 1, 1))
-- If the number is signed: NOT the number, add 1 (one's complement)
if sign == 1 then
packed = toBits(bit.bnot(tonumber(packed,2))+1,32)
end
local integer = tonumber(string.sub(packed, 2, m),2) -- As usual, Lua indexes start at 1..
local fractional = (tonumber(string.sub(packed, m+1, max), 2))/(2^n)
local total = integer + fractional
if sign == 1 then
total = total * -1
end
return total
end
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
Link to videoMovie file
1-02 -1f vs human WR
1772 rerecords
For frame comparaisons, use adress 0x021FBA20 (2 byte).
Speed (4 byte) is available at 0x20DDBAC and 0x20DDBF4, both adresses being the same. Divide it by 65536 to get the displayed speed. (For example, a speed value of 3478176 is equal to 3478176 / 65536 = 53 speed.) Note that speed is 1 frame behind the actual speed counter, located at 0x021FBA24 (2 byte).
Other main relevant adresses like x, y, and z speed as well as position are dynamically allocated and change each level. Both position and speed are floating point; you can get these in RAM watch by setting the data type of these adresses to Fixed Point 20.12. You need to divide speed values by 10^3 to get equal magnitude for both position and speed; for some reason, speed values are 10^3 bigger than position ones when set to floating point.
To get the norm of the speed vector, use √(vx²+vy²+vz²) with vx, vy and vz as the values of each speed adress for X, Y and Z.
I haven't figured out yet what the relation between these values and the speed value itself is. I was thinking it corresponded to the above formula, but that's apparently not it. Either it's a mistake in my reasoning, or the speed value uses a different way to calculate speed.
To see what I mean in more detail: use this RAM watch along with the movie file above, and play until 1-02, then play with the adresses. Because most of the adresses are dynamically allocated, these will only work on 1-02 and I don't have any pointers yet. I'm making a script to display all this info in a TAS-friendly way.
Onto the level. Most of it is just movement optimisation. There are three things I'd like to explain in detail:
- Initial boosting. As already known, boosting is done by holding up-right then up-left, or up-left then up-right. The reason it works is because air acceleration is faster when holding diagonally. When doing any movement input, it both moves the level and the ball. So, even when the ape is in the air, doing different input will change its direction, even though the ape is not touching with the level in any way.
What is the optimal boost? First of all, boosting right then left is always faster on all my tests (most likely due to floating point imprecision, but don't quote me on this). Second, changing direction, here meaning going from up right to up left, kills speed. So, the longer up right is held before switching direction, the more speed the ape gets. Of course, holding up right has the downside of also rotating the ape's angle.
So, if you hold up right for more frames, you get more speed, but at the cost of a "worse", meaning oriented more to the right, angle. This is detrimental if you want to go forward. Bottom line, you always need to boost right then left, but the number of frames to boost right depends.
- Collision. It seems (speculation for now) that there are only a few types of collision. In this level, I avoid all "large" collisions which make the ape make a loud soud and instead go for "medium" one which make Aiai make a less loud sound, when forced to collide with the track. At a high speed, you are supposed to always get these large collisions, yet I manage to get medium ones on the three turns (how exactly this happens is unknown for now.) If you wish to see an example of medium vs large, change the input in this level starting at 56:00, when the ape is about to collide with the turn. If we hold up right for even a tiny bit longer, then we get a large collision which knocks the ape back further than a medium one. (Only netting medium collisions can get this 52:81 time.)
- Optimal movement. When having to turn, hold up left or up right. When in the air, up. When on the ground and having to go straight, hold up (127, 0 stylus coordinates).
Every single area of the touchpad is a valid input, leading to 256*193 = 49408 valid different inputs per frame, and each of them give the ape a different speed. In situations where I have to optimise a turn, I have 256 inputs to test for the turning frame.
An example of this: say we have to switch from holding up right to up left to make a turn. If we hold up-right then up left on frame 2, we hit a wall. If we hold up-right until frame 2 then up left on frame 3, we make the turn without hitting the wall. So we are forced to hold up right on frame 1, but maybe holding up right (the extreme input) in frame 2 will overshoot the wall a bit. Instead, start doing inputs that get closer and closer to up left on frame 2. If we hit the wall, the next input goes a little farther up right; if we don't, a little farther up left. Bisecting inputs like this, we eventually find the optimal input for the turn. (This is why you see inputs that are not up left or up right in this movie.)
This is a lot of text, so please do ask if clarification is needed.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
This TAS is impressive for a relatively low time worked on it. Some levels are not optimised at all (which I can understand if your point of reference was the first 10 worlds TAS) but there are other which are surprising. The best one was certainly Backslide, congratulations on getting that collision.
It beats both WRs and previous TASes combined on 19 levels (6 ties, 13 WRs beaten). Out of the 110 levels currently TASed, humans or other TASes beat your TAS on 91 levels.
I have put up a sheet of your times vs. previous TASes and human WRs: https://docs.google.com/spreadsheets/d/1Id58dEgl1iDiBxiaIkdcbS6_tRskOM9XUItfy84xPMs/edit?usp=sharing
A yellow time means TAS wins, an green time means human win, and orange means a tie. I've linked to my TASes as well as other TASes for reference (only if they beat either human times or your times.) If you wish to try them out in the emulator, the movie files for all my TASes should be linked.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
MUGG wrote:
xy2, thanks for your post. Did you research the game or have you been playing on skribbl.io independently?
I researched the game following your post. I played for a while (if you saw someone named God, that was me) to get how the game itself worked and its rules, then did a bit of 'RE' (the code isn't obfuscated, so not a lot of RE) to confirm what Warp said. Once you have a grasp on how the game works and how it's made, then it becomes much easier.
However, I had no experience in JS before this (quickly learned the syntax at learn x in y minutes and looked up whatever I needed afterwards.) So it is a very surface approach and I recognize my un-skilledness; you should dive deeper yourself if you want concrete, unquestionable answers.
MUGG wrote:
There is no limit to the number of guesses you can make.
I think I once saw someone get kicked after they spammed in the chat, so I'm not sure.
From what I saw, you could make around ~100 guesses in a round pretty easily. I never saw someone getting kicked, even when spamming answers myself, so something to look into.
Editor, Experienced Forum User, Published Author, Experienced player
(817)
Joined: 5/2/2015
Posts: 671
Location: France
Wow, I totally missed this post, my bad. Yes, the TAS is not in developpement, I just do some ILs whenever I feel like. Had been busy with other projects, other TASes and school most of the time.
You have encountered the final world unlock problem. My plan for it was to just start with a SRAM-anchored movie with all 12 worlds unlocked and do all the worlds like the other SMB runs, because honestly this restriction is stupid - I don't want to watch more than 15 minutes of banana grinding in the middle of an otherwise fast paced run.
One good thing is that the game has no RNG as far as I saw during my attempts. So this is why I only TASed individual levels, and then when doing the final run, all that would have to be done is to simply stitch them up using hex editing, and you'd have a full run. If an improvement was found, no need to restart the whole run, just edit the ILs. This is also why the movie file is available for each level, so that would I be unable to finish a TAS of this game (which is what happened) others could just copy paste and then try to improve my input if possible.
Could you post your current TAS on userfiles, along with tools/scripts/etc you used? I would be interested in taking a look at this.
The tool is somewhat similar to TAStudio. It allows non-linear editing, and branches.
Most of all, it doens't restrict traditional TASing: you can use it alongside, using its features when needed.
You can jump to and edit any frame of the movie, and it reloads instantly. (No more Read+Write to edit a mistake 3 frames prior!)
You can edit stylus coordinates with granular precision and modify them from their old states. (No more manual stylus TASing or AutoHotKey scripts!)
You can do bulk editing and even insert new frames in bulk.
The movie editor also features something similar to branches, called parts. You can take any segment of the currently edited movie and keep it in memory. This creates a partial input. This can be then saved to disk, reloaded later on, and even inserted into the movie at a different frame point.
Parts allow for a workflow similar to TASeditor branches, starting many parts from a starting frame to compare different strategies, for instance.
But they also allow easy splicing. There is no limit on a part length: it can be used to capture entire long segments of a movie. This means you can do certain segments independently of each other and splice them all together at the end, or while developping a TAS to copy-paste common parts.
The movie editor warns for most desyncs, however you should keep an eye out for them.
Here's a simple way to encode it (and how I did the above encode):
Use Spike's second avs script. This allows you to hit 1080p60fps without the PointResize at the last line. With the PointResize, you can hit higher resolution, though encode times will become much longer.
(If you are wondering how to hide the top bar like I did here, Tools > View Layer > uncheck Main OBJ)
This took a bit of time to do due to some DeSmuME quirks, but here is an initial lua script for this game, which should be pretty easy to understand if you look at the script: http://tasvideos.org/userfiles/info/49023977547981422
I included the adresses for X, Y, Z position and speed, as well as a time counter; the number in square brackets being the number of frames before the next second. It will work on every level.
