YNAEMP Compatibility

Gazebo

Lord of the Community Patch
Supporter
Joined
Sep 26, 2010
Messages
18,399
Location
Little Rock
I've traced the compatibility issue with YNAMEP's resource-related options to calls to PlotDirection (found in a few files in the LUA of the mod). The DLL now calls PlotDirection, and makes directions, in a different fashion than YNAEMP is designed for:

Code:
inline CvPlot* plotDirection(int iX, int iY, DirectionTypes eDirection)
{
#if defined(MOD_BALANCE_CORE)
	return GC.getMap().getNeighborUnchecked(iX,iY,eDirection);
#else
	if(eDirection == NO_DIRECTION)
	{
		return GC.getMap().plot(iX, iY);
	}
	else
	{
		// convert to hex-space coordinates - the coordinate system axes are E and NE (not orthogonal)
		iX = xToHexspaceX(iX , iY);
		iX += GC.getPlotDirectionX()[eDirection];
		iY += GC.getPlotDirectionY()[eDirection];

		// convert from hex-space coordinates to the storage array
		iX = hexspaceXToX(iX, iY);

		return GC.getMap().plot(iX, iY);
	}
#endif

If someone with interest, and lua know-how, wants to update YNAEMP's calls to PlotDirection to match the changes in the DLL, let me know and I'll upload it.
G
 
Are there any news about updating the routine? Would like to see these features working.
 
I took a quick look of the lua, could one tell me how does getNeighborUnchecked work now compare to original plotDirection code?

I suspect getNeighborUnchecked handle wrap automatically now?

I see in YnaemLoading.lua it change the x and y to handle wrap

Code:
-- Make sure the plot exists
-- ynaem : there's something wrong here, don't know if it is also wrong in vanilla placement
--if wrapX == false and (nextX < 0 or nextX >= iW) then -- X is out of bounds.
	-- Do nothing.
--elseif wrapY == false and (nextY < 0 or nextY >= iH) then -- Y is out of bounds.
	-- Do nothing.
--else -- Plot is in bounds, process it.
	-- Handle any world wrap.
	local realX = nextX;
	local realY = nextY;
	if wrapX then
		realX = realX % iW;
	end
	if wrapY then
		realY = realY % iH;
	end
	-- test this plot.
	-- can't remember who's working inversed now, but double inversed = no inversion...
	
	--print ("   selecting plot at (" .. realY .. "," .. realX .. ")")
	local plot=Map:GetPlotXY(realX,realY)

Code:
elseif CanPlaceDepositAt (resourceID, realX, realY) then

Code:
	-- check if there's not a ressource of another type on the surrounding tiles
	for direction = 0, DirectionTypes.NUM_DIRECTION_TYPES - 1, 1 do
		local otherPlot = Map.PlotDirection(plotX, plotY, direction)
		if (otherPlot ~= nil) then
			if ((otherPlot:GetResourceType() ~= -1) and (otherPlot:GetResourceType() ~= resourceID)) then
				return false
			end
		end
	end

I also see in yemap's lua it sometimes reverse x and y parameter but I am not sure why..

I am pretty new to civ5 mod but have been doing day to day coding job for work. If there is some context on how plotdirection changed would be helpful
 
basically NO_DIRECTION used to be -1, now it's equal to 7. this was done as a performance optimization so we can do a direct neighbor lookup in an array using direction as index.

otherwise no difference
 
I am pretty sure there is difference in handling world wrap as I noticed it is failing for wrapped X/Y value when calling PlotDirection

I added some print message in the lua to see when it fails
Code:
[119145.187] WorldBuilderMapLoader: looping direction 5 X: 59 Y: 24 ResID: 18
[119145.187] WorldBuilderMapLoader: Got Plot
[119145.203] WorldBuilderMapLoader: X wrapped 59
[119145.203] WorldBuilderMapLoader: X wrapped 58
[119145.203] WorldBuilderMapLoader: X wrapped 58
[119145.203] WorldBuilderMapLoader: X wrapped 57
[119145.203] WorldBuilderMapLoader: X wrapped 56
[119145.203] WorldBuilderMapLoader: X wrapped 55
[119145.203] WorldBuilderMapLoader: X wrapped 54
[119145.218] WorldBuilderMapLoader: X wrapped 53
[119145.218] WorldBuilderMapLoader: X wrapped 52
[119145.218] WorldBuilderMapLoader: X wrapped 51
[119145.218] WorldBuilderMapLoader: X wrapped 51
[119145.218] WorldBuilderMapLoader: X wrapped 50
[119145.218] WorldBuilderMapLoader: X wrapped 50
[119145.218] WorldBuilderMapLoader: X wrapped 49
[119145.234] WorldBuilderMapLoader: placed RESOURCE_MARBLE for CIVILIZATION_GREECE, there was 12 plot(s) available
[119145.234] WorldBuilderMapLoader: Map is X wrapped
[119145.234] WorldBuilderMapLoader: X wrapped 56
[119145.234] WorldBuilderMapLoader: looping direction 0 X: 56 Y: 95 ResID: 0

I think it is likely an out of bound indexing error causing CTD when I looked at the getNeighborUnchecked() and PlotNum()

Code:
CvPlot* getNeighborUnchecked(int iX, int iY, DirectionTypes eDir) const
	{
		return m_pPlotNeighbors[ plotNum(iX,iY)*(NUM_DIRECTION_TYPES+2)+(int)eDir ];
	}

	inline int plotNum(int iX, int iY) const
	{
		return ((iY * getGridWidth()) + iX);
	}

just need to figure how should world wrap plot should be handled in the patch as it looks like it changed
 
it is x and y out of bound issue..I reversed x and y for the CheckVicinity call for add specific resource the game no longer CTD, whether the resource is added correctly I am not sure yet.

i.e originally the last 2 parameters for CheckVicinity is startY,startX
Code:
-- x,y reversed, not reversed, just print test and set...
plotTable, alreadyPlaced = CheckVicinity(3, "RequestedResource", resourceID, startX, startY)
-- if no result at close proximity, try larger
if (#plotTable == 0) and (not alreadyPlaced) and not player:IsMinorCiv() then
	print (" no result, try a larger search...")
	plotTable, alreadyPlaced = CheckVicinity(6, "RequestedResource", resourceID, startX, startY)
	-- on larger search, place the resource anyway, a duplicate could belong to another civ...
	alreadyPlaced = false 
end

For adding major deposit, I tried the same change but it cause other resources cannot be placed, so need to investigate further
 
finally I think I made the following 2 options works , at least looks fine to me when I use in game editor to view the resulting map (giant map)

-add specific resource (e.g pearl for japan)
-add major deposit (oil now found middle east , us gulf .etc)

The only change I made is switch PlotY and PlotX, for some reason YNAEMP is switching them around and I have no idea why it was working before, with the C(B)P the PlotDirection code change such that it looks like you have to use the correct X and Y value or it will cause an out of bound and CTD

Code:
	-- check if there's not a ressource of another type on the surrounding tiles
	for direction = 0, DirectionTypes.NUM_DIRECTION_TYPES - 1, 1 do
		[B]local otherPlot = Map.PlotDirection(plotY, plotX, direction)[/B]
		if (otherPlot ~= nil) then
			if ((otherPlot:GetResourceType() ~= -1) and (otherPlot:GetResourceType() ~= resourceID)) then
				return false
			end
		end
	end

I have attached YnaemLoading.lua in a zip, extract and overwrite the file in MODS\Yet (not) Another Earth Maps Pack (v 23)\LUA
I did not put any conditional logic to check whether you are using C(B)P so it may not work without C(B)P or may result weird resource placement
 

Attachments

  • YnaemLoading.zip
    6.5 KB · Views: 2,196
Yeah it is working. Greece got marble and the resource placement looks a lot more accurate now with "Use true geographic resource placement". Thank you! Do you need some help with errors or such?
 
Yeah it is working. Greece got marble and the resource placement looks a lot more accurate now with "Use true geographic resource placement". Thank you! Do you need some help with errors or such?

I think we are good now? are there other errors need to be looked at?
Ideally this leave the following to be done
- test if conditional logic is needed to make this work with default game engine , should be easy to add check in Lua if needed

- i really hope the 43 civs would work but from the threads I read it may not be easy...will look into the c(b)p C++ source code when I have time

you may also want to update your setup thread to link to the single post I attached the files for other to aware those 2 options now work with the fix
 
finally I think I made the following 2 options works , at least looks fine to me when I use in game editor to view the resulting map (giant map)

-add specific resource (e.g pearl for japan)
-add major deposit (oil now found middle east , us gulf .etc)

The only change I made is switch PlotY and PlotX, for some reason YNAEMP is switching them around and I have no idea why it was working before, with the C(B)P the PlotDirection code change such that it looks like you have to use the correct X and Y value or it will cause an out of bound and CTD

Code:
	-- check if there's not a ressource of another type on the surrounding tiles
	for direction = 0, DirectionTypes.NUM_DIRECTION_TYPES - 1, 1 do
		[B]local otherPlot = Map.PlotDirection(plotY, plotX, direction)[/B]
		if (otherPlot ~= nil) then
			if ((otherPlot:GetResourceType() ~= -1) and (otherPlot:GetResourceType() ~= resourceID)) then
				return false
			end
		end
	end

I have attached YnaemLoading.lua in a zip, extract and overwrite the file in MODS\Yet (not) Another Earth Maps Pack (v 23)\LUA
I did not put any conditional logic to check whether you are using C(B)P so it may not work without C(B)P or may result weird resource placement

Is this CBP only? I can include this in the next YnAEMP update otherwise.
 
I think we are good now? are there other errors need to be looked at?

you may also want to update your setup thread to link to the single post I attached the files for other to aware those 2 options now work with the fix
It guess we (you) fixed it and after some testing it seems like it is working as it should like. I will update my tutorial in the next hours to fit the newest development.
Is this CBP only? I can include this in the next YnAEMP update otherwise.
This fix was needed because Gazebo implemented some changes via the DLL of the Community Patch and so two options of YNAEMP were not working anymore and resulted in a CTD.

From my testing I can say that the fix for YNAEMP will allow me to play the Game with the Community Patch and with all options of YNAEMP that were marked as critical (CTD). If you play only with YNAEMP and not with CP it will work also. I don't know why, but I guess you have a better understanding of the lua script. Each option seems to be working and the map will have 'specific resources at starting position' or 'major deposits'.
 
Great news! I haven't played a civ game for months. I can'r wait to play it again when the YNAEMP is fixed.
 
Great news! I haven't played a civ game for months. I can'r wait to play it again when the YNAEMP is fixed.
I hope that it became clear in this conversation that YnAEMP is already fixed ;)
 
Is there a way to spawn the new world city state civs Inca, Maya, Rio, Cheyenne, Sioux, etc... basically keep old world retro with added and remove all European city states?
 
Hi Gazebo, Do you have plan to add the compatibility to EE and Future worlds in the future for CBP as well? : )
Go through the Mods Repository before asking about compatibility on this oh so very old thread. Also, G doesn't do compatibility unless it's a specific problem for a popular mod.
https://forums.civfanatics.com/threads/enlightenment-era-compatibility-contd.610282/
Future Worlds would need someone new to get it clean and balanced with VP, from what I can tell.
 
Last edited:
But they're outdated. It's almost unplayable unless you're coding know-how or civ 5 master.
Infixo's EE is already broken? Should only need some tweaks to bring it up to date since the last update in 3-25.
You mean only the Future Worlds, right? The Enlightenment Era compatibility mod should be very up to date.
I linked Infixo's EE, so yes. It has missed some changes though. I think the policy changes and some descriptions need updating. @Infixo might wanna take a step back from the barren gameplay of Civ 6 he's helping alleviate and take a look at the big updates VP has had lately.
 
Top Bottom