Mentula

Stan, thank you for the outstanding job you did. Besides the remarkable commitment and contribution to the project development, I have admired your patience, tolerance, responsiveness and involvement demonstrated to every member of this community, from the newest forum user, to the ones claiming they know better. Even more so, considering the responsibility and high pressure that the role demands. 2023 has been a tough year for 0AD and the project is more fragile today than it was one year ago. My wish for the future is that the new leadership will successfully tackle the "few can ruin the experience of many" problem, that so deeply harmed the game and the community. Fair winds Stan. Whatever you'll do from now on, it'll be a success.

Hi @Dizaka, each replay has an associated folder where data is stored (see this page to locate replays on your system: GameDataPaths). A replay folder contains two files: commands.txt and metadata.json. The first file, commands.txt is not used by LocalRatings: it contains the sequence of actions performed by each player in the game and its main purpose is to sequentially execute those actions when a replay is played. The metadata.json file is the interesting one, from the LocalRatings perspective. It contains the stats of the game, taken at certain intervals of time. You may want to look into such file, to extract data from a replay. Nicely enough, the engine exposes two methods that facilitate retrieving replay data: Engine.GetReplays() Engine.GetReplayMetadata(replaydir) The first of the two commands above yields all replays along with minimal metadata. To get the full metadata (including all stats) from a given replay, the second call will do the job. If you are curious to dig into the LocalRatings code to see how the mod handles data, I can suggest looking into Replay~LocalRatings.js and Sequences~Localratings.js, although some additional file is probably needed to grasp the full picture. These two files contain classes responsible for handling metadata and stats (respectively) of a given replay and storing relevant information. Cheers

I quitted playing, same for the others.

This project has seen more releases in two months than 0 A.D. in twenty years

New LocalRatings version! I have been working hard on the new release, and I'm happy to announce it is ready for download! It comes in two versions: v0.26.2 and v0.27.1, one for Alpha26 and the other for Alpha27, respectively. The two versions are the same in terms of features. Download for Alpha 26: LocalRatings 0.26.2 (zip) | LocalRatings 0.26.2 (pyromod) Download for Alpha 27: LocalRatings 0.27.1 (zip) | LocalRatings 0.27.1 (pyromod) What's new (with pictures) 1. Rating distribution charts 2. Aliases (thanks Acero for suggesting this very useful feature) See also Treat players with multiple accounts as one and What is the "primary identity" of a player with aliases? 3. Toggle LocalRatings as a dialog from the lobby, the game setup or in-game 4. Mod filter 5. Restyled player profile area 6. Personalized (rating/matches) format 7. Games with AI players included 8. Optional vertical marker for the evolution chart 9. Negative/unlimited weights

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

Agree on many arguments. In the attempt to find a compromise, I formulate a concrete proposal which, to make it clear, I am neither supporting nor opposing: Proposal [codename: "automatic batch size"] The batch size value can drop below 1 when scrolling with the mouse wheel. When it's 0, the batch count displays "A" instead. "A" stands for "Automatic". See picture below: When the batch size is set to "A", that building produces the meaningful maximum amount of units that available resources allow. I'm not doing the math here to define what meaningful means. This is an attempt to formulate the concept, and details can be adjusted later. The propose is, needless to say, to include the automatic batch size feature in vanilla. Benefit #1: The feature is not exactly what the criticized queuing feature provided by proGUI does, but somehow similar, when combined with auto-queue. The main point of criticism would be addressed by making a similar feature available to all players. With the advantage that the player itself (and not an artificial intelligent trainer) chooses the type of units to train by clicking on icons (or associated hotkeys), which is consistent with the rest of the game design. Benefit #2: (and I very much support this) Currently, to train the maximum amount of units, we set the batch size to 1 and repeatedly click on the icon (or the associated hotkey) of the unit to train. This is against Fastest click wins. With automatic batch size, one single click is enough. Feel free to say it's a horrible idea.

Before entering the merit. This post in not an accusation against the proGUI project: if someone moves critiques against the project or its developer, I will take the proGUI part. As I already said in my first post it is desirable that satellite projects (such as mods) are likewise open. Explicitly (if I haven't said it loudly) this means I support modders, mods and creativity. This thread is about a problem we have. Somebody in the community do not consider this a problem, some others do. The sole fact that a part of the community (not just me) evaluates this as a problem, makes this discussion worth to exist. Further, this thread is not a proposal of decommissioning the proGUI project. To summarize what I said is: 1. I don't have proposals 2. We all should behave according to common sense, which varies (as a consequence, I do not expect others to think like I do). And although I didn't formulate any proposal, I am inviting the community members to find a solution that can accommodate the majority of us. Solutions can be: a) we all use proGUI b) some of us use it, some others don't c) the proGUI queuing system becomes part of 0 A.D. vanilla d) other... I am not supporting any solution in particular. My intent is to face a problem and find a solution, leveraging our rationality at best. Entering the merit: one more time, when I say observe, I mean measure more than notice. Expectations and emotions affect the way we interpret results, so I waited and wrote this post after observing a concrete example of a player who reaches maxpop at minute >17 without proGUI, and reaches maxpop at minute ~14 with proGUI. Since data matter, we can all experiment: we play a number of games with and without proGUI under same conditions, and measure the effect. About the (very unproven) accusation of unfairness @Atrik: please note that the section you quote starts with This is 100% personal opinion. Opinions are, by nature, very unproven. Once again (I quote), I don't want to dive into discussions on levels and skills, which can easily go out of track. Arguments about transforming novices into professional players and the use that top 10 players can do of proGUI are, in my opinion, off-track (besides, nobody is supporting such claims, as far as I can read on the forum). The same I can say about individual strategies to boom. The problem we are discussing is not about natural skills and strategies. But, whatever you guys think it makes sense to give a constructive contribution to the topic, I'm open to hear.

