[NoGo] Neighbours are important
Moderator: OpenTTD Developers
Re: [NoGo] Neighbours are important
Thanks for the fast response krinn
Re: [NoGo] Neighbours are important
Update - Version 12
Changes:
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
Changes:
- 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
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: [NoGo] Neighbours are important
Hi,
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.
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.
Re: [NoGo] Neighbours are important
It seems that in arctic climate there is too high lower limit of population (20k) to appear goods requirement for growth.
Should be (IMO as in tropic climate 2k):
Also goods requirement are hidden when they satisfied from stockpile. It would be nice if they are displayed all the time because this will show current town consumption of goods from stockpile.
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.
Re: [NoGo] Neighbours are important
As far as I know, in FIRS, there is only one type of cargo associated with "Goods". Petrol/Gasoline is associated with.... WATER! At least that's what debugging the GS shows.
Re: [NoGo] Neighbours are important
Hello
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?
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?
Re: [NoGo] Neighbours are important
Update - Version 13
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.
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.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: [NoGo] Neighbours are important
He guys, I finally joined this forum after reading a bunch of posts as guest. I’ve been spending hours and hours playing TTD en OpenTTD games. I’m not in it for passengers and mail, however I love too transport all kinds of goods and mostly by rail.
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?
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?
- Attachments
-
- NAI-ECS.png
- (420.33 KiB) Downloaded 9 times
Re: [NoGo] Neighbours are important
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.
Translators
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.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: [NoGo] Neighbours are important
Update - Version 14
Changes:
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.
Changes:
- 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.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: [NoGo] Neighbours are important
Hi, the readme_de was not UTF-8 encoded which let to "?"s when reading it in game.
Updated version attached.
Updated version attached.
- Attachments
-
- readme_de.txt
- (4.44 KiB) Downloaded 208 times
Re: [NoGo] Neighbours are important
I just tried this script, but it gave an error just after creating the map.
I have the FIRS industry set enabled, couldn't reproduce without that.
I have the FIRS industry set enabled, couldn't reproduce without that.
- Attachments
-
- error.png (24.9 KiB) Viewed 2535 times
Re: [NoGo] Neighbours are important
Thanks for your report. I think that I've found and fixed the bug. I assume that you do not use FIRS 1.3.0 in temperate but instead in some other climate or with custom parameters so that there is not any cargo for some town effect.
A fixed release will come but I don't know yet how many days it may take.
A fixed release will come but I don't know yet how many days it may take.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: [NoGo] Neighbours are important
Update - Version 15
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.
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.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: [NoGo] Neighbours are important
Sorry for dumb question, but can i disable this script in running game ?
Re: [NoGo] Neighbours are important
Edit. Deleted.
Last edited by keoz on 18 Jan 2014 12:40, edited 1 time in total.
Patch - Let's timetable depot waiting time with the Wait in depot patch.
GameScript - Searching a new way to make your cities growing ? Try the Renewed City Growth GameScript.
My screenshots thread.
GameScript - Searching a new way to make your cities growing ? Try the Renewed City Growth GameScript.
My screenshots thread.
Re: [NoGo] Neighbours are important
This script has a built-in setting called Master Switch to disable the script. When toggling this setting, the script will take care to restore the town growth settings to OpenTTD defaults. This is much better than trying to kill the script which will freeze the cargo goals as is rather than restoring to OpenTTD defaults.
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.
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.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
-
- Tycoon
- Posts: 2788
- Joined: 22 Feb 2011 18:34
Re: [NoGo] Neighbours are important
How difficult would it be to only have the sign control from this script without the rest of it? I just want to prevent my large towns from growing too large without having to supply all kinds of goods to towns to make them grow, as I mainly play PAX only games.
Coder of the Dutch Trackset | Development support for the Dutch Trainset | Coder of the 2cc TrainsInNML
Re: [NoGo] Neighbours are important
You can set cargo requirement difficulty to 1%. This gives quite low requirements. However, you can probably not set it to 0 % due to a constraint in the script.
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.
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.
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Who is online
Users browsing this forum: No registered users and 1 guest