guerringuerrin

No, i'm not saying that. I'm making my point against automations and smarttrain feature. Here you are defining typical characteristics of a real-time strategy game. Are you really explaining how to use control groups? I invite you to play a competitive multiplayer game and see if you still believe that 2 or 3 seconds isn't a long time. Also, in the fast-paced nature of a competitive game (not exactly Medium Petra Bot, not even Very Hard Petra Bot) you may forget to check your barracks for several seconds due to the number of things you have to pay attention to. Additionally, it may be necessary at some point to check which barracks are IDLE and which are overcrowded. This has to be done manually in the vanilla version of the game, and this takes valuable seconds of time. Talking about something you don't know it's not wise at all. Indeed, generally, the definition of what is cheating and what isn't is ultimately determined by the general opinion of the game's community. In this case, for you, there's no such thing as a mod that cheats (unless it breaks a core mechanic), even if you haven't tried it and don't have the slightest idea how it works. Here we return to subjectivity and irrelevant arguments such as "I can still beat you even if you use ProGUI" and this same sentence is enough: "I can still beat you even if you use revealed map". Ok done whit this. Good luck!

If this is referencing the mentioned feature of ProGUI that automatically restarts the auto-queue when you once again have enough resources, then I think it's a stretch to describe that as "self-managing the barracks". Self-managing the barracks would mean more like the game automatically making decisions about what to train based on external game factors. Even with something like that on someone's computer, they do not become a formidable force just because they have those scripts installed, and they still have to pay attention to where all of their units are, and if unit production has stopped or is slowing down, why is that so? And that's not to say that the script always makes the "right" choice; as I said, you become more predictable of a player when you over-rely on these tools, and this actually makes you a worse player even if your score in the summary seems to be improving. I think you are confusing several issues here: 1. This is not how the ProGUI/ModernGUI a.k.a. Atrik's Mod smarttrain works. The mod's GUI allows you to define your army's composition as a percentage or infinitely produce certain units of your choice. Then it automatically assigns all available Barracks(and other military units) to produce the most efficient amount of units based on your available resources. It does this instantly, and as long as you are not haused and have enough resources, it will continue to produce units infinitely as long as you have the resources available and will produce always on idle barracks rather than the vanila system which sometimes triggers a bug in where you end up with some barracks stacked of units and many barracks idles. It never stops production unless: you have no resources, no houses available, you have reached the unit ratio assigned in the GUI, or you make a mistake in this assignment. This means you can continue maneuvering your units on the attack and not have to alternate between selecting your barracks to monitor their production status, allowing you to focus your attention in the right place at crucial moments. Another, more irrelevant but more graphic example is autostart: you configure your preference in the options, and as soon as the game starts, it automatically moves your units to the resource you've chosen and simultaneously produces units from the CC. That is, you can literally have your hands off the computer and your eyes closed for the first ten seconds (more or less depending on the batch size you chose and whether or not you decide to build a storehouse/farmstead) of the game while the other players execute the orders manually. 2. This is somewhat irrelevant if we discuss the root of the disagreement as has already been discussed in many threads, which is the automation of orders. Using automation won't inevitably lead you to victory, and it's not the only variable that defines your skill as a player, just as using a revealed map won't necessarily lead you to victory. So I could use your argument to say that using a revealed map doesn't necessarily give you an advantage. Do you agree with using a revealed map? I imagine not. But I don't mean to confuse things. Ultimately, some aspects of the multiplayer environment are defined by consensus. 3. This isn't necessarily the case either. Automation significantly improves the average player's production, but it doesn't define their style. You can play in very different ways using it. I wanted to limit myself to responding only to the short paragraph of mine that you quoted (which, by the way, I believe does not fully reflect the substantial part of my argument when I have intervened on this topic), but I will add a few short quotes to try to convey my point of view to you more fully. 4. Returning to the topic of consensus: a similar case can be seen in AoE2, where unit production is entirely manual. The community reached a consensus that using self-produced mods in a competitive multiplayer environment was cheating. On the other hand, some mods that visually modify the game, such as making trees smaller or showing fish icons in the water, ended up becoming almost a standard, and top players can be seen using them. Here, we have not yet reached the necessary consensus on what constitutes a fair multiplayer environment and what does not. This was one of the reasons I stopped participating in these discussions, which ultimately became aggressive and circular arguments. I felt frustrated when I realized neither side was budging on their position, and while I'm against using automation, I have a greater interest in bringing positions closer and reaching a certain consensus. But this is impossible if the parties don't budge on some aspect and if there's no attempt to reduce the discussion to more basic issues instead of prioritizing personal tastes or totally subjective and anecdotal opinions like "I produce the same with or without automation," or "I'm still better than you even if you use ProGUI," or "I'm bored of repeating the same task over and over," or "without that mod you wouldn't be as good." At the end of the day, I believe that the most important thing in an RTS game is to build a sense of fairness in a competitive multiplayer environment. I think the contrast between a system as limiting and buggy as the vanilla version of 0ad and the improved ProGUI system is so great that many players have felt unequal, and there's nothing we can do about it other than hope that whoever uses it doesn't use it, and hope that those we don't know if they use is don't use it, or watch replays to detect who uses it (wtf??). So, it's also understandable that without easy and secure mechanisms to detect mods, so that hosts can choose whether or not to allow mods in the game, the feeling of powerlessness grows and sometimes the responses of those who use the mod are arrogant and this generates even more animosity. I'm currently working on a mod that I plan to PR for the next version of the game that eliminates (or at least considerably mitigates) the bug in vanilla that causes units to be assigned to already occupied barracks when producing from multiple barracks, leaving other barracks free when the necessary resources are insufficient, while respecting the essence of the system, which is automation-free. I have received help from @Atrikto do this and I believe it has now been incorporated into ModernGUI. Even with the major disagreements I have with him on these aspects of the mod, we have been able to work together.

