Some API extension ideas

[Alberth]

If people don't like a GS that automate too much things or do bad/good things, people will just not use it, it's like the cheat function provide by openttd. Some use it, and some don't.

You're thinking too much single player. In multi-player, if some use a script to automate play, they have such a large advantage that playing against them is no fun any more. Then using/not using is not a choice, you must use it, or you're doomed.

In my view, that would be the end of multi-player.

[fabca2]

if some use a script to automate play, they have such a large advantage that playing against them is no fun any more.

What does force a GS to give advantage to only one player ?
I mean, let's imagine a GS that accept commands (from signs dropped by player) for example to copy train to another railtype, I think there are nothing that block GS to perform such action on any company number (for any player).

Or maybe I didn't understood the point?

In my view, that would be the end of multi-player.

This is a real question : aren't every player subject to same script ? if a script runs on server, does he have more privilege on company 0 ?

[Alberth]

It's pretty trivial to treat a certain company different than another one (or all others), and it is hard to see from the outside. To know for sure, you need access to the actual source code of the script, and check it.
Thus even today, you can write such scripts, the only protection against it is that users trust the server owner not to do these things.

However, the complaint was that the current room is not enough, and it should be made possible to do more actions, even if you could cheat with them, under the assumption that a player has free choice whether or not to use them.
I just pointed out that such free choice doesn't exist in a multi-player environment if there are no barriers against such abuse, for example by limiting the allowed actions.

[MinchinWeb]

Is it possible to log certain GameScript actions, perhaps somewhere in the savegame file? Thus, if you're worried about the server's GS giving your opponent tones of money, or that the GameScript is randomly stopping your trucks, you could review the log. This wouldn't necessarily eliminate all abuses, but at least they wouldn't happen in the dark.

[krinn]

I just pointed out that such free choice doesn't exist in a multi-player environment if there are no barriers against such abuse, for example by limiting the allowed actions.

Let's see multiplayer (something i never tried, so my thinking about it are speculations) :

- If the clients must have the same GS as the server : they have access to the source and shouldn't join a server with such GS if they don't like it.
- If the clients don't need it (i think it's the issue there), this time, yes, a server owner can alter a GS to cheat for "the company that do this or that only" (note that this is already the case with GSCompany.ChangeBankBalance). There's nothing clients could do about it, they have access to the unmodified source only this time or even not access to it.

There's three ways to solve this :
1 - The basic one is just do nothing : the server owner have a GS that can do it, and clients are playing a flaw game, but a server owner doing that if catch, will get flame and blacklist, so it's not what i think a server owner should do.

2 - Force clients to have same MD5 GS the server GS use, even they don't run it. I'm pretty sure it's a need for newGRF already. If client MD5 GS don't match server MD5 GS, block login.
It could be problematic for non open source GS, as server then couldn't play a closed source GS without providing them to anyone. Something i don't care personnaly.

3 - Disallow or log certain GS actions as MachinWeb suggest : disable some actions will prevent a server running a "non cheat" GS that use special API. And log in savegame can huge the savegame for an action that might just not be in use to cheat.

I think option 2 is easy to add and will do the job fine.
Right now, i think option 1 is the current state, and clients plays on server that might run a know GS in a modified version they aren't aware of, so allowing more API to GS won't change anything to this. Only option 2/3 may correct it.

[Aphid]

Class extension for GSEvent:

GSEventSettingChanged

- this event is fired whenever the server changes one of the gameScript settings.
- It contains the following values:

OldValue: Previous value of the setting
NewValue: New value of the setting

GetOldValue() gets the first listed value,
GetNewValue() gets the second.

What would this method be useful for? Suppose we have an AI or script that uses a library and which wants to change some of the library's settings based on GS settings. In order to allow SETTING_INGAME flag to work properly, with the current implementation we need to continuously check whether the user changed the setting and forward this to the library. I propose this event to eliminate some unnecessary calls.

[krinn]

Better clear up your mind, as i don't really see the improvment there ?

It would be improvement if events breaks AI execution flow, but that's not how events are handle.

Your current checksettings function, like your current checkevent function must wait until execution flow reach them.
Nothing prevent you from checking event and settings inside the same function if you prefer handle it as "event".

edit: i think i got it, it's only to remove need to check current settings != the one in use ?

[R2dical]

Is there no way to detect a river, like it is not "sea", without maybe a height check too?

