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.