Trouble merging kmod and super forts

here is the code, i moved the i value as you said


error still..

Your code still does not match mine. Your first declaration of int iValue needs to be moved up a couple lines, and you should not have a second one.

Red Key said:

Oops. Just add in the line "int iValue;" like so before line 21224:

Spoiler :

Code:

// Super Forts begin *AI_worker* - this should better determine the value of a build than the original code
												[B]int iValue;[/B]
												if(GC.getDefineINT("SUPER_FORTS_SAFE_BUILD") != 0)
												{
													iValue = GC.getBuildInfo(eBuild).getTime();
													if(GC.getBuildInfo(eBuild).isKill())
													{
														iValue += 10000;
													}
													if(GC.getImprovementInfo((ImprovementTypes)GC.getBuildInfo(eBuild).getImprovement()).isActsAsCity())
													{
														iValue /= 10;
													}
												}
												else

Click to expand...

Lib.Spi't said:

here is the code, i moved the i value as you said

Spoiler :

Code:

//if (bDoImprove)
						if (bDoImprove && eBestTempBuild == NO_BUILD) // K-Mod
						{
							int iBestTempBuildValue = MAX_INT; // K-Mod
							for (int iJ = 0; iJ < GC.getNumBuildInfos(); iJ++)
							{
								BuildTypes eBuild = ((BuildTypes)iJ);

								//if (GC.getBuildInfo(eBuild).getImprovement() != NO_IMPROVEMENT)
								{
									//if (GC.getImprovementInfo((ImprovementTypes) GC.getBuildInfo(eBuild).getImprovement()).isImprovementBonusTrade(eNonObsoleteBonus) || (!pLoopPlot->isCityRadius() && GC.getImprovementInfo((ImprovementTypes) GC.getBuildInfo(eBuild).getImprovement()).isActsAsCity()))
									if (kOwner.doesImprovementConnectBonus((ImprovementTypes)GC.getBuildInfo(eBuild).getImprovement(), eNonObsoleteBonus)) // K-Mod
									{
										if (canBuild(pLoopPlot, eBuild))
										{
											if ((pLoopPlot->getFeatureType() == NO_FEATURE) || !GC.getBuildInfo(eBuild).isFeatureRemove(pLoopPlot->getFeatureType()) || !kOwner.isOption(PLAYEROPTION_LEAVE_FORESTS))
											{
												// Super Forts begin *AI_worker* - this should better determine the value of a build than the original code
												if(GC.getDefineINT("SUPER_FORTS_SAFE_BUILD") != 0)
												{
													[B]int iValue;[/B]
													iValue = GC.getBuildInfo(eBuild).getTime();
													if(GC.getBuildInfo(eBuild).isKill())
													{
														iValue += 10000;
													}
													if(GC.getImprovementInfo((ImprovementTypes)GC.getBuildInfo(eBuild).getImprovement()).isActsAsCity())
													{
														iValue /= 10;
													}
												}
												else // Original Code is used if SUPER_FORTS_SAFE_BUILD is turned off
												{
													iValue = 10000; // Original Code
													iValue /= (GC.getBuildInfo(eBuild).getTime() + 1); // Original Code
													// XXX feature production???
												}
												// Super Forts end
												[B]int iValue;[/B]
												if (iValue < iBestTempBuildValue)
												{
													iBestTempBuildValue = iValue;
													eBestTempBuild = eBuild;
												}
											}
										}
									}
								}
							}
						}

error still..

Spoiler :

1>CvUnitAI.cpp
1>CvUnitAI.cpp(21237) : error C2065: 'iValue' : undeclared identifier
1>CvUnitAI.cpp(21238) : error C3861: 'iValue': identifier not found, even with argument-dependent lookup

Click to expand...

First, you are declaring iValue in 2 different places. Don't do that. (There might be some situations where you want to do this. This is not one of them.)

Second, when you declare a variable inside any level of "{}" it is only valid inside that "{}". This is called the "scope" of the variable. The first time it is declared is "too far in" - it is used at a scope that is outside where it is declared, after the "if/else" code ends. But you are also declaring it again after that. This second iValue is a completely different variable than the first one and it is not set to anything, so you are likely to end up with random junk when using an optimized release build (debug builds should set it to 0, optimized builds may very well just leave it set to whatever was already in the memory it allocated which may or may not be 0).

