Community Patch for BNW

[Gazebo]

Oh... pity. Still, maybe he did (or would) make his code available. If not, what he did is still a good #todo list. I wish I could help with something myself, but it will take quite a lot of time before I actually learn anything (though I am trying to understand how stuff works). Someday perhaps.

Edit: Just read a post by Lord Tirian further in the thread linked by whoward saying that the code is available somewhere.

I'll post a bit more later, but in short The Smart AI dll changes are already in WHoward's DLL. They'll be folded into this. I'm looking at his changed before I do my own. also, all the new building/yields/changes are purely 'proofs of concept.' I'm not one of those modders that is personally attached to his changes. You don't like a change? We fix.

Consider it a 'starting point for debate.'
G

 

[JFD]

Not necessary expressing my dislike, just I feel that it is a significant enough change that its reason should be fully looked at, if to be included in a community patch. Such a change to snow would dramatically alter strategy, and I feel that might fall out of the scope of this patch. Too with the yields to ice and mountains from buildings; although I'll admit I like them, so can't say I'm so opposed to them.

Balance is a highly subjective value. Aiming to achieve it is very difficult. I would advocate dedicating this patch to fixing bugs - but I would argue AI incompetency falls under this category. Bugs are unanimously despised. Imbalance might cause some divide (limited, strategic balance propositions might be argued as okay, though). I would especially argue against attempting to balance civs/buildings/units, because not all will share the philosophy that all things in this game must be equal or equitable. Some "balance" issues also, arguably, run very deep.

Of course, this is just my input, and you can take it in any way you wish, Gazebo. I will be following this thread with interest, and, as a modder with prospering ideas, await your plans for Part 4. If you wish for further explanation as to my position on Part 3 and 4, then I will gladly provide them. I will provide more input on specific in the future. For now, I believe this is a long-awaited endeavour that I'm glad you have initiated. I would trust few others.

 

[whoward69]

The Smart AI dll changes are already in WHoward's DLL.

No they're not. The (partial) code is there but the merge is buggy and they are not enabled. Unfortunately the Smart AI code is not "merge friendly" - at least not the way I need it, such that features can be switched on/off at run-time.

 

[whoward69]

Balance is a highly subjective value. Aiming to achieve it is very difficult.

Don't even try. Make changes to the DLL to enable features - by adding events, Lua API methods, additional table support, et al (such that you could have, for example, yield from snow) leave the actual enabling to XML/SQL/Lua mods.

 

[Gazebo]

Something else: number of spies, I've brought it up in CSD before, but I think the non-scaling with map size is a general issue. In any case, there are only ten names and the game reaaallly doesn't like running out of spy names. Hence, adding more names and making sure the game can use them is important for mods and is, I think, within the scope of this.

That's an easy fix - I'll copy over my code for the National Intelligence Agency to give spies based on 15% of CSs in a game (why 15%? Grants 2 with 14+ city-states, 3 with 20+ city-states, and so on). It can be edited (is a defines value), or cancelled out (put the define at 0).

We'll need a new list of spies/spy names for every civ to do this, though - probably up to 25 total (15 new ones). Any takers?

The (partial) code is there but the merge is buggy and they are not enabled.

