All Activity

That would require to move gui element around. This would require an engine change.

Hi Vantha, thanks for detailed explanation. All is clear now. What I wanted to achieve is to programmatically speed up the game in the beginning to the value of~ x20 (just temporarily) to override default Map Setup setting. Reason is to perform some JS asynchronous calculations much faster eliminating internal tick bottleneck. Then go back to the default speed value few moments after. What you described as a workaround sounds very promising! Can you please explain little more how to communicate between different contexts to register SetSimRate? Thank you!

Hello, you mentioned that you don't know how to compile, but that may be the only option if you want Linux native older 0 A. D. And it's not too hard to do. First, get the a23b tar source and data archives from this link: https://releases.wildfiregames.com/ Then, follow the build instructions for Linux on this page: https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructions Obviously, instead of the latest source and data archives, you would use the a23b ones. Good backup practices apply before compiling any large software from source.

That's not possible, unfortunately. Essentially, the engine creates different JS script interfaces for different purposes - one for the GUI (scripts in gui/), one for the simulation (scripts in simulation/ and trigger scripts in maps/scenarios/) and one for map generation (scripts in maps/random/). And those Engine functions are always registered in specific contexts. Engine.QueryInterface, for example, is obviously only available in simulation context, since that's were simulation components and interfaces are. Similarly, Engine.SetSimRate and Engine.GetSimRate are only registered in the GUI scripting context, meaning you can only call them from GUI scripts. What exactly are you trying to achieve? There are some possible workarounds because the engine allows you to communicate between contexts and modifying the engine to register SetSimRate and GetSimRate in simulation scripting context too is quite straightforward actually.

How many scenarios do you have?

The easiest would probably be using the windows binary with wine / proton. You might see a warning at the start tho as wine doesn't support numa and as such the hardware detection will fail. Just click continue in that case.

Hello everyone! I’d like to share the latest updates from the project as we wrap up the year. I’ve redone many textures and improved several in-game structures. At the moment, I’m reworking all terrain textures, developing the building damage system, and refining many core gameplay mechanics. I hope you enjoy the updates and continue following the development. Wishing everyone a Happy New Year!

I have played this version almost daily for what seems like a decade. My scenarios and skirmishes (single player mode only) are somewhat modified and ONLY work w/ v23 Ken Wood. Have tried many times installing a new or latest version for Linux thru the Mint repositories and moving the maps etc to new version. Never works. I have searched and read here and everywhere else for almost a year merely trying to find the Ken Wood v23 in a Ubuntu .deb package to install on a new PC build. Running Mint 22.2 now the repos and everywhere else only have the latest 0AD versions, or the tar gz versions that I have no idea how to "compile" or install. Even tried a Debian version that of course will not work in Mint 22.2. Finally decided to ask for help and need a good Linux pro. Thanks

Hi guys! I'm working on a new script and I was wondering if there is a way to execute Engine.SetSimRate / Engine.GetSimRate from JS trigger script? It works if executed directly from the console, but using these functions inside JS produces following error: ERROR: Error in timer on entity 1, IID103, function DoAction: TypeError: Engine.SetSimRate is not a function This is my test trigger: Trigger.prototype.TestDelay = () => { Engine.SetSimRate(20); } const trg = Engine.QueryInterface(SYSTEM_ENTITY, IID_Trigger); trg.DoAfterDelay(5000,"TestDelay", {enabled: true}); I'm on release-a27.1 6a576. Do you have an idea how to change simulation speed from within javascript? Is it even possible using trigger mechanics? Thank you.

Alguma novidade das novas civilizações??

Tabletop Tavern

Model of the Roman fortress at Ockenburgh

Yes, and this is a major problem. Some games have AIs that just group units some distance away from the targeted base and commence the attack from there. I know for certain Brood War does this, but it's buggy. Units will still sometimes ignore the player's units while going to their grouping spot. Other times, the grouping spot will be inside the enemy base, so the units will be in a single line anyway. It's not easy to code good grouping without the AI actively using formations. In the older alphas, AI would have grouped his units properly because formations were hard-coded.

I mean, can the AI be programmed to always do that, while the player will certainly do it?

I mean, the longer the march, the worse this problem becomes. But anyway, the player won't be affected by it. I forgot to mention that the AI is the one affected, AI controlled troops are simply walking into their deaths in a single file.

Hello Kreise and welcome to the forums! Do you have a replay or some other hints so that someone can easier start an investigation?

The pull request has been merged by @Vantha. Thank you very much for reviewing Vantha and @wowgetoffyourcellphone!

A similar issue was recently addressed: https://gitea.wildfiregames.com/0ad/0ad/issues/8580 https://gitea.wildfiregames.com/0ad/0ad/pulls/8589

That's not exclusive for large maps or units with different speeds. If you have no formation: Each unit try to get to the destination without collision resulting in this line like ducklings. You can set the destination before the enemy base to regroup. Formations have big problems on their own for path finding. Some players (not me) just activate formation short before a attack so the units run in the formation (a speed slightly faster that normal walk). For new units from the barracks you could make batches. But loose unit groups are vulnerable. If you find such a line and can attack it with a group you can take out a lot of units with without taking much damage. A basic aspect is to attack few units with a lot. It's the players duty to run from outnumbered fights or attack when you are stronger. So: Yeah, but what do you want the game to do about it? You can set the regrouping point before the battle and send them in when you feel ready.

There's a problem with playing on large maps: the movement of units. Units have different movement speeds, and those that arrive first tend to attack first. Sometimes these units wait for those who arrive later to regroup, but more often than not, they don't. The result is a long line of soldiers charging headlong into death. Could this be improved by choosing a regrouping point and making the attack only begin when enough units are present?

I would recommend scaling them up, at least a little bigger.

Depends on when those tournements will be held...

It's great to see more use of this, only the Iberians even have this in vanilla 0 A.D.

You didn't win, game crashed.