another new eol question mark topic

Feature requests and ideas for the new unofficial versions of Elma and general talk related to those.

Moderator: Moporators

User avatar
Labs
37mins club
Posts: 1213
Joined: 2 May 2005, 14:20
Team: SPEED
Location: Hungary
Contact:

Re: another new eol question mark topic

Post by Labs »

Labs wrote: 30 Jul 2019, 14:54
nick-o-matic wrote: 30 Jul 2019, 13:59
Labs wrote: 29 Jul 2019, 16:39 I think 2 thing can run on the same server.
So if you enter an internal, you will have the classical physics, and if you enter an external, you would have the fixed high-fps physics.
What? I meant that the 2 game could run on same server (no need to pay 2 server for that i think). Not that you have to play the old eol if you want to play internals. If you want make new wr on old eol, you could do that on the old eol. okeol would have ofc new wr table, which is very logical, since many styles and times is impossible with high fps.

Ofc can simply turn off old eol and no more updates of the "old" wr table.
Team SPEED

Image
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

Labs wrote: 30 Jul 2019, 14:54
nick-o-matic wrote: 30 Jul 2019, 13:59
Labs wrote: 29 Jul 2019, 16:39 I think 2 thing can run on the same server.
So if you enter an internal, you will have the classical physics, and if you enter an external, you would have the fixed high-fps physics.
What? I meant that the 2 game could run on same server. Not that you have to play the old eol if you want to play internals. If you want make new wr on old eol, you could do that on the old eol. okeol would have ofc new wr table, which is very logical, since many styles and times is impossible with high fps.

Ofc can simply turn off old eol and no more updates of the "old" wr table.
Well I was thinking that you were not meaning it like that but I quoted you because I thought it was idea to the same direction anyways and I did not want to something like ignore your post. Sorry for being unclear.

8-ball wrote: 30 Jul 2019, 14:11 i'm not convinced, i think there should be no exceptions for legacy physics. turning over the page in history doesn't invalidate the impact of legacy records. everything that was worth seeing has already been immortalized in compilation videos, not to mention that you could still browse history and download recs from moposite and watch them in any legacy elma if you feel like it, and there would still be recsource. i think it's a niche concern that would unnecessarily delay work on more important things in game. fixed fps wr table would be 34 mins in no time anyway and that in and of itself would be exciting to witness.
It is niche for any new player but a huge question for quite many people in the current scene. This is an enormous decision and "delaying work" is quite small thing here imo. Also having two different WR tables means quite much extra work due to having to take care of old EOL as well and not to be able to shut it down (whether or not it was running in different or same server as Labs suggested).
iltsu
37mins club
Posts: 248
Joined: 25 Aug 2011, 19:15
Team: EF

Re: another new eol question mark topic

Post by iltsu »

I want to keep elma and eol the way it is now. Imo its great that someone is so pro at this game that he can do fps, vsync, and wheelpop trickery. I cant and i dont mind it.
User avatar
jonsykkel
Kuski
Posts: 982
Joined: 24 Nov 2009, 20:53
Contact:

Re: another new eol question mark topic

Post by jonsykkel »

nick-o-matic wrote: 30 Jul 2019, 13:59 Balazs' iOS elma was apparently quite big fail, but apparently he does not want to entirely sell elma. But he does not have to. Something like this would be good for us (not having to find impsy moneies to pay for him at the day one) and good for him (he still has elma rights and he does not have to do anything to get some money out of it). We should take immediate action to contact Balazs about this, especially since jon himself apparently agrees.
8bal has showed himself wiling to negotiate with balazs, so he will be contacted soon i guess, thx 8bal


nick-o-matic wrote: 30 Jul 2019, 13:59 I have always dreamt that in the new version of elma you could go to an internal and from some menu see the WR history and eye all the shared WR recs and also see the world top 1000 and see all the shared recs osv osv. That should be amazingly fun and interesting also for new players who are learning to play. But that would not exactly fit well with fixed physics for internals...
this is very similar to some of the ideas i have, it should be possible to go in any level and see the best times, when they were made, wr development, all public reks osv for that level easily

there is a lot of history in curent database, times for both externals and ints, would be sadik if that information just disapears if go new game, so would probably copy that data from the old db and there would be another shift+f5 list for legacy times/reks/vatever in all levels

im dont know why it wouldnt fit well with fixed physics ??? pls explain


nick-o-matic wrote: 30 Jul 2019, 13:59 So if you enter an internal, you will have the classical physics, and if you enter an external, you would have the fixed high-fps physics. This system has some obvious idiot system flaws (already pointed out), but a flawless solution is simply not poss here and imo this is the most optimal solution to this situation. Two different WR tables would be the most horror ever imo, sorry. Also some mongoness of the classical physics could be avoided by making FPS change poss to be made in-game and to be level-specific. You could set a default FPS for int 31 without affecting other levs. And you could do that from the level itself, without going to some settings menu in the main menu of the game.
its just too ugly to have 2 versions of the physics in the same game (not to mention a lot more vork making it and maintaining it, especialy since they have 2 completely different rqeuirements for antixiit systems). it makes everything not simpel, like it should be
it has to be a single coherent game, whether that means only old fuked physics or new

why is 2 different tables horror? was it horror when elma replaced acros and it had new table? would it be beter if elma had same physics and wrtable as across?


nick-o-matic wrote: 30 Jul 2019, 13:59 Höyling for WRs is a really miniscule part of elmaing already nowadays, there's some 5 players doing that.
(...)
Even nowadays most people who have gggggot good do not play ints.
maybe there is a reason for this
and if its the case that the reason is fps nonsense etc, i dont know why anyone would want to compete against a small subset of pros instead of all pros


nick-o-matic wrote: 30 Jul 2019, 13:59 29) Actually ggggettin' good at internals and going for WRs yourself. Even with fixed internal physics new players would not start competing with Spef, Zweq and others.
true of course, but with old phyics there are probaly many pro players who have the skill to compete in internals but just dont want to torture themselves with the low fps game. litel bit spekulation maybe, but at least i know if i was skiled enough to get wrs and sach i wouldnt want to just because it would mean dealing with guessing corekt fps nonsense and the randomness inherent to low fps.

if you think you can be as consistent with 30fps as with 1000fps you are wrong, sry. you cant possibly synchronize your brain to the points in time where the input is sampled (every 33ms at 30fps. this is a long time) and predict the exact input latency for every keypress. it is in practice: random
just to clarify if someone thinks im saying its all luck: no, obviously its still 97% skill


nick-o-matic wrote: 30 Jul 2019, 13:59 Antixiit things are super preliminary at this point. Tiny randomness would not really help in fighting against autoplay imo. You can always drive a SL ride to the start of some level and then autoplay perfect starts every try because randomness should not be big enough to affect starts of levels. That is already an enormous advantage especially in some levels. Imo the only solution is to store all the buttonpresses with some gamestates and to spy the player playing the level to analyze by both programs and eye if the hoyling process looks natural (some admins should be able to spy also hidden players).
im dont think should underestimate importance of proper working antixiit
if this game should happen to become xtreme popular (not super likely maybe but always beter to prepare for "worst" case scenario). xiiting hasnt even really been a big problem so far imo, not that many cases historicaly, and its just luck that darmoed xiit recs were detectable for instance. but it would be a big problem if there were many 1000s of players al of a sudden. game should not immediately shatter into pieces under a litle bit of stress (eol/pexi looking at recs system in its current state would)

autoplaying the same inputs over and over again for your start is easily detectable automatically


nick-o-matic wrote: 30 Jul 2019, 13:59 Sad if Smibu's Elma 2 can't be used as a base. But perhaps some blocks of code, or at least some ideas in Elma 2 code, could be useful...? Perhaps after all his work Smibu could give some comments and advice and ideas for this project...?
its very posible there are parts that are usable, example of top of head is gras rendering is something very anoying to implement that i dont have curently in my renderer
status:ONLINE - - -  drinking:GOFE - - - iq:85 - - - elasto mania ranking:#1
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

Sorry for kinda forcing you to use time to a long post, should have talked in some chat for more effective discussion :P I hope I don't do it again now.

First of all it is gonna be your elma and you can do what you want and it is gonna be awesome and I am going to support you to the max in any case. I am just giving my physics onions ^^
jonsykkel wrote: 30 Jul 2019, 21:50 there is a lot of history in curent database, times for both externals and ints, would be sadik if that information just disapears if go new game, so would probably copy that data from the old db and there would be another shift+f5 list for legacy times/reks/vatever in all levels

im dont know why it wouldnt fit well with fixed physics ??? pls explain
Well if you had two different shift+f5s then it would be poss sure. But it is still weird for new mans to eye legacy int31 recs and not to be able to repeat without downloading some old elma.
jonsykkel wrote: 30 Jul 2019, 21:50 its just too ugly to have 2 versions of the physics in the same game (not to mention a lot more vork making it and maintaining it, especialy since they have 2 completely different rqeuirements for antixiit systems). it makes everything not simpel, like it should be
it has to be a single coherent game, whether that means only old fuked physics or new
I understand very well that technically it would be mongo to implement the old physics side-by-side with new physics where a lot of things would have been fixed (not just that one weird code loop and the bugbounces). Without going into technical details all I would like to have is: adjustable FPS knob (as we now have in eolconf) which allows you to change physics to do vsync and pop stuff and to keep old WRs in internals and any external valid and to avoid two shift+f5s. With going into technical details: is it any poss to keep the fps-dependency of physics and at the same time fix the technical side in the physics with neglible change to gameplay, and then keep fps locked to 999 in most levels and allow different values in ints and other special occasions? This way we would always have technically the same physics and there would not be a need for two different antixiits. This would be pretty much equal to today's elma and the eolconf fps knob, with an exception of fixing the most obvious physics problem: different physics for different people at balles. Imo it's win-win. But if it is not possible then it is not possible =(
jonsykkel wrote: 30 Jul 2019, 21:50 maybe there is a reason for this
and if its the case that the reason is fps nonsense etc, i dont know why anyone would want to compete against a small subset of pros instead of all pros
jonsykkel wrote: 30 Jul 2019, 21:50 true of course, but with old phyics there are probaly many pro players who have the skill to compete in internals but just dont want to torture themselves with the low fps game. litel bit spekulation maybe, but at least i know if i was skiled enough to get wrs and sach i wouldnt want to just because it would mean dealing with guessing corekt fps nonsense and the randomness inherent to low fps.

if you think you can be as consistent with 30fps as with 1000fps you are wrong, sry. you cant possibly synchronize your brain to the points in time where the input is sampled (every 33ms at 30fps. this is a long time) and predict the exact input latency for every keypress. it is in practice: random
just to clarify if someone thinks im saying its all luck: no, obviously its still 97% skill
Lol ints are not just 30 fps torture =) Half of the levs if not 2/3 are 999fps levs (or at least high fps levs). Ofc the main attention has lately been with low fps levs due to pops and new int51, so it ezily skews man's perception. But is there even a single 30fps int? Most low fps ints are closer to 60fps (which is already a lot more playable), aren't they..?

This is highly subjective, but I feel like that the randomness and magic times in some short ints is kinda fitting to the eternal story of internals. Internals should be hoyled to the extreme and if you can find some 0.01sec from some quantum fluctuations I say sik nice. Low fps brings randomness to both bike behavior and to input delay, but this kind of extra difficulties and even mongoness along with the search for exactly correct fps is maybe not entirely bad thing in super-highly competitive short ints.
jonsykkel wrote: 30 Jul 2019, 21:50 im dont think should underestimate importance of proper working antixiit
I didn't mean to underestimate it, it's super important and everyone agrees there must be very good antixiit =) Just legal issues and physics questions are the most urgent because they affect the most how the project should be started.
User avatar
jonsykkel
Kuski
Posts: 982
Joined: 24 Nov 2009, 20:53
Contact:

Re: another new eol question mark topic

Post by jonsykkel »

nick-o-matic wrote: 30 Jul 2019, 23:04 Sorry for kinda forcing you to use time to a long post, should have talked in some chat for more effective discussion :P I hope I don't do it again now.

