Script Activation

[Ymarsakar]

<B>The puppet ruler script only runs if a gov4 is built on the map somewhere</b>

And how do you think the game knows when a gov4 is present in a city? And how does the script know to not just endlessly spawn generals for a city?

The answer to the first is that the background script is constantly checking every city on the map for a gov4.

The answer to the second is that each city has its own uniquely named client ruler general, that the game "also" checks for in the script. For every city on every turn.

The size of the client ruler portion of the background script in relation to the rest, is 5 megs of client ruler to 6 megs of the rest of the script.

In the end, you get around a 50% increase in AI turn speeds by reducing the script size down, and the most convenient way to do it is to remove the client ruler portions that are checking every city on the map.

[bovi]

monitor_event BuildingCompleted SettlementBuildingFinished = gov4
and SettlementName Gáwjám~Skándzáwárjoz

Foot is right here, the code only checks when a building is made, not every turn. However, the sheer size of the puppet ruler script (roughly 175000 lines, 40% of the EB script, or 5MB, depending on how you want the figure) seems to cause some slowdown in itself.

[Ymarsakar]

There's no way the script can know when to activate unless something in the game is checking for monitor conditions. The script is running all the time, but I don't know how fast it loops on itself.

So, it doesn't trigger every turn unless the conditions are met, but game resources are still used up, for every city according to every monitor condition set, for every AI faction turn and human turn.

As I've noticed with the background script that detects foreign governments in cities I have conquered for it to destroy, it doesn't take effect until some seconds have passed. It's not too much to extend that logic to a script almost twice as long, that the script must take game resources and time for it to run, even if the conditions in the script are not activated.

Logically speaking, a script has to check every turn otherwise it won't know when the conditions have been met. And this applies to every AI faction, even if the script does not apply to them, but only apply to the human player's actions.

Usually the code for the game engine takes care of the many variables and conditions, but that's hard coded for RTW in its source code, I believe.

[Tellos Athenaios]

I take it you don't have any programming experience yourself? Specifically in object-oriented languages such as Java, JavaScript ?

If, you have ...

Spoiler Alert, click show to read: 

Suppose you were to create your own custom 'events' which are very generic: such as BuildingCompleted. Now, each building could fire such an event and does so by notifying a 'Listener' - sending the listener an object containing : source (sender), type of event, additional data (settlement location etc. etc.). Then suppose you were to write a parser of a script. If that parser were to wrap monitor objects around specific conditions, and a monitor object were to have a listener attached and some method to catch events and subsequently evaluate it 'trigger' condition...

You would have 199 objects rather than 199 times 21 evaluations. So at the cost of some serious RAM you gain a lot of speed. Depending how abusive your script is, this cost of RAM is not so serious at all -- but the run time execution of the code is far superior to that of a lineair evaluation of each scripted statement.

[Ymarsakar]

I never took the time to learn anything about any of the object oriented languages. While your point is valid, that parallel processing has advantages over serial processing, are you then forwarding the proposal that the slow down in AI turn speeds is due to increased usage of ram by the script being parsed?

[Tellos Athenaios]

Well, not as much parsing (that's what's being done upon loading a campaign from a save...) but rather the simple fact that once created the objects just sit iddle for most of the time in the RAM. RAM that otherwise is not being used, hence the effective 'calculating' power of your PC is lowered because the schedule for the CPU is limitted to what the RAM can cope with.

If say 200KB of RAM is being used for simply storing all the objects then your effective RAM drops by roughly 20% if you have only 1024MB to spare... Don't think 200KB is particularly heavy for an object oriented language - in fact the concept of object oriented languages dates to roughly the early 80's but the resources required to implement it, meant that only in the later 90's (512 MB of RAM being available) such languages really took off. And Object oriented databases (webdatabases revolving around XML records for instance) are still a thing of the future: for now all major vendors simply assume you use the Relational model, though support for XML is available... Reason? The comparatively heavy memory demand of anything object oriented, doubly so with databases.

In return you get better code: that is, easier to maintain especially when bugfixing comes into play. (You get the ability to program nearly everything only once in an entire program, and throughout the rest of your code you can simply refer back to the code you need...)

[Watchman]

...I dun get it. I'll just assume you have succesfully reversed the polarity on it and be glad I don't need to understand that stuff.