Thoughts on a community DLL

[whoward69]

It's something you're doing wrong then

You'll get better results if you actually use the DLL in the mod

... import="[COLOR="Red"]0[/COLOR]">CvGameCore_Expansion1.dll</File>

(Needs to be 1, ie VFS=true)

 

[Hambil]

It's great that it works in Firetuner, but I don't understand why it doesn't work in DoXY. I can't write my mods in Firetuner.

 

[Hambil]

You'll get better results if you actually use the DLL in the mod

... import="[COLOR="Red"]0[/COLOR]">CvGameCore_Expansion1.dll</File>

(Needs to be 1, ie VFS=true)

I switched it to use your DLL for testing.
I don't need to import yours, it's a stand alone mod. I checked the xml switches and unless I missed something (which is always possible) there wasn't one I needed to enable for this? Edit: Appears to be enabled (1) by default...

 

[whoward69]

Still something you're doing, see FireTurner output in post #69

 

[Hambil]

I stripped it down to nothing but this:

function DoXY(iPlayer, iUnit, iX, iY)
	pPlot = Map.GetPlot(iX, iY)
	print(pPlot:GetOwner())
end

GameEvents.UnitSetXY.Add(DoXY)

5 lines of code is now literally the entire project, with your DLL enabled (or mine doesn't matter). So if I'm doing something wrong I am totally lost.

 

[Pazyryk]

Are you always seeing cityID=8192? I'm not sure but I believe I've seen that integer used for every civ's initial city.

 

[Hambil]

Yes, that's the value. If I switch to getting the plot from the unit, like in the firetuner example, I still get the same results. Hmmm. I'm going to try one more thing... could still be my stupid

 

[Hambil]

Okay, the problem seems to be neither usage, or a bug, but just my confusion over what the numbers meant (realizing cities don't have unique ids, but are a composite id for example). Gah. Okay, well, how frustrating. Sorted now thank you. I guess the good news is the mistake was not in the DLL I built, it was in my HEAD

 

[Hambil]

I may have found a place to start. I will know more as I get deeper into the code. There appears to be a missing iterator in Teams (actually, this type of method seems missing on many objects). I propose that I add a method of the form

iterator(Player)	Players()

To the Team class.

 

[Hambil]

Possible Tools (I just need to make sure they can't be done in lua, and can be done in the dll):
Create ability to open any popup from a notification
Create the ability to add new end turn blocking notifications

(Just keeping track so I don't forget)

 

[S3rgeus]

Create ability to open any popup from a notification
Create the ability to add new end turn blocking notifications

I'm planning to do this as a part of making the notification system more flexible for my mod and I'd be happy for the changes to be folded into a community DLL. I'm hoping to be able to specify new notifications via XML/SQL and simplify 'sending' a notification to a player by sending an ID (from the new Notifications table) and then some other parameters that will likely be necessary. I've done a bit of looking into the changes necessary and it looks doable, but I've still got to work through the whole thing, I'm just finishing up some other features first.

EDIT: Ok, looks like this is the next thing I'm working on! I'll take a first stab at it later this evening. Given the number of files this affects I doubt my first attempt will work properly. I'll let you know how it goes.

Also, feel free to add my custom mission code to the community DLL.

 

[Hambil]

Also, feel free to add my custom mission code to the community DLL.

I think that would make a great addition! Thank you.

 

[Pazyryk]

I'm very supportive of this effort. Not sure what I can contribute (never coded C++ yet) but I'll be happy to be a cheerleader. Just some random thoughts:

Keep in mind that there will be new dlls with the new expansion. Not just for the expansion, but also new vanilla and G&K dlls. From past experience, maybe one or two before release and one or two after (I'd guess a final one around December). Firaxis has sometimes been slow to release source with these updates, so dll mods can be left in the lurch for a while.

Keep it as modular as possible. Any single mod may want only one or two added features, and you don't want the other 100 non-used features slowing things down. Ideally, one should be able to drop the dll into base game with no effect at all on gameplay or performance.

 

[Hambil]

I agree, though some small performance hits may be unavoidable, it is a goal we should always have; to keep performance high.

Of course, in a compiled language, the true method for keeping things modular is compiling different branches of the code, or compiling with only the features you want. But because we have this "one DLL to rule them all" restriction placed upon us by Fieaxes, the best we can hope for is flexible runtime design (and xml switches perhaps, as Whoward uses).

The two biggest ways I can see non c++ programmers contributing are suggesting ideas (you're already doing that) and helping playtest fixes and tools. Also, in making sure things we fix or add to the DLL really need to be done via the DLL, and aren't just somebody's lack of knowledge of other parts of the system.

Once I get clear of my current project (Army Upgrade) and it's conjoined tutorial I plan to start to develop some phases and hopeful time tables for this project.

 

[Hambil]

There are some tools we might consider adding even though they can be done in lua. This category would be tools that extend the xml capabilities of the system. I think this reaches a much broader potential group of modders than trying to get them to understand or use lua.

One sample thought for such a tool might be allowing users to add more flexible traits to civs without requiring them to mod 'hidden buildings' and other tricks.

 

[Hambil]

Fix(?) have improving bananas no longer remove the jungle.

 

[Pazyryk]

Of course, in a compiled language, the true method for keeping things modular is compiling different branches of the code, or compiling with only the features you want. But because we have this "one DLL to rule them all" restriction placed upon us by Fieaxes, the best we can hope for is flexible runtime design (and xml switches perhaps, as Whoward uses).

Is this really not an option? I only need one dll for my mod and there is no reason it has to match anyone else's. But that's my perspective for a total conversion mod. From the pick & mix perspective, I guess you want one single community dll with xml switches. Too much work to try to do both.

Fix(?) have improving bananas no longer remove the jungle.

This is totally controlled and accessible via xml, though the restriction is on plantation improvement. But you could make a "banana plantation" improvement that doesn't remove the feature if you really want it, so no need for dll modding here. The silly thing about bananas is the -1p for building plantation on it (which, combined with the long build time and -2s from university makes it not a good idea). But this also is completely accessible via xml modding.

One sample thought for such a tool might be allowing users to add more flexible traits to civs without requiring them to mod 'hidden buildings' and other tricks.

This would be very welcome. Though I'm not sure that a dll solution is easier than a Lua solution. I have "hidden" xml tags for buildings, techs and promotions that are all implemented through Lua.

The only one that is very challenging (via Lua) is policies since giving these out mucks up your policy progression. I had to implement a very mod-specific solution for that. Would be nice if there was an xml policy tag "HiddenAndNotCounted".

 

[Hambil]

Is this really not an option? I only need one dll for my mod and there is no reason it has to match anyone else's. But that's my perspective for a total conversion mod. From the pick & mix perspective, I guess you want one single community dll with xml switches. Too much work to try to do both.

It doesn't (shouldn't) be an either or. The community dll would be the bases for your total conversion DLL (if you wanted) and you could branch off that and add your changes (in a private branch even if you wanted to keep them from being messed with). That way your total conversion DLL is only having to code what isn't in the community DLL.

This is totally controlled and accessible via xml, though the restriction is on plantation improvement. But you could make a "banana plantation" improvement that doesn't remove the feature if you really want it, so no need for dll modding here. The silly thing about bananas is the -1p for building plantation on it (which, combined with the long build time and -2s from university makes it not a good idea). But this also is completely accessible via xml modding.

Great, one less things to worry about then. See, this is exactly how you can be very helpful Thanks.

Edit: You can make fixes for those things in lua, but if I understand correctly you can't say to a xml coder 'if you have this mod enabled' it changes or enhances the XML in such and such a way.

 

[whoward69]

Is this really not an option?

If you're willing to build your own DLL from source and the modder(s) wrote the code with this in mind (as I have done for my DLL) it's easy.

The entries in the CustomModOptions.xml file allow mod writers to turn on/off features at will from XML/SQL/LUA. If however you just want a cut-down version of the DLL with only specific features enabled and are willing to rebuild the DLL, you can comment out / remove the #define statements in the CustomMods.h file and all the unwanted code goes away.

 

[Pazyryk]

Ah! I think I'm beginning to comprehend. Both the idea of compiling mod-specific dlls and using git to do that. Very nice!