Zweq wrote:
Then, as we know there are couple of .exes in the elma folder. It seems that elmaconf affects elma12.exe but not eol.exe, that leads to a problem with defining alovolts and keys. In fact I don't exactly remember what was the problem with this, because it was in the spring we had problems with defining the keys. I remember I had to change elmaconf.exe from another elma folder to get it working, was quite a struggle I remember. Either way it's quite damn confusing, not 100% sure if I can say it is bugged.comms.
There is specific Elmaconf12.exe you can use to config eol.exe. I don't know if it was packed next to eol or not.
http://mxb.dk/upload/ElmaConf12.exe
For me main feature of this battle elma would be displaying best time and others playing around.
I think Flag Tag can't be done properly since you'll use UDP (there can be package losses, and you'll have to interpolate less precisely on serverside, ie. calculate if you touched the opponent carrying the flag or not from deficient data), and packages sent from client less frequent than it'd be needed (50 ms is not enough imo).
It'd work, but the little nuances that define FT would be lost.
Though it'd introduce massive flag tagging
(kinda different levs needed for ie. 6 players than for 2)
Same-time-flag-taking-by-multiple-players
issue should be solved by random flag distribution. (or maybe giving it to the guy with the less flag-possessing time?)
In my opinion FT can be done if you can guarantee that all the client data arrives at the server, and you send enough of them to reach same accuracy as in eol (or "normal" 1-comp flag tag).