Latest patch 1.5.7 download

[Suppanut]

And now with release of 1.5.6 (10% longer than version 1.5.4), It suffer another leap for longer end turn time when additional scripts are applied.

That's strange. None of these changes should affect script processing time whatsoever.

There were literally zero changes that affect the script engine in the previous three changelogs, 1.5.3 was the last one that had any.
In fact the file containing the source for script processing has a date of 2023-11-03 so it's 100% certain the file has zero changes since then.

Are you 100% sure the changes weren't made on your side and you measured the time used by the scripts on the exact same save file and mod version?

Best I can do is turn off range checking and enable code optimization in the compiler for whichever remaining parts do not yet have that setting.

Here is an EXE complied with range checking off and optimizations on for the entire code. Let me know if that improved anything.
https://drive.google.com/file/d/1c2lWM7s...sp=sharing

I made exactly the same script test compare between 1.5.4 and 1.5.6 last night. I use the same save. Close all concurrent program so they would not interfere with performance of single core game.

And yes, I first notice significant longer end turn in 1.5.3 that why I release mod for both version 1.5.3 and 1.5.2 at that point. But exact number when I test is now gone, but I most of time lose I report in version 1.5.4 mostly coming from 1.5.3 update. I still not yet give full test on version 1.5.5 when version 1.5.6 coming out. I only decide to test it again last night by compare version 1.5.4 and 1.5.6 due to I get save from Hadriex as longer end turn would jeopardyady his playthrough on livestream.

I will test your new exe without range check tonight and will report the result.

[Suppanut]

Test concluded, here is the result.

Version 1.5.6 official: 4:26 minutes
Version 1.5.6 with code optimization: 3:56 minutes
Version 1.5.4 official: 4:25 minutes
Version 1.5.2 official: 4:33 minutes

1) Your new exe that you upload definitely the fastest version right now with end turn period at least 10% shorter than your official 1.5.6. And also faster than result I get from downgrade content to support version 1.5.2!
2) Result today is much different from test I have done 8 months earlier when I compare version 1.5.2 and version 1.5.3. That time 1.5.2 get at least a minutes faster 1.5.3 and later version 1.5.4 does not faster than 1.5.3 at all when I compare it upon code the mod upon moment new version is released. I have Anskiy as witness that I made these test before and not deluded. Only thing that I could think of that could lead to significantly different result is significant change in the code of script of the mod in last 3 months when I discovered Slinger's More Stuff mod that used to slower than mine now become faster than mine so I learned to use call function to skip code section and implement in the script of the mod extensively after it demonstrate result in newer versions.
3) I think using Call function to skip the code is overall more efficient coding than using overarching IF bracket that I use earlier in all versions I tested. But I think code from version 1.5.3 onward is much more sensitive to multiple layer and number of IF than earlier version (earlier version also sensitive to this but newer version more sensitive to this issue than older one).

Conclusion:
- Turn off range checking and enable code optimization in the compiler definitely make end turn progress faster.
- Method of coding script has more influence in end turn length in newer version than older one. Version 1.5.3 is more sensitive to multi-level of IF than version 1.5.2.
- Reversed condition Call to skip the script is more efficient than use overarching IF condition in all versions with version 1.5.3 and newer version more sensitive to this issue than older version such as 1.5.2.

[Seravy]

Reuploaded the 1.5.6 version zip file as there was a crash bug in the update. It should also contain the above optimization update.

[Suppanut]

Reuploaded the 1.5.6 version zip file as there was a crash bug in the update. It should also contain the above optimization update.

Thank you. I will test immediately once I back to my home.

I have some question. If cut range check and optimization of script make result better game speed, Why you did not do it in the first place? What is purpose of range check? And what is bad thing coming with optimization?

[Seravy]

What is purpose of range check? And what is bad thing coming with optimization?

If range check is on, the game stops with an error whenever an array index is out of range. If that happens while I run the game in the compiler with debug mode on, it tells me which line caused the error.
If range check is off, it'll just do the invalid read/write which will either crash with a general protection error or, if the address is valid, it'll just read/write the data anyway, in case of the latter, leading to data corruption. For example if I try to write into wizard 17's gold, the wizard array is only 14 long so whatever is afterwards for example city data, will be overwritten instead.

