Modder's Documentation

[Dancing Hoskuld]

Anyone know what the name of the interface is for the available building list at the bottom when a city is selected? Can't seem to find it anywhere! lol.

Assets/Python/Screens/CvMainInterface.py

 

[Thunderbrd]

Anyone know what the name of the interface is for the available building list at the bottom when a city is selected? Can't seem to find it anywhere! lol.

You might have to look for that in the python files. I have never been sure if it's the 'city bar' or if that refers to the city help popup.

Assets/Python/Screens/CvMainInterface.py

There's a lot more than just that in this file though.

 

[makotech222]

Yeah i looked in there previously, couldn't really find what i was looking for. Specifically looking for click event when you click on an available building and it gets added to queue. Ill take another look through.

Another question. Does the civ4 engine host the python environment? Or it it entirely contained in the .dll?

 

[Dancing Hoskuld]

Yeah i looked in there previously, couldn't really find what i was looking for. Specifically looking for click event when you click on an available building and it gets added to queue. Ill take another look through.

Another question. Does the civ4 engine host the python environment? Or it it entirely contained in the .dll?

As far as I know all click events are handled by the exe and then passed to both the dll and the python.

The Python code is written in a way that it watches for things like the click event then "sends a message event" out which the other Python modules can catch and act on. However this is not done consistantly there even seems to be more than one set of code that does this. Platyping cleaned the code up a lot just after we included a version of his World Builder. If we updated to his latest version we would get all that too, but it is not straight forward.

There's a lot more than just that in this file though.

Which is another reason it should be split up.

 

[makotech222]

Darn, was hoping the exe didn't touch the python at all.

Whats the extent that the exe sends stuff directly to python? Does python send anything back to exe?

 

[Dancing Hoskuld]

Darn, was hoping the exe didn't touch the python at all.

Whats the extent that the exe sends stuff directly to python? Does python send anything back to exe?

I am not entirely sure. I may have the wrong end of the stick and it is the dll is the link between the Python and the exe. However the Python does call the exe directly as far as I can tell otherwise we would have some documentation about what the parameters mean.

 

[makotech222]

Hmm, if the Python is calling the exe directly, then I would assume that there is a hard link between .exe and python, where it would crash if that python function wasn't there

 

[Thunderbrd]

Yeah i looked in there previously, couldn't really find what i was looking for. Specifically looking for click event when you click on an available building and it gets added to queue. Ill take another look through.

Ah... you're looking for a spot in the code if you're talking specifically about the building lists. Take a look at CvBuildingFilters.cpp. You can probably find your way through to what it is you're looking for from a study there.

 

[makotech222]

Yeah, doesn't seem like that particular click event is handled in the python side, at least, in that specific .py file.

 

[Dancing Hoskuld]

Yeah, doesn't seem like that particular click event is handled in the python side, at least, in that specific .py file.

Those are in the various files in Python/EntryPoints, but as I mentioned they are not straight forward and we have the BUG layer in the mix as well.

 

[makotech222]

Hmm, my first task i'm looking into is optimizing the time it takes to push buildings into the queue. When the available building list is large (which is very often in c2c), each click takes > 2 seconds to add building to queue.

I've followed the code up to the highest root i can find:
void CvNetPushOrder::Execute()

If i comment out all the code inside, the function speeds up a bit, but there still seems to be a significant lag. I don't know what else is being called when you click on a building. Maybe python side? Would appreciate some help

 

[Toffer90]

Hmm, my first task i'm looking into is optimizing the time it takes to push buildings into the queue. When the available building list is large (which is very often in c2c), each click takes > 2 seconds to add building to queue.

I've followed the code up to the highest root i can find:
void CvNetPushOrder::Execute()

If i comment out all the code inside, the function speeds up a bit, but there still seems to be a significant lag. I don't know what else is being called when you click on a building. Maybe python side? Would appreciate some help

That is caused by the fact that the entire city screen is redrawned by python every time you click something inside the city screen.
My python modmod optimizes that part so you may wan't to test the performance with my python performance modmod installed.

