I want to help this mod

Gents, I (5+ years of experience with various programming languages) need to get some more practise with C++, and I'd like to put that effort to the service of this mod - have you any use for a programmer?
 
Gents, I (5+ years of experience with various programming languages) need to get some more practise with C++, and I'd like to put that effort to the service of this mod - have you any use for a programmer?
Start a Conversation with Thunderbrd. He is leader programmer. I would think that he would welcome some help. :)
 
Gents, I (5+ years of experience with various programming languages) need to get some more practise with C++, and I'd like to put that effort to the service of this mod - have you any use for a programmer?
Aside from wanting practice, are you simply offering to help with debugging or do you have a project in mind?
 
all unused calls from DLL to python should be stopped. ill be mass removing on my copy. I can explain if anyone cares
Please! Do so.
 
@Thunderbrd do those slow game or not?
I don't know. I realize they are there for python modders to work with wherever it was imagined they'd potentially need it. I know that the USED calls can take some time but I'm not sure if they really take up time if not used.

Yes, I'd love to hear an in-depth viewpoint on the subject @MattCA .
 
I don't know. I realize they are there for python modders to work with wherever it was imagined they'd potentially need it. I know that the USED calls can take some time but I'm not sure if they really take up time if not used.

Yes, I'd love to hear an in-depth viewpoint on the subject @MattCA .
The call to python in itself can take more time than it takes to process the actual python code.
The forth and back, moving from one programming language to another, the interface part, consume time.
 
The call to python in itself can take more time than it takes to process the actual python code.
The forth and back, moving from one programming language to another, the interface part, consume time.
Even if there's nothing on the python side connecting the handshake, huh?

I'd think then that the best thing to do would be to comment them out rather than remove them entirely, because setting them up would be a pain if they were needed in the future and much easier to just uncomment what's there and read to work once called for.

I would have no idea what is and what is not used by python though.
 
There is always something on the python side, even if it's only an empty function that the dll calls.
See my edit above.

In that case, then commenting out wouldn't be helpful at all would it? Or maybe they can be commented out in python as well? I don't know much about the transfer of info between the two tbh.
 
ya many of them are stopped by an option too so almost no time lost and it means python modders can turn this stuff on and off without messin with vb or c++. cool idea but its unused and shouldn't be used. the way it is set up it cancels the current c++ . some don't have the options and most are in odd places. basically all the current pyton uses the other system which uses CvDllPythonEvents and CvEventReporter and the config folder.
Starts in the Dll
Spoiler :

if(GC.getUSE_CAN_TRAIN_CALLBACK(eUnit))
{
PYTHON_ACCESS_LOCK_SCOPE

PROFILE("canTrain.Python");

CyCity* pyCity = new CyCity((CvCity*)this);
CyArgsList argsList;
argsList.add(gDLL->getPythonIFace()->makePythonObject(pyCity)); // pass in city class
argsList.add(eUnit);
argsList.add(bContinue);
argsList.add(bTestVisible);
argsList.add(bIgnoreCost);
argsList.add(bIgnoreUpgrades);
long lResult=0;
PYTHON_CALL_FUNCTION4(__FUNCTION__, PYGameModule, "canTrain", argsList.makeFunctionArgs(), &lResult);
delete pyCity; // python fxn must not hold on to this pointer
if (lResult == 1)
{
return true;
}
}




bool bConquestCanRaze = false;
if (bConquest)
{
PYTHON_ACCESS_LOCK_SCOPE

CyCity* pyCity = new CyCity(pNewCity);
CyArgsList argsList;
argsList.add(getID()); // Player ID
argsList.add(gDLL->getPythonIFace()->makePythonObject(pyCity)); // pass in city class
long lResult=0;
PYTHON_CALL_FUNCTION4(__FUNCTION__, PYGameModule, "canRazeCity", argsList.makeFunctionArgs(), &lResult);
delete pyCity; // python fxn must not hold on to this pointer

if (lResult == 1)
{
bConquestCanRaze = true;
}
}



