All Activity

i.e.

Is this work around because of some coding limitations? Naively, I would think of normal bridges (the Persian was a particular case) as a structure that behaves like the port and the wall: start on one shore, finish on another (under certain depth/lenght limits), and the construction animation doesn't have to be that accurate (none is)... maybe there's some problem about walking on top of it if done in this way?

I don’t see any relevance in this line of argument. Proto‑Indo‑European dates back to the Neolithic; its origin is probably around 4000 BC, which means it is even further removed from Proto‑Germanic than Proto‑Germanic is from our modern languages. In this situation, we’re comparing things that simply can’t be compared anymore. The purpose of this discussion is to try to understand what vocabulary speakers of Proto‑Germanic might have used to refer to their settlements. The Cimbri migrations took place around 100 BC. I don’t see the point of going back that much further. And if you want to talk about the reconstructed PIE form *ḱóymos, it did indeed yield *haimaz in Proto‑Germanic, but it also produced κώμη (kōmē) in Ancient Greek and káimas in Lithuanian, both of which can be used to refer to a village. Kōmē is precisely the form chosen to designate the first phase (village) for Greek civilizations in the game… So it’s a bit inconsistent to criticize that choice on the grounds that the older PIE form doesn’t necessarily refer to a settlement. That’s really stretching the argument, and I don’t see the point of it. In your message, you criticize me several times for relying on place names that date from a few centuries after the Cimbri period, but in the end, you are constructing an argument based on reconstructions of a language that predates Proto-Germanic by several millennia. Once again, I don’t understand the point of your message. I never said that Old Norse or Old English was older than the other. I’m simply saying that the source you used (Lehmann) suggests that the word þurpą originally referred to a farm, and that the meaning “village” appeared later. In this discussion, the only reason to use medieval Germanic languages is to understand the semantic evolution of words from Proto‑Germanic onward. The context we’re interested in is Proto‑Germanic. In Old Norse, as in Gothic, the word derived from þurpą seems to have preserved its original meaning, that of a farm or agricultural estate. This supports my initial point: the meaning of þurpą in Proto‑Germanic must have been “farm.” And there is no doubt that Old Norse preserved the meaning of “farm” or “agricultural estate.” This is very clear in the poems of the Edda, especially in Hávamál and Vafþrúðnismál. In the Danelaw and in the earliest written records from Denmark, we see that þorps refers exclusively to secondary settlements that depend on a larger primary settlement. In those cases, þorps can refer both to hamlets and to isolated farms. We see the same thing in medieval Scandinavian law codes: þorp retains the meaning of “farm” as well as “village.” There is, however, a notable case in medieval Swedish law where þorp still means specifically “farm” in Old Swedish, which seems to have preserved this original meaning even longer. The evolution of the Germanic languages clearly shows this semantic shift from “farm” to “village.” It’s an understandable shift, since it follows the same pattern as Latin villa, which eventually gave the word “village.” I have taken the time to demonstrate that studies of place names generally indicate that -Heim was used in the oldest layer of place names. Without exception, these studies show that there were several periods characterized by different dynamics in the rules governing the naming of new settlements. It is clear that the trend involving -Dorf emerged relatively late, and this precisely explains what we observe in the various Germanic languages. There was a semantic shift that accompanied the social changes that transformed Germanic societies.

merged

@ThalattaThanks for this great idea for the Persians! We had some discussions a while ago about building bridges and could not really agree on how the bridge would be supported. Now if we could define a special ponton ship that can be linked in, say, up to 5 segments, then we might be able to create a bridge. And it can be destroyed like any other ship. Question is only how we could offer this as a possible option for path finding (topic: "objects you can walk on")

That would be awesome! I've been and hope to be adding more wonders and a capture mode would make good use of them.

Thanks for all these resources!

That's cool stuff to add to my bookmarks I'm not really into modding units, but maybe this web can be useful for you too: https://docs.wildfiregames.com/templatesanalyzer/

https://docs.wildfiregames.com/entity-docs/r28/components/ @Vantha gave me this link a while ago, but no idea where I was supposed to find it.

Is there a list of the xml tags for units and structures?

