The fastest possible internal times program

[milagros]

even if it was feasible, it would be kinda useless
I guess an optimal run on labpro would be pretty sick and retarded:)
even with much simple approach you can get times like 8.xx warmup, 8.xx flattrack, 9.xx twinpeaks, 6.xx freefall or 7.xx enigma

[Zweq]

just take first 2 apples in lab pro with both wheels and head in same frame then 1000000000 speed darm bounce with 30fps towards flower through poligons say no to collision detection 20.63 AHAHAC

[Bjenn]

This swiftly developed into an out-of-hands debate.
with this state of mind, ez 5min tt xd

[Zweq]

well, in theory 10-15 min TT is definitely achievable, if you do everything within the rules of the game engine and without arbitrary limitations like "no bugs", however I have no idea who would want to höyl apple harvest for 10 bug bounces and 6 apple bugs

edit: i dont know how to summarize my brain, something like: optimizing is always interesting problem, but i think in elma it's not interesting because what i've talked with mila you need an initial solution for the computer to optimize and then even small improvement in the initial solution is much more valuable than the optimization, and when you do apple bugs and bug bounces the initial solution can always be improved (pretty safe to say)

[Mawane]

actually taking an apple with head+wheel+wheel at the same time = 3 apple takes, so much possibility!

[dawid]

actually taking an apple with head+wheel+wheel at the same time = 3 apple takes, so much possibility!

IMO we cant accept apple bugs in calculations. We need to use "elma 2" physic (without internal error)

[Mats]

Need to use the MAThS solution. Just use this formula ((54 Levs+24 bugs)/42 billion outcomes +20 million random factors)= best theoretical TT 22.25.71* Human factor 1,47= best human TT 32.12.99

[ribot]

How come no one proved jonsykkel wrong here?

First of all the approach to calculate this on all possible keypresses is just dumb. Although he did mention that you don't have to calculate deaths, there is a lot more to it. The finding of the algorithm is the key here, and that is the path that future computing is taking. You wouldn't need to calculate jon's six states when the bike is in the air, gas if backwheel doesn't touch ground. Neither would you need to test what happens if you try to turn a thousand times or 999 times. The calculation would of course need to be a lot more complex, but in return, you can reduce those extreme numbers.

Just imagine if you would calculate how to win an F1 race by calculating all possibilities of gas, break, steer. It's absurd. You can however optimize many different things. Translated to elma, you could try to find higher speeds in different places for example. The answer lies in AI, whether you could find the theoretical absolute or not.

Second of all, computers are estimated to be a lot faster than what Moore's law predicts. Thirdly, artificial intelligence is estimated to become more intelligent than our own processing skills in not-so-far future.

[Lousku]

You wouldn't need to calculate jon's six states when the bike is in the air, gas if backwheel doesn't touch ground.

Sure you would, it affects rotation. But yeah, it can be more optimal than pure bruteforce. This just isn't a very fruitful discussion until someone proposes some idea of an algorithm.

Simpel exampel problem: how to prove that it's fastest to just hold gas for 4 seconds in the start of hi flyer?

edit: lol

[jonsykkel]

First of all the approach to calculate this on all possible keypresses is just dumb.

yes, and that was dawids idea:

program should calculate all possible combinations of rides (up to a appointed time of ride)

im never said writing a program that can play elma a milion times beter than humans is impasibel, but this was about finding an optimal run

You wouldn't need to calculate jon's six states when the bike is in the air, gas if backwheel doesn't touch ground.

not true, change of wheel rotation sped affects bike rotation sped

Neither would you need to test what happens if you try to turn a thousand times or 999 times.

if you start doing stuff like that you cant be sure you get the absolutely optimal run, unless cane somehow prove that it doesnt make a diference

[dawid]

First of all the approach to calculate this on all possible keypresses is just dumb.

yes, and that was dawids idea:

program should calculate all possible combinations of rides (up to a appointed time of ride)

im never said writing a program that can play elma a milion times beter than humans is impasibel, but this was about finding an optimal run

Look at first post of this topic. I edited it.

[ribot]

You wouldn't need to calculate jon's six states when the bike is in the air, gas if backwheel doesn't touch ground.

not true, change of wheel rotation sped affects bike rotation sped

Neither would you need to test what happens if you try to turn a thousand times or 999 times.

if you start doing stuff like that you cant be sure you get the absolutely optimal run, unless cane somehow prove that it doesnt make a diference[/quote]
It's easily provable using the game physics.

Anyway, to prove jon more wrong: as autoplay works differently every time, so even if each frame has so many combinations, even the exact same keypresses wouldn't result in the same ride. How would you even know when you have calculated all possibilities for the first frame?

We also need to add each possible framerate, and vsync on or off. But is that even enough?

[jonsykkel]

It's easily provable using the game physics.

no

Anyway, to prove jon more wrong: as autoplay works differently every time, so even if each frame has so many combinations, even the exact same keypresses wouldn't result in the same ride.

then that autoplay thing obviously isnt synced with the elma physics, it probably just records keypreses inaccurately in a loop and plays them back. there're no random factors except for the fps thing

We also need to add each possible framerate, and vsync on or off. But is that even enough?

vsync on/off just determines the fps so thats not a factor, and yes its enough

[-T0ny-]

sykkel is right, stop arguing

[ribot]

If the fps thing is a random factor than how would you even calculate the first frame?

[milagros]

ribot is wrong, jonsykkel is a bit less wrong:)

[dimkadimon]

Guys, I've suggested this about 5 years ago: http://mopolauta.moposite.com/viewtopic.php?f=1&t=6068

I still think this is possible. In fact I could probably do it if someone gives me the source to Elma or at least tells me how the physics works.

[milagros]

go for it!

[dimkadimon]

go for it!

I need the source or the equations...

[dawid]

look at this https://www.youtube.com/watch?v=ZCenGtuYy-I

[dimkadimon]

look at this https://www.youtube.com/watch?v=ZCenGtuYy-I

Very cool! Luckily we don't need to consider all those extra forces in 3 dimensions.

[dawid]

dimkadimon, is your idea coherent with avolt?

[dawid]

Interesting: http://www.newscientist.com/article/dn2 ... games.html

[FinMan]

Give elma to that and it won't finish warm up, gg