What the new patch has wrecked/changed

&*(^%*&^%&*^@#%$&* WHAT is going on with assignstarting plots? I tried making even the mildest of changes, just changing the numbers in GetMajorStrategicResourceQuantityValues and it made no change. Ugh I'm going to bed. Even the smallest changes don't seem to work anywhere in the file.
 
&*(^%*&^%&*^@#%$&* WHAT is going on with assignstarting plots?

It looks like it's the same as the DDS; it's just not loading ANY Lua changes by default. New Lua files, yes, but any edited versions of old Lua (including AssignStartingPlots) just isn't being used. I've edited the TechTree lua files to add better tech tree icons, for instance, and none of that is showing up either.

But unlike the DDS, you can't set the VFS flag to true for the Lua; that crashes the game.
 
Blugh. Well hopefully they get it fixed soon.
 
Mark, are you serious??

Your mod files were overwritten? Or, what are you saying?
My unit texts were not harmed, but my building+civ texts were. However, all of those items appear in game (until the game crashes to desktop a turn later).

Yep. I have no idea how. In anticipation of the patch coming out I've been making copies of my mod and setting them aside every night for backup. Downloaded the mod and it changed my custom art settings that I had set up in a custom techtree .xml file.

I couldn't believe it. Checked my backup from last night. Changed. Only thing I can think of is that my custom .xml file shared the name of some other file.

I did use a tech tree editor to create the file so maybe it's connected to that somehow as well.
 
It looks like it's the same as the DDS; it's just not loading ANY Lua changes by default. New Lua files, yes, but any edited versions of old Lua (including AssignStartingPlots) just isn't being used. I've edited the TechTree lua files to add better tech tree icons, for instance, and none of that is showing up either.

But unlike the DDS, you can't set the VFS flag to true for the Lua; that crashes the game.
I have a simple mod with an edited VictoryProgress.lua that fixes a couple vote count display bugs and my file is definitely being used instead of the original because I can see the counts change after I enable/disable it and reload. So it's not all edited Lua files and something else must be going on.

Also, I originally had the same issue as robk with InGameUIAddin-related errors. In my case it didn't clear up until I completely deleted the row from the Content tab and recreated it. It works now, but in the Lua Console instead of just showing the state name in the dropdown menu and output, it shows the whole absolute path. So the console and Lua log looks like this, with comparison to vanilla log entries:
Code:
 GenericPopup: Loaded Popup - Assets\UI\InGame\PopupsGeneric\DeclareWarRangeStrikePopup.lua
 GenericPopup: Loaded Popup - Assets\UI\InGame\PopupsGeneric\ConfirmPolicyBranchPopup.lua
 GenericPopup: Loaded Popup - Assets\UI\InGame\PopupsGeneric\MinorCivGoldPopup.lua
...
 \Users\X\Documents\My Games\Sid Meier's Civilization 5\MODS\MP Random Testing (v 1)\Lua\EventInvestigator: EventInvestigator loaded
 \Users\X\Documents\My Games\Sid Meier's Civilization 5\MODS\MP Random Testing (v 1)\Lua\EventInvestigator: Paris (8192) founded by Napoleon (0). Culture: 3, Era: 0, Continent: 1, populationSize: 0, size 0, fowState is 2
More an annoyance than a problem, but at least the window is resizable and I have a widescreen monitor...
 
Bomber escort- thank you for that list! very helpful.

FYI- I noticed with the recent patch, that they changed the attributes naming in the Leaders table... the WorkAgainst / Willingness is now named:

<DenounceWillingness>6</DenounceWillingness>
<DoFWillingness>6</DoFWillingness>


2 fixes I have encounted (on the topic of new errors from the patch)...


-I was getting errors on my NewText/EN_US city-entries... and i fixed them by removing my <Add Row> for Bergen and Belfast (for my Norse and Gaelic civs), because Firaxis added these cities to the new file (so there is no need for the Add) even though they are not used anywhere (like a lot of the useless city entries in that file). What a stupid reason to break my mod, but oh well, Firaxis loves to waste time on city text entries for civilizations they are not including


-another error source (.dds error might be common for you guys?)

I discovered that my new .dds errors were because the new verison of Modbuddy with the patch, which now adds a 'Property' (bottom right for most people) on files / art, Import into VFS , which you change to true, so all one needs to do to fix prevously working custom art (in this case), is to change your previously 'taken for granted' associations of your art with your mod- and make it explicit rather than implicit


still getting an error on the database.log:
"Failure to check references for foreign key Units(CivilianAttackPriority).
no such table: CivilianAttackPriority"

but this seems like it is all on Firaxis

.DDS files are a go. Thanks a lot for finding that.
 
These are the new things which were added to the leaders:

<DenounceWillingness>7</DenounceWillingness>
<DoFWillingness>4</DoFWillingness>
<Loyalty>4</Loyalty>
<Neediness>4</Neediness>
<Forgiveness>5</Forgiveness>
<Chattiness>7</Chattiness>
<Meanness>7</Meanness>
 
New flavor was also added to the leaders, or at least I didn't have it in my mod:

<Row>
<LeaderType>LEADER_ALEXANDER</LeaderType>
<FlavorType>FLAVOR_NUKE</FlavorType>
<Flavor>7</Flavor>
</Row>
 
New flavor was also added to the leaders, or at least I didn't have it in my mod:

<Row>
<LeaderType>LEADER_ALEXANDER</LeaderType>
<FlavorType>FLAVOR_NUKE</FlavorType>
<Flavor>7</Flavor>
</Row>

nice :D
 
Never mind. I found the issue. Since my icon atlas only had 3 icons I had resized all the dds images to just 3 times the icon size (in case of the 45x45 icons image this was 135x45).

Apparently this now gives issues with the icons in the build menu. Simply expanding the dds containing the 45x45 sized icons to 360x360 solved the issue. The other images need no expanding and I didn't have to adjust the columns/rows entries in the atlas' xml either.
 
Changes to CIV5Policies.xml

Liberty
+50% Settler production in capital only

Meritocracy
50% happiness per trade route

Tradition
50% Settler growth in capital only

Aristocracy
34% Wonder Production (eliminates previous rounding error)

Landed Elite
Plot Culture Cost Modifier is -67%

Monarchy
-50% Plot Gold Cost Removed, 1 gold per 2 population added for capital only

Military Tradition
Lowered to +50% Experience from Combat

Theocracy
Unhappiness modifier is now -25% (was -20%)

Reformation
Golden Age is now 10 turns (was 6)

Rationalism
Golden Age is now 4 turns (was 5)

Multiple FLAVOR Changes
 
It looks like it's the same as the DDS; it's just not loading ANY Lua changes by default. New Lua files, yes, but any edited versions of old Lua (including AssignStartingPlots) just isn't being used. I've edited the TechTree lua files to add better tech tree icons, for instance, and none of that is showing up either.

But unlike the DDS, you can't set the VFS flag to true for the Lua; that crashes the game.

Technically, the VFS flag is what you are supposed to be setting here. It is "Import into the Virtual File System"; It is meant to be used for any file that should outright replace existing files (and I'm sure you all can see why that's a good thing to add :p). Before the patch, it defaulted to true. Lua should not be causing it to crash, anymore than lua files should have caused the old version to crash; I'll try a test of my own and check it out.
 
Er, where exactly is this VFS flag, I've no idea what people are meaning by bottom right...

Edit: nvm, found it :)
 
Technically, the VFS flag is what you are supposed to be setting here. It is "Import into the Virtual File System";

I get that it's what we're SUPPOSED to be setting, but when I do it, the game crashes. Every time, without fail, as I'm setting up a new game. I'd tried this on AssignStartingPlots, so in theory it could be related to the contents of that file, but it worked pre-patch and I've made sure to update the new version with my changes instead of just continuing with the old.

It is meant to be used for any file that should outright replace existing files (and I'm sure you all can see why that's a good thing to add :p).

Actually, no, I don't see it as a good thing. If the game picked up any loose files in the directory by default, then sure, you'd want that layer of protection, but it doesn't. You already have to make an explicit action to add an existing file to your mod inside ModBuddy (which adds a line to the modinfo file and ensures that the file is copied over to the "finished" directory, which serves as an additional layer of protection). Can anyone think up a single reason why you'd do this and include a copy of an existing Lua or art file in your mod structure if you DIDN'T want it to load? Is there any situation where you'd want this flag to stay False for anything other than XML?
The fact that you have to take this action already means that it should default to True, at least for those asset types that always should be included (art, Lua). It's purely redundant at present.
 
hrm, just tried it with assignstartingplots and it had a crash. Probably a mistake of my own, but you'd think they only changed assign starting plots to deal with the natural wonders. Guess I gotta spend 15 minutes/hours figuring out what I need to change.
 
I get that it's what we're SUPPOSED to be setting, but when I do it, the game crashes. Every time, without fail, as I'm setting up a new game. I'd tried this on AssignStartingPlots, so in theory it could be related to the contents of that file, but it worked pre-patch and I've made sure to update the new version with my changes instead of just continuing with the old.



Actually, no, I don't see it as a good thing. If the game picked up any loose files in the directory by default, then sure, you'd want that layer of protection, but it doesn't. You already have to make an explicit action to add an existing file to your mod inside ModBuddy (which adds a line to the modinfo file and ensures that the file is copied over to the "finished" directory, which serves as an additional layer of protection). Can anyone think up a single reason why you'd do this and include a copy of an existing Lua or art file in your mod structure if you DIDN'T want it to load? Is there any situation where you'd want this flag to stay False for anything other than XML?
The fact that you have to take this action already means that it should default to True, at least for those asset types that always should be included (art, Lua). It's purely redundant at present.

It allows you to outright replace files. I see that as a very good thing indeed, for total conversion mods. It is far from redundant. It also avoids issues where multiple mods use the same filenames... Which, for those just starting out and using Kael's guide, happens a lot.

In any case: It should not be crashing Lua. Like I said, I'll try it out, and report it to them if it is.

hrm, just tried it with assignstartingplots and it had a crash. Probably a mistake of my own, but you'd think they only changed assign starting plots to deal with the natural wonders. Guess I gotta spend 15 minutes/hours figuring out what I need to change.

Try winmerge? Should pick out all differences in about 5 seconds. :goodjob:
 
oooooooo I'll check it out.
 
It allows you to outright replace files.

But you could do that ALREADY. I'd replaced AssignStartingPlots, TopPanel, TechButtonInclude, and so on with my own heavily-modified versions.

If you mean replace database XML files altogether (instead of having to delete each line individually) then I can see the appeal there, but that would seem to conflict with the whole UpdateDatabase system they already have. But regardless, that doesn't apply to the cases we were talking about (new .DDS files, new .lua files), all of which replaced the old files entirely under the old system already, but which now won't do so until you set this flag.

Again, the question isn't "what can you do with it set to True", because we already know that; it was set to True before, so we've already got that as our baseline. The question is "what can you do with it set to False that you couldn't do when it defaulted to True". As in, why would you EVER want to leave it set to False (or more specifically, why you would ever want to leave it to the user to decide whether it's True or False instead of hard-coding it to True for asset files and such). If you can give some explicit examples then it'll make it far easier for us to figure out things like why AssignStartingPlots is crashing.

It also avoids issues where multiple mods use the same filenames...

How? I'm not trying to be confrontational here, I mean exactly how? Are you saying that if two mods change AssignStartingPlots.lua, it WON'T still freak out? I can understand if, by sheer coincidence, two mods happened to use the same names for two totally unrelated NEW files (although that's really the modders' fault), but when you're editing old stuff, there's no possible way the code is intelligent enough to merge both sets of modifications seamlessly, and for something like AssignStartingPlots (which runs once and then is done) it couldn't treat them as separate routines and execute them separately.

Try winmerge? Should pick out all differences in about 5 seconds. :goodjob:

It's very useful to have a tool like that, but the only problem here is that we don't usually keep around a copy of the old versions of the official files. If I'm changing 50 lines in a file and the patch changed 5, it'd be easier to diff the pre-patch and post-patch versions and move those 5 lines into my own mod. But currently, you can only diff your mod and the post-patch version, which means any difference lines will be either your work OR the patch's, so you just have to hope you remember which of the 55 lines were the ones you changed.
I didn't think about this until after the patch, but I've now made a backup directory of all the Lua and XML files, so that I can do this sort of thing the next time.
 
Back
Top Bottom