[BTS] K-Mod: Far Beyond the Sword

[Merce_ar]

Karadoc, I love your mod, the improvements you've made are just fantastic. One thing that I find to be superb, is the fact that you didn't touch any aesthetic, only core game mechanics.

Thus, I have a question, is the mod compatible with varietas delectat or something that changes unit graphics according to what nation you're playing with? I find seeing Egyptian-style workers while using my German empire awkward.

EDIT: What do you mean by "improving the AI"? I mean, I consider AI can be improved in 2 ways:

The "calculator/analiytical" one where it plans everything in a mathematical/systematic way (EG: Look at those higly improved STARCRAFT AI's, the win not because they are more "strategic" but because they are able to multitask more than a human and to react faster) besides not making a single mistake (IE: It WILL do something to improve with each turn, will calculate every possibility for a single unit move, etc).

The "humanly" way, where it is open to mistakes, it doesn't "calculate" everything. Can fall to ambushes made by the player, etc etc.

I mean, there is no point, for me, in improving the AI as shown in the first way. It would be impossible, it wouldn't be

EDIT2:

It's also worth noting that the AI in K-Mod actually cheats /less/ than the standard AI; not more.

Yes, this kind of stuff is what I was looking for. Is possible for the AI to not cheat in any way?

[sjodster]

Originally Posted by MisterBenn

To me that there is a scale: at one end of the scale the AI will "roleplay" its flavour ruthlessly, even if it should lead to stagnation and terminate their chances of success. This is perhaps leads to a more believable world simulation but can lead to the "Peace Island" scenario that Charles555nc mentioned.

At the other end of the scale the AI could perhaps behave just like in a competitive multiplayer game, purely looking for the best oppotunity to expand and succeed, and while using racial bonuses where possible could happily overlook their racial flavour where it constrains their chances. If you are on an island of 4 players and all are Buddhist, if stagnation is imminent you might look for the option to expand aggressively even if you spiritual, pacifistic or whatever.

As I said, from what I've seen people's expectations often lie in different places on this scale. Rigidly roleplaying AI at its worst leads to predictable and exploitable opponents and ruthless opponents at their worst lead to a lack of opponent flavour and variety - the difficulty is finding that perfect balance. In Distant Worlds they have a game option for the overall aggression level in the galaxy which roughly corresponds which gives the opportunity to tune to a preference. I would presume that in Civ between the skill levels and the Aggressive AI flag there is similar means to articulate a player preference.

In Realism: Invictus I added on an "AI Plays to Win" game option for exactly this purpose. Instead of using the original BetterAI game defines, I modded the AI_calculateDominationVictoryStage and similar calls to use the new game option like so:

	// MOD - START - AI Plays To Win
	/*
	if( GC.getDefineINT("BBAI_VICTORY_STRATEGY_DOMINATION") <= 0 )
	{
		return 0;
	}
	*/
	if (!GC.getGameINLINE().isOption(GAMEOPTION_AI_PLAYS_TO_WIN))
	{
		return 0;
	}
	// MOD - END - AI Plays To Win

I agree that it would be even more ideal to have a complete scale ranging from total role-playing to total competition. To do that properly the game setup screen would have to be modified though and I'm not sure if that screen is moddable.

Originally Posted by karadoc

There are indeed a huge amount of changes. I'm sorry again about the lack of marker-comment around changes. I was doing that for awhile, but it's just such a drag. It ends up taking a significant amount of time; and I still maintain that it's easier to what's change and why by looking at the version control system. (ie. either online with github, or with git itself.)
What tends to happen is that I'll change one line, and put a comment on it, and then change a different line, and put a comment on it, and then change something in-between the two lines; and then remove the two commends and replace them with a marker at the start and at the end, saying, 'changed a few lines to fix blah'; and then later I might add a new parameter to the function which affects a couple of things; and change the comment to say 'changed a few lines in fix blah; and replaced bDumbParameter with iMoreDynamicParameterThatMakesSense' -- and then I'll realize that bDumbParameter wasn't so dumb after all, and change back, and so change the comment back.. and then I might decide that the stuff I've just written would be better if it was in its own function, so I cut it out of there, and put it in a new function, and write comments saying 'this code use to be in such-and-such-function, but it was different; I've changed blah'; and another comment where I took it saying 'I've moved some code to another function; and also, it's different now because I fixed blah'....

and so it goes on. It's like every change gets doubled, because it requires a comment as well

I sympathize greatly, and as someone that is merging K-Mod with another large mod I'm still trying to come up with my own opinion about this. I think the main reason the markings are useful is to distinguish the K-Mod edits from those of other mods. As I have been checking over my merge there have been times I found the markings useful. Even so, I completely understand that maintaining those markings is an awful nuisance and I can't complain if you don't want to bother with them.

Originally Posted by karadoc

- and in the end I just don't think it's worth it because all of that change information goes into the commit log anyway.

It should be noted that when doing an initial merge the commit log is not very useful. If I am scrutinizing a particular change in a 50000 line file, how would I know which of 200 commits describes the change? I'd have to look through the whole history for that file to find the commit that applied the change in question. Doing that kind of research is time taking; I'll do it if the change is particularly mystifying but typically I won't bother.

That said, I do love that you put so much care into your commit descriptions and that they capture everything that happens. If we merge in future versions of K-Mod that change log will be solid gold. But I can't take time to data mine the commit logs when I'm busy merging 20,000 conflicts; it's much more useful for me to have in-code comments.

Originally Posted by karadoc

In simultaneous turns mode (for multiplayer games), there's a rule that prevents players from moving a unit right at the end of one turn, then immediately again at the start of the next turn. The rule is basically just that units which were recently moved in the previous turn are temporarily frozen at the start of the next turn; so that players at least have a few seconds to react before the unit is moveable again. -- The change in the latest version of K-Mod simply disables that rule for anyone who hasn't yet met a human player. The anti-double-moves rule only exists to give human players a chance to react to surprise attacks from other human players; and so I figure that if the players haven't even seen each other, then the rule has no purpose. The point of disabling the rule is so that the early-game can go a bit smoother; so that players don't have to wait for ages just to move their one and only unit one step each turn.

Thank you for changing this! It has always driven me bonkers in the early game. I play cooperative multiplayer with one human team against the AI, so the rule is completely unnecessary and annoying in the games I play.

[Charles555nc]

New Game 1.34

Me and 2 other civs on a continent, all christian.

*Began early military mass*

Death to peace island!!!

*Charge!!*

lol

Anyway,

Patch notes so long
Great changes Karadoc, gj sir.

[Charles555nc]

I was wondering if the natural plot selection when a city grows, could select grassland with a cottage (2 food and one commerce) rather than a sea square with a financial civ and lighthouse (2 food and 2 commerce). Its extra micro but not a big deal.

[karadoc]

Originally Posted by Merce_ar

Thus, I have a question, is the mod compatible with varietas delectat or something that changes unit graphics according to what nation you're playing with? I find seeing Egyptian-style workers while using my German empire awkward.

It is compatible in the sense that the mods can be merged... but it isn't as trivial as just dropping the files (like is done with the BM tileset). There are heaps of xml changes and so on. (Actually, such a merge has already been done; but it's hiding somewhere in the wings at the moment.)

