Elasto Mania 100% tas in 09:54,58 by bene, Zweq, FinMan
Link to run:
https://www.youtube.com/watch?v=IocsDW2KLEs
Link to short video of tricks:
https://www.youtube.com/watch?v=YRKq37rHOVc
General
* This run is not made according to tasvideos.org rules and can't be published on this site, however I thought some still might be interested in viewing the results.
* Individual runs are made in levels and cut together using video editing to make the full video, there is no tasing for the menu but I recorded it and added it to the final video.
* In game timing is used, elma generates a stats.txt file when you exit that contains total time. The game truncates finished times so 13.979 counts as 13.97.
* The run is made in eol, unoffical version of elma.
* The run is not made using hourglass, the tools are the ones developed by the elma community especially for elma. This tool includes mid run fps switching which is by far the most important feature.
* There are no limits for bugs as discussed earlier in this topic.
* The game is limited at 30-1000 fps. This is the limit that was decided once the fps limiter was introduced to the elma community in unoffical patches. In vanilla versions of elma you had to limit fps using vsync. The 30 fps limit might be controversial as the game breaks even more under 30 fps. But I don't know if the original elma or eol can even go under 30 fps.
Apple bug, hooked bug
If you take an apple with both wheels in a single frame it will count as two apples, allowing you to skip apples. You can also do this with the head and a wheel.
Theoretically you can grab an apple with both wheels and the head for it to count 3 times. I have not found a sane setup to do this anywhere.
Apple bugs are generally not that useful and used in a few levels only.
Clipping
Only the surface of the polygon counts as collision ground, so you can clip into a polygon and drive around on the inside. There is however a limit on how far outside the level you can drive, a crash will occur if you move too far out of bounds.
A wheelclip will occur if the wheel travels past the center point in a single frame. Wheel clips can never occur if the wheel is touching the polygon.
Headclips require the entire distance of the head to be traveled in a single frame, since the heads position changes instantly from one frame to the next when you change direction of the bike it is possible to clip at relatively low speeds using a frame perfect turn. Approx 1/3 of the speed is required to clip with the turn.
Bugpop
In the physics engine there is a division between the distance of the center of the bike and the wheels. When the distance approaches zero the wheel pops (moves instantly to another position far away in 1 frame).
The result of this calculation is multiplied by the timestep, so lower fps causes bigger pop. If the direction of the pop is (x,y) when braking on the frame with lowest min distance it will be (-x,-y) if gassing. Doing neither will not cause a pop.
This is the main trick used to start bugging. However when the bike is stretched (wheel is far from bike) the physics behave differently. If you play at high fps for too long the wheel will unstretch and bug stops. If you play at low fps for too long(around 0.10s, depending on how big the stretch is) you crash the game.
When you go from low fps to high fps you cause more stretch of the wheel(s). So you want to play at low fps for a few frames and then go back to high fps to keep stretch big enough for continued bugging and to prevent crashes.
You can not do this trick again during bugging as it requires you to stop bugging and drive normally for a while to compress wheel to center of bike.
Bugbounce
A bugbounce is a special case of a bugpop. It happens if the pop causes the wheel to clip the polygon surface you are touching. Since it is impossible for the wheels to clip a surface they touch, the pop that is orthogonal to the surface gets removed. All the energy from the removed pop gets transferred to the bike in form of speed.
So a pure bugbounce has a pop perfectly orthogonal to the surface and only adds speed, the pop is never visible. Bugbounces alone are rarely useful as you only gain speed, in combination with a bugpop it can be useful as you gain initial speed.
Stretch bugbounce
It is because of stretch bugbounces that pure bugbounces and apple bugs are rarely useful. A stretch bugbounce is caused by your wheel coming in contact with a surface during big stretch.
This bounce causes the bike to gain speed in the direction orthogonal to the surface. It doesn't always work, like sometimes only wheels stretch and you get 0 speed on the bike and sometimes you get speed that crashes the game.
When stretch bugbounces was found a whole new way of playing opened up. It was now possible to build insane speeds and do clips anywhere and then afterwards slow down and start driving normally like nothing happened.
Previous runs had slower speed bugbounces that was possible to brake without dying or just a single bugbounce that aimed for the flower in a straight line (int16 start, int02, int19, int29).
There is no way to control the wheels enough during big stretches to get apple bugs and driving normally without stretch bugbounces is very slow. This is why apple bugs are not useful.
General explanation of how runs work
The physics during bug playing is very different to that during non bug playing and was quite tedious to explore. Frequent crashes and having to reset the game cost much time.
There are 2 different crashes that occur: one is going too far out of bounds and the other I have no idea about, both are usually caused by the same thing - low fps for too many frames. Going out of bounds was annoying in some levels when I wanted to exit the level to swing around and couldn't leave the level because of out of bounds crashing.
In the beginning I played short bugs for several hours until I got the bug I wanted, for example the first clip bug in int35 is 1 second long and took 7 hours to drive and I had no idea it was even possible when I started trying.
After a while i realized that stretch bounces existed. Not only does this explain why int35 first clip works, suddenly there is a whole new way of playing opening up.
Int35 first clip works because while clipping with the head using low fps frames the wheels touch the oversides of the polygons causing the bike to brake more than normally, because this added speed in the opposite direction the bike was traveling.
Right after initial bugpop the wheel is rarely near a surface where I want to gain speed so low fps frames are combined with high fps frames to keep stretch and change position of wheel. Then once wheel touches the correct surface change to low fps and gain much speed.
Playing at 50-150 fps for a few frames during big stretch can add really weird frames that change wheels position, bikes rotation and stuff which helps reposition wheel.
Once speed is built up in the wanted direction using stretch bugbounces I stay at high fps until wheels are near polygons, then switch back to low fps to clip with wheels so you don't change speed.
Sometimes low fps frames are added mid air to slightly change rotation, add spin or increase stretch, if speed and/or rotation is good there can be many high fps frames without unstretching too much.
When I get close to apples or the flower I use 50-150 fps weird frames to change positions so wheel/head grabs apple/flower. Sometimes it is really easy to reach sometimes really hard. It is all determined by randomness.
Since eol is not constant fps there are many combinations possible running fps limiter at 100 fps and using different moves for a few frames, so just because 100 fps didn't work the first 20 times there is always a reason to try again.
When the level is a straight line to finish it is easier cause there is never any change of initial speed you built up, for example int37,int38.
Stopping or changing direction of the speed you built up is quite hard and might require multiple wheeltouches on polygons to slow down, for example int31,int46.
Closing comments
Going forward with elma tasing I would really like to see a 1000 fps only tas with no bugpops. But we currently have no way of verifying if bugpop occurred. Although it might be a bit strange since some of the current non tas world records might be impossible to beat. I have no plans to make a 1000 fps only tas.
For bug elma tasing there are many improvements that can be made with better tools, I did most of the playing during bug parts and my hand hurts from spamming the pause button to add low fps frames without crashing because there is no frame advance while playing.
Brute force to help finish a level by playing a few frames might prove very useful as well. For example you could in theory finish near int02 instantly after bug, just do opposite input (brake instead of gas) and wheel pops towards flower, but its not sane to try this without tools.
Thanks to Lee for creating splash screen background.
Thanks to anpe for being most awesom man on eol wordl.
Thanks to striker for creating spreadsheet with statistics.