xienwolf
Deity
You should be able to do everything using the basic code which already existed. I would imagine you customize yourself on a custom built python screen, with all options immediately presented to you?
If that is the case, then within the screen he has to handle the input actions you take. Find where those handles are made, and anywhere that he translates User Input to DLL Interface, change it to instead be a sendModNetMessage command. Then take the lines of code which talked with the DLL and define a new Python function for them which will be called by onModNetMessage, and run natively immediately after the sendMonNetMsg.
Something along these lines (PseudoCode):
Original:
New code would be something like:
Then somewhere else in the same file you will create:
And in the onModNetMessage:
Doing something like that, creating your own enumeration system to handle each possible user input option, will cover you for everything EXCEPT string values. ModNet can only really deal with Integers, and booleans and floats can be worked with if required, but doing a full string input would be difficult. I can't think of too many things where you should be able to use a string, so you should be fairly well set with this setup.
If the basic python file you are modding from has some areas where it tries to run multiple values at once (like assigning Civilization Colors and Flag choice all at once, total of 4 numbers), break it down into as few numbers as you can get away with for each individual call to the DLL. Since ModNet can only handle 5 numbers and you waste 2 of those identifying first WHAT to do, and next WHO to do it to. If forced to, you CAN send messages which store values in the local python's global variables temporarily until all of the required values have been gathered together, but this would run into issues if 2 computers attempt to manipulate those values at the same time (2 different players each attempt to select a specific flag). So instead you can try to predict combinations which will occur and pre-store those in a local array which can be referenced by a single integer (if flag 5 goes with colors 27, 147, 234 every time, you can store all 4 of those together in an array called Flag5, or as the 5th element in an array called FlagColors)
So the entire screen and all user input happens exactly how the original mod had it working. You just intercept where the python and the DLL attempt to talk and require that they include ModNetMsg in the conversation.
If that is the case, then within the screen he has to handle the input actions you take. Find where those handles are made, and anywhere that he translates User Input to DLL Interface, change it to instead be a sendModNetMessage command. Then take the lines of code which talked with the DLL and define a new Python function for them which will be called by onModNetMessage, and run natively immediately after the sendMonNetMsg.
Something along these lines (PseudoCode):
Original:
Code:
if (userInput == Checkbox for iTrait clicked)
pPlayer.changeTrait(iTrait, bCheckBoxChecked)
if (userInput == Civ Selected from DropDownList)
CyGame.setCivilizationType(iPlayer, iChoiceFromDropDown)New code would be something like:
Code:
if (userInput == Checkbox for iTrait clicked)
sendModNetMessage(0, iPlayer, (int)bCheckBoxChecked, -1, -1) #the 0 identifies this particular checkbox (Enumeration)
ToggleCheckBox(0, iPlayer, (int)bCheckBoxChecked)
if (userInput == Civ Selected from DropDownList)
sendModNetMessage(1, iPlayer, iCiv, -1, -1) #The 1 indicates this particular Dropdown List (Enumeration)
ChooseCivilization(iPlayer, iChoiceFromDropDown)Then somewhere else in the same file you will create:
Code:
def ToggleCheckBox(self, iCheckBoxEnum, iPlayer, iChecked)
if (iCheckBoxEnum == 0):
if (iChecked == 1):
pPlayer.changeTrait(iTrait, True)
else:
pPlayer.changeTrait(iTrait, False)
def ChooseCivilization(self, iPlayer, iChoiceFromDropDown)
CyGame.setCivilizationType(iPlayer, iChoiceFromDropDown)And in the onModNetMessage:
Code:
cp = CivPickerPythonFile().CivPickerPythonFile()
if (iData == 0)
cp.ToggleCheckBox(0, iData2, iData3)
if (iData == 1)
cp.ChooseCivilization(iData2, iData3)Doing something like that, creating your own enumeration system to handle each possible user input option, will cover you for everything EXCEPT string values. ModNet can only really deal with Integers, and booleans and floats can be worked with if required, but doing a full string input would be difficult. I can't think of too many things where you should be able to use a string, so you should be fairly well set with this setup.
If the basic python file you are modding from has some areas where it tries to run multiple values at once (like assigning Civilization Colors and Flag choice all at once, total of 4 numbers), break it down into as few numbers as you can get away with for each individual call to the DLL. Since ModNet can only handle 5 numbers and you waste 2 of those identifying first WHAT to do, and next WHO to do it to. If forced to, you CAN send messages which store values in the local python's global variables temporarily until all of the required values have been gathered together, but this would run into issues if 2 computers attempt to manipulate those values at the same time (2 different players each attempt to select a specific flag). So instead you can try to predict combinations which will occur and pre-store those in a local array which can be referenced by a single integer (if flag 5 goes with colors 27, 147, 234 every time, you can store all 4 of those together in an array called Flag5, or as the 5th element in an array called FlagColors)
So the entire screen and all user input happens exactly how the original mod had it working. You just intercept where the python and the DLL attempt to talk and require that they include ModNetMsg in the conversation.
