All Activity

Ah, forgot to mention it: to emulate local trade, Markets could also give a trickle. I think this could be an alternative to "limiting the number of Traders considering total enabled route length" to justify their expansion (garrison/ungarrison cooldown could still fix the other things). Best is, with simple rules, to generate something interesting, obviously.

Thanks, I’d really like to see improvements to flying objects, especially those that fly at high speeds.

Yes, but the point was that there are worse problems with trading routes to begin with, which could be solved by limiting Traders per route, and if one wants to make them go to other Markets, that would be harder to analyse. I tried to do it already anyway, for example I thought one could have many Markets, and to reduce micro, the Market screen could show a map with all possible routes, and one would enable or disable them (if some went through enemy territory), Traders taking any enabled route from any Market equiprobably (all to reduce micro, I wouldn't like having to click for every Trader every Market, sometimes more than once if they get disrupted, like this just one click would put them on the allowed network). Still, limit on number of Traders and gains with route length have to be such to have what I think is the ideal algorithm: Markets homogeneously covering the available area, the more Markets the better, but up to certain limit, in my case related to the total amount of Traders one is willing to have. This last bit is hard to get a grasp on if Traders travel to many Markets, that's why just bouncing between two Markets was more than an acceptable simplification to understand the maths, all things considered. Not that it's impossible, but working algorithms are the important bit, after deciding what characteristics for sure people want to be present. To try a working algorithm with random walk, Trader profits could be independent of route length, and Markets have a minimum separation (because of lack of diversity in products and clients), this way they would homogeneously cover the map in hexagonal patterns. Since I don't like hard limits (that's why my Suggestion 56, "Separation criteria", proposes a more flexible approach to Fortress and Tower minimum separation), another possibility could be that the Trader profit has a maximum at the Market separation wanted (long routes have more risks and logistical costs, reducing profits). This would also cover the map in hexagonal patterns (if possible, profits could be indicated when placing the Market, same as height bonus is indicated for the relevant structures). Limiting the number of Traders considering total enabled route length (keeping their average "density" constant, and to disable routes one might need to get rid of some Traders first) would still be needed to justify expansion (on top of all this a trading garrison/ungarrison cooldown could spread Traders better and remove any teleportation exploit in general). No, and even if you could, it would be way less profitable than making it oscillate between the two furthest points, which is the reason of my post

Hopefully you will even be able to get proper interpolations for flying units next release. https://gitea.wildfiregames.com/0ad/0ad/pulls/9253 I even started this PR when I saw your helicopter video

The pont point here is can I send a trader (automatically/repetitively) from trading post 1 to post2, then to post3, then to a harbor and then back to 1 or the same route reverse?

For selection of exisitng objects: CTRL-drag for an area, CTRL-click to add/remove from selection). The you would need to click on "Selected items" then the list should show. Would you prefer this list automatically showing up? (hiding was meant to declutter a bit) show up. Filling an area: select one item left click on the map an drag, left click for each corner of the polygon, double click to finish. There should be yellow dots inside shoiwng the filled objects (in the image below I did not do the final double click yet). Now I did and it shows as still selected on the selection list allowing for additional edits : Now did: For a mixed fill, select an entity, push "add chosen" select another one, click "add chosen", etc. and choose the fill ratio. Then continue defining the area as above. Voilà:

As an influential factor in modern warfare, the kamikaze drone force has become operational; however, I do not yet have an official launch vehicle for them. Recording 2026-10-06 004224.mp4

I’d agree with you, if the maps were large enough to encompass multiple regions (such as if there was a “Greece” or “Central Europe” map). However, based off of the size of the maps, it’s not much different than the trader walking from one town to another in a localized region.

lol, this video makes you realize what a vast improvement this is

Merchants would mostly keep to certain regions. Hardly anyone in the Mediterranean tried to travel to the source of tin for example. I think it's fine that a given Trader bounces between two Markets (representative of a region, not two literal markets, of course they went around a few). I think a problem is that the game makes the most profitable trading route the only one worth having, making things quite dull. To solve this, I think traders per route need to be limited (have slots like resources, varying with distance), and the gain be such that multiple Markets at both ends is not the most profitable configuration (that's why a per Market limit instead would be easily exploitable). Looking at the code, the trade gain goes with distance squared, with a damping for long distances (dividing by 1.25 at map diameter, I think). Ignoring the damping for now, the question would be: given a bunch of Markets with all routes full, where should a new Market be placed for maximum profit? I'll assume Trader slots will vary linearly with route length, to account for time needed to travel them (fixing Traders arriving to Markets per unit time). This problem is then a generalised Leibniz geometrical theorem (https://arxiv.org/pdf/0710.0342), since one wants to add up the square of the distances to all Markets. The solution is that profit is greatest the farthest away from the centroid of all original Markets (I don't think damping changes this result much, and not in an obvious way anyway). This is not nice, since Markets would need to be in a periphery, as expanded as possible (a circle empty inside would be ideal for a given centroid distance, obviously), instead of forming a more interesting network. I don't have a proposal for now, but I think this issue is worth exploring to reach a solution that is simple, intuitive, interesting and not exploitable.

