Making the Python Files More Modular

Jon Shafer

Jon Shafer

Civilization 5 Designer
Joined
Jul 14, 2002
Messages
2,102
Location
Maryland
Hey guys.

One of the things we're hoping to do with the next Civ 4 expansion pack is ease the merging of different mods together. One way of doing that would be to split some of the stuff (probably from CvEventManager and CvGameUtils) into different files so that mods won't conflict so often.

But to be honest, we're not the mod-making experts, you guys are. :) What structural changes to the Python system would make merging mods easier for you guys?
 
Well one thing which is used by many modders at the moment is Dr. Elmer Jiggle's python comp which allows you to merge together different CvCustomEventManager.py's. I suppose that splitting CvameUtils into several smaller files would be useful, but I don't use them much so I can't really say.
The only thing which is really a pain to merge is SDK files and XML, but I don't see how this could be improved.
 
Trip said:
Hey guys.

One of the things we're hoping to do with the next Civ 4 expansion pack is ease the merging of different mods together. One way of doing that would be to split some of the stuff (probably from CvEventManager and CvGameUtils) into different files so that mods won't conflict so often.

But to be honest, we're not the mod-making experts, you guys are. :) What structural changes to the Python system would make merging mods easier for you guys?
Click to expand...

1. Ideally modular xml files would be a godsend. The dream of being able to have Civ4UnitInfos1.XML, Civ4UnitInfos2.XML, Civ4UnitInfosPirateShip.XML, etc etc would be amazing.

Mostly because it would allow component makers to package their unit/tech/building/whatever as a stand alone product for non-mod makers. A player could go out and download the unit he likes (lets say ninja UU for Japan) that comes complete with an addon Civ4UnitInfosNinja.xml, Civ4UnitclassInfosninja.xml, Civ4ArtDefinesninja.xml and a text file and be off and running. Even better he could download a stack of different units from different players and be able to pick and choose which ones he wanted to use easily.

2. The most important python function should call out to seperate functions. combatResult, onUnitMove, onBeginPlayerTurn, onUnitCreated, onUnitPromoted, onImprovementBuilt from CvEventManager and cannotResearch, cannotDoCivic, cannotTrain, cannotConstruct and cannotCreate from CvGameInterface. Ideally all of the function would call out seperatly.

In a dream world we would be able to put multiple copies of CvEventManager and the game would merge the function for each. So we could have a mod that adds xml files as in point 1 and includes a python file that modifies the onUnitMove function (for example). That function wouldn't replace, but owuld be an additiive to the base onUnitMove and other mods onUnitMove functions.

3. Tying these all together should be a tag that identifies the various files/changes that are from one component. In the game menu it should be possible to add or remove components without having to change files. Such that a player could go in and see a checkbox with "Ninja" by it that he can select to use or not use. Deselecting that option would remove all xml and python changes that component applied.

4. I suspect that this would all be easier if their were differing Assets directories for each component. So you would have 'Assets' for the normal replacement stuff and 'Assets.ninja' for that component, etc. Of course you guys are better at the details of implementation.

5. Yeah I know prereqs are going to be a problem. I dont think there is any way around that and conflicts in any system where you try to allow modularity. But if people are clear as to the required base (Civ4, Warlords, Sevomod, Fall form Heaven, etc) they should be able to add and remove optional components easily with a system similar to this.
 
Lord Olleus said:
Well one thing which is used by many modders at the moment is Dr. Elmer Jiggle's python comp which allows you to merge together different CvCustomEventManager.py's. I suppose that splitting CvameUtils into several smaller files would be useful, but I don't use them much so I can't really say.
The only thing which is really a pain to merge is SDK files and XML, but I don't see how this could be improved.
Click to expand...
Yeah, unfortunately getting the SDK and XML stuff to merge more easily would be a huge challenge. Getting Python mods together is less of a challenge, so we'll make improvements where we can.
 
The model for merging xml files is already in place. It is used to allow modular text files.

from CvXMLLoadUtilitySet.cpp:
Code: 
	CvCacheObject* cache = gDLL->createGlobalTextCacheObject("GlobalText.dat");	// cache file name
	if (!gDLL->cacheRead(cache))
	{
		bool bLoaded = false;

		if (!CreateFXml())
		{
			return false;
		}

		//
		// load all files in the xml text directory
		//
		std::vector<CvString> files;
[b]		gDLL->enumerateFiles(files, "xml\\text\\*.xml");[/b]
		int i;
		for(i=0;i<(int)files.size();i++)
		{
			bLoaded = LoadCivXml(m_pFXml, files[i]);	// Load the XML
			if (!bLoaded)
			{
				char	szMessage[1024];
				sprintf( szMessage, "LoadXML call failed for %s. \n Current XML file is: %s", files[i].c_str(), GC.getCurrentXMLFile().GetCString());
				gDLL->MessageBox(szMessage, "XML Load Error");
			}
			if (bLoaded)
			{
				// if the xml is successfully validated
				if (Validate())
				{
					SetGameText("Civ4GameText", "Civ4GameText/TEXT");
				}
			}
		}

		DestroyFXml();

		// write global text info to cache
		bool bOk = gDLL->cacheWrite(cache);
		if (!bLoaded)
		{
			char	szMessage[1024];
			sprintf( szMessage, "Failed writing to Global Text cache. \n Current XML file is: %s", GC.getCurrentXMLFile().GetCString());
			gDLL->MessageBox(szMessage, "XML Caching Error");
		}
		if (bOk)
		{
			logMsg("Wrote GlobalText to cache");
		}
	}	// didn't read from cache
	else
	{
		logMsg("Read GlobalText from cache");
	}

	gDLL->destroyCache(cache);

	return true;
 