You should declare it, just once, probably not much later than around where eBuild is declared just inside the "for" loop (although you could do it up inside one or more of the "if" statements, just not too far in like it is now). Alternatively you could declare it outside the loop around where the iBestTempBuildValue is declared. Some people prefer declaring it inside the loop, others outside. (I would prefer outside, actually - the optimization should cause it to only allocate it once when it is declared in the loop, but I prefer to make sure by not putting it inside the loop. Others prefer to put it in the loop because outside the context of the loop the variable is not useful, so they have the declaration placed where the scope of the variable only covers where it is used.)

As an aside:

Thank you, Red Key!

After merging CvUnitAI::AI_bombardCity, it compiled OK but with a warning:

cvunitai.cpp(15535) : warning C4715: 'CvUnitAI::AI_bombardCity' : not all control paths return a value

note: line 15535 is the closing bracket of the function in my file

What does it mean?

GOAL!

Thanks red for being patient with my ineptitude!

I attached the finished file incase anyone wants it.

Thanks for the explanation emperor I just wish I understood it properly

isenchine said:

Thank you, Red Key!

After merging CvUnitAI::AI_bombardCity, it compiled OK but with a warning:

cvunitai.cpp(15535) : warning C4715: 'CvUnitAI::AI_bombardCity' : not all control paths return a value

note: line 15535 is the closing bracket of the function in my file

What does it mean?

Click to expand...

That function is supposed to return true if something is bombarded and false if something wasn't. That warning is telling you that under certain conditions the function won't return anything which is a problem. Add "return false;" before the very last } of the AI_bombardCity function and it should be fixed.

God-Emperor said:

As an aside:

Spoiler :

I also have to wonder who wrote code that has a smaller value being the "best" value - most other places it prefers larger values. It also seems peculiar in what it is doing. In particular, the "super forts" version will prefer whichever is the quickest to build that doesn't kill the worker but does act as a city. If you have one that is significantly better a higher defensive bonus and higher air bomb defense) but takes longer to build, it probably won't pick it as the best (unless the dividing it by 10 makes it the same integer and it comes first in the file). The "Original Code" version preferred whichever one took the longest to build, regardless of other properties (again, ties after the integer division go to whichever was first in the file). Neither one of these seems very good (although the new one is slightly better, I suppose) as they don't ever really consider any of the actual defensive properties of the fort in determining its "value".

Click to expand...

Yep whoever at Firaxis coded this considered the smallest value the best, and the only thing really considered is the build time. I've seen this same code in other places when determining what improvement to build. I've been considering taking my part out and just using the original code since that is the way things are done other places. There are other parts of the code where all an improvement's effects are properly considered like when determining the best thing to build near a city in AI_bestCityBuild.

Red Key said:

That function is supposed to return true if something is bombarded and false if something wasn't. That warning is telling you that under certain conditions the function won't return anything which is a problem. Add "return false;" before the very last } of the AI_bombardCity function and it should be fixed.

Click to expand...

Thank you.

EDIT: "return false;" added as per instruction. Merge OK - no more warning.

@isenchine
Thank you for your endless efort here, wheter in combining PAE with K-Mod or K-Mod with Super Forts.
Me and my small multiplayer team can't await to enjoy it. We currently play with K-Mod. We would like to play PAE too, but oss is killing us badly.

Thank you, zhongguo and ... Welcome to CFC!

Unfortunately, I have no experience in MP. I know that Karadoc is very keen to have his K-Mod Multi-Player. PAE is full of Python code and I have no idea what could cause OOS in MP.

It still will take a long time I guess until PIE's .dll will be optimized for MP purpose.
However, what about K-Mod + SuperForts?

As far as I know, it should be MP friendly.

So you already finished mixing these two mods?

Yes and no. It's a complicated story.

At one point of time, I did it for myself, for my mod, without succeeding in merging successfully cvunitai.cpp.

Then came Lib.Spi't who had errors in merging (again in his own mod), K-Mod (not the latest version) with SuperForts (so this thread).

In the end, thanks to the help of Red Key himself, he got it fixed, including cvunitai.cpp.

In other words, no, sorry, we don't have a final cut of just K-Mod + SuperForts!...

Will you do it anyway?

Maybe I should, but not in the near future. I'm not promising anything right now but I will keep it in mind.