SilentConfusion
Emperor
I just started a new game. And the traits were definitely different than before so his new traits were working with Developing Leaders.
ls612's Traits
- Thread starter ls612
- Start date
I just started a new game. And the traits were definitely different than before so his new traits were working with Developing Leaders.
Thunderbrd
C2C War Dog
No recalc involved in this at all then? Ok... that helps to know.
SilentConfusion
Emperor
This is a bug, but since it is specifically about the interplay between Developing Leaders and Focused Leaders options.
Before the normal traits were in play with developing traits even if focused traits was checked at start. Now if both are checked the focused traits are definitely used, so that's a step in the right direction, but when I have to select my first trait I get something that definitely wasn't expected. There is the list box as normal but there are two of every trait listed and the protective trait looks funny. Screenshots below. I can provide a save that demonstrates it too if that would help anyone.
Before the normal traits were in play with developing traits even if focused traits was checked at start. Now if both are checked the focused traits are definitely used, so that's a step in the right direction, but when I have to select my first trait I get something that definitely wasn't expected. There is the list box as normal but there are two of every trait listed and the protective trait looks funny. Screenshots below. I can provide a save that demonstrates it too if that would help anyone.
Attachments
Thunderbrd
C2C War Dog
The problem seems to have been isolated in its cause. I presume ls612 will have this taken care of soon.
Should be fixed now on the SVN.
Arkenor
Warlord
I just started a new game with your traits, and developing traits. Today's build, ver 5206.
When the window to choose a new trait pops up, every trait is listed twice.
The Protective Trait does not have an icon.
The Charismatic Trait claims to grant a 1631580% bonus to military unit production. I feel this might be excessive. I'm also a little scared of what happens if one of my neighbours chooses it.
When the window to choose a new trait pops up, every trait is listed twice.
The Protective Trait does not have an icon.
The Charismatic Trait claims to grant a 1631580% bonus to military unit production. I feel this might be excessive. I'm also a little scared of what happens if one of my neighbours chooses it.
Thunderbrd
C2C War Dog
Keep in mind you need to be replacing TRAIT_AGGRESSIVE1, not TRAIT_AGGRESSIVE ls. Not sure if this is what caused what he's talking about though.
Odd on the Charismatic trait but I'd look to see the rest sorted out first and then see if its still causing that issue.
Odd on the Charismatic trait but I'd look to see the rest sorted out first and then see if its still causing that issue.
It is doubly odd because my Charismatic1 XML has no modifiers whatsoever to military unit production. I'd start looking at AIAndy's replacement code for this problem, as it seems to have to do with bad pointers.
@Arkenor: Does the large number change ever?
Arkenor
Warlord
Sorry, I don't know. I was concerned that having AIs running around with the power to instantly build units at no cost would be gamebreaking, so restarted with regular traits.
For all I know it's just a display error, rather than a real bonus. But that is definitely what it was telling me. It's easy enough to check if anyone else can see it, as it was also listed in the Civopedia entry.
Edit: Loaded my old game back up. The number is the same, and I have attached a screen shot on the civopedia entry.
Attachments
I just stepped through the gametext code with the debugger and it gave me a value of 1%. It seems that the value of m_iMilitaryProductionModifier is unrelated to what is in the XML (ie, nothing). This, coupled with some odd stuff I was seeing with isOptionEditCached leads me to believe that something is wrong with option edits somewhere. Please post this in the bugs/crashes thread.
It is probably the order in which those things are done in CvGame::update
Code:
resetOptionEdits();
setOptionEdits();
GC.updateReplacements();Sorry, I think I was unclear. My trait set uses your XML replacement system, which I think of in my head as option edits as well even though I know that that is only Thunderbrd's thing. And that wouldn't be right anyways because the value of m_iMilitaryProductionModifier is determined during XML load IIRC, which would make your system there look like the problem.
It would screw up the entire object or nothing as it loads both and just switches the pointer to the whole object.
There might be problems but a simple value like this?
There is one mistake in the trait coding. The copyNonDefaults uses the normal access functions but those in turn rely on game options which are not valid during game load.
Well, nowadays it just returns false but it is still bad coding.
Flinx
Prince
- Joined
- Dec 8, 2005
- Messages
- 455
If you code as <iMilitaryproduction>0</iMilitaryproduction> or you completely leave out the line with <iMilitaryproduction/> you get the desired result as no modifier.
At least it helped me with fixing the Military production to a reasonable level.
I mean building twenty to thirty units per turn is a bit overpowered, and we are talking about an average city, not my specialized military city.
Thunderbrd
C2C War Dog
I plan to rip it out this cycle. I figured I'd have it done by now but I'm stuck on a serious mystery here which I HOPE I can resolve by the end of the weekend. Ah well... at least it did what I wanted it to and was an exercise in exploring application of an imagined method to real coding.
Me too. I figure we need to call it something by a standard so that we can at least communicate the concept effectively on the forums and as this was how it was introduced so that's pretty much the term for it regardless of the method it is done through. I certainly mean no ego in that either... even if it IS all that really remains of a few weeks of solid effort and a month of planning or so
Admittedly, AIAndy's method is just flat better. Sometimes its hard to live in the shadow of such an awesome programmer when you're trying to learn but its compensated by the fact that he does offer such a helpful hand in trying to pull us closer to his degree of understanding here. Thanks for everything AIAndy! I know you just want things done in the most effective way and it's gotta be frustrating to work with a noob who gets all excited to simply have figured out ANY way. lol!That's what I was thinking too. This is one of my tags we're talking about here so I could believe there's a yet undiscovered bug in the way it gets brought into the dll (perhaps its missing from the statement at the beginning that gives it a default of 0 if no value is in its place?) but what gets me on it is that it apparently works just fine when the option edit mechanism (yours) is not in use? Wouldn't it then stand to reason that it can't be a matter of the programming of the tag at its core?
Yes... that's very interesting to note. I take it you see a way that can be improved on then? And as an aside, that wouldn't explain this issue would it? Since this is an option edit without a modular override coming into play on it thereafter? Also, if this was the case, wouldn't a save and reload fix it? Game options stay as they were selected last when the game is saved and the mod is closed then reloaded.
AFAIK the MS XML parser that Civ 4 uses will treat all three of those instances as the exact same thing, so I don't see how that could be the problem.
@Thunderbrd: The only possible thing I can see wrong with the Traits loading code is that it calls for the current game (GC.getGameINLINE()) in contexts where it shouldn't, same as my Scale City Limits code did. In that case it caused crashes, and Koshling fixed it by adding a bRawXMLValue parameter to the function. You might want to look at that as an example of what I mean, it could be the solution to this.
Thunderbrd
C2C War Dog
hmm... I used those calls for option edits. Those are getting removed. And I suppose I would've used them for the Pure Traits mechanism too. But we haven't had trouble with that so far and again, why would it isolate out THIS one tag and not be bugging everything else?
Still, I'm curious to see what you did for a workaround. I've not heard of any potential issues with getGameINLINE() (and could it simply be the INLINE part that was causing a problem?) What's the function that's taking place in exactly?
Still, I'm curious to see what you did for a workaround. I've not heard of any potential issues with getGameINLINE() (and could it simply be the INLINE part that was causing a problem?) What's the function that's taking place in exactly?
Flinx
Prince
- Joined
- Dec 8, 2005
- Messages
- 455
Obviously not since with the notation you chose the military modifier skyrockets to +16million percent.
You might want to do a test with your traits and choose charismatic.
I'm pretty confidend you will get the same experience, testing against the SVN version that is.
Otherwise i stand corrected for sure.
As I posted above, I did test it and I got plus 1 percent. Which would indicate something else is going on. And it isn't just a display issue either, I tested it in the debugger and the underlying value was screwed up.
No, that is the source of the problem here.
<iMilitaryProductionModifier/> is equivalent to
<iMilitaryProductionModifier></iMilitaryProductionModifier>
which is not a valid entry for an integer and will cause a semi-random value to be read like you see.
The issue is that many copyNonDefaults implementations use the getter methods to retrieve the value that they copy. That happens during game load when there is no meaningful game object yet.
When I moved the option array construction to when the actual game is started or a savegame is loaded, that kind of acccess during game startup caused crashes. Nowadays there is a check in there that always returns false for any game option which in your case happens to make it return the right value for copying the raw value.
Instead of adding a raw getter like Koshling did in the other case I think simply using the variable directly in the copyNonDefaults is a good solution.