@Stan`this is what the Height part of Obstruction is for, only for turreting.

I do! If you want, I’ll throw together the wonder stuff and you can take a look at it.

2 years ago i made this topic, maybe time to resurect it :

I don't find it worths a hotkey place. I just click the call to arms icon at the bottom.

@Atrik I think my repeated second quote from the second paragraph may have caused some confusion, but if I understood correctly, their response was referring to my suggestion of using “order one unit” when building a house with civilians who are already farming. Yes, it doesn’t work when using Shift. It’s only meant to prioritize a single order. If you want to queue multiple houses for construction, the best approach is still the standard method using Shift. You are right. I was wrong about this

When you queue multiple houses using the traditional method (Shift + click), units won’t go and build any pending farm foundations until they finish their previously assigned tasks. Civilians don't actually farm on fields unless building the farm was part of their order queue so I don't know what this discussion is about. They might build the unfinished field, but they won't farm it. They will look for another thing to build OR go idle.

https://gitea.wildfiregames.com/0ad/0ad/pulls/8422

Ok, I just installed this and have a few questions: -Regarding "new quotes and tips" in the game load screen, it goes away too fast for me, I can't read it. As suggested at some point, "press any key to continue" could be implemented. -I have no Scenarios under Campaigns anymore, like I had with R27. And as suggested at some point, I'd remove the redundant "Continue Campaign" option from the main menu and leave only the one under "Single-player". -I like that civilians are both men are women now, but has there been any discussion regarding gendered roles according to each civilisation? I'd like to see more female priestesses for the Greeks for example.

While developing stevenlauBot, I read a whole lot of 0AD source code. I got a closer look on the behaviour of attacks, which isn't available in user guides / manuals. Advanced players might find this useful. Dodge CC arrows with 5 cps Consider the simple case in which some enemy units are constantly running under a defensive building. The building is angry, and would shoot all arrows evenly in the first quarter of repeat time, i.e. 4s / 4 = 1s for CC. During that 1s, the arrows are shot evenly in 5 batches. As a result, to dodge under CC, you do 5 clicks per second, then you have 3s of free time. For stone tower the repeat time is shorter, so you have to click a little bit faster. In addition, the arrows are shot to the same target until it dies, so you only need to dodge one unit, which is by default the closest one. Reference: https://gitea.wildfiregames.com/0ad/0ad/src/branch/main/binaries/data/mods/public/simulation/components/BuildingAI.js#L292 Snipe a formation by enclosing them When attacking an enemy formation, you can't choose to snipe an arbitrary formation member. The member closest to your unit will always be attacked. You could theoretically surround the enemy formation with snipers, so each sniper will see different "closest member", and achieve certain extent of sniping. To attack you just have to right-click the whole formation and the closest member will be chosen automatically. Reference: https://gitea.wildfiregames.com/0ad/0ad/src/branch/main/binaries/data/mods/public/simulation/components/UnitAI.js#L5407 Shoot farther on turret or mountain Suppose the maximum attack range of a unit (CC, archer, jav etc) is said to be 60m. The actual maximum distance is different when the unit is on mountain or turret. It is calculated using the formula: actual_max_distance = sqrt(max_distance^2 + height * max_distance * 2). While this formula produces plausible numbers, I don't think it is physically realistic. It is parabolic but it doesn't represent an actual projectile curve. Anyway, what it means is, if you stand higher, you shoot farther (with larger spread though; and spread considers horizontal distance only). If you stand so low, like 30m below enemy, then you can't shoot them at all. The max height (30m) is half the max distance (60m), which is arbitrarily fixed by the 0AD team. All units and buildings are considered equally on ground level (0m) except that outpost is 8m, sentry tower 9m, stone tower 15m, and Han great tower 20m. So stone tower actually shoots as far as sqrt(60^2 + 15 * 60 * 2) = 73.48m. An archer turreted on wall (roughly 10m tall, different with civs) will shoot at sqrt(60^2 + 10 * 60 * 2) = 69.28m. What about fortress? Although we see fortress shoots arrows at a height, it is still considered to be on ground level (0m), so the max distance is still 60m. This might have to be fixed. Reference: https://gitea.wildfiregames.com/0ad/0ad/src/branch/main/source/simulation2/components/CCmpRangeManager.cpp#L1387

Yes, it doesn’t work when using Shift. It’s only meant to prioritize a single order. If you want to queue multiple houses for construction, the best approach is still the standard method using Shift. You can use this command in multiple ways. For example, if you only need a small amount of food, stone or metal, you can use “Order one unit” so they deposit the resources and then immediately continue farming/mining. It doesn’t work quite as well with wood, since they might end up chopping a tree that’s far away from the dropsite. It’s also useful if you have a production queue and want to prioritize a specific unit or technology. When you queue multiple houses using the traditional method (Shift + click), units won’t go and build any pending farm foundations until they finish their previously assigned tasks. On the other hand, queueing the construction of many houses using Shift + click is not very efficient from a resource utilization standpoint. That said, there are situations where it doesn’t hurt of course, especially if you have plenty of spare wood. IMHO the situation where a farm is left unbuilt and civilians go back to it after finishing all assigned houses/buildings is quite an edge case and easy to handle with a bit of practice. So I wouldn’t treat farms differently from other buildings in this regard. The trick is that this old farm is already occupied. So, the units that just finished building the first farm will try to go and gather there, but since it’s already taken, they’ll get reassigned to the new farm instead. Meanwhile, the remaining five, seeing that all farms are occupied, will move on to build the next one. This way, you avoid having all 10 civilians build both farms before starting to gather. You shouldn’t send them to gather from a distant occupied farm, but rather to the closest one relative to where they’re building to avoid them to walk a long distance for nothing. It works quite well for me. Give it a try. Btw, I’m not saying this to defend the current behavior. It's just a small tip that might help you in the meantime. Ah, got it. I don’t have an opinion on it. It would be a significant change to the game’s dynamics tho. It might work well. I’m not sure. I do know there are some approaches in this direction in the @Emacz mod with the Serf units. Sorry for the long reply.

Honestly, I strongly believe the ModernGUI mod should have its compatibility check permanently enabled, with no option to disable it. This isn’t because of the GUI itself, but due to the autotrainer. There are multiple players exploiting this and receiving credits they haven’t legitimately earned. Same that Delenta Est, Aristeia, even Feldman I think must apply to this mod too. I am not interested in games with this setup. Gray letters to the ones that uses autotrainer pls! So others can make informed decisions.

No, not really, I've mostly just messed around. I did make this though: https://jeff-web-sketch.github.io/minecraftmods/index.html

I have found that the "order in front" behaves weirdly. Iirc in conjunction with SHIFT queuing it makes workers ignore all queued task and go back to their current tasks. Very annoying to get housed and when going back to your base seeing that your Civilians are back to farming instead of building the other houses. But wouldn't that cause the workers to go to the old Field first before continuing with their queued tasks? It's referring to the suggestions that "storehouse and farmstead technologies apply only to civilians". That would make Civilians almost from the start of the game better gatherers than Citizen Soldiers, making training them pointless as they slow down your economy. That would lead to either a super defense play where you train only as few military units as you need to survive until you get close to max pop, or play super aggressive and go for an all-in.

These could be considered: -Artemisia I for Persians (or Carians, if part of the game at some point): naval commander. The one from the battles of Artemisium and Salamis. -Artemisia II for Persians (or Carians): naval strategist and medical researcher. Sister/wife of Mausolus, ordered the construction of his tomb: the Mausoleum at Halicarnassus. -Lǚ Mǔ for Han: rebel leader that played a role in the restoration of the Han dynasty. -Teuta for Illyrians: not a playable faction still (eventually?), but since Gaia's units being more challenging has been mentioned, they could even have Heroes, and Teuta would be compatible with Gaia's piracy units (although I'd name them differently than Gaia, and reserve that for basically abandoned things).

Probably not, but I think better not to drift towards the unrealistic direction. The big ships are one of the things I liked about the game the first time (and many have commented the same). I think it would be the wrong call to make things look more and more like any other RTS. I hope this is done at some point, would also solve the issue of strategising against ships with modified stats because of the troops being carried. Maybe. Personally I prefer battles that look closer to the Shogun 2 Total War ones, not so much on the side of numbers, but tactics. Although numbers is also good. On a side note, maybe different water depths could be considered, differentiated by color, which would be important the more relevant the bodies of water become: -Shallow: for the transit of most land units (except siege for example) and small boats. -Moderate: for small and normal boats, but not the largest ones. -Deep: for all boats. Maybe eventual bridges should not be built over it (except for the Persians, who could have also bridges made of ships).