K-Mod: Far Beyond the Sword

[keldath]

hey k',

well, i saw youve made a lot of changes i guess you know whats best for the mod.

anyway -
i dl the source code,
cause i wanted to add a few mods i play with, and i had a bug in the compile,
so i tried to compiled your source as is and i got the same bug:

CvTaggedSaveFormatWrapper.cpp
CvTaggedSaveFormatWrapper.cpp(3437) : error C2664: 'CvString::Replace' : cannot convert parameter 1 from 'const char [4]' to 'char'
This conversion requires a reinterpret_cast, a C-style cast or function-style cast
CvTaggedSaveFormatWrapper.cpp(3500) : error C2065: 'BUTTONPOPUP_SAVE_INFO_LOST' : undeclared identifier
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin\cl.exe"' : return code '0x2'
Stop.
Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"
Build log was saved at "file://c:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods\CvGameCoreDLL\Release\BuildLog.htm"

i guess theres some error in your files,

can you help me and fix the error in the files?

 

[karadoc]

I don't even have any file called CvTaggedSaveFormatWrapper, and there isn't a file with that name in the unmodded source code either.

Perhaps you copied my code on top of the code for a different mod, and this error is just some unrelated remnant?

 

[keldath]

huh,

you wont let me down huh buddy?

thank you, for some reason i had that file from an old compile , i must have currupted my original source coded of bts...

thank you very much good karadoc.

another matter,
maybe youll be interested on the code i added, which include some new xml tags that add to the game.
lines to the civics,
j-culture mod,
3rd radius city size,
free tech from building,
movable peaks,
fresh water from improvements,
and some tags for units like prereq civic and obsolete unit by tech.



you rock man.

 

[karadoc]

Adding now xml tags can be pretty handy for modding. The stuff you mentioned sound like good options, but I currently don't intend to add improvements that create fresh water, moveable peaks, etc. in this mod - I don't want to stray too far from original BtS. 3rd radius city size is a huge change - it would have far reaching effects on the balance of many things. I don't know what j-culture mod is, but K-Mod already has its own culture system anyway. It was one of the first things I changed, and I'm pretty happy with it.

My approach so far has been to just add tags when I've already got a use for them. For example, I recently added a bunch of new xml tags for handling the new religion removal stuff we were talking about. (For those who are interested, here is my first attempt at the religion changes. I'll be testing those changes along side the rest of the stuff for the next version.)

For the next version, I intend to have just a subtle bias to the spreading of religion with missionaries. The probability of successfully spreading a religion will be slightly higher in cities with a bigger population (big cities can handle having more religions in them); and when a religion would "fail to spread", it gets a chance to bump out an existing religion instead of failing itself.

