Community Patch for BNW

[whoward69]

Anything in the dll that terrifies whoward should be a red flag to avoid if at all possible for the sake of sanity.

Yields (Holy Grail 1), bonuses (Holy Grail 2) and path finding are the top three of my terror list (Civilopedia.lua is number 4, but that's not in the DLL)

One area that would be good to sort out and reasonably achievable, would be to un-hard-code the tooltip methods added in G&K and BNW - search the code-base for "::[a-z]*tooltip"

The formatting and compositing of the tooltip strings should be handled by Lua, the DLL should only be called to retrieve the numbers - which was the way it was done in vanilla. This would enable modders to (more) easily change things like the golden age tooltip to add Brazil like "CARNIVAL!" messages

 

[ExpiredReign]

I'm curious to hear who you think is the target market for a DLL mod such as this one.

If someone loads this (yet-to-be-developed) mod, wouldn't they also be more likely to want mods that make use of the new features? That is, any existing mod would either be pressured into making a compatible version or in some other way providing that functionality to the user.
That means only mods that are still currently being developed would work, and since there are probably no more official releases from Firaxis, wouldn't that mean the modders still modding would be amenable to making a compatible version? Since the only areas left to work are from the community.

I feel like that was too wordy to get across what I'm thinking but honestly I can't think of another way to put it, but I'll try.

Community patch DLL WILL break some existing mods. Is this a bad thing? I don't think so. If a user is going to use this he/she should expect it to do so and be prepared for a period of angst as mods he/she uses catch up.
Conversely someone not looking for 'bleeding-edge' mods is probably happy with the DLL as it is and won't bother to install this.

Anyway, that's my take on it.

 

[Gazebo]

I'm curious to hear who you think is the target market for a DLL mod such as this one.

If someone loads this (yet-to-be-developed) mod, wouldn't they also be more likely to want mods that make use of the new features? That is, any existing mod would either be pressured into making a compatible version or in some other way providing that functionality to the user.
That means only mods that are still currently being developed would work, and since there are probably no more official releases from Firaxis, wouldn't that mean the modders still modding would be amenable to making a compatible version? Since the only areas left to work are from the community.

I feel like that was too wordy to get across what I'm thinking but honestly I can't think of another way to put it, but I'll try.

Community patch DLL WILL break some existing mods. Is this a bad thing? I don't think so. If a user is going to use this he/she should expect it to do so and be prepared for a period of angst as mods he/she uses catch up.
Conversely someone not looking for 'bleeding-edge' mods is probably happy with the DLL as it is and won't bother to install this.

Anyway, that's my take on it.

I think you are right, however we need to start from a position of fixing bugs and gameplay incompatibilities first, then expand the existing assets and functions. I'm committed to fixing the yields issue as best as I can, and I'd like to do so in a fashion that is as compatible as possible with other mods. The changes I can make to the DLL to improve gameplay will have a more tangible impact on the game's 'fun level,' whereas yield changes fall under the category of 'expanding access for modders.' Don't worry - I'm not one to back down from a commitment.

On that note, I think we should do a bit of brainstorming on how to address a couple of the game's bigger balance issues. First, I'd like to talk about the rather-arbitrary nature of the 'tall v. wide' penalties that affect the latter party. Second, I'd like for you all to brainstorm ways to integrate and address any/all problem buildings, policies, pantheons and/or units. These discussions are intended to help me direct my efforts at extended the dll (to give all of you the ability to make the SQL/XML/LUA and artwork). I'm counting on you!
G

 

[Wodhann]

Can you explain what you mean about arbitrary nature of the "wide" penalties?

A big problem I see in civ5 right now (and since ever) is how you absolutely need to go wide in order to win the game - and even if you have just say one or two extremely well populated cities you can't do anything since less cities mean less everything. To add to this there is the factor of resources; if you get a wider empire, you gain more resources, so the penalties for going wide end up being null.

The game penalizes you for going wide with happiness, except happiness when managed, affects nothing of your gameplay, so it's a no-brainer strategy: I get happiness, I get more cities and more stuff. If I commit to the alternative strategy of maintaining a smaller empire and not settle or conquer more cities, I get less stuff.

Not to mention the way the food system works currently, especially with internal trade routes, is that "tall / wide" ends up being "tall / tall and wide", because not only your empire's growth is the same no matter how many cities you have (except if you manage to screw up on happiness management), but with more cities, you can assign more food trade routes making your empire even taller.

The problem with this of course is that the more we start thinking about solution the more we start "modding the game" and making this more of a community mod than a patch. So I don't know how you guys are intending to proceed.

(I'm not a pro player of any caliber by the way, so take what I'm saying with a grain of salt)

 

[Gazebo]

Can you explain what you mean about arbitrary nature of the "wide" penalties?

A big problem I see in civ5 right now (and since ever) is how you absolutely need to go wide in order to win the game - and even if you have just say one or two extremely well populated cities you can't do anything since less cities mean less everything. To add to this there is the factor of resources; if you get a wider empire, you gain more resources, so the penalties for going wide end up being null.

The game penalizes you for going wide with happiness, except happiness when managed, affects nothing of your gameplay, so it's a no-brainer strategy: I get happiness, I get more cities and more stuff. If I commit to the alternative strategy of maintaining a smaller empire and not settle or conquer more cities, I get less stuff.

Not to mention the way the food system works currently, especially with internal trade routes, is that "tall / wide" ends up being "tall / tall and wide", because not only your empire's growth is the same no matter how many cities you have (except if you manage to screw up on happiness management), but with more cities, you can assign more food trade routes making your empire even taller.

The problem with this of course is that the more we start thinking about solution the more we start "modding the game" and making this more of a community mod than a patch. So I don't know how you guys are intending to proceed.

(I'm not a pro player of any caliber by the way, so take what I'm saying with a grain of salt)

I'm not inquiring so that I can change the game, I'm inquiring so that I can open or create functions to facilitate mods like CEP.

By arbitrary I mean just that: are the penalties (science and culture) the best means to affect positive gameplay choices? If not, what are other options that could be facilitated in the dll? Such questions help me direct my work.
G

 

[ExpiredReign]

I would have to say that the penalties for going wide are not really penalties, more like speedbumps. You want to go and settle that extra city but you must prepare for a hit to happiness afterward or maximise your happiness beforehand and then settle. The end result is the same, your empire can do just the same as before but now you have x more cities. Those cities in turn can aid you to expand further.

There needs, IMO, to be a mechanic to determine the optimal number of cities the world can support, minus the number of city-states, divided by the number of players.

So, on a small game with 6 players and 12 CS with a continents style map the number might be something like:

landmass == 60 cities - 12CS == 48 cities/6 players == 8 cities

While the player is under this, number normal rules of expansion apply but once you hit the 'sweet' spot diplomatic and management issues arise.

The 'founding cities in my territory' diplo messages would be more frequent, along with degraded relationships. Your yields would take a hit unless specific buildings or units are in place to quell unrest. Eventually though with determined effort and certain policies/ideologies/beliefs/buildings/units the situation can be brought in check.

This isn't an idea I have thought about, just spitballing after the post above was read.
Feel free to completely rip it to shreds.

 

[Wodhann]

I would have to say that the penalties for going wide are not really penalties, more like speedbumps. You want to go and settle that extra city but you must prepare for a hit to happiness afterward or maximise your happiness beforehand and then settle. The end result is the same, your empire can do just the same as before but now you have x more cities. Those cities in turn can aid you to expand further.

I suppose your philosophy is that Civ5 is about expanding empires then? If that's the case then your opinion makes perfect sense and is quite correct, but I personally would rather have it more about choices. Have you got a great spot but with not much stuff around? Then just go tall and not bother with many cities. Did you start on an ample, ripe environment or are a belligerent, conquering civ? Then go wide and become a threatening force, but face the hardships of ruling a big empire. I would much rather preffer choice than the linearity of just getting more cities, "speedbumps" notwithstanding.

Not to mention expanding empires is snowbally - In a duel with two players, a player with 2 cities will never beat a player with 6 cities and a healthy empire after it comes to a certain point in the game. From a game design perspective I would much rather offer players the choice to "come back" and become a silent emerging power.

To me the only fact that should be a big downside when it comes to going tall is being more vulnerable and easier to capture - but beyond that, I disagree with the design perspective applied this game.


(... And here I am again discussing stuff that probably doesn't account for the real purpose of this patch. My apologies.)

 

[ExpiredReign]

Actually I prefer to go tall and keep to myself. That was just a bit of a quick observation about wide play.
If we want a tall option, then we need to give it the ability to stave off attack from the big civs. How, I don't know.

Sent from my GT-I9305T using Tapatalk

 

[whoward69]

I'm curious to hear who you think is the target market for a DLL mod such as this one.

Modders ... any and all ... beginners or experienced ... "tweakers" or "total conversionists".

And to hit that market the modded DLL must not break anything (or even make earth shattering "always on" changes) but only add to the possibilities opened up to Lua/XML/SQL

Example. Do NOT code the DLL such that connections between cities can be formed by rivers, but do extend the DLL (via events and Lua API methods) such that additional connections can be determined by a mod with Lua. One mod can use these extensions to create connections via rivers, while another can create connections via airports, while another could create connections via Star Gate improvements.

[I've made a few mistakes along the way with my own modded DLL on this score, eg hard-coding the "ships can enter land tiles" to forts and citadels - which I've since changed to being able to enter any tile with an improvement with an associated entry in the <Improvements> table - so if anyone creates a canal improvement 3-d graphic it's easy to make a true canal mod.]

Players should be ignorant of what is going on in the modded DLL and be able to use Mod A alongside Mod X regardless of whether one or the other or neither or both need the modded DLL - otherwise the author of Mod X is going to get blamed/slated for breaking Mod A.

 

[Lord Yanaek]

Holy Grail 3
Well, since whoward officially selected Holy Grail 1 and 2, let me propose Holy Grail 3 : unified prerequisites.
Anything in the game : buildings, units, promotions wonders ...(what did i forget) should have prerequisites that can be selected from any or all of technology, social policy, religious belief, wonder ... (i certainly forgot something)
Why not have an SP allow you to select a specific promotion, or a crusader promotion available only if some belief is in your main religion, special units only available after you build a national wonder ... Currently some of those are only possible with lots of hacky Lua and dummy stuff.

Balance improvements
Hopefully those will be much easier.

• Split Bonus vs Barbarian : On higher difficulties, AI with their large bonus vs barbs and lots of units will raze all camps within the first 30-40 turns, making honor opener pointless. The alternative is to lower (remove) this bonus but the poor AI then suffers badly when barbs are numerous. A possible way to solve this would be to add AIBArbarianBonusOwnterritory in HandicapInfos table. By default it would be nill or -1 value and this would cause the existing AIBarbarianBonus to be used both inside and outside borders (compatibility requirement). However, if AIBArbarianBonusOwnterritory has a value >= 0, then it's used for bonus within borders and AIBarbarianBonus is used outside. This would allow modders to change values so that barbarian stays a threat longer while keeping the AI relatively safe (inside it's own borders). Possibly the same can be done for player bonus.
• Free buildings map-size dependent : On small maps gaining 4 free monuments is enough to fill all your cities, on huge maps not so. I know tradition isn't underpowered, but if someone was to mod it or other trees and mess with free buildings, it would be nice to have it map-size dependent. The easiest way would probably to add NumFreeBuildingsBonus to Worlds table. The number there would be added to the free buildings granted by SPs (or other sources) so a 3 free monuments would become 5 on large if NumFreeBuildingsBonus is set to 2.
  I noticed there is a NumFreeBuildingRessources in Worlds table but i don't think it does what i suggest (or this was changed).

 

[whoward69]

Holy Grail 3
Well, since whoward officially selected Holy Grail 1 and 2, let me propose Holy Grail 3 : unified prerequisites.
Anything in the game : buildings, units, promotions wonders ...(what did i forget) should have prerequisites that can be selected from any or all of technology, social policy, religious belief, wonder ... (i certainly forgot something)
Why not have an SP allow you to select a specific promotion, or a crusader promotion available only if some belief is in your main religion, special units only available after you build a national wonder

A worthy candidate - perhaps Gazebo can update the OP with a "holy grail" list

Currently some of those are only possible with lots of hacky Lua and dummy stuff.

While I'm against dummy stuff, I'm also against adding many new columns to tables - prereqTech, prereqBelief, prereqPolicy, prereqResolution, etc - as by definition these are singular so really should be added as secondary tables - Unit_PrereqTech, Unit_PrereqBelief, Unit_PrereqPolicy, etc - and I'm against adding those as they are limited by our current knowledge of the game (what happens when a modder adds "WonderFluff" and that becomes a prereq?). Especially when a few new Lua events - PlayerCanXyz/CityCanXyz can handle all current and future possibilities.

From your "hacky" comment, what is also obviously needed (in addition to any new events) is an improved Lua API to make writing the code, not necessarily easier, but more pleasant - pPlayer:HasTech(), pPlayer:HasPolicy(), pPlayer:HasBelief(), etc. And also some best practice working Lua samples.

 

[Lord Tirian]

Modders ... any and all ... beginners or experienced ... "tweakers" or "total conversionists".

And to hit that market the modded DLL must not break anything (or even make earth shattering "always on" changes) but only add to the possibilities opened up to Lua/XML/SQL

I'm not really an experienced modder, especially not with Civ5, but let me put in my proverbial two pennies regarding what I'd like to see happening with this:

• It fixes genuine bugs.
• It improves the AI.
• It opens more options so you can do a lot more with basic XML modding.
• It's a replacement for whoward69's brilliant mega-DLL.
• Stays compatible with current non-DLL mods.

This would mean that you could just drop it in and get a better (but mechanically unchanged) vanilla experience. I don't really see abusing the AI's stupidity as mechanic, though, so I think AI is the one thing that should be a sweeping always-on change.

It means that if you want mods, you can just add them as before with the caveat that conflicts may arise - but that always has been the case.

And, finally, it means that you could enjoy most DLL mods together (apart from total conversions), because the community DLL would act a bit like a common API - similar to the way whoward69's merge works now.

This would also mean that on the Steam Workshop, people could just have a mod and add a note "requires the community patch" and you'd know you a) need it and b) can combine most of those together (barring things like conflicting lua changes).

It'd be interesting to then build a "community balance patch" on top of it that strives to be as minimal as possible (akin to the Firaxis balance patches), but that should not be a core part of the community patch, but an "add-on".

EDIT: I'll add some thoughts regarding the Tall vs. Wide balance later when I have more time.

 

[whoward69]

.. what I'd like to see happening with this ... SNIP

The only thing I disagree with there is the "always on improved AI" - if you have all the other code switchable, there's no reason to not have that switchable as well.

Smart AI is a start (which parts of will be in v50/v51 of the combined dll), but there are sub-features in there which others will disagree with (you can't please all of the people all of the time) or may just confuse new players (eg "move and shoot" if you're not accustomed to the AI doing it!)

 

[whoward69]

Holy Grail 3: Unified Prerequisites.

I did a search of all the Civ5*.xml files (the ones that create/update the core game database) and found the following candidates for "things" that can / could have pre-reqs

• Beliefs
• Buildings
• Builds
• GoodyHuts
• GreatWorks
• Improvements
• LeagueProjects
• Policies
• PolicyBranchTypes
• Processes
• Projects
• Religions
• Resolutions
• Routes
• Specialists
• Technologies
• UnitPromotions
• Units

And those "things" which are / could be used as pre-reqs

• Beliefs
• Buildings (type and class)
• Features (forest, marsh, oasis, ice, etc to include fakes - lakes, rivers, etc)
• Improvements
• Plot (mountails, hills, flat, ocean)
• Policies
• PolicyBranchTypes
• Projects
• Resolutions
• Resource
• Routes
• Specialists
• Technologies
• Terrains (grass, plains, desert, snow, etc)
• UnitPromotions
• Units (type and class)

Did I miss anything from either list?

 

[Wodhann]

I think AI intelligence should be based on difficulty level.

Ideally (maybe utopically) thinking: Want average AI? Pick an average difficulty. Want expert AI? Pick Emperor or Immortal. Flawless AI? Deity and so on.

I've always though difficulty levels should be based on how smart the AI is, not how much it "cheats" and gets free stuff. But then again, I might be dreamin'.

 

[whoward69]

I've always though difficulty levels should be based on how smart the AI is, not how much it "cheats" and gets free stuff. But then again, I might be dreamin'.

I think you'd be hard pushed to find people that disagree with that statement.

Unfortunately I also think you'll be just as hard pushed to find modders capable of implementing it. If Firaxis are still making the AI smarter by adding cheats in CivV (and it's not as if they've not had a few previous attempts at it) it ain't gonna be easy!

 

[Wodhann]

You're right, all I'm saying is, after you guys made all improvements in AI you deemed appropriate, you could evaluate which changes could be applied to each difficulty, instead of it being a switch-on switch-off for all difficulties kind of thing. Just an idea.

 

[Lord Tirian]

The only thing I disagree with there is the "always on improved AI" - if you have all the other code switchable, there's no reason to not have that switchable as well.

If that is possible without complete spaghettification of the code, that'd be nice, I agree. I'm just worried about the impact of so many elements: The AI is spread out over a lot of files and it just sounds like something where a lot of switching between Firaxis and Community DLL routines can a) introduce bugs and b) increase the turn times more if it has to check a lot whether the smarter AI is on or off (of course, this can be mitigated by coding it in a way to minimise the checks).

 

