hyperion

Ranged units have to high dps so let's change all else.

Probably because you are a new user, so some "spam protection" will be imposed on you for some time.

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.