Unofficial Patch 0.21 Released

[r_rolo1]

If we want to pull the realism card .....

Recons are almost always done at very high altitude ( to avoid AA fire and minimize detection ) in RL. So, if we go RL on this recon should give the same visibility regardless of what tile we choose to recon , and that should be the max range that we have now in game . But if we go RL, we should have recon specialized aircrafts as well.....

Well, talking more seriously, IMHO this falls in the "designer choice" cathegory...

 

[Roland Johansen]

I really hate the "realism" arguments, because it is first and foremost a game, not a simulator. In any case, the air strike missions (and maybe bombing missions?) give free recon, so the code is likely the same whether you're doing a recon or an air strike. i.e., If a plane is flying close to the ground to avoid detection during an air strike, the game is also assuming it's flying close to the ground during a recon mission.

You shouldn't start a realism discussion when you're not willing to finish it when it isn't going your way.

Gameplay reason for the Vanilla-Warlords model compared to the Conquest model
1) It makes the mission more useful. It's not a really powerful mission.
2) It makes the mission more intuitive to use for starting players.
3) There is no documented change for this mission so it is reasonable to assume that the change in the reconnaissance mission is just an unexpected side-effect of changes for the normal exploration code.

What are the gameplay arguments for the Conquest version of the air reconaissance mission? More tactical? Is clicking on a hill or mountain a tactical decission? Something else? I can't think of a good reason to use this weird air reconaissance viewing range.

If you have 2 ways of doing things and one of them makes more sense, you should come up with good arguments to do it the other way.

 

[TheOnlyDJCat]

It may be bad luck, but in my last mulitplayer team game we both upgraded to this patch and afterwards, whenever one of us popped a hut we found barbarians. This happened 6 times in a row.

I checked, if this is reproducible by creating a new game, but then the huts worked as intended.

I had no time to check with a new multi player game, if it was really bad luck. Has anybody seen this also - or popped something other than barbarians in a (mulitplayer) game, that was started with 0.19.1 patch and upgraded?

 

[Woody1]

If you have 2 ways of doing things and one of them makes more sense, you should come up with good arguments to do it the other way.

No.

If this was a mod, then fine, change the BtS behavior to something that "makes more sense [to you]". Frankly, I don't really care about the behavior one way or the other. They're both fine, as far as I'm concerned.

But if the intent of the unofficial patch is to only fix things that are clearly broken, then you've so far failed to prove this behavior is broken. You've simply stated you don't like it, and want it the other way.

Maybe you're right. But even if you are, it belongs in a separate mod, not the unofficial patch.

If someone from Firaxis says that it was indeed broken in BtS, then it should be fixed. Or, if you can find somewhere in the code that is clearly a mistake, then it should be fixed. Otherwise, leave it alone, because it may very well be intended behavior.

There's lots of things I don't like about the default behaviour in the game. (Such as global warming.) I certainly don't expect the unofficial patch to change them. I mod those things myself.

 

[Roland Johansen]

No.

If this was a mod, then fine, change the BtS behavior to something that "makes more sense [to you]". Frankly, I don't really care about the behavior one way or the other. They're both fine, as far as I'm concerned.

But if the intent of the unofficial patch is to only fix things that are clearly broken, then you've so far failed to prove this behavior is broken. You've simply stated you don't like it, and want it the other way.

Maybe you're right. But even if you are, it belongs in a separate mod, not the unofficial patch.

If someone from Firaxis says that it was indeed broken in BtS, then it should be fixed. Or, if you can find somewhere in the code that is clearly a mistake, then it should be fixed. Otherwise, leave it alone, because it may very well be intended behavior.

This can also be said of every bug that has been fixed in the unofficial patch. Only very few of these bugs can be proven to be bugs by official response from Firaxis (and I personally don't care that much about their official view as their official view of for instance the glance screen is 'remove it, it's ugly'). For the rest of them, it's just our common sense. You can't prove something to be a bug.

In this case, I think the buggy behaviour was introduced as a side-effect of the changes to sight for normal units. I think it's an unintended side-effect. There's no reason to expect the Firaxians to purposely change the reconnaissance mission to something that makes clearly less sense (from a realism point of view) and doesn't add something in some other way.

Can you tell me why the Firaxians would purposefully make that choice?

 

[Pep]

I have tested unseen sub and stealth destroyers with my modcomp:
http://forums.civfanatics.com/showthread.php?t=298512
and there're no side effects (the battleship of your example ends its move in the same tile as the stealth target).

