whoward69
DLL Minion
Done
Found and squashed
EDIT: Also tested a few more tables, posts #2 and #3 are up-to-date
DLL - Unified Yields
- Thread starter whoward69
- Start date
Found and squashed
EDIT: Also tested a few more tables, posts #2 and #3 are up-to-date
whoward69
DLL Minion
Current state of play
Culture Faith Food Gold Production Science Tourism Golden Age
#Belief_YieldPerFollowingCity test
#Belief_YieldPerOtherReligionFollower test
#Belief_YieldPerXFollowers test
#Trait_BuildingClassYieldChanges
#Belief_YieldPerFollowingCity test
#Belief_YieldPerOtherReligionFollower test
#Belief_YieldPerXFollowers test
#Trait_BuildingClassYieldChanges
I wonder why it does that (the infinite loop) is it because of how that particular yield hooks into the updateyield() function?
G
G
whoward69
DLL Minion
You and me both! The code for GA points is identical to that for Tourism and that works correctly, but GA points, no CTD, no response (not even the correct cursor if you tab out and back in to the window), just 100% CPU usage, it's very strange.
I'm sure you have, but did you try hooking VC into the exe and running a live debug to see if it shows you the stack overflow error in the thread viewer? That's the only way I was able to clean up a few of the infinite loops I accidentally created.
I imagine the infinite loop is stemming from how the game processes the updateyields function in tandem with how golden age points are processed by either the LUA or the player.cpp file (as, IIRC, golden ages bump the yields of tiles, so perhaps the check to see if you enter a golden age is causing the GA points to be refreshed on the tile, thus looping it all over and over again). My uneducated guess.
G
whoward69
DLL Minion
whoward69
DLL Minion
whoward69
DLL Minion
V63 released
There are no new tables to test - this is a build that should be stable and so just needs testing under normal game play.
So you think it's broke ...
Please double-check the following before reporting errors on this version
So you're convinced it's broke ...
I need a zip with a save game file with ONLY the DLL and a simple mod (eg "My - Changes") to add the yields enabled. Please include the simple mod in the zip, but not the DLL mod! In your error report post, please explain what you do (if anything) after loading the save game file (eg finish a building, add a trade route, pick a policy), what effect you see, and what effect you would have expected to see.
If you're getting a CTD, I need the CvMiniDump.dmp file from the directory that the main Civ5 .exe file is in - usually "C:\Program Files (x86)\Steam\SteamApps\common\Sid Meier's Civilization V" (NOTE: I do not need any .mdmp files from this sub-directory as these are useless to anyone but Firaxis)
TIA and Enjoy
W
There are no new tables to test - this is a build that should be stable and so just needs testing under normal game play.
So you think it's broke ...
Please double-check the following before reporting errors on this version
- Make sure you have logging enabled, and check the database.log and lua.log files for errors!!!
- Confirm that any database changes adding new yields are actually being applied (at the very least check the database.log for errors, but preferably look directly into the database with something like SQLiteSpy)
- Ensure you fully understand what the new table actually does (and not what you think it should do) and how yield entries within it manifest themselves - some tables are badly named and some have non-obvious effects (I've tried to flag these in post #3)
- If it's a modifier, is there an associated yield to modify? You would not believe how many times during testing I've applied a 500% modifier to a yield of 0!
- If it's a modifier, will the change actually show up - most yields do NOT calculate to hundredths. For things like culture, faith, tourism and golden age points (which count in ones, not hundredths) applying a 25% modifier will not show any increase in yield unless you have at least a base yield of 4 (as 3 * 1.25 in integer maths is still 3)
- Are you sure it's not just a tooltip error. Most tooltips are generated by Lua in the UI. As these files have not been changed, they take no account of the new sources for standard yields or the new yield types.
- Finally, remove all other mods and pseudo-DLCs (including EUI) - you should just be testing with the DLL and the mod needed for testing (eg "My - Changes") to remove any possible chance of interaction. (IGE and/or LiveTuner mods to help with testing should be fine.) Also, don't modify the base files directly as that makes it a royal PITA for anyone trying to reproduce the error!
So you're convinced it's broke ...
I need a zip with a save game file with ONLY the DLL and a simple mod (eg "My - Changes") to add the yields enabled. Please include the simple mod in the zip, but not the DLL mod! In your error report post, please explain what you do (if anything) after loading the save game file (eg finish a building, add a trade route, pick a policy), what effect you see, and what effect you would have expected to see.
If you're getting a CTD, I need the CvMiniDump.dmp file from the directory that the main Civ5 .exe file is in - usually "C:\Program Files (x86)\Steam\SteamApps\common\Sid Meier's Civilization V" (NOTE: I do not need any .mdmp files from this sub-directory as these are useless to anyone but Firaxis)
TIA and Enjoy
W
Gilgamesch
Ancient Alien
Very big thanks for all the work
Well i guess i have to overwork some parts in our mod now.
Just one question, do you suggest to add the tables via sql, or can i just go the nooby
xml way?
Well i guess i have to overwork some parts in our mod now.
Just one question, do you suggest to add the tables via sql, or can i just go the nooby
xml way?
JFD
Kathigitarkh
Could Policy_ResourceHappiness be added in the same vein as Belief_ResourceHappiness. Perhaps Building_ResourceHappiness as well, for ultimate unity. Would be appreciated
JFD
Kathigitarkh
Would Policy_BuildingClassYieldModifiers be translatable into a Building table? i.e. Building_BuildingClassYieldModifiers
Could Policy_ResourceHappiness be added in the same vein as Belief_ResourceHappiness. Perhaps Building_ResourceHappiness as well, for ultimate unity. Would be appreciated
Belief_ResourceHappiness is not a valid function in the dll - it was never implemented fully (it has XML and basic data, but was not integrated elsewhere). As such, it was not included in the unifiedyields project.
Possibly, however the I fear the performance impact of doing a loop for all buildings within every building file - probably not a good idea.
G
JFD
Kathigitarkh
Okay, no problem. They're not essential, so can be stricken from the requests.
Sorry - unfortunately, there are some false XML rows that aren't actually in the DLL. Odd, really.
Did you see my test version for you regarding the puppet override purchases?
G
Did you see my test version for you regarding the puppet override purchases?
G
Vicevirtuoso
The Modetta Man
I hope I'm not about to ask for the Heavens and Earth to be moved.
What are the odds that the Yields table can be made more extensible? Such that new entries in the <Yields> table will not experience the very erratic behavior they currently do. I wanted to add a new yield to my mod, and got it in successfully with its own icon and plot yield icons, but...well, it seems to grant every tile in my territory over a million of the yield and my capital has over 150,000 of it as a base. The values also change each time, and even change between loading the same save file.
Of course, all I ask for is for proper tracking of the yield -- I'll handle what the yield actually does in Lua. I'm just hoping that every ID in the Yields table doesn't have to be hard-coded in the DLL for it to be workable.
What are the odds that the Yields table can be made more extensible? Such that new entries in the <Yields> table will not experience the very erratic behavior they currently do. I wanted to add a new yield to my mod, and got it in successfully with its own icon and plot yield icons, but...well, it seems to grant every tile in my territory over a million of the yield and my capital has over 150,000 of it as a base. The values also change each time, and even change between loading the same save file.
Of course, all I ask for is for proper tracking of the yield -- I'll handle what the yield actually does in Lua. I'm just hoping that every ID in the Yields table doesn't have to be hard-coded in the DLL for it to be workable.
Unfortunately, it does. :/
There's a yield table in the enums of the DLL that needs to have the yield identified there for the dll to use it. That said, you could try the lua method of adding a yield. See the Health and Plague mod for how to do that - just make sure to assign the yield a unique ID (i.e. don't overwrite an existing ID #) or it'll crash on you.
G
Vicevirtuoso
The Modetta Man
A shame. Guess I'll have to rethink how I was going to implement this yield, since it was going to have tile-based yields and all.
Well, on a different note, I'm not sure if this is the best place to ask this question, but it may be better than a new thread. Would it be possible to have all Yield-From-Kill calculations (Monty trait, Honor opener, etc.) calculate the yields based off of the unit's currently set combat strength rather than its base strength in the database? That way, units which retain their relevance throughout the game using SetBaseCombatStrength() will provide on-par rewards when killed in later eras.
You mean counting promotions or something like that? Because in my eyes, current combatstrength would be the number that decreases as the unit gets damaged (unless you're playing Japan)
On a completely different note and even more offtopic, I think CEP managed to channel the Aztec UA into the capitol so that the culture you get from kills actually helps your borderexpansion, it would probably be too powerful to add that to the honor opener, but it sure wouldn't hurt Monty to have some extra power in his UA.
A shame. Guess I'll have to rethink how I was going to implement this yield, since it was going to have tile-based yields and all.
Well, on a different note, I'm not sure if this is the best place to ask this question, but it may be better than a new thread. Would it be possible to have all Yield-From-Kill calculations (Monty trait, Honor opener, etc.) calculate the yields based off of the unit's currently set combat strength rather than its base strength in the database? That way, units which retain their relevance throughout the game using SetBaseCombatStrength() will provide on-par rewards when killed in later eras.
It should already do this, but I'll look into it.
If it isn't this way, it should be, at least for Monty's UA.
G
