Author Message

Xarthok





Joined: 2007-04-02 17:27:49

Posts: 68

Location: Latvia MemberJoined: 2007-04-02 17:27:49Posts: 68Location: Latvia

Posted: 2011-06-12 18:35:49 Post subject: Elasto Mania



As a long time insider of Elasto Mania community I can also confirm that the anticheating team has tools that can tell the difference between replays made legit and replays made with tool assists so the legit records will remain safe.



Assuming a perfect Elasto Mania TAS was to be made... What would be the restrictions bug/glitch wise?



What I mean is that there are several well known bugs within the game that the community don't allow to be abused in any competitions. Some of them are:



- If you touch an apple with both wheels or a wheel and the head at the same time the game will count it as two apples allowing you to skip an apple (or more if abused additional times successfully) to finish the level.

- Sometimes and under certain conditions when pressure is applied to a wheel and brakes are pressed, an abnormally powerful ejection occurs, sending the bike at high speed in some direction.



What else comes to mind:



The game behaves slightly differently at different FPS values. Lower FPS such as 30 allows the bike to spin faster (by unsignificant value but still, useful in level 2) and to possibly pass a wheel through gaps between vertices that are narrower than the width of a wheel (essential in level 27), as well as wheels behaving abnormally when trapped in spaces narrower than themselves. Higher FPS (200+, achieved with vsync turned off) doesn't allow it to happen and improves the grip with the ground and makes performing bounce tricks easier.



Which version of the game would have to be used?



Versions 1.11h and newer are "unofficial" but used by everyone as they contain essential game enhancing configuration options such as binding the "supervolt" move (faster clockwise volting) to one key which normally takes 2 keys to pull off and is much more difficult. The newest unofficial version is 1.3 which is still in public beta and can be found here: I've confirmed that it is currently possible to run it with Hourglass and it runs and syncs normally, besides the bug which jumps over every second selection in menus.As a long time insider of Elasto Mania community I can also confirm that the anticheating team has tools that can tell the difference between replays made legit and replays made with tool assists so the legit records will remain safe.Assuming a perfect Elasto Mania TAS was to be made... What would be the restrictions bug/glitch wise?What I mean is that there are several well known bugs within the game that the community don't allow to be abused in any competitions. Some of them are:- If you touch an apple with both wheels or a wheel and the head at the same time the game will count it as two apples allowing you to skip an apple (or more if abused additional times successfully) to finish the level.- Sometimes and under certain conditions when pressure is applied to a wheel and brakes are pressed, an abnormally powerful ejection occurs, sending the bike at high speed in some direction. http://www.youtube.com/watch?v=BIZcTO9Hwy4 This does not apply to "bounce" boosts that can be reproduced easily and don't give any more speed than the bike had before pressing brakes.What else comes to mind:The game behaves slightly differently at different FPS values. Lower FPS such as 30 allows the bike to spin faster (by unsignificant value but still, useful in level 2) and to possibly pass a wheel through gaps between vertices that are narrower than the width of a wheel (essential in level 27), as well as wheels behaving abnormally when trapped in spaces narrower than themselves. Higher FPS (200+, achieved with vsync turned off) doesn't allow it to happen and improves the grip with the ground and makes performing bounce tricks easier.Which version of the game would have to be used?Versions 1.11h and newer are "unofficial" but used by everyone as they contain essential game enhancing configuration options such as binding the "supervolt" move (faster clockwise volting) to one key which normally takes 2 keys to pull off and is much more difficult. The newest unofficial version is 1.3 which is still in public beta and can be found here: http://beta.elmaonline.net/?s=help and features automated online statistics and multiplayer gameplay and real time battles (short competitions on fresh levels) among other things.

Lex





Joined: 2007-06-25 10:55:38

Posts: 733

Location: Vancouver, British Columbia, Canada Vested memberJoined: 2007-06-25 10:55:38Posts: 733Location: Vancouver, British Columbia, Canada

