XML for city-connections or internal trading?

[DarkScythe]

Please re-read my post more carefully.

I don't know why you skipped issue #1. I even explained why #1 was an issue.

In Lua, most 'blocks' of code must have an explicit end when you define them.
if .. end
for .. end
while .. end
function .. end
do .. end

I would recommend looking at some Lua Tutorials such as this one, specifically the sections on Control Structures and Functions to help you understand what is going on here.

 

[Damirith]

Well this seems to be working!
Edit: wait not yet

 

[Damirith]

yeah so how do you use pPlayer:GetNumBuildingClass() properly?

Being limited to playerId in PlayerDoTurn sucks. I am stuck on how I can get the adder/remover to only work when the current player owns the wonder. I got it working in a PlayerDoTurn to add/remove the dummy buildings when the city gets connected/disconnected, problem is it works even when the wonder isn't built.

I was thinking a global variable "HooverWonder" could be set from 0 to 1 when the wonder is built and then just use that in an if statement, but that just means the for loop wont work until the wonder is built by anyone and not specifically the current player. How can I make it so setting HooverWonder = 1 is specific to only the player who made the wonder and to pass that information into PlayerDoTurn?

 

[DarkScythe]

I wouldn't recommend doing that just yet; If you set a Lua variable, then that variable is only "set" and working for that one instance. If the player at any point quits the game, and/or reloads the game from a save file, that variable is wiped out / reset to whatever default you have in your Lua. This kind of 'toggle' information is something you need to persist between game saves, and it's not something I'd recommend you look into just yet, considering how much trouble you're having with standard Lua code.

If you are interested though, check out the Modiki's page on Data Persistence which details the idea, and a few available routes. I personally use Pazyryk's TableSaverLoader although if you do, you will likely want to use my TSL Serializer component alongside it to fix some compatibility issues.

Otherwise, utilizing the on-demand Lua method provided by the game to check whether each player has the Wonder is going to be vastly easier. As far as GetNumBuildingClass(), I'm not entirely sure of its exact syntax/usage since I haven't used it yet, but I would imagine it would require an argument indicating the buildingclass ID you're looking for. I have no idea if it's a Player or City method; LeeS can probably chime in here, although I suppose I can test it at some point.

But, basically, GetNumBuildingClass(GameInfoTypes.BUILDINGCLASS_HOOVER_DAM) or something.

EDIT:
Okay, so I just tested for you. GetNumBuildingClass is incorrect.
The method you want is pPlayer:GetBuildingClassCount() which takes the argument of the buildingclass ID you're looking for: pPlayer:GetBuildingClassCount(GameInfoTypes.BUILDINGCLASS_HOOVER_DAM)
Simply set this as the first check in your PlayerDoTurn, and build the logic around that.

 

[LeeS]

I just do this towards the top of my lua, before any of the functions for PlayerDoTurn, CityConstructed, etc., are presented in the code:

gLeonardoBClass = GameInfoTypes.BUILDINGCLASS_LEONOARDOS_WORKSHOP

Then in the PlayerDoTurn function I do this:

if pPlayer:GetBuildingClassCount(gLeonardoBClass) > 0 then
	--do some stuff, ie, your code for adding and removing dummies based on whether the city is connected to the capital
end

Obviously you would change the name of the variable to something else besides gLeonardoBClass and you will need the proper name of the Hoover Dam Wonder's Building-Class

For the purposes of Civ5 modding, forget your C++ instructor's fetish about 'global' variables. Every time the game has to find the info that matches for a GameInfoTypes["SOMETHING_OR_OTHER"] or GameInfoTypes.SOMETHING_OR_OTHER takes time because the game has to go through the list of all the valid GameInfoTypes that are in the XML/SQL database. If your code is doing this every turn, or multiple times per turn, it takes far less time to do this look-up once, stick it in a variable, and have it available for the rest of the player's play-session than it does to look that info up and grab it from the game's database every time it needs to refer to that information.

Remember that your code is also going to be running alongside everyone else's code, and if everyone programs their lua so that every turn and for every player (human, AI, city-state, barbarian) the game has to look up all these different pieces of information from the game's database every time (or multiple times per turn) for every player, this can very quickly reach a point where the player sees a quite noticable turn-processing lag.

By grabbing the info and sticking it into a variable at the top of your lua (before your lua does anything else) that info will be available everywhere else in the same lua file so that all functions in the same file can use it without ever having to re-look-up the info from the game's database, and by using this method it forces you to be consistent with the way you name the variable in all your functions within the same file, which means all those functions will be "playing the same tune".

 

[Damirith]

ok one sec

 

[DarkScythe]

By grabbing the info and sticking it into a variable at the top of your lua (before your lua does anything else) that info will be available everywhere else in the same lua file so that all functions in the same file can use it without ever having to re-look-up the info from the game's database, and by using this method it forces you to be consistent with the way you name the variable in all your functions within the same file, which means all those functions will be "playing the same tune".

I should note that the "only accessible within the same file" only applies if you declare your "global" variables at the top as locals.

local XYZ will be visible to every function within the same file, but functions from an include("abc.lua") will not see it.

However, simply declaring a global XYZ will allow all functions within that file, as well as all functions called from within include("abc.lua") to see it.

I also failed to respond to this when it was brought up before, but Civ5 isolates all of our Lua files into their own contexts. Even if we declare variables as global, different contexts will not be able to see the others. LuaEvents bypasses this to some degree by allowing Lua to "talk across" contexts, but this is not something you should concern yourself with at this stage.

Edit:
That revised Lua is looking much better, although I question the usefulness of CityConstructed here if you already have the same function it calls running every turn already.

 

[Damirith]

OK it works now, it's so simple when you think about it...yet took me all this time to get it lol

pPlayer:GetBuildingClassCount solved the problem! Thanks again for all your help DarkScythe and LeeS

 

[LeeS]

Edit:
That revised Lua is looking much better, although I question the usefulness of CityConstructed here if you already have the same function it calls running every turn already.

True in this case. Especially the way he ended up structuring everything, and the fact that he is doing nothing different when the wonder is constructed as opposed to what he is doing every turn. I tend to keep the CityConstructed because I haven't yet satisfied myself that the buildings and wonders are added before the PlayerDoTurn events are processed. They seem to be, but I am not satisfied in my own mind it is not merely a "seems to be".

OK I think it works now, it's so simple when you think about it...yet took me all this time to get it lol

Welcome to CIV5 modding. It's pretty much all that way.