Not only does it redraw, the python also asks the dll if all the buildings in the game are built in this city one building at a time every time you click something in the city screen.
It also asks if all the resources in the game are available to the city one resource at a time.... and so on.
It does these things to rebuild the built buildings and resource lists.
My modmod makes the python cache all this info and only build the lists when needed.

 

[makotech222]

Heh, I am using your mod too I don't remember what C2C is like before your mod, too, so i imagine its way worse. Can I ask, where this call is started from? I'd like to follow along the code to see what its doing and see if I can optimize it any further.

 

[Toffer90]

Let's see, I'll go to the beginning then.

This function in CvMainInterface.py builds the selection buttons.

def updateSelectionButtons(self, screen, yRes, yBotBar, bCityScreen, enum):​

Building buttons are given the widget WIDGET_CONSTRUCT. (unit buttons would have the widget WIDGET_TRAIN)
That means that when the button is pushed the stick gets past along to CvDLLWidgetData.cpp.
In there it will connclude that the case is WIDGET_CONSTRUCT, and will then call the doConstruct(); function.

The doConstruct() function will in most cases do this:
GC.getGameINLINE().selectedCitiesGameNetMessage(GAMEMESSAGE_PUSH_ORDER, ORDER_CONSTRUCT, eBuilding, -1, false, gDLL->altKey(), bShift, gDLL->ctrlKey());
Which probably leads to the "void CvNetPushOrder::Execute()" you mentioned in your previous post.

Somewhere along the line there will be some flags raised that will inform the CvMainInterface.py that it is time to redraw the city screen and such.
It looks like this when the flag is raised within python
CyInterface().setDirty(InterfaceDirtyBits.CityScreen_DIRTY_BIT, True)
but I'm sure it looks quite similar when the flag is raised from the dll.

 

[makotech222]

Hmm interesting. When i was mucking around in the CvNetPushOrder, I commented out the calls to redraw the python interface (and set it dirty). Ill have another look through what you posted and see if there are any other calls somewhere. Thanks a lot!

 

[Toffer90]

Maybe what is taking time is within these functions which are also called by the doConstruct function:

gDLL->getInterfaceIFace()->setCityTabSelectionRow(CITYTAB_BUILDINGS);
pCity->setBuildingListSelectedBuilding(eBuilding);
​

I think the core mechanics of the interface UI and the interaction with them as a widget, are controlled mostly by the exe. So maybe there is some general slowness when there's a lot of interface with a lot of one type of widgets placed inside a UI list like the selection buttons are. Erm, my point being that it may just be a shortcoming in the exe code that we can't do much about.

I like that you are looking into this on the dll side btw. I only work on the python side, and when doing so, I sometimes wonder if there could be made important optimizations on the dll side (but I rarely investigate it since I'm not so familiar with all the dll code involved).

 

[makotech222]

Hmm, Aren't there interface widgets controlled entirely by python? I suspect at the least, we could empty out the widget controlled by the exe and just create our own entirely.

 

[Toffer90]

Hmm, Aren't there interface widgets controlled entirely by python? I suspect at the least, we could empty out the widget controlled by the exe and just create our own entirely.

I've seen one case... Don't remember exactly where or what.
A widget defined in XML which is designed and set up through the BUG system. I could look into it, see how that widget operate and what limitations, or extensions, it has compared to the vanilla widget stuff.

 

[makotech222]

Heh, I tried commenting out all of doConstruct. There is still that significant lag when a building is clicked. Guess Ill keep investigating for now. Do you know where on the python side the click event is first generated?

 

[Toffer90]

Heh, I tried commenting out all of doConstruct. There is still that significant lag when a building is clicked. Guess Ill keep investigating for now. Do you know where on the python side the click event is first generated?

Input is handled by the exe as far as I know, when a widget UI is clicked the exe will initiate the CvDLLWidgetData.cpp for the widget interaction, whether it does anything else is unknown as it is a black box.
The dll may or may not involve python code for a particular widget interaction, but mostly it is only the WIDGET_GENERAL type UI elements that are handled by python in a function called handleInput().