Posted: 2011-06-12 20:34:11 Post subject: I think since we're not the Elasto Mania community, we can safely ignore the "rules" imposed upon unassisted speed runners. The point of TASvideos is to beat the game as fast as possible, abusing glitches where possible. Skipping apples sounds like an awesome trick I'd love to see in the TAS! The same should be said about the powerful ejection glitch. Both of these glitches would be awesome to see abused to perfection.



I don't know the standard rules about game versions to use. Someone else should chime in here.

Phallosvogel





Joined: 2006-01-03 01:01:02

Posts: 334

Active memberJoined: 2006-01-03 01:01:02Posts: 334

Posted: 2011-06-12 20:34:56 Post subject: Its been years since I left the community. Funny its still around.

Well if I remember correctly, there was a big discussion about a world record for "Enigma" (dont know if its still the current one, been ages since I was on the moposite) if it uses a legit bounce, cause the one used by the player gave him susoicious height. But it got acceoted after all.

My point is, we shouldnt take over the rules of the moposite. SDA once didnt allow out of bound glitches or unexplained warps, while they are more then okay for TASvideos. I think we should push the game to its limits and use all the bugs we can, maybe with TASing tools we could even find new ones. A current world record broken with a bug bounce in a level you wouldnt expect it, man that would blew me away.

Also I guess it would be clearer to the elma community, that we do not want to compete with them in any way if we play by our rules.

I would also reccomend the use of the official version, since hib's patch (or mila's nowadays) would count as a hack kinda. I dont know if there would be synching problems either, if someone used another config in the second exe file. Also by this we would stay true to the game.

If it comes to ingame technics I would have to pass. My best time in the whole game was a 14.20 in Warm Up ;__;

Anyways I would love to see this game taken apart. As I said, I left long ago but I still look for ElMa vids on youtube and sniff through mopolauta once every half year or so.

Xarthok





Joined: 2007-04-02 17:27:49

Posts: 68

Location: Latvia MemberJoined: 2007-04-02 17:27:49Posts: 68Location: Latvia

Posted: 2011-06-12 22:35:56 Post subject: I'm not sure about the "bug" bounces that cause extreme speed as the only times people ever get them are by accident. More than 99% of the time pressing brakes when a wheel is under pressure just cause a regular bounce without any added speed which is easily controllable and reproducable. Bug bounces, however, are not. They happen sometimes and I suppose /can/ happen in any place where sufficient pressure can be applied to a wheel. But nobody knows exact circumstances that would trigger the abnormal boosted speed ejection.



However, I do agree the apple collecting bug could be entertaining to abuse and not that difficult to pull off. It's most commonly encountered in level 53, Hooked. People get times like 14:00 and gotta use a bug time removing software to fix up their stats.



But the bounce bugs are so insanely uncontrollable that I see no way they could be optimally abused in any way besides a few levels like level 30 and for that reason I just don't see it as a realistic goal to aim for because aiming to get an uncontrollable boost from every possible spot to go in a desired direction and a desired speed (not too fast as to make you die but fast enough) and to manage to pick apples with both wheels at the same time while zooming around like that... It's just too much even for tools that we have.

Phallosvogel





Joined: 2006-01-03 01:01:02

Posts: 334

Active memberJoined: 2006-01-03 01:01:02Posts: 334

Posted: 2011-06-12 23:05:54 Post subject: Wouldnt it be possible with Hourglass to watch a replay of a bug bounce in frame advance while using some memory watching software to understand these better?

Lex





Joined: 2007-06-25 10:55:38

Posts: 733

Location: Vancouver, British Columbia, Canada Vested memberJoined: 2007-06-25 10:55:38Posts: 733Location: Vancouver, British Columbia, Canada

Posted: 2011-06-12 23:23:10 Post subject: Yes. This is what debugging is for. I know some people with extensive reversing experience who would be able to figure out how it worked, given a replay in which it occurred. I may not be among those people, but I know it's possible.

