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