Posts for bene

Experienced Forum User
Joined: 11/18/2015
Posts: 13
Not a tas but a compilation of all current world record replays will be released soon. There has been many recent records driven and the total time has been pushed down quite a lot after many years of inactivity. Here's the announcement copied from our discord: The first Across Done Quick video is taking place some days before edq (12th July at 18:00). Link to video
Experienced Forum User
Joined: 11/18/2015
Posts: 13
Here is the link for the EDQ premiere Link to video
Experienced Forum User
Joined: 11/18/2015
Posts: 13
CoolHandMike wrote:
Well right now tasvideos is on its way to allowing more types of runs. Specifically Showcase type submissions and this could possibly qualify. I personally would love for that type of crazy tool driven gameplay to be accepted. Maybe someone that knows more of that process could comment on this?
The problem we have now is that there is a division by the distance of the wheel and the center of the bike and if this approaches 0 things go crazy. If this is allowed in play (Especially along changing physics fps) any video is finding the fastest way to make this happen and the rest is just brute force to find physics fps that works to finish the level (One frame per apple and one frame to get the flower after getting the bug). Making everything finishable in less than a couple of seconds easily, even without brute forcing, you can after getting the bug just do anything you want without much effort, it just takes a few hours to do stuff and it's a couple of seconds longer video. So in the community we have this home made div 0 check along with the not in use physics frame rate check to make it competetive and nice. The div 0 thing is the hardest problem to solve for this, it's mostly just someone looking at the run and giving it thumbs up or down based on how they feel today.
Experienced Forum User
Joined: 11/18/2015
Posts: 13
And at this time we are somewhere in between everything. We don't use the created tooling to verify runs and players can change physics fps as they please but it's not fun to play so no one does anything. The impressive stuff we have, like limpsy05, is just players not abusing possibility to change physics fps at any time. If you allow and use that you can finish the level in under 10 seconds with an hour of effort compared to this magic that took months of work.
Experienced Forum User
Joined: 11/18/2015
Posts: 13
moozooh wrote:
bene wrote:
Two of the best players in the world get together to try out new tooling and at the same time achieve something impossible.
Can you give a breakdown of the tooling used these days? I think it shouldn't be a big problem in principle to have Elma TASes accepted here.
Two tools are mainly used. The most recent one is "okesl" which is a completely home made program based on reverse engineered physics. So way back, someone reverse engineered all the physics to have their level editor be able to play levels and this circled around privately and finally reached someone that made a collection of cheat tools. The other tool is an edit from the person that made elma online. And this is a bit more shrouded in mystery but it's a small change to the dll that enables online play. Okesl is by far superior of the two in terms of sophistication but the minute fps difference compared to regular play makes the other one way better for practicing live world records. The difference is how the game behaves at small <1 fps differences between frames and doesn't matter at all for regular play or at higher framerates but it being different for a low fps run changes everything How we tune the game now is to limit the physics fps to some value and the intricate details of this changes everything. We don't set it to constantly be 30fps and it's just limited to 30fps and fluctuates around 30fps. The creator of okesl made a tool that could be used to verify runs using the recorded inputs and reverse engineered physics. And the most important thing to verify would be that we don't allow changing physics fps in the middle of the run. All modern cheat tools allow changing the fps at any time, and technically it could happen in a real run as well, but due to how differently the game plays at various frame rates the most sensible option, to keep competitive, would be to disallow changing fps in the middle of a run. It's just not fun to compete when allowing changing fps in the middle of the run. So being accepted here is a bit strange, If you have the same rules that are for any other game it just causes bugged mayhem that no one likes playing or watching, like the video I showed a few years ago. And enforcing a different set of rules requires specific tools to verify the runs. Also we have some additional rules to work around the division by zero problem that "are good enough" but they just don't work for tasvideos rules :)
Experienced Forum User
Joined: 11/18/2015
Posts: 13
The community has grown and learned a lot in the years since the last EDQ. This limpsy05 replay, although being a couple of years old, is in my opinion the peak of everything though. Two of the best players in the world get together to try out new tooling and at the same time achieve something impossible. If you know the game enough to enjoy this video you can look forward to the premiere that will be on the same channel compiling all the individual level records of the original levels to a single video :bear: The reason this is unique is because the community does not enforce showing video of a run being performed and a single person is responsible for keeping the table updated and verifying runs. A lot of the individual level records being shown have never before been seen in public.
Experienced Forum User
Joined: 11/18/2015
Posts: 13
moozooh wrote:
bene wrote:
moozooh wrote:
Also, a bit of a tangent, but are there any plans for a new Elma Done Quick?
A couple of years later but finally there are news about this. After more than a decade since the last video it's happening again. The world premiere is planned for 15th July at 10pm Finnish time.
Omg, that's awesome! Can't wait.
I can highly recommend this beautiful piece of TAS to make the wait easier. This is limpsy05, a level made as a joke and supposed to be impossible, finished (Start at 8:17): Link to video
Experienced Forum User
Joined: 11/18/2015
Posts: 13
moozooh wrote:
Also, a bit of a tangent, but are there any plans for a new Elma Done Quick?
A couple of years later but finally there are news about this. After more than a decade since the last video it's happening again. The world premiere is planned for 15th July at 10pm Finnish time.
Experienced Forum User
Joined: 11/18/2015
Posts: 13
bene wrote:
For example in warm up the best known non bugpop tas time without changing fps is 13,94 while it is 13,81 using 1000 fps for the first few seconds and 30 fps for the rest of the level.
The secret project for the Finnish elma meeting 2018 was revealing the newest tricks and TAS of warm up. We did this in the form of a world record progression video for warm up mixing cheated, tool assisted and live runs. The best TAS without changing fps mid run is now 12.99. The time should be improvable by a bit. We stopped playing after getting 12.99 because it was the target. It's almost a second faster than the previous record of 13.94. No one is playing fps change TAS these days and the TAS record with fps change was 13.45. There are also some bonus TASes of other levels during the end credits. Link to video
Experienced Forum User
Joined: 11/18/2015
Posts: 13
Another update from the TAS elma scene! bene and Zweq teamed up and played Labyrinth pro for a year with a target time of under 2 minutes. The replay was a surprise for the Finnish Elma Meeting that just happened last week and was shown there. The time we ended up with was 1:55,48. The old record was 2:06,05 and can be seen here http://www.recsource.tv/r/nfeqgusbdj Link to video
Experienced Forum User
Joined: 11/18/2015
Posts: 13
moozooh wrote:
Also, a bit of a tangent, but are there any plans for a new Elma Done Quick?
Madness, our local tas wr table updater just uploaded a trailer for the tas version of EDQ (Which would be the non bubgpop non funny stretchbug category opposite of the one featured in my previous video). I have not heard much talk about the full version and don't expect it for a year or two. Link to video You can see the full tas wr table over on our forums http://mopolauta.moposite.com/viewtopic.php?f=2&t=8639
Experienced Forum User
Joined: 11/18/2015
Posts: 13
Optimal constant framerate is really hard to say. 30 fps has always been the fastest option, bike accelerates faster with lower fps there is less delay between volts. However some tricks require different values. For example in warm up the best known non bugpop tas time without changing fps is 13,94 while it is 13,81 using 1000 fps for the first few seconds and 30 fps for the rest of the level. Compared to the wr of 13,97 you can see there is a great benefit to changing fps. These times are with non constant framerate however so randomness occurs because of that. The best time using hourglass is 13,97 with some (just guessing) 800-1000 fps. Personally I think changing fps mid run is silly and something that should not be allowed outside of a special tas category. While others argue that it should be allowed for all cases because it is something that can happen, play at max framerate (not limited in any way) and then computer just lags for 12 seconds so you go to 30 fps and you have optimal framerate for warm up. I did not define any rules or think about how sane the runs were, like hardware limitations. I did everything the tool would allow no questions asked. Currently the tasing scene in elma does not allow bugs but has bugs in the records table because the non tas wrs have bugs. I don't find arbitrary limits enjoyable as you can just increase the speed of your bounce and improve the time and no rules are defined for what is acceptable. My suggestion to a 1000 fps constant framerate tas was because this is the sweet non buggy, non random zone in elma that is enjoyable to play at. So 1000 fps would be the glitchless tas. But maybe 1000 fps can prove to be even more buggy when you start doing inputs at that speed(if possible), it has not been explored afaik. I guess I have adopted the non bug mentality from the elma scene and that is why it interests me. You can achieve high frame rates by turning vsync off, this works in any version of elma. The vsync option is not part of the original game options however. I don't know the default vsync setting for vanilla elma or if there even is one, in eol it is off by default or maybe there is an unofficial setting for it. In short, I don't think there is a way you can ever find the optimal const fps value in this lifetime so it's better to just pick a value and go with that. Bugbounces are possible with every fps and it all depends on the distance and direction of the pop, which is determined by unknowns since no one has examined exactly what happens and explained it. I have had bounces where 1000 fps was a big speed and bounces where 30 fps did almost nothing. Stretch bugs without controlling framerate on the fly would just crash the game, because what is done is you play a few frames leading up to a crash and then change to higher fps to prevent it. Bugbounces would be possible so a constant framerate run would look closer to int02, int16 start, int19 or int35 start. Finding the frame with min distance would be more tedious using constant lower fps, now we abuse on the fly fps changing and search for the frame using 1000 fps, more frames = more chance to find the frame you want. But I guess you could make this automatic with better tools. So a run in int01 at a constant framerate of 60 fps would require a slower start than the 13,81 tas because the bug happens after the 1000 fps is optimal spot, but would use a bug bounce and finish around 8 seconds. It would look almost exactly like this http://www.recsource.tv/r/rciaolfbqx I should mention that crashes are really internal errors caused by various checks in the game. Instead of exiting to menu on non critical errors the programmer decided to always quit the game with an error. I have only had 1 or 2 crashes happen without internal error. There has been little to no discussion about a new EDQ in the community, i think it is far too early to make one now but some say they want a new one when the tt drops below 34:30 instead of below 34:00, which could be fair. Current tt is 34:44 Current non bug tas tt (with arbitrary limit) is 33:34
Experienced Forum User
Joined: 11/18/2015
Posts: 13
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.