K-Mod: Far Beyond the Sword

@noto2: yes, you have a point. But note that tank has a railway, while chariot has only slow road in the best case to travel on. So the difference is actually in roads. It would be interesting to implement such thing as sea routes, which would be faster to travel on (not on enemy territory though). Then there would be similar 'commando' promotion for naval units (difficult to get to of course). But unfortunately this is probably really difficult to implement in Civ4 :(
Simply leveling naval units' speed would mean the same speed in ancient and modern eras. And it's not realistic too.

One amendment that can be easily done (this isn't the real solution, but still interesting): pillaging is allowed only for ships with full movement, so that they have to stop at a resource tile in one turn and pillage it in the next one. This can be combined with the same fix for bombardment and removing transported units' movement points (as I described in my first post here).
After these fixes only
1) unexpected attack of naval unit outside of city
and
2) fast movement itself
would remain valid out of the fast movement problem, which you described.
 
Roads and rails don't apply to enemy territory, so I don't know why you would bring that up. Imagine if they did, though... if you had rails connected to your neighbours, then in one turn, they could declare war on you and raze 1/2 of your empire... in one turn. This is what happens at sea.
 
I think noto2 is correct about why naval warfare is difficult to balance. The high movement speeds and strong first-attacker advantage give rise to fairly messy and somewhat tedious tactics. (Only tedious if you are seriously focused on using the best possible tactics - which would involve a lot of back-and-forward movement for scouting and so on.)

Slowing the ships down might reduce the problem, but the lack of terrain features and things like that make naval combat pretty bland anyway. Slower ships would be less useful in general; and I think it would be somewhat tedious in a different way.

If ships were slower, overseas invasions would be more difficult - because of the additional time the enemy would have to build new troops, position existing troops, and research new technologies; and using ships to move units just to a different part of the same continent would probably no longer be viable. Air-lifting would be relatively more powerful. ...

I don't think sea pillaging is a really a problem as it is now. Pillaging a few fishing boats in a single turn is pretty insignificant compared to killing an enemy stack or capturing a city.

As for super-fast land wars - it can happen. If you use bombers/fighters combined with helicopters and paratroopers, it's possible capture multiple cities in a single turn without having to march through enemy territory. But generally that only happens if you're significantly more powerful than your enemy. Also, it takes a fair bit of organisation and planning to execute it effectively. In some end-game situations it is even possible to get a large army of land units with the Commando promotion. It's probably a good thing that there are some powerful tactics in the game like that.

I'm not really thinking about making any changes right now. It's crazy hot where I am, and I don't really want to produce more heat by thinking.

By the way though, in K-Mod it's possible to put air units on 'auto explore', which basically means auto recon missions. I find that feature very useful for scouting the oceans around my territory. I like to have a handful of airships stationed around the coast set to auto explore. (And I don't 'upgrade' them to fighters, because fighters can't see submarines.) Using that feature isn't quite as efficient as doing it manually, but it's a pretty good way to dramatically reduce the burden of having to scout the ocean all the time.


The game would be pretty boring if the biggest army always won wars, and the biggest civ could always make the biggest army and so on. So I think it's good that there are some tactics which can use a relatively small army to inflict great damage. Just so long as those tactics are too boring to execute, and not too boring or too difficult to try to counter.

We're talking a lot about naval warfare, but I think the other elephant is nukes. Nukes are super effective pretty much all the time; and they're easy to use, and very difficult to counter. The real-life reasons for not using nukes don't really apply to the civ world. Because in real life, there are no victory conditions, and in civ there is no value on 'life' other than for building towards 'victory'. The rules about nukes in civ4 aren't really about addressing balance so much as they're about giving players the option of ignoring that part of the game... The kinds of problems we're talking about with naval warfare can be mostly ignored in a similar sense. The AI doesn't really know how to execute focused and efficient naval assaults; and so if the human player chooses not to do it either, then the problem is kind of brushed under the carpet...
 
