For sider.dll version: 7.1

Top

Instead of offering a C interface, where the programmers would need to write a DLL, i'm a taking a different approach here and trying to design a system, where extension modules are written in Lua. A module would typically initialize itself by registering for certain events, and then Sider will call the module functions, when those events occur. The Lua module embeds Lua into NGINX and by leveraging NGINX's subrequests, allows the integration of Lua threads into the NGINX event model. This is a slightly modified build of the Terra library which allows the Terra runtime to be loaded from Lua as a Lua/C module. The terra module exposes the complete Terra Lua API and installs a require loader for loading.t files from the same locations that are used for loading Lua. Introduction; Anatomy of a Lua to C Call; Putting It All Together; Make an msleep Function; We've Just Scratched the Surface; Introduction Earlier you read the Calling Lua From a C Program web page showing how to call Lua from C. There are a lot of instructions with no examples, always leaving something out, so you have to keep trying various things by trial and error, and there.

1. Introduction

The main idea here is to provide a safe and flexible way to extend Sider functionality. It allows modders to alter many aspects of game logic, and load all sorts of extra content. Visual and gameplay tweaks are possible too.

Lua is by now a well-established language of choice for scripting support in games, used all over the gaming industry. Most famous example is probably WarCraft, but many modern games use it, including Pro Evolution Soccer itself. To boost the performance, Sider uses a just-in-time compiler for Lua called LuaJIT (https://luajit.org), written by Mike Pall. LuaJIT is a truly brilliant piece of software. It is 100% compatible with Lua 5.1, and it is super fast, often approaching and sometimes exceeding the speed of C code.

After reading this guide, the next step is to study the example (and non-example) modules, which are provided with this release of Sider. Find them in the 'modules' directory.

Top

2. Module structure

If you are familiar with Lua and how modules are typically organized then this will make full sense to you. If are you new to Lua, i would strongly recommend reading 'Programming in Lua' by Roberto Ierusalimschy. 2nd edition covers Lua 5.1, which is the version of the language used by Sider. However, any other edition of the book will be just as helpful.

In any case, the module organization is pretty simple:

Your need to create a new table
Provide a function, called 'init' in that table, where you need to do any initialization logic for the module and register for the events your module is interested in.
Return that table as the last statement

Example module: test.lua

As you have already guessed, this module doesn't really do much. But it is a valid module, and can be loaded by Sider. For that you need to save it as {something}.lua file in the 'modules' folder, inside sider. Let's assume that you named it: test.lua. Then, you must also enable it in sider.ini, like this:

If you now run the game, your module will get loaded by Sider, and then the 'init' function will be called, so you should see a 'Hello, world!' message in sider.log. If you made a mistake and your module has a syntax error, for example, or some other problem, don't panic, instead open sider.log with Notepad (or any text editor) and look for an error message there. It will explain where (on which line of your script) and what sort of problem occurred.

VERY IMPORTANT NOTE:
File encoding must be UTF-8. This is vital, if you are using non-latin characters in the strings in the module code - for example, in paths. If you only have latin-1 chars, then ANSI is ok too.

Let's now see how you can make a more useful module. First step for that is to understand the context object (ctx).

Top

3. Context object

Context object is what Sider knows about the current state of the game. As more scripts/modules are created by the community the context object will probably also change, and include more and more information about the game.

As of 7.0.0 release, the context object has the following:

ctx.home_team	id of the home team of the current match, after it is selected in the exhibition match, or the next match is determined in the league mode.
ctx.away_team	id of the away team of the current match, after it is selected in the exhibition match, or the next match is determined in the league mode.
ctx.tournament_id	numeric id of the current tournament. See doc/tournament.txt file for the list of ids for all of the game's tournaments.
ctx.match_id	some sort of number, which seems to indicate where in the season you currently are. However, the exact meaning of this id is unclear. Maybe you can figure it out and tell me ;-)
ctx.match_leg	set to 1 or 2, if this is 1st leg or 2nd leg of a two-legged knock-out match.
ctx.match_info	meaning of this field varies, depending on the type of tournament: league: number of league matches already played cup/play-off: 46 - first round of play-off, 47 - second round of play-off, 51 - quaterfinal, 52 - semifinal, 53 - final You can use this together with ctx.tournament_id to identify a final match of a particular tournament.
ctx.stadium	numeric id of the stadium that will be used (or was last used, if the stadium for the next match hasn't been chosen yet by the game logic)
ctx.stadium_choice	This field is set when the game is in one of the exhibition modes, and the stadium is allowed to be selected via the menu. Once the actual final selection of the stadium is made (right after the 'set_stadium' event fires), the 'stadium_choice' field get removed from the context. Special values: 65533 - home stadium 65534 - random stadium 65535 - not chosen yet
ctx.timeofday	The values are: 0 - day, 1 - night. Same as with stadium, it represents the time of day of the coming match, or the last one, if the stadium isn't set yet for the next match.
ctx.season	The values are: 0 - summer, 1 - winter.
ctx.weather	The values are: 0 - fine, 1 - rainy, 2 - snowy
ctx.weather_effects	The known values are: 2 - enforce weather effects (rain/snow falling)
ctx.match_time	Duration of the match in minutes.
ctx.difficulty	Difficulty that was chosen: 0 - Beginner, 1 - Amateur, ... 5 - All-star, 6 - Legend
ctx.extra_time	0/1 flag to indicate if extra time will be played
ctx.penalties	0/1 flag to indicate if penalty shootout will be played
ctx.substitutions	number of substitutions allowed in normal time
ctx.substitutions_in_extra_time	number of substitutions allowed in extra time
ctx.kits	table of functions for kit manipulation. (See more details further down)

The context object also contains a register function, which has the following signature:

ctx.register(event_name, handler_function)

The event_name parameter is a string, which identifies a particular event. The handler_function should be a function in your Lua module, which will be called when the corresponding event happens. Parameters vary depending on the event - see the next section for details on all supported events and their handler signatures

The idea of the context object is that in your handler functions, your code will make decisions on what to do, using the information in the context.

3.1. ctx.kits

It is a table of helper functions to manipulate kits (uniforms).

IMPORTANT NOTE:
kit operations only work for 'licensed' teams, in other words, for those that have real kits, not ones made in game editor. If your team is unlicen

Lua C Module