hyperion

Possible but probably not worth it. Up to you tho. The basic idea is to have a root actor which only defines an attach point and then use props (actors themself) for each "variant-group"

Flaming pigs would make some sense, but agreed, in the video it looks like punctured oil vats on legs running around. As for spreading fire, the computational cost for non structures probably isn't cheap either.

Check https://trac.wildfiregames.com/wiki/Manual_Cheats You could also run two instances of the game and play lan multiplayer against yourself, ie each window controlling a player. Trivial if on LInux probably harder on Windows.

And what do you want to decentralize?

There are 2 points to be made. First, it's not up to the community at large to decide, only the players in a particular game. Asking the community for consensus is unimaginable anyway. Secondly, it can't be called cheating at all if you are open about your modifications. PS: psychedelic trees and velociraptor chickens are a no-go, at least for me.

@Norse_Harold, Had time to really dig into it. There are one or two bugs in enet depending on how you want to look at it, first enet uses MTU in a misleading way. Secondly during mtu negotiation on connect the server doesn't check for lower mtu and just uses the one passed by the client. https://github.com/lsalzman/enet/issues/132 https://github.com/lsalzman/enet/pull/222 https://code.wildfiregames.com/D4967

https://github.com/lsalzman/enet/issues/132 So at this point I suspect that enet doesn't take the 28 bytes for the header into account, this would still allow some vpn to work but not all of them within 1400. So code digging it will be

There is the thing called path mtu discovery, but it's tricky and or unreliable. The reason why I'm somewhat skeptical is such a bug should have been found long ago one might think. This sounds a bit like luck that the order was preserved.

Which means mtu is 1420 between both of you, if now with your host patched to mtu of 1392 there are no drops anymore we have a bug in enet. Will check enet over the weekend to confirm. Possibly a release blocker as it would mean vpn definitely is broken.

An enet package might be much larger than the MTU, then fragmentation is done based on MTU of both peers (server/client). That would be futile as it won't update the MTU on the side of the peer. Given the information in this thread so far the issue is not on your end, but you can ofc fix the issue on the other end if it's mtu related by lowering your enet mtu at the cost of possibly making all other connections less efficient at the same time. Attached a cleaner patch without sanity checks that allows setting mtu in config or via command line, ie. pyrogenesis -conf=network.mtu:1392 Anyway not yet convinced that this is the actual issue, yes might be, but still waiting for the output of the original ping command from @Helicity to confirm. enet-mtu.patch

Well, you could ping play0ad or whoever instead with the above arguments. In case you are the bottleneck this would suffice. 1400 should work with a vpn but yours might cut it further than strictly required. Meaning "ping -M do -s 1392 play0ad.com" succeeds. If so there is supposed to be no issue on your end and the enet default of 1400. You shouldn't unless required but if you want, there is no config in 0ad so you have to patch the code. Just set it right after enet_host_create on the returned struct, then let it run as usual.

Quick look, enet assumes an mtu of 1400, so what's the output of ping -M do -s 1372 [norse_harolds ip]

To the right, maybe a different page would make sense as well. Covering existing buttons I'd say is bad practice.

A somewhat valid concern. Using the match title in the lobby is unsuitable as likely you want to name it after the game and it should also support single-player matches. For tags I'd go with free form first. If it becomes an issues it's still not to late to not show them or even filter them using the service. Also you haven't mentioned GDPR yet

The only reason I see to use more than one background is one can't bear to remove the others. It's certainly better to stick to one from an UX point of view and change it only on new release. --- As for vertical orientation of main buttons, I'd place them roughly where Athena upper body is in the above screenshot, just in case you are still brooding this question.

It makes you more competitive, you can deny that. Personally, as for autociv I can't imagine playing the game without anymore.

42 ... , well this question doesn't have enough meat for me to answer. Well, I only have ever seen 2 users generating replay archives indicating they are aware of the specifics involved and so making it possible for others to just unpack those. (I'm only talking about solving the sharing of replays P2P via forum, mail etc without any dedicated service here) Developing a service in tandem or first may not be bad tho, as it may highlight additional requirements (title and tags were mentioned already) for a potential pyroreplay format.

Not using the service but the current approach of zipping and unzipping with "date-gamenumber". Also people use arbitrary root, wonder whether they need metadata.json and so on. Those things would have to be done by the engine (c++) ofc. The UI just calls into the engine. You can simply create a symlink to the replay directory at any time, no need for the engine to know about it at all.

Autociv or @Yekaterina own gui mod are "exploits" on another level as they give even more advantage than this disconnect trick to see stats in competitive play. About disconnect, whether intentional or not, the important bit is to communicate to fix you network if you have issues. In the maybe 200 to 300 games I played over network I have yet to see this issue even once. So the attitude of it's normal to have such issues bugs me.

One of the things I had in my mind as nice to have. Just I'd start with an export / import replay feature in-game. There are many who struggle with exporting manually and we see formats like 7z, rar and what not. Also there are possible file collisions with this approach. So having a standardized replay file format (pyroreplay ?) taking care of all such nuisances would already much improve the replay sharing situation. Once in place this format would then be the basis of such a service.

Of course, but that's not what happens with vanilla 0ad. I can't reproduce it. The stats are only ever shown if the game is considered finished. It's trivial enough to change the code to always show it if people want to cheat. About connection issues, the threads listed by @Genava55, we have driver bug and powersave issues. Anyone playing competitively is expected to fix or workaround such issues. In fact everyone who drops every ten minutes and isn't inclined to fix it is an annoyance for other players. So yuo may call it sarcastic, but for me this belongs into the realm of netiquette.

It's fine to continue to play a game that is considered 'finished' for the fun of it but the rating points should be issued based on when the game was considered 'finished' first time. PS: Just a guess, technical error, e.g. program crash, network problems etc would be come a lot rarer if they wouldn't help avoiding point loss

This is the only issue here, disconnect should mean loss of rated game.

One is a resource the other not, there is no inconsistency here. This is the same as AoE2 AFAIR.

If it's really old hardware as stated Vulkan won't be available, and the userreport_hwdetect indeed suggests this to be the case.