@Karadoc - I agree about nukes being the other side to this coin. Nukes present a big problem in terms of making the game both realistic and fun. To make the game realistic, ICBMs should wipe out a city in one hit, or cost 10 times less than they currently do... but that wouldn't be fun at all, because the first civ to nukes would then always win. To make the game fun, nukes must be not even close to as powerful as they are in real life.

I wish there was a custom game option to disable nukes, like there is to disable, say, espionage. I find I often use nukes as a crutch come late game, which is unfortunate, because some of the most fun I've had in civ is with late game conventional wars.
 
noto2 said:
Roads and rails don't apply to enemy territory, so I don't know why you would bring that up. Imagine if they did, though... if you had rails connected to your neighbours, then in one turn, they could declare war on you and raze 1/2 of your empire... in one turn. This is what happens at sea.
Click to expand...
What I meant is: tanks usually move much faster than chariots on the friendly or neutral territory due to railroads. It would be interesting to make the same on water tiles. If land combat is performed on neutral territory, it's essentially the same as naval combat (assuming that there are plenty of railroads). Unfortunately seeing as naval cultural borders are very thin, introducing 'roads' or just slowing down on enemy territory on water tiles won't change much.
With current state of naval combat, fast movement on all water tiles is unfortunate due to many possibilities of fleet: declaring war, bombardment, capturing cities, pillaging on water tiles – all in the same turn! If these possibilities were reduced, the problem would shrink. Then it would be just identical to land battle on neutral territory – not really so bad :)
Scouting adjoining territory each turn is not a good solution, because in case if you want to stop enemy ships before they reach your cities and start land invasion, you have to declare war pre-emptively and this is not usually desired due to diplomatic implications. Also scouting wouldn't help the AI to defend from another AI's or human's naval invasion at all, because it just can't use scouting properly.

As for nukes: at least severe diplomatic penalty exists, also construction of nukes can be prohibited in UNO. In case of sneaky naval warfare there is no diplomatic penalty at all and it can't be prohibited. This means that naval combat flaws can be exploited without any drawbacks at all! So I believe that reducing naval problem is more important than 'fixing' nukes.

Although I admit that it would be good to have a start option to disable nukes entirely. Another possibility is making Treaty on the Non-Proliferation of Nuclear Weapons passed by default. Then this can be put to vote in UN by Secretary-General and if there are not enough votes to prohibit this treaty explicitly, nukes would become enabled. This way nukes would be much less common in the average Civ game.
 
Although, I will say, in the game I was talking about I actually lost, because the AI won the nuclear war. I had SDI and he did not, but he just had more nukes than I did, and so I lost. Nukes in Civ are somewhat similar to real life in that if you actually get into a nuclear exchange with another civ you're going to be knocked back in the middle ages. A nuclear exchange won't work if the game is a three way race, because the two who nuke each other will do too much damage to each other.

Like I said, I had SDI, I even had bomb shelters in every city, and tons of workers for scrubbing, and I made the first strike and took out some of his nukes before he got to launch them, but still, his retaliation did too much damage. Half my tiles were fallout and I lost about 1/4-1/3 of buildings in all my cities.
 
I removed paradrop ai from the paratrooper xml and put in ai reserve, and lowered the ai asset rating and the ai now puts more focus on better units like marines/tanks, keeps slightly larger stacks imo.
 
Hello Karadoc,

Some months ago I posted here an issue with the culture layer on the global view. Changes introduced in your mod made the culture layer too heterogeneous and almost unusable. Well, looking into the code I found a workaround to fix it:

In the CvPlayer.cpp file there's an "if" that starts on line 23193, this one:
Code: 
if (GET_PLAYER((PlayerTypes)iPlayer).isAlive())
{
	int iCurCultureAmount = pLoopPlot->getCulture((PlayerTypes)iPlayer);
	if (iCurCultureAmount != 0)
	{
		iNumNonzeroOwners ++;
		plot_owners.push_back(std::pair<int,int>(iCurCultureAmount, iPlayer));
	}
}