void CvCity::doTurnBeginProcessing()
{
PROFILE_FUNC();

FAssert(m_deferringBonusProcessingCount == 0);

// Allow the player to determine the type of conscripted units
{
PYTHON_ACCESS_LOCK_SCOPE

long lConscriptUnit;

CyArgsList argsList;
argsList.add(getOwnerINLINE()); // pass in player
lConscriptUnit = -1;
PYTHON_CALL_FUNCTION4(__FUNCTION__, PYGameModule, "getConscriptUnitType", argsList.makeFunctionArgs(),&lConscriptUnit);

m_eConscriptUnitType = (lConscriptUnit == -1 ? NO_UNIT : (UnitTypes)lConscriptUnit);
}

[/spoiler]
over to CvGameInterface which does nothing excpet bounces call to BugGameUtils then to CvGameUtils to be handled. code that tells the dll not to skip the following c++ is then sent back the same way
Spoiler :


def canRazeCity(self, argsList):
iRazingPlayer, pCity = argsList
return True


def canTrain(self, argsList):
pCity = argsList[0]
eUnit = argsList[1]
bContinue = argsList[2]
bTestVisible = argsList[3]
bIgnoreCost = argsList[4]
bIgnoreUpgrades = argsList[5]
return False
[/spoiler]
 
looks like complicated code but the args are never used so don't worry about any arg parts. lresult is what will come back from python. it always fails the if in c++ and nothing happens
 
In that case, then commenting out wouldn't be helpful at all would it? Or maybe they can be commented out in python as well? I don't know much about the transfer of info between the two tbh.
Commenting out the dll call to empty python functions would help, the python code can exist without ever being called on.

Matt mentions that some python calls can be turned on and off in the PythonCallbackDefines.xml.
The dll then checks the global boolean set in that xml to decide if it makes the python call or not.

This discussion is all very nitpicky, we may want to add more on/off switches to the python calls (or simply comment the calls out), but it wouldn't result in any huge speedups.
looks like complicated code but the args are never used so don't worry about any arg parts. lresult is what will come back from python. it always fails the if in c++ and nothing happens
Not always. Some of the python calls to CvGameUtils.py do actual game related stuff.
The arguments given by the dll are essential for the python code, if there is any, for it to know why it was called and for what context it should work within.
 
Last edited:
Currently PythonCallBacks are not working in C2C. Or at least the one we use for the Great Farmer is but the others aren't. Koskling did a lot of work on the them because they were very slow on the dll side before they even got to the boundary with the Python. If you can understand what is being done there and let us use some more of them it would open up a number of projects that were put on hold. It may also be that the way they are now defined has just not been described well enough for us to get more than one to work.

edit just to be clear PythonCallBacks are only the functions in the globals XML. It is not all calls to Python just those special ones.
 
ha ive been doin and thinking the exact opposite. I find there is a huge set up for python and only uses half of it. 41 python events used, 27 unused. 55 of the other kind sent to the python game module unused and about a half dozen used. Im not lookin to cut the python off at the knees - just uncomment as needed.

this stuff I only understand pieces
Spoiler :

// KOSHLING - granular control over callback enabling
#define GRANULAR_CALLBACK_CONTROL
#ifdef GRANULAR_CALLBACK_CONTROL
typedef enum
{
CALLBACK_TYPE_CAN_TRAIN = 1,
CALLBACK_TYPE_CANNOT_TRAIN = 2,
CALLBACK_TYPE_CAN_BUILD = 3
} PythonCallbackTypes;

class GranularCallbackController
{
public:
GranularCallbackController()
{
m_rawInputProcessed = false;
}

// Unit list for a named (unit based) callback which must be enabled
// Logically OR'd into the current set
void RegisterUnitCallback(PythonCallbackTypes eCallbackType, const char* unitList);

but I don't see why anyone would wanna use python to add requirements when c++ already takes care of that stuff.
id rather see those lairs and pirates and whatever else (I think that stuff is your). if u could use a hand id like to help
 
ha ive been doin and thinking the exact opposite. I find there is a huge set up for python and only uses half of it. 41 python events used, 27 unused. 55 of the other kind sent to the python game module unused and about a half dozen used. Im not lookin to cut the python off at the knees - just uncomment as needed.

this stuff I only understand pieces
Spoiler :

// KOSHLING - granular control over callback enabling
#define GRANULAR_CALLBACK_CONTROL
#ifdef GRANULAR_CALLBACK_CONTROL
typedef enum
{
CALLBACK_TYPE_CAN_TRAIN = 1,
CALLBACK_TYPE_CANNOT_TRAIN = 2,
CALLBACK_TYPE_CAN_BUILD = 3
} PythonCallbackTypes;

class GranularCallbackController
{
public:
GranularCallbackController()
{
m_rawInputProcessed = false;
}

// Unit list for a named (unit based) callback which must be enabled
// Logically OR'd into the current set
void RegisterUnitCallback(PythonCallbackTypes eCallbackType, const char* unitList);
Well that explains it as it was one of the others that I was trying to use. The USE_CAN_RESEARCH_CALLBACK when I was trying to add Platyping's World Techs to the game. I think TB has implemted it another way now, so it is not needed.
but I don't see why anyone would wanna use python to add requirements when c++ already takes care of that stuff.
  • Most modders are not programmers.
  • Python does not require compiling. It takes a whole lot less time to implement.
  • If you want your mod to run on a Mac you can't change the dll in any way.
id rather see those lairs and pirates and whatever else (I think that stuff is your). if u could use a hand id like to help
I grabbed the art for the lairs when it came out. SO, Hydro and I had some ideas we wanted to implement but it was low priority. I will have to see if I still have the notes on what we wanted to do.

edit mainly
  • the lairs were going to be spawn points for animals before the current spawn was invented.
  • bandit/pirate camps were going to be added to the Events to make them a bit more on going rather than a one off. Eg the pirate Event would not just spawn a bunch of pirates but also place a base on the map, owned by the barbarians and have it spawn new pirates until it was destroyed.
 
Well that explains it as it was one of the others that I was trying to use. The USE_CAN_RESEARCH_CALLBACK when I was trying to add Platyping's World Techs to the game. I think TB has implemted it another way now, so it is not needed.
The USE_CAN_RESEARCH_CALLBACK works just fine...
I think you tried to use it like if it was a USE_CANNOT_RESEARCH_CALLBACK, as in you wanted python to set a criteria to disable the possibility to research a tech.

The USE_CAN_RESEARCH_CALLBACK can only be used to make it possible to research a tech that normally cannot be researched, not the other way around.

The USE_CANNOT_RESEARCH_CALLBACK should work just fine too btw.
 
Last edited:
Back
Top Bottom