Replay Pallàs — A platform to share your replays

[Stan`]

53 minutes ago, Feldfeld said:

I guess I couldn't upload the replay since nothing happened. I'm on Librewolf browser

Can you upload the zip you tried here ? (It only works with zips)

[Feldfeld]

Archive.zip

Tried another structure after and didn't work

[Stan`]

8 hours ago, Feldfeld said:

Archive.zip 302.43 kB · 2 downloads

Tried another structure after and didn't work

Should be fixed now, There was a bug in the GUI. You'll also get a loading bar at the top

[Stockfish]

It looks very nice, and a very good project, as I read it's not possible to upload replays directly, but maybe it could be fine to add a "upload to pallas" on the replay when you watch it from your game.

Are you @Stan` going to use the site for something else?, it has good design tbh.

By the way, any recent new about A27?

[Stan`]

5 hours ago, Stockfish said:

It looks very nice, and a very good project, as I read it's not possible to upload replays directly, but maybe it could be fine to add a "upload to pallas" on the replay when you watch it from your game.

Are you @Stan` going to use the site for something else?, it has good design tbh.

By the way, any recent new about A27?

You should be able to upload replays now. I'm vetting users manually.  

Technically it's possible to send replays from the game, but I'm not going to write the C++ code for it  

Regarding the website itself no I don't plan to use it for something else why ?

Pushed some fixes to the website, some matches were not visible in local ratings. 

Sanafur: If you're having trouble accessing the website let me know, it's the third account you create.

[Stan`]

Pushed some fixes. There was an issue with registration. Still no emails as I'm not sure it's worse the hassle.

We got a few replays yesterday which now total to 98.

 

[TheCJ]

On 01/03/2023 at 8:59 AM, Stan` said:

For security reasons there will be no direct upload button there if it gets online, but rather you'll be able to upload replays to single thread and it will be scrapped periodically.

I'm sorry, I can't quite follow. Where exactly am I supposed to upload the replays? 
Or should I just send them to @Dizaka ?
Lastly I'm unsure what kinds of replays are of value... I doubt a25 or a24 replays are of any interest, as they don't reflect the state of the game right now? And replays with very untested/unfinished modifications probably don't add anything either?

[Stan`]

18 minutes ago, TheCJ said:

I'm sorry, I can't quite follow. Where exactly am I supposed to upload the replays? 
Or should I just send them to @Dizaka ?
Lastly I'm unsure what kinds of replays are of value... I doubt a25 or a24 replays are of any interest, as they don't reflect the state of the game right now? And replays with very untested/unfinished modifications probably don't add anything either?

Hey,

I've given you access, you can now add replays on this page https://replay-pallas.wildfiregames.ovh/Replays
You can also send them to Dizaka.
 

A26 1v1 and team games are welcome. Basically if you think someone like @mysticjim  @superflytom @zxphxr or @ValihrAnt would be interested in streaming them, they should go on the platform.

The more replays we get the more accurate the local rating plugin by @Mentula will be. For 1v1 it also feeds your glicko rating.
 

For security reasons there will be no direct upload button there if it gets online, but rather you'll be able to upload replays to single thread and it will be scrapped periodically. 

My first announcements flopped hard, so I never did get around making a thread I'd scrap.

[Stan`]

• Small update, improved performance a bit using caching (the first call will be slow, but the rest will be fast)
• Fixed searching for player names breaking the background menu
• Fixed searching for players in local ratings being case sensitive.
• Added CPT (commands per turn) chart
• We now have 643 replays

[Stan`]

Working on a CPM graph, which is a bit more readable.

Dunno what happened there @guerringuerrin Some kind of frenzy ? ;D

[ffm2]