Originally Posted by Merce_ar

EDIT: What do you mean by "improving the AI"? I mean, I consider AI can be improved in 2 ways:

The "calculator/analiytical" one where it plans everything in a mathematical/systematic way (EG: Look at those higly improved STARCRAFT AI's, the win not because they are more "strategic" but because they are able to multitask more than a human and to react faster) besides not making a single mistake (IE: It WILL do something to improve with each turn, will calculate every possibility for a single unit move, etc).

The "humanly" way, where it is open to mistakes, it doesn't "calculate" everything. Can fall to ambushes made by the player, etc etc.

I mean, there is no point, for me, in improving the AI as shown in the first way. It would be impossible, it wouldn't be

EDIT2:

Yes, this kind of stuff is what I was looking for. Is possible for the AI to not cheat in any way?

Well, the key thing to understand about A.I. (or even non-A. I.) is that every decision needs to be calculated somehow. The calculation can be based on randomness, or based on some heuristic approximations, or based on highly-accurate maths - but it has to be calculated somehow. Every decision must involve some kind of decision making process, and that process is essentially a calculation.

Spoiler:

I claim this true even for human intelligence, although most of the thinking happens behind-the-scenes, outside of consciousness... and so it's difficult to pinpoint exactly what's going on. The key to writing good AI for a game is to first try to identify how a human would do it... unfortunately, the full human-like calculation for most decisions in the game is either is too large to do on-the-fly, or is based on lots of memories of past games that the computer simply doesn't have access to...

Anyway, the point is that all AI is calculated and analytical - but at least it can include some calculations based on the 'personality' of each AI leader.

That said, the Civ4 AI certainly does not make its decisions by simulating what would happen in every possible move each turn. That would be an enormous calculation, because the number of possible moves is truly vast. The number of possible moves each turn in Civ4 is much much much bigger than it is in games like Chess - so that kind of AI just isn't feasible.

...

Anyway, the AI certainly can fall to ambushes. It doesn't see everything, it is barely capable of predicting anything let alone everything.

It would be possible to write the AI in such a way that it doesn't cheat at all; and I'm gradually moving the AI in that direction. But the reason I haven't just gone all the way with it is that I don't think the AI is yet smart enough to play effectively without some of the (minor) cheats that it uses. For example, if you sink an enemy ship with your frigate, and then just move it a few steps off the coast, the frigate might be out of site... A human player would think "that frigate only has a few movement points. It can't have gotten far. I'm going to move my boat into the fog to find it and kill it before it heals". But the AI doesn't think like that. If the damaged frigate is not visible it might as well just not be there. It doesn't remember losing its unit, and it doesn't remember seeing the enemy. It doesn't really remember anything much at all - mostly because it would be to computationally costly and/or difficult to write the AI which could remember stuff like that. -- So.. rather than just allow the human player to get away with hit-and-run attacks like that all the time, the AI cheats a little by simply 'knowing' whether or not something is in attack range, regardless of whether it can actually see it.

It doesn't do this much, but that's the kind of cheating that it uses.

--

Originally Posted by Charles555nc

I was wondering if the natural plot selection when a city grows, could select grassland with a cottage (2 food and one commerce) rather than a sea square with a financial civ and lighthouse (2 food and 2 commerce). Its extra micro but not a big deal.

I'm pretty sure you mean 'coast' rather than 'sea', and '3 commerce' rather than 2... but if that's the case, then you're right. The current AI gets it wrong, because it doesn't take into account that when the cottage grows it will get the financial bonus.

There are actually lots of little problems like that in the way the AI evaluates plots and improvements and such – particularly when upgradeable improvements (such as cottages) are involved... It would be possible to fix them all, but I'm reluctant to do it because I suspect it might be computationally expensive to calculate everything the 'right way', without approximations.

In any case, the problem you mentioned is now fixed. The AI now does take the financial bonus into account when considering the future upgrades of what it's working. (It still doesn't take that into account when choosing which improvements to build in the first place... but I figure that's probably not as important, and I don't feel like fixing it now. I'm hoping that I'll come up with a neater/faster solution sometime in the future.)

