kTriggeredData = argsList[1]
What is 'argsList' abaut? Like does it use a 'premade' list, or something, or the lines below make the list?
Whenever the DLL file makes a call to python, it generates a list (array) of arguments. Simply put, it's a list of variables the DLL wants to give to python. There are multiple locations in the DLL, which calls python and each tend to have a unique setup of arguments. However it's less tricky than it sounds because vanilla gets the arguments right. This means you can look up some vanilla event, which has a python callback and then you copy paste the argsList code from that one. I picked applyTsunami1, though any event with a python callback could be used for this.
The contents of EventTriggeredData is a bit more tricky. Experience made me look it up in CyStructInterface1.cpp, though I also read CvStructs.h too.
.def("initUnit", &CyPlayer::initUnit, python::return_value_policy<python::manage_new_object>(), "CyUnit* initUnit(UnitTypes iIndex, plotX, plotY, UnitAITypes iIndex) - place Unit at X,Y NOTE: Always use UnitAITypes.NO_UNITAI")
Not sure how much i understand here... I truly feel dumb looking at this line. Everything below is quite simple even for me.
All the game data is in the DLL. This means when you run code in python, you need to call DLL functions to read and modify the game data. This is done by getting a pointer to an object and then call member functions.
Luckily it's not as tricky as it sounds. Take for instance:
PHP:
player = gc.getPlayer(kTriggeredData.ePlayer)
gc is CyGlobalContext, which is an object, which is always available.
getPlayer is a member function of CyGlobalContext. It returns a CyPlayer object, which is stored in player. player can then use the member functions for CyPlayer.
The member functions are listed in Cy*Interface*.cpp. The first * is the object (like player) and the last is a number (which can be skipped). Due to a compiler limitation, the interface files can't exceed 64 kB, which is why some of them have the functions split into multiple files.
In the interface files, each member function is defined in a single line.
PHP:
.def("initUnit", &CyPlayer::initUnit, python::return_value_policy<python::manage_new_object>(), "CyUnit* initUnit(UnitTypes iIndex, plotX, plotY, UnitAITypes iIndex) - place Unit at X,Y NOTE: Always use UnitAITypes.NO_UNITAI")
It's in CyPlayer, which means it's a function, which can be used by player objects.
- "initUnit"
is the name of the function, as in what you need to write in python
- &CyPlayer::initUnit
is the name of the function inside the DLL to call. You can look up the function if you like
- python::return_value_policy<python::manage_new_object>()
is return policy as in memory management. Forget about this unless you mod the DLL interface itself
- "CyUnit* initUnit(UnitTypes iIndex, plotX, plotY, UnitAITypes iIndex) - place Unit at X,Y NOTE: Always use UnitAITypes.NO_UNITAI"
the last is always a comment. It tells how to use the function
Figuring out how to read the python interface in the DLL should help a lot when writing python code. People talk about python exposed functions and not exposed functions. The functions in the interface are the exposed functions while the non-exposed are those present in the DLL, but aren't mentioned in the interface files, meaning python can't access them.
