An Idiots Guide to Editing the DLL

[xienwolf]

I haven't personally used the event reporter yet. But what you have for the DLL side does seem to work. I would wonder if you have everything proper in the python in that case.

You defined the function to call in self.EventHandlerMap? Then created your def to match?

 

[The_J]

Yes, i did.

'setTerrainType'			: self.onSetTerrainType,

and

def onSetTerrainType(self, argsList):
		eNewValue = argsList[0]
		bRecalculate = argsList[1]
        bRebuildGraphics = argsList[2]

I'm not sure, if there's no typo, but would a misspelling lead to a crash without an error?

 

[xienwolf]

First element from the argslist is pPlot, not eNewValue. Would possibly cause errors if you use them wrong, and when the map is made this will fire a LOT of times, so pile enough small errors and it might crash. But if you don't have any actual code yet (instead just have the definitions posted so far), then just declaring the variables won't cause a crash

 

[The_J]

First element from the argslist is pPlot, not eNewValue.

Would possibly cause errors if you use them wrong, and when the map is made this will fire a LOT of times, so pile enough small errors and it might crash.

I think atm, that i've placed the...event-report (?) at the false place in the function, so that it fires every time, when the function is called, also at the beginning, when there is no plot.
Maybe this is the mistake.

And the performance when creating the map: Sure you're right, but it doesn't matter, i need the function.

You say it is right, so it is right , it gives me a bit self-confidence.
Thanks for the help .
I'll try it again tomorrow, let's see, what happens.

But if you don't have any actual code yet (instead just have the definitions posted so far), then just declaring the variables won't cause a crash

I've only written the print-statement for all variables after the code, and i could have interpreted the python errors, so that's not the problem.

 

[ZachScape]

Where can I extract Notepad++? Once I download it, I don't know what to do with it.

 

[Gooblah]

Quick tip/pointer:
CvTeamAI: includes capitulation mechanics (such as land target definition, power measurements, etc), voluntary vassalage, trade denials, etc.

When in CvTeamAI, DENIAL_[insert phrase] simply refers to the message the AI will give when an option is 'redded out'. Thus, NO_DENIAL (always with human, and with some trade options relating to vassals) means that the option is never 'redded-out'. The rest tend to be self-explanatory.

 

[xienwolf]

Copy/Pasted that into the description for CvTeam file introduction Could well prove useful to quite a few modders

 

[phungus420]

I've tried the instructions for adding a boolean tag, but it crashes on loading the first step in the adding tags process. Only edited in the information to the XML schema (works fine), and CvInfos (.h & .cpp). I can't figure out what I'm doing wrong here, have tried it about 7 times now, and while it compiles fine, it crashes when initializing the XML. Here is the post in SDK/Python forums:
http://forums.civfanatics.com/showpost.php?p=8040290&postcount=3

I don't know why, but it wanted me to compile a whole fresh new gamecore... so frustrating that takes like an hour and a half...

 

[xienwolf]

Any time you change anything in the header files (*.h) you MUST do a full recompile.

 

[phungus420]

Any time you change anything in the header files (*.h) you MUST do a full recompile.

That makes things take alot longer...
Thanks though for that clarification. That might be the cause of my error at the moment...

 

[xienwolf]

It does get annoying. Once you get accustomed to the DLL though you can usually predict what header file changes you need in advance and write all of them on the first go through. Then you sit down to work on the main working code and have quick compile times for the rest of things.

 

[phungus420]

Xienwolf any chance you could write your exposing to python tutorial next? I've added a couple new XML tags, and would like to expose their generated effects to Python (not just the tag itself, but the get and such functions that go along with them). It's not essential at this point in time, but I'd consider it cleaner, and would help with the overall utility of the code.

 

[xienwolf]

The python part will be for python callbacks, allowing Python to override a function or add input in the middle of it. The other parts, checking data on a new building or on a player/unit, are going to be included as I place data on them, it is everything which happens in the Cy____ files, with the Cy___Interface being the most important piece of the puzzle.


About 2 weeks now till I can return to full modding mode and get some more material written both here and in my personal modding endeavors

 

[xienwolf]

Bah, silly forum burping double-posts...