Speaking of which this also applies to scripts doing these reads or writes so if your script does anything that writes data for cities, wizards, etc and uses an invalid index, it might cause data corruption instead of a crash from now on.
(If that becomes too much of a problem, maybe it's a good idea to recompile specifically the parts for script commands that write data to have range checking enabled while the rest of the code does not, or add checking for the validity of script parameters into the script engine)

Turning off optimization allows the debug mode to report where a crash happens exactly and do things like executing the code one line at a time, with optimization enabled, some lines of code became untrackable in the debug system as they are merged together into optimized code.

It's usually not worth turning off range checking except in critical bottleneck parts of the code that use like 90% of the total processing time.

[Suppanut]

What is purpose of range check? And what is bad thing coming with optimization?

If range check is on, the game stops with an error whenever an array index is out of range. If that happens while I run the game in the compiler with debug mode on, it tells me which line caused the error.
If range check is off, it'll just do the invalid read/write which will either crash with a general protection error or, if the address is valid, it'll just read/write the data anyway, in case of the latter, leading to data corruption. For example if I try to write into wizard 17's gold, the wizard array is only 14 long so whatever is afterwards for example city data, will be overwritten instead.

Speaking of which this also applies to scripts doing these reads or writes so if your script does anything that writes data for cities, wizards, etc and uses an invalid index, it might cause data corruption instead of a crash from now on.
(If that becomes too much of a problem, maybe it's a good idea to recompile specifically the parts for script commands that write data to have range checking enabled while the rest of the code does not, or add checking for the validity of script parameters into the script engine)

Turning off optimization allows the debug mode to report where a crash happens exactly and do things like executing the code one line at a time, with optimization enabled, some lines of code became untrackable in the debug system as they are merged together into optimized code.

It's usually not worth turning off range checking except in critical bottleneck parts of the code that use like 90% of the total processing time.

Thank you for enlighten me. Would this be better if this feature able to turn on or off? I definitely see usefulness of both feature in debugging script for modder but not useful for those who do casual playing or livestreaming that require fast pace and engagement. (last night I try to make some call function usage in AI customwizard script but it does not show error so I could not figure it out where I do it wrong and I don't know at that time that it nolonger show error on optimized version)

If it is not possible then perhaps you could release both versions, normal update for casual playing and another version for modder that only release when new feature or major change occur for debugging script?

[Seravy]

Compiling the file in a way that range checking is specifically enabled only for the part that executes script commands that write data is definitely a better solution than two exe files.
Alternately, adding manual range checking into the source code directly and making the script engine display a script error that shows the exact problem is even better albeit slightly more time consuming.

[Seravy]

Also, one more thing : the easiest way to make scripts faster would be to convert parts that would use loops into a single command that handles those loops internally.
For example instead of the script checking every single unit to find which one is on a specific position, a script command doing that.
Problem is, it's impossible to have a generic purpose solution for these so I'd need to know exactly which of these would be used most often and slow down the script code the most so I can specifically add  a command for that.

An existing example of this is CITYONETILE() which is probably at least 100 times faster than a script loop checking the coordinates of every city for a match.

I think using Call function to skip the code is overall more efficient coding than using overarching IF bracket that I use earlier in all versions I tested.

This is 100% true, the position of labels are pre-calculated and jumping to them takes no additional time.
Meanwhile IF, THEN, FOR etc search for the appropriate } or NEXT etc by reading the script one character at a time until they find it.

[Suppanut]

Also, one more thing : the easiest way to make scripts faster would be to convert parts that would use loops into a single command that handles those loops internally.
For example instead of the script checking every single unit to find which one is on a specific position, a script command doing that.
Problem is, it's impossible to have a generic purpose solution for these so I'd need to know exactly which of these would be used most often and slow down the script code the most so I can specifically add  a command for that.

An existing example of this is CITYONETILE() which is probably at least 100 times faster than a script loop checking the coordinates of every city for a match.

I think using Call function to skip the code is overall more efficient coding than using overarching IF bracket that I use earlier in all versions I tested.

This is 100% true, the position of labels are pre-calculated and jumping to them takes no additional time.
Meanwhile IF, THEN, FOR etc search for the appropriate } or NEXT etc by reading the script one character at a time until they find it.

Thank you.

[Suppanut]

Also, one more thing : the easiest way to make scripts faster would be to convert parts that would use loops into a single command that handles those loops internally.
For example instead of the script checking every single unit to find which one is on a specific position, a script command doing that.
Problem is, it's impossible to have a generic purpose solution for these so I'd need to know exactly which of these would be used most often and slow down the script code the most so I can specifically add  a command for that.

An existing example of this is CITYONETILE() which is probably at least 100 times faster than a script loop checking the coordinates of every city for a match.

I think using Call function to skip the code is overall more efficient coding than using overarching IF bracket that I use earlier in all versions I tested.

This is 100% true, the position of labels are pre-calculated and jumping to them takes no additional time.
Meanwhile IF, THEN, FOR etc search for the appropriate } or NEXT etc by reading the script one character at a time until they find it.

So less THEN is better? Is this mean that I should combine several IF by using %AND or %OR into single THEN? From my experience, it works with unitcalc.cas and unitcalcpre.cas (less IF is better there) but is not working with other scripts at all (longer condition end up make script slower). Is there any explanation about situation that which is better?