Saveload WR table
Moderator: Moporators
Re: Saveload WR table
This means that we could purge out all the non-acceptable bugruns from SL table. I guess its quite a great thing. One step closer to clean records. On the other hand it could be used to check 32tt recz from zweck. Definitely GAA nomination for this one, provided that this will lead us to clean WRs.
Maybe 32tt is not even possible? (pipe, trix, animal fram)
If you ask me I vote for a finally clean table, even if its an TAS table.
Maybe 32tt is not even possible? (pipe, trix, animal fram)
If you ask me I vote for a finally clean table, even if its an TAS table.
Elasto Mania - 34:21.69 | #421 - 11. April 2024
Ancient Internals
Ancient Internals
Re: Saveload WR table
I dont know anything about what bene said, but i wonder, how couldnt be legit that Sink's little bounce and how can be Pipe's wr?
Re: Saveload WR table
Pipe wr is an easily reproducible bug, it's barely more of a bug than that sink rec though. You can try the pipe bounce 1 million times in an hour because it's right in the start of the level though which makes it more viable, also saves a tiny bit more time.
Re: Saveload WR table
It's hard to define what's legit. In general if something is hard to reproduce, we call it a bug in the Elma world. The lower the distance of the wheel from the centre of the bike, the less reproducible it is and the stronger the bounce usually is (if you have the same fps). However, if you change to a higher fps and brake at the same spot, you can get a normal bounce that doesn't give you any advantage, but you can also get a bounce that looks perfectly legit, but still gives you a tiny advantage that is hard to reproduce and impossible to detect.
Pipe bounce is right at the beginning, so even though it's extremely hard to reproduce it, a few people have done it as they hoyled the first 6 seconds for hours. But is it not a bug if you only get it once out of a thousand tries? If you had to do the same trick at the end, no one would ever do it. And this is the same thing that happens when you hoyl in SL. You save at a certain spot and suddenly an irreproducible bounce becomes reproducible and if you save it even a shorter time before that bounce happens, it suddenly becomes ez, even though in reality it's impsy.
When you get a bug bounce, the wheel usually pops strongly and quickly in a certain direction. This is sometimes not visible as it gets stopped/suppressed by the ground, which is what happens in my Sink rec. Bene suggested that I save the rec at the spot where the bounce happens and then load the state in an empty level while holding brake and using the same fps and see what the wheel does. It's not completely accurate as you never get the same exact fps, but it helps a little bit.
Here's the results (merge them):
http://kopasite.net/up/6g4x22nnx75n5nf/SL45Mad3184.rec
http://kopasite.net/up/d1w2107g34320h7/airsink.rec
http://kopasite.net/up/elcdacrxg5b7a1l/SinkNONBUG.rec
http://kopasite.net/up/eu2oz5zwt05co56/ ... NONBUG.rec
http://kopasite.net/up/96v2ke199i7y4g8/SL30Mad2863.rec
http://kopasite.net/up/243m8jmdc6rm299/airpipe.rec
Pipe bounce is right at the beginning, so even though it's extremely hard to reproduce it, a few people have done it as they hoyled the first 6 seconds for hours. But is it not a bug if you only get it once out of a thousand tries? If you had to do the same trick at the end, no one would ever do it. And this is the same thing that happens when you hoyl in SL. You save at a certain spot and suddenly an irreproducible bounce becomes reproducible and if you save it even a shorter time before that bounce happens, it suddenly becomes ez, even though in reality it's impsy.
When you get a bug bounce, the wheel usually pops strongly and quickly in a certain direction. This is sometimes not visible as it gets stopped/suppressed by the ground, which is what happens in my Sink rec. Bene suggested that I save the rec at the spot where the bounce happens and then load the state in an empty level while holding brake and using the same fps and see what the wheel does. It's not completely accurate as you never get the same exact fps, but it helps a little bit.
Here's the results (merge them):
http://kopasite.net/up/6g4x22nnx75n5nf/SL45Mad3184.rec
http://kopasite.net/up/d1w2107g34320h7/airsink.rec
http://kopasite.net/up/elcdacrxg5b7a1l/SinkNONBUG.rec
http://kopasite.net/up/eu2oz5zwt05co56/ ... NONBUG.rec
http://kopasite.net/up/96v2ke199i7y4g8/SL30Mad2863.rec
http://kopasite.net/up/243m8jmdc6rm299/airpipe.rec
Re: Saveload WR table
as i see 31.9x still posibble in Sink
did you finish the ride with legit bounce Madness?
did you finish the ride with legit bounce Madness?
Elasto Mania - 34:21.69 | #421 - 11. April 2024
Ancient Internals
Ancient Internals
Re: Saveload WR table
wel said. With SL it's very feasible to perform controversial looking bugs everywhere, and eventhough the final result/rec looks never reproducible each individual bug would be easily reproducible if the start was next to it. It's a bit like http://kopasite.net/up/1ji4bk41i5hc80c/35x20003.rec but those bugs are not easily reproducible without pause + 1 frame advance, so it's kinda unrelated and dum of me to mention it here.Madness wrote:
Pipe bounce is right at the beginning, so even though it's extremely hard to reproduce it, a few people have done it as they hoyled the first 6 seconds for hours. But is it not a bug if you only get it once out of a thousand tries? If you had to do the same trick at the end, no one would ever do it. And this is the same thing that happens when you hoyl in SL. You save at a certain spot and suddenly an irreproducible bounce becomes reproducible and if you save it even a shorter time before that bounce happens, it suddenly becomes ez, even though in reality it's impsy.
What coms to determining whether a bounce is a bug or not, I guess it's possible with extra tools like milasl because all possible data about ride is saved in the .dat files. If bene has found some method thats nice, and i hope we can get the parameters right(threshold of bug/unbug) and start using it for saveload table.
However, same method cant be usable for .rec files therefore nat usable for norm playing
Re: Saveload WR table
bnc at 1:08 seems legit. others nat
Elasto Mania - 34:21.69 | #421 - 11. April 2024
Ancient Internals
Ancient Internals
Re: Saveload WR table
Updated the rules, more info in the first post. Many thanks go to bene for the "air test".
Here's a list of WRs that will most likely be deleted/replaced by the next update:
6. Long Haul - 29,52 by milagros - not completely sure about this, but the min distance is way too low for sure (0.0045), so I will test this more and see if I can get a good acceptable bounce with a min distance of over 0.0300
7. Hi Flyer - 23,64 by Zweq - gas bug bounce (min distance 0.0012)
30. Pipe - 28,63 by Madness - there will be some leeway in Pipe for the min distance as I said in the first post, but my bounce definitely looks too strange, so it's out
45. Sink - 31,84 by Madness - air test showed it's buggy (min distance 0.0280), will probably be replaced with another time of mine where I got a good non-buggy bounce (min distance 0.0301)
46. Bowling - 48,67 by Zweq - always looked quite buggy to me and the air test confirmed it (min distance 0.0083)
Here's a list of WRs that will most likely be deleted/replaced by the next update:
6. Long Haul - 29,52 by milagros - not completely sure about this, but the min distance is way too low for sure (0.0045), so I will test this more and see if I can get a good acceptable bounce with a min distance of over 0.0300
7. Hi Flyer - 23,64 by Zweq - gas bug bounce (min distance 0.0012)
30. Pipe - 28,63 by Madness - there will be some leeway in Pipe for the min distance as I said in the first post, but my bounce definitely looks too strange, so it's out
45. Sink - 31,84 by Madness - air test showed it's buggy (min distance 0.0280), will probably be replaced with another time of mine where I got a good non-buggy bounce (min distance 0.0301)
46. Bowling - 48,67 by Zweq - always looked quite buggy to me and the air test confirmed it (min distance 0.0083)
Re: Saveload WR table
Increasing tas tt bit by bit.
It should be noted that the air test is theory but seems to work, there is no checking of elma code to verify anything osv.
It should be noted that the air test is theory but seems to work, there is no checking of elma code to verify anything osv.
Signatür ruined by SveinR - smaller plz :*
Re: Saveload WR table
Huge props to all of you guys for the effort of 'cleaning' the table from bugs. Now since the discussion is on, I want to ask all ppl how do they feel about stretches and wheelpops as well. Should they be allowed? Is there another way to tell that they are bugs, like the min distance is for bug bounces? Or should these not be considered bugs? Are they vsync/fps related? They always looked quite unnatural to me. Examples: Flat Track start, Freefall start for wheelpops, Animal Farm start and Tricks Abound bottom part for stretches. Also, are there any more questionable things except these 3?
Re: Saveload WR table
They are all bugs.
All bugs should be allowed for any proper tas, after that comes special categories.
This table is a special category now, actually it was before also but more so now. It is the non bugpop category, removing only bugpops is a good category because of how big of an advantage it gives (As my tas video proved). Removing wheelpops will have a few seconds difference only so it is quite a meh category to compete in imo. Stretches are only in two levels (31,51)? (Maybe int45 how would one prove that the start is not bug here if vsync hole stretches are considered bugs?) but it will be a bigger difference than wheelpops maybe.
Removing all bugs and/or enforcing a single set fps value might be a good category where the difference from this is big enough to care for anyone with times in this already. The problem with that is that we currently don't have a way of playing with constant fps with current tools.
Another fun category maybe would be one using tasvideos rules to get published there.
Edit: This table also disallows stretchbugging as my tas video probably, otherwise you could start a b0nebounce bug in some levels without using bugpops and finish in a way similar to my tas video.
Edit 2: Like this http://www.recsource.tv/r/hipdywenxf 1 min shitrec
All bugs should be allowed for any proper tas, after that comes special categories.
This table is a special category now, actually it was before also but more so now. It is the non bugpop category, removing only bugpops is a good category because of how big of an advantage it gives (As my tas video proved). Removing wheelpops will have a few seconds difference only so it is quite a meh category to compete in imo. Stretches are only in two levels (31,51)? (Maybe int45 how would one prove that the start is not bug here if vsync hole stretches are considered bugs?) but it will be a bigger difference than wheelpops maybe.
Removing all bugs and/or enforcing a single set fps value might be a good category where the difference from this is big enough to care for anyone with times in this already. The problem with that is that we currently don't have a way of playing with constant fps with current tools.
Another fun category maybe would be one using tasvideos rules to get published there.
Edit: This table also disallows stretchbugging as my tas video probably, otherwise you could start a b0nebounce bug in some levels without using bugpops and finish in a way similar to my tas video.
Edit 2: Like this http://www.recsource.tv/r/hipdywenxf 1 min shitrec
Signatür ruined by SveinR - smaller plz :*
Re: Saveload WR table
I think it's great to see the TAS scene maturing like this. Hope you guys can figure out a good ruleset and avoid major controversies in the future.
Re: Saveload WR table
Now that b0ne explained that all of the things I mentioned are indeed bugs (I also forgot to mention hooked bug), the community should decide how this table (and other tables) should operate, if they should be bug-less, only some bugs allowed, etc. Then, the said rules should be enforced and mentioned by the table so everyone can see what is and isn't allowed.
Re: Saveload WR table
lol, airtest is not a solution. Where isBug(data) -> bool vtf bene
Re: Saveload WR table
there is only one solution = fix the elma code such that there is no division by 0 and the physics framerate is fixed to 1000
for example some code like this would do:
(bx, by - bike centre, w1x, w1y - wheel1 centre)
double d = sqrt((w1x-bx) * (w1x-bx) + (w1y-by) * (w1y-by));
if(d == 0.0) w1x = bx + eps, w1y = by; // never happens
else w1x = bx + (w1x-bx) * eps / d, w1y = by + (w1y-by) * eps / d;
same for wheel2, eps should be chosen reasonably:)
ofc this makes all old wrs invalid.. blahblahblah, but should be used in elma2
for example some code like this would do:
(bx, by - bike centre, w1x, w1y - wheel1 centre)
double d = sqrt((w1x-bx) * (w1x-bx) + (w1y-by) * (w1y-by));
if(d == 0.0) w1x = bx + eps, w1y = by; // never happens
else w1x = bx + (w1x-bx) * eps / d, w1y = by + (w1y-by) * eps / d;
same for wheel2, eps should be chosen reasonably:)
ofc this makes all old wrs invalid.. blahblahblah, but should be used in elma2
[carebox]
Re: Saveload WR table
I don't understand anything, but is there a way to fix it without fixing the frame rate to 1000? Would it affect all bounces or just eliminate the buggy ones (where the min distance is under a certain value)?
It would be nice if you put these three simple lines in the code and shared the .exe for us to test.
It would be nice if you put these three simple lines in the code and shared the .exe for us to test.
Re: Saveload WR table
Update:
17. Labyrinth — Mielz - 51.20 Kazan - 50.51
18. Spiral — bene - 44.03 Kazan - 43.79
30. Pipe — Madness - 28.63 Kazan - 27.03
43. He He — Madness - 54.66 Labs - 54.21
Buggy times replaced by slower times:
06. Long Haul — mila - 29.52 Madness - 29.78
07. Hi Flyer — Zweq - 23.64 Zweq - 25.76
45. Sink — Madness - 31.84 Madness - 31.99
46. Bowling — Zweq - 48.67 Zweq - 49.87
// Updated recs. Added bene's glitch project recs, lots of non-wr recs and some bug recs, all in separate folders for clarity.
// Added gifs explaining the meaning of bug bounces, bug pops, hooked bugs, bug stretches and grip wheel pops.
17. Labyrinth — Mielz - 51.20 Kazan - 50.51
18. Spiral — bene - 44.03 Kazan - 43.79
30. Pipe — Madness - 28.63 Kazan - 27.03
43. He He — Madness - 54.66 Labs - 54.21
Buggy times replaced by slower times:
06. Long Haul — mila - 29.52 Madness - 29.78
07. Hi Flyer — Zweq - 23.64 Zweq - 25.76
45. Sink — Madness - 31.84 Madness - 31.99
46. Bowling — Zweq - 48.67 Zweq - 49.87
// Updated recs. Added bene's glitch project recs, lots of non-wr recs and some bug recs, all in separate folders for clarity.
// Added gifs explaining the meaning of bug bounces, bug pops, hooked bugs, bug stretches and grip wheel pops.
Last edited by Madness on 1 Aug 2016, 11:26, edited 1 time in total.
Re: Saveload WR table
were you ahead of me before the bounce? if not, i can provide any strong rec you like:)
[carebox]
Re: Saveload WR table
Can I ask why are grip wheel pops and stretches (like int 31 and 51) allowed? I though if we're gonna remove bugs, we're gonna remove them all.
Re: Saveload WR table
Time to share all 32tt recz mila
Last edited by Schumi on 1 Aug 2016, 06:32, edited 1 time in total.
Elasto Mania - 34:21.69 | #421 - 11. April 2024
Ancient Internals
Ancient Internals
Re: Saveload WR table
here clean version of 46 http://kopasite.net/up/0w4cwryyvjv44v5/46z4987c.rec
Re: Saveload WR table
Why are wheel pops allowed?culinko wrote:Can I ask why are grip wheel pops and stretches (like int 31 and 51) allowed? I though if we're gonna remove bugs, we're gonna remove them all.
1) They are easily reproducible.
2) They are used in regular WRs (Flat Track, Freefall, Hooked).
3) They are impossible to detect (with low fps you can see them clearly, but as you increase the fps, the pop becomes weaker and weaker, but it's still there).
4) Forbidding them would mean forbidding braking whenever you are close to a polygon.
Why are stretches allowed?
1) They are easily reproducible with low fps. The only thing that makes them irreproducible is the fps switching, which saves the wheel from going inside the ground.
2) It's used in Animal Farm regular WR.
3) Forbidding them would mean forbidding fps switching.
If we were to remove all bugs, we wouldn't be allowed to do any bounces at all.
Last edited by Madness on 1 Aug 2016, 14:38, edited 6 times in total.
Re: Saveload WR table
I was.milagros wrote:were you ahead of me before the bounce? if not, i can provide any strong rec you like:)
Added in the table, sorry for overlooking this one.Zweq wrote:here clean version of 46 http://kopasite.net/up/0w4cwryyvjv44v5/46z4987c.rec
Re: Saveload WR table
my time in spiral - 43.79
Re: Saveload WR table
Is the TT oke?
Elasto Mania - 34:21.69 | #421 - 11. April 2024
Ancient Internals
Ancient Internals
Re: Saveload WR table
Thx. Nice effort btw making this stuff!
Elasto Mania - 34:21.69 | #421 - 11. April 2024
Ancient Internals
Ancient Internals
Re: Saveload WR table
Updated the rules.
- From now on, only Mila's saveload is allowed. This is because other saveloads don't make it possible to check the min distance from the centre of the bike and other stuff important for deciding what is a bug. This doesn't affect WRs driven with different tools up to this point in any way.
Internals where there is a bounce at the end:
- In order for your WR to be accepted, you need to have a better run prior to the bounce. You can compare your rec with the pictures in the first post.
Also rephrased some things and added two more questions to the FAQ.
Now the main problem is Internal 30 (the only Internal with a bounce at the beginning) where bugs need to be allowed to a certain point. The problem is that the first bounce decides pretty much everything and there's no point in hoyling the rest if anyone can just beat it with a better (buggier) bounce at start. What do you think of a rule that everyone would have to have the exact same bounce → use the first 6 seconds of Kazan's current WR? (He said he would agree to make the first 6 seconds of his rec (.dat) public for everyone to use if other people agreed with this rule.)
- From now on, only Mila's saveload is allowed. This is because other saveloads don't make it possible to check the min distance from the centre of the bike and other stuff important for deciding what is a bug. This doesn't affect WRs driven with different tools up to this point in any way.
Internals where there is a bounce at the end:
- In order for your WR to be accepted, you need to have a better run prior to the bounce. You can compare your rec with the pictures in the first post.
Also rephrased some things and added two more questions to the FAQ.
Now the main problem is Internal 30 (the only Internal with a bounce at the beginning) where bugs need to be allowed to a certain point. The problem is that the first bounce decides pretty much everything and there's no point in hoyling the rest if anyone can just beat it with a better (buggier) bounce at start. What do you think of a rule that everyone would have to have the exact same bounce → use the first 6 seconds of Kazan's current WR? (He said he would agree to make the first 6 seconds of his rec (.dat) public for everyone to use if other people agreed with this rule.)
Re: Saveload WR table
make some rules about who gets the wr, if it's driven by multiple persons
for example - in steppes in did only last 2 secs, it was 10,50 zweq's wr (same way i did 39.99 downhill for example and many others i don't remember)
in twinpeaks i played only 2nd half
02/44/53 were done by me
for example - in steppes in did only last 2 secs, it was 10,50 zweq's wr (same way i did 39.99 downhill for example and many others i don't remember)
in twinpeaks i played only 2nd half
02/44/53 were done by me
[carebox]
Re: Saveload WR table
What if want different angle or spin on bounce of int 30?
Re: Saveload WR table
in Pipe i would suggest to make more starts with bounces (provided if it is possible), then the players could choose from that rec/dat collection. there has to be a way to determine if a bounce is closer to a legit one or not (bene & mila & zwek cooperation -> discussion -> approval)
very sik times could happen...
very sik times could happen...
Elasto Mania - 34:21.69 | #421 - 11. April 2024
Ancient Internals
Ancient Internals
Re: Saveload WR table
It's always up to the people involved in making the WR together. In my opinion, if Zweq gets 40.00 in Downhill on his own and you improve it by 0.01, then it would be unfair to have your nick in the table. So maybe the one who drives most of the rec should have the WR? But then again, I don't know who drove what and it's still for you to decide.milagros wrote:make some rules about who gets the wr, if it's driven by multiple persons
for example - in steppes in did only last 2 secs, it was 10,50 zweq's wr (same way i did 39.99 downhill for example and many others i don't remember)
in twinpeaks i played only 2nd half
02/44/53 were done by me
If you use someone else's .dat file to get a WR without their permission to do so, then this is a different story. I've just added a rule forbidding this, just in case.
Kazan has got a perfect angle. Different angle = different strength of the bounce = we are back to square one.sunl wrote:What if want different angle or spin on bounce of int 30?
I see your point. It is surely possible to make 1000 differently strong bounces, but there's not much to discuss, you can always get one that's slightly faster or slower. I believe Kazan's bounce is just about right and also using his bounce is the only way of making a rule that wouldn't exclude his own WR.Schumi wrote:in Pipe i would suggest to make more starts with bounces (provided if it is possible), then the players could choose from that rec/dat collection. there has to be a way to determine if a bounce is closer to a legit one or not (bene & mila & zwek cooperation -> discussion -> approval)
very sik times could happen...
Re: Saveload WR table
Missing these recs from replay pack?
http://www.recsource.tv/r/zpgcfitbwh
http://www.recsource.tv/r/xadhkutywe
http://www.recsource.tv/r/zpgcfitbwh
http://www.recsource.tv/r/xadhkutywe
Re: Saveload WR table
I don't agree with almost all the points you listed. Bug bounces are also easily reproducible and Stini's Enigma WR is still in the official WR table, so the first two points honestly don't mean much to me. Claiming that forbidding wheel pops would forbid braking near polygons and that removing all bugs would forbid all bounces is silly. I know this is your table and I respect your decision, but I was hoping for a debate about all these things instead of just one person deciding the rules. If you came to this conclusion with more people discussing these things, please do tell. I welcome everyone in this discussion, because I want to know how other people feel about this. It's unlikely that the rules will be changed again at some point in the future (if ever). Kazan, Zweq, milagros, b0ne any input?Madness wrote:Why are wheel pops allowed?culinko wrote:Can I ask why are grip wheel pops and stretches (like int 31 and 51) allowed? I though if we're gonna remove bugs, we're gonna remove them all.
1) They are easily reproducible.
2) They are used in regular WRs (Flat Track, Freefall, Hooked).
3) They are impossible to detect (with low fps you can see them clearly, but as you increase the fps, the pop becomes weaker and weaker, but it's still there).
4) Forbidding them would mean forbidding braking whenever you are close to a polygon.
Why are stretches allowed?
1) They are easily reproducible with low fps. The only thing that makes them irreproducible is the fps switching, which saves the wheel from going inside the ground.
2) It's used in Animal Farm regular WR.
3) Forbidding them would mean forbidding fps switching.
If we were to remove all bugs, we wouldn't be allowed to do any bounces at all.
Re: Saveload WR table
I think everything should be allowed for any proper tas however this table is norm because
Same logic for bug stretching, it is reproducible but it gives a big advantage and is nonfun. Bug bounces/Bug pops/Bug stretching (b0ne stretching, not int51) are all horribly boring to höyl and they have no stop for possibility until few frames finish from bugspot.bene wrote:removing only bugpops is a good category because of how big of an advantage it gives (As my tas video proved).
Signatür ruined by SveinR - smaller plz :*
Re: Saveload WR table
my input is a) allow everything or b) code new elma oke serious input is that i think madnes is on the right trak. Using kazaan start for pipe is a new refreshing idea, but i think it wouldnt work, we are at the same problem as always. Consider someone makes 0.005 faster start, then can just make same bug as kazan except it's just 0.01 times stronger, something you cannot see or measure, but it is faster. There you go, faster bug was accepted than the previous bug. Then someone improves 0.005 in start again and so on. So it's just another arbitrary solution. Camp A: oh hey lets use this bug it cool oke Camp B: wtf.. no.., someone did faster in lev x and was acept.. Camp C: wtf way too bugy fuk of
megastretches are oke imo, they are fundamentally something totally different than this min distance from center of bike shit
megastretches are oke imo, they are fundamentally something totally different than this min distance from center of bike shit
Re: Saveload WR table
Bug bounces are not easily reproducible, they are very rare to reproduce without SL. Why do you think no one has managed to beat Stini's Enigma WR since 2004? Stini's Enigma being in the official WR table is simply wrong, it's buggy as hell.culinko wrote:Bug bounces are also easily reproducible and Stini's Enigma WR is still in the official WR table, so the first two points honestly don't mean much to me.
Grip wheel pops happen when you brake near polygons, sometimes they are visible, sometimes not. Have you noticed how hard it is to decide which bounces should be accepted and which shouldn't? Now imagine I make a hundred recs for you, each with a differently strong wheel pop while changing the fps gradually up by one in each rec, from the point when they are clearly visible to the point when you would never be able to tell there is a wheel pop there. Do you want to be the one to judge which recs contain a wheel pop or which wheel pops are too strong and shouldn't be accepted? It's impossible. But you can have a go at it: http://kopasite.net/up/ot8jy31nj5e574y/wheel_pops.zipculinko wrote:Claiming that forbidding wheel pops would forbid braking near polygons and that removing all bugs would forbid all bounces is silly.
A bug is "an error in a computer program or system". All bounces in Elma happen in the same way, so technically speaking all bounces are bugs. The lower the minimum distance from the centre of the bike, the rarer and (often) stronger the bounce is. There's no way to tell which bounces are unacceptable unless someone draws the line and clearly states what is an unacceptable bounce, which is pretty much impossible because bounces are affected by so many things (min distance, fps, velocity, angle...).
Debate is always welcome. It's not me deciding the rules, it's the community. If most people disagree with the rules, I will change them. However, I cannot forbid something that's impossible to detect and I won't forbid anything that's easily reproducible even without SL.culinko wrote:I know this is your table and I respect your decision, but I was hoping for a debate about all these things instead of just one person deciding the rules. If you came to this conclusion with more people discussing these things, please do tell. I welcome everyone in this discussion, because I want to know how other people feel about this. It's unlikely that the rules will be changed again at some point in the future (if ever). Kazan, Zweq, milagros, b0ne any input?
Re: Saveload WR table
Nah, you couldn't make a faster start. You would basically get a .dat file and have to start playing from the point where the bike left the ground after the bounce.Zweq wrote:Using kazaan start for pipe is a new refreshing idea, but i think it wouldnt work, we are at the same problem as always. Consider someone makes 0.005 faster start, then can just make same bug as kazan except it's just 0.01 times stronger, something you cannot see or measure, but it is faster. There you go, faster bug was accepted than the previous bug. Then someone improves 0.005 in start again and so on.
Re: Saveload WR table
I think Madness is setting right guidelines for sl wrs. The only one that's iffy is the Tricks Abound style as that's not completely reproduceable without saveload but it probably has to do more with consensus and the consensus so far has been glitch-stretch (non-epileptic) are okay.
I think Madness' guidelines for bounce levels (e.g. Long Haul + Enigma) are very genius idea
As I said before, pipe is the new enigma
I think Madness' guidelines for bounce levels (e.g. Long Haul + Enigma) are very genius idea
As I said before, pipe is the new enigma
Re: Saveload WR table
Well, Stini managed to reproduce hundreds of Pipe bug bounces, but they weren't accepted just because "it's possible to reproduce". I think nobody beating Stini's Enigma is simply because it was decided that only non-bugs will be accepted as better times so we can get rid of the bug in Enigma once and for all (or at least I assume so). I'm not saying Stini's Enigma rec should have been accepted, I'm just saying that the argument "it's in the WR table" is not strong enough for me and this replay is the reasoning. And I believe it's still possible to beat the Enigma time even without a bug ride, but unfortunately Jarkko is not playing anymore to hoyl that :/Madness wrote:Bug bounces are not easily reproducible, they are very rare to reproduce without SL. Why do you think no one has managed to beat Stini's Enigma WR since 2004? Stini's Enigma being in the official WR table is simply wrong, it's buggy as hell.
I'd personally just forbid every wheel pop that is visible. Meaning that if your wheel gets "more speed" after pressing a brake, it's clearly a bug and should not be accepted.Madness wrote:Grip wheel pops happen when you brake near polygons, sometimes they are visible, sometimes not. Do you want to be the one to judge which recs contain a wheel pop or which wheel pops are too strong and shouldn't be accepted?
As for the stretches (31 and 51), they just don't look pretty to me. It might be a weak argument, but that's how I feel about them. On the technical side, the wheels in tight spaces just jump from one place to another which is definitely not normal. This reminds me of extremely slim pipes where you press brake and you get very high speed from it. Is that one a bug too?
I agree, but I would want normal bounces to be allowed, because bounces are one of the most fun aspects of the game for me.Madness wrote:All bounces in Elma happen in the same way, so technically speaking all bounces are bugs.
I really like the idea of using "recommended" .dat files for a Pipe start and for similar levels, the idea sounds fresh. However then you'd need to bring a credit system for level's segments instead of crediting just one kuski for the level. Not sure what would be the best way to do it, just throwing the idea out there. Oh, and also "Elma SL done quick with 180 kuskis"
Re: Saveload WR table
Part before bonceMadness wrote:Nah, you couldn't make a faster start. You would basically get a .dat file and have to start playing from the point where the bike left the ground after the bounce.Zweq wrote:Using kazaan start for pipe is a new refreshing idea, but i think it wouldnt work, we are at the same problem as always. Consider someone makes 0.005 faster start, then can just make same bug as kazan except it's just 0.01 times stronger, something you cannot see or measure, but it is faster. There you go, faster bug was accepted than the previous bug. Then someone improves 0.005 in start again and so on.
Re: Saveload WR table
Stini was the only one who could ever reproduce bug bounces and it is still not known why / how. That's why his Pipe times weren't accepted. If everyone could reproduce it, it would be accepted. Either way, I agree that the fact that something is in the regular WR table is not very relevant, the reproducibility is.culinko wrote:Well, Stini managed to reproduce hundreds of Pipe bug bounces, but they weren't accepted just because "it's possible to reproduce". I think nobody beating Stini's Enigma is simply because it was decided that only non-bugs will be accepted as better times so we can get rid of the bug in Enigma once and for all (or at least I assume so). I'm not saying Stini's Enigma rec should have been accepted, I'm just saying that the argument "it's in the WR table" is not strong enough for me and this replay is the reasoning. And I believe it's still possible to beat the Enigma time even without a bug ride, but unfortunately Jarkko is not playing anymore to hoyl that :/Madness wrote:Bug bounces are not easily reproducible, they are very rare to reproduce without SL. Why do you think no one has managed to beat Stini's Enigma WR since 2004? Stini's Enigma being in the official WR table is simply wrong, it's buggy as hell.
Which ones in particular would you forbid? http://kopasite.net/up/ot8jy31nj5e574y/wheel_pops.zipculinko wrote:I'd personally just forbid every wheel pop that is visible. Meaning that if your wheel gets "more speed" after pressing a brake, it's clearly a bug and should not be accepted.Madness wrote:Grip wheel pops happen when you brake near polygons, sometimes they are visible, sometimes not. Do you want to be the one to judge which recs contain a wheel pop or which wheel pops are too strong and shouldn't be accepted?
As for the stretches (31 and 51), they just don't look pretty to me. It might be a weak argument, but that's how I feel about them. On the technical side, the wheels in tight spaces just jump from one place to another which is definitely not normal. This reminds me of extremely slim pipes where you press brake and you get very high speed from it. Is that one a bug too?
The fact that they just don't look pretty to you is indeed not a very strong argument, considering that they are easily reproducible without SL.
The wheel in tight spaces always jumps from one place to another if you press brake. If normal = usual, then it is normal. Is it a bug? I don't know, it depends on whether Balazs intended to make this behaviour possible.
You asked why not remove all bugs and now you say you want to keep the nice ones because they are fun. That's kind of what this table is about.culinko wrote:I agree, but I would want normal bounces to be allowed, because bounces are one of the most fun aspects of the game for me.Madness wrote:All bounces in Elma happen in the same way, so technically speaking all bounces are bugs.
Re: Saveload WR table
Madness 100- culino 0. Imo
Re: Saveload WR table
just want to add there are different kind of bounces and fixing bug bounce wouldnt remove all bounces: for example this bounce at 13s has nothing to do with min-distance-from-center-bug http://www.recsource.tv/r/bdovuqeism . This kind of bounce can never result in a bug, ive tried for ages in new wave left wall (before i knew how bugs work). Also this kind of bounce is always the same looking, without any variation (as long as you get timings right), which is not something you can say about bounces like bowling end (even if you think you get timings right, you might get mega bounces randomly)
milagros' suggestion was something along the lines of: in every frame if(min_distance < some_threshold) offset wheel in correct direction to achieve min_distance >= some_threshold . I might remember the logic terribly wrong, if so, sorry it's my fault not milagros' if such fix was applied it wouldnt affect bounces like in serpents tale at all because min_distance is always above some_threshhold. There could be some unwanted side effects though like uphill battle, hi flyer brutals becoming slower osv, because wheel is max close to center of bike there.
milagros' suggestion was something along the lines of: in every frame if(min_distance < some_threshold) offset wheel in correct direction to achieve min_distance >= some_threshold . I might remember the logic terribly wrong, if so, sorry it's my fault not milagros' if such fix was applied it wouldnt affect bounces like in serpents tale at all because min_distance is always above some_threshhold. There could be some unwanted side effects though like uphill battle, hi flyer brutals becoming slower osv, because wheel is max close to center of bike there.
Re: Saveload WR table
You can't change the part before without changing the part after o,oZweq wrote:Part before bonceMadness wrote:Nah, you couldn't make a faster start. You would basically get a .dat file and have to start playing from the point where the bike left the ground after the bounce.Zweq wrote:Using kazaan start for pipe is a new refreshing idea, but i think it wouldnt work, we are at the same problem as always. Consider someone makes 0.005 faster start, then can just make same bug as kazan except it's just 0.01 times stronger, something you cannot see or measure, but it is faster. There you go, faster bug was accepted than the previous bug. Then someone improves 0.005 in start again and so on.
I think the only difference here is that due to the direction of the bounce you need and the inclination of the pole you bounce from you have to brake for the whole time without using gas and therefore you can't control the min distance. You always land at a similar speed and angle and the position of the wheel simply can't be much different under these circumstances, unless you want to bounce in a different direction.Zweq wrote:just want to add there are different kind of bounces and fixing bug bounce wouldnt remove all bounces: for example this bounce at 13s has nothing to do with min-distance-from-center-bug http://www.recsource.tv/r/bdovuqeism . This kind of bounce can never result in a bug, ive tried for ages in new wave left wall (before i knew how bugs work).
Also this kind of bounce is always the same looking, without any variation (as long as you get timings right), which is not something you can say about bounces like bowling end (even if you think you get timings right, you might get mega bounces randomly)
milagros' suggestion was something along the lines of: in every frame if(min_distance < some_threshold) offset wheel in correct direction to achieve min_distance >= some_threshold . I might remember the logic terribly wrong, if so, sorry it's my fault not milagros' if such fix was applied it wouldnt affect bounces like in serpents tale at all because min_distance is always above some_threshhold. There could be some unwanted side effects though like uphill battle, hi flyer brutals becoming slower osv, because wheel is max close to center of bike there.
Re: Saveload WR table
i think there is difference, so much actualy that it's totally diff thing. For example you cant bounce to opposite direction with throttle, but you can bugbounce with throttle. This serpents tale bounce just has to do with the brake physics, not with the "dividing stuff with almost 0 results in big number" -> bugbounce. But maby someone like mila or smibu or ropelli can clarify.
Re: Saveload WR table
too bad i didn't do a version 5 years ago with limited bug bounce and fixed 1000 fps simulation speed
at that time i thought recs would not be accepted, because it's not repeatable with original elma
however, now that all the sl is public, it would be way better for saveload wr table
limited bug bounce is easy to do, 1000 fps would require some knowledge I've forgotten (there is somewhere in the code 30fps simulation limit - if you alt+tab and alt+tab back, the run looks like 30fps, that needs to be change to 1000 fps)
for some reason this sl code does not work on win8 (anyone knows some easy way to fix? i guess it has something to do with writing rights to hdd) so i can't really code anything more complicated anymore, because there is no way to test
at that time i thought recs would not be accepted, because it's not repeatable with original elma
however, now that all the sl is public, it would be way better for saveload wr table
limited bug bounce is easy to do, 1000 fps would require some knowledge I've forgotten (there is somewhere in the code 30fps simulation limit - if you alt+tab and alt+tab back, the run looks like 30fps, that needs to be change to 1000 fps)
for some reason this sl code does not work on win8 (anyone knows some easy way to fix? i guess it has something to do with writing rights to hdd) so i can't really code anything more complicated anymore, because there is no way to test
[carebox]
Re: Saveload WR table
I think he meant that you can't disallow improving some part (start of Pipe before the bance) that is probably not 100% perfectly driven.Madness wrote:You can't change the part before without changing the part after o,o
then again i don't know anything
maybe easier not to think abouut alöl things thought than not things thought ... or something..=?
maybe easier not to think abouut alöl things thought than not things thought ... or something..=?
Re: Saveload WR table
thats true, my vote goes for Madness til the bounce of course there can theoretically be a perfect run driven, yea. and how much faster that could be? 0,006? 0,008? 0,009? or even 0,01? so what? which means that we wont have 26.62 in the table, only 26.63...
Kazan's dat file could be a great idea UNTIL a new style is found for the first 4-5 seconds... which i personally think wont ever happen, but who i am to make an assumption like this?
edit:
we will never reach the perfect times in elma, why dont we give a chance for others to perfect pipe style further?
imho only a sikly advanced AI could do perfect drives, but by then humanity will be vanished from earth
Kazan's dat file could be a great idea UNTIL a new style is found for the first 4-5 seconds... which i personally think wont ever happen, but who i am to make an assumption like this?
edit:
we will never reach the perfect times in elma, why dont we give a chance for others to perfect pipe style further?
imho only a sikly advanced AI could do perfect drives, but by then humanity will be vanished from earth
Elasto Mania - 34:21.69 | #421 - 11. April 2024
Ancient Internals
Ancient Internals