It checks how many culture each player has on a plot and if it is different to 0 (in other words, superior to 0) then that player is counted as a "plot owner". What I have made is to calculate the percentage of culture the player has on that plot based on the total culture of the plot in question, then only if the the percentage is equal or superior to a specified number the player is counted as "plot_owner". Here it is:
Code: 
if (GET_PLAYER((PlayerTypes)iPlayer).isAlive())
{
	int iTotalCulture = pLoopPlot->countTotalCulture();
	int iCurCultureAmount = pLoopPlot->getCulture((PlayerTypes)iPlayer);
	if (iTotalCulture != 0 && iCurCultureAmount != 0)
	{
		if (iCurCultureAmount * 100 / iTotalCulture >= 10)
		{
			iNumNonzeroOwners ++;
			plot_owners.push_back(std::pair<int,int>(iCurCultureAmount, iPlayer));
		}
	}
}

Here the percentage is 10, but it works with any number. I have already tested it and works flawlessly.
 
I have a few questions:


1. Is this exploit http://www.civfanatics.com/civ4/strategy/subsidies.php mitigated in K-mod by AI reconsidering GPT deals when lacking funds?

2. Current capitulation mehanic seems unfair, one player gets a vassal and others get nothing if the capitulating player was in multiple wars. Can this be exploited to stop AI from expanding by attacking and vassalizing his nearly defeated enemies?

3. Why does the culture of defeated civilizations disappear? Would there be some problems if it didn't?

4. It seems that when city flips to you there is no view city option before deciding whether to keep it or disband it?

5. What is the limit on the number of colonies (per player and globally)?

6. If culture victory can be achieved by team why then in victory screen aren't listed cities from teams but only from single players? (both for controlling player and the best rival)
 
Some weird behaviors by the AI in my most recent games:

1) City defenders leave city
I've repeatedly seen the AI leave its city unprotected in order to kill targets of opportunity. I've even seen units decide to wander around when no target of opportunity is around.

2) City Placement
AI values land-grab expansion a little too heavily during early game, to the extent of ignoring game-changing city sites in its backfill. On the plus side, the city sites that it is choosing are usually very good. (I only raze about 20% of the time, now, usually for economic reasons.)

3) Defensive Backfill/fog-busting
Similarly, AI will sometimes let barbs continue to spawn and harass, when its borders could be closed with another city or two, or a handful of scouts. Instead, it maintains standing army instead of pushing culture to mountains/sea.

4) Suicidally Abandoning Vassalage
In a recent game, all my vassals decided to leave my empire within three turns, despite the power graph showing I dwarfed them. They were all gone within ten turns, devoured by me or one of the other domination-driven AIs. On the other hand, the vassals were all so far behind that they may have given up and decided to go out with a bang. At least it made things a little more interesting. Seeing them join the runaway AI would have been better, though

5) AI Doesn't Leverage Vassals' Research
Self-explanatory, but could be deliberate. This might only apply to voluntary vassals, in which case AI would be wise not to trust vassals. Otherwise, getting several vassals to research in parallel and swap might be too complex, but at least sharing techs so they all advance at the rate of the best researchers might make more sense.

6) More city defenders may be needed
It still seems like raging barbs are too much for the AI, a little too often. Or raging player.

All in all, I have to compliment you; The AI is now good enough to be worth criticizing. Gameplay is so much faster it's creepy. I still wish there were diplomacy options to taunt an AI that left my empire, and is now almost wiped out.
 
While merging 1.42 with the Realism:Invictus mod I noticed a bug in CvPlayerAI::AI_baseBonusVal (circa line 10237):