First of all it is gonna be your elma and you can do what you want and it is gonna be awesome and I am going to support you in any case. I am just giving my physics onions ^^
its absolulty NP, there needs to be a good discussion, onions from all ppl is needed, this is why im made the tropic
beter that things are written on a usable vebsite than in shitik discunt log which is imposible to use/search
this way everyone can have a chance to read and respond


nick-o-matic wrote: 30 Jul 2019, 23:04 Well if you have two different shift+f5s then it would be poss sure. But it is still weird for new mans to eye legacy int31 recs and not to be able to repeat without downloading some old elma.
yep but its gona be weird no matter what we do, as you said in prev post there realy are only bad options here, question is which one is least bad


nick-o-matic wrote: 30 Jul 2019, 23:04 I understand very well that technically it would be mongo to implement the old physics side-by-side with new physics where a lot of things would be fixed (not just that one weird loop and the bugbounces). Without going into technical details all I would like to have is: adjustable FPS knob (as we now have in eolconf) which allows you to change physics to do vsync and pop stuff and to keep old WRs in internals and any external valid and to avoid two shift+f5s.
if i go with old physics there would be fps knob and so on yes


nick-o-matic wrote: 30 Jul 2019, 23:04 With going into technical details: is it any poss to keep the fps-dependency of physics and at the same time fix the technical side in the physics with neglible change to gameplay, and then keep fps locked to 999 in most levels and allow different values in ints and other special occasions? This way we would have technically the same physics in every case and no different antixiits needed. This would be exactly equal to today's elma and the eolconf fps knob, with an exception of fixing the most obvious physics problem: different physics for different people at balles. Imo it's win-win. But if it is not possible then it is not possible =(
its not that its not poss to do weird hybrid solutions like this, its more that it wouldnt solve what the actual main problem is, which is (in my estimation):

with fps dependency, the game is too complicated

one aspekt of vat makes a game good is that its a ___simpel__ alternative to horror real life with its complexity
why would u play 1997 2d motor bike instead of buy real trial bike?
becuz dont have to vork for 5 years to have money for it, dont have to pay for gas to use it, dont have to risk breaking ur legs bones, donth ave to fix it when u drive it throguh lake and get 4 liter of vater in the oil

take the idea of "riding moto bike" and boil it down to the fundamental concepts that make it interesting, gz now u have a good game

fps dependency makes the game not simpel anymore, fewer ppl want to play it that way
it also makes it less like what it should be (imo), a 100% pure skill based game, it just makes it a worse game. not everyone can see that it seems but im very convinced its true

not saying it doesnt take skill to master guessing/figuring out the right fps, doing low fps tricks or anything, obviously it does. but there is an undeniable component of luck associated with low fps playing just because of the low input sampling rate, unperfect fps limiter (this one thing could be fixed of course, but then it wouldnt be exactly the same as the old game), very big number of usable fps values that could all potentially be "magic" values

maybe the more important point though is that not very many people want to play the game like that

if have both physics in the same game there would always be this question of whether to use this or that, its not good


nick-o-matic wrote: 30 Jul 2019, 23:04 Lol ints are not just 30 fps torture =) Half of the levs if not 2/3 are 999fps levs (or at least high fps levs). Ofc the main attention has lately been with low fps levs due to pops and new int51, so it ezily skews man's perception. But is there even a single 30fps int? Most low fps ints are closer to 60fps (which is already a lot more playable), aren't they..?
as far as i know most ints are played with ~30fps or ~75fps these days (?), 60fps animal fram and 1000fps uphil batle. im dont know tbh, need zamppe spef bene promans to comment on this one


nick-o-matic wrote: 30 Jul 2019, 23:04 This is highly subjective, but I feel like that the randomness and magic times in some short ints is kinda fitting to the eternal story of internals. Internals should be hoyled to the extreme and if you can find some 0.01sec from some random quantum fluctuations I say sik nice. Low fps brings randomness in both bike behavior and to input delay, but this kind of extra difficulties along with the search for exactly correct fps is maybe not just a bad thing in super-highly competitive short ints.
if you take this hoyling them to the extreme thing seriously, you can also find things like this https://www.youtube.com/watch?v=IocsDW2KLEs


nick-o-matic wrote: 30 Jul 2019, 23:04 I didn't mean to underestimate it, it's super important and everyone agree there must be that =) Just legal issues and physics questions are the most urgent because they affect the most how the project should be started.
oke oke
legal issues not very big deal imo, whether balazs vants to cooperate or not is his decision, not mutch anyone can do about that other than wait for his reply) i dont think it changes the way i would go about makeing this thing
but yes, physics thing needs to be sorted before i can realy start hoyling this
status:ONLINE - - -  drinking:GOFE - - - iq:85 - - - elasto mania ranking:#1
User avatar
Labs
37mins club
Posts: 1213
Joined: 2 May 2005, 14:20
Team: SPEED
Location: Hungary
Contact:

Re: another new eol question mark topic

Post by Labs »

