Unofficial Patch 0.21 Released

[Dresden]

I took a look at rolo's "worst enemy of human team" issue and it does look like a simple isHuman() check will solve it. The second post of the topic now contains a list of topics which might be addressed in the next version. This one is nice and easy but others on the list are generally a good deal more complicated and/or a lot more controversial so no decisions have been made yet.

 

[r_rolo1]

I had reveiewed the patrol fuction thread ( oh my god, that thread was a mess ) and I still maintain the position that it should be corrected. My big issue is that IMHO I don't see a elegant solution for this besides a completely new and shiny patrol function, because the current function allows defenders to act like attackers ( it even forbids non-attack naval units of patroling ... see here ), that is the root of all the malus in here. Now about having a patrol function that works and it is well bundled with the rest of Civ combat... well, I wish you luck

The never ending "hands full"..... I had got that once in BtS in one of the LHC ( saves washed away by the hacker attack ). I am strongly in favour of any fix to this. any idea how?

The solution proposed by Dan to the dogpile problem seems nice and easy. I vote for it

Now I need to get back to the game and find some more work for Dresden

 

[Woody1]

Please, let's drop the patrol function argument. It boils down to only a very debatable matter of opinion whether it is a bug or not. And, even if it is a bug, it's only a bug that the user can take advantage of (or be a victim of) if he uses the patrol function. The AI does not use patrol, so it would only affect multiplayer games.

If you think it's a cheat or bug, then simply don't use patrol. The AI doesn't use it. I don't need or want a fix to stop me from cheating. If you think patrol is a broken feature, then don't use it! (Problem solved.)

 

[r_rolo1]

Good to know that your opinion hasn't changed, woody Like I said in the thread long ago, your opinion is IMHO logically inconsistent ( because in the end it would boil to that no broken feature would be solved if you applied to other problems the same rule ) , but if we are going to discuss this again, it is better to reactivate the other thread

P.S. Just because you don't play MP, do not presume that no one plays

 

[Dresden]

I'm aware of the controversy on the patrol issue and will be fully reading over the other topic again. Up till now I've basically just ignored it but I ought to make a decision one way or another on it.

I've also just added another issue to look at: The Liberalism cheat where you can get the free tech to apply to a different game. It's currently in the "undecided" category because although I want to fix it, I'm not yet sure it can be fixed in the SDK since the actual tech popup and bulk of game loading are handled by the engine.

 

[jdog5000]

There's one tiny bug in CvUnitAI::AI_attackAir that you inherited from Solver ... there's a line which should read like this:

if (((100*currHitPoints()) / maxHitPoints()) < 40)

As it is now there's a order of operations issue which makes it false for any injured unit.

 

[Dresden]

Good catch. Thanks jdog.

 

[Dresden]

The next version will definitely include Pep's group visibility fix where a group on a sentry mission will awake based on the vision of the best-seeing unit rather than the visibility of the "head" unit. I've coded it a little differently but the end result will be the same.

It will also probably include Pep's other fix: Privateers beginning their move inside a friendly city trigger "Declare war popup" Haven't looked at the details of that one yet.

And I'm considering Pep's movement changes where if you tell a unit to goto a square in the fog or black it won't automatically attack if it finds a previously-unseen enemy when it gets there. Really nice idea but might be a bit much for us as it's in that grey bug-fix/design-change area. Definitely want to hear some opinions on that one.

 

[Woody1]

Groan... another thing broken from Solver's attempt to improve the AI interception? :-(

How serious is this? When does it occur? I'm wondering whether I should back-out the unofficial patch and roll-back to vanilla 3.17.

 

[Dresden]

This one isn't very serious. One of Solver's changes was supposed to be "Damaged AI attack planes may choose to continue attacking if no defending interceptors are around" but it turns out that they actually just always refused to attack (like in the Official 3.17) because of the error.

 

[Woody1]

Okay, good to hear.

 

[r_rolo1]

The "attack on previously unseen unit while in go-to" is definitely a oversight and I seriously doubt that Firaxis wanted to make things that way ( Soren said that they wanted to kill the MM, right? Having to move the units tile by tile to avoid attacking a unseen battleship with a frigate or a privateer fits very well in my definition of MM )

 

[Woody1]

The "attack on previously unseen unit while in go-to" is definitely a oversight and I seriously doubt that Firaxis wanted to make things that way ( Soren said that they wanted to kill the MM, right? Having to move the units tile by tile to avoid attacking a unseen battleship with a frigate or a privateer fits very well in my definition of MM )

Yeah, I agree. The functionality should be "move 1 tile away from unseen target, then stop for orders."

Would be nice to fix that, if it's a simple fix. But beware of side-effects of a fix, such as what happens if the unseen target is a sub or stealth destroyer. You don't want to change something that breaks a battleship from moving over a stealth target.

 

[jdog5000]

Yeah, I third r_rolo1's comment. Good spot of potential side-effects Woody.

 

[Roland Johansen]

I'm aware of the controversy on the patrol issue and will be fully reading over the other topic again. Up till now I've basically just ignored it but I ought to make a decision one way or another on it.

