hyperion

svn

Don't know how you tested, anyway simply setting it to 10% to make the effect more pronounced and running combat demo huge I see quite the difference (actually more than predicted). Given that this change also has an effect on unit composition I'd expect an even more favorable result for regular game play.

The tech I posted impacts bolt, structures, ships and ele archers all the same, whether this is as it should be is up for debate. I never claimed zero side effects, but there is a difference between a few and many all over the place. One possible side effect of the half dps change might be better performance of the game for example.

@nz., there was an issue with dns for a couple hours, should be fixed now. Give it another try.

Which is as intended, ranged units shouldn't matter much in straight up fights but having to make use of obstructions like natural chockpoints or walls to be really useful. If a micro god can get value from ranged units that's fine too. Bolt shooters also do ranged damage, so also affected by half dps. Btw, a couple alphas back you didn't even need a small army to defend a small mass of bolt shooters for them to be invulnerable.

ranged vs buildings, ranged vs sieges isn't meant to be a thing in the first place, ranged vs units is the whole point of this change.

It's the obvious solution without a dozen side effects. I still feel @Feldfeld suggestion of halving ranged damage as a start the most reasonable approach. Those willing to test may drop the following into simulation/data/technologies { "autoResearch": true, "modifications": [ { "value": "Attack/Ranged/Damage/Hack", "multiply": 0.5 }, { "value": "Attack/Ranged/Damage/Pierce", "multiply": 0.5 }, { "value": "Attack/Ranged/Damage/Crush", "multiply": 0.5 } ] } Adjust multiplier as you see fit.

Assuming healers have large vision range would this not mean making healing ranged units rather tricky?

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.

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.