Indeed, a lower threshold would be like trampling, a higher one charging/ramming. That's quite nice and flexible!

The damage is scaled with relative speed. And it has a threshold* you can set in the template (could be 0 too). It's called charge in the code but trampling could be somewhat descriptive too since it's any collision that would trigger the effects. *the threshold is only checking the charger own speed, so 0 for elephants makes the unit coming into contact to also count as hit. So it is somewhat a bit trampling.

So, like centurions for boats? I'll consider this for my boats mod

It is shift-drag for me The grayed selection area is showing for my mouse, but nothing is showing in the list

I agree with all that @guerringuerrin said. Those tests look really good, and in such tight spaces. @Atrik, since I guess now with inertia units need to accelerate, is heavy cavalry dealing "charge" damage only when at max speed? (I'm not sure if this is what's called "trampling", which wouldn't be the same thing in reality). Because I guess that would be nice, one would need to repeatedly move out and smash for that to be more effective, similarly to how it should really work for ramming ships, although elephants I guess could charge out when mobbed.

Select: Ctrl-left mouse drag on Win11, on MacOS possibly Opt-drag. Fill area: select an entity or a mix and left-click to draw the area.

How do I test it?

If we give them "charge" but with 0 damage it's indeed what that would be. They'll be pushing immobile units a bit better, like current cav and archer elephants. But they cannot push a entire crowd (They would need to be 'solids' for this).

Thank you so much @guerringuerrin for the deep testing and helping and pushing me for the elephant deadlocks issue!! Together with the balancing of states, I also think we got it to somewhere where they became very nice to play with. What mainly changed in the last commit is that when two elephants push each other, the one that would push the other into wall yield, and let the other one push him. A few other small tweaks for when there are in large group pushing each other too should make deadlocks temporary there too.

The strategic missile force has become operational. Recording 2026-10-04 233221.mp4

Perhaps use for short range anti building attack like in Age of Empires 3 At least for regular buildings. For walls and forts undermining with reused villager pickaxe animation might be more accurate (palisades, gates and wooden forts get axe instead). That is if weapon switching is implemented ofc.

New test on this last commit ee1083529d: The commit before this one had identified that elephant deadlock when trying to pass through narrow passages. Two elephants try to pass through the passage at the same time. They have the same strength and resistance, and neither of them stops pushing: With the latest commit, this no longer happens. They can still take a while to get through sometimes, but they eventually manage to pass. Overall, I think the resolution of these deadlocks has improved significantly: Here I’m sharing the basic test I’ve been repeating with 24 elephants going through a base with narrow paths with micro: And here I’m sharing some other tests simulating a more or less standard army: This first video shows how the infantry units are able to advance without being significantly blocked by the elephants. The positioning of the elephants at the front is intentional. You can see how they block the entrances, yet the infantry is still able to push through them without major issues. Here, you can first see me repositioning my army to achieve an optimal formation. The infantry units flow smoothly through the moving elephants without any issues. Secondly, we can see that I send the army to the other side and move an elephant that was about to block others coming toward the passage from another angle, allowing them to get through quickly. Toward the end of the video, you can see me stop the last elephant moving along the upper line to help the infantry get through quickly. This is an interesting situation: even though the infantry units are faster than the elephant, they still aren’t fast enough to simply move around it, so the elephant ends up blocking their path. The solution is simply to stop the elephant for a few seconds. Another example of the infantry advancing smoothly, even when the elephants get heavily stuck at the various entrances: My overall impression of this latest commit is very positive. The elephants feel heavy to control but still reasonably fluid. I like that they feel heavy. They’re huge and heavy units. (I’d love to see them charging in side by side, swinging their tusks around and sending soldiers flying through the air. A charge-like ability with a cooldown would probably be OP, though. Sorry for the digression. ) Although less frequently, some of them will still get stuck in narrow passages. However, with a bit of practice, it’s easy to identify which ones need to be moved to clear the elephant jam. And honestly, I think it’s fine that this happens. They are large, heavy units that can easily knock down a building. I think it could even be an exploit to have a unit that can quickly flow through narrow paths while pushing enemy units ( while trampling them ) and reach its destination with a single click. It feels like a pretty reasonable drawback: You want to mass elephants and reach the enemy CC? Do a little micro. In fact, the most natural (and fastest) thing to do would be to destroy a few houses and make your way through. The infantry would probably capture some of the barracks, opening up even more space. As for the movement of mixed armies, it really feels and looks great. I forgot to include a video with cavalry, so I’m not sure if there’s one with the latest adjustments. It’s very, very good. I don’t think the elephant jamming is enough of a reason to block this PR. The improvements this work brings are clearly more valuable. In vanilla, we can see greater fluidity due to the overlapping. But the result is not only unrealistic, it also looks ugly. It’s like a snake of fast-moving pachyderms, so light and nimble that a single infantryman can stop them. In this video, I forgot about the enemy’s initial army, so they rushed in to attack the elephants, who ended up getting completely stuck against just four infantry units. So, ultimately, I think this is a gameplay decision. From a technical standpoint, I think the issues are already pretty well addressed. Perhaps the only thing still missing is some fine-tuning for ships. And it would be great to test some actual games over the next few days. We can coordinate and play a few 1v1s, and hopefully we can get some 2v2 games in as well. @AtrikI think I would add the pushing property to the worker elephant, but not the trampling property. A picture:

Officer functions - Helmsman: increases the ship's rotation speed and maneuverability. - Chief of Oarsmen: increases the ship's movement speed. On ships capable of ramming, it also improves ramming damage. - Marine Officer: increases the ship's boarding and capture power. - Commander: determines the ship's command rank and defensive capture capacity, defining its capture points. The officers would not simply provide generic bonuses. Their importance would depend on the ship's role. For example, the Chief of Oarsmen would be particularly important on a Ram Ship, while the Commander would be more important for a heavily defended warship. The Marine Officer could work together with the soldiers garrisoned aboard the ship to determine its ability to capture enemy ships. This would make naval combat more than a simple exchange of hit points. A ship could lose specific capabilities as its officers are killed or incapacitated: - Losing the Helmsman reduces rotation speed. - Losing the Chief of Oarsmen reduces movement speed and ramming effectiveness. - Losing the Marine Officer reduces boarding power. - Losing the Commander reduces the ship's defensive capture capacity. The ship class would determine which special abilities it can use. For example, only ships designed for ramming would deal ramming damage, while a Fire Ship would specialize in incendiary attacks rather than ramming.

Selecting didn't seem to work, neither the making a shape. Maybe I just don't understand how they work