Ouch, I've posted some really long posts in that thread. Good luck!

By the way, I just remembered another bug that I've never seen mentioned by someone else (although I haven't read every single post on this site) but which I think is pretty serious and basic: the aerial reconnaissance mission bug.

When you're exploring with normal land units, then units on high terrain can look over low terrain to see tiles on the other side of the low terrain (and can see high terrain behind low terrain). The various rules governing this process are not too difficult but would still take a lot of time to explain in detail. While this is perfectly realistic for land units, I personally think it's utterly ridiculous that a plane exploring over sea tiles can't see inland tiles while a plane exploring over land tiles can see many tiles into the sea area (and similar ridiculous situations).

I'll show some of these situations with some pictures as a picture is worth a thousand words. Note that the normal aerial reconnaissance range is rather huge, but the terrain factor can be debilitating.

My suggestion would be to make aerial reconnaissance viewing range independent from terrain.

1 Standard Reconnaissance Range.JPG
2 One can't look from water to land.JPG
3 One can't look from water over hills.JPG
4 One can't look from flatland over hills.JPG
5 One can't look from hills over mountains.JPG
6 Forests don't help with the viewing range.JPG
7 Flying over a mountain is the best.JPG

 

[Pep]

Yeah, I agree. The functionality should be "move 1 tile away from unseen target, then stop for orders."

Would be nice to fix that, if it's a simple fix. But beware of side-effects of a fix, such as what happens if the unseen target is a sub or stealth destroyer. You don't want to change something that breaks a battleship from moving over a stealth target.

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).

 

[Woody1]

By the way, I just remembered another bug that I've never seen mentioned by someone else (although I haven't read every single post on this site) but which I think is pretty serious and basic: the aerial reconnaissance mission bug.

I'm not sure it's a bug. That behavior has been around since day 1, it's very obvious to anyone doing air missions, and Firaxis has never addressed it in any patches.

I think they may have meant air units to do their scouting missions at a fixed height above ground level. A plane flying 1000' above plains couldn't see over hills, nor could a plane flying 1000' above hills see over mountains.

 

[Dresden]

I'm not sure it's a bug. That behavior has been around since day 1, it's very obvious to anyone doing air missions, and Firaxis has never addressed it in any patches.

If by "Day 1" you mean the day BTS came out, you are correct but if you mean the day Civ4 came out you are mistaken. This behavior changed between Vanilla/Warlords and BTS. For example here is a test similar to Roland's where we have a jet fighter reconning both a lake and a mountain in the middle of grass with a ring of hills around it.

In vanilla 1.74, there is no difference between the two situations. (aplogies on the zoom level; with my vanilla setup the clouds get in the way pretty quickly.)



And the same experiment in BTS 3.17 (UP 0.21) where flying over the lake is less effective than flying over the mountain:

I think they may have meant air units to do their scouting missions at a fixed height above ground level. A plane flying 1000' above plains couldn't see over hills, nor could a plane flying 1000' above hills see over mountains.

If it is a design decision, it's a bad one. Why does a plane only fly a certain distance above the hill if it's doing recon? A plane on a bombing or air-strike mission could reasonably be assumed to be hugging the ground so as not to endanger its mission but a plane whose sole purpose is to scout the area ought to be maximizing its vision and flying as high as it can. And what about the fact that you might have to fly over high terrain to reach the valley at the center of the recon region? I mean, shouldn't you at least be able to see the stuff on the closer side of the mountain or did the pilot have his eyes closed until he reached the recon spot?

Anyhow, with regard to the technical details, the recon function uses CvPlot::changeAdjacentSight() to reveal the plots and that function is vastly different between the vanilla/warlords SDKs and the BTS 3.17 SDK. However, the recon differences may be simply a side effect of that change since lots of other things use it too. The main difference in the actual CvUnit::setReconPlot() function is using a global define for the recon (max) visibility rather than a unit attribute (I think it was supposed to be half the operational range or something similar) and there's nothing there obviously related to the terrain behavior differences.

I wish I could find something in the BTS manual or patch notes about it to give me a clue as to whether recon was supposed to be changed this way or whether it was simply a side-effect of the new changeAdjacentSight() function though.

 

[bergee]

Count this as another vote to include Pep's changes to prevent you from attacking a previous unseen enemy. I can't fathom a situation where I would really want that to happen automatically.

 

[Woody1]

If by "Day 1" you mean the day BTS came out, you are correct but if you mean the day Civ4 came out you are mistaken.

Ah, I didn't realize the behaviour changed in BtS. It's been a long time since I've played vanilla or warlords. However, I'm not sure that lends any evidence toward it being a bug or a feature, either way.

If it is a design decision, it's a bad one. Why does a plane only fly a certain distance above the hill if it's doing recon? A plane on a bombing or air-strike mission could reasonably be assumed to be hugging the ground so as not to endanger its mission but a plane whose sole purpose is to scout the area ought to be maximizing its vision and flying as high as it can.

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.