Seleucids

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

For me, my frame drops to 10 fps as soon as I reach P3. Then freezes during fights. Good news @0 calories, I managed to recompile A27 with the wraitii quick hash and it reduces lag to near A26 levels! The game throws OOS errors at 10 seconds in but it is a false alarm and will not pop up again.

I'm afraid this isn't always the case. In A26, people with low spec computers also had low frames and simulation delays. However, the stuttering was much less of an issue as it only gets extreme in very very large fights. In most cases, low graphics cards just gave 10-20 fps, which was not comfortable but still playable. We have almost never seen anyone having to pause the game because their GUI is crashing, whereas this happens in almost every game nowadays. On average, the frame rate in A27 is only 70% of that in A26. I did some fps recording and obtained this data. The important part is the minimum fps has dropped a lot since A27 and GUI fails to respond. A26 could run smoothly with just 1 stutter per game on powerful hardware, whereas A27 struggles even when your hardware is maxed out. The difference is, A27 fails to utilise 100% of any resource: a single CPU core is at 60% when the game is stuttering and the GPU usage is merely 50%. However, with the build which removed full hashing, the usage of system resources is near 100% and the bottleneck now is really the hardware. Another solution is to async the GUI so that at least the player can hang in the game, but not sure if that is trivially doable. If nobody shows up, we can make a few alt accounts and join with multiple instances (Linux OP !). Since the game is only a single core process, the performance of 4 instances is the same as 1 instance. Another idea is I do unofficial builds and distribute that out to players.

As most people are aware, A27 has some technical bugs: extreme stuttering and OOS on rejoin. The extreme stutter makes many players drop down to 3fps or even freeze and crash the game completely. We have determined that it is caused by full hash. Wraitii has a fixed version with quick hash that solves this problem. I and @real_tabasco_sauce have tested it out and large battles with 4 players were able to run smoothly. My question is, can we do a quick re-release like we had in A25-b or just call a new version A27.5 / A28, where we at least fix the hashing stutter. If this is too much to ask, all we need to do is compile this: https://gitea.wildfiregames.com/wraitii/0ad/src/branch/quick_hash_only/ into .exe or appimages then distribute it to the player base so that people who aren't capable of building the solution can also play. Of course it might not be compatible with the rest of A27 players but if everyone could update easily, then it won't be a problem. The solution can be popularised by advertising on the forum and the lobby heading message. We can do a release candidate every time a bug is fixed, just to get games going. This current version is almost unplayable for many medium spec users and a few players I know have quit because of the stutter issue.

Updates for A27: To enlarge training icons: larger-icons.zip Ranged Overlay without OOS: rangedoverlay.zip Previously, the ranged overlay mod caused OOS with community mod, because the stats of units are different. Now, community mod no longer exists so your templates will not be touched by other mods and hence no OOS issue.

autociv-sevda.zip This is my enhanced version of autociv, which displays the count of each unit class, KD ratio etc.