Leaderboard

Just a short guide to improve your network setings. Disable IPv6. (Its famous for a lot of trouble in online gaming) Go to Advanced tab of your Ethernet adapter settings, and disable the following: Interrupt Moderation - clumps packets together and sends them as a batch - the main offender Flow Control - sounds counterintuitive to disable it, but it messes with existing flow control in Windows networking stack Receive Side Scaling - also messes with Windows networking stack [anything goes here] Checksum Offload - supposed to speed up performance by offloading TCP/UDP checksumming to hardware; in reality does nothing for an average desktop PC except interfere with Windows networking stack UDP Is more important, because 0AD is using the UPD protocoll! Thats what u can do on your Desktop ----------------------------- If you want to go more forward, you can optimize your Routers config too. Search in the config for something like QoS, Filters, Portforwarding etc. In most routers, you can prioritize network traffic. Just watch out and give realtime priority to the UDP protocoll and bind it to the 0ad port 20595. ----------------------------- Want more? If your PC have a lot of RAM you are lucky. Try to set up a RAM-Drive and put a Copy of your 0ad into it and run it from there

@LordGood, I think it's a bit strange the colonnade is player-owned and attackable. When a unitAI sees this, it will start attacking the colonnades, which is a bit stupid. IMO, it would serve better as a stone resource, or some unattackable, unselectable obstruction. What do you think?

I want to talk about some problems with pathfinding for large armies and proposed solutions. I would implement these solutions and submit a patch. If you have a big group of units gathered together with no formation, and select them and click for them to move somewhere across the map (or even relatively nearby), two things happen. The units in front start moving immediately, but it takes a long time before the entire group is moving. The group narrows into a single-file column as each unit tries to follow exactly along the planned long-range path. Neither of these things is what the player wants. The army would get to the destination faster if every unit started moving immediately, and it would be more effective once the fighting starts if it stayed together as a clump. The more spread out the army is, the more vulnerable it is. I want to pause here and say that I don't intend to do anything with formations. These changes can be accomplished through individual unit pathfinding alone. I want to compare this to other RTS games such as Starcraft II. In Starcraft II, if you have a clump of units and tell them to move, the entire clump instantly start moving, and stays together as a clump. You can see examples of Starcraft II pathfinding here: https://www.youtube.com/watch?v=x0gSVKVZ4YU. Throughout the video, notice how units stay in tight groups, even as they move around and change direction a lot. If they split up, that's generally because the player manually split them up by telling part of the group to go one way and another part to go another way. Starcraft II has no formations. So how can 0ad work like this? I plan on the following changes. For reference, this is the current pathfinder doc: http://trac.wildfiregames.com/browser/ps/trunk/docs/pathfinder.pdf Add additional information to units giving their expected direction. This is a vector saying where and how fast the unit is probably going to move in the next turn. It doesn't have to be perfect. If you give a unit a walk order, its expected direction would be immediately set to be parallel to the long-range path to the destination. Otherwise, a unit's expected direction would be set to the direction it moved in the previous turn. This information would only be updated once per turn. For the purpose of short-range pathfinding, units ignore units whose expected direction would move away from them fast enough that there is no expected collision during the next turn. This should solve the issue where it takes a long time for a group to get moving because of units treating units in front of them as obstructions. As a side benefit, this would improve performance because the short-range pathfinder would have fewer edges to consider!! After short-range paths have been selected for units, units with short-range paths that are nearly parallel to allied units adjacent to them, should have their paths adjusted to be exactly parallel. This would prevent units from converging into a single-file column over long distances, by keeping a group moving in a parallel direction. A unit is considered to have passed a waypoint (but not a final destination) if the closest point on the long-range path is at or beyond the waypoint. This is necessary in combination with change 3, to keep units from insisting on stepping directly on every waypoint even when other allies who were going in the same direction are in the way. edit: After further examination, I see there's another major reason for why groups of units take a long time to fully start moving. Units ask for a new short term path as soon as they encounter an obstacle, even if the obstacle is moving. Asking for a short term path causes the unit to stop for a bit. You can see this by ordering a cluster of stationary units to move with the speed set to Turtle (0.1x). You can see units freeze in place for a second, waiting for a path, before starting to move in a direction perpendicular to where they were ordered. To fix this, units should keep trying to move for a short period of time if they were obstructed by a moving unit, and only ask for a new path if this doesn't work. This would be in addition to the other changes. As it would result in fewer calls to the pathfinder, this would also improve performance. staticsliding.diff

Currently only the c++ part has its documentation generated. Since there are some JSDOC comments on the Js part of the code as well I thought it would be nice to generate it as well. I therefore separated the js code (AI, GUI, RMGEN, Components, Globals, Helpers,...) from the public folder of A20 to generate the documentation. Documentation was generated with JSDOC 3 using the node.js plugin Since classes don't have the proper @class tag for now I added in attack.js so you can see what it can look like. Here are the Documentation files (Open Index.html) : out.7z And here are the files I used for the generation : 0adtest.7z During the execution I got the following warnings : The unexpected identifiers ones are deprecated foreach (@elexis if you want to nuke those) and there are some errors with comments.

Ofc that's possible. There are other entities that have simulation-like behaviour, but aren't selectable. Like the bird models, the territory_block and territory_pull, and more useful for you: the bridge sides have an obstruction but aren't selectable.

Because operations don't work. F.e. take multiplication. Take (as a small example, I won't write out 32 bits) it's stored in 8 bits, of which 1 bit is for the sign 4 are for the integer value, and 3 for the decimal places. Then 1 is represented as 1000 in binary, so 1*1 integer multiplication is 1000000 = 16. Doesn't really work out eh? The functions made available in CFixed make sure the numbers get shifted to one side or the other so these operations do make sense (and take into account unexpected overflows). It's just easier when you can do a*b with fixed numbers, and let it give the correct result. Instead of calling some method mult() defined in an obscure place.

I'd think if an enemy razes a town and all that's left is the colonnades that would seem stupid as well, and if its a stone resource stone miners will automatically move to dismantling them after their mines run out... I figure they'd work similarly to fence entities

oh whoops, forgot I wasnt following this topic lol. Gates are animated yes, and the colonnade is a prop entity in SVN now.

Here you go templates actors everything (The first guy who says I'm not nice enough gets punched :P) You just have to copy paste the public folder. Don't forget to delete the remaining tavern actors, and, If you can, edit the celt struct so that the cardigan cloth is player color. (Don't have any DDS editor that doesn't screw up everything) Gaul_Tavern.zip No advanced graphics tho.

Visiting the sacked coastal city