Also, I've found and fixed a bunch of other problems in the way the AI chooses which plots to work. I think it's going to be noticeably better in many cases. (Also, keep in mind that the AI uses essentially the same system for choosing what to work. So if the governor is choosing good plots, then the AI will be stronger. )

[Charles555nc]

Originally Posted by karadoc

Also, I've found and fixed a bunch of other problems in the way the AI chooses which plots to work. I think it's going to be noticeably better in many cases. (Also, keep in mind that the AI uses essentially the same system for choosing what to work. So if the governor is choosing good plots, then the AI will be stronger. )

Financially stronger? *epic cry* Nooooooooooooooo.

On another note, when my cities grow they often pick a specialist instead of working a plot, imo I only use specialists in particular cities and I wouldnt mind microing those cities. But I find I have to micro ALL my cities to make sure that some city with no great people bonuses (outside of philosophic civ trait) doesnt have a single specialist that will spawn a great person in 400 turns...I mean I would prefer a regular plains, one food, one hammer, rather than a hopeless lone specialist.

[Charles555nc]

Brighton keeps building a "citizen" specialist when it grows. I guess its for the one hammer...do you think thats good/bad/ok Karadoc? I forget what you said about it last time.

[teejing]

I have for the 1st time a small chance to maybe win a monarch game, but in the year 1888 Ghandi wins a cultural victory.

My problem is that india was a vasal state of the greeks who were the most powerful military nation.

Personally i would prefer if vasal states would have all victory conditions disabled while being a vasal state
or
the master of the vasal state should interfere himself to hinder the vasal state to win.


ps: For now i think i play without vasal states and hope that doesnt mess with other parts of the game / game balance

[Leoreth]

Speaking of vassal states, that's really a mechanic that needs to be revisited, especially the AI aspect.

