guerringuerrin

You are right. Comparing mechanics from other RTS games to discuss a mechanic in an RTS game makes absolutely no sense…

Perhaps you should ask yourself why thousands of people are still playing Age of Empires II or StarCraft II in the international competitive scene and haven’t left despite having to make thousands of clicks. Anyway, I see you’re a clever guy who came here to explain to all of us how stupid we are, appealing to analogies and “smart” comments, while you can’t even beat Petra Bot, which must be one of the dumbest RTS AIs out there.

I think car analogies don’t work very well for discussing RTS design. But even if we were to accept it as a valid comparison rather than a false analogy, I’ll explain why I still think it doesn’t hold: The Model T today is mostly a collector’s item and is no longer part of the modern car's market. By contrast, StarCraft: Brood War still has active professional tournaments, specially in South Korea. And the same unit-training mechanics are still present in modern competitive RTS titles like StarCraft II and the Age of Empires series, which continue to run esports tournaments with significant prize pools. So this isn’t just a case of defending an obsolete design. These mechanics are still part of the competitive RTS ecosystem today. However, I’m still not entirely sure what we are actually discussing here: whether the goal is simply to add an option so that the vanilla auto-queue pauses until enough resources are available, or whether the intention is to introduce a highly automated system like the smart training from the ModernGUI mod. In that system, production not only resumes automatically when resources become available, but the game also determines the batch sizes based on the available resources and distributes the training across all eligible buildings through the training panel provided by the mod. Because those are two very different things.

That paragraph you quote refers to something slightly different: it describes how units are assigned when the player orders training using a selected group of barracks. Even when resources are available and auto-queue is enabled, this behavior occurs in the same way if the available resources are not sufficient. As for whether barracks should remain with auto-queue enabled or not, I addressed that earlier above: Now, I think you are referring to something beyond simply keeping auto-queue enabled, and you are advocating for a fully automated training system. That is highly debatable from a game design perspective and can hardly be considered “a bug.” There are plenty of successful RTS games that do not automate this aspect.

This is already solved here: https://gitea.wildfiregames.com/0ad/0ad/pulls/7806 and will be available in R29

Hi, @seregadushka I agree that the vanilla training system has some issues, and even some behaviors that may feel like bugs, although perhaps for somewhat different reasons than the ones you mentioned. In many RTS games (including some very famous, successful ones that are still widely played today) it is normal for the player to pay attention to unit production. In fact, many of those games do not even have an auto-queue feature like the one that exists in 0 A.D. As for whether the auto-queue should automatically resume once resources become available again, I think that falls more into the area of design decisions. Personally, I find it difficult to consider the current behavior a bug. However, I could imagine having an option in the settings that allows the auto-queue to remain active and automatically resume production once the required resources are available again. What I do consider a real issue in the current system is the way units are assigned to production buildings. At the moment, when you order units from a group of barracks, the system does not prioritize barracks that are idle or less occupied. As a result, it is quite common for new units to be added to barracks that already have long queues, while others remain completely unused. This often leads to unnecessarily long production queues and an inefficient distribution of unit training. And you end up going through your barracks one by one, trying to find which one ended up with a huge production queue and which ones were left idle. In fact, there is currently a PR in progress in the repository that aims to address exactly this problem. The idea is to prioritize the least occupied barracks when assigning newly trained units. I hope to finish it in time for it to be included in the next version of the game. You don't have to rely only on the mouse. You can use control groups to select all your barracks with a single key, and you can also use the keyboard to choose which units to produce and even the batch size. So it is perfectly possible to manage production using only your left hand.

I'm not at home for the weekend (father in law 70s birthday ) Let's do another testrun during the week

are we still talking about batches here?

I'd love to add this to the training system improvements

I'm not particularly against of him to comeback but I don't think supremacist claims like saying black people, latins, women, muslims are inferior humans is "game psychology". It's also true that gaming environment is super toxic speccialy in strategic teamplay game. So maybe is not a big deal for some ppl. Also, as far as I know he actually could join the lobby and play. But I guess he is not that smart after all... (But in fact I think he is roaming around using automute mod.) Also this:

