FS#5934 - Game script - Town growth, transport service condition

Attached to Project: OpenTTD
Opened by Jan Skoch (The_Dude) - Sunday, 02 March 2014, 21:02 GMT
Last edited by andythenorth (andythenorth) - Thursday, 31 August 2017, 19:02 GMT
Type Feature Request
Category Script → Goal/Game script
Status With patch
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 1.4.0-beta5
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


I am trying to implement new GS features to my Simple City Builder script, and I get into one small trouble.

Script influences town in such way, that they need to be supplied to grow houses. I added new growth mechanism, that uses new features of setting town growth as TOWN_GROWTH_NORMAL when town is supplied and TOWN_GROWTH_NONE when not. This all works fine,
but when town has enough resources and is not serviced, the town will not grow, but the GS will think it grows, because town was supplied.

Since GS cant recognize, that the town has no transport service, it gives the user invalid information about town growth in that case. That is when town gui says correctly the town is not growing, but GS will say in goal gui the town is growing (even if I omit the growing line, the user can still be confused, if he sees the deliveries).

How it would be possible to implement some new GS feature?

Either gather the service information directly in town_cmd.cmd in
static void UpdateTownGrowRate(Town *t)
and send it to GS, like GSTown.HasService(townid),

or make some GSStation function to retrieve struct Station properties :
byte time_since_load
byte time_since_unload
, which would make it possible to decide the service status in GS.

The latter could be also useful for other interesting scripts too.
This task depends upon

Comment by Jan Skoch (The_Dude) - Monday, 03 March 2014, 20:07 GMT
Eddi was so kind to suggest a simple solution, I am posting it hereby.
It would indeed provide the information of town actually not growing to GS.
Comment by Leif Linse (Zuu) - Sunday, 09 March 2014, 12:11 GMT
While this change is possible useful for you, it will break other scripts that rely on the old behaviour. (API returning the growth rate even when the goals are not met)

With the many different town growth scripts available, it is hard to know if you break any script or not with this change. Maybe you can provide a new API with the wanted behaviour and update the Doxygen comments to clarify the difference between GetGrowthRate and GetCurrentGrowthRate or similar.

Edit: The new API should be added to game_changelog.hpp and ai_changelog.hpp
Comment by frosch (frosch) - Sunday, 09 March 2014, 12:32 GMT
I don't think just exposing TOWN_IS_GROWING is a good idea. I mean you would need like 3 pages of text to explain when it is set, and when it is not set. And when it is set when you do not expect it to be set, and when it is not set when you would expect it to be set.

Better start with defining what the function should really check and what not, instead of exposing some magic bit.
Comment by Jan Skoch (The_Dude) - Monday, 10 March 2014, 19:24 GMT
Zuu is right, I do realize weakness of that too simple patch.

One way could be to pass second optional argument return the days period value only when town is growing, but new function is probably cleaner.

Check included patch. It returns the boolean value depending on TOWN_IS_GROWING. Since TOWN_IS_GROWING bit is really always set when town is growing in any way possible, I do not see reason, why not to expose it. You could check for the exactly same fix as are already being checked elsewhere on the path, but what would be purpose of double checks.
I added comments to possible ways how TOWN_IS_GROWING is set, but I think it is not imporant info for script writers. When I am writing a script, I dont care for exact proccess behind the functions.

I have not added the function for AI in this patch yet, but you get the idea.
Comment by frosch (frosch) - Monday, 10 March 2014, 20:15 GMT
The issue with TOWN_IS_GROWING is, that it also is affected by funding houses and a 1/12 chance.
I think you rather only want to check the normal growth conditions.
Comment by Jan Skoch (The_Dude) - Monday, 10 March 2014, 21:03 GMT
Sure, but it still gives accurate information, that town is or is not growing.
That is the reason and the need of the new function.
Comment by Jan Skoch (The_Dude) - Monday, 10 March 2014, 21:44 GMT
Comment by Leif Linse (Zuu) - Monday, 10 March 2014, 23:31 GMT
Some notes on the patch:
- In your doxygen comment you have something that looks like you intended to have a bullet list there. In order for the HTML output to show up as a list, you need to follow the Doxygen syntax for bullet lists, otherwise it will probably even ignore your manual line breaks.
- Items in the changelog is sorted alphabetically - not by date within the same version.
- "more of this conditions" => "more of these conditions" (change "this" to "these")
- In the API documentation, you should not refer to internal ENUM constants which are not exposed in the API. For example TOWN_GROW_RATE_CUSTOM is not exposed in the API. Use descriptions that relate to what is exposed to API users or use plain English if you need to refer to internal logic not exposed in the API. It is better here to refer to existing APIs for how a GS set growth rate. This will make the references clickable and improve understanding of the API.

This line in your patch will not compile:
+ static bool ScriptTown::IsTownGrowing(TownID town_id)
Comment by Jan Skoch (The_Dude) - Tuesday, 11 March 2014, 17:23 GMT
Thanks for review. At this stage I was more interested into developers opinion on implementing that new function.

Semanthic check is not that important now. Give me some sign of approval and I can make working patch with squirrel templates, etc.

I think some API for getting real status of town growth can be useful for more script authors than me (as I tried to point out when using TOWN_GROWTH_NORMAL, in some conditions GS has no way to say that town is growing with 100% accuracy).