Caveman 2 Cosmos
- Thread starter strategyonly
- Start date
I was editing my posts to not double post unless my commit was something bigger.I thought we were doing that as not to spam people with alerts.
Thunderbrd
C2C War Dog
I'd far rather be spammed by alerts than have activities go unnoticed.I thought we were doing that as not to spam people with alerts.
Thunderbrd
C2C War Dog
Does anybody know why the Wooden Tower improvement has the Stone Tower upgrade commented out? Can we return that to being upgradeable?
I have it turned on in the "My take on stuff" modmod, I think DH commented it out for some reason, but I never commented it out in my modmod because I didn't really see why it should be.
It seemed to work fine in my games...
The reason may have been related to the maximum range for unit visibility, something about the upgrade not actually giving longer visibility.
JosEPh_II
TBS WarLord
DH did it. And I forgot why. One less step in the upgrade chain to Fort?
Thunderbrd
C2C War Dog
Yeah I don't remember why either so it's probably something where I should hear from him before I do it. I think it had something to do with a frustration over culture growth from towers or something.
10347
Fix dumb parse error for CivicInfos.xml, Somehow added a 6 before the 1st line that starts <? at top of file.Crickey!
Thunderbrd you made small error in Medieval era that I fixed, also there was weird break from pattern in Classical era resulting in faster growth of cities.
In Medieval era you neutralized growth rate instead of construction costs.
I guess you both are modding for so long, that you don't use "Compare with base" tool when committing file (right click on file, when you are committing files)
.Reducing construction costs will help AI even more in later eras.
On my tests it was building planes and they could build tanks and other stuff like that.
By the way units are cheaper on SM (global 70) than without it (global 105), so everyone can build more units.
I added excel file with raw and modified tech/building cost arc and its graph.
How do you like revised strategy and pedia texts of civics?
Strategy text appears when new civic is unlocked (Do you want to change to....) and inside of civic screen as yellow text.
Kation revised those.
I'm doing another Tiny/Nightmare/Blitz test on C2C_World mapscript.
Traits are disabled altogether and I'm using all combat mods.
Last edited:
Thunderbrd
C2C War Dog
No not usually. Sorry - I suppose I did all that in a hurry since it wasn't a plotted out project but a quickfix.
Cool I suppose - probably haven't done much reading of them tbh. I'm not sure I like some of the renamings... Burned? That's the name of a civic now? I mean - I get the thinking behind it but I'm not a fan of it.
In some places you see only civic names - I think diplomacy and tech splash screens.By all means, rename whichever you think are bad.
That is you don't know from what categories such civics are.
Thunderbrd
C2C War Dog
Well put. That's my entire issue with that particular name.
I don't mean to be mean about this. It's really exactly what Rax just said that irked me about it.
I guess those strings could be changed - instead of Civic it could be Category: Civic or Civic (Category)
@Toffer90 is it possible to change displayed strings to like this?
@Thunderbrd @Toffer90 I'm having an issue with adding a variable to the .dll
I'd like to add an additional string that represents the civic category when someone picks a new civic. It's located at XML\Text\CIV4GameTextInfos with the tag TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC. It's currently written as this:
I looked for something referencing it in the Source files and found one in CvPlayer.cpp line 19533 and line 19539. It's written as this:
I then went into Python/Screens/CvCivicsScreens to see what is used to get each category name, I believe it's what's on line 265:
I tried adding this to the .cpp file, ending with something like:
It successfully compiled. I then changed the text file in CIV4GameTextInfos to:
Now the issue is that in game it shows like this:
Any reason as to why?
I'd like to add an additional string that represents the civic category when someone picks a new civic. It's located at XML\Text\CIV4GameTextInfos with the tag TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC. It's currently written as this:
XML:
%s1_PlyrName adopts [COLOR_HIGHLIGHT_TEXT]%s2_CvcName[COLOR_REVERT]!
Code:
szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide());
Python:
gc.getCivicOptionInfo
Code:
szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicOptionInfo(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide());
XML:
%s1_PlyrName adopts the [COLOR_HIGHLIGHT_TEXT]%s2_CvcOptionType[COLOR_REVERT] civic [COLOR_HIGHLIGHT_TEXT]%s3_CvcName[COLOR_REVERT]!Any reason as to why?
Thunderbrd
C2C War Dog
This is tough for me to explain but I'll try.
The data is a mismatch and you aren't giving the correct data in the correct parameter position.
The original statement:
szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide());
gDLL->getText()
is the function call. Inside the () goes the parameters. I'm sure you get this but I'm establishing my ability to express this in a less confusing way.
The first parameter fed to this function is "TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC" since it's the data given prior to the first comma (,).
The second parameter is getNameKey() (it's then immediately followed by a comma as the parameters are comma delineated.)
The third and final parameter is GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide(). This is all one data parameter and it is a function call itself to getting the civic information on the civic defined currently by getCivics(eIndex) and then defining (after the period) the type of information of that civic - specifically getTextKeyWide() - the term referring to the string name of the civic. There's a few calls to the name - this one is safe for most applications and is, from what I can tell, generally the best one to use.
After that parameter, the ) at the end indicates we're done entering parameters. This is a getText call, though, so with this you can enter in any number of parameters and it will feed those parameters into the variables in the order those variables appear in the text itself as written in the Text file. So the first parameter calls which text you are drawing on and the parameters to follow feed the variables called for in that text. If there are less variables in the text than what is fed to that text in the parameters here, it neutrally ignores that - no bug but not quite correct in form.
You gave it 3 variables in the parameters.
szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicOptionInfo(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide());
This is not code-incorrect so the compiler won't catch that.
GC.getCivicOptionInfo() is the parameter you gave for the civic's name. That's a raw call to the class of Civic Option Infos themselves. Not a bad form of data to call in some spots but it's going to come up with a NULL for a string.
Then you give a comma and feed another parameter, which is more like what it would be looking for, a name call to the civic currently being referred to by eIndex. That's in the 3rd text variable slot and the text only calls for 2 variables so you don't see it delivered in the text. You see the NULL (converted to string by an automatic background portion of the function call that fills in ??? when it can't figure out what you've given it) in that 2nd text variable instead.
%s1_PlyrName adopts [COLOR_HIGHLIGHT_TEXT]%s2_CvcName[COLOR_REVERT]!
And make it something like
%s1_PlyrName adopts [COLOR_HIGHLIGHT_TEXT]%s2_CvcName[COLOR_REVERT] in the %s3_CivicOptionName Category!
%s is % = variable call, s = string, 3 = naming convention to help us see that this is the 3rd variable called for, then without breaking the label (thus using _ to separate the beginning of the variable call) name the thing whatever you want it to be. It could be %sMyDogIsAnIdiot and that would work just as well. The magic is in % and the rest is naming convention to help the sanity of programmers who have to look at your stuff later.
Then fix the text call in the dll itself:
szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide(), GC.getCivicOptionInfo(GC.getCivicInfo(getCivics(eIndex).getCivicOptionType())).getTextKeyWide());
GC.getCivicOptionInfo(GC.getCivicInfo(getCivics(eIndex).getCivicOptionType())).getTextKeyWide() may or may not be quite right but the idea is to get the name of the civic option that the civic under evaluation during this text call defines as it's civic option type. Let me know if you need me to break down this syntax a bit further to help you understand the order of object calls and parameters being filled in.
Is this making sense?
The data is a mismatch and you aren't giving the correct data in the correct parameter position.
The original statement:
szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide());
gDLL->getText()
is the function call. Inside the () goes the parameters. I'm sure you get this but I'm establishing my ability to express this in a less confusing way.
The first parameter fed to this function is "TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC" since it's the data given prior to the first comma (,).
The second parameter is getNameKey() (it's then immediately followed by a comma as the parameters are comma delineated.)
The third and final parameter is GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide(). This is all one data parameter and it is a function call itself to getting the civic information on the civic defined currently by getCivics(eIndex) and then defining (after the period) the type of information of that civic - specifically getTextKeyWide() - the term referring to the string name of the civic. There's a few calls to the name - this one is safe for most applications and is, from what I can tell, generally the best one to use.
After that parameter, the ) at the end indicates we're done entering parameters. This is a getText call, though, so with this you can enter in any number of parameters and it will feed those parameters into the variables in the order those variables appear in the text itself as written in the Text file. So the first parameter calls which text you are drawing on and the parameters to follow feed the variables called for in that text. If there are less variables in the text than what is fed to that text in the parameters here, it neutrally ignores that - no bug but not quite correct in form.
You gave it 3 variables in the parameters.
szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicOptionInfo(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide());
This is not code-incorrect so the compiler won't catch that.
GC.getCivicOptionInfo() is the parameter you gave for the civic's name. That's a raw call to the class of Civic Option Infos themselves. Not a bad form of data to call in some spots but it's going to come up with a NULL for a string.
Then you give a comma and feed another parameter, which is more like what it would be looking for, a name call to the civic currently being referred to by eIndex. That's in the 3rd text variable slot and the text only calls for 2 variables so you don't see it delivered in the text. You see the NULL (converted to string by an automatic background portion of the function call that fills in ??? when it can't figure out what you've given it) in that 2nd text variable instead.
Are you wanting this in the alert? The first thing you need to do is restructure the text to call that additional variable. So take:
%s1_PlyrName adopts [COLOR_HIGHLIGHT_TEXT]%s2_CvcName[COLOR_REVERT]!
And make it something like
%s1_PlyrName adopts [COLOR_HIGHLIGHT_TEXT]%s2_CvcName[COLOR_REVERT] in the %s3_CivicOptionName Category!
%s is % = variable call, s = string, 3 = naming convention to help us see that this is the 3rd variable called for, then without breaking the label (thus using _ to separate the beginning of the variable call) name the thing whatever you want it to be. It could be %sMyDogIsAnIdiot and that would work just as well. The magic is in % and the rest is naming convention to help the sanity of programmers who have to look at your stuff later.
Then fix the text call in the dll itself:
szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide(), GC.getCivicOptionInfo(GC.getCivicInfo(getCivics(eIndex).getCivicOptionType())).getTextKeyWide());
GC.getCivicOptionInfo(GC.getCivicInfo(getCivics(eIndex).getCivicOptionType())).getTextKeyWide() may or may not be quite right but the idea is to get the name of the civic option that the civic under evaluation during this text call defines as it's civic option type. Let me know if you need me to break down this syntax a bit further to help you understand the order of object calls and parameters being filled in.
Is this making sense?
Yes it does, thank you @Thunderbrd!
I'm having some compiler errors, do you know what might be causing that?
Code:
C2228 left of '.getCivicOptionType' must have class/struct/union type 19533
C2228 left of '.getTextKeyWide' must have class/struct/union type 19533
C2228 left of '.getCivicOptionType' must have class/struct/union type 19539
C2228 left of '.getTextKeyWide' must have class/struct/union type 19539Thunderbrd
C2C War Dog
When you get these, doubleclick on the lines that express the errors. That will take you directly to the line where there's a problem. Look for one but if you don't see it, post the code line here and I should be able to spot the issue. I have a suspicion already.
It was the example you posted.
Code:
szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide(), GC.getCivicOptionInfo(GC.getCivicInfo(getCivics(eIndex).getCivicOptionType())).getTextKeyWide());Here's the log:
Code:
1>------ Build started: Project: C2C, Configuration: Final_Release Win32 ------
1>
1>Microsoft (R) Program Maintenance Utility Version 14.16.27023.1
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>
1>SubWCRev: 'D:\C2C\Caveman2Cosmos\Sources'
1>Last committed at revision 10342
1>Updated to revision 10347
1>Local modifications found
1> "C:\Program Files (x86)\Microsoft Visual C++ Toolkit 2003\bin\cl.exe" /nologo /MD /Zi /O2 /Oy /Oi /G7 /DNDEBUG /DFINAL_RELEASE /Fp"Final_Release\CvGameCoreDLL.pch" /Fd"./Final_Release/" /GR /Gy /W3 /EHsc /arch:SSE2 /Gd /Gm- /DWIN32 /D_WINDOWS /D_USRDLL /DCVGAMECOREDLL_EXPORTS /Yu"CvGameCoreDLL.h" /Zm200 /DXERCES_STATIC_LIBRARY /D_MOD_SENTRY /D_MOD_FRACTRADE /D_MOD_GOVWORKERS /DQC_MASTERY_VICTORY /DLOG_AI /D_MOD_GWARM /D_MOD_SHAM_SPOILER /DC2C_BUILD /DMULTI_FEATURE_MOD /IBoost-1.32.0/include /IPython24/include /I"C:\Program Files (x86)\Microsoft Visual C++ Toolkit 2003/include" /I"C:\Program Files\Microsoft Platform SDK/Include" /I"C:\Program Files\Microsoft Platform SDK/Include/mfc" /I"C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\CvGameCoreDLL\Boost-1.32.0/include" /I"C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\CvGameCoreDLL\Python24/include" /I"./xerces-c-3.1.1-x86-windows-vc-7.1/src" /FoFinal_Release\CvPlayer.obj /c CvPlayer.cpp
1>CvPlayer.cpp
1>CvPlayer.cpp(19533): error C2228: left of '.getCivicOptionType' must have class/struct/union type
1> type is 'CivicTypes'
1>CvPlayer.cpp(19533): error C2228: left of '.getTextKeyWide' must have class/struct/union type
1>CvPlayer.cpp(19539): error C2228: left of '.getCivicOptionType' must have class/struct/union type
1> type is 'CivicTypes'
1>CvPlayer.cpp(19539): error C2228: left of '.getTextKeyWide' must have class/struct/union type
1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual C++ Toolkit 2003\bin\cl.exe"' : return code '0x2'
1>Stop.
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.MakeFile.Targets(44,5): error MSB3073: The command "nmake Final_Release" exited with code 2.
1>Done building project "C2C(VS2017).vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========1. is wrong, 2. is right.
- szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide(), GC.getCivicOptionInfo(GC.getCivicInfo(getCivics(eIndex).getCivicOptionType())).getTextKeyWide());
- szBuffer = gDLL->getText("TXT_KEY_MISC_PLAYER_ADOPTED_CIVIC", getNameKey(), GC.getCivicInfo(getCivics(eIndex)).getTextKeyWide(), GC.getCivicOptionInfo(GC.getCivicInfo(getCivics(eIndex)).getCivicOptionType()).getTextKeyWide());
