Leaderboard

Some numbers from experimental data I made an experiment to quantify the advantage provided by the proGUI trainer to economy. Technical details below. It turns out that -within the context of the settings below- I could reach the population cap 24 seconds earlier with proGUI (on average). On top of that, I could gather additional 1.14K resources with proGUI (on average). Experiment details (conditions, fairness, biases) Conclusion Results from experiments under comparable conditions show that -in my case- the economy of games with the proGUI trainer enabled is boosted by a non-negligible factor. The fact that both the population and the amount of collected resources are better with proGUI can be decisive in a game. I foresee objections of having forgot this and that. Please remember that 1. this is just data, anybody can produce more data to fit different settings 2. 0 A.D. is a game based on public information: other measurements -even on other players- can be taken and shared. Whether we use a particular mod or not, the information we share as a community, via replays, is public and visible. In other words, a player who does not use proGUI have the same means to evaluate the impact of proGUI on other players [with a rough comparison: one does not have to be alcoholic to measure the effect of alcohol on others]. So any data or thought from any user is welcome and shall not be minimized, regardless of the mods they use. I will put a link to this post in the first post of this thread for future reference. 10_replays_Mentula_20_06_2023.zip

this made me laugh, your analysis is perfect. If you added a chart, I'd have you published.

Go guys, lets play

fulltext-search for help commands: https://youtu.be/VjJGmbLnhsY

Interesting. And you had only 2 productions buildings to manage. The edge it probably provides is expected to noticeably grows with the number of buildings. Your sample looks serious enough for this kind of experiment but very surprised from the results. Since you don't have much edge cases in your boom in these experiments (and that you train only 1 type of unit and you don't actively manage production variables), you could have exactly the same performances if you used the resize queue mod I cited earlier. (Will do the exact same thing: training batch using same forumla and at the same moment).

Bro I know they were overthrown in 7th century but it doesn't mean we can deny iranians who were always revolting and struggling with Arabs and Muslims even two centuries after the collapse of Sassanid The eldest and the most important rival of Arabs and Byzantines was Iranians or Sassanids and these three civilization had had a lot of cultural, scientific and political exchanges with each other and many transactions and communications whether in war or in peace. The Sasanian units and especially the Sasanian horsemen and knights, who are very famous and popular and unfortunately have not been made in this game yet, were very similar to Byzantine and European medieval horsemen and knights, no doubt considering that the Sasanians and Byzantines were neighbors and rivals in the same region, according to the same military and cultural exchanges, they became very similar to each other in architecture and military forces. Many educated and scholarly Arabs who studied at the largest university in the world at that time, GundeShapur, learned many things from the Iranians and took them to their other lands, and for this reason even the Arabs had horsemen like the Sassanians and so on. To defeat the Sasanians, they used the same political, military, and economic structure as the Iranians, and what is known as Islamic architecture today is actually a mixture of Iranian or Sasanian architecture with Byzantine and Egyptian architecture, nothing else. I have personally studied the history of my homeland Iran very well and I know that every Iranian dynasty that came to power after the Sassanids considered themselves the descendants and successors of the Sassanids and traced their descent to the kings and princes of our ancient Empires. the Umayyads and Caliphs still used Sasanian horsemen, and the Sasanian, which was a new Iranian civilization, was not something that could be completely destroyed that easily, and even a game like Stronghold Crusades 2 used these Sasanian knights, Although it happened in the 12th and 13th centuries. we really cannot deny this great and glorious civilization. The Abbasids are called the Arabic Sassanians, so see what influences the Sassanians had and what many things the Arabs adopted from the Iranians (Sassanian). Now I've made real historical scenarios of 7th and 8th centuries before the fall of Sassanid Empire or during their collapse. And I have three civilization there: Byzantines, Rashidun Caliphate or sometimes Umayyads and Sassanids. I chose the Byzantine civilization for both the Sasanian and Byzantine empires due to many similarities they had. Plz support my request and Sassanid to this game.