[whoward69]

made all improvements in AI you deemed appropriate, you could evaluate which changes could be applied to each difficulty, instead of it being a switch-on switch-off for all difficulties kind of thing.

Which fits nicely with the current approach of a switch for each (sub-)feature, eg, it is not "all of Smart AI or none of it" it is

    <!-- Omit obsolete/no value items as part of a deal if asked to balance things out (v50) -->
    <Row Class="6" Name="AI_SMART_DEALS" Value="0"/>
    <!-- Use Great people more effectively, plant some improvements early, and later use GP powers (v50) -->
    <Row Class="6" Name="AI_SMART_GREAT_PEOPLE" Value="0"/>
    <!-- Delay grand strategy bias until the Renaissance (v50) -->
    <Row Class="6" Name="AI_SMART_GRAND_STRATEGY" Value="0"/>
    <!-- Make better policy choices ignoring grand strategy until medieval and giving less importance to opening branches vs unlocked branches (v50) -->
    <Row Class="6" Name="AI_SMART_POLICY_CHOICE" Value="0"/>
    <!-- Stop making archaeologists sooner and also disband archaeologists if there are not valid targets (v50) -->
    <Row Class="6" Name="AI_SMART_ARCHAEOLOGISTS" Value="0"/>
    <!-- Disband long obsolete units, eg triremes in industrial era (v50) -->
    <Row Class="6" Name="AI_SMART_DISBAND" Value="0"/>
    <!-- Upgrade more units per turn if there are lots of units that can be upgraded. Also upgrade air units more often (v50) -->
    <Row Class="6" Name="AI_SMART_UPGRADES" Value="0"/>
    <!-- Units with at least 75% health will avoid healing (v50) -->
    <Row Class="6" Name="AI_SMART_HEALING" Value="0"/>
    <!-- Units won't randomly embark to water tiles (v50) -->
    <Row Class="6" Name="AI_SMART_FLEE_FROM_DANGER" Value="0"/>
    <!-- Ranged units are always able to move AND shoot on the same turn and should not attack over and over a city with 1 HP remaining. (disabled) -->
    <Row Class="6" Name="AI_SMART_RANGED_UNITS" Value="0"/>
    <!-- AI will hold planes back for interceptions and perform air sweep missions more efficiently, if enemy aircraft are nearby (v50) -->
    <Row Class="6" Name="AI_SMART_AIR_TACTICS" Value="0"/>
    <!-- Improves the AI's melee tactics (disabled) -->
    <Row Class="6" Name="AI_SMART_MELEE_TACTICS" Value="0"/>

which means you can do what you want

 

[whoward69]

(of course, this can be mitigated by coding it in a way to minimise the checks).

And by "inlining" the check code.

BUT, given the inefficient way the Firaxis code is currently written, adding a few nanoseconds to check for on/off options even in thousands of places in the code will have no perceivable overhead