ffm2

Yes it does. You don't have the final say in the truth. Also: there's never a mind challenging task you add to the eco that you would rather like to solve in your base while you are raiding. You just removed the "boring repetitive" ones. All your "features" go just one way, you remove penalties and make the game easier in a competition with the ones that still have to deal with the penalties.

That is no argument. The whole game is a artificial problem. If you want to relax, there is no problem in setting the starting resources to high. Your production won't turn of. You can also use proGUI which changes 0a.d. more to your liking, just as DOTA changed Warcraft 3 with a shift of the focus to the heros. The Idea of these "artificial problems" is that the player has tasks in his base even while raiding that may get neglected. The key is for the player to prioritize on the more beneficial: Is the raid good or doing more damage to your economy. In depth also discussed here: The community is heavy divided because players automate their game with mods, don't disclaim it and compete with players that like to compete solving these "artificial problems" better than their enemy. See other threads like: It's also not just that the problems just gets removed, they get removed in a way that no human player can. So besides that they have to deal with less, they have a benefit.

Tbh. I didn't fully understand what each is doing here. But as I understand it, the pro of small batch is the units can get faster to work, the pro of higher batch sizes is the total train time decreases. In this simulation a unit with total cost of 100 gets produced, gathers with 0.75 without ways to drop of, at different batch sizes from one cc. To account for the ways one could reduce the gather rate. I wouldn't take any practical advice from this. Just spectate some games with good eco scores. This leaves out the timings of the next barracks which costs again. batch.py

Here is what the LLM ended up with, take it with caution, but to me it seems kind of plausible. Some approximations have been made. One builder just build sequential houses, corrals or fields. Usually its more. The walking distances are neglected. Targeted are ~38.9 f/s. All resources are just pooled together. Realistically its also a big factor that one gathers wood and get food at the fields, while at the corrals you don't have so much food to invest at the start, except if you start out with elephants (or other plenty of fauna) nearby. The one big benefit with the corrals is that you need a lot less pop. Also this pop is way better as it can be used to attack. farms_vs_corrals.py

Why though? It would be 2 developers working against each other. First develops a game mechanic where each farmer has x0.9 of the efficiency of the former. Second just optimize the effect automatically to a minimum making it meaningless for the player. If you like to plan less for your setup, why don't you just suggest to remove the feature that's also not full documented with the numbers? I'd just keep it as it is, but it should be documented with the numbers clearer.

Yeah, if I have some time, I could update it or anyone with the script and a LLM. Just describe the stats in full detail. But to me this seem to be too obvious to put in that effort of typing the stats and debug it. First comes the berrys, then hunt/fish, then transition to fields. Corrals with slaughtering seems not to be the meta atm.. In earlier alphas I liked to have corrals, a temple nearby, wounded cav could work and heal by aura. But it was never a question of either farm + upgrades or corrals. Farms are a must. ... (well one exception was survival of the fittest were there were once no farms, but corrals)

Map: Mainland Players Involved: ffm (Germans), JulioC23 (Macedonian) Description: After capturing an enemy cc (belonging to JulioC23), I trained units and attempted to set the CC waypoint first to ground, then to the cc, so newly trained units would garrison. Despite multiple attempts changing the waypoint to different spots on the ground in front of the CC, on the CC’s corner, and beside it, units spawned outside, did not garrison, and were killed by a nearby enemy tower (still owned by JulioC23). Attempts to reproduce: Replicated the situation in a new game with unassigned players on Mainland, but the issue did not occur. The original game was saved and rehosted, so no working replay is available. Note: If someone is interested, it might be possible to combine the two replays by adjusting turn numbers to investigate further. This is at least a report for awareness; perhaps others can upload if they encounter the same issue commands1.txt commands2.txt

The connection issues I was talking about should happen in the first 4 min. and I'd expect if 2 players recognize this to just abort the game on equal terms. More frustrating its at >8 min. I also like the way lichess handles it. Its server hosted, but apart from that, if one player disconnects, a timer counts down "1:30" and if its run out, the remaining player has the option to claim a victory or draw. He also has the normal resignation option. For 0 A.D. if one player drops, and the remaining player is fair, I'd like some options, like claim victory, resign, abort (draw), spoil scores for a better decision or choose decide by score (blind without knowledge of it).

I set up another game where it was 11 relics: commands.txt

I was late joining as spectator in a ffa hellas game. Not all 15 relics were shown in the bar on the top, only 12: I don't have the full replay file, since I joined late.

Maybe in theory, but I can tell from experience: There are some hosts which I usually can't join at all. Sometimes it works a bit and some minutes later i drop again. Like jagsusindia and CIA. I regularly see 7 players at a host of CIA, try to join but can't. I can play with the other players fine and they can play with CIA. I can also be in a game with CIA by a different hosts.

It is not just about "a stable internet connection". It depends how far the players are away or how well their isps interact. IMO: The auto-pause on disconnection feature from autociv should get implemented in the main game. Connection, disconnections, pauses should be logged. Logging should be done with timestamps

Corrected plots: p_ice_vs_cor.py

