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

Smibu
Kuski
Posts: 465
Joined: 15 Jun 2007, 13:17
Location: Finland

Re: another new eol question mark topic

Post by Smibu » 1 Aug 2019, 17:53

jonsykkel wrote: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
Yea ofc not, I just realized I never really mentioned the refactoring thing, so I did it now.
jonsykkel wrote: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.
Ye ok, I never got around to customizing the default skin (and I agree it looks bad), so not sure if it was fixable. But another bad thing about CEGUI is that it doesn't have keyboard support. I coded some custom kb handler, but it's far from perfect. Also it looks max ugly on 4K screen.

Some more Rust sales pitch...
jonsykkel wrote:i dont like rust, it seems to have many of the things i dont like about c++ (way too complicated syntax).
Ye, syntax is kinda subjective I guess. Was there any specific snippet of Rust code that looked too complicated?
jonsykkel wrote:i dont care about memory safety, just write things carefully (like you shud be doing anyway) and it isnt a problem.
Yup, that's the ideal. But, the existence of various C/C++ analyzers and sanitizers shows it's not so easy :)

The annoying thing about C/C++ is that some bugs cause undefined behavior, so with bad luck the bug won't manifest itself right away but a lot later, so it's harder to track down.
jonsykkel wrote:if i used rust for the server it would be riddled with bugs, since i dont know the language
But here's the great thing about Rust - it's really hard to write Rust code that 1) compiles but 2) is broken. So beginners spend most of the time fighting the compiler errors. It's way more strict than C or C++ because Rust doesn't allow "dumb mistakes".

I forgot to mention that it's really simple to use 3rd party libs (e.g. a TCP/HTTP server) in Rust. Basically you say "cargo add xxx" and then you can "use xxx;" in code. I've never used C so I can't say if it's easy/hard there. At least in C++ it's a pain to add a library because there's no standard package manager.

User avatar
jonsykkel
Kuski
Posts: 916
Joined: 24 Nov 2009, 20:53
Team: BAP
Contact:

Re: another new eol question mark topic

Post by jonsykkel » 1 Aug 2019, 18:48

Smibu wrote:
1 Aug 2019, 17:53
jonsykkel wrote: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
Yea ofc not, I just realized I never really mentioned the refactoring thing, so I did it now.
btv while ve are on the topic of smibuelma and using gode from it, most ppl know but nabs maby dont, the only reason any of this is posible is becuz smibu reverse enginered elmaphysics in 2011 or somethign and shared gode with me (and other ppl) so alredy kind of maked bigest cuntribution posible by making new elma a posibiltiy at al


Smibu wrote:
1 Aug 2019, 17:53
Ye, syntax is kinda subjective I guess. Was there any specific snippet of Rust code that looked too complicated?
not any specific no, just any rust ive ever seen has loked complete chinese
also sumting i 4got mention - never used rust but i belive from wat ive read the build times are even more ridiculous than c++, which is just nat gona vork


Smibu wrote:
1 Aug 2019, 17:53
Yup, that's the ideal. But, the existence of various C/C++ analyzers and sanitizers shows it's not so easy :)
sure if just anyalize any random avg code its gona suk, no big surprise there )
have tryed clang static analizer (probably not best or anyhting no idea) on sum of my recent gode, complained about few things but vas only 1 or 2 potentialy "serious" problems in that 100kb src


Smibu wrote:
1 Aug 2019, 17:53
The annoying thing about C/C++ is that some bugs cause undefined behavior, so with bad luck the bug won't manifest itself right away but a lot later, so it's harder to track down.
for sure, gota be more careful with c/c++ than any other languages probably


Smibu wrote:
1 Aug 2019, 17:53
But here's the great thing about Rust - it's really hard to write Rust code that 1) compiles but 2) is broken. So beginners spend most of the time fighting the compiler errors. It's way more strict than C or C++ because Rust doesn't allow "dumb mistakes".
its probably good at eliminating one class of mistakes ye, i wish c cumpilers cud do that kind of stuf beter, but its stil not a good enough reason