It might make sense to pull the Plot list out of the CvMainInterface.py.

I am not sure pulling CvEventManager apart is necessary. The existing method pioneered by Dr. Elmer Jiggle is more than adaquate.

I would be concerned with too many major changes to the exisiting structure. The changes would have to have enough long term benefit to offset the short term effort to change all the affected Mods.

Is the thought that Vanilla and Warlords would be patched to match? How about incorporating some of the advisor mods into the game?
 
Denniz said:
Is the thought that Vanilla and Warlords would be patched to match? How about incorporating some of the advisor mods into the game?
Click to expand...
No, the structure changes would be unique to the 2nd Expansion. Part of the plan is also to incorporate mods from here (I actually have another thread on that in this forum about that :)).
 
...wow... this is the most encouraging and thrilling thread I have seen since Civ4 hit the shelves.....
 
Kael said:
1. Ideally modular xml files would be a godsend. The dream of being able to have Civ4UnitInfos1.XML, Civ4UnitInfos2.XML, Civ4UnitInfosPirateShip.XML, etc etc would be amazing.

Mostly because it would allow component makers to package their unit/tech/building/whatever as a stand alone product for non-mod makers. A player could go out and download the unit he likes (lets say ninja UU for Japan) that comes complete with an addon Civ4UnitInfosNinja.xml, Civ4UnitclassInfosninja.xml, Civ4ArtDefinesninja.xml and a text file and be off and running. Even better he could download a stack of different units from different players and be able to pick and choose which ones he wanted to use easily.
Click to expand...

You might want to use this:
http://forums.civfanatics.com/showthread.php?t=184907

Matze
 
Seems I droped out of moding just a bit too early. :rolleyes: I've done some some simple extentions onto Chinese Americans code and basicaly produced the kind of functionality that Kael is describing with a whole unit packed into a folder you drop into Assets. It has'nt realy caught on as you need a custom DLL to use it and all the content in XML currently in existence needs be converted inorder to work with it so theirs a chicken-egg problem. If the functionality were in the next expantion then it would realy take off majorly!

Theirs a catch when if comes to buildings theirs a file the Civ4CityLSystem.xml which seems to be completly bypassing the DLL, presumably geing read by the .exe or the graphics engine. This makes it impossible to achive full modularity with a custom building. I belive improvments suffer a similar fate due to Civ4PlotLSystem.xml, if the data on these files could be read through the normal BuildingInfo it would allow for full modularity.
 
Kael said:
1. Ideally modular xml files would be a godsend. The dream of being able to have Civ4UnitInfos1.XML, Civ4UnitInfos2.XML, Civ4UnitInfosPirateShip.XML, etc etc would be amazing.

Mostly because it would allow component makers to package their unit/tech/building/whatever as a stand alone product for non-mod makers. A player could go out and download the unit he likes (lets say ninja UU for Japan) that comes complete with an addon Civ4UnitInfosNinja.xml, Civ4UnitclassInfosninja.xml, Civ4ArtDefinesninja.xml and a text file and be off and running. Even better he could download a stack of different units from different players and be able to pick and choose which ones he wanted to use easily.
Click to expand...

A resounding YES to this one. I don't mod simply because I cannot be bothered (simply no time because of work and the rest of my life), but I'd like to use other people's mods. As it is, it is too much work to go and edit all the standard files in order to add one unit, so making unit (and building etc.) addition as simple as "drop it in and go" would be, well, a deity-send!

Adding the functionality of the above-mentioned mod (by ChineseAmerican) into the base code would do this pretty nicely.
 
Denniz said:
It might make sense to pull the Plot list out of the CvMainInterface.py.

I am not sure pulling CvEventManager apart is necessary. The existing method pioneered by Dr. Elmer Jiggle is more than adaquate.

I would be concerned with too many major changes to the exisiting structure. The changes would have to have enough long term benefit to offset the short term effort to change all the affected Mods.

Is the thought that Vanilla and Warlords would be patched to match? How about incorporating some of the advisor mods into the game?
Click to expand...

What I think Denniz means is that CvMainInterface.py is not that you should remove plot list enhancements, but that the file itself way too big and too complicated. The parts that deal with the city screen and with the worldbuilder really need to be refactored into separate files, if not separate screens.

While you are at it, we could really use some better documentation of class CyGInterfaceScreen, which is not in the SDK.
 
You must log in or register to reply here.

Similar threads

AW Arcaeca
[BTS] Help with modular loading of resources from the Resource Mod
Replies
0
Views
843
AW Arcaeca
AW Arcaeca
rsc2a
(7a) VP Events Overhaul (Expansion Pack system)
2
Replies
27
Views
3K
APLion
A
C
[BNW] Unlock existing UU & UB for an existing civ ( especially shoshone pathfinder )
Replies
4
Views
301
Caocao84
C
Taefin
Second Impressions: More than the sum of its parts.
Replies
8
Views
970
Taefin
Taefin
Recursive
VP Community Roadmap/Vision Brainstorming
2 3
Replies
54
Views
4K
N.Core
N.Core
Top Bottom