News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Scripted scenarios

Started by Dwachs, January 11, 2012, 07:08:42 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dwachs

UPDATE: This is now merged into trunk, and it is available with latest nightly builds.

You will need to install scenario files from here:

https://github.com/downloads/Dwachs/simutrans/simutrans-scenarios-r5873.zip



I am working currently to enable scripted scenarios. The scripts are written in squirrel: www.squirrel-lang.org

What is implemented:
== a new info window for scenarios
== a templated interface to transfer values / call functions between C++ and squirrel, which allows for a relatively easy code to expose C++ methods to squirrel
== currently only functions that get values from simutrans into squirrel are exposed
== the standard pak64 scenarios are fully translated
== two new scenarios based on these threads are in the repository:

http://forum.simutrans.com/index.php?topic=8449.0
http://forum.simutrans.com/index.php?topic=7697.0

What needs to be implemented:
== more exporting: lines, goods routing connection information, etc
== translation of texts
== networking: enable multi-player scenarios such that players can compete to reach the goals
== networking: transfer script from server to client in case of scenario games
== improve scenario selection window to show short summary, diffucilty etc
== whatever potential scenario creators demand ...

Patch is at http://simutrans-germany.com/patches/download.php?file=5077-scenario-patch.diff

As it is a git patch, it needs to be applied with 'patch -p1'.

The git repository is:

https://github.com/Dwachs/simutrans , branch 'scripted'
Parsley, sage, rosemary, and maggikraut.

prissi

Great: When this is somehow stable, one really should think of an AI interface. That was really a huge success with OpenTDD.

Dwachs

Can we specify, what is needed for an AI interface? This is what comes to my mind
== query data from game
== interface to all call init/work for all tools (needs a separate method to send work-commands via network)
== parts of the way/bridge/tunnel builder interfaces to be able to create customized building routines
Parsley, sage, rosemary, and maggikraut.

prissi

I think you nailed it more or less. For the route builder, an AI needs to be able to query the calculated route and, if needed, to change or to extend it (i.e. for double way route). Thus is must need read access to the calculated route and the route builder must be able to be called by such a route (of course the AI could call the tools tilewise, but this seems very tedious).

I am not sure if really network support for such an AI is desired. Maybe just stop AIs when in networkmode.

TurfIt

Squirrel? .nut? oh my  :::)

Are you still looking for scenarios?
I've always liked the ones from Sindor in the old forum. The text is still there so you could see if the winning conditions could be handled by your new code.
Scenario: Highlander 1972
Scenario: Gold Rush 1900
Scenario: Japan 1946
Scenario: Northern express 1990-2005
Second scenario: Long march 88.01 & pak128
Scenario: Velvet Revolution 88.01 & pak 128
Last scenario: Odyssey 88.01 & pak 128 1.2.6
Unfortunately I can only find the saves for the first 3 in my archives.  ::'(
Let me know if you want them. I've tried the first relatively recently and it still works. Need to try the other two...

As for the AI, having one that could connect to a network game as a client would be great. i.e. The AI only runs on one computer and transmits its commands the same same as a regular player. This would allow for development of a really CPU intensive AI.

Dwachs

Quote from: TurfIt on January 11, 2012, 10:18:56 PM
Unfortunately I can only find the saves for the first 3 in my archives.  ::'(
Let me know if you want them.
Yes, definitely!
Parsley, sage, rosemary, and maggikraut.

Ashley

Great work :) Definitely a feature which has been missing from Simutrans so far. Squirrel looks neat too :)
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

Dwachs

Moving this to the 'larger projects' board.

In the meanwhile, I finished implementation to make the scripts' output translatable.

The New-York scenario is also implemented. http://forum.simutrans.com/index.php?topic=3812.0

I am somehow stuck at the implementation for network games. My intention is that the scripts only run on the server, so the client does not need the script files. Exchanging of error messages aka "The script does not allow you to build a track here" is implemented. I still need to figure out how to nicely implement the transfer of texts in the scenario description window. Not much progress here in the last months due to real life (new job, new home) and forum issues.
Parsley, sage, rosemary, and maggikraut.

Dwachs

I am happy to 'release' a first version of scripted scenarios stuff.

Scenario script can run at servers, clients will obey the rules enforced by the script without having access to the script itself. This enables to force certain rules without clients to be able to cheat.

There is also support for translation as well. In network games, scenario output is translated to the language that is set at the server.

Here is a complete zip-file with all the source code and example scenarios:
https://github.com/Dwachs/simutrans/zipball/scripted-0.1

You can as well checkout the branch 'scripted' of my github repository:

git clone git://github.com/Dwachs/simutrans.git
git checkout scripted


I consider the current state as finished, in the sense that the core features are implemented and working. The code needs some cleanup and restructuring, also more functionality can be exposed to scripts.

Please test and comment!
Parsley, sage, rosemary, and maggikraut.

sdog

well done!

this might be one of the most important new features, allowing tutorials and in the long run perhaps an educational game.

prissi

As well as scripted AI and so on. I am also looking forward to this. (I still fear no big testing from my side soon.)

Dwachs

