Community Patch for BNW

[ExpiredReign]

My flippant comments should in no way be taken as anything other than what they are, my hope of a better game facing a frustrating reality. I have nothing but admiration for those that mod in the core C++.

Sent from my GT-I9305T using Tapatalk

 

[whoward69]

My flippant comments should in no way be taken as anything other than what they are

They weren't [edit: taken in way, shape or form as derogatory] (at least not by me [edit: someone who's put so much effort into CEP et al would have to try a lot hard than that to upset me!]) - I was just trying to explain why I've dropped this task (at least) three times. Without a light at the end of the tunnel (ie a playable mod), it's a heck of a long, dark, dank (and lonely) tunnel!

 

[Lord Yanaek]

All i can say is may the force be with you

This might not even be possible by modding only cvgamecore.dll, but something i would like to see is a way to accelerate animations, rather than just skip them with quick movement/combat or live with the current sluggish animations. I've looked at this previously and movement can be made faster with xml/sql modding (or at least some movements) but i found no way to speed up combat animations at all (no matter how much parameters i changed) and quick combat sucks big time because sometimes you won't even know what hits you and where it came from (the scrolling text goes off way too fast).

Also, i would suggest you make as few "balance changes" directly. Rather, whenever possible, open some of those changes to other mods by enabling access through tables and/or Lua. Of course, some of the proposed changes (like Desert Folklore) goes into the Yields issue. The issue with balance changes is that there are as many "perfect balance" as there are players so the less you modify it directly, the more player will accept the mod as a patch.

Speaking of yields, if it's too complicated to try and unify them, don't. But maybe there is a middle ground somewhere by expanding existing functions (such as the example of food from kills) and adding yields for what can't currently be affected by yield functions (such as happiness, including negative happiness).

 

[Wodhann]

This might not even be possible by modding only cvgamecore.dll, but something i would like to see is a way to accelerate animations, rather than just skip them with quick movement/combat or live with the current sluggish animations. I've looked at this previously and movement can be made faster with xml/sql modding (or at least some movements) but i found no way to speed up combat animations at all (no matter how much parameters i changed) and quick combat sucks big time because sometimes you won't even know what hits you and where it came from (the scrolling text goes off way too fast).