Code: 
for (int iJ = 0; iJ < GC.getNUM_UNIT_PREREQ_OR_BONUSES(); iJ++)
{
	if (kLoopUnit.getPrereqOrBonuses(iJ) != NO_BONUS)
	{
		iOrBonuses++;
		//iOrBonusesWeHave += ([COLOR="Red"]iJ != eBonus[/COLOR] && getNumAvailableBonuses((BonusTypes)kLoopUnit.getPrereqOrBonuses(iJ))) ? 1 : 0;
		// @*#!  It occurs to me that using state-dependant stuff such as NumAvailableBonuses here could result in OOS errors.
		// This is because the code here can be trigged by local UI events, and then the value could be cached...
		// It's very frustrating - because including the effect from iOrBonusesWeHave was going to be a big improvment.
		// The only way I can think of working around this is to add a 'bConstCache' argument to this function...
		bIsOrBonus = bIsOrBonus ||[COLOR="Red"] iJ == eBonus[/COLOR];
	}
}

The last line of the loop should use getPrereqOrBonuses to look up the proper bonus type:

Code: 
bIsOrBonus = bIsOrBonus ||[COLOR="Green"] kLoopUnit.getPrereqOrBonuses(iJ) == eBonus[/COLOR];

By the way, in regard to your note about the use of getNumAvailableBonuses: I believe that function is safe to call here. PlotGroup bonus counts are cached at time of modification, not at time of query. Calling getNumAvailableBonuses shouldn't perturb the state and thus it shouldn't lead to an OOS error. Even so, I greatly appreciate your caution about these sorts of things.

-Josh
 
