:SSchumi wrote:yea. and how much faster that could be? 0,006? 0,008? 0,009? or even 0,01? so what? )
imo i stop discusion here, impsy mentality for z brian
Moderator: Moporators
:SSchumi wrote:yea. and how much faster that could be? 0,006? 0,008? 0,009? or even 0,01? so what? )
This is not a dick measuring contest, so please stay relevant on topic.iltsu wrote:Madness 100- culino 0. Imo
Alright checked them out. 01-08 look buggy to me, 09-20 don't.Madness wrote:Which ones in particular would you forbid? http://kopasite.net/up/ot8jy31nj5e574y/wheel_pops.zip
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.
So do you think wheelpops and stretches are pretty?Madness wrote: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.
Install other operating system to test, in wm if don't want to ruin current install dunno why you would want to keep win8.milagros wrote: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
They're all relatively strong wheel pops. Merge pop20.rec (the weakest wheel pop in the pack) with http://kopasite.net/up/0y222r38uzgxul8/non_pop.rec (these two use the same fps). How do you want to forbid them if you don't even see the visible ones?culinko wrote:Alright checked them out. 01-08 look buggy to me, 09-20 don't.Madness wrote:Which ones in particular would you forbid? http://kopasite.net/up/ot8jy31nj5e574y/wheel_pops.zip
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.
Maybe that's why you don't like them, people often fear the unknown.culinko wrote:I don't think I have experienced any wheelpop in my elma career ever, or at least I haven't noticed them. Maybe I suck or my PCs were all weird, but it's true. And I don't want every replay to have wheelpops in them just because each saves ~0,03. What if your average replay in a longer level in the future has 10 wheelpops in a single ride to save time? Wouldn't it look ugly?
It's not about whether I think they are pretty. The 51 stretch is pretty awesome though, if you ask me.culinko wrote:So do you think wheelpops and stretches are pretty?Madness wrote: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.
my old laptop died and i bought a new one, which had win8 installedbene wrote:Install other operating system to test, in wm if don't want to ruin current install dunno why you would want to keep win8.
I want to forbid the obvious ones which can be easily spotted. If you want to forbid all of of them, someone would need to release a tool to detect them, because I don't think anyone could spot all of them with a naked eye. You can sort out bug bounces with the wheel distance (or whatever it's called), maybe you could sort out wheelpops by some value as well.Madness wrote:How do you want to forbid them if you don't even see the visible ones?
Where is the wheelpop?Madness wrote: Now do you think this WR should be rejected? http://www.recsource.tv/r/ulxnoadhrb
This is such a ridiculous and generalized assumption. I can't drive a WR, therefore "people fear WRs". Wtf? Wheelpops are not unknown, I know they exist.Madness wrote: Maybe that's why you don't like them, people often fear the unknown.
Bene's project was also awesome for me. That doesn't mean I want his times to be in this table.Madness wrote:It's not about whether I think they are pretty. The 51 stretch is pretty awesome though, if you ask me.
I have had no problems with milasl in ubuntu which is fast to get running in a vm for testing.milagros wrote:my old laptop died and i bought a new one, which had win8 installed
But then I will play some level and make 20 differently strong wheel pops at 10 spots (always ask Culino which one of the 20 wheel pops is acceptable before proceeding to the other one) and then someone else does the same, but somehow they will get a better time only thanks to some of their wheel pops turning out to be slightly stronger (even though Culino did his best to judge them fairly). They will have the best time, but I will shout "unacceptable, they only got a better time than me because of buggier wheel pops and Culino allowed them because they are friends!!!"... There's the same situation with bug bounces now (min distance doesn't sort out anything at all). If there's a bounce in the middle of the level which tends to be buggy easily and affects the final time a lot, we can't simply hoyl it, we have to pick one that's fast enough but not too fast, so that the rec doesn't look too buggy. There's simply no competition possible in such levels, if 10 people played them, we would have to choose the most "nice looking" rec to be the WR regardless of the final time. Do you think it's worth having the same issue with wheel pops, considering how hard it is to notice them, judge them and how little they affect the final time (especially in big levels)?culinko wrote:I want to forbid the obvious ones which can be easily spotted. If you want to forbid all of of them, someone would need to release a tool to detect them, because I don't think anyone could spot all of them with a naked eye. You can sort out bug bounces with the wheel distance (or whatever it's called), maybe you could sort out wheelpops by some value as well.Madness wrote:How do you want to forbid them if you don't even see the visible ones?
There's one (maybe even unintentional) that wouldn't be acceptable based on what you picked to be buggy in the wheel_pops.zip pack and so the whole rec would be unacceptable and the WR would have to be deleted from the table. See how ridiculous this is? See why they can't be forbidden?culinko wrote:Where is the wheelpop?Madness wrote: Now do you think this WR should be rejected? http://www.recsource.tv/r/ulxnoadhrb
You know they exist, but as you've probably never bothered to try to play Elma with low fps (to be able to notice them better), you have no clue how they happen and how reproducible they are. There's a huge difference between knowing they exist and having actually tried them for hundreds of hours.culinko wrote:This is such a ridiculous and generalized assumption. I can't drive a WR, therefore "people fear WRs". Wtf? Wheelpops are not unknown, I know they exist.Madness wrote: Maybe that's why you don't like them, people often fear the unknown.
As I said before, I don't see reproducibility as a valid point to decide whether an interaction is a bug and whether it should be accepted. There should be other measures to decide if a replay is "legit". Also, I think it was b0ne who mentioned that wheelpops are indeed bugs. I don't see why some kind of bugs are accepted are some don't. I thought if we're gonna get rid of bugs, we're gonna rid of them all.Madness wrote:you have no clue how they happen and how reproducible they are
You first said you wanted to forbid the obvious ones which can be easily spotted and that's what I was referring to. If there was a program, it would be a different story, but there isn't any now.culinko wrote:I said that a best solution would be to make a program which should validate all the bugs (wheelpops included) and you just made fun of me accepting stronger wheelpops for my friends. I honestly don't know why you did that.
I'm glad we've got to agree on something - there would have to be a program for it, which means we can't do anything about it now. In any case, if there was a program like this, it wouldn't accept Zweq's int15 45.35 unless it was able to calculate how much advantage the wheel pop gave him and how much advantage is acceptable to gain from a wheel pop at a certain speed. The (visible) wheel pop is at 26.60 by the way.culinko wrote:Before watching the rec pack, I admit I didn't know that wheelpops can be so subtle and hardly visible to the human eye. Before watching it, I thought that all wheelpops are visible, that's why I wanted to forbid them all. But now I just want to forbid the ones that are clearly visible, because I think pressing a wheel near the polygon should not suddenly give it higher speed for a split second. But again, that should be a work of some "rec validator" program which should sort out the "good" ones from the "bad" ones. So the Zweq's replay would most likely be accepted.
The point of this table is to make it as similar to regular playing as possible. Reproducibility is the vital point. Whether something is a bug (an error that wasn't intended to work like it does) is irrelevant if the bug is easily reproducible or can't even be avoided. Whether something looks pretty is even less relevant.culinko wrote:As I said before, I don't see reproducibility as a valid point to decide whether an interaction is a bug and whether it should be accepted. There should be other measures to decide if a replay is "legit".Madness wrote:you have no clue how they happen and how reproducible they are
For me it's some kind of "validator" program, but the community needs to decide how it's being validated. This is the entire point why I started the discussion in the first place and I'd like more people to contribute and post their suggestions about this.Madness wrote: If not reproducibility, then what should be the valid point to decide what should be accepted?
My opinion is that this is fine, because it's possible without SL too (timer on/off, programs in the background that you can operate by a hotkey and happen to decrease Elma fps...). Maybe it would be best to implement this feature into the regular EOL. After a few years people won't complain about it anymore and will learn to appreciate it (just like alovolt button).Zweq wrote:- FPS switching, possibly mongo / problematic, needs discussion osv
This is the same issue - FPS switching.Zweq wrote:- mega stretches, maybe some discussion is needed about tricks abound because of rabid FPS switching, but animal farm and fruit in the den use single fps value so those should be cool.
Nice rec, thanks for sharing it.Zweq wrote:here hi flyer 24:98 http://www.recsource.tv/r/mivjpzuclo for tablle, ancient rec, didn't know i never shared it o_O
Alovolt is a bug in the same way that wheelpops are. Should we disallow them from the table?culinko wrote:I don't like bugs in general in any game and previously asked b0ne (I think) if the wheelpop is a bug. He confirmed that indeed it is so once Madness tried to get rid of the bugs.
Would like to hear more about at least some of these solutions.Zweq wrote:I think it should be like this:
- bug bounces, the real problem that needs solving. There are bunch of solutions, each one with its own pros and cons.
If there was to be a constant fps, it would most likely be 1000 fps. Low fps causes most of the randomness and you wouldn't want to keep it just to be able to do the Shelf Life trick, which is not right either after all. If the hole is smaller than the wheel - you shall not pass!Tm wrote:Wheel pops - I'd argue for leaving it as it is, as it is a natural phenomenon in Elma's gameplay. If wheel pops nature differs from fps to fps, I'd argue for simulating Elma's physics somewhere on such fps value which allows player to be able to do most of tricks: brut bounces, shelf life hole, sliding etc. If there's no such value - dunno.
What about Animel Fram trick? What fps it requires to do it correctly?Madness wrote:If there was to be a constant fps, it would most likely be 1000 fps. Low fps causes most of the randomness and you wouldn't want to keep it just to be able to do the Shelf Life trick, which is not right either after all. If the hole is smaller than the wheel - you shall not pass!
Tm wrote:Would like to hear more about at least some of these solutions.Zweq wrote:I think it should be like this:
- bug bounces, the real problem that needs solving. There are bunch of solutions, each one with its own pros and cons.
The criterion, that may go alongside reproducibility, could be naturalness of gameplay. I mean that anything interfering with gameplay outside Elma's mechanics (e. g. software running in a backgroud) should be taken into account and eliminated. Argument like this would remove FPS changing during the run option. Therefore, I'd argue for static FPS at the same time being against Trick Abound stretching or other things coming from FPS change during the run. // Just read Madness reminder of timer on/off here. That makes me hmm...
Talking about bugbounces from what I've read, programming for some distance value from the center of the bike seems the most reasonable solution right now (tho, would like to hear more solutions). In a perferct world, I'd prefer someone with extra-master programming ability to programme for different distances and community could decide on the value most agree as acceptable (ofc there would be no unanimous decision, but democratic way seems most logical anyways [maybe even make a jury of pros, that could make their vote]). On the same theme - leave serpents bounce type of bounces in different natural category.
Wheel pops - I'd argue for leaving it as it is, as it is a natural phenomenon in Elma's gameplay. If wheel pops nature differs from fps to fps, I'd argue for simulating Elma's physics somewhere on such fps value which allows player to be able to do most of tricks: brut bounces, shelf life hole, sliding etc. If there's no such value - dunno.
[I nab at elma physics understanding, so please forgive]
as far as i know the randomness comes from unstatic timestepdawid wrote:What about Animel Fram trick? What fps it requires to do it correctly?Madness wrote:If there was to be a constant fps, it would most likely be 1000 fps. Low fps causes most of the randomness and you wouldn't want to keep it just to be able to do the Shelf Life trick, which is not right either after all. If the hole is smaller than the wheel - you shall not pass!
EDIT:
PS. Elma is always little random because of float variables. Autolevs not always run the same.
Almost true. You can still experience differences because of floating point if you run same inputs on another computer. Solvable ofc but not part of current Elma. Most of the randomness is from unstatic timestep however.Zweq wrote: as far as i know the randomness comes from unstatic timestep
added that to the listculinko wrote:Another cons for using 999 or 1000 fps is that older PCs (which people sometimes use exclusively for elma) wouldn't work.
I don't think this is true at all. You could still play the game with lower fps (the maximum fps that your old computer would allow you to see), but it wouldn't make any difference on the physics.culinko wrote:Another cons for using 999 or 1000 fps is that older PCs (which people sometimes use exclusively for elma) wouldn't work.
I meant if you make elma run 999 fps and somehow forbid the use of any different values.Madness wrote:I don't think this is true at all. You could still play the game with lower fps (the maximum fps that your old computer would allow you to see), but it wouldn't make any difference on the physics.
there was some bug on pentium60, but as far as know know the results are the same on all current co-processorsbene wrote:Almost true. You can still experience differences because of floating point if you run same inputs on another computer.
as always, you forgot to share your knowledge with usbene wrote:As always you forgot times Madness.
I never forget! You forgot to send me a PM.. It's there now.bene wrote:As always you forgot times Madness.