NoGo - A Scriptable Game Framework - v1.5

[Xaroth]

You already got my kudos on IRC, but to re-state:


<3 <3 <3 <3 <3 <3 <3 <3

[TrueBrain]

wait... no XML?!?

Haha, no. Rather: hell no

http://www.json.org/

Clear state diagram ftw. No confusion. No misunderstanding. 'Strong' typed. f*** XML

[ChillCore]

It's disturbing to me that newGRF seems to be considered holy for some reason. Sure there are already quite a bunch of newGRFs out there and it runs faster then a script (depends on how things are treated, though).

But drawing a line? I don't see a point in that other then obstructing (possible future) innovation.

If this line gets drawn, chances are there will be forks in the future or the line gets moved again and again.

OpenTTD is a great game. Whether the mods are written using NFO or squirrel, I don't care.

You cannot have 2 separated systems do identical things. There will be conflicts between data if you do, which have to be resolved. Resolving such conflicts is hard, if not impossible. This will in the end work against you, and so a line is needed. The line will also constantly move, and as everything evolves, it might even jump from time to time.

To state the obvious, I agree that a line needs to be drawn somewhere to avoid conflicts.

IMHO, from my, very limited in regards of NewGRF, point of view:
NoGo should override town growth without a doubt ... everything else, eg. acceptance of goods by houses and industry production levels, is up to the NewGRF authors.

EDIT:
Which does not mean that there could not be a goal like eg. boost all industry production levels above level x.



Also as this is my first post in this thread ... /me is looking forward to this addition in trunk very, very much.

[XeryusTC]

It's disturbing to me that newGRF seems to be considered holy for some reason. Sure there are already quite a bunch of newGRFs out there and it runs faster then a script (depends on how things are treated, though).

But drawing a line? I don't see a point in that other then obstructing (possible future) innovation.

If this line gets drawn, chances are there will be forks in the future or the line gets moved again and again.

OpenTTD is a great game. Whether the mods are written using NFO or squirrel, I don't care.

You cannot have 2 separated systems do identical things. There will be conflicts between data if you do, which have to be resolved. Resolving such conflicts is hard, if not impossible. This will in the end work against you, and so a line is needed. The line will also constantly move, and as everything evolves, it might even jump from time to time.

To state the obvious, I agree that a line needs to be drawn somewhere to avoid conflicts.

IMHO, from my, very limited in regards of NewGRF, point of view:
NoGo should override town growth without a doubt ... everything else, eg. acceptance of goods by houses and industry production levels, is up to the NewGRF authors.

But what happens if a game script says that you need to deliver goods to a town when it reaches X population but the town newgrf doesn't have any buildings which accept goods by then. What happens then?

[ChillCore]

But what happens if a game script says that you need to deliver goods to a town when it reaches X population but the town newgrf doesn't have any buildings which accept goods by then. What happens then?

Why would a GRF do that? That would be stupid no? (*)
Towns have more than one cargo type they react to (mail, passengers) and even if that type is changed to something else sometimes by GRF, (eg. FIRS requiring petrol and ECS something else in Toyland) there is still an acceptance of the new type of cargo, although OpenTTD still counts it as "goods".

IMHO, if one does prevent acceptance of everything at some point, that then that GRF is "kaka" and you should really play with another one as that one would be a major game breaker.


(*) I have also changed "my" version of the town growth patch to never drop below 1% growth for exactly this reason -> read: for very small towns to still be able to grow until they do accept all requirements.

[andythenorth]

But what happens if a game script says that you need to deliver goods to a town when it reaches X population but the town newgrf doesn't have any buildings which accept goods by then. What happens then?

You learn that it was a bad choice of newgrf

I can't discover many newgrf properties or callbacks that it would be safe for NoGo to have access to. Newgrfs need to be a closed box to NoGo; there are far too many easily triggered unintended consequences if NoGo scripts are allowed to directly adjust newgrf.

However it's quite easy to think of ways for NoGo and newgrfs to co-operate, via existing frameworks, or those that might be added (town control).

A NoGo script needs to be either very generic, so it will work with a wide range of newgrfs, or very tightly bound to a specific set of newgrfs (even to specific newgrf versions).

FWIW I had lots of ideas for interesting ways to allow NoGo to modify newgrfs, but it was quite easy to show they had problems

[Hyronymus]

But what happens if a game script says that you need to deliver goods to a town when it reaches X population but the town newgrf doesn't have any buildings which accept goods by then. What happens then?

Good one. Perhaps a validity check for town buildings accepting cargo types being available before offering the goal?

EDIT: @andy
Specific may be cool but you don't want multiple versions of NoGo, that'll confuse people. A "NoGo plugin" or "NoGo Modmod" might be far more interesting and efficient: you downlaod the plugin for the proper NewGRF and that plugin overrides/changes only the necessairy parts of the default NoGo framework.

[Eddi]

But what happens if a game script says that you need to deliver goods to a town when it reaches X population but the town newgrf doesn't have any buildings which accept goods by then. What happens then?

the same thing that happens right now e.g. when you play the alpine climate grf. the towns need food above snow line, but there is no food cargo. tough luck getting towns above snowline to grow at all. (pro tip: try the "fund new buildings" option in the town window, it overrides the food/water requirements)

[ChillCore]

EDIT: @andy
Specific may be cool but you don't want multiple versions of NoGo, that'll confuse people. A "NoGo plugin" or "NoGo Modmod" might be far more interesting and efficient: you downlaod the plugin for the proper NewGRF and that plugin overrides/changes only the necessairy parts of the default NoGo framework.