nick-o-matic wrote: 30 Jul 2019, 23:04 Without going into technical details all I would like to have is: adjustable FPS knob (as we now have in eolconf) which allows you to change physics to do vsync and pop stuff and to keep old WRs in internals and any external valid and to avoid two shift+f5s. With going into technical details: is it any poss to keep the fps-dependency of physics and at the same time fix the technical side in the physics with neglible change to gameplay, and then keep fps locked to 999 in most levels and allow different values in ints and other special occasions? This way we would always have technically the same physics and there would not be a need for two different antixiits. This would be pretty much equal to today's elma and the eolconf fps knob, with an exception of fixing the most obvious physics problem: different physics for different people at balles. Imo it's win-win. But if it is not possible then it is not possible =(
I think for bug bounces its needed to know the fps, so what makes bugbnc in 60 fps, its maybe not makes bugbnc at 1000fps etc. So a fixed high fps is a need (it was discussed in saveload wr table topic i think). Also giving fps values to exact internals is a very bad thing if its just to make some "bug" styles possible. Pipe wr is already bugbnc tho, and enigma is forever indecisive. With new physics there wouldnt be such occasions, which would also freeing out px from his deadly big pain job with wrtable updates. After sometime even a superpx couldnt decide if smth is valid legit wr or not.
Team SPEED

Image
User avatar
skint0r
39mins club
Posts: 768
Joined: 16 Jun 2002, 07:36
Location: Oslo, Norway

Re: another new eol question mark topic

Post by skint0r »

I don't know why anything from old Elma should be there in game, even this alternate shift+f5 thing. If someone wants to see old times go look at old tables or that info elsewhere? As other man said, people moved from Across to Elma just fine, no one gives a shit about old Across times anymore. I know I never drove any WR or good times so maybe I'm biased in not caring and can understand that might someone feel their several months/years of work were wasted or whatever, but then again why keep old EOL/Elma alive just for their sake and keep happy, meanwhile hindring any progress just because afraid of making someone feel a bit sad or quit. Or maybe I'm old grump that don't think these wheelpops and low-fps WRs etc are any fun or good for game except for alienating many people. If someone wants to bother with old Elma/EOL let them and hopefully most people just move to new version and fuck all who cares if people split. Over time assuming new EOL is better (how hard can be), more people will play it. I'm tried understand reasoning for keeping old things but still have max hard time understanding why people very defensive about it and unable to let go, very ???
Prestigious member of 14.6x Tutor14 club
User avatar
ArZeNiK
37mins club
Posts: 883
Joined: 30 Jul 2016, 09:18

Re: another new eol question mark topic

Post by ArZeNiK »

pardon me for interfering in a discussion about a more than 20-year period which i haven't even lived all of, but i suppose across was easier to let go since it wasn't "tamed" as much (as in: got its physics as much understood and exploited, and times so much lowered to perfection) as oldelma (current), since it was only around for 3 years, compared to almost 7x the time that oldelma lived with us. so it's understandably harder to turn over to okeol since we have achieved a great multiple of the things ppl of across have done
hi im arzenik :>
elmzuke.lev is the greatest piece of art ever created
Image
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

jonsykkel wrote: 30 Jul 2019, 23:54 if i go with old physics there would be fps knob and so on yes
Hold on - please define what you mean with new physics. My old perception was that "new physics" = partly rewritten physics engine, where several badly coded things are fixed, allowing 999fps even with the badest laptop and removing weird stuff like elma not behaving 100% same at different computers even at same fps. Along with fixed bugbounces and physics fps-dependency. So I understood that the fps thing might not be an integral part of the new physics engine. But do you mean that it actually is? Before continuing the discussion it is imo pretty much vital for everyone to have a clear picture what is your full plan with the physics engine and how your full plan is reduced if the fps knob was there, and what could not be done if we want to keep old internal and external WRs valid.
jonsykkel wrote: 30 Jul 2019, 23:54 fps dependency makes the game not simpel anymore, fewer ppl want to play it that way
it also makes it less like what it should be (imo), a 100% pure skill based game, it just makes it a worse game. not everyone can see that it seems but im very convinced its true
I can totally see all the bad elements of the fps-dependency. It is ugly how artificial the complexity dimension introduced by it is. It is ugly how it is coded. It is ugly how the low-fps version of the physics leads to some randomness and how it forces you to have random input delays, and thus reduces the skill element. On the other hand, I can also see some beauty over there. It is quite elegant how this kind of small parameter change leads to such huge differences in bike physics at some situations (contrary to intuition). It is pretty freaking elegant and beautiful how something like the new int51 style is possible. In the case of moderate vsync holes such as int45 start it even adds a little bit of fun into the playing (imo high-fps sink start is super slow and boring to play). Also not-so-moderate vsync holes can be fun to play and elegant such as int31 start (well it looks fun, I have just spied people in EOL, not done it myself).
jonsykkel wrote: 30 Jul 2019, 23:54 weird hybrid solutions
I am not completely sure how this is a hybrid solution because it is close to the situation today. Or it depends on the technical implementation. Have to wait for your reply about that first.
jonsykkel wrote: 30 Jul 2019, 23:54 yep but its gona be weird no matter what we do, as you said in prev post there realy are only bad options here, question is which one is least bad
Imo the "hybrid solution", if technically possible, minimizes the ugliness and maximizes the beauty sections.
  • Maximizes the beauty by applying the unanimously beautiful and fully fixed high-fps physics to more than 99% of the levels.
  • Reduces the ugliness by allowing low-fps physics with some ugliness only in the levels where they are actually vital (= internals and some carefully chosen externals).
  • Avoids the ugly solution of two-shift+f5s.
  • Avoids the alternative ugly solution of not having legacy shift+f5 at all and having to go for old sources to see the old times in any old norm (=high-fps) internal or external.
The only concern I have here is that will the low-fps-physics elmaing (mainly some of the internals) become too much about pops. Will some currently high-fps levs be converted into low-fps pop levs? Would be nice and even necessary to see some pro internalist comments here about pops and low-fps hoyling in general, not just my non-internalist opinions. Some questions:
  1. How many internals are 999fps or very high fps?
  2. How fun it is to hoyl short levs like 01, 02 and 44 with low fps? How would hoyling these levs be like with high fps?
  3. How fun it is to hoyl long levs like 31, 51 with low fps?
  4. How widespread are the pops going to be in the future if pop-physics preserve? Would we see pops in nearly every new WR? Would some currently high-fps levels be converted into low-fps levs due to pops?
jonsykkel wrote: 30 Jul 2019, 23:54 if you take this hoyling them to the extreme thing seriously, you can also find things like this https://www.youtube.com/watch?v=IocsDW2KLEs
Labs wrote: 31 Jul 2019, 00:20 I think for bug bounces...
The bugbounces are not gonna be a concern in new elma anymore as discussed in this jon's paragraph =)
jonsykkel wrote: 26 Jul 2019, 18:42 yes, the reason they happen is this place in the code where you have 1.0 divided by the length of bike->wheel vector, so you can just pretend that length is slightly longer than it is if its too close to 0, that fixes it without making normal bounces any different
the threshold can be determined by experimentation, checking against borderline bug .dats etc. tested it quickly now with threshold = 0.01 and with fix in place it runs all the normal .dats (including normal bounces) i tested perfectly but bug .dats dont work anymore
Moreover, as a side note, even with old elma engine it would be poss (atleast imo) to get rid of bugbounces with a new .rec format where every frame and button presses are saved (because it lets you to see the length of bike->wheel vector when brake press occurred and we could check if it was below the new thereshold).
Labs wrote: 31 Jul 2019, 00:20 Pipe wr is already bugbnc tho
As another side note: It would be very interesting to know what the bike-wheel distance is in the pipe WR style rides. Imo I have heard opinions that pipe WR bnc is not really a bug bnc. The pipe WR-style .dat files might be an excellent starting point for looking for the thereshold value.
skint0r wrote: 31 Jul 2019, 06:19 I don't know why anything from old Elma should be there in game, even this alternate shift+f5 thing. If someone wants to see old times go look at old tables or that info elsewhere? As other man said, people moved from Across to Elma just fine, no one gives a shit about old Across times anymore.
Across is not a valid comparison because of fundamental reasons:
  1. Across-elma physics transition was huge. Keeping old times in any single level (except maybe in some completely flat lev with only gasing) would have not made sense. But in this case the new physics would be pretty much equal to the old high-fps physics and also most low-fps rides do not contain too much if any unfair advantage. Moreover, low-fps and high-fps players have always competed in battles and cups at the same time anyway.
  2. Pretty much what ArZeNiK said. Despite of being three years in, the development in Across playing was still in a rapid phase. All the old Across times would have been beaten pretty quickly. Now the development is largely converged and the situation is that there does exist very many very good times, also with high fps. People would totally give a shit of several these times even after 20 years from the release of new EOL. I would not be surprised if for example Kazan's Apple Harvest WR (high fps) remains something like 10 more years.
In general, the huge resource of all the times and recs driven in internals and in EOL battles and also in belma/irc battles and old cups/contests totally are not just nostalgy. They are a vast game content, nearly unique to any video game. New players would have nearly endless resource of kewl recs to eye and to try to repeat and learn. It would be an enormous loss if new elma was started from blank page.
skint0r wrote: 31 Jul 2019, 06:19 Over time assuming new EOL is better (how hard can be), more people will play it.
Of course it will be better and of course everyone will move there. Especially me since I can't even pop and I don't play internals. People would move there even if jon decided to mess around with physics parameters a bit to the EOL+ direction for the lulz. This is not about people moving there. It is possible to discuss what kind of physics there should be even if people would move there whatever the decision will be.
skint0r wrote: 31 Jul 2019, 06:19 meanwhile hindring any progress
skint0r wrote: 31 Jul 2019, 06:19 I'm tried understand reasoning for keeping old things but still have max hard time understanding why people very defensive about it and unable to let go, very ???
I am not trying to hinder any progress and I am being defensive because it might not be necessary to remove the fps-dependency and simultaneously still have all these awesome good progress things in 99% of the levels (and the applicable ones even with the special and manually selected low-fps levs):
jonsykkel wrote: 22 Jul 2019, 08:35 advantages of fixing it:
- you can drive a good time and there is no question about whether this bounce or that pop was valid or sach nonsense, its just a good time
- you can make anti xiit that actualy works vhere fysics change a tiny bit (unperceptible but engouh to prevent saveloading or replaying moves) based on seeds received from the server (maxdamantus idea)
- you dont have to wonder if you have been höyling with the wrong fps for years and al that time was wasted
- you dont have to wonder if randomnes in fysics fuked ur ride
- you can focus on playing the game instead of mesing with fps numbers
- you can play without huge input lag and horror framerate al the time
- the fysics would be the same across computers/platforms (they arent now, example: zamppe elma doesnt do same thing as bene elma and my elma at unlimited fps. it also acts difrent at limited fps)
I have to wait for the jon's answer about if it would be any poss.
Last edited by nick-o-matic on 31 Jul 2019, 12:59, edited 1 time in total.
User avatar
pawq
38mins club
Posts: 6547
Joined: 24 Aug 2008, 19:56
Team: TR
Location: Southampton, UK

Re: another new eol question mark topic

Post by pawq »

nick-o-matic wrote: 31 Jul 2019, 12:56
jonsykkel wrote: 30 Jul 2019, 23:54 if i go with old physics there would be fps knob and so on yes
Hold on - please define what you mean with new physics. My old perception was that "new physics" = partly rewritten physics engine, where several badly coded things are fixed, allowing 999fps even with the badest laptop and removing weird stuff like elma not behaving 100% same at different computers even at same fps. Along with fixed bugbounces and physics fps-dependency. So I understood that the fps thing might not be an integral part of the new physics engine. But do you mean that it actually is?
jon said in the very beginning that there are 2 options when creating okeol, either keeping physics as it is, or "fixing" it.
nick-o-matic wrote: 31 Jul 2019, 12:56 Imo the "hybrid solution", if technically possible, minimizes the ugliness and maximizes the beauty sections.
Maximizes the beauty by applying the unanimously beautiful and fully fixed high-fps physics to more than 99% of the levels.
Reduces the ugliness by allowing low-fps physics with some ugliness only in the levels where they are actually vital (= internals and some carefully chosen externals).
"Carefully chosen externals"? As long as you have this option, some people are going to try to exploit it in every single level, so it doesn't really change anything compared to now.
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

pawq wrote: 31 Jul 2019, 12:59 jon said in the very beginning that there are 2 options when creating okeol, either keeping physics as it is, or "fixing" it.
I know. There is still ambiguity with the term "new physics". It is possible he meant there just the fps-dependence. One could also use the result of the all the physics engine edits "new physics". The bottom line is that I am trying to resolve how many of these things are not related to fps things at all or in general do not affect physics too much so that the old times could be kept valid. Just one obvious example is the bugbounce. My understanding is that fixing it is completely separate to pretty much anything else in the physics engine (just edit one line of code to include the thereshold value), but it can also be called "new physics".
pawq wrote: 31 Jul 2019, 12:59 "Carefully chosen externals"? As long as you have this option, some people are going to try to exploit it in every single level, so it doesn't really change anything compared to now.
In this hybrid solution the possibility to change fps would be allowed only in the carefully chosen externals which are impsy to finish without low fps or which have records that exploit low-fps tricks. In 99% of the levels you would always drive with 100% fixed physics. Or if someone specifically wants to make a pop or vsync lev.
Last edited by nick-o-matic on 31 Jul 2019, 13:14, edited 1 time in total.
User avatar
Lousku
Kuski
Posts: 2925
Joined: 5 Feb 2010, 00:25
Team: BAP
Location: expensive land of dads

Re: another new eol question mark topic

Post by Lousku »

I think nom is thinking about the possibility of an engine that has no timestep (physics fps) at all. Is that possible?

Jon's solution is closer to the original physics as it still runs differently depending on physics, it would just be locked at a chosen value.

And yeah, bugbounces are a different issue.

Did I misunderstand?
then again i don't know anything
maybe easier not to think abouut alöl things thought than not things thought ... or something..=?
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

Lousku wrote: 31 Jul 2019, 13:13 I think nom is thinking about the possibility of an engine that has no timestep (physics fps) at all. Is that possible?

Jon's solution is closer to the original physics as it still runs differently depending on physics, it would just be locked at a chosen value.

And yeah, bugbounces are a different issue.

Did I misunderstand?
Imo I did not think this kind of possibility =D To put it very short, I am wondering if it is poss to fix everything else in the physics but the fps thing, and keep the bike behavior similar enough to keep the old WRs and all the old times. Perhaps (if it does not lead to too much antixiit problems) also the fps thing could partially be technically fixed, something like this:

Code: Select all

if level.fpsmongoing == True:
	[old sux code block which leads to the fps-physics -dependency]

else:
	[beautiful and fixed block of gode]
end
User avatar
Labs
37mins club
Posts: 1213
Joined: 2 May 2005, 14:20
Team: SPEED
Location: Hungary
Contact:

Re: another new eol question mark topic

Post by Labs »

nick-o-matic wrote: 31 Jul 2019, 12:56
The bugbounces are not gonna be a concern in new elma anymore as discussed in this jon's paragraph =)
Bug bnc doesnt only appear because of wheel distance, it depends on fps also, so if jon corrects the wheeldistance value, he must setup a fixed fps also for that. Thats why old physics shits wont be available. I wont miss pops or bugbnc and vsync gak at all tho, it makes game unfun to play for bugs.
Team SPEED

Image
User avatar
pawq
38mins club
Posts: 6547
Joined: 24 Aug 2008, 19:56
Team: TR
Location: Southampton, UK

Re: another new eol question mark topic

Post by pawq »

nick-o-matic wrote: 31 Jul 2019, 13:09 In this hybrid solution the possibility to change fps would be allowed only in the carefully chosen externals which are impsy to finish without low fps or which have records that exploit low-fps tricks.
This is, practically, unfeasible.
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

pawq wrote: 31 Jul 2019, 13:25 This is, practically, unfeasible.
Why? It does not have to be done to all levs, at least right away. There are maybe something like 1000 externals at max which urgently need this kind of thing and there would be some mods to do this work, no need for jon to do. And if someone stumbles upon an external in the database or in levelpacks (something like a random battle lev) which needs low fps, he can request mods to grant low-fps rights or delete the lev and recs from database if it suks. There could be some special low-fps levelpacks and most levelpacks would be 100% fixed physics.
User avatar
Labs
37mins club
Posts: 1213
Joined: 2 May 2005, 14:20
Team: SPEED
Location: Hungary
Contact:

Re: another new eol question mark topic

Post by Labs »

nick-o-matic wrote: 31 Jul 2019, 13:29
pawq wrote: 31 Jul 2019, 13:25 This is, practically, unfeasible.
Why? It does not have to be done to all levs, at least right away. There are maybe something like 1000 externals at max which urgently need this kind of thing and there would be some mods to do this work, no need for jon to do. And if someone stumbles upon an external in the database or in levelpacks (something like a random battle lev) which needs low fps, he can request mods to grant low-fps rights or delete the lev and recs from database if it suks.
Even if it would be possible i would vote no for that hybrid thing. Why would some levs get the priority against others just to let some bug style appear there? Why its so bad to leave old tables? They will be still visible on moposite for nostalgia mans. Let the new come and let the old go.
Team SPEED

Image
User avatar
pawq
38mins club
Posts: 6547
Joined: 24 Aug 2008, 19:56
Team: TR
Location: Southampton, UK

Re: another new eol question mark topic

Post by pawq »

Firstly, this would mean that mods would have a huge and neverending (and wholy unnecessary) job of deciding which lev is appropriate for low fps and which one isn't. Just think about it - you said 1000 levs urgently (meaning many more in the future) - each lev would have to be looked up, eye-tested, possibly actually tested, and then change applied. Tens of hours of work, hundreds in the long-term.

And secondly, what criteria could we possibly use to decide which lev needs low fps? In principle every single lev in existence could benefit from low fps. And keeping low fps in the game after such a huge change just so that a few random mongo externals don't become unfinishable seems very counter-productive.



My updated thoughts on the debate:
the more I think about it, the more I'm convinced that modernising the physics engine, forcing high fps and eliminating bugbounces would be a good thing for the game and the scene

why?

I hate having to ask "what's the fps for this lev" when starting to hoyl some internal. I hate playing a lev and thinking that the style doesn't work because wrong fps or because wrong pc. I hate playing a speed battle at fem and losing to ilkka because my laptop gets internal error faster than his because can't get high enough fps. I hate playing a bullet battle and losing because 90% of the time the wheel doesn't lift off enough (just pressing gas at start). I hate when I'm hoyling Enigma and suddenly start stops working (wheel doesn't lift off enough after just pressing gas), because music stopped playing in the background and it affected elma, even though in theory I'm playing on max fps. I hate when a 1-min bullet battle is a low-fps lev so I can either spent some 25% of battle time changing fps in eolconf, or just get rekt.
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

Labs wrote: 31 Jul 2019, 13:25 Bug bnc doesnt only appear because of wheel distance, it depends on fps also, so if jon corrects the wheeldistance value, he must setup a fixed fps also for that. Thats why old physics shits wont be available.
Good point and it might crash the whole thing indeed. It makes sense now that I think of it. Velocity change is proportional to time integral of the force and fps determines the timestep in the discrete integral. Thus it totally makes sense why low fps gives more ezily bugbounces. As my first impression this makes things a lot more complicated, but not necessarily impossible to fix. Some artificial fps-dependable threshold would be a solution, but also the planned constant thereshold is artificial in the first place. There might also be another, completely new, solutions to this than the threshold, like improving the physics calculation algorithms with something like Velocity Verlet if it is not already used and if other changes than removing bugbounce are neglible. It is needed to wait for jon's reply here.
User avatar
Zweq
34mins club
Posts: 4055
Joined: 28 Nov 2002, 15:54
Location: suo mesta

Re: another new eol question mark topic

Post by Zweq »

Out of like last 15 ints i improved I recall only 05, 07, 16, 28 were 999 fps, and for 16 and 28 less fps is most likely ideal.
For 19, 33, 46 I used 350-450.
For 39 I used 200.
For 01, 02, 04, 53 around 30-45
Generic battle fps that I use is 300
999 fps is too clunky and has too stiff suspension for general gameplay... need a bloody good reason to use 999 fps, like a slide brutal.
Image
User avatar
Labs
37mins club
Posts: 1213
Joined: 2 May 2005, 14:20
Team: SPEED
Location: Hungary
Contact:

Re: another new eol question mark topic

Post by Labs »

Zweq wrote: 31 Jul 2019, 14:26 999 fps is too clunky and has too stiff suspension for general gameplay... need a bloody good reason to use 999 fps, like a slide brutal.
I agree with that, 999 fps suspension is very bad compared to 100-300. Maybe 300 i would like more than 999.
Team SPEED

Image
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

Labs wrote: 31 Jul 2019, 13:36 Even if it would be possible i would vote no for that hybrid thing. Why would some levs get the priority against others just to let some bug style appear there?
Because of this thing:
nick-o-matic wrote: 30 Jul 2019, 13:59 This system has some obvious idiot system flaws (already pointed out), but a flawless solution is simply not poss here.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Labs wrote: 31 Jul 2019, 13:36 Why its so bad to leave old tables? They will be still visible on moposite for nostalgia mans. Let the new come and let the old go.
Because of these things:
nick-o-matic wrote: 31 Jul 2019, 12:56 Now the development is largely converged and the situation is that there does exist very many very good times, also with high fps. People would totally give a shit several of these times even after 20 years from the release of new EOL. I would not be surprised if for example Kazan's Apple Harvest WR (high fps) remains something like 10 more years.
nick-o-matic wrote: 31 Jul 2019, 12:56 In general, the huge resource of all the times and recs driven in internals and in EOL battles and also in belma/irc battles and old cups/contests totally are not just nostalgy. They are a vast game content, nearly unique to any video game. New players would have nearly endless resource of kewl recs to eye and to try to repeat and learn. It would be an enormous loss if new elma was started from blank page.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pawq wrote: 31 Jul 2019, 13:43 Firstly, this would mean that mods would have a huge and neverending (and wholy unnecessary) job of deciding which lev is appropriate for low fps and which one isn't.
In any case mods are needed to delete some levels (duplicates, old versions of levs, impsy levs etc etc) manually from the mass of levels. The system of granting low-fps rights to levels does not differ significantly from this. Imagine the situation of mod request to review old belma vsync battle lev. There does exist two scearios:
  1. 100% fixed physics OKEOL: delete the lev or keep it if it is playable anyways.
  2. option for fps change OKEOL: delete the lev or keep it if it is playable anyways or grant it low fps rights.
The option 2) does not take significantly longer time than the option 1) for the mod. Of course non-vsync non-pop levels which have times impsy for 999fps (such us many Kopasite hoyla levels) are a lot more tough decision. You could also delete all the best times instead of granting low-fps right in these cases. But the amount of such decisions for ultra-hoyled levs is quite limited.
pawq wrote: 31 Jul 2019, 13:43 you said 1000 levs urgently (meaning many more in the future)
Imo you are just attacking the word choice "urgent" instead of thinking this thing yourself. There would be maybe a couple of hundred of thousands old levels in the database. Many of them (super random levs) will not be played unless we get 10000 players, and even in the case of someone playing them they would not care if it has best time impsy for 999fps and would not report it. All the new levels would be free of the review. In general, if some random external has low-fps rights or not, is a very miniscule detail. The big picture is being able to keep the majority of old times and recs ingame.
pawq wrote: 31 Jul 2019, 13:43 And secondly, what criteria could we possibly use to decide which lev needs low fps? In principle every single lev in existence could benefit from low fps.
Of course every single lev could benefit from low fps but the point of this whole thing is opposite to trying to drive as fast time as poss in every single lev. Specifically we would try to prevent going into the direction of fps tuning in most levels. 99,9% of all new levs (the remaining 0,1% being some special vsync and pop levels nobody is forced to play) would not use the fps tuning.
pawq wrote: 31 Jul 2019, 13:43 And keeping low fps in the game after such a huge change just so that a few random mongo externals don't become unfinishable seems very counter-productive.
I am speechless. Do you really think that that is the reason I want to keep fps-dependency?
pawq wrote: 31 Jul 2019, 13:43 I hate having to ask "what's the fps for this lev" when starting to hoyl some internal.
Yes that sucks. Tm provided this kind of solution for this (EDIT: he actually did not mean that as a solution, but as an additional problem):
Tm in discord wrote: but there are also ints (wud say, quite handful) where best to drive inbetween fps like 350, or 669. If leave 999 for these, must remove rekords, if deal with it - every internal should have the concrete fps value wr was driven on okeol release date. And that fps mite not be optimal, becouse magik and maybe other value better and too late to change in okeol kode. And if third option, selecto some brain magik fps for every internal separately, same problem - maybe there is better value yet untested.
But you would not have to set the optimal fps for the internal. It is just enough to have good enough value to keep old times valid.