Smibu wrote:
1 Aug 2019, 17:53
I forgot to mention that it's really simple to use 3rd party libs (e.g. a TCP/HTTP server) in Rust. Basically you say "cargo add xxx" and then you can "use xxx;" in code. I've never used C so I can't say if it's easy/hard there. At least in C++ it's a pain to add a library because there's no standard package manager.
if using visual studio or sach its probably max horror yes
if using sum kind of linus like environment it realy is ez af, maybe not as ez as rust but ez enoguh
also im not plannign on using many libs, using other ppls code suks, i vrite most my self
Last edited by jonsykkel on 26 Aug 2019, 03:34, edited 2 times in total.
Image
Image
Prestigious member of 16.6x IL101 club

User avatar
jonsykkel
Kuski
Posts: 916
Joined: 24 Nov 2009, 20:53
Team: BAP
Contact:

Re: another new eol question mark topic

Post by jonsykkel » 1 Aug 2019, 18:50

milagros wrote:
1 Aug 2019, 17:52
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
indead, just changing that 0.0055 vorks
Image
Image
Prestigious member of 16.6x IL101 club

User avatar
ribot
Not banned
Posts: 2289
Joined: 19 May 2002, 16:20
Location: omnipresent fractal hologram
Contact:

Re: another new eol question mark topic

Post by ribot » 1 Aug 2019, 18:53

Generally I think it's a good idea to make this project happen.

I would focus on a strategy with the highest probability of making it happen. For example:
- there is a coding philosophy that says "release often"
- make the project open source so that others can contribute (only hide any code that is essential to hide)
- make the project as small as possible, for example never implement anything that is not 100% required right now
- focus on the essentials first, such as seeing how physics actually feel, and let zampape tweak it
- such things as implementing eol features like battles and api's could be delegated to other coders, the whole project doesn't have to break just beacause jon couldn't make everything
- the less features you add, the higher quality each feature will become

and so on

- ElmaWars http://zzz.ink/war - lauta
- Elma Title
- Elma 3D HD (RPG GAME, GAA nominee)
"leader status in the Elma against-the-system underground" - Abula

User avatar
jonsykkel
Kuski
Posts: 916
Joined: 24 Nov 2009, 20:53
Team: BAP
Contact:

Re: another new eol question mark topic

Post by jonsykkel » 1 Aug 2019, 19:01

ribot wrote:
1 Aug 2019, 18:53
- there is a coding philosophy that says "release often"
- make the project as small as possible, for example never implement anything that is not 100% required right now
- focus on the essentials first, such as seeing how physics actually feel,
- the less features you add, the higher quality each feature will become
agre


ribot wrote:
1 Aug 2019, 18:53
- make the project open source so that others can contribute (only hide any code that is essential to hide)
- such things as implementing eol features like battles and api's could be delegated to other coders, the whole project doesn't have to break just beacause jon couldn't make everything
posibly in the future but for now im gona do everything just becuz i dont know how the code is gona look when its done so i cant break it into peaces and assign difrent developers to them, it doesnt vork in my experience unless u can clearly outline the structure of the finished thing, which i cant
but vhen its in a more cumplete state, cud be idea
and if im give up ill let anyone who vants (and is good enoguh) try to continue it


ribot wrote:
1 Aug 2019, 18:53
... and let zampape tweak it
again im dont htink its a good idea to make more changes to the physics than jsut fixing shit that are actualy problems
Image
Image
Prestigious member of 16.6x IL101 club

User avatar
Zweq
35mins club
Posts: 3953
Joined: 28 Nov 2002, 15:54
Location: suo mesta

Re: another new eol question mark topic

Post by Zweq » 2 Aug 2019, 12:28