Thanks Josh, you're right about that bug. It's time like this that make one wish for stronger rules about types (and that's part of why C++ now has 'enum class'). I probably should have picked up that mistaken in my testing...

As for the OOS thing, I still think it would be a problem if CvPlayerAI::AI_baseBonusVal used any game state information which could change during the period of a turn.

The root of the problem is that AI_baseBonusVal caches its results when it is called, and then uses those cached results if it is called again before the next turn. This is a problem because AI_baseBonusVal can be call for use in AI functions and game mechanics, but also for UI related things such as negotiating trade deals and recommending tech research.

The only time the cache is cleared is at the start of a new turn, or when the player does something dramatic such as making a permanent alliance.

So, what can happen to cause an OOS situation is that the function might get called for one player when the game recommends to them what tech they should research, the value gets cached, and then during that same turn if a tech trade is made or a city is captured or something, the results of the true (uncached) bonus value might change in such a way that it affects the AI's decision about something. For example the player might automate a worker sometime near the end of the turn, and that automated worker's AI might decide to improve one bonus based on the cached AI_baseBonusVal, but improve some other different bonus based on the uncached value on some other player's computer.

Now that I think about it, AI_baseBonusVal already does use a couple of things that can change during a turn; current player techs and city placements are two things that come to mind. That could well be the source of some of the few (very rare) remaining OOS bugs. Maybe I should just calculate the value of all bonuses for all players at the start of every turn to fix that problem, and hence remove the problem I was complaining about the comments at the same time.

Manujuanel said:
Hello Karadoc,

Some months ago I posted here an issue with the culture layer on the global view. Changes introduced in your mod made the culture layer too heterogeneous and almost unusable. Well, looking into the code I found a workaround to fix it:
Click to expand...
Thanks for that, I did see your first post but I forgot to reply. I will use someone like you suggested.

Back when I first implemented the culture changes there was a similar problem with the mouse-over text for culture on plots. I changed it so that only cultures with >= 5% influence would be displayed in the mouse-over text so that it wasn't as cluttered.

I hadn't noticed the problem you mentioned because I never zoom out that far. Now I guess the only question is whether I should use the same 5% that I use for the mouse-over text, or a stricter 10% (or even higher) because of the different nature of the information... I'm thinking maybe even 25%.


I'm currently very busy, so I'm not currently making much progress on larger changes. But I guess I should just upload a minor update to fix those bugs.
 
I dont like how you have to chop absolute everything to build enough chariots to capture a protective leader with 60% culture and hill. Charmalagne had this as hes capital at 1360BC with 5 archers.

After making 2 cities the max chariots I could get is 16 with decent cities to. If I chopped everything I would get several more but even then the odds are 30% after 16 chariots. There is just no end to how much units you need for this in ancient era.
 
You seem to be saying that you think it should be easier to eliminate players in the very early phases of the game. I don't share that view.

In order for the later phases of the game to have any relevance to the victory conditions whatsoever, it's important that the early phases of the game don't have easy decisive victories. The example you gave refers to one of the best possible defensive situations possible at that phase of the game. If that kind of defensive strategy still wasn't enough to beat a chariot rush, I think we'd be facing a serious balance problem.
 
robyextreme said:
I dont like how you have to chop absolute everything to build enough chariots to capture a protective leader with 60% culture and hill. Charmalagne had this as hes capital at 1360BC with 5 archers.
Click to expand...

Protective is a pretty weak trait but this is one area it is useful, don't think that should change - early wars should have a cost!

Sent from my Android phone
 
karadoc said:
Thanks Josh, you're right about that bug. It's time like this that make one wish for stronger rules about types (and that's part of why C++ now has 'enum class'). I probably should have picked up that mistaken in my testing...
Click to expand...
Oh it surely happens to all of us from time to time, and I completely agree with you about the typing rules :)

karadoc said:
As for the OOS thing, I still think it would be a problem if CvPlayerAI::AI_baseBonusVal used any game state information which could change during the period of a turn.

The root of the problem is that AI_baseBonusVal caches its results when it is called, and then uses those cached results if it is called again before the next turn. This is a problem because AI_baseBonusVal can be call for use in AI functions and game mechanics, but also for UI related things such as negotiating trade deals and recommending tech research.

The only time the cache is cleared is at the start of a new turn, or when the player does something dramatic such as making a permanent alliance.

So, what can happen to cause an OOS situation is that the function might get called for one player when the game recommends to them what tech they should research, the value gets cached, and then during that same turn if a tech trade is made or a city is captured or something, the results of the true (uncached) bonus value might change in such a way that it affects the AI's decision about something. For example the player might automate a worker sometime near the end of the turn, and that automated worker's AI might decide to improve one bonus based on the cached AI_baseBonusVal, but improve some other different bonus based on the uncached value on some other player's computer.

Now that I think about it, AI_baseBonusVal already does use a couple of things that can change during a turn; current player techs and city placements are two things that come to mind. That could well be the source of some of the few (very rare) remaining OOS bugs. Maybe I should just calculate the value of all bonuses for all players at the start of every turn to fix that problem, and hence remove the problem I was complaining about the comments at the same time.
Click to expand...

Yes I see what you mean now: it's not getNumAvailableBonuses that you're concerned about being mutable, but AI_baseBonusVal itself. It looks ripe for OOS errors doesn't it? I've hit a few OOS errors in the later eras in our mod; I'm not certain of the source yet but there's a possibility its related to this.

And you're right, fixing the system as its currently designed presents a difficult challenge.

I love the idea of keeping these values cached and keeping the cache fresh enough to always be accurate, but to do that properly the cache would have to be dirtied way, way more frequently. There are so many factors that go into the output that it could be very difficult to find them all. And then any time you add a new factor you have to remember to dirty the cache accordingly.

Going with the const-cache approach could work, but with so many other values being derived from AI_baseBonusVal it could be very difficult to track down all of the possible downstream UI calls and to refactor everything in between.

Going with a naive cache that's updated once-per-turn has a certain appeal doesn't it?

-Josh
 
You must log in or register to reply here.

Similar threads

J
Loaded mod - But my game is still vanilla BTS?
Replies
0
Views
42
jerminor
J
C
Modmod: K-Mod plus AdvCiv's UI enhancements
Replies
1
Views
840
f1rpo
f1rpo
B
Bandit's plot tooltip [Early portotype]
Replies
0
Views
32
bandit_heeler
B
B
Beyond the Sword 3.19 - How to get it?
Replies
13
Views
566
Rodnok
R
bmaupin
Reload mod changes without exiting the game
Replies
2
Views
429
Ryan F. Mercer
Ryan F. Mercer
Back
Top Bottom