#11
Thanks to Wernieman there now compiled versions of this version. They can be found at:

https://github.com/Dwachs/simutrans/downloads

You need to download the right executable for your system and the archive

https://github.com/downloads/Dwachs/simutrans/sim-scripted-0.11-scenarios.zip

that contains the data files. There are some very basic scenarios available for pak64, two ready scenarios for pak128 (New York, tram madness), and an unfinished pak128 scenario.

Put the executable as well as the data files into an existing simutrans installation. You need pak64 and/or pak128 to be able to play available scenarios.

For those interested in creating scenarios: first you need an idea and vision about scenario goals and rules. Then create a savegame. Then you need to write a script. Look at the example scripts *.nut in the scenario-subdirectory of pak the pakset. There is also a template script file in script/new_scenario_template.nut, where you can start to build your own scenario.


Edit: there was a problem with the Windows executables, please re-download again.
Parsley, sage, rosemary, and maggikraut.

VS

#12
For me, both GDI and SDL can not receive any input after closing the intro dialog :-/ I think I can't activate or use any tool or toolbar, and it all begins there, so... But mouse moves and wheel zooms, too.

I downloaded about 7 hours after your edit.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Dwachs

#13
:( will check later.

Edit: There was an error in a script. Dont know, why I did not notice before. Please download the update:

https://github.com/downloads/Dwachs/simutrans/sim-scripted-0.11-scenarios.zip
Parsley, sage, rosemary, and maggikraut.

prissi

I think you can commit this to trunk, please. The current scenarios are so underdeveloped, any progress there - even if buggy - is highly desired.

Dwachs

I still want to to some code cleanup and documenting ...
Parsley, sage, rosemary, and maggikraut.

hreintke

LS.

This is a nice feature. I looked at some features and made first tries.
Have some trouble to understand the working.

- Could you include a script snippet how to loop thru all cities and convoys ?
- I found that you can do (f.e.) localcity.citizens.reduce(sum) and localcity.citizens.reduce(max).
looks like the max option gives the current city size. What are the definitions of reduce, sum and max and are other options available ?

Kind regards,

Herman

Dwachs

#17
Quote from: hreintke on June 01, 2012, 07:39:09 AM
- Could you include a script snippet how to loop thru all cities and convoys ?
Looping through convoys is done in the sell-cloting scenario, see function get_trawler_count(). Looping through cities is not implemented yet. You can query city properties of a particular city if you know its position.

Quote
- I found that you can do (f.e.) localcity.citizens.reduce(sum) and localcity.citizens.reduce(max).
All of the functions that return statistics will return an array, ie the history of for example citizen over the last months (citizens_year gives the history over the last n years). The reduce function is a built-in function to be applied to the array, see the squirrel documentation:

http://www.squirrel-lang.org/doc/squirrel3.html#d0e3275

Max gives the max value in the array, sum returns the sum of all elements in the array.

You can get an impression, which functions are currently supported in the script when looking into

https://github.com/Dwachs/simutrans/blob/scripted/script/export_objs.cc (from line 256 on)

All these get-function can be called without the "get_" prefix. I.e. the statements

local n = city.get_citizens()
local n = city.citizens

are equivalent.
Parsley, sage, rosemary, and maggikraut.

hreintke

LS,

Thanks, enough to get me going again.

Noticed a possible error in your code. Look at line 366 of your exp_objects.

register_function(vm, exp_convoi_stats<convoi_t::CONVOI_DISTANCE>,          "get_revenue",           1, "x");

I presume it should say get_distance as get_revenue was listed already in line 362.

Herman

Dwachs

Quote from: hreintke on June 01, 2012, 08:53:23 AM
Noticed a possible error in your code. Look at line 366 of your exp_objects.

register_function(vm, exp_convoi_stats<convoi_t::CONVOI_DISTANCE>,          "get_revenue",           1, "x");

I presume it should say get_distance as get_revenue was listed already in line 362.
Thanks for spotting! Already fixed in the source code :)
Parsley, sage, rosemary, and maggikraut.

Dwachs

#20
There is now version 0.2 released :)
Special thanks to freca (from the German forum), who completed the script for the sell-clothing scenario!

I asked Wernieman to compile new version of the executable. They will be found at:

...

The updated archive with scenarios needs to be downloaded from:

...

Savegames saved with v0.1 should load with v0.2, scenario progress should be recovered upon loading.

Edit: New executables have been compiled by Wernieman, thank you !
Parsley, sage, rosemary, and maggikraut.

Dwachs

If I find more spare time, I want to complete the doxygen documentation of the script interface. Look here for a incomplete first version:
http://dwachs.github.com/simutrans-sqapi-doc/annotated.html
Parsley, sage, rosemary, and maggikraut.

prissi

Since we had the release, I would suggest to submit it to trunk, as it seems not to break anything so far ...

Dwachs

In the meanwhile, the auto-generation of code is implemented, and doxygen can run on it. I also started to write some documentation:

http://dwachs.github.com/simutrans-sqapi-doc

