Seleucids

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:

This is a LAN game, because i can't get a large battle with just 1 player. Atlas doesn't work for me (crashes on start) My user report is attached below. userreport_hwdetect.txt I am using an integrated GPU (Intel Arc) and is not ideal. However, frame drops and stutter also occur on my much stronger machine running RTX 3060, except the minimum fps on there is 20 and there aren't complete GUI crashes. Looking at profiler2 results, the rendering is the most costly. Could we only render 1 texture layer, not all 3 materials? (just the .png file not the spec tex and AO tex norm tex etc)

Sadly A26 doesn't build itself on Linux anymore. I am happy to try it on A27 though. Profiling before start (during loading etc) There was a fair bit of stuttering and low fps once I reached about 400 units per side. commands.txt profiler2.html

Lets think back to changes to the engine and the public mod between A26 and A27. Which additional features could introduce extra load during game session? I plan to do these 2 experiments: 1. Run A27 public mod with A26 engine 2. Run A26 public mod with A27 engine The difficult part is there were many changes in function names and that might cause many compatibility issues. I personally think that public mod is unlikely to be the culprit, but I stand corrected. Pathfinder is usually a big contributor to lag.

Yeah totally. I've played hundreds if not thousands of TGs. I've seen less than 10 wonders built (in non troll games) in my entire 0ad career. In most cases people don't even build forts and towers (especially me) unless there is a serious risk of early inf push.

1. Are you playing A27 or A23? Don't think siege can be captured now. 2. Most of these exploits can be solved by setting fixed diplomacy 3. In Mainland Standard Settings there won't be any Gaia soldiers on the map 4. Each person is only allowed to have a certain amount (20?) towers and dogs. Forts even less. But nice thoughts!

Try what I just posted above with the A23 zips. I will try A23 tomorrow as well.

This video below shows you how to re-compile A27 and edit the engine code so that hash is removed. This is exactly what I did this afternoon: By the way welcome to my new channel ! This one is for Linux users. I will look into Windows tomorrow.

As long as it doesn't affect balance and game mechanics, it's fine. Atrik always uses ProGUI so his level is consistent and we can balance him accordingly. We don't know his level if we take ProGUI away from him, but we can easily balance him as of now. Similarly, if you take my cube trees away from me, you will see a 1350 player struggling to put down storehouses.

https://releases.wildfiregames.com Here you can download all past versions of the game and try them out if you are interested We did our custom builds here.

Originally they did: if (turn % 20 == 0) return true; Which means 1 full has per 20 turns. We can do maybe turn % 300 == 0 which means 1 full hash check per minute. return true = do full hash return false = don't do full hash For everyone else who want to do this or play with us: The OOS is false alarm. The error is thrown because everyone else is doing a full hash at 20 turns, but we did not respond to their check request. The error does not affect gameplay and can be royally ignored. Just play on and the simulation will be in sync because it is deterministic in nature and player commands are synced over network. I personally have noticed significant improvements, especially in early game and in large fights. However, it doesn't solve everything because other parts of simulation are still poorly optimised.

This was taken while spectating a TG at minute 9, on my custom build: profile.txt Now with the normal one: profile.txt