Thoughts on a community DLL

[Hambil]

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.

We will definitely be designing it that way. Just best practices IMHO. It's minimal effort for maximum reward.

 

[S3rgeus]

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.

Unfortunately I spent way longer than I should have fixing another bug and it got too late for me to start this. The next time I'll be able to put a proper day into that is Wednesday after my next exam, but I'll give it a shot then!

Whoward's system of being able to switch off functionality via an XML file also sounds like a great one for the community DLL. People can re-compile if they want ultimate performance and the packaged up one with enable/disable-able features can be really helpful for those who don't want to/can't recompile it.

 

[Hambil]

I am a bit confused about one thing though. We have one DLL, shared by several mods. If one mod changes the xml settings they are changed for all mods, correct? I'd rather push functionality that requires this (has very high overhead even if not used) out of the community DLL altogether if possible. Or at least I think I would... I have to roll this one around in my head for a bit.

 

[S3rgeus]

There is a way around that. It's not quite as straightforward as just being able to depend on the community DLL, but you could make it so the XML spec (which says which functions are on/off) isn't a part of the git repository. Post it on the forums (in the community DLL's thread) and anyone can include it in their own mod to make the changes they want to the DLL when only they're running.

That does introduce compatibility issues though. I've only just thought of that. Argh!

 

[whoward69]

I suggest you check out how I use the on/off code. Just because something is compiled in doesn't mean it's used.

Take events. Say your community DLL has 40 more events added. If' no mod is listening for those events there is no point doing the costly C++/Lua context switches to send them. Most of my events default to "off", if a mod wants the event it switches on the corresponding group.

Same with most of the path-finding changes. If no mod is going to provided an Artic Corp (can cross ice) promotion there is no point spending the extra time in the path finding code checking that the unit has a promotion with the feature enabled.

And then there's the "one mans bug is another's feature". I hate the way ships that capture a city teleport to the nearest friendly city if that city is then razed to the ground and not an adjacent coastal tile. IMHO that's a bug, but some may call it a feature and not want that particular "bug" fixed in their game. Now you need to give control back to the player as to what is on/off.

 

[Hambil]

Smart usage sounds like a great idea. It doesn't solve the conflict between mods over one setting issue though. I suppose their will always be conflicts between mods, and it's really a combination of mod author and mod user issue, not the dll.

Still, it warrants further thought as we move forward.

 

[Hambil]

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.

I think this could work in our favor. Not from a standpoint of getting things done faster, but from the standpoint that a lot of developers will be updating their mods, releasing new mods, and for various reasons having increased interest in the DLL.

 

[Hambil]

When I finish my current Army Upgrade mod/tutorial I plan to put together a basic set of phases and plans and timelines for this. The first phase will be something like 'Define Features' and the second 'Code new Features' the third 'Play Testing' and finally 'Alpha Release'.

Since I am not a big believer in the waterfall method, these phases will overlap. Meaning, you can come up with the idea for a feature, code and test it, then move onto the next feature. The phases just give us a way of having overall project level milestones.

I will put together a nice document in color and all! Suggestions are welcome.

 

[Hambil]

BTW: One of the things I've liked about working on mods here is no pressure. So when I say timeline I mean something like target month. And if we hit it fine. It's just so we have some way of knowing when we are 'done' with our first attempt, rather than just keep tweaking and adding to it forever I swear I will not pressure anyone!

 

[S3rgeus]

When I finish my current Army Upgrade mod/tutorial I plan to put together a basic set of phases and plans and timelines for this. The first phase will be something like 'Define Features' and the second 'Code new Features' the third 'Play Testing' and finally 'Alpha Release'.

Since I am not a big believer in the waterfall method, these phases will overlap. Meaning, you can come up with the idea for a feature, code and test it, then move onto the next feature. The phases just give us a way of having overall project level milestones.

I will put together a nice document in color and all! Suggestions are welcome.

Github has some quite nice issue tracking and milestone setting features on their website for each repository. It makes it easier to keep track of what bugs need to be fixed at any one time and what features still need to be implemented. Plus it means you can reference issues/milestones from commits and interact with them that way. (I always enjoy closing issues from commits.)

 

[Hambil]

Sweet! I've got github setup and am working on understanding it enough in my own safe sandbox that I can than go play in others and not cause damage I will look into if the above phase document idea should just be folded into git-hub features.

 

[Hambil]

I'm working on "missing lua methods" starting with iterators. If someone wants to start (not necessarily coding - but that's up to them) on list of missing xml tags that would be great.

Basically, if it should be there and be easy (via lua or xml or both) then it's a missing method or xml tag. Whoever has knowledge and desire please start a Missing XML Tags post, like my Missing Lua Methods below. If I start it only I'll be able to edit it.

 

[Hambil]

Missing Lua Methods (please nobody point me toward Whoward's thread I'm very aware of it).