Not sure if you are aware of this but ... you (or anyone else) will be (are already) able to write your own script ... exactly in the same way you can write an AI.
There can and will be as many different script as people are willing to write.
NoGo will only provide the hooks just like NoAi does already for AIs.

[TrueBrain]

To dance or not to dance:

Code: Select all

	{
		local company = GSCompanyMode(0);
		GSSign.BuildSign(GSTown.GetLocation(1), "Test Test");
	}

	GSSign.BuildSign(GSTown.GetLocation(2), "Test Test");

tralalalaaaaa!

(for some reason I have a feeling this will be abused more than used for good; but time will tell if this was the worst mistake thinkable, or the best thing ever )

[Eddi]

this is probably really evil, but to mimic the original tutorials, moving the mouse cursor to an interface element (e.g. "rail construction"-button) would be needed.

[Zuu]

One could include a bit field with flags for some extended authority that a GS can have. Executing actions as player could be one of those. An other way would have a script type property: "Goal script", "Observer script", "Tutorial" etc. with different permissions.

[Expresso]

Perhaps some things on the edge of what the purpose is of GS, but here are some suggestions for GS.

1) phoenix areas, when certain conditions are met.
2) production cap of local industries dependent on town size.
3) (in combination with some cargodest patch) increase the likelyhood of certain cargoes wanting to go somewhere... or decrease the likelyhood.
4) alternative growth patterns for towns.
5) maintenance and/or construction costs dependent on the local authorities.

[TrueBrain]

Today a new version of NoGo. I am starting to run out of easy things to do here A changelog since last release:

- Communication (bi-directional) with AdminPort. For that 2 new packets are created, both called GAMESCRIPT, on Receive, on Send. In Squirrel you can send via SQAdmin::Send, and receive via the ADMINPORT Event. See a post above for more information
- Get a vehiclelist of every company in the game, or from 1 specific company
- Build on behalf of a company (with great power comes great responsibility!), by create an instance of GSCompanyMode(<value>) in a scope. It works identical to TestMode and ExecMode, only it changes the current company.
- Open up 90% of the AI API for GS too. The only exceptions atm are setting companyname, presidentname, and looks of the president, as well as all Group related settings, and changing autorenew settings. To me it feels like a GS should never be touching those things. But I can be convinced to open them up too, if you can give me a good reason to

Other stuff includes some stability fixes, comply with OpenTTD coding style, and some better refactoring (there is no include of any AI file in the script/* files no, which means the refactoring is 100% done, and ScriptEngine no longer depend on the AI (but the AI does depend on the ScriptEngine).

It is now possible to make a Tutorial, although it is still hard to communicate with the client.

[Kogut]

- Get a vehiclelist of every company in the game, or from 1 specific company

Is it possible to include this in NoAI API?

[TrueBrain]

All NoAI actions are restricted to their own company only. This is unlikely to change, and for sure outside the scope of NoGo Sorry

[andythenorth]

2) production cap of local industries dependent on town size.

This is desirable functionality. Two ways it could be achieved:
1. allow GS to modify ottd behaviour when handling the production change callbacks (29 and 35). This will work for any industry newgrf that (a) uses those callbacks and (b) allows the game to control the production change (i.e. returning 04h to the cb). It may also work for default industries. It wouldn't work for most of FIRS, probably not ECS either from what I know of ECS.
2. store values on the registers for the town. The industry newgrf would then control production, but would pay attention to the register values. There has been some discussion of this on irc. By agreeing conventions on which registers and values to use, industry newgrfs could offer predictable behaviour with GS. It would need quite a lot of agreement.

It won't work to allow GS to modify production multiplier directly on an industry. This would likely conflict with what the newgrf does and cause problems (examples could include: incorrect text information on industries; unexpected industry behaviour such as closure, or refusal to accept / produce cargos, or unexpected consumption or non-consumption of inputs).

Basically there needs to be a clean API between GS and items controlled by newgrf, and in many cases existing frameworks can provide that (like cb handlers or subsidies); or town control (work in progress) can provide it, with some conventions needed.

4) alternative growth patterns for towns.

This is also desirable. If GS could modify the town zones on demand, that would be one way to provide some control. Using registers to communicate with house newgrf is another. Controlling the building of street grids, and the demolition / construction of buildings might also offer some possibilities.

cheers,

Andy

[Expresso]

What I'm a bit concerned about is performance impact. On a small map it won't be much of a problem... but what will be/can be the impact of GS on a large map late game?

[TrueBrain]

Nothing more (or less) than an AI can do. The GS is, like the AI, restricted in an amount of opcodes it can perform every tick. So it will be almost the same (load-wise) in the begin as at the end of a game, with a small or a large map. I even think you will hardly notice that it is active tbh.

So performance wise is, as far as I know a non-issue. I am sure the future will tell, and as always: you can always opt-in to not pick a GS

[Eddi]

All NoAI actions are restricted to their own company only. This is unlikely to change, and for sure outside the scope of NoGo Sorry

i disagree with this decision, since it's a deviation from "AI can see everything that a player can see", because players can get vehicle and station lists for each company.

this is kind of an elementary feature to get AIs, especially two companies of the same kind of AI, to not interfere with each other as much, if they could factor in "there is already another company with this route" or "there are already 3 companies at this industry" into their decision whether to start servicing an area.