SDK Discussion/Question/Help/Tip Thread

jgerman said:
If it's doable with the current mod system, keep it there. Junking up the SDK needlessly is horribly poor design. There's a reason a scripting language was built in, the same reason it's in most modern games.
True and not true. For example I was/am working on a mod to the governor, and was having great difficulty getting it to run acceptably fast. This is because python is an interpreted language, and just can't match the speed of compiled languages.

Sometimes you need the SDK.
 
The Great Apple said:
True and not true. For example I was/am working on a mod to the governor, and was having great difficulty getting it to run acceptably fast. This is because python is an interpreted language, and just can't match the speed of compiled languages.

Sometimes you need the SDK.

No, you're wrong. It's always fun when nonsense coding maxims rear their ugly heads.

Yes, Python is interpreted, yes it CAN run slower under normal circumstances. The majority of any performance hit for an interpreted language is the loading of the interpreter itself, this is not an issue in Civ IV, the engine is loaded whether you use it or not. More importantly the devs used it to script the game. Anything you add is just a drop in the bucket compared to what is already being used.

It is highly unlikely that you will see a performance benefit.
 
talchas said:
You are correct that in general you should do stuff in python if you can, if only because its generally far easier to see what you are doing. However, loading a different DLL is just as easy as loading a mod - if a mod has a CvGameCoreDLL.dll in Mods/<ModName>/Assets then the game will load that rather than the normal CvGameCoreDLL.dll

That I didn't know, very good to hear.
 
jgerman said:
Yes, Python is interpreted, yes it CAN run slower under normal circumstances. The majority of any performance hit for an interpreted language is the loading of the interpreter itself, this is not an issue in Civ IV, the engine is loaded whether you use it or not. More importantly the devs used it to script the game. Anything you add is just a drop in the bucket compared to what is already being used.

It is highly unlikely that you will see a performance benefit.

The python code by itself might run reasonably fast, but I think that the overhead for the transition from python to C++ code and vice versa may be relatively slow. So if you are going back and forth between python and C++, then your python code may run fairly slowly. And you cross this boundary every time you call a function for the wrapped classes (ie CyCity, CyUnit, etc).
 
dsplaisted said:
The python code by itself might run reasonably fast, but I think that the overhead for the transition from python to C++ code and vice versa may be relatively slow. So if you are going back and forth between python and C++, then your python code may run fairly slowly. And you cross this boundary every time you call a function for the wrapped classes (ie CyCity, CyUnit, etc).

Gotta love that context switching...
 
jgerman said:
It is highly unlikely that you will see a performance benefit.
Right, so rather than taking your word for it I googled it.

http://furryland.org/~mikec/bench/

On these benchmarks python was between 3 and 350 times slower than c++... usually nearer the 350 end. Now I retract the bit about it being an interpreted language, but I stand by the fact that it is a significantly slower language.
 
The Great Apple said:
Right, so rather than taking your word for it I googled it.

http://furryland.org/~mikec/bench/

On these benchmarks python was between 3 and 350 times slower than c++... usually nearer the 350 end. Now I retract the bit about it being an interpreted language, but I stand by the fact that it is a significantly slower language.

[Edit - Removed orginal post]

Original reply removed, it's not worth it. I should know better than to try and correct technical accuracies in a forum like this. Think what you want.
 
Kudos to Firaxis for releasing the SDK :goodjob:

I'm curious though... what portion of the source code is actually there? I would assume not everything, or there's the risk of someone compiling and distributing their own pirated copies of Civ4.
 
Heffalump said:
Kudos to Firaxis for releasing the SDK :goodjob:

I'm curious though... what portion of the source code is actually there? I would assume not everything, or there's the risk of someone compiling and distributing their own pirated copies of Civ4.

Its only the code for one DLL file which includes pretty much all of the games features and functions. The sourcecode for the .EXE file isnt distributed. So we dont have any code which belongs to the Gamebryo engine (obviously).

But we got all we need to make better mods, and new games based on the Civ4 engine. But someone cant just download this source, compile it and start playing the game. (Without having the rest of the game files already, the exe files, all other dlls, all python, xml, graphics etc)
 
Does anyone knows where is "PyPopup.addPythonButton()" is processed in SDK?
The addPythonButton() seems to be broken.
I tried to fix it. but I can not get a clue..

According to comment in "Assets/Python/Entrypoints/CvPopupInterface.py"
Code:
# This is an interface file for handling Python Popup Function Calls
# argsList = (iData1, iData2)

# Assign the function by using the 'addPythonButton' function in pyHelper/Popup
# This allows you to specify a strFunctionName. If the player clicks that button then this file
# will be called with the specified function name.

# ie: addPythonButton( self, strFunctionName, strButtonText, strHelpText, \
 strArtPointer = "Art\Interface\Popups\PopupRadioButton.kfm", \
 iData1 = -1, iData2 = -1, bOption = True):

But I can not make it call the python function specified in "strFunctionName".
I try to fix it. But I can not figure out where it is processed.
I know that the CyPopup() class and function "addPythonButton" itself is not included in SDK.
But the function should call some function in CvDLLButtonPopup.cpp or CvPopupInfo.cpp in to display popup. ( My conjecture)
I tried to trace it by printing debug log. But can not get any trace of it.

Or, Does anyone succeeded in using "addPythonButton" to call Python function?
 
This is what i could find for the adding of buttons, from the CvPopupInfo.cpp file.

Not used the functions my self, some one else might know how it works.