Ah, okay. I thought it was (I see #if statements for it in the merged dll), but sounds like it isn't up to snuff. That's okay, I can build on the ideas.

Make changes to the DLL to enable features - by adding events, Lua API methods, additional table support, et al (such that you could have, for example, yield from snow) leave the actual enabling to XML/SQL/Lua mods.

That's the plan - the XML changes I listed above were simply proofs of concept for testing stuff. I'm primarily interested in putting in functions and methods (like the MountainYield table) that gives XML/SQL modders more dll access without having to write custom lua. I do think that Snow needs a yield (and Ice, to boot), but I'll leave that to the community to test out.
G

 

[whoward69]

like the MountainYield table

Mountains are plot types - there are already Plot and Plot_Yields tables in the code (as I used it as the example for one of my C++ tutorials)

 

[Gazebo]

Mountains are plot types - there are already Plot and Plot_Yields tables in the code (as I used it as the example for one of my C++ tutorials)

Really? Where? I didn't see them when I was adding the Mountaintable. Must've missed them.
G

I see them now - they're in the Plot.cpp, tied to religious pantheons, yes?

 

[whoward69]

I see them now - they're in the Plot.cpp

Yes

, tied to religious pantheons,?

Only as an example

See http://forums.civfanatics.com/showthread.php?t=517567 and http://forums.civfanatics.com/showthread.php?t=517496

 

[Gazebo]

Yes


Only as an example

See http://forums.civfanatics.com/showthread.php?t=517567 and http://forums.civfanatics.com/showthread.php?t=517496

Ah, okay, I wanted to make sure I hadn't missed something. I added the MountainYield as a Building modifier - since mountains were the only plot that didn't have a corresponding yield table, I figured it'd just be easier to add it as a standalone table. Well I guess hills don't have one either, but there are improvement modifiers, so...

 

[whoward69]

Anything which is like "HillsMakesValid" or "NearbyMountainRequired" are lazy/quick hacky fixes and the Spawn of Satan and should be terminated with extreme prejudice!!!

In a "proper" DLL they should be secondary/associated tables Improvements_TerrainMakesValid, Buildings_NearbyPlotRequired and Buildings_NearbyTerrainRequired

 

[Gazebo]

Anything which is like "HillsMakesValid" or "NearbyMountainRequired" are lazy/quick hacky fixes and the Spawn of Satan and should be terminated with extreme prejudice!!!

In a "proper" DLL they should be secondary/associated tables Improvements_TerrainMakesValid, Buildings_NearbyPlotRequired and Buildings_NearbyTerrainRequired

Ha! Agreed (unless I'm feeling super lazy). That's what I did for mountains.

<Table name="Building_MountainPlotYieldChanges">
		<Column name="BuildingType" type="text" reference="Buildings(Type)"/>
		<Column name="YieldType" type="text" reference="Yields(Type)"/>
		<Column name="Yield" type="integer"/>
	</Table>

Also, as a side note, anything I add with this I'm going to push to lua, in the event someone wants it in that fashion. Is too easy not to push to lua. I wish there was an automated function for that (is there a tutorial for that, whoward?)
G

Edit: also, are you asking for tables for those things? Wouldn't be too hard, I suppose.

 

[whoward69]

Ha! Agreed ...

<Table name="Building_MountainPlotYieldChanges">
  <Column name="BuildingType" type="text" reference="Buildings(Type)"/>
  <Column name="YieldType" type="text" reference="Yields(Type)"/>
  <Column name="Yield" type="integer"/>
</Table>

Ummmm ... IMHO ... it should be

<Table name="Building_PlotYieldChanges">
  <Column name="BuildingType" type="text" reference="Buildings(Type)"/>
  <Column name="PlotType" type="text" reference="Plots(Type)"/>
  <Column name="YieldType" type="text" reference="Yields(Type)"/>
  <Column name="Yield" type="integer"/>
</Table>

Otherwise you're going to have Building_MountainPlotYieldChanges, Building_HillsPlotYieldChanges, Building_OceanPlotYieldChanges, Building_GrassTerrainYieldChanges, Building_PlainsTerrainYieldChanges, etc, etc, etc instead of the two tables Building_PlotYieldChanges and Building_TerrainYieldChanges

 

[whoward69]

are you asking for tables for those things?

No (and if I do I'll add them) - just pointing out that Firaxis did it the lazy way and "the community" shouldn't follow suit!

 

[Gazebo]

One of the biggest aspects of the game that CEP was/is looking at, and hasn't fully integrated properly yet, is the lack of consistency in yields and the various ways they are generated, utilized and then displayed.

If I understand correctly, you're asking for the ability to use the same secondary table to produce any yield, correct? Essentially, you'd get rid of the <Happiness>4</Happiness> element of buildings, and make it:

<BuildingType>x</BuildingType>
<YieldType>YIELD_HAPPINESS</YieldType
<Yield>4</Yield>

Shouldn't be all that hard - all I'd need to do is fill these into the Yield enums and redirect city and player pointers to look at yield changes rather than unique functions.

 

[whoward69]

Shouldn't be all that hard

Famous last words ...

The yield methods are a mine-field. Gold/Production/Science work the best but themselves are not consistent. Culture (not being a yield in vanilla) has its own set of functions (all the JONS stuff) that have been hacked to sort-of-work like a yield. Faith is a mishmash of the two approaches.

I wish you luck. I've looked at the yield code several times in depth and run screaming from it. Resolving the yield code such that Gold, Production, Science, Culture, Faith, Tourism, Happiness (both local and global), Great Person points (for any/every GP/Specialist) and a few others I've forgotten, all work the same way will be one of the "holy grails" of a community DLL

 

[Gazebo]

Famous last words ...

The yield methods are a mine-field. Gold/Production/Science work the best but themselves are not consistent. Culture (not being a yield in vanilla) has its own set of functions (all the JONS stuff) that have been hacked to sort-of-work like a yield. Faith is a mishmash of the two approaches.

I wish you luck. I've looked at the yield code several times in depth and run screaming from it. Resolving the yield code such that Gold, Production, Science, Culture, Faith, Tourism, Happiness (both local and global), Great Person points (for any/every GP/Specialist) and a few others I've forgotten, all work the same way will be one of the "holy grails" of a community DLL

Well, I'm going to give it a try. If you don't hear from me in a week, I leave everything in your hands...

 

[whoward69]

If you don't hear from me in a week, I leave everything in your hands...

Before you dissolve into a gibbering wreck, could you sort those methods in CSD v23 in the PM out first

 

[Gazebo]

Before you dissolve into a gibbering wreck, could you sort those methods in CSD v23 in the PM out first

Yes, of course. One quick question. Do you think it would be better to have specialists produce a unique yield (i.e. YIELD_GREAT_WRITER), or should I just build a new specialistyield table? I'm trying to think backwards on the specialists, as they're the most complex (yields within yields).
G

 

[Lord Tirian]

Need icons for those?

Hey, when I saw the draft patch notes, I started to (out of procrastination boredom) attempt an icon for the wind plant, though it's not 100% finished (figuring that even if it's not needed for the patch, somebody might find an use for it):

Spoiler :

Didn't see your offer at that point, hope I'm not treading on your toes, Wodhann...

We'll need a new list of spies/spy names for every civ to do this, though - probably up to 25 total (15 new ones). Any takers?

Since I've been complaining, I'm happy to have a stab at it, though it might take a bit... What would be the correct way to do it? Just appending it in the XMLs, going for entries like (I assume the text keys will just continue to count up, up to 24):

Spoiler :

<Row Tag="TXT_KEY_SPY_NAME_FRANCE_24">
      <Text>Grenouille</Text>
</Row>

 

[Gazebo]

Hey, when I saw the draft patch notes, I started to (out of procrastination boredom) attempt an icon for the wind plant, though it's not 100% finished (figuring that even if it's not needed for the patch, somebody might find an use for it):

Spoiler :

Didn't see your offer at that point, hope I'm not treading on your toes, Wodhann...

Since I've been complaining, I'm happy to have a stab at it, though it might take a bit... What would be the correct way to do it? Just appending it in the XMLs, going for entries like (I assume the text keys will just continue to count up, up to 24):

Spoiler :

<Row Tag="TXT_KEY_SPY_NAME_FRANCE_24">
      <Text>Grenouille</Text>
</Row>

I like the icon a lot! I imagine those buildings will stay in the mod, as they're pretty substantial balance-wise. We'll see, though.

For spies, start at 10, then work your way up. I can do the other half of the xml (this is the creative part):

<Language_en_US>
		<Row Tag="TXT_KEY_SPY_NAME_AMERICA_10">
			<Text>Edward Snowden</Text>
		</Row>

Having decent progress with the yield conversion. Definitely a bear.
G