hyperion

A hopefully simple example: Little Alice and little Bob are playing ball on top of Eiffel Tower. When passing the ball to Bob he fails to catch it and Alice shot falls all the way to the ground. Grown Robert picks up the ball, and has he is a grown up he has further range and is able to throw the ball all the way back to where Alice is if she where on the ground. Is Robert able to pass the ball back to Alice?

Well, they wouldn't be just circles anymore. There was a patch for a more accurate range indicator at some point, don't ask me what became of it. Because it wouldn't be correct in the general case as was pointed out, whether this is of concern we can argue about. Just because some people don't understand the relation between elevation and range isn't a sufficient reason in my eyes to throw away what we have tho.

Pretty sure wow didn't mean to just touch the mod.io browser and leave the more problematic mod-selector as is. As for the problem raised of figuring out what exists such a browser will be a sub-optimal choice anyway, it won't ever have more info than https://www.moddb.com/games/0-ad/mods and only covers a minor part of the mods available.

An image can be packaged into the mod as well, no need to fetch it from somewhere else. If the mod is signed so is a bundled image. This covers the mod selector. So this leaves what to do about a mod.io browser, relying on mod.io having the necessary tools and report mechanisms sounds good enough for now.

Right click, open with ... 0ad -> done installing

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