This is what I believe too, and I agree on all the thoughts you shared @Philip the Swaggerless. The solution that could mitigate this problem is to change the mechanics of the rating system to adapt to this particular case, but I am not in favor of subduing data to expectations. You know what they say: “If you torture data long enough, it will confess to anything”. Following the reasoning above, I really think rushing is a particular aspect of the game: in a 1v1, for example, LocalRatings will be very accurate in rewarding effective rushes. The less players, the more rushes are valued. Also, the fact that we regularly play with 200 pop (and not, for example, 50 or 100) and with 300 res (and not 500 or 1000) are reasons why rushes are not very well taken into consideration. In other words, different conditions will be evaluated differently and the effectiveness of a rush depends very much on the game design (which might change in future versions), so I'd rather keep the rating system as abstract as possible, removing all possible sources of arbitrariness. As a side note, some combinations of weights are suitable for rushes more than others: for example number of units killed + exploration will be more significant for rushers [reason: rushers have a high relative value on these parameters compared to other players during the largest part of the game]. However, I acknowledge this is far from being satisfactory, as all the other aspects of the game (economy in primis) will be ignored.

It's now a few months proGUI has been around and we have had the time to form an opinion and evaluate the consequences on the gameplay and the game experience. Although I have never used the mod myself, I played in several games and watched replays with players using it and here is my evaluation on the matter. Most of what I am writing here is personal opinion, so please take it with a grain of salt. 1. Non-negligible advantage proGUI gives a non-negligible advantage to players. We can observe (in the sense of measure, more that just notice) that players using proGUI have a significantly better economy compared to other players of the same level, and even of higher levels. We regularly observe less experienced players having an economy aligned to that of experienced players. We also observe good players making the difference in games against players far beyond their reach. I don't want to dive into discussions on levels and skills, which can easily go out of track, I'm just appealing to the reader's experience, which might match mine. See this post for an actual experiment supporting this claim. 2. Unfair advantage This is 100% personal opinion, as the definition of what is fair and what is not depends on each individual's sensibility. From my point of view, the use of proGUI oversteps the threshold of what is fair. In a game like 0 A.D. the combination of economic growth and military strategy are skills that players value and seek. One of the two aspects is not fully, but greatly automatized by proGUI, making the whole game assuming a different flavor. Sure, there are configurations (f.e. deathmatch) and mods focusing exclusively on the military side, and I am not against all-proGUI-games. But I think it's unfair to mix proGUI players and non-proGUI players in the same game, due of the artificial advantage introduced by proGUI. It's a bit like mixing bikes and electric bikes in a race. 3. Against the game spirit Again, personal opinion. The concept of 0 A.D. (and games alike) revolves around dominating the opponent on two main levels, intrinsically combined: economy and military. proGUI artificially forges one of the two. proGUI is not an eco-bot that plays for you, but it's not even far from that. The game vision expresses clear positions on certain pitfalls that should be avoided, and I don't see proGUI giving a contribute in that direction; rather the opposite, I would say. So, what? Well, I don't know! Personally, I would kindly invite those who use proGUI (or similar) to refrain from using it in regular games, but of course it's up to their sensibility to keep the game "fair". Far from me pushing towards enforcement of rules or other robocop solutions that, in my opinion, don't help making this community more cohesive. It would be nice to behave in accordance to common sense, but I can see that common sense varies a lot depending on who you ask. That being said, I know the developer of proGUI is a good guy, with a genuine curiosity and the best intentions. As an open project as 0 A.D. is, it is desirable that satellite projects (such as mods) are likewise open. It's on us -as a community- to find the solution to this problem, if we evaluate it as such.

Sorry but I can't see any benefit in limiting the freedom of users in choosing their own parameters.

What's for A27? Here are some of the new features that LocalRatings will include in the upcoming version 0.27.1. > Rating distribution charts - If you like charts, statistics, Gauss, or you simply like colors... it's time for new charts! See screenshots below. > Open LocalRatings from the lobby, the game setup or in-game - The LocalRatings page can be toggled as a dialog while playing a game, while in the game lobby or during the creation of a new game. Simply with a hotkey. > A new mod filter - Filter out replays with mods you want to exclude from the rating calculation. > Unrestricted weights - Weights can now be set to any value... even negative! That means that certain parameters can be considered as a malus for the rating calculation. Who knows what data will reveal. > AI players included - Games with Petra can be included for the rating calculation. Because even Publius Cornelius Rufinus deserves his own rating. > And other little perks - An optional vertical marker to navigate charts more easily, persistent table sorting preferences, improved performance... The new version 0.27.1 is currently in the final stage of development and will be released soon, after the necessary tests. If you are interested in trying it, you can download the development version (branch name: Alpha27) at this page. Cheers

In-game you can use Engine.SetSimRate(speed) where speed is the speed multiplier.

As a simple workaround, you can open the console and run: g_GameSettings.gameSpeed.setSpeed(speed) where "speed" is replaced by a number (for example, speed=10, to play at 10x). This is much harder to achieve. The major problem here is not much going forward, but backward. The issue of navigating replays has been brought up multiple times on the forum, but I'm afraid it requires some changes to the engine that may take some time to be developed. I hope this will become a feature soon, it's very useful.

Yes, it records game actions. Therefore, it works in the the game session only.