I don't know if this solution would be better than free fps choice for ints but it fixes Pawq's problem. Another way to fix Pawq's problem is to have FPS values of times public or provide recommended fps's. Again not very pretty, but, once again:
nick-o-matic wrote: 30 Jul 2019, 13:59 This system has some obvious idiot system flaws (already pointed out), but a flawless solution is simply not poss here.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pawq wrote: 31 Jul 2019, 13:43 I hate playing a lev and thinking that the style doesn't work because wrong fps or because wrong pc.
Not going to be a problem in nearly any lev.
pawq wrote: 31 Jul 2019, 13:43 I hate playing a speed battle at fem and losing to ilkka because my laptop gets internal error faster than his because can't get high enough fps.
Not going to be a problem, you will have same fps.
pawq wrote: 31 Jul 2019, 13:43 I hate playing a bullet battle and losing because 90% of the time the wheel doesn't lift off enough (just pressing gas at start).
Not going to be a problem, it will work every time.
pawq wrote: 31 Jul 2019, 13:43 I hate when I'm hoyling Enigma and suddenly start stops working (wheel doesn't lift off enough after just pressing gas), because music stopped playing in the background and it affected elma, even though in theory I'm playing on max fps.
Not going to be a problem, it will work every time the same way.
pawq wrote: 31 Jul 2019, 13:43 I hate when a 1-min bullet battle is a low-fps lev so I can either spent some 25% of battle time changing fps in eolconf, or just get rekt.
Not going to be a problem, everyone will have the same fps.
Pawq in discord wrote: one of the points of the rewritten physics engine is to make it run independently of pc
so won't have any more situations like stini's legendary bounce pc
I am waiting for jon's answer whether or not fps-dependency excludes this or not, among the other improvements.
Last edited by nick-o-matic on 31 Jul 2019, 15:50, edited 1 time in total.
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

Labs wrote: 31 Jul 2019, 14:47
Zweq wrote: 31 Jul 2019, 14:26 999 fps is too clunky and has too stiff suspension for general gameplay... need a bloody good reason to use 999 fps, like a slide brutal.
I agree with that, 999 fps suspension is very bad compared to 100-300. Maybe 300 i would like more than 999.
Oh dear, this makes it more complicated if people would not prefer the 999fps-like physics after all. I have not really ever been driving with 999fps myself, but all the pros like Bjenn play with it so I have always assumed it is fun and smooth to play. Based on my own experiences 300 is fun to play yes.

Once again, whatever it is gonna be, people will move to new elma. It is just worthwhile to take some time at this point to determine what would be the optimal solution for the physics. Sik nice physics is the main reason people are playing this game after all.
Last edited by nick-o-matic on 31 Jul 2019, 15:50, edited 1 time in total.
User avatar
Lousku
Kuski
Posts: 2925
Joined: 5 Feb 2010, 00:25
Team: BAP
Location: expensive land of dads

Re: another new eol question mark topic

Post by Lousku »

TAS is already played separately from EOL. This doesn't split the community. People can continue to play EOL, current WR table can be kept and updated as long as there are WR's.

The people who want to keep playing with current physics can pay to keep EOL server up (np, currently paid until 2022), or they can revert to the system that was in place before SmibuSL was published. EOL antixiit doesn't really work anyway, does it? I imagine these players will also play okeol, just as they now play both EOL and TAS. No problem.

The prestige and all the amazing gaming history won't be gone. Replays will be preserved and compatible with okeol.

There are also Across levs in EOL database that are not finishable because of head position. This is actually a bigger problem than having levs that can't be finished without lowfps. There's no reason to go through externals at all.
then again i don't know anything
maybe easier not to think abouut alöl things thought than not things thought ... or something..=?
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

Lousku wrote: 31 Jul 2019, 15:29 The prestige and all the amazing gaming history won't be gone. Replays will be preserved and compatible with okeol.
The big problem here is that if they were not preserved in the OKEOL database (just as .rec files in various websites and people's hard drives and youtube videos) the prestige and all the amazing gaming history would be in practice gone for the normal OKEOL player and even for the old players who don't orka start to do the digging.

Alternatively there will be two shift+f5s, which would be quite bad solution as well. Once again, all the solutions have some bad sides.
Lousku wrote: 31 Jul 2019, 15:29 There are also Across levs in EOL database that are not finishable because of head position. This is actually a bigger problem than having levs that can't be finished without lowfps. There's no reason to go through externals at all.
This is already pretty far away from the main points that should be discussed. But I would hope that the OKEOL level database system would be more organized than EOL database and that you could explore levs more ez and every best time would have some significance (it would give you some points or mention to your player card or whatever). Thus every lev would have at least a little bit significance.
User avatar
pawq
38mins club
Posts: 6547
Joined: 24 Aug 2008, 19:56
Team: TR
Location: Southampton, UK

Re: another new eol question mark topic

Post by pawq »

All those points that you replied to by saying "wouldn't be a problem" also wouldn't be a problem if we just get rid of the fps variance altogether, which is probably the main suggestion. I suggest that you take a step back and really think why you're defending variable fps so strongly, and try to understand that one of the main purposes of getting rid of it is to essentially simplify the physics. Pretty much everything you're suggesting is going the opposite way - making things even more complicated, adding more problems, more dilemmas, and more effort.

Also regarding the mod-approved low-fps levs - forget it, it's just not going to happen. I have no idea why you're assuming that mods would have to delete unfinishable levs from the database. There are fucktons of levels in the db now which are unfinishable (flower in ground etc), and nobody's deleting/locking them, people just don't play them. So of those 2 options you compared, 1) is actually 0 effort, and 2) is a huge amount of effort. Effort, which could, for example, be spent developing the elma.online site, or one of a million other things more worthwhile than deciding which lev should have low fps allowed and which shouldn't. Which is a silly idea in the first place.
User avatar
Ruben
Kuski
Posts: 836
Joined: 31 Dec 2012, 18:07
Location: Oslo, Norway

Re: another new eol question mark topic

Post by Ruben »

nick-o-matic wrote: 31 Jul 2019, 15:44Alternatively there will be two shift+f5s, which would be quite bad solution as well. Once again, all the solutions have some bad sides.
First of all I think the current system with f keys is quite bad and unintuitive. To me the best way to deal with this is having a rec tab of some sort where you can see all times and click to view rec in each lev. Beside each rec there can be a tiny tag that says e.g. "EM," (which means they were driven in EOL or Elma). Additional tags like "AB" (apple bug), "BB" (bug bounce), "VS" (vsync), "TAS" (tool-assisted), "WR" (current world record), "FWR" (former world record) etc. can also be included in such a system. Options to show/hide only EOL recs, or only wr's, or only tas etc. can be added too. With some good design work I think it can be done very well and uncluttered.

