Seleucids

fpslog1.txt average fps: 76.17021276595744 fpslog1.txt `10%` low: 30 fpslog1.txt `1%` low: 20 fpslog1.txt lowest: 18 fpslog2.txt average fps: 92.876254180602 fpslog2.txt `10%` low: 30 fpslog2.txt `1%` low: 21 fpslog2.txt lowest: 17 fpslog3.txt average fps: 91.12413793103448 fpslog3.txt `10%` low: 31 fpslog3.txt `1%` low: 21 fpslog3.txt lowest: 17 fpslog4.txt average fps: 81.94713656387665 fpslog4.txt `10%` low: 30 fpslog4.txt `1%` low: 20 fpslog4.txt lowest: 16 fpslog5.txt average fps: 119.80232558139535 fpslog5.txt `10%` low: 42 fpslog5.txt `1%` low: 27 fpslog5.txt lowest: 20 fpslog6.txt average fps: 188.7904761904762 fpslog6.txt `10%` low: 53 fpslog6.txt `1%` low: 30 fpslog6.txt lowest: 29 The 10% low and 1% low has been calculated. Human eyes will feel smooth for animations above 30 fps. Having decapitated frozen Maurya spearman ensures the fps is smooth even in 300 vs 300 situations (extreme 2v2 battle). This can at least remove the GUI lag from A27, without the pain of editing the engine. I will be working on a mod which can do this.

The result, graphed: This might explain why experiment 4 and 3 yielded lower values than they should have: I could have paused the experiment prematurely, while the fight was still happening. This decreases the amount of high fps values recorded at the end and hence reduces the total values. However, it is still clear that experiments 5 and 6 (disabling spearman animations) consistently outperformed the vanilla 0AD.

Experiment 6 only removed the attack animations of half of the melee actors present, but the performance improvement was already this huge! To reduce render, one can seriously consider replacing all spearman templates with Maurya spearman. It will look weird but it will really help your fps. Files used attached below: fpslog6.txtfpslog5.txtfpslog4.txtfpslog3.txtfpslog2.txtfpslog1.txtcomparator.pyfpslog6.txt

A source of frame rate drop found: attack animations. When we fight large armies, the GUI must render all of the attack animations, which is a huge task. I removed the attack animations of some units and did a fps comparison to with the attack animations and noted the results. Experimental method: 1. Mod the fps counter so that it prints out the fps value into my terminal. I then save the terminal outputs to a .txt file. 2. For each test, I ran the Combat Demo Huge map on automatic. On game start, I zoom out to my zmin (8.00 in user.cfg) and watch the units fight. 3. Kill 0ad as soon as one side lose all units. 4. Use a Python script to compute the average frame rate recorded, discarding anomalous values and the gamesetup screen etc. I did a FPS measurement and save it to a new file every time I remove an art feature (sorry Stan ). Results fpslog1.txt average fps: 76.17021276595744 fpslog2.txt average fps: 92.876254180602 fpslog3.txt average fps: 91.12413793103448 fpslog4.txt average fps: 81.94713656387665 fpslog5.txt average fps: 119.80232558139535 fpslog6.txt average fps: 188.7904761904762 file 1: Vanilla 0ad units with just my katemod. file 2: removed attack animation of just Roman skirmishers file 3: repeat of experiment 2 file 4: removed Gaul skirmisher attack animation, but kept Roman skirmishers file 5: removed some Roman and Athenian spearman animations; removed both Gaul and Roman skirmisher animations file 6: kept all above changes, replaced Roman spearman with a Mauryan spearman, then decapitated the Mauryans. Subjective observations: Experiments 1, 2, 3, 4 all had a stutter immediately after game starts, then fps rises over time. Experiment 5 was not perfectly smooth animation but playable from a first person perspective Experiment 6 had almost no lag or stutter. Units were selectable in real time without delays. Conclusions: This is consistent with my experience of Romans being one of the most lagging civ and Mauryas lagging significantly less. One big source of lag (at a GUI level) when fighting is the sudden need to render many animations. Removing spearman animation had the biggest effect on fps. A mitigation strategies: simplify skirmisher attack animation (we can't remove it completely because you wouldn't know whether they are attacking anymore); remove spearman / melee attack animation (you will not watch your spearman in battles, you just assume they are fighting ).

I think we should follow weirdJokes' idea and move the champs to barracks and stables, because that is the standard of most A27 civs. Only training champs from temples nerfs the civ too much. The temples can be differentiated in other ways. For example, Carthaginian temples have faster healing rates or greater area of influence, for some rituals they practised. Carthage is already unique enough, no need for more weirdness.