moozooh





Joined: 2005-08-04 20:58:59

Posts: 5701

Location: Moscow, Russia Vested EditorJoined: 2005-08-04 20:58:59Posts: 5701Location: Moscow, Russia

Posted: 2011-06-13 02:16:27 Post subject:

_________________

Warp wrote:

Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry. Let's start with abusing all bugs there are and going from there. If it indeed gives too much power we can open up another category with stricter rules.

Patashu ♂





Joined: 2005-10-02 01:39:27

Posts: 3735

Vested memberJoined: 2005-10-02 01:39:27Posts: 3735

Posted: 2011-06-13 09:48:44 Post subject:

_________________

My Chiptune music, made in Famitracker:

My twitch. I stream mostly shmups & rhythm games

My youtube, again shmups and rhythm games and misc stuff: _________________My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu With hourglass can you set the FPS as high as you want? 1000? 10000?

Lex





Joined: 2007-06-25 10:55:38

Posts: 733

Location: Vancouver, British Columbia, Canada Vested memberJoined: 2007-06-25 10:55:38Posts: 733Location: Vancouver, British Columbia, Canada

Posted: 2011-06-13 10:04:47 Post subject: Yes. However, whether the replay syncs at those settings is a different matter.

Xarthok





Joined: 2007-04-02 17:27:49

Posts: 68

Location: Latvia MemberJoined: 2007-04-02 17:27:49Posts: 68Location: Latvia

Posted: 2011-06-13 11:47:12 Post subject: If anybody has any idea how to reverse and understand those bug bounces I have plenty of various replays so message me on IRC.

Ves

Lurker



Joined: 2011-06-13 22:14:30

Posts: 1



Posted: 2011-06-13 22:19:32 Post subject: Xarthok wrote:

I have plenty of various replays so message me on IRC.

Regular .rec-files are nothing but collection of frames and events. Do you have some bug-bounce replays driven with hourglass?

Lex





Joined: 2007-06-25 10:55:38

Posts: 733

Location: Vancouver, British Columbia, Canada Vested memberJoined: 2007-06-25 10:55:38Posts: 733Location: Vancouver, British Columbia, Canada

Posted: 2011-06-13 22:44:05 Post subject: Regular .rec files can be used to reproduce the events. They run in a deterministic manner.



The PC Worms Armageddon developers research in-game logic glitches using its replay files.

MESHUGGAH ⚪

Editor / Expert player (2296)



Joined: 2009-11-14 10:11:11

Posts: 1123

Location: 𝔐𝔞𝔤𝑦𝔞𝔯

Posted: 2011-06-14 08:47:41 Post subject:

Since I don't have Elasto Mania atm, you should try to load the rec file while running via Hourglass and 1st investigate the memory for possible locations of hitbox positions (with subpositions) and dump these at least at the "1 frame before bug bounce", "bug bounce", "1 frame after bug bounce" situations. Btw the video you linked for it looks like a simple ejection to the facing direction because the back tire can't move in to the hill.

Xarthok





Joined: 2007-04-02 17:27:49

Posts: 68

Location: Latvia MemberJoined: 2007-04-02 17:27:49Posts: 68Location: Latvia

Posted: 2011-06-15 00:07:01 Post subject:



The bike is capable of a lot of crazy stuff :P

http://www.youtube.com/watch?v=Dywi1Eo8Rzg

http://www.youtube.com/watch?v=EUevhnTjw20

http://www.youtube.com/watch?v=RxI3G2R5TLg

http://www.youtube.com/watch?v=8xcXaNq9icU



And here is a fantastic documentary made for the 10 year anniversary of the game about the history and development of Elma scene for anyone who might be interested in it:

http://www.youtube.com/watch?v=WhujtzYD0VM



Also, here are some new tool assisted replays made with other non-public tools that significantly improve upon legally driven WRs:



Warm Up 13.84:

Hi Flyer 23.52:

Downhill 39.99:



Some used slightly bugged bounces though. The conditions LOOK the same for both reproducible bounces which don't add any speed but just change the direction of movement and bugged bounces which do unpredictable things. I'm not very familiar with memory value fishing so someone else might find something there much easier.The bike is capable of a lot of crazy stuff :PAnd here is a fantastic documentary made for the 10 year anniversary of the game about the history and development of Elma scene for anyone who might be interested in it:Also, here are some new tool assisted replays made with other non-public tools that significantly improve upon legally driven WRs:Warm Up 13.84: http://www.youtube.com/watch?v=7776Nzb0kw0 Hi Flyer 23.52: http://www.youtube.com/watch?v=izSBT7uo78U Downhill 39.99: http://www.youtube.com/watch?v=tfJ-f6w5t5Y Some used slightly bugged bounces though.

moozooh





Joined: 2005-08-04 20:58:59

Posts: 5701

Location: Moscow, Russia Vested EditorJoined: 2005-08-04 20:58:59Posts: 5701Location: Moscow, Russia

Posted: 2011-06-15 13:42:34 Post subject:

_________________

Warp wrote:

Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry. I haven't taken a look at it yet, but it seems that ejection speed (which mainly qualifies the bounce as bugged) depends on the combination of wheel pressure angle and force exerted upon the surface. The reason why they're so rare is that the combination(s) probably needs to be very precise, probably a round (thus, exact) value. My hypothesis is that while a "normal" bounce is a result of the suspension being highly contracted and exerting its potential energy as kinetic in a short time frame, a bugged bounce is a result of a wheel getting a little inside a polygon surface and being forced out with a fixed (?) speed.

Xarthok





Joined: 2007-04-02 17:27:49

Posts: 68

Location: Latvia MemberJoined: 2007-04-02 17:27:49Posts: 68Location: Latvia

Posted: 2011-06-15 19:09:43 Post subject: But where and from what calculation does the speed come from? Bug bounces can be both just slightly faster than regular bounces or cause a speed that can not survive any impact with an obstacle... Also I've had bug bounce where the bike stays still but one of the wheels ejects itself a huge distance into the air without moving the rest of the bike at all.

upthorn ♂





Joined: 2006-03-24 09:48:50

Posts: 1802

Emulator coder / Experienced player (508)Joined: 2006-03-24 09:48:50Posts: 1802

Posted: 2011-06-16 07:17:31 Post subject:



_________________

How fleeting are all human passions compared with the massive continuity of ducks. If the bug-bounces are, indeed, caused by terrain ejection, it is likely that the resulting speed value comes from the amount of pixel overlap into the terrain.

nitsuja





Joined: 2004-12-21 00:32:54

Posts: 2687

Emulator coder / Skilled player (1370)Joined: 2004-12-21 00:32:54Posts: 2687

Posted: 2011-06-16 08:10:52 Post subject:

Here's my guess based on watching a couple of videos showing this bug: The bike can be thought of as a system of 3 points (one at the center of each wheel and one at the center of the larger bike-and-guy-on-bike compound sprite) that are connected by springs. The spring physics break down somewhat if any 2 of those points become exactly overlapping, resulting in the bug. Maybe what happens is that the game wants to push them away from each other but can't because they're at the same pixel position, so it builds up energy until something else nudges them slightly apart, at which point it applies a huge spring force to one of them which will be greater depending on how long they were overlapping.

Xarthok





Joined: 2007-04-02 17:27:49

Posts: 68

Location: Latvia MemberJoined: 2007-04-02 17:27:49Posts: 68Location: Latvia

Posted: 2011-08-13 01:00:40 Post subject:

Here:



(Link to video)

_________________

This is a block of text that can be added to posts you make. There is a 255 character limit Anyone interested in the game should check out the trailer for the newest version which came out today :)Here:

Bisqwit





Joined: 2004-03-08 11:34:25

Posts: 7452

Location: Arzareth Precursor / Active player (268)Joined: 2004-03-08 11:34:25Posts: 7452Location: Arzareth

Posted: 2011-12-08 20:57:51 Post subject:



Anyone making a TAS at this game? "Legit" world record collage. http://www.youtube.com/watch?v=08mPl4Z9tK0 Anyone making a TAS at this game?

Tompa ♂

Vested Editor / Expert player (2344)



Joined: 2005-08-15 07:20:25

Posts: 1884

Location: Mullsjö, Sweden

Posted: 2011-12-08 21:04:17 Post subject:



An optimised TAS would be very awesome to see. I won't be the one to make one at least, but I'll gladly watch =).

Should note that it is a very old vide. All levels except two (1 and 47) have been improved. The total time for all levels is currently 35:05.44 (As of Dec 4 2011).An optimised TAS would be very awesome to see. I won't be the one to make one at least, but I'll gladly watch =).

bene

Newbie



Joined: 2015-11-18 20:39:20

Posts: 5



Posted: 2015-11-19 08:07:29 Post subject: Elasto Mania 100% tas in 09:54,58 by bene, Zweq, FinMan



Link to run:

Link to short video of tricks:



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. Link to run: https://www.youtube.com/watch?v=IocsDW2KLEs Link to short video of tricks: https://www.youtube.com/watch?v=YRKq37rHOVc * 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.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.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.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.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.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.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.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.

Weregoose





Joined: 2015-10-13 04:33:13

Posts: 9

NewbieJoined: 2015-10-13 04:33:13Posts: 9

Posted: 2015-11-19 08:41:17 Post subject:



I remember building maps and witnessing Zweq (one of the authors here) absolutely crush them on his third or fourth attempts, in ways I hadn't anticipated! He's quite a powerhouse, and I'm privileged to see him in action again after all these years in this different venue. Absolutely an honorable in my book. This is one of the many games I grew up with, and what I saw here was nothing short of beautiful. Very little shown here is remotely doable in RTA – the combined world record as of just over three years ago was 34:58:49 I remember building maps and witnessing Zweq (one of the authors here) absolutely crush them on his third or fourth attempts, in ways I hadn't anticipated! He's quite a powerhouse, and I'm privileged to see him in action again after all these years in this different venue. Absolutely an honorablein my book.

moozooh





Joined: 2005-08-04 20:58:59

Posts: 5701

Location: Moscow, Russia Vested EditorJoined: 2005-08-04 20:58:59Posts: 5701Location: Moscow, Russia

Posted: 2015-11-19 09:37:58 Post subject:



I always wanted to try a TAS of this game myself, but was intimidated by the potential amount of effort and research needed. My personal unassisted total time is still somewhere around 55-ish minutes, and I haven't seriously touched this game in about a decade.



A Hourglass TAS would likely not allow on-the-fly framerate switching, so I guess we should see some more semblance of normal gameplay in a potential Elma submission. That being said, to what extent everything that happens here would occur at, say, a constant 60 fps? What would you expect to be the optimal constant framerate figure if not 60?



Also, a bit of a tangent, but are there any plans for a new Elma Done Quick? I don't really keep up with the community; I saw some interest talks on the forums a few months ago, but I don't remember seeing any new versions surface since the last one (which was when the WR TT dropped under 35 minutes I believe). Traditionally it's made only when a new minute barrier is crossed, but realistically this is becoming exponentially longer and more challenging to achieve, so if the new compilation is to be done, it should likely be done at an earlier breakpoint. I think the current WR TT is like 34:40-ish? Can't access Moposite for some reason...



EDIT: To weigh in some more on framerate abuse and the like: while this is definitely interesting, and I understand that many of the Elma community members accept this as legit tricks, there are several ways I think this might not exactly work. We need some discussion on this.



1. Yes, the physics simulation is done by the original code, native to the game's executable, but framerate change is introduced externally via third-party tools, OS features, or hardware manipulation. This is different to even, say, Half-Life, where it is at least done by the game's internal means. So while this is possible to do, is it a legit thing to do?