I see Krinn wrote a patch (FS#5377), was that not included for some reason?

[R2dical]

Made a patch of Krinns work for the IsRiver function to current trunk.

---

Also, as it seems some marine infrastructure is "common property" (everyone can destroy/rename/etc), case in point being buoys, I would think AI/GS would need to get a list each time you wanted to interact rather than assume a stored tile list is always valid. Is there a better way to do this than searching every tile in the map? Maybe worthwhile to write a AIGetBuoyList(or locks, etc) function for the API?

[frosch]

Canals are not common property by default. They are like roads: They are owned by the company who builds them, and become common property when the company bankrupts.

Buoys are "owned" by those companies, who use the buoy in any of their ship orders. You can only remove a buoy, if you are the only company using it.

Wrt. a list of buoys: Buoys are waypoints, you get them via AI/GSWaypointList.

Wrt. IsRiver(): What is its purpose?
Currently the API has two methods:
* AI/GSTile::IsWater: Checks for sea, canal or river.
* AI/GSMarine::IsCanalTile: Checks for company constructable stuff.
What is the use case for distinguishing river and sea?

[R2dical]

Wrt. a list of buoys: Buoys are waypoints, you get them via AI/GSWaypointList.

Thanks, yeah after so much time going through the API docs I somehow missed this and only saw its reference when poking through the OpenTTD source (I amended my post in the Dev thread too).

What is the use case for distinguishing river and sea?

The case I currently have is with pathfinding for ships, a simple !AI/GSTile::IsWater cost addition (to differentiate land and sea) frequently results in a path going up a river (as my pathfinder accounts for "landscaping" and canals while building graph). So the need is find ONLY sea tiles, no rivers or canals.

Currently I use "(AITile.IsWaterTile(tile) && (AITile.GetMinHeight(tile) > 0)" for IsRiver cost but in the situation where a river is at height 0, sea level is > 0 or if "lakes" are present at different height to "sea" (therefore no way to hardcode "sea height") there would be no way for an AI to tell a river from sea. I am not sure if these scenarios are possible or not in terragen or custom though...

[krinn]

Made that patch because you cannot deal with river as river and water doesn't work the same :

River : Must and can be clear. Cannot raise/lower corners. 100% chance of success
Water : Can be clear but you are wasting huge money. You can lower/raise corners. Chance of sucess depend on adjacent tiles state.

- So in order to know cost to clear an area that include water, you must know each tile cost to clear, but if your area with water isn't a river, you get a too low result as you must include raise/lower costs, without any warrant you would success.
- Raise/lower corners works in testmode, but clearing tile doesn't :
- An invalid path because a tile is water and adjacent tiles prevent terraforming, is just a valid path if those water tiles are river, as you clear the river tile and replace it with your road.
- Jumping a water tile == a minimal size of 3 tiles for a bridge, a river = just a road
- BT_CLEAR_RIVER is there to answer the cost to clear a tile with a river, allowing dev to calc total cost to clear an area. Without handling river, there's no need to get cost to clear a water, as the water tile itself is always clear. Hence why no BT_CLEAR_WATER exists. But you just have to query a water tile to see there's a cost to clear a water tile
So clearing a water is stupid, it do nothing, except take your money, but clearing a water tile is the way to remove a river.


When dealing with water/river the amount of money put on the table is not something you could just play with. You must be able to take decision before going into such investments.
So that's why i create IsRiverTile. You might goes into a bunch of tricky tests to determine if a tile is water or river (looking at height, looking at size of area >3)... But none are 100% perfect, and worst, add complexity to functions that per themselves are time earter already (pathfinding and terraforming)

[hpfx]

Hello,
I don't know if my request can be candidate to game script extension...
I would like to be able to lock/unlock a town for a company.

It's quite common in GS to have claimed town, but once claimed it's not easy (and ressource consuming) to check if other players are placing station/HQ...
In ottd code something already exists to "lock" a town for a company : yes, you know when you have this "town authorities refuse..." well known message...
The idea is just to be allow GS to enable this "refusing" (without altering company rating)

It would simplify a lot of script, and make them more reliable. (script does not avoid user to place the station, it can just detect it once placed... at the price a endless and heavy checking...)

GSTown::DisallowCompany(GSCompany::CompanyID company, TownID town)
GSTown::ReAllowCompany(GSCompany::CompanyID company, TownID town)
GSTown::isDisallowedCompany(GSCompany::CompanyID company, TownID town)

Please let me know your feeling.
Thank you.

[planetmaker]

It's quite common in GS to have claimed town, but once claimed it's not easy (and ressource consuming) to check if other players are placing station/HQ...
In ottd code something already exists to "lock" a town for a company : yes, you know when you have this "town authorities refuse..." well known message...
The idea is just to be allow GS to enable this "refusing" (without altering company rating)

The current "lock" actually does work exactly via the company rating for building stations or demolishing town property. I guess it would not be too hard to introduce another variable which can only be set by a game script which is also checked in the same places as currently the town rating - though wouldn't it make more sense to then rather give access (read / write) to the town rating to the GS instead of introducing another variable? It could then fix the town rating in a town for one company to "like" and to "hate" for all other companies.

I'm +0.5 on this and would not mind either approach.

[hpfx]

wouldn't it make more sense to then rather give access (read / write) to the town rating to the GS instead of introducing another variable?

That would be great,
but we have to keep in mind that towns will alter the rating over time, GS will have to refresh "hated" companies.

Or maybe adding a method to stop built-in town rating (like you did for towngrowing) that would add possibility to GS authors to manage town rating themselve ?


whatever the approach, I would be happy.
Best Regards.

[Alberth]

I am not convinced towns are sufficient. Instead I'd like to propose areas (collections of tiles) where you attach access rights to.

[krinn]

Better think twice before going that way :

1/ Allow GS to alter town rating.
Fine, but AI or player may re-alter it as they wish thru bribing and planting.
2/ Allow GS to use a new var to state ro or rw a company in a town.
Fine, but AI (i suppose human player will get a fine error message) need to know that state, else they will goes into the "let fix my rating there" function for nothing.

So if you really want a new API to be able to blacklist a company, you must also add new API to AI to know that state.

And if you want option 1/ Just allow GS to handle level of rating in a town, you may just don't need any new API function for that, GS can switch to any company and remove trees itself to make that company rating goes to hate. And GS can even gives back the money the GS took from the company to accomplish that task (if you care about fairness as the most loved company will pay the most to goes down to hate). So implementing 1/ doesn't even need new API function.

I think 1/ is useless, 2/ need AI API update but if you goes with 2/ do it Alberth's way. So AI will knows tiles could be reserved by GS/openttd but it will also allow greater improvement (as GS can now even reserved industry tiles, allowing industry to only be use by company X or Y)

edit: just to emphasis, it's not as easy to implement, per example AITile.IsBuildable should check the tile/town state and return result depending on it too. Many AI functions should be update to handle it.

[fabca2]

Hi,

And if you want option 1/ Just allow GS to handle level of rating in a town, you may just don't need any new API function for that, GS can switch to any company and remove trees itself to make that company rating goes to hate.

This is just a trick. If you want "option 1/", you can not just offer a trick.
There is a difference with giving an API function for that stuff, with a function you know that rate have been changed. your trick is not reliable : are your sure you find enough tree to destoy to change rating ? In the case of claimed town, you have to change rating of many company, will you have enough tree for each companies... each months ?
Globally, do you find it's a nice way to work to continuously destroy tree to ensure the bad rating ? the answer is no, the fact is : no script perform such action.

2/ Allow GS to use a new var to state ro or rw a company in a town.
Fine, but AI (i suppose human player will get a fine error message) need to know that state, else they will goes into the "let fix my rating there" function for nothing.

I agree, but I think that AI will also get the state when trying to build (like for human player). on calling AIRail::BuildRailStation(...) an exception can be raised for such a case... or something like that.

I am not convinced towns are sufficient. Instead I'd like to propose areas (collections of tiles) where you attach access rights to.

Nice idea, it would provide interresting improvment.
not instead but in addition of town reservation idea (to avoid managing tiles on town expension).
we could have two set of api function for :
- managing collections of tiles, great to have fine tunnig (like krinn said to allow a given industry of a company only)
- managing town (dis)allow, fine to manage town without need to manage variation of town influence area.

As krinn, I would prefer api function to allow or not tiles/towns instead of modifying town rating.

[planetmaker]

I am not convinced towns are sufficient. Instead I'd like to propose areas (collections of tiles) where you attach access rights to.

Nice idea, it would provide interresting improvment.
not instead but in addition of town reservation idea (to avoid managing tiles on town expension).
we could have two set of api function for :
- managing collections of tiles, great to have fine tunnig (like krinn said to allow a given industry of a company only)
- managing town (dis)allow, fine to manage town without need to manage variation of town influence area.

As krinn, I would prefer api function to allow or not tiles/towns instead of modifying town rating.

If these "tile areas" or, as I prefer to call them, regions are not the same as the areas of a local authorities, this introduces a new concept. This is not necessarily bad, but it definitely needs some more thinking about it - especially on how to define and distinguish these regions. That said, such concept could offer many more interesting use cases, like regional-based use of town layouts, house NewGRFs, landscape look, industry placement etc.

[Alberth]

I am not convinced towns are sufficient. Instead I'd like to propose areas (collections of tiles) where you attach access rights to.

Nice idea, it would provide interresting improvment.
not instead but in addition of town reservation idea (to avoid managing tiles on town expension).

Who says a city cannot be limited to a tile area? (not sure if it's a good idea, but it'd eliminate your managing tiles problem ).