1 hour ago, Stan` said:

Some kind of frenzy

That's a teleport.

Quote

turn 5526 200
cmd 1 {"type":"construct","template":"structures/brit/arsenal","x":598.5357055664062,"z":248.4114990234375,"angle":2.356194490192345,"actorSeed":14179,"entities":[292,293,295,7134,7232,7244,7245,7348,7349,7549,7550,7551,7552,7784,7786,7830,7951,7952,8274,8275,8277,8308,8309,8310,8364,8495,8497,8700,8798,8799,8808,8810,8909,8910,9211,9212,9230,9231,9233,9406,9407,9408,9409,9567,9577,9682,9708,9726,9760,9834,9835,9876,9877,10043,10044,10045,10058,10059,10061,10062,10263,10264,10265,10413,10414,10415,10416,10417,10418,10419,10420,10421,10422,10456,10457,10468,10469,10592,10593,10595,10608,10609,10720,10721,10788,10803,10804,10805,10806,11076,11077,11078,11079,11080,11081,11082,11083,11184,11185,11186,11391,11417,11418,11422,11423,11655,11656,11657,11658,11880,11881,11882,11883,11884,11960,11997,11998,11999,12000,12001,12099,12100,12101,12102,12103,12156,12228,12274,12275,12276,12277,12278,12347,13466,13728,13777,13778,13965],"autorepair":true,"autocontinue":true,"queued":false,"pushFront":false,"formation":"special/formations/null"}
cmd 8 {"type":"train","template":"units/gaul/infantry_javelineer_b","count":1,"entities":[7065,7469,8232,9599,10869,11649],"pushFront":false}
cmd 7 {"type":"attack-walk","entities":[14719,14720,14721,14722,14723,14724,14725,14726,14727],"x":370.9630432128906,"z":810.8374633789062,"targetClasses":{"attack":["Unit"]},"queued":false,"pushFront":false}
cmd 7 {"type":"attack-walk","entities":[14719,14720,14721,14722,14723,14724,14725,14726,14727],"x":370.79071044921875,"z":811.256591796875,"targetClasses":{"attack":["Unit"]},"queued":false,"pushFront":false}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
cmd 3 {"type":"leave-turret","entities":[]}
cmd 3 {"type":"unload-all","garrisonHolders":[14260]}
end

 

Insane. This variety from 80 to 10 also speak against a fixed multiplier per special hardwarde.

 

Maybe unnecessary commands like this should not be send over the network / recorded at all?

[Stan`]

There is probably some optimization to be done here. But in general I don't expect people to be able to do 80 actions per 200ms

[Acero]

Congratulations for the replay sharing platform.

Regarding the @guerringuerrin spike of 80 ungarrison commands in one turn, that's a bug in 0AD, and should be fixed.

During the sniping autoclick trend of last year, some players analized spikes in 'command.txt' files like the one mentioned above, looking for click amplification during sniping on some games, and by chance they found this problem existed.

The situation is caused when, during lag spikes in games, the user keeps the ungarrison key pressed for several seconds. 0AD seems to record the key press every frame, so the amount of commands start to accumulate super fast, even if you keep the key pressed for only a few seconds.

Of course it makes zero sense to record and send so many commands over the network, when just one command per turn is enough.

Keeping the ungarrison key pressed for several seconds is useful when you want to teleport a lot of troops, say through a castle:
    1. You set the garrison point of the castle the way you want.
    2. You order your army to go into the castle
    3. You keep the ungarison key pressed for several seconds until all troops teleported.

If you make repeated key-presses instead of holding the key down it will likely not produce this spike.

As this behavior is useful in normal gameplay, and players will continue to use it, it would be ideal if 0AD would not spam the replay file and the network with such useless identical commands on one turn.

[Acero]

Another benefit of fixing this issue in 0AD (besides making replay files smaller and use less network bandwidth) would be that analizing replays for APM spikes in search of cheat behavior would not be cluttered by noise caused by 0AD malfunction, and would be actually more useful.

[ffm2]

Indeed. I just held the U key down in one player in this figure. So one can imagine with a bit of lag for this to pile up fast. This is new to me, but I had a break of 4 years. Maybe I did it wrong back then or it is new behavior. Thanks

[Acero]

Nice experiment.

I think you can get higher spikes in team games when the game lag is at its highest, and also if you PC is quite fast. You will tend to keep the "U" key pressed down for longer because of the lag util all your troops teleported , and your fast PC will have a lot of frames to capture a lot of useless repeated commands during that time.