There is still a major design issue to resolve: If a script takes too long to deliver a result, it should be suspended and resumed later on. The problem here is that in between the world might change: tiles and stuff may be deleted. If the script holds a reference to such an object, it will fail later at random places. The script's programmer has no chance to detect this.


// Code to be executed:
local halt = tile_x(1,2,3).get_halt()
// Script knows that there is a tile at (1,2,3)
// Execution is suspended here
//                        v
local halt = tile_x(1,2,3).get_halt()
// Up to now the result of tile_x(1,2,3) is a valid reference to a tile grund_t
// However, if in between a player works on the map, the tile is gone (ie bridge deleted, terraforming)
// Now the script is resumed
//                        v
local halt = tile_x(1,2,3).get_halt()

What to do in this situation? The return value of tile_x is invalid. What should get_halt do? Return default value? Should we force script programmers to implement try/catch chains?

Simutrans will not crash, as the script objects do not safe pointers to c++ objects, but coordinates or handles that are used to retrieve the object. That said, the script engine can catch these cases perfectly, but this process is not transparent to the programmer.

The Openttd guys implemented a sleep() function, which suspends the script at defined places. If the script is then resumed it has enough time (op-codes) to ensure that all objects stay valid... Afaict they do not have any classes and objects on the c++ side of things, so the script has full control about the lifetime of instances.

Any thoughts?
Parsley, sage, rosemary, and maggikraut.

Ters

I don't think a script should automatically suspended if it takes too long time, if that's the idea. It will be too confusing and might yield incorrect results even if all references are valid.

That

tile(1, 2, 3)

might fail is something a scripter just has to expect. It's more confusing when you do

local tile = tile(1, 2, 3) # Returns a valid tile
... (code that does not modify anything)
tile.do_something() # fails because tile isn't valid


The easiest solution to program might be to lock everything that is referenced by scripts, but would be very bad for players, especially when references from the scripting language stay alive for longer than necessary.
One probably has to state that references should to game world objects should not be kept between frames (across calls to sleep(), yield() or whatever it is called), but it can't be enforced other than throwing exceptions when such references are used, either always or just when they have become invalid.

prissi

One could require scripts to lock certain instances (like halt handles) explicitely and otherwise request to always use lookups for stuff. I.e. if you want to work with a tile, the you call "EnterCriticalSection" or so and later "ExitCriticalSection". Outside, you have to work with references (like tile(1,2,3).get_halt() ) and also call sleep() often enough.

And the OpenTTD guy have the problems, since their wayfinder for their AI uses the script and is very slow. Often indeed the world changes in between. It is then up to the AI programmer to work around this.

Dwachs

#26
This is now incorporated in r5859, hopefully in time for the nightly.

Scenario files are available at
Parsley, sage, rosemary, and maggikraut.

prissi

#27
I added hhopefully teh right files to the MSVC08 project too.

But there are some files aparent not used (seleton, awk, ... ) Maybe it would make sense to put them in a separate folder?

I also added the load scenario butt to the man staring banner screen.

By the way: Why not join about and info in the scenario window tabs?

Dwachs

#28
Quote from: prissi on August 03, 2012, 08:27:19 PM
But there are some files aparent not used (seleton, awk, ... ) Maybe it would make sense to put them in a separate folder?
These files are used to generate the documentation for the API. The files in script/api are used to export c++ functions and at the same time enable automatic documentation with doxygen. This documentation is here:

http://dwachs.github.com/simutrans-sqapi-doc/

Quote
By the way: Why not join about and info in the scenario window tabs?
The info tab is meant to contain the scenario description and story. The about tab is there to display technical information about the scenario: author, version and the like.

Updated scenario files can be found here:

https://github.com/downloads/Dwachs/simutrans/simutrans-scenarios-r5873.zip
Parsley, sage, rosemary, and maggikraut.

VS

Ohh... looking forward to this :D I had a few ideas set aside for this moment.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Dwachs

I created a new repository for scenario development here:

https://github.com/Dwachs/simutrans-scenarios

Happy forking :)
Parsley, sage, rosemary, and maggikraut.

VS

Just a thought - looking at the file-level structure... Wouldn't it make more sense to move sve and nut into the folder, too? One scenario = one folder :)

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

eipi

Just found an issue: In dataobj/scenario.h (lines 99 and 104), hmax should not be initialized to 128 but instead to 127, which is the maximum value for sint8. It causes a truncation warning on MSVC.

Dwachs

Quote from: eipi on August 08, 2012, 01:26:28 PM
Just found an issue: In dataobj/scenario.h (lines 99 and 104), hmax should not be initialized to 128 but instead to 127, which is the maximum value for sint8. It causes a truncation warning on MSVC.
thanks for reporting, will be fixed soon. This should not cause any misbehavior, as these values are unused at the moment.
Parsley, sage, rosemary, and maggikraut.

Dwachs

Quote from: VS on August 04, 2012, 07:06:58 PM
Just a thought - looking at the file-level structure... Wouldn't it make more sense to move sve and nut into the folder, too? One scenario = one folder :)
This was implemented some days ago. New scenario files are at sourceforge:

http://sourceforge.net/projects/simutrans/files/simutrans/112/
Parsley, sage, rosemary, and maggikraut.