Here it is: binaries/data/mods/public/simulation/templates/template_structure_resource_corral.xml ... <ResourceTrickle> <Rates> <food>0</food> </Rates> <Interval>5000</Interval> </ResourceTrickle> ...

lol, I think your right. I thought I did this for some minutes and divided by that time to reduce the error of measuring one small time interval. Needs a revision, but first I'll check the code where the time interval really is handled. Btw. maybe it should be documented XD

:S Man, you don't get my point, but ok. Before the next noob asks me to make sheeps too, where you can pay more and take longer to get the same trickle as the goats, here you go: [Edit: This is wrong! see later post]

One could balance differently. Atm. the ice houses are useless. So they are the nerf themself. They are only a distraction. Of course one would first make woman on fields as much as you can first until one resource runs out: population. Here is a detailed analysis of Net Resources over Time when making one corral after the other. Each corral makes cows until 50 cows are reached: [Edit: This is wrong! see later post] Here is a detailed analysis of ice houses when they are produced one after the other. When the last ice house is made, the upgrade is invested: Here they are directly compared: One can see just how much the ice houses pale in comparison. Then the next thing mentioned were the pigs. Here is a detailed analysis of pigs vs cows: Since one could argue that one could go for pigs without going so much in a resource deficit, here is a comparison with setting a limit of -2000. So one would only make cows when the other cows gave a bit resources so this threshold isn't crossed: One can see just how much of a long-term investment the cows are, but you really get something for your money in the end. Meanwhile with the corrals you go into a resource deficit for a bit over 9 minutes and then get a very little trickle. For the pigs i'd say just leave it. Don't waste actions. You'd never slaughter them anyway and replace with the better cow. For a competitive 1v1 I would only go for fields if it isn't a special map. Python file is there if I made a error. AI was used in the making of the script. p_ice_vs_cor.py

Yeah man. Nice leaning back and watching some games on my spec-top.

Its fixed I think. I let petras play 7 min. because it's late here, but I think it's fixed. Thanks if you read this

I was following: https://gitlab.archlinux.org/archlinux/packaging/packages/0ad/-/issues?show=eyJpaWQiOiI2IiwiZnVsbF9wYXRoIjoiYXJjaGxpbnV4L3BhY2thZ2luZy9wYWNrYWdlcy8wYWQiLCJpZCI6MjI0OTY4fQ%3D%3D but they didn't let me create a account due to heavy traffic or so. Toolybird said: "Can you reproduce the problem? Where is the log file? If it's crashing, where is the backtrace?" Can another arch user reproduce it? Or can another arch user say that they could play for a bit longer? I just started a single player game, let some gaia fight and waited 2 minutes and 10 seconds for the next crash. Here are some log files from .local/state/0ad/log If you tell me how I can run tools tracing it, but wouldn't it be easier if the person that investigates it just lets the game run themself for just max. 5 minutes? log.zip

The version is also wrong, since it's not alpha anymore: https://archive.archlinux.org/packages/0/0ad/ 0ad-a28.0-1

This might not be the best channel, but: The build from the arch repository gets a segfault after a few minutes gaming. This happens for me on 2 different pcs and each game, not like there is one game where it didn't happen of about 5 attempts on each pc. The appimage or compiled git version works reliably.

A minimal mod that replaces the default player colors with a more practical color scheme. The Problem The default player colors in 0 A.D. have several issues: Too many similar color options (hard to distinguish enemies at a glance) Colors are dependent of host settings (creates inconsistency) Some colors are overly bright/neon (unrealistic, visually aggressive) The Fix This mod provides a clean, simplified color palette that: Reduces color choices to only essential, distinct shades Improves distinguishability - no more confusing similar blues or greens Standardizes colors - consistent for all players regardless of host Tones down brightness - realistic, non-aggressive colors Changes nothing else - tiny codebase, easy to maintain across game versions Why It Matters Here's a real scenario that shows why this mod is needed: You're playing as a blue-toned civilization. You're attacked by two enemies - one with a similar blue tone and one red. The red enemy holds 30% of capture points, the blue enemy holds 20%. You miss the blue enemy entirely because their color is too similar to yours, while the aggressive red tricks you into thinking the threat is only 30%. By the time you realize the real danger, it's too late. Why not another color mod There are several other color mods. Some offer 16 color changes, the more colors the less distinct they can be. Some touch areas one might not be interested in. I had issues with the others and ended up making this. The python script is there if you want to replicate it with a different approach and a picture with the background blurred to show how I got the backgrounds. I started with the the tableau colors that I know and like from matplotlib. Install by putting the zip in the right folder: On Windows (Vista or newer): C:\Users\{name_of_user}\Documents\My Games\0ad\mods\ On OSX: ~/Library/Application Support/0ad/mods/ On Linux: ~/.local/share/0ad/mods/ (may be found in GUI via Home/.local/share/0ad/mods/) color_by_distance.py ffm_simple_colors.zip

Huge step forward. Lag is basically gone even in 4v4 games. OOS errors are gone. Some stuff can be found if one looks hard, but nothing that is worth to stick longer to a27.1.

Yeah they are ok.