Mentula
-
Posts
85 -
Joined
-
Last visited
-
Days Won
8
Posts posted by Mentula
-
-
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
-
1
-
-
7 hours ago, alre said:
@Mentula what about your gang?
I quitted playing, same for the others.
-
2
-
-
This project has seen more releases in two months than 0 A.D. in twenty years
-
2
-
-
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
SpoilerA chart with 100 bins (vertical bars). The yellow bin is the one of the player selected from the player list:
A chart with 10 bins and different colors:
When hovering on a bin with the mouse, more information on players in that tier shows up:
Distribution chart options:
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?
SpoilerThe Aliases menu, where groups of multiple identities of the same player can be created, deleted or edited:
3. Toggle LocalRatings as a dialog from the lobby, the game setup or in-game
SpoilerThe LocalRatings page can be toggled via a hotkey, unassigned by default:
The LocalRatings page can also be opened from the in-game menu button:
The menu button can be enabled/disabled from the Options menu:
4. Mod filter
SpoilerThe Mod Filters options menu. Th list of mods is taken from your -the mod user's- replays. In presence of many mods, the list is distributed across multiple pages:
5. Restyled player profile area
SpoilerThe new player profile area that shows up when selecting a player from the player list:
6. Personalized (rating/matches) format
SpoilerA custom format can be set from the Options menu. For example, the following format:
will result in the Lobby page as:
and in the Game Setup page as:
7. Games with AI players included
SpoilerAn example of an AI player (Ashoka the Great) showing up in the player list:
8. Optional vertical marker for the evolution chart
SpoilerThe Evolution chart can be navigated with the help of a vertical marker. Its color can be changed from the Options menu:
9. Negative/unlimited weights
SpoilerAn example of a negative weight and a big weight:
-
3
-
2
-
-
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)
Spoiler1. Dataset
Dataset consists of 10 games, 5 with proGUI (with QuickStart enabled), 5 without proGUI (with QuickStart mod enabled). Replays are attached to this post.
2. Conditions
In all games, settings are: population cap: 200, initial resources: 300, map: mainland with temperate biome, opponent: Petra sandbox (so that no military action ever occurs), civilization: Gauls.
3. Bias reduction/removal
- Games are played in alternating order (proGUI, no proGUI, etc..) -> to reduce the impact of habits and muscle memory.
- Games are played in sequence: no other game has been played between one game and the successive -> to reduce the impact of short-term memory arising from different play styles.
- Focus on economy only -> to remove fight, rushes and other military actions that can alter economy.
- No economy/other technology researched -> to reduce the variance arising from late or early research.
- No extra food gathered (berries, hunt) -> to reduce the impact of random map generation.
- Equal number of production buildings -> to impose same conditions on production capacity.
- Equal number of fields and food gatherers -> for comparable conditions.
- Equal population composition: only one type of military unit is trained after reaching ~65 female citizens -> for comparable conditions.
- Equal equipment (computer, mouse, screen, etc...) and equal user.cfg/local.cfg configuration files -> for comparable conditions.
- No cherry-picking: all games played for this experiment contribute to final result. Find them attached -> to remove arbitrary selection.
4. Possible existing biases
- I have not played any competitive game with boonGUI or proGUI. Adaptation to the new interface and the new training system could in principle have had a negative impact on games with proGUI, in favor of games without proGUI, which is the setting I am more familiar with. It is possible that a higher familiarity with proGUI affects the edge in favor of proGUI.
- I used my mod bundle (all mods here) in the non-proGUI games. Although QuickStart is the only mod whose functionalities have an impact on the games, a more familiar setting could in principle have boosted the economy in favor of games without proGUI. It is possible that the absence of the mod bundle affects the edge in favor of proGUI.
- After having observed other players whose economy was boosted by proGUI, I could have been influenced by previous knowledge. Besides my assurance that I tried to act as fair as possible, this bias cannot be removed and can in principle affect the economy of one setting in favor of the other, although it's not evidently clear which of the two.
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.
-
2
-
1
-
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.
-
3
-
1
-
-
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.
-
2
-
-
10 hours ago, Philip the Swaggerless said:
Since this mod is based on averaging scores of different frames, it may not be well suited for this. Is that right @Mentula?
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.
-
3
-
2
-
-
On 12/06/2023 at 1:30 PM, seeh said:
set minimum population higher then 0 ? maybe 20?
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
-
3
-
-
In-game you can use
Engine.SetSimRate(speed)where speed is the speed multiplier.
-
1
-
-
13 hours ago, NitroVicky said:
- Faster speed-ups, x32, x40, x50. This is especially useful for watching 2 AIs fight against each other.
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).
13 hours ago, NitroVicky said:- A slider to instantly jump to any point in the replay, much like watching a video in a video player.
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.
-
1
-
51 minutes ago, seeh said:
is it working only in games?
Yes, it records game actions. Therefore, it works in the the game session only.
-
1
-
-
@seeh have you tried with different hotkeys? Hotkeys work fine for me. Also, have you tried using ß and ä as hotkeys for other purpose? To see if those two keys are "special".
Perhaps it would be better to report issues on the project page (page for opening Issues here), so the thread can focus more on other aspects than technicalities.
-
1
-
-
Just now, nani said:
From the code I see you only record serializable actions, do you plan to add local UI actions too? If so how?
Sounds cool and complicated at the same time. I'll take note and think about it.
Just now, nani said:A cool feature would be to show an UI with the steps of the macro after you record it.
Indeed! Definitely worth of consideration.
-
1
-
-
-
Hi community!
This is a mod implementing macro recording. With the Macros mod, a player can:
- Start recording, with a hotkey.
- Do some actions. Any action.
- Stop recording, with the same hotkey.
- Execute the recorded sequence of actions with a hotkey press, at any time during the game.
I see great potential in macros. The more I think about it, the more I find use cases. Therefore, I propose: try the Macros mod, find use cases and share them.
There's much space for new features (and you're welcome to suggest); more than that, I'm very interested in the game-changing aspects of macros.
Be aware that...
This mod executes automated actions. This can be considered as a cheat. When you play a game with this mod, make sure other players are aware you are using this mod and agree.
Installation
Click here to download the latest release. Install following the official 0 A.D. guide: How to install mods?
Alternative downloads: Latest Release (.pyromod) | Latest Release (.zip) | Older Releases
Contribute
The public repository is at this page. Everybody is very welcome to contribute, suggest, fork or simply give feedback. Have fun!
-
3
-
1
-
14 hours ago, borg- said:
Go to the trees closest to the cc?
Yes, I'm not finding much sense in setting the default targets elsewhere.
Also, go to meat closest to CC, go to fruit closest to CC, go to stone closest to CC etc... units garrison into closest CC (QuickStart supports multiple CCs).
I forgot to say. Downloads are (currently) for A27. The latest release of QuickStart for A26 can be downloaded here.
-
Hi!
Let me start with a quote from 0 A.D. - The Vision:
QuoteRepetition - If you find yourself doing the same action over and over without thought, then we need to either eliminate or automate such an action. Linear repetitious procedures are meaningless and boring.
The above quote neatly summarizes the reason why I made QuickStart. QuickStart is a mod that allows to automatically perform predefined actions as game starts, reducing initial micromanagement. Official mod page on GitLab here.
Initial steps can be customized from the Options menu, see image below:
QuickStart and proGUI
In short: proGUI mod embeds QuickStart, with differences. But if you enjoy stories and moral concerns, keep reading.
SpoilerThe idea of developing a framework that allows defining macros in 0 A.D. has been in my head for a while and I eventually took no real action.
But I am a curious guy, and before giving up I wanted to explore what can be done and what can not. QuickStart has been my first project in that direction.
Besides the practical issues, I sensed (from the forum thread on macros and further discussion) that some players express a -fully legitimate, in my opinion- concern on the definition of what is legitimate and what is not in a game. That raised some inner conflict about the opportunity of publishing QuickStart. Among the choices I had, I took the worst one: keeping it public on my GitLab and not posting it on the forum. Well done, Mentula.
Enters @Atrik, cutting the Gordian knot. With proGUI mod (which includes QuickStart) made public on the forum, the Pandora box has been opened and, to some extent, it relieved me of my moral dilemmas.
QuickStart and the embedded-QuickStart-in-proGUI are currently taking two different paths code-wise and I don't know whether they will eventually merge.
Anyway, there are multiple good reasons why a player would use QuickStart without affecting the GUI and the game session, so I will keep maintaining the project and announcing updates.
Be aware that...
This mod executes automated actions. This can be considered as a cheat. When you play a game with this mod, make sure other players are aware you are using this mod and agree.
Installation
Click here to download the latest release. Install following the official 0 A.D. guide: How to install mods?
Alternative downloads: Latest Release (.pyromod) | Latest Release (.zip) | Older Releases
Contribute
The public repository is at this page. Everybody is very welcome to contribute, suggest, fork or simply give feedback. Have fun!
-
2
-
-
New release CircularCamera 0.27.1 compatible with 0 A.D. A27 is out! Please see the first post of this thread for installation instructions.
Changelog:
- Port to A27.
- Thanks to Changeset 27230 (credits to @edoput), the 9 cameras provided by the CircularCamera mod will always point to cardinal points, regardless of camera rotation.
-
1
-
Thanks @seeh, fixed.
Downloads for SelfNerf v0.27.1 and installation guide are in the first post of this thread.
-
1
-
-
SelfNerf mod updated for A27. Only port, no other changes made.
-
1
-
-
Leadership changes
in Announcements / News
Posted
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.