For the AI, I've already spotted a couple of significant flaws that will be fixed in the next version. The biggest one is that I've just noticed an bug in the original BtS code which causes the AI to reduce its maximum units when it reduces its maintenance costs - for example, if the AI built some courthouses and switched to state property, that would cause it to think it should keep far fewer military units. -- (Actually, it's not so much a "bug" as it is a design flaw.)

There's also a bug which prevents the AI from ever doing a trade mission with a great merchant, and another bug which stops the AI spies from attacking improvements (those are both my fault). Regarding the improvement targeting, I don't think it's a very powerful strategy in most cases anyway; and I'm sure the AI isn't smart enough to understand the subtle cases in which its a good idea. I'm going to re-enable the strategy anyway, but only in limited situations.

.. anyway, all those things will be fixed in the next version; and there will be a bunch of other AI improvements as well.

 

[karadoc]

But from now on I expect save compatibility to not be a problem.

Umm, about that... In the next version I'm going to add a new unit AI type; and the code required to maintain save compatibility would be messy. I'm thinking of just skipping the messy code and breaking the save format instead. Would anyone be too upset if I did that?

(Specifically, I'm adding UNITAI_GREAT_SPY. In original BtS, great spies just used the same AI type as great merchants.)

In other news, yesterday I found (and fixed) a truly remarkable bug from the original BtS code. I was shocked and amazed when I found it. The bug essentially prevented AI settlers from ever walking towards the same destination two turns in a row. The bug was forcing them to alternate between possible city sites every turn. It's a wonder that they ever managed to get anywhere useful at all!

 

[Linkman226]

Talk about a bug. That's pretty bad.

What exactly was the offending bit of code, if you don't mind my asking?

 

[karadoc]

Here's how the bug came about:
AI_settleMove() is what is used to move settlers. It checks a bunch of stuff, and then calls AI_found() if it wants the settler to find somewhere to settle. AI_found() does some rough evaluation of where it should send the settler, including the following condition:

if (GET_PLAYER(getOwnerINLINE()).AI_plotTargetMissionAIs(pCitySitePlot, MISSIONAI_FOUND, getGroup()) == 0)

That line basically says "if we already have a settler targeting this site, then we shouldn't go there." It sounds like a fair enough statement, except that it could be this settler that was told to go to the site on the previous turn.

So the AI is doing all these calculations to work out the best site, and then it start going to the site; but on the next turn it has to pick a different site because the first site has a settler going to it already...

To fix the bug, I didn't remove that condition, because that could result in multiple settlers going to the same site. Instead, I added some stuff to AI_settleMove() to tell the AI to continue previous missions rather than trying to find a new best site. Here's what my new code in AI_settleMove() looks like.

	if (plot() == pCitySitePlot)
	{
		if (canFound(plot()))
		{
			if( gUnitLogLevel >= 2 )
			{
				logBBAI("    Settler founding in place since it's at a city site %d, %d", getX_INLINE(), getY_INLINE());
			}

			getGroup()->pushMission(MISSION_FOUND);
			return;					
		}
	}
	// K-Mod. If we are already heading to this site, then keep going!
	// This change fixes a bug which prevented settlers from targetting the same site two turns in a row!
	else
	{
		CvPlot* pMissionPlot = getGroup()->AI_getMissionAIPlot();
		if (pMissionPlot == pCitySitePlot && getGroup()->AI_getMissionAIType() == MISSIONAI_FOUND)
		{
			// safety check. (cf. conditions in AI_found)
			if (getGroup()->canDefend() || GET_PLAYER(getOwnerINLINE()).AI_plotTargetMissionAIs(pMissionPlot, MISSIONAI_GUARD_CITY) > 0)
			{
				if( gUnitLogLevel >= 2 )
				{
					logBBAI("    Settler continuing mission to %d, %d", pCitySitePlot->getX_INLINE(), pCitySitePlot->getY_INLINE());
				}
				CvPlot* pEndTurnPlot = getPathEndTurnPlot();
				getGroup()->pushMission(MISSION_MOVE_TO, pEndTurnPlot->getX(), pEndTurnPlot->getY(), MOVE_SAFE_TERRITORY, false, false, MISSIONAI_FOUND, pCitySitePlot);
				return;
			}
		}
	}
	// K-Mod end
	iAreaBestFoundValue = std::max(iAreaBestFoundValue, pCitySitePlot->getFoundValue(getOwnerINLINE()));

[edit]
I was looking over the code again today, and I now think I was wrong - at least partially.

There actually is a check in the original code to make sure it's not the same group targeting site. ("pSkipSelectionGroup" which gets set to "getGroup()" in AI_found.) So... well, I'm not entirely sure why it wasn't working properly.

But the fact remains that the AI settlers definitely were oscillating between potential city sites. I've seen them do it, and I've seen it written in the AI logs... and the behavior was corrected by my changes. I'm just no longer sure what the exact cause of the problem was.

 

[keldath]

when the new version will be released?

)))

 

[Linkman226]

Here's how the bug came about:
AI_settleMove() is what is used to move settlers. It checks a bunch of stuff, and then calls AI_found() if it wants the settler to find somewhere to settle. AI_found() does some rough evaluation of where it should send the settler, including the following condition:[snip]

Thanks. Surprising the developers didn't notice that.

 

[Rheikon]

Wow, this sounds great. Glad to see someone still willing to work on AI. Are you gonna cut down the AI cheating too if it still is?

 

[karadoc]

when the new version will be released?

I'm not really sure. But probably pretty soon. I've made some changes that are obvious improvements (such as fixing the great merchant bug), but there are some changes that are questionable and need further testing. I don't want to release a new version and then later find out that it's actually worse than the previous version. For example, I mentioned earlier that I've discovered a "design flaw" in how the original AI sets its unit building limits... well, fixing that problem is not completely straight forward, because any change I make will affect the AI's unit building throughout the game, and its probability of declaring war and stuff like that. I've made up a new formula for the unit limit, but it's hard to tell if its actually better or worse without playing through a few games.