Hopefully this isn't something that's too difficult or time consuming to implement, because I think the ideal goal would be to include all these things (record tables, replays, histories, graphs, everything) in the game itself. Unless mans vehemently disagree, ofc., just throwing in my two cents.

A menu that's navigable using only the keyboard is also something I want in pretty much every game, but it can sometimes require some clever thinking and at worst be virtually impossible to do well. Since Elma is played without the mouse I think it's a good idea to make this happen.

I will try to draw up some ideas and see what all this might look like. I realise I'm way ahead of the development here, and that this is somewhat tangental to the main fps issue, but I think having a good menu system can be a big factor in a game's success, and looking at possible solutions even this early can't hurt.
<veezay> antti also gonna get stabbed later this month
<nick-o-matic> niec

My fake plants died because I did not pretend to water them.
Smibu
Kuski
Posts: 476
Joined: 15 Jun 2007, 13:17
Location: Finland

Re: another new eol question mark topic

Post by Smibu »

Replying to some of the "whether to use EOL2 code or not" discussion:
jonsykkel wrote:biggest reason is that its just impsy to work with other ppls code, it would be biger effort to figure it out than to write my own.
As a data point, I refactored EOL2 code quite a lot in 2017-2018. It seems like there were only 2 functional commits (both were bug fixes) between 26.3.2017 and 21.4.2018, all others were refactoring/docs. I'm not saying you should've continued EOL2; I'm just saying the current code at least isn't total spaghetti and has some sensible documentation.
jonsykkel wrote:i have too many disagreements about how it has been done so far, so i would have to change many things anyway.
It probably doesn't matter much at this point, but can you give some concrete examples of the things you'd change? I remember the Motoros guy ("crunkoy") saying something similar.
jonsykkel wrote:c++ is horror language
We agree ;) but admittedly, I don't like C that much either...
jonsykkel wrote:and i need quick build times
Some C++ compilers been improving on this front (well, MSVC at least). C++20 will also have a module system which will probably help with build times (but that's still kinda far away).
Kopaka wrote:what are your reasons for not continuing on smibu's work instead of something completely from scratch?
Just so it's clear to everyone: this is only about the client. EOL2 source doesn't contain any server code, expect for a short (87 lines) server stub written by Ropelli in 2013. So the server code needs to be written from scratch in any case, assuming mila's EOL server code won't be used.
nick-o-matic wrote:But perhaps some blocks of code, or at least some ideas in Elma 2 code, could be useful...?
EOL2*. :) But yeah, like jon said, grass rendering comes to mind. But it's not the same as Elma's algorithm - I didn't look at Elma's code when I made it. Just fiddled around until it looked good enough. Other easily reusable code parts don't really come to mind.
nick-o-matic wrote:Perhaps after all his work Smibu could give some comments and advice and ideas for this project...?
Sure, I have a few.

I recommend using Rust for all/most of the server code. My experience with Rust has been nothing but positive, and I think the server will have far fewer bugs this way (assuming C is the other option).

Using Rust for the client is a harder sell because 1) some/lots of C code already exists and 2) game development in Rust is not that mature yet.

For project management, using GitLab could make sense - the repo can be marked private but people can still post issues there, like with EOL2. And with the free GitLab CI you get automatic builds for each commit. Most people won't sign up to GitLab of course, but there could be a custom web page (no login needed) that forwards bug reports to GitLab. Some hard FEM quiz question for catching bots!
User avatar
pawq
38mins club
Posts: 6547
Joined: 24 Aug 2008, 19:56
Team: TR
Location: Southampton, UK

Re: another new eol question mark topic

Post by pawq »

Unrelated to the last few posts:

Sorry if I came around as a bit offensive earlier @nick-o-matic, I've had a shitty mood all day and I guess it probably transpired. Wasn't my intention, I'll refrain from posting again until I'm not an angry asshole.
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

Ruben wrote: 31 Jul 2019, 17:36 First of all I think the current system with f keys...
I probably talk also in behalf of the others who have used the "shift+f5" term when I say that usage of this term should not be taken literally - sure there is going to be something much better and convenient =)
pawq wrote: 31 Jul 2019, 18:46 Unrelated to the last few posts:

Sorry if I came around as a bit offensive earlier @nick-o-matic, I've had a shitty mood all day and I guess it probably transpired. Wasn't my intention, I'll refrain from posting again until I'm not an angry asshole.
Hehe, np, thank you for this post =) Actually I started to get angry, so it's a good thing that I did not immediately write a reply to your last post. In general, I would like to say two things about the discussion:
  • I am a very big fan of logics and reasoning especially in this era of Trump-twitter-argumenting. I am all in for welcoming reasonable arguments against my solution suggestion (=keep fps-dependency), but I am going to strongly fight against the unreasonable ones. I tried to very carefully list all kinds of pros and cons of my solution suggestion myself, along with pros and cons of other scenarios.
  • I am fundamentally just trying to find the best solution to this whole physics thing, and particularly I am trying to research all the possibilities which would not split the internal and external WR tables into two. It would be a huge shame if a reasonable solution to this would exist, but it was not thought of by anyone, and we would go with a solution that splits the tables.
User avatar
jonsykkel
Kuski
Posts: 982
Joined: 24 Nov 2009, 20:53
Contact:

Re: another new eol question mark topic

Post by jonsykkel »

nick-o-matic wrote: 31 Jul 2019, 12:56 Hold on - please define what you mean with new physics. My old perception was that "new physics" = partly rewritten physics engine, where several badly coded things are fixed, allowing 999fps even with the badest laptop and removing weird stuff like elma not behaving 100% same at different computers even at same fps. Along with fixed bugbounces and physics fps-dependency. So I understood that the fps thing might not be an integral part of the new physics engine. But do you mean that it actually is? Before continuing the discussion it is imo pretty much vital for everyone to have a clear picture what is your full plan with the physics engine and how your full plan is reduced if the fps knob was there, and what could not be done if we want to keep old internal and external WRs valid.
new physics means: rewritten physics engine (most likely. pretty much only for technical reasons that dont affect the gameplay. for example i plan to validate every single run that is made by all players on the server and since there will be many people playing at the same time that means its a big advantage that the physics run as fast as possible), fixed bugbounces, fixed hooked bug, fixed 200aple bug, no fps knob, fixed physics framerate at exactly 1000fps (this allows 1:1 mapping to millisecond resolution times. 1 frame would be exactly 00:00:001 on the elma timer)

old physics means: exactly 100% like current eol physics with nothing fixed. its not possible to fix bugbounces and keep the new physics compatible with the old physics, there is no way to know for example if stinibounce or pipe bounce osv is still valid by just looking at the rek. this solution would have fps knob just like current eol

im think this answers question?


nick-o-matic wrote: 31 Jul 2019, 12:56 I can totally see all the bad elements of the fps-dependency. It is ugly how artificial the complexity dimension introduced by it is. It is ugly how it is coded. It is ugly how the low-fps version of the physics leads to some randomness and how it forces you to have random input delays, and thus reduces the skill element. On the other hand, I can also see some beauty over there. It is quite elegant how this kind of small parameter change leads to such huge differences in bike physics at some situations (contrary to intuition). It is pretty freaking elegant and beautiful how something like the new int51 style is possible. In the case of moderate vsync holes such as int45 start it even adds a little bit of fun into the playing (imo high-fps sink start is super slow and boring to play). Also not-so-moderate vsync holes can be fun to play and elegant such as int31 start (well it looks fun, I have just spied people in EOL, not done it myself).
i agree i also think int31 vsync start 4 example is a elegant style, its just "nyce" how it works out. but if u ask me the masive problems with low fps far outweigh any positive aspects of it
also once youve seen it youve seen it. old recs/vids/vatnot are still there, stuff like this wont be forgotten


nick-o-matic wrote: 31 Jul 2019, 12:56 I am not completely sure how this is a hybrid solution because it is close to the situation today. Or it depends on the technical implementation. Have to wait for your reply about that first.
its a hybrid solution because it requires 2 different physics engines in the same game, the situation today is that we have 1 physics engine. its not really even about the masive aded complexity of the implementation and antixiit, but about the simplicity of playing the game for the ppl that will be playing it


nick-o-matic wrote: 31 Jul 2019, 12:56 Imo the "hybrid solution", if technically possible, minimizes the ugliness and maximizes the beauty sections.

Maximizes the beauty by applying the unanimously beautiful and fully fixed high-fps physics to more than 99% of the levels.
Reduces the ugliness by allowing low-fps physics with some ugliness only in the levels where they are actually vital (= internals and some carefully chosen externals).
Avoids the ugly solution of two-shift+f5s.
Avoids the alternative ugly solution of not having legacy shift+f5 at all and having to go for old sources to see the old times in any old norm (=high-fps) internal or external.

The only concern I have here is that will the low-fps-physics elmaing (mainly some of the internals) become too much about pops. Will some currently high-fps levs be converted into low-fps pop levs? Would be nice and even necessary to see some pro internalist comments here about pops and low-fps hoyling in general, not just my non-internalist opinions. Some questions:

How many internals are 999fps or very high fps?
How fun it is to hoyl short levs like 01, 02 and 44 with low fps? How would hoyling these levs be like with high fps?
How fun it is to hoyl long levs like 31, 51 with low fps?
How widespread are the pops going to be in the future if pop-physics preserve? Would we see pops in nearly every new WR? Would some currently high-fps levels be converted into low-fps levs due to pops?
im dont understand why one has to think so much about what will happen to the internals and try to plan everything that will happen ahead of time, the way i see it pleyers will pley the new game and find styles for the levels where the old styles are not possible anymore


nick-o-matic wrote: 31 Jul 2019, 12:56 The bugbounces are not gonna be a concern in new elma anymore as discussed in this jon's paragraph =)
...
Moreover, as a side note, even with old elma engine it would be poss (atleast imo) to get rid of bugbounces with a new .rec format where every frame and button presses are saved (because it lets you to see the length of bike->wheel vector when brake press occurred and we could check if it was below the new thereshold).
if new game, yes they wont be a concern. they will be the same concern they have always been if old physics are used. new runs could be validated automatically of course, but you cant prevent the bugs from happening without modifying physics (so i guess you would just get big red text on screen SRY BRO!! u got bug bounce !! ur run is now trash, bad luck try again), and you cant figure out whether old times are valid or not


nick-o-matic wrote: 31 Jul 2019, 13:09 I know. There is still ambiguity with the term "new physics". It is possible he meant there just the fps-dependence. One could also use the result of the all the physics engine edits "new physics". The bottom line is that I am trying to resolve how many of these things are not related to fps things at all or in general do not affect physics too much so that the old times could be kept valid. Just one obvious example is the bugbounce. My understanding is that fixing it is completely separate to pretty much anything else in the physics engine (just edit one line of code to include the thereshold value), but it can also be called "new physics".
the only way to keep the old times valid in the new game is to use the physics as is, with no modifications or fixes (maybe except for hooked bug). bugbounce fix = new physics, all times invalid



nick-o-matic wrote: 31 Jul 2019, 13:22 Perhaps (if it does not lead to too much antixiit problems) also the fps thing could partially be technically fixed, something like this:

Code: Select all

if level.fpsmongoing == True:
	[old sux code block which leads to the fps-physics -dependency]

else:
	[beautiful and fixed block of gode]
end
ur gona have to take my word for it but it really isent that simpel =D (not that i think you actually think that)

sry nom, but to save you some brain pover thinking too much about this: its not really an option for my to have 2 difrent physics in the same game


nick-o-matic wrote: 31 Jul 2019, 14:09 As my first impression this makes things a lot more complicated, but not necessarily impossible to fix. Some artificial fps-dependable threshold would be a solution, but also the planned constant thereshold is artificial in the first place.
there are alredy many artificial things in the physics, like the springs stop having an effect on things when the wheels are "close enough" (0.0001 elmameters iirc) to where they should be, to stop oscillation. this type of thing is prety similar to the proposed fix for bugbounces
not to spek of volts changing the angular velocity of the bike instantly in 1 frame and not through a natural torque applied to the bike like everything else in the physics