Seems like option 2 is potentially less work if we have to adjust anything/un-commit anything. Option 1 doesn't seem like it really saves any time

I think we were discussing gui features, for example I don't think you consider formations macros, but it's running much more code then something that will resize batch size. My guess is that you'd want the gui to features to be alike the "Age Of" and stay as is. This would be a very reasonable opinion tbh. Still the gui could have some better feature for managing production. I used to play with just a modified boongui overlay. I had nothing auto, but I could see and select idle buildings very fast, and set the batches manually, it was also already solving my issue with having to find the building for which auto-queue broke. I'm sure for example implementing in vanilla idle building icon like the idle units could still look useful for players with your UI preferences.

I'm against all macros, so the "solution" I am most in favor of is no solution at all.

Thanks for the heads up, however the forums aren't a good place for such urgent information, as receiving and reading its notifications might come with a significant delay. In fact I just did see this post when I went to the forums to post the post-mortem, you can see below. Pinging me in the lobby (as long as it's still available) or in the 0ad channels on IRC is usually much faster. Today's lobby outage happened between 18:31 UTC and 19:04 UTC. During that outage the ability to host games or join hosted games was limited and the lobby bots rapidly quit and rejoined the lobby, leading to a lot of spam due to the quit and join messages. Here is why that happened: Earlier today I merged some lobby related infrastructure improvements (https://github.com/0ad/lobby-infrastructure/) and deployed the changes to the lobby VM. As part of that I accidentally deployed the productive configuration (lobby-config.yml) to a local instance of the lobby running as a Vagrant VM on my machine as well. This happened, because the hosts file I use for Ansible didn't just contain the VM of the official lobby, but my local instance as well and I wasn't limiting applying the changes to the official lobby (using ansible-playbook --limit …). I had my local lobby instance in the hosts file, because I sometimes test things which are easier to do with ansible-playbook, than with vagrant provision. While I did notice the incorrect deployment of the productive config to my local VM, I didn't recognize the possible impact that might have and instead figured that running vagrant provision later on would cause the correct config to be used for my local instance and would fix everything again. When I ran vagrant provision later to test some unrelated changes locally, the correct config (lobby-config-vagrant.yml) did get used, but instead of fixing things, it resulted in the outage. That's because deploying changes to the lobby bots doesn't remove possibly existing instances of the lobby bots. So if for example a bot named xpartamupp1 is present on a target host, it doesn't get removed when a new deployment happens which doesn't include xpartamupp1 in its config anymore, but rather includes for example xpartamupp2. That alone wouldn't have been an issue, but that deployment also removed the mapping of lobby.wildfiregames.com to 127.0.0.1 in /etc/hosts, as is done for the productive lobby to ensure the lobby bots don't need to do a network round-trip when connecting to the ejabberd which runs on the same host. That then caused the productive lobby bots to connect to the official ejabberd server instead to the one running on localhost. That meant suddenly for all bots two instances with the same XMPP resource were connecting and that caused ejabberd to kick out the one connected first. As each bot then immediately reconnected again, that resulted in a kick-loop which caused the rapid quits and rejoins of the lobby bots. To get out of this situation I simply stopped the bots on my local lobby instance again. That took a bit, as I had to figure out the reason for the problems first. While that whole outage was ultimately my fault, I believe there are some things we can improve to avoid such problems or their impact in future: - Adjust the Ansible code to delete (or at least disable) lobby bots present on the target host, but not in the configuration used to deploy. - Fix the lobby bots so they honor the reconnect delay when getting kicked like in this situation. - Avoid putting hosts which aren't the official lobby host in Ansible's `hosts` file. If somebody wants to step in and contribute to these improvements or would like to see other improvements, pull requests for https://github.com/0ad/lobby-bots/ and https://github.com/0ad/lobby-infrastructure/ are always welcome.