Wow, this sounds great. Glad to see someone still willing to work on AI. Are you gonna cut down the AI cheating too if it still is?

I'm glad you're glad. I haven't cut down on the AI's cheating so far, but I've been consciously trying not to make it cheat any more than it already does! The AI's cheating is actually pretty minor anyway. The bonuses it gets from the difficulty level handicap is far more significant... so if you really want to play against the AI on a more equal footing, then lower the difficulty level to noble! .. Actually, that's a big part of my motivation for improving the AI. I was winning on Emperor almost every game, but I didn't want to bump the difficulty up to Immortal because although I like a challenge I don't want the game is to be entirely about exploiting AI flaws to catch-up with the bonuses they get at the start of the game... I figure that if keep making the AI better, then I won't have to increase the difficulty level to get a decent challenge. And when I win a game, I like to be able to feel like I won because I played well, not because the AI did something stupid.

 

[Rheikon]

Cool, wasn't sure how bad the AI cheating was for sure, good to know its mostly based on the difficulty scale. I eagerly await further developemnt

 

[Lenowill]

Just wanted to chime in here and say that my significant other and I have been trying the mod, and we're loving it. ^_^ We've never seen a mod make so many good subtle AI changes along with such intuitive changes to the way Culture works. We heartily approve.

I would love to see a merge at some point that includes the Multiple Production mod option (something I got used to when I played PIG Mod when PoM was still developing it), as I really like that option a lot.

The upcoming changes to religion are exciting and scary at the same time ... I hope you can come up with a way to make religion in general more balanced and interesting without having to totally overhaul the game mechanics.

I heartily support the goal of making a mod that can be played on a more normal difficulty like Noble, Prince, or Monarch by a skilled player with that player still feeling a challenge. Like you, I think it's a bit silly that winning on Immortal and Deity frequently involves heavy abuse of the AI's stupidity, since beating their ridiculous production bonuses (and their free starting workers and so forth) would be all but impossible if the AI actually played anywhere near as intelligently as a human can.

The changes to the AI's use of espionage have surprised me in a good way. Foment Unhappiness is EVIL now! Never have I felt such a strong need to actually build spies for Defense. >.< I'm nextdoor to Gilgamesh in my current game and suspect he's the one doing it.

Anyway, just letting you know I'm playing with the mod. I'll try to provide more feedback as time goes on. Best wishes for the next version! We eagerly await.

 

[karadoc]

Thanks, Lenowill. That's great to hear.

Regarding the religion changes; at this stage they certainly aren't something to be scared of. To be honest, the changes in the current version are barely even noticeable. Ultimately, I'm hoping to do just what you said: make religion more balanced and interesting without having to totally overhaul the game mechanics. But I'm not really sure how best to go about it, so I'm taking it slow for now. My first goal is to just reduce the dominance of the early religions.

I've just uploaded the new version – the landmark version 1.00. As usual, most of the work is in the AI changes. The gameplay changes are only minor. The new framework for how religion is spread is a significant change, but I've chosen the parameters such that the effects are small. (if you want to experiment with the religion stuff, feel free to try changing some of the new religion numbers in GlobalDefinesAlt.xml.)

Unfortunately, this version breaks the save-game format again. So if you are in the middle of a K-Mod game, you'll have to finish it before installing this version otherwise you won't be able to load your save. I'm sorry about that. The change that breaks the save format is the new unit AI type for great spies. Previously, the AI did not distinguish between great spies and great merchants. I had to add the new AI type for them to be used differently. The new great spy code doesn't really do anything fancy, but it is a bit different to the merchant code. The main difference is that if the AI is saving its spy for a golden age, it will use it to do some recon rather than just leaving it in a city.

That reminds me... I forgot to write in the change log that great spies can now intercept enemy spies in the same way that ordinary spies can. ... not that it really makes much difference.

 

[karadoc]

A couple of things I forgot to mention in my previous post.

Regarding the Multiple Production mod, I will probably add it for the next version.
I'm kind of in two minds about whether or not it's a good feature, and it's the kind of gameplay features that I think should be either in or out because it affects balance and such. But as long as the "no espionage" option exists in its current form (a hopelessly and completely broken option), I can't really use that excuse for not including multiple production as an option...