nick-o-matic wrote: 31 Jul 2019, 14:09 There might also be another, completely new, solutions to this than the threshold, like improving the physics calculation algorithms with something like Velocity Verlet if it is not already used and if other changes than removing bugbounce are neglible. It is needed to wait for jon's reply here.
im just idiot programer, not mathematician or physics expert =[) im really have no glue about this kind of stuff
im would also like to make minimal changes to the physics engine to avoid introducing new unforeseen problems and bugs whcih would defeat the purpose of fixing the broken game


Labs wrote: 31 Jul 2019, 14:47
Zweq wrote: 31 Jul 2019, 14:26 999 fps is too clunky and has too stiff suspension for general gameplay... need a bloody good reason to use 999 fps, like a slide brutal.
I agree with that, 999 fps suspension is very bad compared to 100-300. Maybe 300 i would like more than 999.
nick-o-matic wrote: 31 Jul 2019, 15:19 Oh dear, this makes it more complicated if people would not prefer the 999fps-like physics after all. I have not really ever been driving with 999fps myself, but all the pros like Bjenn play with it so I have always assumed it is fun and smooth to play. Based on my own experiences 300 is fun to play yes.
im no elma pro by any strech of the imagination (OR STRETCH OF SUSPENSION LOOOOOOOOOOOOOO GOLDEN APLE JOKE) so im a bit reluctant to goment on the utility of 300fps but the difference i can feel between 300 and 1000fps is relatively minimal, cud be wrong but i think this is more like a "feel" thing that you would get used to within 30mins than anything else, im dont see this is a problem


Lousku wrote: 31 Jul 2019, 15:29 The people who want to keep playing with current physics can pay to keep EOL server up (np, currently paid until 2022), or they can revert to the system that was in place before SmibuSL was published. EOL antixiit doesn't really work anyway, does it? I imagine these players will also play okeol, just as they now play both EOL and TAS. No problem.
im thoguht about this and what pavq said about not good to have 2 things runing at the same time but ye i think this realy is the only solution if go new game. cant force people to play it if they dont vant to


nick-o-matic wrote: 31 Jul 2019, 15:44 The big problem here is that if they were not preserved in the OKEOL database (just as .rec files in various websites and people's hard drives and youtube videos) the prestige and all the amazing gaming history would be in practice gone for the normal OKEOL player and even for the old players who don't orka start to do the digging.

Alternatively there will be two shift+f5s, which would be quite bad solution as well. Once again, all the solutions have some bad sides.
old reks could be available from inside new game, that is not a big issue. cud even match them to times from old db in cases where that is possible
im dont see how can posibly think having separate legacy times shift+f5 in game is bad solution but 2 difrent physics is less bad =D its by far the least bad solution as far as i can se


Ruben wrote: 31 Jul 2019, 17:36 Hopefully this isn't something that's too difficult or time consuming to implement, because I think the ideal goal would be to include all these things (record tables, replays, histories, graphs, everything) in the game itself. Unless mans vehemently disagree, ofc., just throwing in my two cents.
there are plans


Ruben wrote: 31 Jul 2019, 17:36 A menu that's navigable using only the keyboard is also something I want in pretty much every game, but it can sometimes require some clever thinking and at worst be virtually impossible to do well. Since Elma is played without the mouse I think it's a good idea to make this happen.
definitly i h8 using mouse for anything so everything will be posible with keyboard and the gmae and keybinds osv wil be very cumfigurable just like okesl (but not overly complicated like okesl, and ther wil be graphical interface for most important setings)


Smibu wrote: 31 Jul 2019, 18:12 As a data point, I refactored EOL2 code quite a lot in 2017-2018. It seems like there were only 2 functional commits (both were bug fixes) between 26.3.2017 and 21.4.2018, all others were refactoring/docs. I'm not saying you should've continued EOL2; I'm just saying the current code at least isn't total spaghetti and has some sensible documentation.
ye, dont get the wrong idea, im wasnt saying the code is badik or anything liek that (im dont know im havent seen it), i have no reason to think it is
more like ppl brains vork difrently and thigns that make cense to one man often doesnt make sense to other man


Smibu wrote: 31 Jul 2019, 18:12 It probably doesn't matter much at this point, but can you give some concrete examples of the things you'd change? I remember the Motoros guy ("crunkoy") saying something similar.
bigest thing i gues: im dont like the CEGUI interface, it feels very "cheap" and not like the right thing for best game of al time. my idea for the interface is quite different, cant really say much more since its still mostly just an abstract idea in head
also order of operations: focusing on minimal working eol (with very solid online stuff in place) to begin with is the way to go i think. duno if this is just my brain being weird but it feels important to do it like that, again ppls brains vork difrently


Smibu wrote: 31 Jul 2019, 18:12 Some C++ compilers been improving on this front (well, MSVC at least). C++20 will also have a module system which will probably help with build times (but that's still kinda far away).
might very well be, duno. used to like c++ when i was using it but then i tried doing stuff in c and realized how mutch cleaner it is. theres just zero reasons for me to go bak to c++, i dont miss anythign about it
also msvc isnt exactly my gompiler of choice ))


Smibu wrote: 31 Jul 2019, 18:12 I recommend using Rust for all/most of the server code. My experience with Rust has been nothing but positive, and I think the server will have far fewer bugs this way (assuming C is the other option).
i dont like rust, it seems to have many of the things i dont like about c++ (way too complicated syntax). i dont care about memory safety, just write things carefully (like you shud be doing anyway) and it isnt a problem. maybe i would care about that if i were the manager of sum big corporation and all the coders were bad =D

if i used rust for the server it would be riddled with bugs, since i dont know the language


Smibu wrote: 31 Jul 2019, 18:12 For project management, using GitLab could make sense - the repo can be marked private but people can still post issues there, like with EOL2. And with the free GitLab CI you get automatic builds for each commit. Most people won't sign up to GitLab of course, but there could be a custom web page (no login needed) that forwards bug reports to GitLab. Some hard FEM quiz question for catching bots!
never used gitlab but sounds like cud be good idea ye, at least for the issues thing
status:ONLINE - - -  drinking:GOFE - - - iq:85 - - - elasto mania ranking:#1
User avatar
Zweq
34mins club
Posts: 4055
Joined: 28 Nov 2002, 15:54
Location: suo mesta

Re: another new eol question mark topic

Post by Zweq »

jonig wrote: im no elma pro by any strech of the imagination
vtf u r best elma of al times
jonig wrote: (OR STRETCH OF SUSPENSION LOOOOOOOOOOOOOO GOLDEN APLE JOKE)
ROOOOFL so good yoke i had to take my glases of :pig: :thumbsup:
jonig wrote: the difference i can feel between 300 and 1000fps is relatively minimal
y, vel not y if megahöyl international. if not alvays piking best posible fps betwen 300 and 1000 for every internal that is soppoused to b played with 300+ fps you end up losing some casual 10-20 seconds in total time.

i just think no fps value is silver bulet in elma, whatever value is chosen, it's going to cause tears in some ints. (and i don't realy care like implied in my first post on first pagE)
a great man wrote: no fps value is silver bulet in elma
now that's a fine quote, i can definitely agre on that
Image
User avatar
jonsykkel
Kuski
Posts: 982
Joined: 24 Nov 2009, 20:53
Contact:

Re: another new eol question mark topic

Post by jonsykkel »

Zweq wrote: 31 Jul 2019, 22:02 y, vel not y if megahöyl international. if not alvays piking best posible fps betwen 300 and 1000 for every internal that is soppoused to b played with 300+ fps you end up losing some casual 10-20 seconds in total time.
oke axualy litel more siginificunt than im imaginegnd
but ye there are good reasons for going with 1000fps just talked this in discunt here vat said

10:37 PM] Ruben: @jonsykkel why no discussion on fps choice? I have no experience playing over 300-ish so I don't know what it feels like, but it seemed like some promans didn't like teh
[10:37 PM] jonsykkel: because 1000 is the perfect choice
[10:37 PM] Ruben: a bit unsatisfactory answer maybe...
[10:38 PM] lousk: afaik its moar like you cant hangstretch as far with highfps so its bad for some levs
0:38 PM] jonsykkel: its the max available in old elma, it gives you the most accurate physics, minimum input latency, 1:1 mapping to millisecond times
[10:38 PM] jonsykkel: least vsync problems
status:ONLINE - - -  drinking:GOFE - - - iq:85 - - - elasto mania ranking:#1
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

jonsykkel wrote: 31 Jul 2019, 20:53 new physics means: rewritten physics engine (most likely. pretty much only for technical reasons that dont affect the gameplay. for example i plan to validate every single run that is made by all players on the server and since there will be many people playing at the same time that means its a big advantage that the physics run as fast as possible), fixed bugbounces, fixed hooked bug, fixed 200aple bug, no fps knob, fixed physics framerate at exactly 1000fps (this allows 1:1 mapping to millisecond resolution times. 1 frame would be exactly 00:00:001 on the elma timer)

old physics means: exactly 100% like current eol physics with nothing fixed. its not possible to fix bugbounces and keep the new physics compatible with the old physics, there is no way to know for example if stinibounce or pipe bounce osv is still valid by just looking at the rek. this solution would have fps knob just like current eol

im think this answers question?
Sorry but it only answered to the question of what you are exactly going to do and even there I would like to see more details xd The main question was:
nick-o-matic wrote: 31 Jul 2019, 12:56 how your full plan is reduced if the fps knob was there, and what could not be done if we want to keep old internal and external WRs valid.
Based on that list you provided, many if not all of your improvements to the physics code could be done without fixing the fps. Is it so or not? Does the fps fix materialize to this one and only small code block?
jonsykkel wrote: 24 Jul 2019, 11:41

Code: Select all

main loop
  get delta time
  sample input
  phys loop
    calc physics
  end phys loop
  render
end main loop
80.1 - 1000 fps: 1 iteration of phys loop
39.3 - 80.0 fps: 2 iterations
26.7 - 39.2 fps: 3 iterations
19.9 - 26.6 fps: 4 iterations
For me it looks plausible that it does. So not touching this would keep the fps-dependency, but everything else would be fixable. But is it so? This is what I really urgently would like to know.
jonsykkel wrote: 31 Jul 2019, 20:53 the only way to keep the old times valid in the new game is to use the physics as is, with no modifications or fixes (maybe except for hooked bug). bugbounce fix = new physics, all times invalid
jonsykkel wrote: 31 Jul 2019, 20:53 its not possible to fix bugbounces and keep the new physics compatible with the old physics, there is no way to know for example if stinibounce or pipe bounce osv is still valid by just looking at the rek.
Yes, every change in the physics engine leads to some differences in physics. But it is up to debate if old WRs could still be comparable it the changes were tiny enough. I am not necessarily saying that it is so. This is something that should be discussed. Imo fixing bugbounce would not necessarily (=discussion needed) make old times invalid, bc the bike would behave norm in all legal situations.
jonsykkel wrote: 31 Jul 2019, 20:53 also once youve seen it youve seen it. old recs/vids/vatnot are still there, stuff like this wont be forgotten
There's also some value greater than zero in the playing experience of these things, it is not the same thing to eye it from rec than to play it yourself. It can ofc be argued to be neglible, but I would like to hear opinions.
jonsykkel wrote: 31 Jul 2019, 20:53 im dont understand why one has to think so much about what will happen to the internals and try to plan everything that will happen ahead of time, the way i see it pleyers will pley the new game and find styles for the levels where the old styles are not possible anymore
I am just carefully trying to weigh different scenarios. And it would be nice if some nice 999fps stuff will be found in ints, but I am very much afraid that the 999fps int styles would be exactly like the old styles or then some old boring styles if the old WR style is not poss anymore. To put it short, I think this question is important and it can not just be passed without careful discussion.
jonsykkel wrote: 31 Jul 2019, 20:53 im just idiot programer, not mathematician or physics expert =[) im really have no glue about this kind of stuff
im would also like to make minimal changes to the physics engine to avoid introducing new unforeseen problems and bugs whcih would defeat the purpose of fixing the broken game
What I wrote was only a side note for an option to fix bugbounces (because I want to comprehensively discuss everything). My personal opinion is that I also think that just the artificial distance thereshold (which replaces the artificial eyetest from rec) is good enough.
jonsykkel wrote: 31 Jul 2019, 20:53 im no elma pro by any strech of the imagination (OR STRETCH OF SUSPENSION LOOOOOOOOOOOOOO GOLDEN APLE JOKE) so im a bit reluctant to goment on the utility of 300fps but the difference i can feel between 300 and 1000fps is relatively minimal, cud be wrong but i think this is more like a "feel" thing that you would get used to within 30mins than anything else, im dont see this is a problem
Imo this thing should be carefully discussed as well.


What it comes to the hybrid solution having two different physics (about which your post was much about) there has been a massive misunderstanding. I probably was not clear enough, for example that pseudocode thing was a mistake to post.

What I meant with hybrid solution: To fix everything else or nearly everything else but the fps code block (=the block quoted above). Then the physics would be close (neglibly close??? I want to know if yes/no?) to the old elma physics. Thus there would effectively be just one physics engine, that just depends on one parameter (fps). A little bit like it depends from gravity parameter. Physics engines with different gravity parameters are still technically same physics engines. Then the fps would be forced to be 999 (or 1000) in 99% of the levels and other values would be allowed most importantly in ints. Then the term "new physics" would mean mainly just fixed physics engine (except the fps).

What I wanted to know: Is what I meant poss? I still am not sure.
nick-o-matic wrote: 31 Jul 2019, 13:22 Perhaps (if it does not lead to too much antixiit problems) also the fps thing could partially be technically fixed, something like this:

Code: Select all

if level.fpsmongoing == True:
	[old sux code block which leads to the fps-physics -dependency]

else:
	[beautiful and fixed block of gode]
end
A small clarification to this very misleading post of mine. It was kinda just a joke. I assumed that you probably want to write the fps block better (the one quoted above) bc it is ugly osv. But if you want to keep the possibility for low fps physics open you can not. Thus I suggested that it would be still poss to use the if clause to include the beautiful code block which you would like to write. Then the fpsmongoing==False section planned by you would be included in the code, even though effectively it would be the same as using fps=1000 for the fpsmongoing==True section (which is the ugly fps block).
User avatar
nick-o-matic
Kuski
Posts: 870
Joined: 27 Jan 2007, 12:53
Location: Lappeenranta

Re: another new eol question mark topic

Post by nick-o-matic »

jonsykkel wrote: 31 Jul 2019, 22:09
Zweq wrote: 31 Jul 2019, 22:02 y, vel not y if megahöyl international. if not alvays piking best posible fps betwen 300 and 1000 for every internal that is soppoused to b played with 300+ fps you end up losing some casual 10-20 seconds in total time.
oke axualy litel more siginificunt than im imaginegnd
but ye there are good reasons for going with 1000fps just talked this in discunt here vat said

10:37 PM] Ruben: @jonsykkel why no discussion on fps choice? I have no experience playing over 300-ish so I don't know what it feels like, but it seemed like some promans didn't like teh
[10:37 PM] jonsykkel: because 1000 is the perfect choice
[10:37 PM] Ruben: a bit unsatisfactory answer maybe...
[10:38 PM] lousk: afaik its moar like you cant hangstretch as far with highfps so its bad for some levs
0:38 PM] jonsykkel: its the max available in old elma, it gives you the most accurate physics, minimum input latency, 1:1 mapping to millisecond times
[10:38 PM] jonsykkel: least vsync problems
Imo there is a big misunderstanding here. Elma physics engine is to some extent a physics simulation code that models some math equations that determine the bike movements. It is clear that smaller timestep models these equations more accurately and everything works more smoothly. But the question was not about that. The question was that elma might be slightly more fun to play at 300fps than with 1000fps. If it is true, the reason is that some errors due to bigger timestep lead to things like effectively softer suspension and mb things like effectively slightly stronger volts or other such things that some people would prefer. So we would have the right thing for wrong reason. If we would like to have 300fps feeling to physics but also the smoothness of 1000fps, we should start fine tuning things like the spring and volt parameters. At latest at that point the game would become a new game and old times would become uncomparable.

In order not to be misunderstood, I feel like more safe when I repeat once more: I am not saying the above thing should be done. I am just trying to provoke discussion in this very important topic and to point out things that have not been pointed out yet.
User avatar
Ruben
Kuski
Posts: 836
Joined: 31 Dec 2012, 18:07
Location: Oslo, Norway

Re: another new eol question mark topic

Post by Ruben »

This might be opening a giant can of worms, but one could always use 1kfps and play around with the physics until it feels comfortable (like e.g. 300). Though let's not do something silly like in Elma 2 moving the center of mass or adding lots of torque to the throttle. Just teeny tiny adjustments to make that perfect soup.

Problem is there would probably be as many different tuning preferences as there are kuskis.
<veezay> antti also gonna get stabbed later this month
<nick-o-matic> niec

My fake plants died because I did not pretend to water them.
User avatar
jonsykkel
Kuski
Posts: 982
Joined: 24 Nov 2009, 20:53
Contact:

Re: another new eol question mark topic

Post by jonsykkel »

nick-o-matic wrote: 31 Jul 2019, 22:59 The main question was:
nick-o-matic wrote: 31 Jul 2019, 12:56 how your full plan is reduced if the fps knob was there, and what could not be done if we want to keep old internal and external WRs valid.
Based on that list you provided, many if not all of your improvements to the physics code could be done without fixing the fps. Is it so or not? Does the fps fix materialize to this one and only small code block?
nick-o-matic wrote: 31 Jul 2019, 22:59 For me it looks plausible that it does. So not touching this would keep the fps-dependency, but everything else would be fixable. But is it so? This is what I really urgently would like to know.
the fps fix pretty much only affects that code yes
the only improvements that could be done without fixing the fps is:
- fixing bugbounces (but this would affect the physics to such a degree that it makes it impsy to say which old times are valid and which ones arent)
- fixing hooked bug
- fixing 200aple bug

what would not be possible:
- fixing pops
- fixing vsync stuff
- fixing fps dependency (obviously, but this is really one of the most important problems to fix)

the planned fix for pops and vsync is enforcing a high fps, i dont know of any other way to do that, and if there is such a way it would most likely alter the "meaning" of the physics by a much more significant amount than the bugbounce fix would


nick-o-matic wrote: 31 Jul 2019, 22:59 Yes, every change in the physics engine leads to some differences in physics. But it is up to debate if old WRs could still be comparable it the changes were tiny enough. I am not necessarily saying that it is so. This is something that should be discussed. Imo fixing bugbounce would not necessarily (=discussion needed) make old times invalid, bc the bike would behave norm in all legal situations.
yes, you could of course just guess that all the old runs are valid and ignore the possibility that they wouldnt be possible with fixed bugbounce physics. it could be true and it could be false, and its most likely false in many cases


nick-o-matic wrote: 31 Jul 2019, 22:59 I am just carefully trying to weigh different scenarios. And it would be nice if some nice 999fps stuff will be found in ints, but I am very much afraid that the 999fps int styles would be exactly like the old styles or then some old boring styles if the old WR style is not poss anymore. To put it short, I think this question is important and it can not just be passed without careful discussion.
i dont think anyone can predict correctly what would happen with ints if you make changes to the physics
but if ppl want to discuss it, go ahed, discuss


nick-o-matic wrote: 31 Jul 2019, 22:59 What it comes to the hybrid solution having two different physics (about which your post was much about) there has been a massive misunderstanding. I probably was not clear enough, for example that pseudocode thing was a mistake to post.

What I meant with hybrid solution: To fix everything else or nearly everything else but the fps code block (=the block quoted above). Then the physics would be close (neglibly close??? I want to know if yes/no?) to the old elma physics. Thus there would effectively be just one physics engine, that just depends on one parameter (fps). A little bit like it depends from gravity parameter. Physics engines with different gravity parameters are still technically same physics engines. Then the fps would be forced to be 999 (or 1000) in 99% of the levels and other values would be allowed most importantly in ints. Then the term "new physics" would mean mainly just fixed physics engine (except the fps).

What I wanted to know: Is what I meant poss? I still am not sure.
alright i see there has been a misunderstanding here
i think i get your idea now but im still not 100% what exactly the question is, what is left to fix if not gonna do anything about the fps thing? pretty much only bugbounces. would the physics be neglibly close if did that fix? no, definitely not. again there would be no way to determine what old runs are valid and which ones arent


nick-o-matic wrote: 31 Jul 2019, 22:59 Then the term "new physics" would mean mainly just fixed physics engine (except the fps).
it would be nearly pointless to only fix bugbounces and nothing else, it doesnt address any of the big isues with the playability of the game


nick-o-matic wrote: 31 Jul 2019, 22:59 A small clarification to this very misleading post of mine. It was kinda just a joke. I assumed that you probably want to write the fps block better (the one quoted above) bc it is ugly osv. But if you want to keep the possibility for low fps physics open you can not. Thus I suggested that it would be still poss to use the if clause to include the beautiful code block which you would like to write. Then the fpsmongoing==False section planned by you would be included in the code, even though effectively it would be the same as using fps=1000 for the fpsmongoing==True section (which is the ugly fps block).
ye im understand you dident mean that literaly. the reason i want to fix the fps stuff has apsolutely nothign to do with the ugly code, that realy is an insignificant detail


nick-o-matic wrote: 31 Jul 2019, 23:16 Imo there is a big misunderstanding here. Elma physics engine is to some extent a physics simulation code that models some math equations that determine the bike movements. It is clear that smaller timestep models these equations more accurately and everything works more smoothly. But the question was not about that. The question was that elma might be slightly more fun to play at 300fps than with 1000fps. If it is true, the reason is that some errors due to bigger timestep lead to things like effectively softer suspension and mb things like effectively slightly stronger volts or other such things that some people would prefer. So we would have the right thing for wrong reason. If we would like to have 300fps feeling to physics but also the smoothness of 1000fps, we should start fine tuning things like the spring and volt parameters. At latest at that point the game would become a new game and old times would become uncomparable.
you could ask everyone what their prefered fps value is and you would get (almost) as many diffrent answers as the number of ppl you asked

the whole point of using high fps is to make the physics more stable, and to decrease randomness in playing

the idea about changing spring rates to make some sort of compromise is something ive thought about, but decided against
first of all i dont think its a good idea to start messing with the constants. if you do that, why not add sum horsepower to the engine, make the volts a little stronger, make the game funer to pley ??? vhy not???
secondly, i have no idea why the springs feel different at 300 and 1000fps, there is no guarantee that changing the spring rates would counteract that effect exactly

the answer to this type of question is the same answer to the quesiton of modifying internals or adding new internals: if you are gona start modifying the game in a significant way like that, who decides what changes to make?
impsy to answer, only reasonable solution - dont change anything
keep the game as close as possible to the original (but fix the things that actually are problems)


nick-o-matic wrote: 31 Jul 2019, 23:16 In order not to be misunderstood, I feel like more safe when I repeat once more: I am not saying the above thing should be done. I am just trying to provoke discussion in this very important topic and to point out things that have not been pointed out yet.
i understand, i think its good that u are asking these questions. im know very well im making some big decisions here and from my posts it probably sounds like i dont take it very seriously, but that is because ive been thinking about how exactly to do many of these things for years. i vant ppl to at least understand the reasons behind all of these decisions
status:ONLINE - - -  drinking:GOFE - - - iq:85 - - - elasto mania ranking:#1
User avatar
bene
Hot kuski
Posts: 906
Joined: 18 Aug 2003, 23:33
Team: dat
Location: Sweden
Contact:

Re: another new eol question mark topic

Post by bene »