why not PR some of the historical changes into community-mod instead of working on a totally new base stats rework?

Thanks, FeldFeld, thats interesting. I thought it was only about amount of items in the queue. I might modify that feature to fully mimic that behavior besides it's not the main purpose of this mod, tho. But some players might find better to play that way.

When we try to produce units from multiple barracks at the same time but don't have enough resources to assign the desired number of units to each barracks, it often happens that units are added to the production queue of already occupied barracks, while free barracks remain idle. This results in long production queues accumulating in fewer barracks than we actually have available, and it also locks up resources that remain reserved for those units. This week, I have been working on a mod to fix this bug in 0 A.D.'s training system. Additionally, I added an option to define the maximum number of units in the production queue. This works the same way as for free barracks: if some of our barracks have reached the maximum queue limit, new units will only be assigned to the free barracks. I'm sharing two videos showing the behavior. When producing in batches, the mod takes into account the number of occupied "slots" in the queue. That is, it does not consider the number of units produced but rather the number of assigned batches in the queue. Also, I added an alternative production system based on the standard system from AoE2, where units are assigned, as we issue the command (via hotkey or click), to the free barracks or the one with the fewest queued units. For now, this system only applies to individual units (not batches). This means we can combine both systems—producing one unit per barracks each time we issue a command or distributing multiple batches among the selected barracks when using batch production. The spirit of this mod is to offer an alternative approach to what I consider to be design flaws in 0 A.D.'s vanilla training system. Distributing it as a mod gives us the opportunity to conduct the necessary tests and receive feedback with a view toward its implementation in the next release. I want to give a special thanks to @Atrik for pointing me to the necessary game files to modify and for sharing a preliminary code to implement this mechanism. To install: Double click on .pyromod file. or Drag the .pyromod file into your 0ad exectuable file or Unzip the content of the folder into your mod's folder. Download files CustomTrainer.zip CustomTrainer.pyromod New Update. v0.2 -GUI now shows the correct number of units that can be trained according to the available barracks GUI batches.mp4 AoE2.mp4 176872599_MaxQueueLimit2.mp4

A dev will answer this better, but AFAIK a natively compiled version should offer better performance than a version installed from an AppImage.

for the record: my only contribution to this has been making myself available to @real_tabasco_sauce, who has been carrying out testing tasks on these potential patches for quite some time and guiding volunteers through the process of compiling patched versions of the game to be tested in a controlled environment. I believe the best approach in a situation like this is to keep bringing in more volunteers so we can conduct 4v4 performance tests in controlled environments while ensuring everyone uses the same client. The real challenge is reaching an agreement and working as a team because jumping to conclusions and spreading "performance solutions" that may not work as expected will only lead to more frustration.

I've sent you a .deb file from the official Debian repositories via PM. It was just a four-word Google search. I can't say whether you'll run into the same issue that @Stan` pointed out with the AppImage, but you might at least face some outdated dependency problems. When RC1 was released, I offered to help you with the compilation, which is a relatively straightforward task, but you chose to wait for an AppImage or the final version. It would have been valuable to have you involved in the tests.

