Technical Question @Martin/Devs

[Limith]

This is to any programmers with access to the source code:

Based on the implementation of the DH engine (which we can't see), are there any optimizations that we as the modder could do to increase performance time (if it would matter at all)?
*Ex: Less tag usage
*Ex: Using smaller event/minister/tech/leader/etc ids
*Ex: Using event ids that call other events next to each other
*Ex: Optimizations in event triggers
*Ex: Increasing event offsets

Thanks!

 

[^_AC_^]

Here's a few things from the Guide:

Here are some performance hints that should be taken into account when events are created
1. Triggers (no matter if these are for events, actions or commands) should be as simple as possible
and those that are most likely to fail should be first.
2. If there is at least one action that has no own triggers it should be on top of the actions - that's
because action triggers are now considered as continuation of the event trigger and there should be
at least one valid action in order for the event to fire. Actions without triggers are considered as
always valid (no matter what commands they have in opposite to 1.2/1.3).
3. If all actions has triggers, actions with triggers that are most likely to be true should be on top. This
will allow for faster event validation (if main trigger is true and there is at least one valid action the
event is good to go).
The following two rules have smaller impact, but should be followed too as a good practice.
4. Commands in actions should be arranged so most likely to be valid commands to be on top of the
list.
command = { type = addcore which = 300 } #Invalid for Germany. Province #300 is Berlin
command = { type = money value = 10 } # Always valid command - good to have it on top!
5. Command without own triggers should be prioritized in commands list over commands using
triggers.

Also, bigger offsets help too.

 

[ewphoenix123]

This is to any programmers with access to the source code:

Based on the implementation of the DH engine (which we can't see), are there any optimizations that we as the modder could do to increase performance time (if it would matter at all)?
*Ex: Less tag usage
*Ex: Using smaller event/minister/tech/leader/etc ids
*Ex: Using event ids that call other events next to each other
*Ex: Optimizations in event triggers
*Ex: Increasing event offsets

Thanks!

*Ex: Less tag usage

Doesn't matter afaik.

BUT if you have generic events, use the TAG = {} option, to limit the event to nations that really need it, just as you would have used country = {} in none generic events.

There is a big difference if the engine has to check for 200+ country tags to exist or just 50.

*Ex: Using smaller event/minister/tech/leader/etc ids
*Ex: Using event ids that call other events next to each other

Doesn't matter afaik.

*Ex: Optimizations in event triggers

Yes. Andrea posted the important tips. There are differences between the triggers, some are faster to check then others for the engine, but sadly there is no list and I don't think we will get around to create one in the near future.

War, alliance etc. triggers works on lists and are slow.
exist just checks if a country is valid in a fixed array and is fast.

*Ex: Increasing event offsets

Yep, that one will probably help most in the overall picture.
There isn't really any need for offset 1 events.
Time critical events, like ai switches, work fine with an offset of 3-5, and most can have a much higher offset.
Especially generic TAG ={} based events should have higher offsets.

It may be a good idea to spread the offsets a bit.
Don't use allways the same offset. If you use offset 30 as your standard value, split the events into 29/30/31 offsets f.e. so you don't have all checks bunched up on one day but distributed more evenly.






Another things, mostly interesting for total conversion mods.
Higher soft-/hardattack values slow the combat engine down.
Each attack increases the amount of attacks that are checked every hour in combat, so it far more economical to reduce the amount of attacks and increase the damagemultiplicator instead.
Only remeber to keep enough attacks to even out the random factors in the hit/damage calculation.