Yes, the vanilla training system has many limitations that, in my opinion, are a form of malfunction. I think that frustration can lead users to look for alternatives. In fact, I’ve been working on a mod that always prioritizes empty barracks, and my goal is to have it implemented in the next release (PR #8483). While respecting the “no automation principle”, I believe removing unnecessary limitations is something positive.

I guess that’s a bit like life, right? A person can be many things at the same time. It’s also true that we are a very small community, so frictions naturally arise. Also, I don’t support encouraging hatred. And I think @Atrik has contributed many positive things, even if there are some aspects I don’t like. Personally, I consider the automation features in ModernGUI’s training system a clear advantage, and we have discussed this publicly many times. Aside from that, all the GUI aspects of the mod are really great. The configuration wizard is excellent. In my view, a game that allows you to configure the GUI the way you like—the more freedom it gives you, the better the user experience. Of course, there can be some nuance regarding how far certain visualizations might also be considered an advantage, although I see that as a relatively minor issue.

Right now you can accomplished the same by using the "Order one unit" command (alt by default I think) . You can grab a bunch of units and, by holding the modifier key assigned for this command, send one by one to each farm. like alt+left click 3 times on every farm. I think a feature similar like this #8525 would also be useful for gathering. It would help with chopping wood as well, since targeting certain trees can be a pain and workers often end up crowding on one side of the woodline.

Thats expectable. You are keep capturing the building with 3 strong units. So every point they decay you are recapturing. Your friend could have do the same. In fact, he did with some but I they were common pikemen, so not enough to keep control up. So it’s not a bug or an exploit. He would have kept the buildings if he had used champions. EDIT: @dinuruian i updated the video, it was bad cropped 20260310-1207-35.7648851.mp4

20260310-1153-51.1347075.mp4 Take a look at this Its just 3 units but they are Champs pikemen. They have 5 capture points (double of common pikemen)

@dinuruian I just watched the replay. When you captured the barracks, some of your pikemen kept capturing the building, while your friend didnt do the same when recaptured. Thats why you kept the control of the building and he didnt

And you say you were playing as Athens, right? If the territory gained from the building you captured ends up touching your own territory, then it’s expected that it won’t decay (even without garrison). But if the building remained isolated (not connected to your territory) and it was ungarrisoned, then that would indeed be a bug. Do you have the replay? It would be good if you could share it so we can check what happened. If you don’t know where to find it, you can go to the replays window, identify the match, and at the bottom you’ll see a text box showing the exact file path.

I don't understand very well your first message, @dinuruian. What is actually the exploit? Could you please rephrase?

You can use the README.md file on your repository to do all this kind of stuff

lets do it this week

I've just installed using .pyromod and is working good so far. But I have a serious question....

Create a Markdown file called README.md in the root folder of your local repository. Write there anything you want. It can be an introduction of the mod, instructions to install it or anything else: Here you have a guide to use special character to give it some nice looking format: https://www.markdownguide.org/basic-syntax/ Then commit and push your changes to your remote repository If you use the command line git you can: git add README.md git commit -m "Add README" git push I was about to explain how to make a Release but @Grapjas just did it here:

Congratulations, @wowgetoffyourcellphone! Eles are happy @Arup, look! Couldn't you use a Git repository? That way you could even receive contributions.

I though you meant files could be different not only path. If not I misunderstood and that would explain why we keep discussing this matter. My initial point was that this seems like a solution tailored to modders who do not meet this basic condition: And judging by that response, I think I might be a bit right, .

My reply was only meant as an example in response to your question. I didn’t mean to imply that the goals of a mod like this could lead to cheating. Perhaps it was a poor example. I only wanted to suggest that this kind of change could potentially introduce compatibility issues. But as I clarified immediately after, I don’t have the knowledge to categorically say whether it would or wouldn’t prevent that. Rather, my impression was that this change seems designed mainly to spare modders from a small inconvenience that, in my opinion, they should probably handle themselves. Afterall they should kinda know what they are doing or keep learning and improving their product. We’re not talking about anything very complex here. Just learning how to properly create a .zip and distribute it correctly. You yourself mentioned that this was something like: Of course I see mitigating the risk of cheating as a good thing. But it’s not my intention to revive any unproductive debate around that topic here. Those weren't my motivations when I ask about this mod. Yes. I still think that would be a good thing to do. Even if I remember someone arguing that this might be a sterile solution, since hiding a mod can be as simple as renaming one or two files. Anyways, I think we’ve interacted enough over the years for you to know that I’m not against mods or modders.