Thoughts on a community DLL

[Hambil]

Project Git Pages
For Alpha code changes.
Wiki for requests for lua methods to be defined more fully.
Repository for mod unit tests. Each change should have a unit test.

Has Firaxes said they will be releasing the DLL code *with* BNW or months/years later?

I had figured there was still a ton of time to work on a G&K dll as we wouldn't have one for BNW for a long time even after release. But, perhaps I'm wrong on that point.

I am working over the next couple days on building the DLL and getting my environment setup. Then I guess we can start discussing the issues and how/if I can help.

I will repost here when I have a working DLL and am not just a fly on the wall


Moderator Action: Split from the Thoughts on use git for Civ5 DLL mod sharring thread

 

[Hambil]

A few questions, as reading the thread and my lack of history with mod development, has left me unsure.

Is R.E.D. the community DLL? Are we attempting to bring an existing DLL from vanilla to G&K?

I was thinking of starting from scratch and then adding new functionality in after it's been tested well enough. I was also thinking of the focus initially being on general functionality that could be useful to all mod developers, such as adding events, fixing bugs/workarounds, adding abilities that make interacting with the UI easier (e.g. the recent custom missions DLL).

I am sure there are also a ton of such things that already exit in a current or previous DLL that we want to port forward.

I have a few thoughts/concerns on adding actual functionality to the DLL (meaning, features that the user gets automatically when they use the DLL, regardless if using it with a mod). An example might be 1upt functionality. It's something alot of people want, and modders want, but if I have my druthers I'd rather avoid that kind of thing. The way to do it in my humble opinion would be to either have the DLL itself do nothing but expose the functionality to be used by a modder if they choose, or to have any functionality built into the DLL come with a runtime switch so we can do things like add a checkbox to enable on the advanced settings page.

I was also thinking that if there are mods people have been waiting to port to G&K because they are waiting on their DLL to be updated, we should move those items to the top of the queue.

It looks like this has been moving slowly for sometime, hopefully we can get some gas in it and get things moving

 

[S3rgeus]

Is R.E.D. the community DLL? Are we attempting to bring an existing DLL from vanilla to G&K?

I don't think any DLL was ever settled on as a 'community' DLL. R.E.D. is being developed by Gedemon for his mods, Whoward's DLL has all of his pick'n'mix components in it, and anyone else (myself included) are creating separate DLLs with the functionality they need.

Also, I don't think it's possible (currently) to load the vanilla DLL as part of a mod. Since the OnGetDLLPath setting in ModBuddy is broken it appears to be impossible to load the vanilla one. We can load the G&K one because giving it the right name and setting it to VFS = true replaces the existing G&K DLL.

EDIT: Ignore me, apparently I didn't see the last few messages.

 

[Hambil]

By 'bring an existing DLL from vanilla to G&K" I meant porting it's functionality, not trying to use it directly

 

[Hambil]

One idea I have is to force a mod to register with the DLL before it can use the DLL. This can be done with one simple function call e.g. MyDll.Register("Mod Name"). This way, if we are using runtime switches to enable or disable functionality it gives mods a chance to play well together, as well as giving the DLL the ability to provide more useful exceptions, such as "MyMod has already changed 1upt functionality and is not compatible."

In the above example, if a mod changed 1upt to allow only a range and melee on the same hex, then a later mod tried to change 1upt to allow any combat units to stack, the second mod would receive an exception. However, if the second mod changed 1upt to allow civilians to stack, it would not conflict and no exception would be thrown.

On further thought the registration idea may not work as simply as I'd first imagined. But, I have time to put some more thought into it. Anyway, I'm just tossing stuff out to see what if anything 'sticks' with other modders desires/opinions ATM so no biggy.

 

[Gedemon]

A few questions, as reading the thread and my lack of history with mod development, has left me unsure.

Is R.E.D. the community DLL? Are we attempting to bring an existing DLL from vanilla to G&K?

No, R.E.D. is the code I use for my WWII mod, I've put it on git with different branches so that parts of the code could be picked for other mods.

git could be a community tool this way, with separated branch for each added features, with people choosing which branches to merge in their local build.

 

[Hambil]

I'm mostly just trying to figure out:

1) Where we are now.
2) Where we want to be.
3) How I can help.

 

[Nutty]

AFAIK,
1) The idea of a community DLL has languished.
2) The problem is that to do something like this, you really need someone to step up and be the maintainer.
3) How do you feel about taking on a largely thankless responsibility indefinitely?

 

[Hambil]

My answer to that is complicated. I have health issues and would like to leave it at that.

That is not a no, it just means that for real life reasons people will come and go and we shouldn't put our eggs in one basket. I'm willing to try and take up the charge at the moment, but several people should always have the keys and passwords and such at any time.

I also don't consider it largely thankless. It's what I used to do for a living Building toolsets with code.

 

[Hambil]

plot:GetPlotCity appears to be broken in lua, which means it's interface is borked most likely, since I see it being used all over the place in the DLL code. Do we have a running list of needed bug fixes (completed or waiting to be completed) any place?

edited: It appears this function is meant to return the city only if the plot is a city (Plot:IsCity()).

So it appears we have a one way connection. A city knows what plots it owns, but a plot doesn't know what city owns it. *sigh*

 

[Pazyryk]

, but a plot doesn't know what city owns it. *sigh*

There's a very long thread somewhere where we all came to that conclusion. That info is simply not available in Lua. (Though you can set which city owns it in Lua, so if you really need to know you can "know" after you change it.)

 

[Hambil]