[Stan`]

Hmm I supose this could be fixed by some sort of debounce function, but it would probably cause more lag. I don't know if it can be fixed easily. (detecting command patterns undoing each other sounds hard)

[Acero]

On another topic, if we want to analyze players APM (actions per minute) or APS (actions per second) to detect abnormal cheaty/automatic behavior, it will be necesary that the replay file (commands.txt) not only saves the turn number as it does now, but also the clock time elapsed (for example in miliseconds) on each turn.

Due to game pauses and game lag we have absolutely no way to know how long each turn took in real clock time, so any APM analysis on replays will be flawed, no matter how sophisticated the analysis tool is.

I would advocate for adding this extra piece of information to every turn on the commands.txt file in the next alpha. If we limit it to miliseconds elapsed since the game started, the number would not be too huge and would not bloat the replays too much.

On another thread someone posted a stockfish game where he had a spike of about 20 unique attack commands in one turn. We can only wonder how long that turn took in real clock time, as that information is lost forever.  A turn can take more or less clock time depending on different factors, like: cpu lag, network lag, and even pauses (autociv allows to issue commands even when the game is pauses). This is just an example of how if elapsed time per turn was recorded in the replay, discussions about automation could be way more grounded.

Another benefit of this, would be that the devs could actually use Replay Pallàs to detect which games have bigger lag spikes and when in the game these spikes happen, in order to use these replays for optimizing 0AD further, instead of relying on abstract tests.

Edited Tuesday at 15:56 by Acero

[Acero]

2 minutes ago, Stan` said:

Hmm I supose this could be fixed by some sort of debounce function, but it would probably cause more lag. I don't know if it can be fixed easily. (detecting command patterns undoing each other sounds hard)

Stan, two ideas come to my mind:

1. I guess somewhere in the game there must be a function for recording and sending the data produced a player every turn. Just dont record a command if another exact same already exists on this turn. Its not about undoing commands as you suggest, but saving just one of each type of command each turn.
2. This repetition pattern of a keypress being held, reminds me of the typical repetition of a normal text editor if you press and hold any key: for example the "u" key you get this: uuuuuuuuuuuuuuuuuuuuuuuuu.  In most operating systems control panels this feature is adjusted by two sliders: "repeat delay", and "repeat speed". Clearly 0AD does not obbey the operating system "repeat speed", but maybe there is a way to lower it down in the 0AD code itself, so that the repetition of a pressed key does not happen on every frame.

[ffm2]

1 hour ago, Acero said:

I would advocate for adding this extra piece of information to every turn on the commands.txt file in the next alpha. If we limit it to miliseconds elapsed since the game started, the number would not be too huge and would not bloat the replays too much.

On this note I'd like to add to the metadata.json:

-decrease the sequence interval from 30s to 10s (if the resulting size is accaptable)

-add a counter for trainer idle times (e.g. you have your barrack and cc idle for 1 s the counter adds 2 s) Edit: Better a counter for each type. For stables and corrals it's not so crucial if they stay idle (But still 2 idle baracks increase the counter by 2 each second).

Edited Tuesday at 16:50 by ffm2

[ffm2]

17 minutes ago, Acero said:

This repetition pattern of a keypress being held, reminds me of the typical repetition of a normal text editor if you press and hold any key: for example the "u" key you get this: uuuuuuuuuuuuuuuuuuuuuuuuu.  In most operating systems control panels this feature is adjusted by two sliders: "repeat delay", and "repeat speed". Clearly 0AD does not obbey the operating system "repeat speed", but maybe there is a way to lower it down in the 0AD code itself, so that the repetition of a pressed key does not happen on every frame.

I think it gets a key press and a release signal. Navigating the map with wasd would be very laggy if it were by interval signals in the scope of appearing text.

[guerringuerrin]

Just for the record. Yeah! I use a lot garrison as teleport. I always hold U instead of spaming as sometimes building capacity gets full just right when you lift the finger and remaining soldiers no more enters the building turning the manouvier in a total mess xD

Edited Tuesday at 18:13 by guerringuerrin

[real_tabasco_sauce]

4 hours ago, ffm2 said:

Indeed. I just held the U key down in one player in this figure. So one can imagine with a bit of lag for this to pile up fast. This is new to me, but I had a break of 4 years. Maybe I did it wrong back then or it is new behavior. Thanks

Wouldn't it be a good fix to only execute degarrison commands if there are units to degarrison? It seems sub-optimal to have a ton of commands that don't do anything.

Edited Tuesday at 19:38 by real_tabasco_sauce

[Stan`]

9 hours ago, Stan` said:

Working on a CPM graph, which is a bit more readable.

Dunno what happened there @guerringuerrin Some kind of frenzy ? ;D

Feature is now live

6 hours ago, ffm2 said:

decrease the sequence interval from 30s to 10s (if the resulting size is accaptable)

This would add a significant size increase.
 

 

3 hours ago, real_tabasco_sauce said:

Wouldn't it be a good fix to only execute degarrison commands if there are units to degarrison? It seems sub-optimal to have a ton of commands that don't do anything.

In the replay above, it does it in loop, so garrison ungarison, garrison ungarrison and so on... Technically it's doing something ^^