I always play without them because it's just annoying to have your enemy capitulate to a powerful AI civ and plunge you into new wars. It just isn't fun to speculate every turn if I can conquer another city or have to accept their capitulation before anyone else does.

[satrapper]

i 2nd/3rd that! also, vassalage happens too lightly at times.

[ripple01]

Hi karadoc,

Could you add a tag on github so that we can easily download the 1.34 source code? The latest tag is for 1.33. Many thanks.


Also, for anyone interested, I have opened a thread in the SDK/Python subforum detailing a couple of issues I'm having with the K-Mod/RevDCM merge I'm working on. The quicker I can get these resolved, the quicker I can release a playable copy.

[sjodster]

First, just a really minor bugfix. In CvTeam::doesImprovementConnectBonus the FAssert checks look like this:

FAssert(eImprovement <= GC.getNumImprovementInfos());
FAssert(eBonus <= GC.getNumBonusInfos());

<= is incorrect, it should be <

FAssert(eImprovement < GC.getNumImprovementInfos());
FAssert(eBonus < GC.getNumBonusInfos());

I also notice that CvTeam::doesImprovementConnectBonus doesn't check whether the bonus has been revealed or not. getNonObsoleteBonusType doesn't check for that either. Is the assumption that the tech to reveal a bonus always comes before the tech to connect it?

On another note: I have a couple of performance improvements in Realism: Invictus that might be useful to K-Mod:

• PlotGroup Bonus Efficiency
• PlotGroup City Cache
• Living Team Member Cache
• Unit Upgrade Cache (would be improved to handle some edge cases before merging)
• Building Activation

At some point I'd like to add a living player cache to CvGame as well, just to cut down on the bazillion loops through all players checking for aliveness. We have MAX_PLAYERS of 56 in our game core so those loops start to pile up.

Anyway, do you have an interest in having some of these improvements merged in at some point?

-Josh

[Lenowill]

How does the "no double moves" change affect a game in which there are only two human players in the game (versus a bunch of AIs) and the humans are on the same team together?

It would be rather cool if we could get it setup to where we could go the whole game without having to deal with that mechanic if all the humans are on the same team.

[karadoc]

Originally Posted by ripple01

Hi karadoc,

Could you add a tag on github so that we can easily download the 1.34 source code? The latest tag is for 1.33. Many thanks.

You're right, I forgot to push the new tag. But in any case, the most recent commit on github is version 1.34. You can confirm this by checking the commit message. It says "This is version 1.34." Every version I upload on this site has a commit message like that, so if the tag is missing, then that's a good thing to look for.