From my POV this is the great advantage of the Smart train. @Atrik Do you remember the game we played the other day where Hakunamata constantly attacked my base with cavs? I had my barracks for a long time without producing xD. And even if I had remembered to produce in them, the vanilla production system is quite inefficient and instead of assigning units to free barracks it stacks units in the same barracks in a somewhat random way. I believe that improving the production system should be a priority in the next version of the game, similar to how it’s done in AOE 2. This way, the advantage of a macro that automatically assigns the batch size according to the available resources and instantly would be mitigated greatly. The advantage of being able to freely maneuver your units instead of having to keep watching where the heck the barracks full of stacked units are is really quite obvious. I have used the smart train several times and my production has improved a lot specially in situations like I mentioned before. Unfortunately, you are also a bit dishonest in this regard. I have rarely heard you mention it as an argument, and instead you argue about your great skill as a player and how you can overcome this difficulty. Something that, while true, somewhat avoids the point in question that, at least I and other players have pointed out to you. I don’t believe the solution is to enter a game as a spectator and start berating yourself. However, I understand the feeling of frustration. Taking extreme positions on either side hasn’t proven to be effective. And it would be nice to reach some common ground. Something that also seems unlikely.

Shouldn't we wait to do the necessary testing on other implications of removing this feature before we go public and start having players running different versions of the game? It seems a bit hasty. Or maybe I'm missing something?

If I recall correctly, we ran a 2v2 large-army combat test two or three days ago with you and @real_tabasco_sauce . During that test, I used two computers: a high-spec PC and a mid-range laptop. Despite having all graphics settings on low, the laptop still struggled, running at just 3 FPS for most of the large battles. Some improvements have been observed, such as the absence of stuttering and state hash check spikes when panning the camera. While these changes may indicate a performance boost overall, I would be cautious about promoting them as a definitive "performance improvement," as players might find the gains imperceptible, leading to potential frustration. To ensure a more accurate assessment, it would be beneficial to involve more players in the testing environment, allowing us to conduct full 4v4 matches under "typical multiplayer conditions".

My intention is to be able to get a more or less accurate idea of the players' preferences by giving them the possibility of choosing multiple options instead of holding a vote in which only one option can be chosen, which would force each user to exclude some of their preferences from their vote. As an example: So far, there is a clear preference for the addition of Building Hotkeys over Players' Stats Overlay, with a difference of approximately 18% percentage points (17 votes/22voters = 77% vs 13 votes/22voters = 59%. ). Of course, here we have to take into account the different preferences between single player users and multiplayer users. We could infer that a single player user does not have much interest in seeing the economic information of his allies as a multiplayer player does. Same for hosts features which has even more difference (23% over hotkeys). And this "could confirm" that right now most voters are single player users. Evidently, this seems to be the case. However, taking into account what I expressed in the previous paragraph, we should consider which of these features are more suitable for the two game modes (single/multiplayer). Taking Active Pause as an example, it doesn't seem right that a player can execute commands while the game is paused in a multiplayer game, and in this regard I would put more emphasis on how to modify the pause system in multiplayer in such a way as to mitigate pause abuse, something we know can be quite irritating. Finally, I would like to add that beyond the "democratic spirit" of any vote, it is difficult to take the results as an absolute and definitive truth. Rather, I believe they serve as valuable feedback for those who, with effort and dedication, develop 0 A.D. and make the decisions they consider most appropriate (and feasible) to continue improving this great game, incorporating Autociv features that have contributed a lot. It could also be a nice tribute. =)

Considering the latest news about the Autociv mod, it seemed like a good time to do this poll. While it's possible that some community member will start maintaining this mod, perhaps this is a good opportunity to think about what features we think could be incorporated into the vanilla game in the future. I want to take this opportunity to eternally thank @nani for the invaluable contribution he has made to the game with all the time dedicated to the development of Autociv. I'm sure that most of the community shares this feeling. Thank you very much, nani. You're the best. If I have omitted any feature that you think is important, please mention it in your answer.

Ok, that's good to know! Thanks

I know that at some point it is adding more work to the devs but perhaps an official WildFires' AppImage would be the best approach. I don't doubt the good intentions of the github user "0ad-matters" but it is understandable that someone might doubt whether he is not incorporating some vulnerability in our system by installing this package. In any case, since this is a free software development native to GNU/Linux environments, perhaps the best thing would be to officially announce the release when it is available in the repositories of, at least, the most important Linux distributions. Afterall, having a new release that is first available with two clicks on Windows and MacOs before it is on Linux is a bit ironic. Yes, people can learn to compile and become better computer users. But this is a video game and the best strategy for spreading it is to not put obstacles in people's way. Just an opinion.