2. While simulation yields different results based on framerate, does it poll for user input at frame rate, or is it limited to a certain range? If it's limited, should the framerate be, at least, limited to this range?



3. You can run the physics simulation at 1000 fps with a decent enough CPU, but there is neither a way to supply it with input at that rate (to my knowledge—I might be wrong on this), nor show the output (no display technology I'm aware of supports framerates this high). It's in a theoretical hardware territory.



Furthermore, if a constant framerate is to be established, it will most likely have to be one of the three values:

— 60 fps: the golden standard supported by all of PC-compatible hardware;

— 100 fps: the maximum in-game precision for the shown timer and the purposes of total time calculation;

— ??? fps: the optimal value at which the lowest time can be achieved.



EDIT 2: The USB 2.0 port can poll at 1 kHz (not sure if more is possible or if this is changed in 3.0/3.1; probably not). But it appears as if either the OS or something else limits keyboard polling to something like 125 Hz to avoid accidental repeats in input—this needs confirmation.

_________________

Warp wrote:

Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry. I absolutely did not expect this post, and much less the content. Stretch bugs are pretty... disturbing, to say the least! What an obnoxious way of playing the game. :D Anyway, great job on this run!I always wanted to try a TAS of this game myself, but was intimidated by the potential amount of effort and research needed. My personal unassisted total time is still somewhere around 55-ish minutes, and I haven't seriously touched this game in about a decade.A Hourglass TAS would likely not allow on-the-fly framerate switching, so I guess we should see some more semblance of normal gameplay in a potential Elma submission. That being said, to what extent everything that happens here would occur at, say, a constant 60 fps? What would you expect to be the optimal constant framerate figure if not 60?Also, a bit of a tangent, but are there any plans for a new Elma Done Quick? I don't really keep up with the community; I saw some interest talks on the forums a few months ago, but I don't remember seeing any new versions surface since the last one (which was when the WR TT dropped under 35 minutes I believe). Traditionally it's made only when a new minute barrier is crossed, but realistically this is becoming exponentially longer and more challenging to achieve, so if the new compilation is to be done, it should likely be done at an earlier breakpoint. I think the current WR TT is like 34:40-ish? Can't access Moposite for some reason...EDIT: To weigh in some more on framerate abuse and the like: while this is definitely interesting, and I understand that many of the Elma community members accept this as legit tricks, there are several ways I think this might not exactly work. We need some discussion on this.1. Yes, the physics simulation is done by the original code, native to the game's executable, but framerate change is introduced externally via third-party tools, OS features, or hardware manipulation. This is different to even, say, Half-Life, where it is at least done by the game's internal means. So while this is possible to do, is it a legit thing to do?2. While simulation yields different results based on framerate, does it poll for user input at frame rate, or is it limited to a certain range? If it's limited, should the framerate be, at least, limited to this range?3. You can run the physics simulation at 1000 fps with a decent enough CPU, but there is neither a way to supply it with input at that rate (to my knowledge—I might be wrong on this), nor show the output (no display technology I'm aware of supports framerates this high). It's in a theoretical hardware territory.Furthermore, if a constant framerate is to be established, it will most likely have to be one of the three values:— 60 fps: the golden standard supported by all of PC-compatible hardware;— 100 fps: the maximum in-game precision for the shown timer and the purposes of total time calculation;— ??? fps: the optimal value at which the lowest time can be achieved.EDIT 2: The USB 2.0 port can poll at 1 kHz (not sure if more is possible or if this is changed in 3.0/3.1; probably not). But it appears as if either the OS or something else limits keyboard polling to something like 125 Hz to avoid accidental repeats in input—this needs confirmation.

bene

Newbie



Joined: 2015-11-18 20:39:20

Posts: 5



Posted: 2015-11-19 12:52:22 Post subject:



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



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 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:44Current non bug tas tt (with arbitrary limit) is 33:34