Pro Evolution Soccer 2019 Sider 5.2.0 by Juce
– overlay can now be controlled by gamepad: Lua modules can use new “gamepad_input” event. Press “RT+LT” to toggle the overlay on/off. Press “LT” to switch to next module in the overlay.
– new “livecpk_read” event for examining the data as the game reads it. Also new library available to Lua modules: “zlib” – for compressing/uncompressing data. See doc/scripting.txt – for all the details on this.
– now using LuaJIT 2.1.0-beta3. This allows Lua modules to use all RAM available.
How to upgrade with minimal impact on your existing Sider:
1. Keep the sider.ini that you already have.
2. Copy sider.exe, sider.dll, lua51.dll, gamepad.ini from the sider-5.2.0.zip archive, replacing the existing files.
3. (Optional) You can also copy “modules” and “doc”. There are some new modules that demonstrate the new features, and also the documentation has been updated.
Gamepad controller support
If you are writing a Lua module and want to handle gamepad input in it, please read the section in the doc/scripting.txt about the new “gamepad_input”. There is also a so-called “global-input-mapping” configuration: the modules that only handle input from keyboard, but not from gamepad (which is how all of them are right now :) ) – will receive automatically-mapped keyboard events. For example, if user pushes RS (right stick) to the left, a keyboard event of “PageUp” key will be generated and sent to Lua module, which is currently active in the overlay. The mapping is defined in gamepad.ini file. This mapping works best with @zlac ‘s modules – such as BallServer, ScoreboardServer, RefkitServer, StadiumServer – because they all provide consistent interface in terms of hot keys. You can always disable/modify the global mapping – by deleting or editing gamepad.ini. Your module also can also register to handle the “gamepad_input” event, in which case controller events will not be mapped to key presses.
This is a somewhat experimental change. We have been using LuaJIT 2.0.5 in previous releases of sider. It works well, but on 64-bit architectures it has a strict limit on how much RAM the modules can use. On 64-bit Windows this limit is around 1GB and also the memory needs to be allocated from “lower” addresses, some of which can already be used by other DLLs loaded by the game. So, in practice, this limit is often less than 1GB. With LuaJIT 2.1.0-beta3, built with new garbage collector (GC64) enabled, the limit is no longer there, and your Lua modules can use all the RAM available. There is an demo module that tries to allocate 8GB of memory – modules/gc64test.lua . You can try it to. If for some reason new LuaJIT doesn’t work well for you (unstable, or slow) – you can always switch back to 2.0.5 version: i’ve included both of them in the “luajit” directory.