What I haven't altered is the stardard behaviour of "go to" order when the enemy unit is not in the final plot of the path. The battleship would alter its path (without finishing its move) if an enemy destroyer is in a middle tile of the path.

In my mod, I provided another "go to" mode: "go to and sentry". Using this mode, the battleship stops its movement when an enemy unit is seen (one, two or more tiles away, depending on its visibility range).

I think both "go to" and "go to and sentry" mode should exist. Maybe you want a unit to go to a distant tile even if an enemy unit is nearby. What is true is that a unit in "go to" mode should stop if an enemy is blocking a choke point and path recalculation leads to a substantially longer path than the original one (I haven't altered this questionable behaviour on my mod).

Three screenshots to show "go to" mode behaviour when an enemy unit is blocking a choke point:

1. Civ4ScreenShot0000.JPG shows the calculated path from initial tile to destination.
2. Civ4ScreenShot0001.JPG shows the destroyer following the real path as it is recalculated to consider the enemy unit blocking thw choke point.
3. Civ4ScreenShot0002.JPG shows the destroyer arriving at the final point of the recalculated path. The destroyer now has no left movement points as opposed to the initial path.

My mod does not alter this behaviour. What it does is finish the movement if the enemy destroyer is on the final tile of the initial path.

My "go to and sentry" mode finish the movement when an enemy unit is spotted on any direction.

It can be seen in another two screenshots:
4. Civ4ScreenShot0003.JPG shows the new order "go to and sentry" icon and help.
5. Civ4ScreenShot0004.JPG shows the end point of the movement with this order.

My "go to and sentry" mode can be seen really as a sort of "hunt mode". In fact, I created it to give tons of experience to my privateers hunting enemy caravels. AI seems to have a predisposition to build many caravels when privateers are sacking its coast, but it doesn't make serious mass suicidal attacks (as it should do). So I hunt their caravels one by one moving my privateers in "go to and sentry" mode along the enemy's coast.

Maybe the correct aproach to normal "go to" mode should be my "go to and sentry" mode, but only on a directional way: a unit should stop its movement if an enemy unit is on the initial path, rather than recalculate a new path. Maybe a modification of SentryAlert function, changing a call to "canSeePlot(pPlot, pHeadUnit->getTeam(), iMaxRange - 1, NO_DIRECTION)" to "canSeePlot(pPlot, pHeadUnit->getTeam(), iMaxRange - 1, pHeadUnit->getFacingDirection(true))" could do the trick...

 

[Woody1]

This can also be said of every bug that has been fixed in the unofficial patch. Only very few of these bugs can be proven to be bugs by official response from Firaxis (and I personally don't care that much about their official view as their official view of for instance the glance screen is 'remove it, it's ugly'). For the rest of them, it's just our common sense. You can't prove something to be a bug.

I think you're grasping at straws. Very few of the changes in the unofficial patch are debatable as to whether or not they are bugs. Okay, Solver did put in some AI tweaks which were fixing deficiencies rather than bugs. I'm okay with most of those, but some of them crossed over into "mod territory" (and started breaking other stuff, unfortunately). The AI tweaks should probably be kept in the "Better AI" mod.

There are a ton of mods out there to change things people don't like. The nice thing about the unofficial patch is that it doesn't try to be just another mod. It's something that almost everyone can apply, and then use mods on top of it if they wish to tweak things.

It's what it doesn't try to do that makes the unofficial patch so valuable. K.I.S.S.

In this case, I think the buggy behaviour was introduced as a side-effect of the changes to sight for normal units. I think it's an unintended side-effect.

You may very well be right. I'm not saying you're wrong. I just want to you prove your assertions. So far, all you've given is opinion. Back it up with some evidence. Otherwise, you're simply asking for a mod to be included in the patch, not a bug fix.

You're saying, "I want fog of war for air units to be different than fog of war for land units." Maybe that's a good mod; I may even use it myself. I just don't think mods, good or bad, should be part of the unofficial patch.

Can you tell me why the Firaxians would purposefully make that choice?

You're missing the point. If you think it's a bug, then crack open the code and see if there's something obvious in the code that is wrong. Something like a conditional statement that always results in true (or false). A block of code that is impossible to reach. Something like that.

 

[Psyringe]

I don't think that discussions along the line of "It's a bug, prove that it isn't" / "No it's not not a bug, *you* prove that it is" can lead to a meaningful conclusion - there is no commonly shared, non-ambiguous definition of what constitutes a bug, and even if there were, we'd have so little data that neither position can be proven.

So I suggest we ditch the "realism" and "prove it!" debates and switch to a more practical approach instead: In which way does the recon change influence gameplay?

The first thing that comes to my mind is that recon does similar things as city visibility through espionage. City visibility is hard to achieve, you have to invest a lot of points for it. In contrast, monitoring large areas seems rather easy to achieve when the unobstructed recon behavior from vanilla is re-established(unless you're playing on really huge maps where plane range does matter). Hence I'm raising the question whether re-establishing the unobstructed recon behavior might devaluate espionage points spent to achieve city visibility.

(And yes, I know that from this question, an argument along the line of "See! There was a reason why the visibility was limited in BtS" might be constructed. I'd still prefer if we didn't do that though. Personally, I regard the explanation "unwanted side effect of other changes" just as convincing.)

 

[DanF5771]

If the intention really was to nerf air recon visibility vs. espionage enabled city visibility, then reducing the GlobalDefines xml value RECON_VISIBILITY_RANGE would have been the better/sensible way (plus make it conditional depending on "No Espionage" settings). The fact, that the code of CvUnitAI::AI_exploreAir does not take the elevation of the target plot into account while determining the pBestPlot makes me agree to the "unwanted side effect of other changes" opinion, thus I'd like this to get fixed.

 

[r_rolo1]

Well, speaking of "no espionage".....

No espionage option is full of loopholes and has all the aspect of having been rushed. If you want to give a look at it when you have ( lots of ) spare time...... To start , events that give espionage points are not blocked, and that gives unwanted side effects in terms of gameplay. Then we have the Spy GPP issue ( that acts like "blank GPP" ) and some other stuff.... like I said, when you have lots of time give it a look

 

[Woody1]

Definitely, the events that give espionage should be turned off if "no espionage" is selected. Yeah, that feature was definitely not well thought out. I like the concept of turning it off, but you pretty-much have to also turn off events as well.

Scotland Yard should also be turned off. I'm not too concerned about the spy GPP being wildcards, but the tech level that gives you a Great Spy (communism?) should give you something else instead.

 

[Roland Johansen]

I don't think that discussions along the line of "It's a bug, prove that it isn't" / "No it's not not a bug, *you* prove that it is" can lead to a meaningful conclusion - there is no commonly shared, non-ambiguous definition of what constitutes a bug, and even if there were, we'd have so little data that neither position can be proven.

Fully agree. Bhruic used to ask the forum goers in a poll-thread what they thought about an issue to help him decide whether something was a bug or not.

The fact, that the code of CvUnitAI::AI_exploreAir does not take the elevation of the target plot into account while determining the pBestPlot makes me agree to the "unwanted side effect of other changes" opinion, thus I'd like this to get fixed.

So I guess what you're saying here is that the AI isn't aware that some tiles show a lot more terrain when using the aerial reconnaissance mission... Not everyone speaks coder-language.

Well, speaking of "no espionage".....

No espionage option is full of loopholes and has all the aspect of having been rushed. If you want to give a look at it when you have ( lots of ) spare time...... To start , events that give espionage points are not blocked, and that gives unwanted side effects in terms of gameplay. Then we have the Spy GPP issue ( that acts like "blank GPP" ) and some other stuff.... like I said, when you have lots of time give it a look

Maybe we could try to categorise the loopholes and think of solutions? It's so easy to forget one of the issues.

Espionage events: remove (or dramatically change)

Free Spy GP from technology: remove

Espionage points from buildings: remove instead of turning them into culture. Turning them into culture made culture way to easy to get

Espionage related buildings: remove. The great person points which are espionage related mess up the game. The espionage points that they produce mess up the game. There's no use for these buildings in a no-espionage game

Scotland Yard: remove

Espionage related great person points from wonders: change to another source of great person points instead of blank great person points. Blank great person points are troublesome.

Forgetting something? Maybe reintroduce the vanilla/warlords espionage system in the no-espionage game mode. Oh boy, this sounds like a lot of work. It's clear why Firaxis rushed it.

By the way, I don't think a lot of players are actually playing the no-espionage version of the game...

 

[r_rolo1]

You can't remove all the espionage buildings... I can't see how you can play civ besides OCC without courthouses and jails also have a non-espionage function ( reduce WW ). Besides that I agree with all ( except that you forgot to remove the effects of civics in espionage output )

By the way, I don't think a lot of players are actually playing the no-espionage version of the game...

I wonder why....

I recently hosted a SG with exactly that variant: no espionage option. I might say that actually IMHO the AI plays better in no espionage ( probably because they don't waste money stupidly in espionage as in more mainstream games ( boo, I poisoned your well.... ) )..... I am increasingly being convinced that BtS AI was actually made for Warlords , given the way that it mishandles BtS stuff , like espionage, colonies, AP and corporations.

But that is stuff for Better AI

 

[Psyringe]

You can't remove all the espionage buildings... I can't see how you can play civ besides OCC without courthouses and jails also have a non-espionage function ( reduce WW ).

I think Roland meant to remove the espionage points, not to remove the building.

I am increasingly being convinced that BtS AI was actually made for Warlords , given the way that it mishandles BtS stuff , like espionage, colonies, AP and corporations.

Yep, definitely. Had to be expected though - it's not easy to teach an AI to intelligently use features which are still in development themselves. That's one of the reasons why I'm so glad that the Better AI mod has been revived.

 

[r_rolo1]

You know, Psyringe, a good deal of the world troubles come because of the diference between what ppl say and what ppl wanted to say And given that computers are very stupid machines we need to know exactly wht we want before we code them, otherwise we can get into big problems

 

[Woody1]

By the way, I don't think a lot of players are actually playing the no-espionage version of the game...

I turn it off in about half mt games. It's not too bad. A few useless buildings, but otherwise it works quite well.

However, I always turn off cultural victory (I just don't like it, and no espionage makes it worse). And I usually play with random events turned off (especially if I choose no espionage).

I'd be fine with just removing the spy events if you choose no espionage. Put in a check for no espionage when an event triggers, and if it contains spy points or something like that, don't trigger it?

My bet is that trying to fix all the problems with no espionage is going to result it some additional unintended bugs. The fix may be worse than the problem.

 

[Dresden]

Regarding Recon:

The fact, that the code of CvUnitAI::AI_exploreAir does not take the elevation of the target plot into account while determining the pBestPlot makes me agree to the "unwanted side effect of other changes" opinion, thus I'd like this to get fixed.

So I guess what you're saying here is that the AI isn't aware that some tiles show a lot more terrain when using the aerial reconnaissance mission... Not everyone speaks coder-language.

That's exactly what he's saying and he makes a very good point. If recon is supposed to have variable visibility based on terrain, why wasn't the AI made aware of the change? I'm leaning toward changing this one, despite the espionage visibility argument. Which brings us to...

The No Espionage Option:

I'll look at disabling the espionage-related events, disabling the free great spy, and disabling Scotland Yard (is that even necessary if there's no chance at a great spy?) as those seem really obvious and fairly simple fixes. I'll think about disabling purely Espionage-related regular buildings (e.g. Intel Agency & Security Bureau) but doing that in a flexible manner might prove difficult. That'd be about as far as I want to go in terms of No Espionage though, at least for now.

The base No Espionage effect turning of all building EP into culture pts does feel like a ridiculous hack made because of deadlines, but I'm worried that the reason Firaxis went that way rather than the more logical complete disabling of EP is because the latter broke stuff that they didn't have time to fix. My trying to change that sounds like an enormous undertaking that I'd never get properly tested and has high potential for unintended breakage.

BTW, thank you all for your input on these discussions; it's a big help.

 

[Woody1]

Regarding Recon:

That's exactly what he's saying and he makes a very good point. If recon is supposed to have variable visibility based on terrain, why wasn't the AI made aware of the change? I'm leaning toward changing this one, despite the espionage visibility argument. Which brings us to...

Sounds like you've found some evidence, that it is indeed a bug. It now moves from the "opinion" category to "likely a bug" category. That's good.

 

[r_rolo1]

If the AI isn't coded to know that there are better tiles to use recon, I agree that the current behaviour is buggy.

about no espionage: I think that blocking espionage events and the other easy stuff should be implemented as soon as possible , since they aren't big changes and that they would make the no espionage option far more inteligible. The other stuff.... well, it requires a lot more of thinking and beta testing Maybe it is better to let it to a less rushed oportunity

 

[Jaybe]

If the AI isn't coded to know that there are better tiles to use recon, I agree that the current behaviour is buggy.

Is AI use of recon actually meaningful?
Doesn't the AI know where all your units are automatically, or is that only with privateers (for which there has been ample evidence)?