I definitely need to know. I can detect when a threat is occurring pretty efficiently. But it's silly that I have to do time consuming acrobatic flips to determine what city the enemy unit is threatening. And I do need to know because I need to tell the correct worker units (in Follow and Cover) not to run away if they have cover. Otherwise the entire empire jumps into 'defensive mode' when any city is threatened. I don't think I'm alone either. I saw in the FrameArchitect's Militia mod that he wants to extend it to all cities and not just the capital... I've been waiting to see what his solution would be. Now based on your above mention of a previous thread, I guess I can expect the answer to be just as ugly as my solution.

 

[Pazyryk]

I can see many reasons why you might want to know what city a plot belongs to, but your particular example doesn't seem to be one if I understand correctly. Isn't your need based on proximity, not specific city ownership? A city could own a plot up to distance 5 in an unmodded game (or any distance if you set city ownership via Lua, which some mods do). On the other hand, it may not own a plot at distance 2 even though it is working it (if the plot happens to belong to a neighboring city).

I wish there was a "time consuming acrobatic flip" that would get city ownership info for a plot. But there isn't even that in Lua (except in the case where you set city ownership in Lua).

 

[Hambil]

There is a "time consuming acrobatic flip" it looks something like this:

-- Lua Script1
-- Author: Mark
-- DateCreated: 4/30/2013 5:26:47 PM
--------------------------------------------------------------
print('-----[ Enemy Check Loaded ]-----')

function EnemyOnPlot(pPlot, pPlayer)
	local i = 0
	while i < pPlot:GetNumUnits() do
		if (pPlot:GetUnit(i):GetOwner() ~= pPlayer:GetID()) then return true end
		i = i + 1
	end

	return false
end


--
-- DoTurn(int iPlayer)
-- This method is called every turn for every player, human and AI. In it we will walk the city's plots looking
-- for threats. We shouldn't have to do this but Plot:GetCityPlot() is broken in the DLL.
--
function DoTurn(iPlayer)
	local pPlayer = Players[iPlayer]
	local cityThreatTable = {}
	local iThreatCount = 0

	-- Check the Threat table
	for pCity in pPlayer:Cities() do
	
		-- If we can range strike we are being threatened. This is here to cover the edge case
		-- where the range strike radius is greater than the city radius.
		if (pCity:CanRangeStrikeNow()) then 
			table.insert(cityThreatTable, pCity:GetName())
		else
			local i = 0
			while i < pCity:GetNumCityPlots() do
				local pPlot = pCity:GetCityIndexPlot(i)
				if (pPlot:GetNumUnits() > 0) then
					if EnemyOnPlot(pPlot, pPlayer) then
						table.insert(cityThreatTable, pCity:GetName())
					end
				end
				i = i + 1
			end
		end
	end
end

-- 
-- Event handlers
--
-- These event handlers use pcall which allows for error reporting in fire tuner even though
-- the GameEvents object is bugged and doesn't print errors. 
--

function P_DoTurn(iPlayer)
	if (iPlayer ~= Game.GetActivePlayer()) then
		return
	end
	bSuccess, strResult = pcall(DoTurn, iPlayer)
	if (not bSuccess) then
		print(strResult)
	end
end

GameEvents.PlayerDoTurn.Add(P_DoTurn)

That's stripped out of Follow and Cover so you may notice it doesn't do anything except built a table of cities being threatened. There's a lot more, but that was the meat of the issue being discussed I thought, and this was the test project I built to try and solve the problem so I had it laying around anyway.

 

[Pazyryk]

No,

local i = 0
while i < pCity:GetNumCityPlots() do
	local pPlot = pCity:GetCityIndexPlot(i)
	if (pPlot:GetNumUnits() > 0) then
		if EnemyOnPlot(pPlot, pPlayer) then
			table.insert(cityThreatTable, pCity:GetName())
		end
	end
	i = i + 1
end

does not cycle through plots owned by the city. It cycles through all plots out to radius 3 irrespective of ownership.

But that makes more sense to me than worrying about city ownership for your purposes. I was addressing your original statement: "but a plot doesn't know what city owns it."

 

[Hambil]

Ah. Good to know the problem I've been fighting with for days is not just me being thick lol.

Sure seems like a candidate for a DLL fix once we get things going.

 

[Pazyryk]

It's in whoward69's [DLL] Missing Lua methods thread. plot:GetOwner needs to return iPlayer, iCity. Right now it only returns iPlayer.

 

[Hambil]

Great. Now I have not only a DLL to build, but a reason to build it. That always makes it easier

 

[Hambil]

Attached is a unit test that just implements Whoward's small change to make plot:GetOwner() return both city and player. It comments out the old code instead of doing a proper #define but I'll get to that. This is sort of my "Hello World" of "yes I can build the DLL and make changes". Woohoo! Now I need to go figure out some stuff about git-hub.

Edit: The only problem is the code fix (Whoward's or mine, doesn't matter which DLL) doesn't work. It always returns the same value for city. I'm pretty sure it's returning the wrong value for owner also. It should return no owner most of the time, instead it appears to be returning the owner of the unit on the plot.

Expect results: Owner is -1 (no owner) and city is -1 if not on an owned plot. Owner is plot owner playerID and city is plot owner cityID if plot is owned.

Actual results: Owner is set to the player that owns the unit on the plot. City is set to the same value no matter what.

 

[whoward69]

It's something you're doing wrong then

> for pUnit in Players[0]:Units() do
    if pUnit:GetUnitType() == GameInfoTypes.UNIT_SCOUT then
      print(pUnit:GetName(), pUnit:GetPlot():GetOwner())
    end
  end
 WorldView: Scout	0	73736
 WorldView: Scout	26	8192
 WorldView: Scout	0	24578
 WorldView: Scout	-1	-1
> Players[0]:GetCityByID(73736):GetName()
Dire Dawa
> Players[0]:GetCityByID(24578):GetName()
Debre Berhan
> Players[26]:GetCityByID(8192):GetName()
Monaco