guerringuerrin

Now do it for every building with aura and PR

Yes, only for civilians.

Is intended for hide civilians. If you remove them from storehouses you might not be able to garrison your civilians chopping woods. I think the current behavior is good Yeah and is nice bc u those bells will garrison your choppers, keeping the farms gathering.

If you don’t know how, here are some basics to get you started.

(If you haven't already) the best thing you can do is try it and draw your own conclusions.

I don’t agree with this. There are different cases of this. Calculating the exact batch size for your available resources isn’t instantaneous to begin with and it changes over time. (besides 3–5 seconds in the heat of a battle is a long time). Also, we know the vanilla system is buggy so you end up with some barracks having long queues while others sit idle, and figuring out which one is idle takes time. Even when using auto-queue. All of that adds up. ModernGUI does this instantly everytime. No -or almost no- mistakes. Finally, there’s the issue of awareness: the human mind forgets things, and the more elements it has to keep track of, the more likely it is to make mistakes or forget to perform certain tasks and that all adds up over time.

Sure, I understand you. I also don’t think that arguing “learn to play” contributes much. For me, the key point of the discussion is how to reach a consensus—how to bring both “playstyles” closer together without pushing everything to extremes. And I’d like to elaborate a bit on this so you understand what I mean. There’s a big difference between allowing the queue to resume once resources are available and a mod that assigns batches of units sized exactly to fit each building automatically and at instant speed. Moreover, the mod in question (ModernGUI) doesn’t simply leave a preassigned production queue; as a player, you can choose the composition of your army—for example: 40% javelineers, 40% pikemen, and 20% cavalry—and the mod will produce units in batches, assigning them to the queue just 1–2 seconds before the currently produced unit finishes. This also optimizes resource usage, since you keep them available until that exact moment. Then, if you run out of resources because you used them elsewhere, as soon as you have resources again, the mod automatically resumes production. Of course, there are caveats—you can’t say it’s perfect. Additionally, the mod includes some very interesting GUI improvements that, in my opinion, would be very positive to incorporate into vanilla. In other words, for me this isn’t a black-and-white issue. It’s true that the vanilla 0 A.D. system has some fairly clear functional bugs, and there is ongoing work to improve them. If you haven’t tried the mod already, I invite you to try it yourself so you can compare it with what I’m saying. Sure—against the AI, use whatever mod you like. Personally, I find it frustrating to lose a match to someone and then realize they were using this mod. There’s also been a lot of discussion about transparency—whether people should disclose when they’re using it. And in my experience, until you watch a replay and notice it yourself, players usually don’t tell you. It’s true that many people aren’t deliberately hiding it. In my experience, most players who use the mod don’t feel like they’re cheating; they just enjoy the game more that way. Some at least acknowledge that it helps them play better; others argue they would play just as well and that they simply find it boring otherwise—something I personally find very hard to believe, since the advantages of this training system seem quite obvious to me. That said, it’s natural that someone who doesn’t use that mod and plays against someone who does might feel it’s unfair. It’s humanly impossible for a player not using the mod to perform all the tasks that someone using it can, especially in battle scenarios where, while one player has to manage unit production, the other can keep clicking in combat while the barracks are practically producing on their own—as long as you have houses and resources, it will keep going. In other words, one player can focus on microing units in battle, while the other also has to deal with barracks micromanagement. And you might say these are just different schools of play, different preferences. Fair enough—but in multiplayer, when you’re facing another human who has these advantages, it’s natural that someone might feel frustrated or that it isn’t fair. This thread mixes many different issues. That’s why I asked whether you really knew what kind of automation was being discussed, and to what extent that automation goes. It’s not a minor debate. And even if the multiplayer community is a minority, let me say that it’s a very active one, and many people who actively contribute to the game’s development are part of it. Moreover, I think the multiplayer aspect should not be minimized at all—considering that this is an RTS, it’s only natural that it carries a certain weight. Sorry for the length of my response. I’m terrible at summarizing my ideas. At the same time, it felt more practical to just dump this whole rant at once rather than go little by little, haha.

I’m not sure whether you’re aware of what kind of automation is actually being discussed. I agree that you can’t really say one thing is better than another, or that one approach is “how it should be” and the other isn’t. In the end, it comes down to consensus about what a community wants or accepts as valid and what it doesn’t. The case of AoE2 is quite illustrative: a feature like 0 A.D.’s vanilla auto-queue is considered cheating in the multiplayer scene. Is that right or wrong? That’s not really the point. The real question is whether there is a broad consensus around one gameplay mechanic or another. The issue is that, when playing against a human opponent, the sense of fair play matters. Whether certain features are accepted or not is part of an ongoing discussion and a necessary consensus in any community. This debate has been going on for years and has been approached in different ways. Some have led to a good, inclusive understanding despite disagreements. In other cases, things like this happen, where someone shows up out of nowhere and starts treating everyone like id**ts, and nothing productive can come out of that.

Yes, I think this behavior is quite appropriate. And I don’t think it’s worth over-optimizing this behavior. If there are no nearby buildings to garrison in, having units stay idle where they are seems like the most appropriate outcome. Players should be responsible for ensuring there are enough nearby buildings for units to take shelter. Otherwise, keeping them idle is actually helpful, since it makes it easier to quickly select them using the idle hotkey. Short video of this. I don’t see any civilians switching resources after the bell. Not even those who garrison in buildings with rally points set to other resources. ringbell.mp4

I’ve noticed that when there are no buildings available for garrison, civilians just stay idle where they are. However, I haven’t verified whether this happens because there are no buildings close enough for them to detect, or because there are no available buildings at all. What I’m fairly sure about is that units do not switch to gathering a different resource. In other words, if they were farming, they will try to resume farming rather than moving to gather wood.

I never seen this before. It might be worth to test it

Forbidden thread!! I’d love to see what’s inside Wasn’t there rot in A23? I think I remember seeing it in some earlier version. I imagine the balance team must have some explanation. Same for the capturing siege feature From my POV, it would make sense to reintroduce rotting

Nah, they kinda suck atm. Except for some champion ones.

Well, no. A javelin throws javelins; a shortbow unit uses a bow and arrows. And my guess is a Javelineer would be slower than a shortbow archer bc higher carry weight?? Answering to both of you here: Nah I didn't even check this. I was just following the logic of what Thalatta said here: But probably misunderstood the logic and he was talking about the arrow deal more/less damage depending target distance... To be honest, I’m not very interested in realism or historical accuracy, and I don’t know much about it so I leave that to those who do. I’m more interested in gameplay. And I’d be willing to sacrifice historical accuracy to prioritize gameplay, variety, and so on. But I’m not trying to argue anything (just to be clear). In general, archers feel quite weak in the latest alphas and also lack variety, with the exception of some champion archers. So I guess my "proposal" would be that A shortbow could have higher dexterity and a faster attack speed (with less damage, based on what I now understand), while a longbow could be slower but have greater range and deal more damage.

One thing 0 A.D. lacks is a diversity of archer types. I think the current ones resemble longbowmen more, but there are no shortbow units. I like the idea of a short-range ranged unit with higher damage than a longbow. Perhaps, in melee, it could fight with a short sword or dagger. I’m not sure how complex its implementation would be. I think it would make sense not to allow tight formations for slingers if we want to add a touch of realism, but limiting slingers to direct line of sight would make them quite useless. Beyond 0 A.D.’s realistic orientation, let’s not forget this is an RTS, not a combat simulator.

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/

@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

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.

https://gitea.wildfiregames.com/0ad/0ad/wiki/Modding_Guide And also you have the full 0ad Wiki here: https://gitea.wildfiregames.com/0ad/0ad/wiki

There is a "put order in front" command you can use for this. Select your farmers, select the house to build with hotkeys or clicking on the GUI, then hold your "order in front" modifier key while you place the building. The civilians will build the house and as soon as they finish, they will continue with the order they had before (farm in this case) Little trick if you have at least one farm built already. Select your 10 civilians, shift+order to build 1 farm, shift+order to farm (on the old farm you already have), then shift+order to build the 2nd farm. This way, when they finish the first farm, the 10 civilians will continue with the go farm order and only the remaining 5 civilians will go to build that 2nd farm you placed. Do you mean that the ability of citizen-soldiers to gather resources should be removed? Correct me if I misunderstood. Removing this feature seems like a bad idea to me. It’s one of the most original aspects of 0 A.D. as an RTS.

I know some people (myself included) who use it when designing their base to get a better sense of the spacing between buildings. And having the same icon repeated many times—for example on houses or storehouses, which tend to be numerous and small—could become annoying. I really like the idea! However, having the option to toggle it on and off would be ideal to accommodate both preferences.

Yes, but when the GUI scale is increased to fractional (non-integer) values, the issue still occurs due to "subpixel misalignment and texture filtering." Check this comment of #8759

Regarding blurry fonts. I've noticed the same as you and @trompetin17 is already working on this for the next release. Here are some issues and PR related to this: Issue: #8759 PR: #8793 Using the GUI at 100% shouldn’t result in blurry fonts. One idea that comes to mind is that, in the meantime, you could use a lower resolution when playing so you’re not forced to increase the GUI scale. That way, you wouldn’t have the blurry font issue.

Civilization aura joined the chat I love the idea. I would make it optional, with a toggle in the settings, so as not to force a feature that could be negative for some players or in certain contexts.

unrelated but