Change ownership of a plot?

Plot:SetOwner has its argument list as player ID, city ID, and then two booleans. Presumably, if you keep the player ID the same as before and give it a different city ID, it'd change which city the plot is associated with. Haven't tried this, though.
 
problem is that Plot:Getowner() only return the playerID, so we can't check the city with this function and City:GetNumCityPlots() return all plots in the working range of a city, even if they belong to another city.

AFAIK you won't be able to know which plots are going to flip with the city, except the ones you've assigned with Plot:SetOwner()
 
AFAIK you won't be able to know which plots are going to flip with the city, except the ones you've assigned with Plot:SetOwner()

There's a way. Do this:
Code:
for ii = 0, pCity:GetNumCityPlots() - 1, 1 do
	local mPlot	= pCity:GetCityIndexPlot( ii );
end

This loops over all plots assigned to that city. Kind of annoying if you only want to modify one plot, but it at least works. I use this for a few things.

Also, to the original point, there IS a plot:GetPlotCity. So you shouldn't even have to mess with that loop.
 
I'm pretty sure of that :
City:GetNumCityPlots() return all plots in the working range of a city, even if they belong to another city.

You can refine the search by checking which plots are worked by which city, but there could still be plots not worked in the shared area of 2 or more cities, and I don't know how to get those.
 
there could still be plots not worked in the shared area of 2 or more cities, and I don't know how to get those.

That's why I posted that loop above. City:GetCityIndexPlot loops over the plots that were added by that city (through culture or purchasing), whether or not they're being worked at that moment. There's no issues with having two cities' areas overlapping if you do it that way. Or, like I said, use GetPlotCity, which I believe tells you which city owns the tile, not which is working it at the moment.
 
Plot:GetPlotCity() return nil if there isn't a city on the plot if I remember correctly...

I'll do a few test and report :)
 
Plot:GetPlotCity() return nil if there isn't a city on the plot if I remember correctly...

Hmm, could be. It's been a while since I used it for anything. Regardless, the loop method I gave above definitely works, since I use that method in several places within my code.
 
yep, using GetNumCityPlots...

Code:
include( "FLuaVector" )
function ShowCityPlots(hexX, hexY)
	local mouseOverPlot = Map.GetPlot( hexX, hexY );
	if (mouseOverPlot ~= nil and mouseOverPlot:IsCity() ) then
		local mouseOverCity = mouseOverPlot:GetPlotCity()
		for i = 0, mouseOverCity:GetNumCityPlots() - 1, 1 do
			local plot = mouseOverCity:GetCityIndexPlot( i )
			Events.SerialEventHexHighlight( ToHexFromGrid( Vector2( plot:GetX(), plot:GetY() ) ), true, Vector4( 1.0, 1.0, 1.0, 1 ) )
			local city = plot:GetPlotCity()
			print (city)
		end
	else
		Events.ClearHexHighlights()
	end
end
Events.SerialEventMouseOverHex.Add( ShowCityPlots )

... I'm getting all plots in working range, not just those belonging to the city :



... and 36 "nil" and one table id printed in firetuner.
 
Hmm, strange. I'm pretty sure I checked this for duplication before. Try putting a second city nearby, and see if it still shows all 36 for each; it might be allocating those 36 to the city only because there are no other cities that might also want it.

But yeah, if it's handling it THAT way, then there's really no easy way to keep track of which hexes were from which cities. Unfortunate.
 
A smal update on that since, through IGE, I amassed some xp on this topic.
* Plot:GetWorkingCity returns the city that works this plot.
* Beware of SetOwner, it bugs if you remove a plot from a city that was working it, and this plot contains a resource (or some features, etc): after that, if your city ever regains this plot, the yield computations for this city will be forever messed up (will go high in the negatives or positives), even if you save and reload! You absolutely need to remove the worker before you remove ownership.
 
I wanted to understand this issue a little more, so I ran Gedemon's code above on a late game map with many close cities and cities with >3 tile radius ownership. Unfortunately, it always returns all plots to exactly 3 radius, regardless of other cities or borders that have expanded >3 tile radius.

Beyond ownership, there is clearly something in the dll that "claims" tiles to 3 radius even before ownership. You can see this based on which city gets to build a building like stoneworks or circus (it's the first city that settles within 3 radius, not the first to expand onto that tile). So there are really three "levels" of city association: plot claiming for the purpose of resource association, ownership by border expansion, and plot working. Unfortunately, there does not seem to be any way to identify either of the first two. (Unless someone has learned anything more recently???)
 
Does anyone know the exact return city given by plot:GetWorkingCity()? It seems to return a city even if the plot is not currently worked. I suppose it also gives you the city if this is an "override worked" plot (which is not really owned by the city), but this is easily detected by plot:GetWorkingCity():IsForcedWorkingPlot( plot ).

I wonder if city ownership could be determined by some function involving GetWorkingCity, IsForcedWorkingPlot, and something else? Partial code:

Code:
function GetOwningCityForPlot(plot)
	local workingCity = plot:GetWorkingCity()
	if not workingCity:IsForcedWorkingPlot(plot) then
		return workingCity
	else
		--get city from which this plot has been work-overridden (GetWorkingCityOverride???)
	end
end

I'm not sure how to fill in that missing part. I'm also not sure if GetWorkingCity could return a city at >3 tile radius, but it seems possible since the method is not really detecting whether or not the plot is actually being worked.
 
Back
Top Bottom