Another observation: some civs lag and stutter more than others in P3 and when fighting. Unplayable stutter: Athenians, Romans Very Lag: Spartan, Seleucid, Carthaginians, Macedonians OK: Gaul, Britons, Persians Least lag: Ptolemies, Mauryas, Kushites, Han Unit type also matters: in general, skirmishers lag much more than slingers and archers. Pikes lag less than spears or swords. Cavalry units also follow the same pattern, but will stutter completely if you try to retreat them.

Carthaginians lack bonuses and they are quite a weak civ right now, compared to the others. They are too dependent on metal and mercenary. They are an archer civ but don't have the archer upgrades... Some ideas: At least give them the archer techs? Numidian skirmisher cavalry run 10% faster than other civs, because they were known for speed and agility? Metal mining bonus, because they are a merc civ? Trading / barter / eco bonus, because they were the richest civilisation around the entire Mediterranean sea? A tech which increases the speed of units but reduces armour or something - new hit and run strategy.

Why is it that Spartans have two separate buildings for heroes and champions? Could we add champion skirmishers back to one of these buildings, and possibly some kind of archer / slinger unit?

Some trolls like to impersonate others. Thankfully MarcAurel is kicking them out on time. I don't really mind this as long as they don't ruin balance or defame the original user; I am just notifying you to look at usernames carefully before assuming who they are. Some hosts fell for the trolling. Examples of impersonating troll accounts: rice-curvature nice-curvature hakunamatatata phyZik PhyZic. PhyZic- .PhyZic. The correct spellings are: Ricci-Curvature Hakunamata PhyZic

What is this and could we mitigate it? Question: how can i compile A26 on Linux? There are many errors

commands.txt This is a 4v4 where I suicided due to lag. Hakuna was pinging me to retreat but I couldn't, because the GUI was almost frozen. The counter claimed 8 fps but it was more like 0.8 fps. Within 1 frame update, my pop dropped from 200 to 173. The next frame I saw I was at 130. All I did was order a retreat. This one is me attempting a 1v7 challenge against AIs: commands.txt

Sadly anti-cheat solutions don't seem to work on Linux. Anti-cheat programs be like: Linux user = Hacker + cheater -> ban Linux users would have many more games available to them if it wasn't for anti-cheat engines; they are the true roadblocks; the compatibility issue is already handled very well by WINE and PROTON.

Is there something special about the Linux kernel that you have noticed, or is it just a coincidence that most people replying to this thread are Linux users? I have tried to play A26 on Windows 11, with Atlas playbook. The frame rate on Windows was on average 70% of my Linux values but generally more stable. The CachyOS kernel always pushes for the highest frame rate possible so the fps is somewhat uneven. Vulkan only deteriorates performance compared to ARB, in my laptop's case. But on a stronger computer, Vulkan performs a bit better.

With the stutter "fix", in P3 there is visible delay (between input and GUI response) as soon as the phase 3 tech finishes researching. It's almost magic. Frame rate wise, the counter drops from 120fps in P2 to 50-60fps. However, in reality (at least from user perspective), it is nowhere near the 50 fps claimed by the counter. Occasionally the frame rate counter does shop dips to as low as 8fps while building barracks in P3. Weird thing is, if I push with large army in P2, the stutter is significantly less and frame rate is high. P3 seems to be the culprit. These graphs illustrate my frame rate experience: Multiplayer:

From a technical perspective, advancing from rank 3 to a Centurion is a conversion. The unit template file changes and the entity changes. Therefore it would be non-trivial to implement a mechanism that automatically converts swordsman to champions. We are looking at a class change on top of stats change; even parent templates are different.

I think the intended way (and fast way) to gain experience is to fight. Try to walk your swordsman onto some enemy archers and farm xp by hacking them down.

Yes. I did a bit more of these experiments: Singleplayer is generally very monotone with a single frequency. If there is too much to render then the rendering time for each frame is equally long until units die out. Even with LAN game, there exists hashes which come in at random intervals and last for quite long compared to render. Singleplayer experience has almost no stuttering. LAN stutters with large quantities or units or high number of commands issued. The same does not apply for singleplayer, where the fps strongly depends on the number of units and their animation, only.