void CvPopupInfo::addPythonButton(const wchar* szText, const char* szArt)
{
CvPopupButtonPython button;
button.szText = szText;
button.szArt = szArt;
m_aPythonButtons.push_back(button);
}
 
What is proper way to print log message for debugging in SDK?

It seems that printf or fprintf(stderr,) won't print anything in SDK..
OutputDebugString(msg) Won't work too in RELEASE build...
gDLL->logMsg("xxxxx.log", szError); does not seems to be proper way to log in SDK...

There is some ways to show Dialogbox or Mesage Box.
But I want log to Text file like PythonDbg.log or PythonErr2.log.
There should be central, consistent and unified way to print log.
 
SimCutie said:
What is proper way to print log message for debugging in SDK?

It seems that printf or fprintf(stderr,) won't print anything in SDK..
OutputDebugString(msg) Won't work too in RELEASE build...
gDLL->logMsg("xxxxx.log", szError); does not seems to be proper way to log in SDK...

There is some ways to show Dialogbox or Mesage Box.
But I want log to Text file like PythonDbg.log or PythonErr2.log.
There should be central, consistent and unified way to print log.
I've been creating my own logs using regular file I/O, as I couldn't seem to find an inbuilt way.
 
I have a function that I define in CvUnitAI.cpp, which I use for all debugging in that file:
Code:
void logMsg(char* format, ... )
{
	static char buf[2048];
	_vsnprintf( buf, 2048-4, format, (char*)(&format+1) );
	gDLL->logMsg("ai.log", buf);
}
I adapted this from the xml loader cpp I believe.
 
talchas said:
I have a function that I define in CvUnitAI.cpp, which I use for all debugging in that file:
Code:
void logMsg(char* format, ... )
{
	static char buf[2048];
	_vsnprintf( buf, 2048-4, format, (char*)(&format+1) );
	gDLL->logMsg("ai.log", buf);
}
I adapted this from the xml loader cpp I believe.

Then.. How about we agree upon log file name? Log file name like "sdk.log" or "gamecore.log" will be more general name to log all logging message from SDK. This will prevent prolification of multiple and arbitrary log file names.
 
SimCutie said:
What is proper way to print log message for debugging in SDK?

It seems that printf or fprintf(stderr,) won't print anything in SDK..
OutputDebugString(msg) Won't work too in RELEASE build...
gDLL->logMsg("xxxxx.log", szError); does not seems to be proper way to log in SDK...

There is some ways to show Dialogbox or Mesage Box.
But I want log to Text file like PythonDbg.log or PythonErr2.log.
There should be central, consistent and unified way to print log.

I created a small Python Looback from cpp using CvGameUtils.py. This adds SDK debugs to the PythonDbg.log file with the prefix "DLL:" instead of "PY:".

Add this piece of C code somewhere where it fits (I used an own file for tools):

Code:
#include "CvGameCoreDLL.h"
#include "CvGlobals.h"
#include "CyArgsList.h"
#include "CvDLLPythonIFaceBase.h"

void dllDebug(char* szMessage)
{
	CyArgsList argsList;
	argsList.add(szMessage);
	long lResult=0;
	gDLL->getPythonIFace()->callFunction(PYGameModule, "dllDebug", argsList.makeFunctionArgs(), &lResult);
};

Add this to CvGameInterface.py :
Code:
def dllDebug(argsList):
	return gameUtils().dllDebug(argsList)

Add this to CvGameUtils.py :
Code:
	def dllDebug(self, argsList):
		printToScr = True
		printToLog = True
		message = argsList[0]
		if (printToScr):
			CyInterface().addImmediateMessage(message,"")
		if (printToLog):
			message = 'DLL:' + message + "\n"
			sys.stdout.write(message)
		return 0

Its a bit quick and dirty and needs to be modfied to you belongings, but it works. It has the major advantage, that its not event based so the call-order is reflected in the log file and, of course, you can use the same log without getting file access violation.
 
Does anyone here have any good ideas about how to post small mods which need be done using the SDK? I'm going to post my 4 modified source files somewhere, but the dll is too big to be posted for a small mod. Of course, hardly anyone will download and compile the stuff delivered that way. I think posting a dll is awkward as you can't merge two dll's together so we're stuck with compiling everytime.
I wonder if it would be possible to set up a server with a set of mods (modified files) and let the would-be downloader check which mods they want (they'd have to be compatible together, i.e. do not modify the same files) and let the server compile a dll, zip it and give it to the player? Does anyone know of something like that for any kind of project or am I daydreaming?
 
LDiCesare said:
Does anyone here have any good ideas about how to post small mods which need be done using the SDK? I'm going to post my 4 modified source files somewhere, but the dll is too big to be posted for a small mod. Of course, hardly anyone will download and compile the stuff delivered that way. I think posting a dll is awkward as you can't merge two dll's together so we're stuck with compiling everytime.
I wonder if it would be possible to set up a server with a set of mods (modified files) and let the would-be downloader check which mods they want (they'd have to be compatible together, i.e. do not modify the same files) and let the server compile a dll, zip it and give it to the player? Does anyone know of something like that for any kind of project or am I daydreaming?

It seems that we need some kind of satellite DLL facility.
Using this facility, the main DLL (CvGameCoreDLL.dll) will dynamically load smaller set of DLL's on request of Python part of MOD. Then mod which does not modifies existing code but only addes some function to main DLL can be distributed as smaller satellite DLL.
Such a dynamic loading of DLL is used by many large program or game, so I think that it is also possible with Civ4. But it may take time to develop generally usable dynamic DLL loading facility for Civ4.
 
Back
Top Bottom