guerringuerrin

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....

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.

I know that some multiplayer platforms and games implement file integrity checks to prevent malicious code or cheats disguised as mods. I’m not saying that would necessarily solve anything here (we know how easy it is to hide mods in 0 A.D.), but I also don’t have enough knowledge to take a strong position on it. I was mostly wondering whether removing it could introduce other problems. Your explanation helps clarify the situation. My original comment was more about the idea that this feels like a solution that lets modders skip some basic precautions, rather than addressing a real engine issue. I understand that this can be somewhat subjective. I see. The point I was trying to illustrate is that, regardless of where the mod is downloaded from, its correct functioning depends on it being distributed properly: the same file structure across all download sources, and the correct download link in the case of git. Not through Code -> Download ZIP, but by creating a release that appears on the right side of the repository page. Also, if I remember correctly, this caused issues with Feldmap in the past when different versions were used, resulting in OOS. Not trying to make a big issue out of this. Thanks for the explanation!

Ok, I understand your point. I have a few questions though: From what I understand, in your first example the issue would only exist on the modder’s machine, since end users would all receive the same file structure. Is that correct? If so, this seems like the most justifiable case for not checking file integrity, since it only affects a development environment and not distributed copies of the mod. Seems very similar to the previous one. A user cloning the repository would obtain what is essentially the “final” structure of the mod that would later be distributed, right? I see your point about downloading the repository as a zip from git, which adds the -branch suffix to the directory name. But couldn’t that be avoided by creating a release? That would appear on the right side of the repository page and users could download the packaged version directly. This case also seems similar to the first one to me. Users downloading the mod from mod.io would all receive the same package, and therefore the same file structure. Am I right? It’s true that I haven’t worked on incompatible mods (I only contributed something very small to the community-mod, the changelog). However, we’ve been using Feldmap for years and this has never been a problem in practice, largely for the reasons above: users end up downloading the same file structure. The only exception I can think of is when someone downloads the source code directly from the repository (using the “Code → Download ZIP” button). But I always assumed that option exists mainly for people who want to develop or inspect the code, not for end users who just want to install the mod. For that purpose, isn’t the release mechanism intended? In my humble opinion, an end user shouldn’t have to deal with technical issues that are inherent to development workflows. It seems more reasonable for the modder to be responsible for distributing a consistent packaged version of the mod.

Isn't it unusual to allow the same mod to have a different file structure for two different users? Couldn't that generate false positives? Aside from my question, this seems like a rather forced solution aimed at solving a problem that doesn't really exist. Modders should provide a simple way for users to obtain their mods. Besides, it doesn’t seem like a serious issue. It’s just a matter of learning how to properly create a .zip/.pyromod and providing clear instructions to the end user.

Could you check fire damage from Cartha Fire Inf Jav and Iberian Champions Jav Cavalry? Some time ago I read somewhere they actually ignore armor. Edit: also you can check Han crossbows poison damage

hi, @DesertRose. It is highly recommended to use one branch for each change/feature you want to make. On windows I mostly use Git Bash (it's console) but for some stuff I use GitExtensions https://gitextensions.github.io/ I hope this can help you, last comment.:

This is true, at lease by checking the stats in-game. Only Will to Fight affects Elephant melee attacks.

That was fast, @Tapothei! Thanks for putting in the effort to learn how to create a PR. You could get a source-code editor like Visual Studio Code to make things easier for you. Also, when creating a PR that solves an issue, you normally want to include this in the PR message like this: "Fixes #8781" I'll try to explain the basic Git workflow as simply as possible. I'm still learning myself, so there may be a few details I’m overlooking. The usual workflow is to fork the repository, clone your fork locally, and create a branch for your changes ( You don't want to work directly on the website for practical reasons). You commit your work and push the branch to your fork. Each contributor works on their own fork. Once the changes are ready, you open a pull request from your branch to the upstream repository, where the maintainers can review it. Also, right now your changes are on the main branch of your repository. `Check this: Normally main should not be used for development. Instead, it is kept in sync with upstream (the official 0 A.D. repository), and new changes are developed in separate branches. Pull requests are then opened from those branches. This is an example of a PR from another contributor, notice his PR comes from another branch, called "lazy-actual-size": This way your main branch always stays clean and can be used to create new branches. Otherwise, if main contains previous work that wasn’t merged, those changes could end up included again in future pull requests. An if you later want to work on something else and sync your main branch with upstream, you may run into problems because git will detect local changes that don’t match upstream. By creating separate branches from main, you isolate each set of changes. This makes it easier to keep main clean, revisit your work later, and work on multiple things in parallel. I also noticed that your PR contains many separate commits. Like this: In these cases, it is usually recommended to squash (git command) them into a single commit. This makes it easier for maintainers to review the changes and keep a clean history of the proposed modifications. I know this might seem completely confusing right now. But if you plan to keep contributing, learning it will make things much easier in the long run.It can take months and plenty of frustration to get comfortable with the basics of git. So if you decide to learn it, be patient with yourself. It gets a little easier every day. Well, I don’t want to overwhelm you any further. You’ve already made it this far, and that’s worth recognizing. Thank you!

@trompetin17 I realize this is the same branch as the issue I have to test so I guess I have the chance to give it a try of this great project!

indeed this is somewhat a strategy in mid/late games. unfortunetly is not very seen these days

@DesertRose You might find this interesting

i was just about to say that what is the cost multiplier, @DesertRose?

That would be great, @Obelix!