real_tabasco_sauce

maybe, from the above, I am starting to think the bottleneck theory is pretty well supported.

ok yeah I can already tell that they still occur in a26 and that they still disrupt the GUI. Its easiest to tell by panning. Indeed, even early on, there is a slight freeze every 4 sec. state_hash_check is unlogged in a26, but I can see 4MS jumps coinciding with the stutter every 4 sec. I'll see how large they get

it still shows up in profiles with the same magnitude. here is a 4v4 on foothills from a26 I'm going to watch this replay on normal speed and see if any stutters coincide with jumps in state hash check. For the record, in a27, I have seen the state hash check value surpass 20MS in the f11 profiler, which I have not yet seen in a26 or the rc

yeah "rc1" in those profiles is the one @Gurken Khan shared.

From what I understand, we are still figuring out why it seems to be worse. The unfortunate thing is that aside from this, the performance really is strikingly better: https://gitea.wildfiregames.com/0ad/0ad/issues/7589#issuecomment-111582 (red is a26, green is a27). So this is essentially holding back the benefits of the work that was done, at least for MP. Ok, so here are 3 profiles of combat demo huge in multiplayer, along with one with quick hash only: fullhashCDH.jsonp nofullhashCDH.jsonp a26CDH.jsonp rc1CDH.jsonp I can't tell any significant difference between the magnitude of the full hash across these alphas, they all seem to be 120 to 150MS for me.

My guess is what registers for faster PC players as a stutter, a brief hiccup, could be far, far worse for players with a lower spec PC. The 'gaps' you see below represent the former: This is what it looks like for a full TG, you can see the effect of the stutter for sure. This is a 19 minute foothills TG. the blue lines are normal turns that take very little time to compute, and the gaps are the full hashing. We have done these for a long time, but I suspect that in addition to improvements in other areas revealing the stutter, we might also have more to hash overall. So yeah there is full hashing in replays. I'll look at earlier versions and see if the hashing gap remains large like this. if you want to profile stuff, there is a really excellent guide on how to do it here: https://gitea.wildfiregames.com/0ad/0ad/wiki/Profiler2

So that does actually sound like the same issue @0 calories, just more severe. Was the one you did with 8xAI more similar to your experience from a26?

Can you describe your problem in more detail? Do you drop down to 4fps irregularly, like every 4 seconds, or is it just a constant laggy experience? How quickly in a typical game do you get down to 4fps? And what fps would an equivalent game in a26 have? What steps to fix it have you tried, like switching to different graphics settings in options -> graphics (advanced). Have you tried combinations of Vulkan/openGL and with vs without GPU skinning? It could be that you are experiencing a separate issue.

I was just explaining how I change my settings in a way that makes sense to me.

What I like to do is set the batch increment size to 1 and then hold shift and click multiple times to get the number I want.

I think making it so buildings can only be deleted if they are connected to your town could work, but does anyone think this would be frustrating? I think it might be. Imagine you have captured a house only to realize it has no value, and now you have to wait untill it is the enemy's building to start poking it down. We can make destroying buildings more relevant without this change. I'd like to cook something up to address this in the community mod.

yeah, but its good to put uninteresting effects into phase ups. For example building arrow damage increases with each age, but if that were instead 2 technologies, there would be a ton of tower techs. The CC is getting rather full of techs recently.

It would be interesting if attacking buildings was a bit more worthwhile/effective. In any case, the default should be set by an option. I would avoid adding too many techs for this kind of thing. In this case, utilizing phase ups would be good (ie for HP).

Do you have to actually start the game, or just get to game setup?

Ok i forgot to explain With this PR, (https://gitea.wildfiregames.com/0ad/0ad/pulls/7633) units will only get stuck attacking a building (or capturing) if you have directed them to do this. If you didn't, they will consider units of higher priority. So it means that if you looked away from your army and they start attacking buildings because there are no units nearby, they won't get stuck doing this. Also, it helps with units like bolts to not get stuck attacking a house or something.

Screen Recording 2025-02-15 202422.mp4

I hope that we can make it so we don't need to remove corpses. I have a PR with some promise https://gitea.wildfiregames.com/0ad/0ad/pulls/7616, but more can be done.

I'd be ok with Germans or Cimbri. I suppose we could break the norm of 1 word civs and call it the Cimbrian Alliance.

The were called Gastraphetes if that helps you search.

H is stop, which halts existing orders. This way the stopped units check for targets anew, and if there are higher priority targets, they will instead attack those ones.

??? I don't do this. Its not even that good atm. You seem strangely biased for some reason.

This has nothing to do with sniping. Sniping is where you task ranged units to shoot other ranged units beyond melee units. It was about getting past the "meatshield meta". I suppose you could cheat and set a unit's top preference to be ranged units to do this but that would be almost guaranteed to go OOS. Also it would be incredibly lame and uninteresting.

One idea I thought of was to add a check for targets of higher priority than the one currently engaged if the unit is not following an order. I thought of this for bolts, but it could apply to other units too. I think AOE2 does this.

Yep this is it. @Dakara, @leopard I recommend going to hotkeys and binding "attack-move (unit only)" as a replacement for the existing attack move.

Well, I suppose with the issue identified (maybe just one of the issues), we probably don't need to do this today. Its telling enough that it takes place, albeit to a lesser extent, even in the first minutes of some games when CPU load from simulation should be really low.