- what is perfekt doesn't need tweaking
- jonig already going for 5/5 fizics changes
- i gues only debatable addition is reverse alo but loL lets not go ther
- hi
Image

User avatar
ribot
Not banned
Posts: 2289
Joined: 19 May 2002, 16:20
Location: omnipresent fractal hologram
Contact:

Re: another new eol question mark topic

Post by ribot » 2 Aug 2019, 13:12

for sure jon i agre that yuo should do things the way they feel right for you...

the ztampe tweaking was meant only if solving the physics wouldn't be straightforward, as i thought i read you were not 100% sure how it would work out, and if there would have to be decision making and trade-offs

my main points were that:
- the strategy is there for making the efforts count, so that the same amount of efforts could actually become something instead of a huge project nobody wants to touch
- there are many improvements that could be made to the surrounding systems, and these would perhaps take more time than the physics fix.

once the physics is fixed the surrounding systems should have the ability to be continually developed, instead of locked to one developer such as with eol and smibu's elma 2. the surrounding systems being:
- the game interface, making it easier to find and delete recs and levs, as well as improvements for seeing best times and contest info in levs
- the chat, battle and api interfaces could give scope to so many more types of contests if the api were better, and also if there are ppl with new ideas they should be able to implement them

these interfaces should be completely revolutiionized to make it easier for contest creators to host their contests and invent new contests

- ElmaWars http://zzz.ink/war - lauta
- Elma Title
- Elma 3D HD (RPG GAME, GAA nominee)
"leader status in the Elma against-the-system underground" - Abula

User avatar
milagros
Cheatless
Posts: 4446
Joined: 19 May 2002, 17:05

Re: another new eol question mark topic

Post by milagros » 2 Aug 2019, 16:52

in any case these changes are trivial and can but changed in 5 mins both way when the code is done
so there is no point in discussing atm
[carebox]

User avatar
ribot
Not banned
Posts: 2289
Joined: 19 May 2002, 16:20
Location: omnipresent fractal hologram
Contact:

Re: another new eol question mark topic

Post by ribot » 2 Aug 2019, 17:51

you forgot to lock thread

- ElmaWars http://zzz.ink/war - lauta
- Elma Title
- Elma 3D HD (RPG GAME, GAA nominee)
"leader status in the Elma against-the-system underground" - Abula

User avatar
ArZeNiK
39mins club
Posts: 485
Joined: 30 Jul 2016, 09:18
Team: Ferrari

Re: another new eol question mark topic

Post by ArZeNiK » 2 Aug 2019, 21:06

milagros wrote:
2 Aug 2019, 16:52
in any case these changes are trivial and can but changed in 5 mins both way when the code is done
so there is no point in discussing atm
indeed this discussion is pointless. that's why it has been going on for 3 pages
I like turtles
Image

User avatar
jonsykkel
Kuski
Posts: 916
Joined: 24 Nov 2009, 20:53
Team: BAP
Contact:

Re: another new eol question mark topic

Post by jonsykkel » 2 Aug 2019, 21:55

ribot wrote:
2 Aug 2019, 13:12
- the strategy is there for making the efforts count, so that the same amount of efforts could actually become something instead of a huge project nobody wants to touch
im dont think pouring 500 goders into the project avoids that risk, i think it increases the risk of that happening


ribot wrote:
2 Aug 2019, 13:12
- there are many improvements that could be made to the surrounding systems, and these would perhaps take more time than the physics fix.

once the physics is fixed the surrounding systems should have the ability to be continually developed, instead of locked to one developer such as with eol and smibu's elma 2. the surrounding systems being:
- the game interface, making it easier to find and delete recs and levs, as well as improvements for seeing best times and contest info in levs
- the chat, battle and api interfaces could give scope to so many more types of contests if the api were better, and also if there are ppl with new ideas they should be able to implement them