thanks @Atrik i'm sharing the errors i see as nani asked for fixing further releases

@nani Stats overlay does not count kills

@hyperionthanks! i'll with this @real_tabasco_sauceno errors. I also tried the dunedan's combat demo huge we were testing the other day of that same issue u shared and it doesn't work either

I was trying to profile some high stuttering games but suddenly profiler2.html stop working. I did the regular stuff pyrogenesis -mod=public -replay=commands.txt wait a bit for the file to be created and then upload the profile2.jsonp into the .html It seems that is loading the file for a brief after it turns red and then disappears

I'd be glad to do it, but RCs are not available any more here: https://releases.wildfiregames.com/rc/ Is there any way to get them again?

⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⣀⣤⣀⢠⡤⠤⠖⠒⠒⠒⠲⣆⠀⠀⠀⠀⣾⠋⠉⠉⠛⢷⠀⣴⠖⠒⠤⣄⠀⣀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣀⣤⠤⠶⢺⣾⣏⠁⠀⠀⣧⣼⣇⣀⠀⠀⠀⡀⠀⠘⡆⠀⠀⢰⣏⠀⠀⠀⠀⠘⣿⡟⠀⠀⢠⢃⣼⡏⠉⠙⢳⡆⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⣀⡤⠴⠒⠋⠙⣇⣿⠀⠀⠀⣿⣿⠀⠀⠀⢸⣿⣿⣿⠃⠀⢰⣿⡀⠀⠹⡄⠀⢸⣿⠀⠀⠀⠀⠀⢹⡇⠀⠀⢸⡿⣽⠀⠀⠀⡜⠀⣀⡤⠖⠓⠢⢤⣀⠀ ⣠⡴⠒⠉⠁⠀⠀⠀⠀⠀⠸⣿⡇⠀⠀⠘⠛⠃⠀⠀⠈⡟⠉⣿⠀⠀⠘⠛⠃⠀⠀⢷⠀⢸⣿⠀⠀⢠⡀⠀⠀⠀⠀⠀⣿⢧⡇⠀⠀⠸⠗⠚⠁⠀⠀⠀⣀⣠⣾⠃ ⣿⡇⠀⠀⠀⠀⠀⠀⣶⣶⣿⢿⢹⠀⠀⠀⢀⣀⠀⠀⠀⢳⠀⣿⠀⠀⢀⣀⣤⠀⠀⠘⣇⢸⡏⠀⠀⢸⣧⠀⠀⠀⠀⢸⣿⡿⠀⠀⢀⠀⠀⠀⢀⣤⣶⣿⠿⠛⠁⠀ ⢧⣹⣶⣾⣿⡄⠀⠀⠸⡟⠋⠘⡜⡆⠀⠀⢻⣿⡇⠀⠀⢸⡀⣿⠀⠀⢸⣿⡿⡇⠀⠀⢸⣿⡇⠀⠀⢸⡿⡆⠀⠀⠀⣾⣿⠃⠀⠀⣾⡇⠀⠀⠈⡟⠉⠀⠀⠀⠀⠀ ⠘⣿⡿⠿⢿⣧⠀⠀⠀⢳⡀⠀⣇⢱⠀⠀⠈⣿⣷⠀⣀⣸⣷⣿⣤⣤⣼⠋⣇⣹⣶⣶⣾⣿⡿⢲⣶⣾⡇⣿⣤⣀⣀⣿⡏⠀⠀⣼⡏⢧⠀⠀⠀⣇⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠸⡞⣇⠀⠀⠀⢧⠀⢸⣈⣷⣶⣶⣿⣿⣿⣿⣿⣿⣿⣽⣿⡏⢀⡼⠟⠛⠻⢿⡿⠿⠿⣿⣁⣿⣿⣿⣿⣿⣿⣿⣶⣴⢿⠁⢸⠀⠀⠀⢸⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⢹⣼⣦⣤⣶⣿⠁⣀⣿⠿⠿⣿⣫⣿⠉⠁⠀⠀⠀⡏⠀⣴⠏⠀⠀⠀⠀⠀⠹⣆⠀⢠⣿⠀⠀⠀⢈⠟⢻⡿⠿⣅⣘⡆⣸⣇⠀⠀⢸⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠻⠿⠿⠛⠃⢠⣿⣷⣄⠀⠈⠙⠋⠀⠀⠀⠀⣸⢁⡾⠁⠀⠀⣠⣤⡀⠀⠀⠸⣤⡞⡇⠀⠀⠀⢸⣰⣿⠃⠀⠀⢹⣿⣿⣿⣿⣦⣼⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠻⢿⣿⣿⣷⣄⠀⠀⠀⠀⠀⠀⣿⣾⠇⠀⠀⣸⣿⣿⢿⠀⠀⠀⣿⢁⡇⠀⠀⢀⣿⣿⡏⠀⠀⠀⡼⠀⢙⣿⠛⠻⣏⡀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠙⢿⣿⣿⣷⠀⠀⠀⠀⢸⡿⡿⠀⠀⠀⡏⢹⠟⡟⠀⠀⠀⡿⢸⠀⠀⠀⢸⣿⡿⠀⠀⠀⢠⠇⡰⢋⡏⠀⠀⠀⢙⡆⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠙⡿⡿⠀⠀⠀⠀⣸⡇⡇⠀⠀⠀⠻⠾⠞⠁⠀⠀⢀⡇⡏⠀⠀⠀⢸⣿⠃⠀⠀⠀⡼⣰⠃⡞⠀⠀⠀⠀⡾⠁⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢠⡇⡇⠀⠀⠀⠀⣿⣇⣷⠀⠀⠀⠀⠀⠀⠀⠀⠀⣼⣃⡇⠀⠀⠀⠀⠀⠀⠀⠀⣼⣷⠃⣼⡀⠀⠀⢀⡞⠁⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⢸⠃⠀⠀⠀⢀⡇⢿⣿⣧⣀⠀⠀⠀⠀⠀⣠⣾⣿⣿⣧⠀⠀⠀⠀⠀⠀⠀⣸⣿⣿⣿⣽⣿⣷⣤⡞⠁⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣾⣼⣤⣶⣶⣶⡿⠁⠈⢿⣿⣿⣿⣿⣿⣿⣿⠿⠃⢸⣿⣿⣷⣤⣄⣀⣀⣤⣾⣏⣤⡟⠁⠀⠈⠻⡍⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⠿⠿⠿⠟⠛⠁⠀⠀⠀⠉⠛⠛⠛⠛⠉⠁⠀⠀⠀⠙⠿⢿⣿⣿⡿⠿⠋⢀⣿⣿⣧⡀⠀⠀⣠⡇⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢿⣿⣿⣿⣿⠟⠋⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠉⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀

My favourite song is 0.8.Bit Helen Leaves Sparta and Harvest Festival are the ones that move me lately

Bug reproduced under Windows 11. In my case I started the game. 1v1 vs gaia crashlogs files uploaded crashlog.dmpcrashlog.txt

@Ginnungagap @Itms I compiled rc2 and packaged it into a .deb to make things a little easier for users of Debian Linux-based distributions. I was able to install it correctly on the same computer I compiled it. Then uninstalled, removed any dependencies and installing again and it still works. We ran some tests with @real_tabasco_sauce and everything seemed to work fine. But I can't guarantee that it will work correctly on other computers. Maybe someone can try installing it. If it works, it might speed up the testing process a bit. Just in case, I set it to install the game under the name pyrogenesis-rc2 to avoid overwriting the version previously installed on the system. I uploaded in a drive of my own. Here's the link to the file: https://drive.google.com/file/d/1nVYrUtmSb41f9AvsUXJF3SSj5AUFVasS/view?usp=drive_link Not the best place to put it, but I don't have any personal server. I could use something like github or something else if you want. Feel free to tell me: 1) You can install the package with this command: sudo dpkg -i 0ad-deb.deb You can identify the installed package as 0ad-rc2 by running dpkg -l | grep 0ad $ dpkg -l | grep 0ad ii 0ad 0.0.26-2~bpo11+1 amd64 Real-time strategy game of ancient warfare ii 0ad-data 0.0.26-1~bpo11+1 all Real-time strategy game of ancient warfare (data files) ii 0ad-data-common 0.0.26-1~bpo11+1 all Real-time strategy game of ancient warfare (common data files) ii 0ad-rc2 0.27.0 amd64 This is the release candidate #2 of 0 A.D. 2) You can now run the rc2 with the following command: pyrogenesis-rc2 3) If you want to uninstall, you can run this command: sudo dpkg -r 0ad-rc2 I hope this helps the testing process and is not violating any WFG rules . If that's the case, feel free to remove this post. Thanks.

Sure, @Norse_Harold, sorry for that!. It's true that you shared with me this idea. Those batch files were made by myself =) Thanks