I share your frustation (it's either really fast but not knowing what is going on, or having to watch the painfully sluggish plane bombardment sequences), but if I were to take a guess I would say accelerating animations can't be done. I personally don't know though.

However, it could be interesting if we had a system of quick combat that instead of skipping through every combat animation altogether, it focuses the camera on every battle just before they take place (like "hey, this thing is happening"), activates combat, waits a bit, and then moves on to another (if there's a chain of them).

 

[whoward69]

All i can say is may the force be with you

You've missed that by 14 days

This might not even be possible by modding only cvgamecore.dll, but something i would like to see is a way to accelerate animations

All of the UI (3d-map, sv map, animations, dialog components, etc, etc) are in the UI DLL and not accessible from C++ either

Also, i would suggest you make as few "balance changes" directly. Rather, whenever possible, open some of those changes to other mods by enabling access through tables and/or Lua. Of course, some of the proposed changes (like Desert Folklore) goes into the Yields issue. The issue with balance changes is that there are as many "perfect balance" as there are players so the less you modify it directly, the more player will accept the mod as a patch.

That was the philosophy with my DLL (although I may not have stuck to it 100%) and I hope it will continue into whatever "community DLL(s)" appear

Speaking of yields, if it's too complicated to try and unify them, don't. But maybe there is a middle ground somewhere by expanding existing functions (such as the example of food from kills) and adding yields for what can't currently be affected by yield functions

It's not actually that complex - it's just a massive minefield of spaghetti programming which will probably take longer to fully comprehend than fix. The problem with a middle ground is that it just adds to the problems if anyone ever takes the task on.

(such as happiness, including negative happiness).

I'm removing these arbitrary tests as I come across them in the spaghetti

 

[Lord Tirian]

Attached the extra spy names. The archive contains a XML with all formatted names (and also a table I used to organise it, but you can safely ignore it). The names are all from lots of Google searching. Most lists should be sound and contain genuine names, though for some like the Shoshone or Huns, there are more random names that are either single word translations (Shoshone) or in-jokes/something that sounds vague right from adjacent languages.

Sorry for the inconsistent XML indentation (tabs vs. spaces) but I based it on the Firaxis files which aren't consistent either... it should work, though.

 

[Wodhann]

Only thing I would point to is that brazillian names lack diacritics (although if I remember well vanilla commits the same mistake) - Aloísio, Bonifácio, Eusébio, Tácito, Timóteo, Vitória.

(Most of these are really weird, uncommon names by the way, I'm wondering where you found them)

 

[Lord Tirian]

Only thing I would point to is that brazillian names lack diacritics (although if I remember well vanilla commits the same mistake) - Aloísio, Bonifácio, Eusébio, Tácito, Timóteo, Vitória.

Well, I attempted to keep it consistent with the Civ 5 standard list.

(Most of these are really weird, uncommon names by the way, I'm wondering where you found them)

Mostly from Behind the Name and 20000-Names, which both struck me as hobby projects - meaning they're good at collecting random weird things that are (hopefully) not just made up! I deliberately tried to go for somewhat uncommon names (or at least sound like that to me as German/English speaker) to keep it from sounding too much like people you'd just meet on the street (and implying that these might be code names). Of course, I might have overshot and picked really stupid sounding names - I'm not an expert by any means... feel free to improve on it or suggest improvements!

EDIT: Removed attachment, new version below (post #71).

 

[Gazebo]

Looks great, Lord Tirian. I'll add these in once I get to the spies section.

I'd like to clarify that this is not going to be a balance patch. I noted in the first post that anything which can be done via SQL/XML will not be included in this project. I'm going to stick to that, as well as complete granularity regarding changes (I'm not going to make any changes that cannot, in turn, be ignored or disabled). Also, I'm going to make sure that the changes I do make are as open and free-form as possible. I've tried to stick that policy with CSD's additions, and I intend on doing the same here.

As far as yields are concerned, I'm going to do my best to integrate a standard set of secondary tables that are hooked into every major yield calculator in the dll. In short, this will achieve what ExpiredReign wants (tables which can use all yields) without requiring a complete re-write of the DLL. The rule will simply be this: if a building/unit/policy/etc. adds a yield in its primary entry (i.e. <Happiness>4</Happiness>), do not also add that yield in a secondary table or the yield will be doubled. Simple enough, eh?
G

 

[Wodhann]

... feel free to improve on it or suggest improvements!

My suggestion is, replace Eusébio with Anselmo. Corporal Anselmo was an actual brazillian spy. (Edit: Sure, he was a spy for Cuba, but still brazillian...)

 

[Lord Tirian]

My suggestion is, replace Eusébio with Anselmo. Corporal Anselmo was an actual brazillian spy.

Done and attached. I decided against the diacritics, solely to keep consistency with vanilla. Though it might be worthwhile thinking about "patching" the vanilla names, too?

 

[Gazebo]

Done and attached. I decided against the diacritics, solely to keep consistency with vanilla. Though it might be worthwhile thinking about "patching" the vanilla names, too?

Do we know if diacritics display correctly in civ? It might cause problems.

 

[Lord Tirian]

Do we know if diacritics display correctly in civ? It might cause problems.

The default XML uses diacritics for a few names (see France, Celts, Spain and Mongolia) and I stuck to the same encoding (UTF-8 w/out BOM) as the default XML, so it should work, but it would be good to test it first, of course.

 

[Gazebo]

The default XML uses diacritics for a few names (see France, Celts, Spain and Mongolia) and I stuck to the same encoding (UTF-8 w/out BOM) as the default XML, so it should work, but it would be good to test it first, of course.

Ah, excellent. We'll give it a go soon enough.

 

[Wodhann]

In case you guys are fixing the diacritics for vanilla, the vanilla brazillian spy names with correct diacritics are Antônio, Estêvão, Fernão and Tomé.

Also Álvaro, for portugal.

 

[whoward69]

As far as yields are concerned, I'm going to do my best to integrate a standard set of secondary tables that are hooked into every major yield calculator in the dll. In short, this will achieve what ExpiredReign wants (tables which can use all yields) without requiring a complete re-write of the DLL. The rule will simply be this: if a building/unit/policy/etc. adds a yield in its primary entry (i.e. <Happiness>4</Happiness>), do not also add that yield in a secondary table or the yield will be doubled.

Unless this DLL is only being aimed at total conversion mods, I honestly don't see how this is going to help.

If Building A can have

<Happiness>4</Happiness>

while Building X can have

<Buildings_Yield>
  <BuildingType>BUILDING_X</BuildingType>
  <YieldType>YIELD_LOCAL_HAPPINESS</YieldType>
  <Yield>4</Yield>
</Buildings_Yield>

then the DLL has to go to two places to calculate building yields, which is fine because you have control of that, [but you'll have to take extreme care to avoid duplication bugs in your calculations (which given the spaghetti nature of the code will be a nightmare once you get into gold, food, science and production)]

However, any Lua that uses GameInfo.Buildings[BUILDING_X].Happiness will get a value of zero (not 4) so all existing mods based on that assumption break. In addition, any standardised tooltip building code still has to know about the "special columns" in all the primary tables and not just the yield related secondary tables.

What is actually required is on DLL startup (before the database tables are cached - see CvDllDatabaseUtility:: PrefetchGameData()) to update all the special columns from the new secondary yield tables where the special column value is zero and to create entries in the new secondary yield tables where the special column is not zero - ie you intentionally duplicate the data. The DLL and standardised tooltip building code can now just use the secondary yield tables, while any existing Lua (including all the game core UI Lua) still works.

 

[maglock]

What is actually required is on DLL startup (before the database tables are cached - see CvDllDatabaseUtility:: PrefetchGameData()) to update all the special columns from the new secondary yield tables where the special column value is zero and to create entries in the new secondary yield tables where the special column is not zero - ie you intentionally duplicate the data. The DLL and standardised tooltip building code can now just use the secondary yield tables, while any existing Lua (including all the game core UI Lua) still works.

So excuse my naivete (I have not done any modding but used to be a programmer): but couldn't you have:
- a new #define COMMUNITY_YIELDS or something
- if defined, at start of game all values calculated the old way are copied into the new secondary database
- any values for which a modder uses in the new fashion eg YIELD_LOCAL_HAPPINESS vs <happiness></happiness> overwrite the old values in the secondary database (perhaps with a warning in the logs saying that you have the value defined in the old way and the new way)
- all old yield functions get #defined COMMUNITY_YIELDS and return the standard yield if not defined OR the values from the secondary table if defined
- et voila! solved.

Edit: then it is up to modders: if not defined COMMUNITY_YIELDS then they can only use the standard yields and functions, if it is defined then they can take advantage of the new yields while gradually porting over old yields to the new system.

Now tell me I am naive and this can't possibly work

Otherwise, looking forward to where this mod is going

 

[whoward69]

Except you can only have one replacement DLL so that DLL must be capable of working for all mods the player has enabled.

Getting this to work for a player using one total conversion mod is a very different beast to getting it to work for a player using over 100 mods from 10 or more authors (a not uncommon scenario)

 

[Gazebo]

Monday Update:

I did some work on yields over the weekend, but I'm going to put the yields overhaul/extension work on the backburner for a bit, as I think AI improvements are far more immediate. I'm not going to forget about yields, however the more I learn about (and study) the yields problem, the more I realize just how miserable the task is. Anything in the dll that terrifies whoward should be a red flag to avoid if at all possible for the sake of sanity.

I'm still going to address yield-related concerns for things like pantheons, etc., so don't fret. The work on that is coming along well enough. I should have some time this week to (maybe) push out an early build of the patch. We'll see!

As always, I appreciate all help and efforts by the community. If you have any services you would like to give forth, by all means join the effort!
G

 

[whoward69]

but I'm going to put the yields overhaul/extension work on the backburner for a bit,

I'm in the process of pulling all the notes from several hundred hours of looking at yields into one document (when I can find them all!)

When I have that done, I think it'll be most productive to spawn the discussion off into a dedicated "unified yields" thread.