I like how this stopped being a "LOL WE CANT WHEELPOP SO WE DONT WANT LOW FPS - LOL WE CANT WHEELPOP BUT PRO CAN SO WE WANT LOW FPS"-fight topic to something sensible. (Side note: Any post that says they want it because they can't pop should be disregarded. Because they haven't tried. I taught sick mambo in fem, he had never done it before. I said how and he did it in less than 5 minutes. My teachings are no secret I've said millions of times how and why and when to do inputs and there are posts on lauta explaining everything. It is not a big secret and these people just refuse to even try. Even very old skool man mr knew how to do it from recs and the only thing he had wrong was guessed fps value which I told him what I use and why in fem, all other wrongs he did was him sucking because of too little höyl)

Many levels are low fps (under 100) now, only a handful of them would go from high to low in the next 5 years.

Jon is painting okeol to be some magical piece that fixes elma for all eternity but I will add the argument that there is nothing wrong with it currently, except we are lacking proper anti xiit or any updates. The current elma can be mastered. There is some randomness I can't argue with this but if you put enough time into it you can learn how and why. It's not like every run is ruined because some random factor. Your inputs do matter. And at the end of the day if you are skilled enough 30 fps is even less random because it has fewer places to put inputs.

I'm not saying okeol shouldn't happen. I still want it and I stand by my first post but :bear: if it sucks I will just quit. I know I can persuade jon into making it not suck though. Like having a menu that makes any sense at all for the game we are playing.
Smibu wrote: 31 Jul 2019, 18:12 "crunkoy"
lol

Sorry for the ranty post.
Image
Image
Image
Signatür ruined by SveinR - smaller plz :*
User avatar
pawq
38mins club
Posts: 6547
Joined: 24 Aug 2008, 19:56
Team: TR
Location: Southampton, UK

Re: another new eol question mark topic

Post by pawq »

jonsykkel wrote: 1 Aug 2019, 00:49i dont think its a good idea to start messing with the constants. if you do that, why not add sum horsepower to the engine, make the volts a little stronger, make the game funer to pley ??? vhy not???
secondly, i have no idea why the springs feel different at 300 and 1000fps, there is no guarantee that changing the spring rates would counteract that effect exactly

the answer to this type of question is the same answer to the quesiton of modifying internals or adding new internals: if you are gona start modifying the game in a significant way like that, who decides what changes to make?
impsy to answer, only reasonable solution - dont change anything
keep the game as close as possible to the original (but fix the things that actually are problems)
yep, yep, yep, yep, yep

bene wrote: 1 Aug 2019, 00:54 Jon is painting okeol to be some magical piece that fixes elma for all eternity but I will add the argument that there is nothing wrong with it currently, except we are lacking proper anti xiit or any updates. The current elma can be mastered. There is some randomness I can't argue with this but if you put enough time into it you can learn how and why. It's not like every run is ruined because some random factor. Your inputs do matter. And at the end of the day if you are skilled enough 30 fps is even less random because it has fewer places to put inputs.
Technically, that's all true, as in, elma is what it is, and for 20 years people had to deal with how it was and learned to master it. But it doesn't mean that it can't be improved, that it's not hurting itself at the moment. I'd be the first person to defend the physics of the game, because that's what makes it so fucking perfect, but there are these annoying things (some of which I mentioned in a post above) which are not najs. I think it's important to remember that the elma community is maybe 5-10% hardcore hoylas, and the rest are more or less casual players.

Pops have been controversial ever since their discovery. Suar, using them is not cheating, so those who took the time and effort to master them have a deserved advantage. But a fairly sizeable proportion of the community don't like the fact that they're there, because in a way they make the gameplay less "pure" (I really hope you get what I mean). I'm one of them, even though I used pops in a few levs to my advantage. But the casual player won't be bothered mastering pops, won't be bothered finding optimal fps values for every lev. It's also not just about casual players, but potential newcomers.

Ultimately my only concern is: would updating the physics engine as outlined by jon help the community stay alive and grow in the years to come. I believe that it would (or at least could, ofc depends on the exact implementation (such as a decent menu :U)). At the very least it has the potential for that, while the potential of the current EOL is rather limited.

[edit: nice to see that jon wrote pretty much teh same thing as in the above 3 paragraphs while I continued writing this post]
nick-o-matic wrote: Then the fps would be forced to be 999 (or 1000) in 99% of the levels and other values would be allowed most importantly in ints.
Can you please stop mentioning allowing low fps in particular levels. This absolutely will not happen and I explained several times why. Can do it again: firstly, it would be a huge effort for the mods which is unfeasible and unsustainable; secondly, there are no reasonable criteria by which low fps levs could be selected, because it could be of benefit in every single level; and thirdly, why would you even want to do this? Why want to tell people "okay, in this level you can fully exploit the engine, but in this level you are not allowed to and have to make do with constrained physics". In your hybrid scenario there is only one option - allow any fps in any level (as it is now). There is no feasible in-between.
Last edited by pawq on 1 Aug 2019, 01:33, edited 3 times in total.
User avatar
jonsykkel
Kuski
Posts: 982
Joined: 24 Nov 2009, 20:53
Contact:

Re: another new eol question mark topic

Post by jonsykkel »

bene wrote: 1 Aug 2019, 00:54 I like how this stopped being a "LOL WE CANT WHEELPOP SO WE DONT WANT LOW FPS - LOL WE CANT WHEELPOP BUT PRO CAN SO WE WANT LOW FPS"-fight topic to something sensible. (Side note: Any post that says they want it because they can't pop should be disregarded. Because they haven't tried. I taught sick mambo in fem, he had never done it before. I said how and he did it in less than 5 minutes. My teachings are no secret I've said millions of times how and why and when to do inputs and there are posts on lauta explaining everything. It is not a big secret and these people just refuse to even try. Even very old skool man mr knew how to do it from recs and the only thing he had wrong was guessed fps value which I told him what I use and why in fem, all other wrongs he did was him sucking because of too little höyl)

Many levels are low fps (under 100) now, only a handful of them would go from high to low in the next 5 years.

Jon is painting okeol to be some magical piece that fixes elma for all eternity but I will add the argument that there is nothing wrong with it currently, except we are lacking proper anti xiit or any updates. The current elma can be mastered. There is some randomness I can't argue with this but if you put enough time into it you can learn how and why. It's not like every run is ruined because some random factor. Your inputs do matter. And at the end of the day if you are skilled enough 30 fps is even less random because it has fewer places to put inputs.

I'm not saying okeol shouldn't happen. I still want it and I stand by my first post but :bear: if it sucks I will just quit. I know I can persuade jon into making it not suck though. Like having a menu that makes any sense at all for the game we are playing.
Smibu wrote: 31 Jul 2019, 18:12 "crunkoy"
lol

Sorry for the ranty post.
dont know if this is a response to the stuff im writing or not but if it is:
i think you are missing the point, im not saying that people cant physicaly do wheelpops or watever

ofc anyone can lern it, the point is it becomes a different type of game, and most ppl just dont want to play that game

the reason elma became an insanly popular game in the first place is not because it has wheelpops

yes there is nothing "wrong" with the game currently, yes expoliting bugs in the physics is a perfectly valid way to play the game, yes it can be mastered as shown by pro promans, but almost noone wants to fuking do it becuz its just not fun to most ppl
do you want to compete against noone?

im not painting any magical pictures im just saying what i think, like u are doing now
i like the game and im trying to prevent it from dying, which it currently: is

noones saying you havent put time into learning this stuff, ive read ur posts about how whelpops work (intresting stuf recomend) and obvisouly theres 100s of hours of vork that has gone into learning and understanding all of that

why do you think it might suck? (i really want to know)
status:ONLINE - - -  drinking:GOFE - - - iq:85 - - - elasto mania ranking:#1
User avatar
adi
36mins club
Posts: 305
Joined: 7 May 2007, 19:24

Re: another new eol question mark topic

Post by adi »

YES, we should do it. Getting rid of bug bounces, vsync, cancer pops, fps tuning etc. sounds really amazing. It has made perfectly sense to master those things, especially if you went for great internal times. But majority of players dislike them for sure. I guess I'd probably master them too if they were important for overall success in game like going for good total time, kinglist points, contest victories etc.

I don't really have any concerns. Sometimes it's good to start all over again :) (just like hard reset in cookieclicker). Also I wonder if we should release new official external level pack like EOL pack but with much better levels and more carefully thought concept, maybe something that represents modern elma era.
Team MiE
User avatar
Zero
Kuski
Posts: 548
Joined: 19 Feb 2010, 14:16

Re: another new eol question mark topic

Post by Zero »

Green light to this project if you ask me.

Any kind of a Steam release or so in the future could bring so much new life to this game. This project compared to the official Elma 2 would be so heavenly too.

Small differences won't matter much on the long run. Elastomania is a ridiculously amazing game that is slowly dropping in popularity and we should do everything we can to keep it alive :beer:
Rank #1 battler and the champion of BOSS cup :gaa:
36 club since 02/2024
User avatar
zebra
Kuski
Posts: 1009
Joined: 23 Sep 2003, 15:35
Team: TAP
Location: Finland
Contact:

Re: another new eol question mark topic

Post by zebra »

jonsykkel, after reading 90% of this topic, I think that you have a great "feeling" and knowledge of programming and elma physics. Just fix anything that you think needs fixing. I agree with you that fixed physics is the way to go.

It's also funny to read your "acrossish" ;D
A winner of 4 GAA's (mc2 included), winner of mkup206, and a proud member of team TAP.
Play uni levels: http://koti.mbnet.fi/zebra/uni.html
Homepage: http://koti.mbnet.fi/zebra/elma.html
User avatar
jonsykkel
Kuski
Posts: 982
Joined: 24 Nov 2009, 20:53
Contact:

Re: another new eol question mark topic

Post by jonsykkel »

kjhdfjkhkfjh
Last edited by jonsykkel on 9 Oct 2019, 09:45, edited 1 time in total.
status:ONLINE - - -  drinking:GOFE - - - iq:85 - - - elasto mania ranking:#1
culinko
38mins club
Posts: 1551
Joined: 29 Dec 2002, 19:17
Location: Bratislava, Slovakia
Contact:

Re: another new eol question mark topic

Post by culinko »

on a topic of fixing things, is it pos to fix internal errors too? how many internal error types are there currently? (out of bounds, too big stretch, what else?)
Image
User avatar
Zweq
34mins club
Posts: 4055
Joined: 28 Nov 2002, 15:54
Location: suo mesta

Re: another new eol question mark topic

Post by Zweq »

bene wrote: It's not like every run is ruined because some random factor.
I agree not every run, but I think some are ruined.

Imagin playing a lev with 30 fps where one spot is played with very high speed. You must perform a volt to dodge a killer. The volt input precision required to survive is < 10ms, if one frame is 33ms long then some runs are imposible to survive.

Same issue occurs at int04 TAPPI at around 20s, except ther you don't die if volt timing is slightly off, you just lose some time.
Image
User avatar
roope
37mins club
Posts: 1552
Joined: 14 Apr 2008, 17:58
Team: MiE
Location: smedjebacka

Re: another new eol question mark topic

Post by roope »

I think the discussion is great, I think the whole thing is great, but at some point mans just gotta agree to disagree and get to vvork (which I'm sure jon will do anyway). It's not uncommon that some details of a thing will be discussed endlessly and the actual thing that was supposed to happen never happens because of the discussion, so just go for it, I believe in jon's vision and reasoning)
Team MiE - MiE Cup 1
Prestigious member of 14.6x Tutor14 club
User avatar
jonsykkel
Kuski
Posts: 982
Joined: 24 Nov 2009, 20:53
Contact:

Re: another new eol question mark topic

Post by jonsykkel »

culinko wrote: 1 Aug 2019, 09:47 on a topic of fixing things, is it pos to fix internal errors too? how many internal error types are there currently? (out of bounds, too big stretch, what else?)
i belive al reasons for int errs are fixable
there are very many of calls to the error func but iirc the one that always hapens is out of bounds, the bike does something weird when it stretches too far and things start teleporting out of galaxy (have 2 investigate if that is fixable, ahvent looked @ it yet. its not gona exit the game thoguh thats 4 sure. i think mostly not a problem at 1000fps anyway maybe unless make weird lev)
status:ONLINE - - -  drinking:GOFE - - - iq:85 - - - elasto mania ranking:#1
User avatar
milagros
Cheatless
Posts: 4560
Joined: 19 May 2002, 17:05

Re: another new eol question mark topic

Post by milagros »

btw in current eol both of these issues are fixable with minimal effort
elma has already some restriction not to run below certain time step, so to make it run 1000fps internally it is enough to edit that value
for bugbounces, it is enough to add asm code equivalent to if(d < epsilon) d = epsilon;
too bad i've already forgotten where's what
[carebox]
Post Reply