these interfaces should be completely revolutiionized to make it easier for contest creators to host their contests and invent new contests
eol can be improved, yes
all of these are trivial things that cud be fixed/changed/aded at any point (including ading more goders)
to begin with everything has to be done by 1 mans with 1 vision or else its gona be a mess


Zweq wrote:
2 Aug 2019, 12:28
- hi
hi
Image
Image
Prestigious member of 16.6x IL101 club

User avatar
bene
Hot kuski
Posts: 881
Joined: 18 Aug 2003, 23:33
Team: dat
Location: Sweden
Contact:

Re: another new eol question mark topic

Post by bene » 3 Aug 2019, 01:30

Zweq wrote:
1 Aug 2019, 12:24
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.
So what I say is not every run is ruined. There is random factor, we can't avoid this currently. But scenario that is described with killer doge happening in middle of frames where you want to do stuff and can't because middle of frame won't happen because you:
a) chose different fps because smart
b) played ever so slightly differently to adjust for it, i've found some extremely weird things that help in ints
c) bear

Even with perfect play there will be slight randomness but it's not much like we can't do input at all. If we are not idiots we can do it in time because of fps we chose. Sure choosing fps might be boring for some but it is also huge part when you start to think level of choosing fps where can volt with correct frames. I've done this in externals, never internals.

Edit: I still wan't okeol. It's great idea and good. I just put ranty drunk arguments because I can :bear:
Image
Image
Image
Signatür ruined by SveinR - smaller plz :*

User avatar
Zweq
35mins club
Posts: 3953
Joined: 28 Nov 2002, 15:54
Location: suo mesta

Re: another new eol question mark topic

Post by Zweq » 3 Aug 2019, 07:11

bene wrote:
3 Aug 2019, 01:30
Zweq wrote:
1 Aug 2019, 12:24
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.
So what I say is not every run is ruined. There is random factor, we can't avoid this currently. But scenario that is described with killer doge happening in middle of frames where you want to do stuff and can't because middle of frame won't happen because you:
a) chose different fps because smart
b) played ever so slightly differently to adjust for it, i've found some extremely weird things that help in ints
c) bear

Even with perfect play there will be slight randomness but it's not much like we can't do input at all. If we are not idiots we can do it in time because of fps we chose. Sure choosing fps might be boring for some but it is also huge part when you start to think level of choosing fps where can volt with correct frames. I've done this in externals, never internals.

Edit: I still wan't okeol. It's great idea and good. I just put ranty drunk arguments because I can :bear:
Somhow i guessed you will com up with that argument, i thought about it. It simply isn't plausibl to play perfectly in longer complex levels with many inputs, slight improvisation is required. You'r basically talking about freefall, sure in there some rides ar definitely clones of previous ones if playing with 30 fps and do lots of tries. Still i think somtimes you don't get 11.3x even with perfect play. This is just my hypothesis, i don't know if it's corect or wrong.

Also there's no point of arguing about this at al because it shud be posible to pretty easily prove this hypothesis corect or wrong with hardcoded inputs for specific frames if you hav acess to smibu or jonsykel code.
Image

User avatar
milagros
Cheatless
Posts: 4446
Joined: 19 May 2002, 17:05

Re: another new eol question mark topic

Post by milagros » 3 Aug 2019, 16:56

Zweq wrote:
3 Aug 2019, 07:11
Also there's no point of arguing about this at al because it shud be posible to pretty easily prove this hypothesis corect or wrong with hardcoded inputs for specific frames if you hav acess to smibu or jonsykel code.
bene has access to the format of teh dat files
[carebox]

User avatar
Bjenn
35mins club
Posts: 2363
Joined: 25 Apr 2007, 14:23
Team: EF
Location: Östersund, Sweden

Re: another new eol question mark topic

Post by Bjenn » 5 Aug 2019, 08:23

Yes I'm tired of all fps-tweaking and pops here and bugbounces there. Would be awesome with new elma version with static FPS.

Post Reply