In the past, I've been frustrated that sometimes I get such high productivity in particular cities that they can't really build anything without wasting hammers. That could been seen as a game flaw which multiple production would correct. But on the other hand, it could be seen as a balance feature - so that you can't completely stack all of your productivity in one city.
With multiple production, maybe I'd actually build some cruise missiles... (currently, I never ever build those things, because the cities I would like to build them in have too much production and my other cities are too busy building their infrastructure.)

One thing I don't like about the multiple production mod is that the player needs to use the build queue to take advantage of it. You and I may use the queue all the time, but some players rarely use it, and I know the AI doesn't currently use it at all - ever. ...

So, I'm considering implementing a different version. What I've got in mind is to automatically assign the any overflow beyond the usual max overflow to the same kind of unit, rather than assigning it to the next thing in the construction queue. For buildings / projects / wonders, the system would be the same as it is now; but for units, instead of excess overflow turning into gold, it would turn into more of the same kind of unit. The point of this would be to remove the need to queue things, and to simplify the multiple-production rules (it would just be units vs non-units, as opposed to having special rules for food units, projects, wonders, and whether or not things are actually queued).

But I don't really know... maybe I should just use the same old tried-and-tested multiple production option that is in the PIG mod.

---

All that aside, regarding the current version of K-Mod (v1.00), I forgot to mention a potentially important side effect of my changes to the AI's calculations for "unit cost percentage". The side effect is that the AI may sometimes be significantly more likely to declare war than previously. The AI's probability of planning war depends on this unit percent thing, and I've noticed that at some points in the game the new percent is much higher than the old... so there might be more wars than before. I'm not sure if it's going to be _too many_ or not, I'm just mentioning it in the hope that if the AI turns out to be noticeably more warlike I can get some feedback and maybe try to "fix" it.

[edit]
I've just spotted a bug in my new for the AI's colony decision making stuff. It makes the far more likely to split a colony than I intended. So... I'm going to release a minor update soon. (v1.00b), I'll just it a bit more time to see if any other problems show up first. The update will also reduce the war probability that I mentioned above, so that it is closer to the normal BtS probabilities.

 

[Linkman226]

Er, wouldn't that kinda suck for players who keep a tight fiscal policy/ are heading towards to debt? You know, (a) unit(s) spawning in their cities just because they have overflow? This would be especially hurtful for the AI; at least the human can opt not to use big production cities for units, but the AI will never realize.

 

[karadoc]

I don't think it would be a big problem for that. There would only be extra units if the player was using its big productivity city to build units; and if it turns out that the player got two units when they only wanted one, then they can just delete the other one. The only disadvantage would be that they'd miss out on that small amount of gold they would have gotten from the previous system, and they have to take the bother to delete their extra unit.

As for the AI, their fiscal policy is pretty loose. I'm sure they wouldn't mind getting two units instead of one from time to time (and they do know how to delete units if they are in financial trouble).

So - I take it that you're saying you'd prefer the 'normal' multiple production mod?

 

[Lenowill]

Regarding the usual mod for multiple production and the AI, is there any way to teach the AI to "alt-click" when it tries to build a unit (i.e., to place it on "build this indefinitely until otherwise ordered" status)? But somehow still let the AI re-evaluate what it wants to build each time this unit is made? I ask because I _think_ that would give the AI the standard benefits of Multiple Production (at least regarding units) if it could get its hammers high enough.

Another alternative is to somehow teach it to build units in one-turn-able clusters via queueing, if it's capable of doing so.

Like you said, Missiles are terrible investments in most cases without Multiple Production available. That's part of why I want it in. I also liked being able to finish multiple buildings in one turn if I happened to chop a ton of forests in the same turn (though that's a lesser issue by far).

If I had to pick, I'd probably prefer the normal multiple production mod--if only because that works on low-cost buildings in extreme production-hurrying situations as well--but I would be 100% willing to give your idea a try and see how I liked it too. I've never seen anything quite like it and it's possible that it could evolve into something even better if tested.

At any rate, thank you for the new version! Looking forward to giving it a whirl soon.

EDITED-IN: I just reread your post more carefully, Karadoc. I now realize you mean to keep the way it works for non-units the same as it is now. I would be perfectly fine with that, then. I vote that you give your system a whirl if it'll help the AI do better (and it sounds like it will).

 

[Linkman226]

I prefer the approach of automatically having the AI queue whatever it would have built next.

 

[JosEPh_II]

Good to see the Mod at version 1.00b

JosEPh