(I'll probably just push the tag there when I upload the next version, which I expect will be soon.)

Originally Posted by sjodster

First, just a really minor bugfix. In CvTeam::doesImprovementConnectBonus the FAssert checks look like this:

FAssert(eImprovement <= GC.getNumImprovementInfos());
FAssert(eBonus <= GC.getNumBonusInfos());

<= is incorrect, it should be <

That's true. The asserts are wrong. Thanks for pointing it out. (Non-modders be reassured though, this has no effect on the mod whatsoever. FAssert stuff is only used when debugging.)

Originally Posted by sjodster

I also notice that CvTeam::doesImprovementConnectBonus doesn't check whether the bonus has been revealed or not. getNonObsoleteBonusType doesn't check for that either. Is the assumption that the tech to reveal a bonus always comes before the tech to connect it?

getBonusType checks whether the bonus is revealed; and getNonObsoleteBonusType uses that function before checking whether the bonus is obsolete. So, the revealedness does get checked.

As for doesImprovementConnectBonus, I was in two minds about whether or not it should check that or not; and I decided just to have it not check it, mostly just so that it's a slightly shorter computation... I figure that it is usually used in conjunction with getNonObsoleteBonusType when checking which improvement to build or what to pillage and so on; and that it may be helpful to not check whether the bonus is revealed if the player is trying to evaluate a new type of improvement or something like that.

Originally Posted by sjodster

On another note: I have a couple of performance improvements in Realism: Invictus that might be useful to K-Mod:

• PlotGroup Bonus Efficiency
• PlotGroup City Cache
• Living Team Member Cache
• Unit Upgrade Cache (would be improved to handle some edge cases before merging)
• Building Activation

At some point I'd like to add a living player cache to CvGame as well, just to cut down on the bazillion loops through all players checking for aliveness. We have MAX_PLAYERS of 56 in our game core so those loops start to pile up.

Anyway, do you have an interest in having some of these improvements merged in at some point?

-Josh

I do have some interest... In general, performance improvements are good; obviously. The downsides are that they may introduce bugs or maintenance problems, or just be time consuming to implement.

The main thing that puts me off other people's performance improvements is that I had a nightmarish time with the attitude cache from the "CAR" mod which I inherited from the original BBAI code when I first started this mod. That code was trash. It was written in a way that created horrible maintenance problems and it had heaps of subtle OOS bugs. I spent many hours of debugging due to that code; and I recently ended up just writing it completely to be rid of the problems once and for all.

I don't want a repeat of that situation... and so I'll have to read the changes myself carefully before merging them, to make sure they're done the right way; but that's kind of boring and time consuming and blah blah blah.

The bottom line is that I'm interested, but only when there are clear gains and the changes are easy to understand.

--

That said, I know that the upgrade cache is probably worthwhile, and wouldn't be surprised if your plot group stuff was a significant improvement as well. And I'm pretty sure that RI has decent quality-control on these things...

I'm not really sure what you mean by Living Team Member Cache, or Building Activation. Checking whether or not a player is alive is essentially instant; and counting the number of living team members in a team is pretty fast too, and I don't think it happens terribly often anyway. But by the sounds of things, what you're talking about has something to do with using something smaller than MAX_PLAYERS when doing most of the loops in the game.

I know there are a lot of loops in the game which go through all of MAX_PLAYERS, when all they really want to do is go through all of the living players. -- So I suppose you're talking about having a kind of dynamic MAX_PLAYERS thing? I would be interested in doing something like that.

There are a few different way to approach it though.

One way would just be change all of the loops from MAX_CIV_PLAYERS, to some new number, say iNumAlivePlayersEver; or something like that. (Loops with MAX_PLAYERS, as opposed to MAX_CIV_PLAYERS, would need special treatment if they were to be shortened as well, because of the barbarian player always being the last player.)

But maybe you'd want to go a step further than simply changing the size of the loops. There are lots and lots of bits of information in the game which are storied for all players regardless of how many players are actually alive. So if MAX_PLAYERS is 52 rather than just 17, then the memory usage of the game will be significantly higher... It might be nice if MAX_PLAYERS itself could be dynamically set at the start of the game, perhaps based on the map size; and then most of the memory wouldn't have to be allocated in the first place. -- Awhile back, I started implementing something a bit like that. ie. changing all of the allocations to be based on a variable MAX_PLAYERS rather than a fixed number. Statically allocated arrays became vectors and so on. I reckon it could probably be made to work, but it's a significant undertaking...

Is that the kind of thing you're talking about?

[karadoc]

Originally Posted by Lenowill

How does the "no double moves" change affect a game in which there are only two human players in the game (versus a bunch of AIs) and the humans are on the same team together?

It would be rather cool if we could get it setup to where we could go the whole game without having to deal with that mechanic if all the humans are on the same team.

The double-move-delay (with the new rules) is only applied if the team has met another other human team. If you and your friend are on the same team (as in, in a permanent alliance) then the double-move-delay will never be applied.

(If anyone notices something which contradicts what I've described, please let me know.)

[Lenowill]

Sweeeeeeet.

I will have to test that sometime soon if I can.

[ripple01]

I'd just like to announce to K-Mod players that the first public beta of my merge between K-Mod and RevolutionDCM is now available.

Thread link: http://forums.civfanatics.com/showthread.php?t=470980

[Merri]

Vassalage does indeed seem very odd... in my current game I'm together with Shaka and Justinian on our own continent, none of us was doing too badly and had roughly equal points, but immediately after Shaka hit vassalage I noticed Justinian became his vassal. They did have the same religion and Shaka did have a mighty army, but it still doesn't seem like a good decision for Justinian... unless he tries to win a cultural victory with a culture that is far behind mine.

[noto2]

This is a really convoluted way to deal with the imbalance of upgrading. One should just reduce the upgrade cost, slightly. The way the game works now, if you have a well developed production city, it's usually faster to just disband an old unit and build a new one, rather than set the city to build wealth and save gold to upgrade the unit. This is terribly imbalanced. The cost of upgrading should be cheaper than building a new unit from scratch, therefore the upgrade cost of units should be reduced. That's all that is needed to improve the game.

-A post in another thread. I think unit upgrade costs should be reduced to improve game balance. What say you? Yay? Nay?

[Leoreth]

Well, upgrading a unit preserves its promotions.