Engine.GetSimRate/SetSimRate from JS script

[CulturedCait]

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.

[Vantha]

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.

[CulturedCait]

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!

[phosit]

Trigger-scripts are executed in the simulation js-interface.

I took a look at the tutorial and saw that it uses

Engine.QueryInterface(SYSTEM_ENTITY, IID_GuiInterface).PushNotification(...);

to send a message to the gui.

The gui receives the messages in "session/messages.js".

[CulturedCait]

Hi phosit,

I checked PushNotification and it seems to be limited to several possible message types. Which of course makes sense from the usage perspective...

Does it mean the only way to achieve what I wanted would be to mod messages.js by adding new message type that registers function executing SetSimRate? Did I get your idea right?

Thanks.

[phosit]

Yes, I think that is correct. But @Vantha has more knowledge. 

[Vantha]

Yes, notifications are the best way to communicate stuff like this from the simulation to the GUI (and it works just as @phosit said).

23 hours ago, CulturedCait said:

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 kind of calculations? A "tick" in the GUI happens for each rendered frame, so the tick rate won't go up if you increase the sim rate (in fact, it'll probably go down a bit, since the game is busier with the simulation and has less time for rendering).

[CulturedCait]

4 hours ago, phosit said:

Yes, I think that is correct. But @Vantha has more knowledge. 

Well, I wanted to avoid creating a mod. Actually I just wanted to make scripted map in plain "vanilla" 0 A.D. SetSimRate, as helpful as it would be for automating few things, is not that critical in the end. I can always invoke the command from the console. Thank you.

3 hours ago, Vantha said:

What kind of calculations? A "tick" in the GUI happens for each rendered frame, so the tick rate won't go up if you increase the sim rate (in fact, it'll probably go down a bit, since the game is busier with the simulation and has less time for rendering).

Ok. This is very long story, but to the details what I'm working on... I'll try to explain. I've always wanted to know which types of units and formations are best in a given case. Also, how my formation should look like considering shape and direction vector of the enemy during tactical clash (in second stage of the project my idea would be also to find precise polynomials that should represent formation lines that should be used). On the one hand these are pointless questions (what we're dealing with are differential equations... that's why some say that strategy is rather an art than something you can calculate).

But for a long time it's been bugging me and I had some ideas how to crack this problem with genetic algorithms. Or at least to try finding approximate or partial answers in some cases. Since I found some time during the Christmas I developed very tiny genetic algorithm framework in JS that operates only on 0 AD triggers in asynchronous way. Since the objective function in my problem is the result of single combat, and GA requires to perform many of such clashes for single generation, this is "the lengthy calculation" I was talking about. GA has to wait for each of such "entities" (i.e. clash of two armies) results to pick parameter candidates for next generation. That's why I was interested in SetSimRate to speed up the process a little. As you can see there are many asynchronous calculations (actually thousands...) that need to be processed sequentially. Speeding up simulation helps much.

I know what you say. You could always grab units statistics, calculations etc from the code and write a program in faster environment to achieve similar results. But I wanted to utilize exact 0 A.D. engine as it is. There would be many mistakes in this process if I did otherwise. Maybe it would be easier, and you wouldn't have to resort to some quirks, but since scripting support in 0 A.D. is very comprehensive it is possible to achieve all I described above. GA's are very slow by definition so technology doesn't matter that much. The algorithm itself is the bottleneck. This is of course very lengthy project. Absolutely nothing to brag about, more like a hobby actually  Hope this now sheds little light where my question came from.

Now, to simulate how SetSimRate helps, just try to invoke something simple that spawns itself each 100ms in a sequence using DoAfterDelay. You can assume this "100ms" is aforementioned sequenced lengthy atomic operation that you don't know the result yet. You'll be notified of the result later when it finishes, and you'll utilize the result later to spawn next iteration "somehow".

testTrigger.DoAfterDelay(100, .....)

You'll see the difference if you speed up simulation to x20. This "100" would become ~5 in real life time. Maybe not really 5, but much faster.