Moderator: OpenTTD Developers
- Fix: Saving during initialization could crash the script
- Fix: Pre-cache the town save data after each town management to avoid "save took too long". In my tests with 2048x2048 with 'high' town density, I do no longer encounter "save took too long".
- Add: Faster initialization of large maps with many towns (but 2048x2048
with 'high' amount of towns still takes more than the 2500 initialization
ticks in world gen)
- Add: Detect FS#5561 and postpone initialization of Story Book to after
world gen if user has an affected OpenTTD version.
On 2048x2048 with 'high' town amount, the script still often overshoot the initialization budget of 2500 ticks during setup (these ticks are more powerful than later in the game, so if you overshoot, you will likely get 10 000+ ticks for setup in total)
On 2048x2048 with 'medium' town density, the script seems to stay within budget.
On 2048x1024 with 'high' town density, the script seems to stay within budget.
Also note that I have so far only addressed initialization. If you play with stockpiles on, you will notice that the script will not manage to each town each month on 2048x2048 with 'high' town density. It may take several months between each time the script compares delivery since last check with the town demand for that period. The script tries to do this at least once in a month, but each town management currently executes one DoCommand for each town goal. If stockpiling is on, an additional DoCommand is needed to update the town text. If you have stockpiles disabled, then I don't think you will notice the performance issues that much other than town goals being a bit slow on updating.
A DoCommand is when the script changes something to the game that has to be propagated to all multiplayer clients. Both in multiplayer and singleplayer this causes the script to pause for the reminder of the current tick and not continue execution until next tick. Each day in OpenTTD is 74 ticks., So you can do the math on how many DoCommands that are available during a month.
During world generation, scripts can execute DoCommands for "free" (or rather, they cost no more than any other API call) So there it has 2500 * 10 000 opcodes without the DoCommand limitation that exists later in the running game.
Oh, sorry for the wall of text
I have tested the new version and I am not having any issues with saving any more, thank you for fixing it
The script on a 2048 x 2048 map with "normal" towns took just 1181 ticks this time.
I will have a proper game with it now to see if any other issues pop up, thanks again for your efforts Zuu.
Code: Select all
case GSGame.LT_ARCTIC: this.SetCargoGoal(GSCargo.TE_PASSENGERS, MaxAsInt(((population / 10) - 5) * factor, 1)); this.SetCargoGoal(GSCargo.TE_FOOD, MaxAsInt(((population / 20) - 5) * factor, 0)); this.SetCargoGoal(GSCargo.TE_MAIL, MaxAsInt(((population / 50) - 10) * factor, 0)); this.SetCargoGoal(GSCargo.TE_GOODS, MaxAsInt(((population / 100) - 200) * factor, 0)); break;
Code: Select all
case GSGame.LT_ARCTIC: this.SetCargoGoal(GSCargo.TE_PASSENGERS, MaxAsInt(((population / 10) - 5) * factor, 1)); this.SetCargoGoal(GSCargo.TE_FOOD, MaxAsInt(((population / 20) - 5) * factor, 0)); this.SetCargoGoal(GSCargo.TE_MAIL, MaxAsInt(((population / 50) - 10) * factor, 0)); this.SetCargoGoal(GSCargo.TE_GOODS, MaxAsInt(((population / 100) - 20) * factor, 0)); break;
It seems that script take into account only the first town effect cargo. When I use FIRS it do not take into account delivered goods at all. It takes petrol instead as it seems that petrol have goods town effect. Stockpiles at the same time displayed both petrol and goods. But goods do not go to stockpiles if delivered.Zuu wrote:FIRS and ECS should work as the script uses Town Effects. How well stockpiling works with multiple cargos per town effect is unknown to me.Kogut wrote:Description is not fitting into default-sized window for selecting GS. In readme default window width is a bit smaller than length of lines. It may be nice to mention whatever it is compatible with FIRS, ECS etc.
This script gets more interesting every version, thanks for the effords which are put in it to create it
While i absolutely think the stockpile option is great, i do have some concerns in matther of realism. I mean: stockpiling passengers and mail will surely not get you on the "best appreciated" list when you are running a transport company i guess
"Sure, Lets put all bodies (passengers) in this warehouse for a few months, that will get us to the goal for our company this month"
So, my question is: could you exclude some cargo's from the stockpile option? Or make it configurable by how many percentages you are able to store of the total cargo requirement?
There was a bug in version 12: When you found a town the script crashes.
This bug has now been fixed. Thanks to Djohaal on IRC for the report.
Took me a while to find NewGRF’s and scripts that I really like and NAI is certainly one of them. It works great in combination with FIRS, however I’m have troubles with ECS1.2. The 5 TE’s for stockpiling are wrong, making it harder to reach the growth goals. As shown in the picture bellow it stockpiles tourists and water in normal climate. Compared to FIRS I ‘m expecting Passengers, Goods and Petrol
The big question for me is; what am I doing wrong or is it a NAI bug?
- (420.33 KiB) Downloaded 9 times
From what I can see, the problem is that the stockpile implementation contributed to this script assumes that there is only at most one cargo for each town effect.Novex wrote:The big question for me is; what am I doing wrong or is it a NAI bug?
However with ESC, there can for example be two TE_PASSENGERS cargoes (passengers and tourists)
Eg. what you see can is a result of a limitation in NAI.
I've added this script to eints web translator so that it will be easier for anyone who want to contribute a translation or update any of the existing translations.
- On ECS and other NewGRFs with multiple cargoes for TE_PASSENGERS, display in town window the cargo type that correspond to SuperLib.Helper.GetPAXCargo() - eg. the cargo that is most likely to be "passengers".
- Delivery of cargo is accounted for all cargoes with each town effect even if only one cargo is displayed in the stockpile info.
- In a new story page the full list of cargoes for each stockpile is displayed. This page is not added to existing games which already has the about story page. New games, and games saved with OpenTTD 1.3 (or other version without Story Book) will get this page.
- Language updates from eints (Swedish + German)
If you contribute new translations via eints - which you can do without anything more than general permissions to translate a language in eints - let me know in this thread if you like a new release with the translations.
A fixed release will come but I don't know yet how many days it may take.
Now I have finally been able to commit my changes and push them to the remote repository so that I can release a version without releasing something which will not correspond to the version control history.
The release contain some updates to English strings and translation updates as well as fixing the bug mentioned above.
The translation updates are made against the old English wordings (thanks to feedback from Alberth). Though most changes in the English strings are re wording for better flow in the English language. So I think it is fine to release now and then later make a new version when most translators have had time to review the updated strings. This way users get the bug fix and the translations that has been contributed so far.
In your game, open the settings menu (3:rd button form left in main toolbar) and then select AI/Game script settings. There select the game script and click on configure. In the settings dialog for Neighbours are important, you can now disable the master switch. Especially if you use 1.3 or older, you need to allow some time before town growth is restored to normal. In newer versions of OpenTTD the API has better support for this and thus it is quicker.
Changing the code so that you can turn off the goals (and stockpiling) completely and only have sign control is probably quite easy. However, it falls a bit outside the scope of this script. Sign control is there for users who want the cargo requirements and fine grained control and cannot run a general purpose sign control script at the same time.