iterator(Player) Teamlayers()
iterator(Plot) Citylots()
iterator(Unit) Plot:Units()
iterator(BuildingType) City:Buildings()
iterator(Plot) CitylotUnitScan(int unitClassID = -1, bool bIgnoreFriendly = false, bool bIgnoreHostile = false)
iterator(Plot) CitylotResourceScan(int resourceTypeID = -1, bool bIgnoreImproved = false, bool bIgnoreHostile = false, bOnlyPillaged = false)
iterator(Unit) Player:UnitScan(unitClass = -1, combatClass = -1, bOnlyNeedsUpgrade = false, bOnlyObsolete = false, bOnlyAutomated = false)
iCity Plot:GetCity()

Grey = Needs discussion

 

[Hambil]

I want to work out a way to get smarter filtering into the DLL too. An example of what I have in mind (not a perfect example I'm still thinking through it all in my head). My reasoning being this kind of thing is way faster to do in c++. There are plenty of potential useful scans. Right now my example only shows unitClass but we could include combatClass as well, and domainType...

-- City:PlotUnitScan(int unitClassID = -1, bool bIgnoreFriendly = false, bool bIgnoreHostile = false)
-- Example 1: Scan for any hostiles
for pPlot in pCity:PlotScan(-1, true, false) do
    print(pCity:GetName() .. ' is under threat')
    break
end
-- Example 2: Scan for workers
for pPlot in pCity:PlotUnitScan(GameInfoTypes.UNIT_WORKER) do
   print(pCity:GetName() .. ' found a worker at ' .. pPlot:GetX() .. ', ' .. pPlot:GetY())
end

Another example using Player

-- Player:UnitScan(unitClass = -1, combatClass = -1, bOnlyNeedsUpgrade = false, bOnlyObsolete = false, bOnlyAutomated = false)
-- Example 1: Scan for units needing upgrades
for pUnit in pPlayer:UnitScan(-1, -1, true) do
    print(pUnit:GetName() .. ' needs to be upgraded.')
end
-- Example 2: Scan for obsolete melee units
for pUnit in pPlayer:UnitScan(-1, GameInfoTypes.UNITCOMBAT_MELEE, false, true) do
    print(pUnit:GetName() .. ' is an obsolete melee unit.')
end
-- Example 3: Find automated scouts
for pUnit in pPlayer:UnitScan(-1, GameInfoTypes.UNITCOMBAT_RECON, false, false, true)
    print(pUnit:GetName() .. ' is an automated scout.')
end

 

[Hambil]

Bug Fixes:

CvLuaCity.cpp

int CvLuaCity::lGetOrderFromQueue(lua_State* L)
{
	CvCity* pkCity = GetInstance(L);
	if(pkCity)
	{
		const int iNum = lua_tointeger(L, 2);
		OrderData* pkOrder = pkCity->getOrderFromQueue(iNum);
		if(pkOrder)
		{
			lua_pushinteger(L, pkOrder->eOrderType);
			lua_pushinteger(L, pkOrder->iData1);
			[B][I]lua_pushinteger(L, pkOrder->iData1);[/I][/B]
			lua_pushboolean(L, pkOrder->bSave);
			lua_pushboolean(L, pkOrder->bRush);
			return 5;
		}
	}
	lua_pushinteger(L, -1);
	lua_pushinteger(L, 0);
	lua_pushinteger(L, 0);
	lua_pushboolean(L, false);
	lua_pushboolean(L, false);
	return 5;
}

Should either be pushing iData2 or nothing, since this exists solely to send data to lua.

 

[Hambil]

New Features (for developers)

These will be further down the road, if they make alpha I'm not sure, but I hope they do.

Integrating Custom Missions by S3rgeus (with permission, thank you!)

 

[Hambil]

I have a git-hub setup https://github.com/Hambil/CommunityDLL/tree/Alpha

I have moved the 10 open issues into 3 milestones and anyone inclined can either fix/discuss the issues, or add new issues. If you need anything special to access the repository let me know and I'll get that set up ASAP. Updating of this thread will be spares from now on, as most of what we need can be done directly from github. There is an alpha fork to use for code changes.

 

[Pazyryk]

Can I make requests there? Some are unabashedly for my mod. Others would have wider interest. One thing that would be widely useful is a GameEvents (or possibly more than one) that would allow you to always get a pUnit object before it is destroyed (by being killed, disbanded, sunk as cargo with ship, or any other way I can't think of now).

 

[Hambil]

Can I make requests there? Some are unabashedly for my mod. Others would have wider interest. One thing that would be widely useful is a GameEvents (or possibly more than one) that would allow you to always get a pUnit object before it is destroyed (by being killed, disbanded, sunk as cargo with ship, or any other way I can't think of now).

Yes please do. There are currently three milestones, if it doesn't fit into one of those, or if you aren't sure how to add an issue, let me know and I'll help.

The milestones (all set semi-randomly for July 1st) are:
Fix Missing LUA methods
Fix Missing XML tags
Add New Features

Give it the appropriate tag(s), and add the discussion tag if you want others thoughts before it's implemented.

 

[Pazyryk]

Great! I'll do that.

You should update the OP with a link to the Git page. Discussion here is still useful so new folks can discover it as they drop by (at least until Gedemon stickies the thread, at which time no one will notice it anymore...).