Anyway, if you meant something other than what is in the end of the first boolean tutorial, let me know and I'll make certain to cover it in some manner soonish.

 

[phungus420]

Well, actually I have added a new integer iUpgradePriceModifier to buildinginfos, basically took Tstentom's Leonardo's Workshop and moved it over the SDK from Python (also as a side note I just followed the Boolean tag example, pretty similar with integers, just referenced other integer functions in the SDK to see what needed changing, but it's pretty much the same). It's cleaner this way, and I also wanted to make another change. Also this allows for easier modibility for any mod moders, if anyone ever starts modding Legends of Revolution. I was more wondering how to expose the integer that is set in the XML to python, so that other moders, or myself could reference it in Python code if it is convient. It just seems like one of those tags which should be exposed.

 

[xienwolf]

Referencing a loaded XML value happens through the Cy____ files, so it was covered at the end of the Boolean example. For BuildingInfos changes that would only involve CyInfoInterface(1, 2 or 3).cpp (single line addition). For that particular type of a field, probably you also want to expose a new field in CvPlayer, which would be through CyPlayerInterface.cpp, CyPlayer.cpp and CyPlayer.h (single line in ___interface, single function in the other 2).

Really the exposing to python is such a small and simple step for new XML fields and tracker values that it is easy to overlook and/or mess up by simply forgetting about it Just 6 lines total, 2 of which are just { or }.

 

[phungus420]

OK, here is another question. I'll just go by example here as it'll explain exactly what I'm asking, I don't know how to ask this more simply.

In RevolutionDCM, the Revolutions Component adds an XML tag to the Civilizations section, it is found in CivicInfos. Now I want to clone this tag into LeaderheadInfos. I know I'll need to edit the CivilizationsSchema file, but I'm wondering since the tag is already loaded in CvInfos through the Civilizations section, if I'll need to also modify the dll, or if it'll just load the cloned tag. If it does load the cloned tag, will it add it (ie the Civilization is running a civic that provides a penalty to Revolutions, but their leadertrait adds a bonus will it add these together), or will it just overwrite the previous value with whatever it reads last? If it does overwrite, is there anyway to get it to add the value of the cloned tag, or do I need to create an entirly new variable and tag, even though I want it to do the exact same thing?

 

[xienwolf]

Yes, you MUST modify the DLL any time you add a new tag. Having the tag already exist means that the functional portion is simpler (places in the code it does something) because you just need to read from an additional location (though sometimes even that is complicated enough). It is actually in the Schema where you have the most work saved, in that you don't have to define what goes in the tag again (if you stay in the same Schema at least), but just say where to place things.


I finally seem to have things sorted out in my lab, so soon I should be doing dataruns, which means a couple of minutes where I have little else to focus on. Ideally I will be able to write some then, and I might jump straight to the Integer and Array fields since I have a few to write myself. I am attempting to stick to things which use the base BtS code so that someone who reads this can follow every step and compile along the way successfully, but unfortunately I am far more familiar with my own code and there are SO many tricks available in it which aren't there in BtS, so it takes me a while to "dumb down" my approach to handling things so that it is possible with native Firaxis code. But I will endeavor to have some more written semi-soonish.

 

[phungus420]

So I will need to name it something else then I'm assuming? I can't use the exact same variable name, that just doesn't seem right

Or rather in the XML I can use the same thing, but when I load these into CvInfos, I should split the two into something like m_RevDistanceModTraits and m_RevDistanceModCivics so that I don't run into any conflicts later in the code.

 

[xienwolf]

You can use the same variable name actually. The computer can tell the difference because they "live" in different places. It's like having 2 friends by the name of Jones. If you call Jones Sampson's house and ask for Jones, his mother isn't going to tell you that regretfully Jones Henry isn't available, but she can maybe send her son out to check the local park for him. She'll naturally hand the phone to her own son.

The "Full name" of your field will be something like:

CvLeaderHeadInfos::m_RevDisanceModCivics

as opposed to his

CvCivicInfos::m_RevDistanceModCivics


Of course, in this case having CIVICS in the name of something attached to a LEADERHEAD can get confusing for people who use your code (to include yourself later on down the road), so it might be worth changing the name. Though I personally would just drop the last word out so it is simply m_RevDistanceMod