LUA - Determining if an Open Borders agreement in place?

[sman1975]

Hello,

Am working on a mod that needs to know if two civs have an Open Borders agreement in place.

After establishing an embassy, and then bribing the other civ with free IGE Gold, they agreed to a 'Mutual OB Agreement.' I know there is an agreement in place - can see it in the Diplomacy UI.

Have seen a few examples of how to test for OBs in other mods, and have recycled code that looks like the fragment below. The variable iPlayer is the player ID of the Active Player, having a value of 0. iOwner has a value of 1, for the Civ that owns the plot in question:

...

local iOwner = pPlot:GetOwner()                                                                -- Check ownership of the tile

if (iPlayer ~= iOwner) and (iOwner >= 0) then                                                  -- If plot owner is not active player AND plot is owned by anyone, then...
    if Players[iPlayer]:IsPlayerHasOpenBorders(iOwner) then                                    -- If Active Player has open borders with plot owner, then...   
        return true                                                                            -- Return TRUE early
    end
end

...

The code looks good, nice, and compact. The problem? It doesn't work.

Using print statements, I know the first IF statement (with the 2 conditionals) works, leading to the 2nd IF.

The second IF statement (with the IsPlayerHasOpenBorders) never returns TRUE even though I know the condition is true.

I've reversed the player ID's in the second IF, but the results were the same.


Is there anything peculiar about the IsPlayerHasOpenBorders method that might cause it to fail? Or (as is usually more likely) is there something bone-headed I've missed?

Thanks!

 

[whoward69]

IsPlayerHasOpenBorders() is for City States.

Open Borders for majors are between teams (not players), so you need to use pActiveTeam:IsAllowsOpenBordersToTeam(iOwningTeam)

 

[sman1975]

Thank you, @whoward69 - unsurprisingly, it worked like a charm....


Working solution, in case anyone in the distant googled future is wondering:

if Teams[Players[iOwner]:GetTeam()]:IsAllowsOpenBordersToTeam( Players[iPlayer]:GetTeam() ) then
        return true                                                                            -- Return TRUE early
end

It would have taken me years to figure this one out. Never occurred to me the basic method only applied to CS's. Just wasn't thinking through the "when do you use teams, and when do you use civs" issue. Really appreciate the help!

Ironically, the mod I'm working on borrows liberally from your Airbases Terrain Improvement mod, and adjusts it for a scenario I'm working on. It will allow me to let the UK use French "airstrips" in France in a WW1 scenario, during a time when aircraft couldn't reach the Western Front directly from Dover... Will greatly improve the immersive quality/accuracy of the entire scenario.

So, I guess I owe you two 'Thank you`s!"

Thank you, thank you!

 

[sman1975]

Mr. WHoward - I did notice something else when using the UnitFlagManager replacement script from the 'Improvement - Airbases (v 14)' mod:

There's some kind of odd shadow any time a land unit moves into the city. Only happens when AI moves in, not human player.

Have you seen this before? I didn't make any changes to the UnitFlagManager.lua file.

 

[sman1975]

Odd, when Live Tuner is running, the problem looks differently:

 

[LeeS]

I also see the same temporary glitchy with the garrison unit when multiple units are or have been on the city-plot on that same turn when using William's UI - Improved City Banner V2 mod. It may have something to do with the way 'garrisoning' a unit is really no longer a 'thing' in BNW as it was in Vanilla (and G&K ?). Generally it only really seems to effect the 'garrisoned' unit . Usually it fixes itself on the next turn.

The glitch may also be in the unmodded game and may not have anything at all to do with William's mods. I always play civ5 with the Improved City Banner mod on because the unmodded city banner sucks so I cannot remember whether the glitch follows with the UI mods being enabled or not.

 

[sman1975]

Thanks, @LeeS - the error is quite consistent - every time a land unit enters an AI city, the black circle immediately appears. Remains until the unit leaves the city, then it disappears immediately. I guess the AI units could be garrisoned immediately on entering, but they always (well, 99% of the time) left the city the very next turn. Watched this behavior for dozens of turns with always the same results - in all AI civs.

Never saw the bug in my own cities, though, those always looked exactly like you'd expect.

I'm currently looking in the RestackFlags function to see if I can fully understand what WHoward was doing here. Am hoping it's a fairly straightforward change, even if it "breaks" the UI for Vanilla/G&K - at this point, I'm not worried about those very much.

I'm only seeing this errant flag-shadow bug in the replacement Flag Manager from the Airfields Terrain Mod. I can substitute a different replacement UnitFlagManager UI (one of mine that simply isn't as good as WHoward's), and the bug disappears.

A terribly minor thing, for sure, but I always amaze myself how much time I can spend chasing my own tail working on "minor" things...

You've inspired me yet again, though. Think I'll take a look at UI - Improved City Banner V2 and see how it behaves. Appreciate all of your advice!!!

 

[whoward69]

Remember that most of my BNW UI mods were converted from G&K and most of those were converted from Vanilla - if Firaxis changed the UI (which they did for garrisoned units) and something minor broke (and there are lots of UI glitches in the game anyway) it was rarely worth the effort of working out what Firaxis had bodged (the bodging level in BNW is much greater than in G&K and that's more than in Vanilla) to fix a none game breaking glitch.

The city banner code for AI cities IIRC is very different for your own cities. After writing the Airfields mod, I rarely played with it. I suspect the Improved City Banner code is more up-to-date, so you may want to start from that.

 

[sman1975]

Thanks, @whoward69 - I guess I underestimated just how much extra effort was required to maintain backward compatibility. I'm slowly learning just how much kludging is all over the code - so much that in a way, I'm sometimes amazed the game works as well as it does...

Again, unsurprisingly, using your 'Improved City Banner' mod, the problem magically disappears.

After writing the Airfields mod, I rarely played with it.

I'm having a blast with this mod. It solved some huge problems I was having in a scenario I'm working on (adding a lot of realism, helping to make the mod more immersive). Am also working on a later-Era scenario that uses 3 versions of the Airfield, based on Era.

Although the mechanics of the mod work great, I'm not seeing the AI use the airfields, unfortunately. I added some "improvement flavors" but that didn't seem to help. Since that table is empty, I'm guessing the AI doesn't use it any longer.


EDIT - I just realized something - I was working on converting a different mod to a VP-compatible version. Installing VP on my machine brought EUI with it, and EUI - like the proverbial houseguest after 3 days - doesn't leave the install cleanly when you're no longer using it. Perhaps my problem is related more to EUI than to the normal UnitFlagManager?

 

[whoward69]

Flavours are used by the AI for determining what to build (after several other higher priority considerations). They're not used when working out what to do with an improvement. Also, pretty sure what improvements are built are hard-coded in the DLL.

The AI's use of aircraft is appalling anyway. Don't expect the AI to work out that this turn it should rebase an aircraft so it's in a better position next - the AI just isn't programmed that way! (It has "this turn only" when fighting and the concept of an army to move units into position - it has no "look ahead" strategy)

 

[sman1975]

I figured since 'Improvement_Flavors' was empty, that it was probably a legacy artifact, and a long-shot to get working. I had still hoped that since the table was called 'Improvement_Flavors' and not 'Builds_Flavors' there might be at least a snowball's chance of it being used after the TI was completed...

I originally started down this path while working on a WW1 scenario. Aircraft ranges being quite short in those days, there was a problem getting British planes to the front in eastern France. Nearest town was Dover on the map, and they just couldn't reach, which hurt the realism I spent quite a lot of time trying to create.

My original solution was basically a few UK 'land-carriers' with 0 movement points, pre-built near the front on the scenario map. It worked (more or less) OK - AI used them like they always do - planes flying willy-nilly, in and out, never really doing much. Later in the scenario, a few cities would change hands enough for the British to get one somewhere closer to the front, obviating the need for any additional land-carriers. I gave up on this approach because I could never find a unit model that looked like an airfield. That's when I started experimenting with your Airfields TI and liked it much better.

But if the aircraft's destination selection is hard coded, not influenced by anything anywhere in the tables, I guess there's not much else I can do to influence AI usage of the Airfield TI. At some point, I suppose, you just say, "good enough..." and move on, eh?

Thanks for all the info - I can't tell you how many hundreds of hours you've saved me in researching problems. It is greatly appreciated!

 

[whoward69]

Mmmmm … wonders if you could make an invisible, or at least very small model, land carrier and park one of those on each AI controlled airfield improvement …

 

[sman1975]

I'm on it! Am using a similar construct from Hulfgar's Coastal Artillery TI.

What a great idea!

Will let you know!


EDIT - it works...

Used a derivative model of the Carrier unit, shrunk it to .001, then set ZOffset to -5. Can't see a thing...

AI doesn't seem to like to use them, but they will. In the test games I'm seeing planes do circles between 2 cities for about 20 turns in a row, but then they'll throw a plane or two at the Airfield, then it quickly returns to the city-to-city rotation - for another 20 turns. Have bumped the "FLAVOR_AIR_CARRIER" on the unit from 50 to 99 (normal Carrier is 40), but haven't noticed much change. I even put a sea-based Carrier unit next to the Airfield, but the AI pretty much ignored that unit in the same manner. I'm thinking the flavors don't change the behavior all that much.

I changed the "IgnoreOwnership" in the Airfield TI to true, so you can build new Airfields in other civ's territory, but you still need Open Borders to navigate the Worker to that spot.

All-in-all, I'm happy with the result, but the "does the AI use the new improvement" question is only a nominal yes.

 

[sman1975]

Modded airfields based on units is complete. All-in-all, I'm pretty happy with the performance. Think it looks pretty cool, too:



The mod removes the TI when the corresponding unit is destroyed - for any reason (combat, overlaid by a new TI, etc.). It also adds the appropriate airfield unit when the TI is created. Seems fairly robust.

Still looking for a way to handle "movement" the same way a Guided Missile does (e.g. where you can still delete the unit/terrain improvement manually, but the game doesn't give you the chance to try and move an immobile unit), but haven't quite figured that out. If I assign 0 Moves, it dims the flag and won't let you delete.

The other question - is there an event I can tie into when a Worker STARTs to build an improvement? Right now, when a Worker starts a non-Airfield TI on top of an existing Airfield unit, the "unit" part of the Airfield remains on the map until the new TI is complete - at which point this mod removes it. With no visible unit on the map, it looks a little hinkey.

Anyways, thanks again for the idea. I like how it worked out.

 

[whoward69]

Are you using a modded DLL (mine or VP)?

 

[sman1975]

Neither.

 

[whoward69]

Shame, pretty sure I added the event you're after

 

[sman1975]

Shame, pretty sure I added the event you're after

I'm shocked, shocked I say....

 

[LeeS]

About the closest you can come is use PlayerDoTurn and then look at all units that are workers and see if Unit:GetBuildType() gives the current 'build' project a worker is conducting. I say see if it does because I can't remember whether it gives what the worker is currently 'building' from the Builds table or if it returns a list of what it can possibly build. Based on William's Lua as XML I think returns what the worker is currently 'building'. I'm assuming Airfields can't be made on Forest, Marsh, or Jungle so you would not get a "remove_X" as the 'build' that would have anything to do with placing a different improvement over the top of an Airfield.

It's about the only hack-around I can think of based on using standard DLL.

Just remember to re-base or otherwise 'teleport' the Air Units that might be on the Airfield plot before removing the Land Carrier unit. Otherwise the Air Units will be *poofed* by the game.

 

[sman1975]

Ya see, @LeeS, there you go again with all this solid advice....

Personally, I was only trying to make the mod "fire proof" but you're advice is going further, into "bullet proof" territory - even bordering on "fool proof," and we all know how hard it is to make something "fool proof" since it's easy to underestimate the ingenuity of fools... Like me...

Having looked at this for a couple of hours, it seems to me the best (lest intensive) way-ahead is to use PlayerDoTurn to loop thru all player's units, check if it's an "airfield" unit, get the plot, then look to see if the plot hosts an airfield improvement. If not? Teleport the planes to the capital, destroy the airfield unit, then call it a day?

Of all the things I've experimented with, this seems the simplest, and perhaps fairest, way to go.

Short of breaking down, and exclusively using WHoward's DLL for modding. It sure would save a h*** of a lot of time...