"Controversial" mods such as ProGUI and chat hacks often leave behind unwanted signatures that expose them. Having a machine learning detector program running besides 0ad might be a solution. For example, we can implement ffm's script as a separate live application that sends a system message whenever abnormal activity is detected. Unsolicited behaviours such as private chat between specs and players will also leave a warning in everyone's log. Reveal map and other cheat commands will result in "invalid command" being printed in logs. If too much of these occur in one game then you know somebody is messing around.

Unfortunately hot loading doesn't happen normally. The game only scans the mod folder once on boot, then never scans again. Even if you put in a new mod, it will not be detected by the mod selector until you restart the game. However, this is not an impossible problem: 1. We can always load a dummy mod which has all the dummy file placeholders, so that the engine is forced to consider all of the files there in live. Then, if we need to modify a file, we copy in and replace the dummy on the fly. To deactivate, we overwrite with dummy values. 2. We can add engine commands to check the mod folder more often for presence of new mods and hotload files. I'm afraid this might have to go to engine level. You can't really see into other people's mod files without hacking their computer filesystem. 0AD lobby 100% trusts your own mod reporter script during game registration, which only reports the title and versions of your active mods. The exact contents of your mod folders will never be transmitted to anyone. On top of this, people can edit this script to fool the lobby and other clients.

They have returned in A27 as an official feature. Not sure why it was removed or why it returned. It is not a particularly OP item so no whines about it yet. I tested all of the things mentioned above, the decay then capture exploit does exist (except for siege). These are very creative and meticulous observations. However, nobody has ever tried to exploit these in a TG. Building houses to extend territory then delete is quite a large waste of wood and time. Not sure if it is actually advantageous in most standard TGs. The territory influence is actually quite strong for a single tower; you are going to need about 4 houses out to achieve this with certainty - 300 wood spent. Then, the gaia tower will shoot and hurt your units if you go back and re-capture. I lost 4 slingers just to get 3 towers up this way and it's not even that dense.

source/simulation2/helpers/selection.cpp: for (CSimulation2::InterfaceListUnordered::const_iterator it = ents.begin(); it != ents.end(); ++it) { entity_id_t ent = it->first; CEntityHandle handle = it->second->GetEntityHandle(); // Check if this entity is only selectable in Atlas if (static_cast<ICmpSelectable*>(it->second)->IsEditorOnly() && !allowEditorSelectables) continue; if (matchRank) { // Exact template name matching, optionally also allowing foundations const std::string curTemplateName = cmpTemplateManager->GetCurrentTemplateName(ent); bool matches = (curTemplateName == templateName || (allowFoundations && std::string_view{curTemplateName}.substr(0, 11) == "foundation|" && std::string_view{curTemplateName}.substr(11) == templateName)); if (!matches) continue; } // Ignore entities hidden by LOS (or otherwise hidden, e.g. when not IsInWorld) // In this case, the checking is done to avoid selecting garrisoned units if (cmpRangeManager->GetLosVisibility(handle, owner) == LosVisibility::HIDDEN) continue; // Ignore entities not owned by 'owner' CmpPtr<ICmpOwnership> cmpOwnership(simulation.GetSimContext(), ent); if (owner != INVALID_PLAYER && (!cmpOwnership || cmpOwnership->GetOwner() != owner)) continue; // Ignore off screen entities if (!includeOffScreen) { // Find the current interpolated model position. CmpPtr<ICmpVisual> cmpVisual(simulation.GetSimContext(), ent); if (!cmpVisual) continue; CVector3D position = cmpVisual->GetPosition(); // Reject if it's not on-screen (e.g. it's behind the camera) if (!camera.GetFrustum().IsPointVisible(position)) continue; If I interpreted this piece of code correctly, it iterates through all entities in the selection zone, then discards entities which are not valid for selection. I think this decision process will take time, even for non-selectable items. I stand corrected on this as I don't fully understand how LoS and Cmp work.

If there are 300 units to select, then yes. However, in A26, I raised the selection size to 1000 with my own GUI mod and it was quite fine. Although it's to be tested when the area we are drawing over contains many allied and enemy units which will not be added to our controllable selection but nevertheless be considered by the engine. Since you mentioned selection, there is something strange I noticed: if I draw the selection area from top left to bottom right, the selection works as usual. However, if I move my cursor from bottom right to top left, I cannot select anything. Not sure if this is related. profile2.jsonp This file here is saved from the huge battle demo map during the middle of a huge fight, corresponding scene: I must say, this setup felt much smoother than my previous LAN game, even though the units present have been doubled.

The profiler 2 excerpt is attached profile2.jsonphere:

I already have everything set to minimum. Could we prohibit it from the engine somehow?

A video recording: