Unified Prereqs (Community Patch for BNW)

[whoward69]

Post #4 updated to include the parameters for the GameEvents

 

[whoward69]

Post #3 updated as I've implemented the missing events in V51 of my DLL

Now for the missing Lua API methods

 

[whoward69]

Working on the pCity Lua API methods - do we also want

int CountPlotType(iPlotType)
int CountWorkedPlotType(iPlotType)

in addition to

bool HasPlotType(iPlotType)
bool HasWorkedPlotType(iPlotType)

 

[whoward69]

All events and API given in posts #3 and #4 are now implemented in V51 of my DLL

 

[JFD]

I would say that Player/City.CanConstruct could have the clauses bProduction and bGold. As far as I'm aware - and I could be wrong - CanConstruct can only be used to control whether a building can be produced in a city, which is inextricably tied to whether it can be purchased. I ask if it would be possible to allow the two to be controlled separately, in the same way that units can be. Of course, I'm presuming you can made amendments to existing GameEvents, and I could be wrong there.

Working on the pCity Lua API methods - do we also want

int CountPlotType(iPlotType)
int CountWorkedPlotType(iPlotType)

in addition to

bool HasPlotType(iPlotType)
bool HasWorkedPlotType(iPlotType)

The second achieves the same result as the first, but the second is much tidier if it's not a count you're after.

 

[whoward69]

HasPlotType(iPlotType) is equivalent to CountPlotType(iPlotType) > 0

But if you want to know how many mountain tiles a city has you need the latter. However, the only time I've need that info, I've needed it at a much more granular level - how many mountains in ring 1 and how many in ring 2 - and there is already a Lua library that can help you figure that out.

 

[whoward69]

I would say that Player/City.CanConstruct could have the clauses bProduction and bGold. As far as I'm aware - and I could be wrong - CanConstruct can only be used to control whether a building can be produced in a city, which is inextricably tied to whether it can be purchased. I ask if it would be possible to allow the two to be controlled separately, in the same way that units can be.

We need the buildings experts here. You can make a building not purchasable by setting it's hurry modifier to -1 IIRC (same way that wonders can't be bought). Is there really no way to make a building that can only be purchased?

 

[Gazebo]

We need the buildings experts here. You can make a building not purchasable by setting it's hurry modifier to -1 IIRC (same way that wonders can't be bought). Is there really no way to make a building that can only be purchased?

You would have to separate the hurry value of a building from its production cost, as hurry value is a factor of production cost.

In essence, if you set a building's production cost to -1, you can't build it, but it can be 'given' via policies, WC projects, etc. (much like Great People cost -1). With that value, though, a hurry mod also returns -1 regardless of its value. So, what we would need to do is simply add a new integer column for buildings called something like 'OnlyGoldPurchaseCost,' and add an if statement in the 'calculate hurry gold cost' function that looks for this value. If a building has this value, it would read that, instead of the -1 of the building's production cost.

Does that make sense? I hope so.
G

 

[whoward69]

Buildings with a HurryCostModifier of -1 are handled as a special case and can't be bought; it's what stops Wonders being purchased

There is no way to stop a building being constructed from hammers, the equivalent for units is the <PurchaseOnly> column - a la Landsknechts

Simple solution, add <PurchaseOnly> to the buildings table (which I think was suggested in another thread)

 

[Gazebo]

Buildings with a HurryCostModifier of -1 are handled as a special case and can't be bought; it's what stops Wonders being purchased

There is no way to stop a building being constructed from hammers, the equivalent for units is the <PurchaseOnly> column - a la Landsknechts

Simple solution, add <PurchaseOnly> to the buildings table (which I think was suggested in another thread)

Makes sense. I thought you could 'disable' buildings from being purchased with a -1 value for cost, but I didn't actually check. That would be an easy column to add (PurchaseOnly). Might be beneficial to make <PurchaseWithPolicy> and <PurchaseWithTenet> options as well, for granularity, although you could probably use the existing columns for that.

G

 

[whoward69]

Might be beneficial to make <PurchaseWithPolicy> and <PurchaseWithTenet> options as well, for granularity, although you could probably use the existing columns for that.

That way leads to column/table "explosion", both of those should be covered by the Lua events. And if not already, it makes more sense to add a few lua extras than potentially tens, possibly hundreds, of new columns/tables to cover every possible eventuality (especially as that's impossible - see my quoted comment in post #1 about "WonderFluff")

 

[whoward69]

Simple solution, add <PurchaseOnly> to the buildings table

Added to the code base, should be in the next release