Unofficial BTS 3.13 patch

My gut feeling is that improving the worker code was a slight judgement error. This is because the "Sid Meier Fun" test was not heeded with this improvement. Yes it is more fun from a purist point of view to see workers behaving more sensibly, but it is also more fun to see them behaving a bit less sensibly, and being able to nab em good every now and then. Thus it only produces a neutral (+1-1=0) result and was not a genuine bug in the first place (it was only an imperfection).

I must admit that I find it hard to believe someone would put forth an argument that an improvement to the game AI is a bad thing... As to whether it's a bug, barring some extremely stringent requirements for the definition, I don't think there's any question there. AI workers are designed to "run away" when they sense danger, the fact they couldn't properly assess the danger from units with certain types of promotions is clearly an oversight.

Bh
 
Also a human player knows to pull workers away from boarders and use them manually, but the A.I. doesn't have that option.
 
AI workers are designed to "run away" when they sense danger, the fact they couldn't properly assess the danger from units with certain types of promotions is clearly an oversight.

It strikes me that 'not working as intended' is a pretty good definition of a bug, so it was a good idea to try and make the AI workers a little less reckless. I'll just have to put up with very occasionally being able to nab a worker!:)
 
Am I the only one finding that this patch appears to be making the game near unplayable late game? My turns are taking several minutes or more to crunch when I or one of the computers is at war. And sometimes longer than ten minutes apiece. It appears to be calculating worker movement. This is happening every single game.
 
Am I the only one finding that this patch appears to be making the game near unplayable late game? My turns are taking several minutes or more to crunch when I or one of the computers is at war. And sometimes longer than ten minutes apiece. It appears to be calculating worker movement. This is happening every single game.

Are you using version 1.105 ?
 
I'm really thinking it's a problem with railroads, since I don't remember seeing this in the early game. Even in the early game, I have stacks of units with different movement point values that behave as intended.

It's the Gunships that are causing the problem. Gunships don't get movement bonuses from railroads, they are treated as roads for them. So when you multi-select a group that includes Gunships, it assumes the entire stack doesn't get the railroad movement bonus and calculates accordingly. Of course, they still do, so after you've moved 3 squares (the number of squares a 1-move unit can move over roads with Engineering), all the non-Gunship units still have movement points left, and the Gunships, since they have 4 moves, still have 3 moves left. So they can all keep moving.

I'm not sure where it does the movement calculations for the "predictions". If I can find that, it should be easy to fix. Obviously it'll be less easy to fix if I can't find it. ;)

Bh
 
It's the Gunships that are causing the problem. Gunships don't get movement bonuses from railroads, they are treated as roads for them. So when you multi-select a group that includes Gunships, it assumes the entire stack doesn't get the railroad movement bonus and calculates accordingly. Of course, they still do, so after you've moved 3 squares (the number of squares a 1-move unit can move over roads with Engineering), all the non-Gunship units still have movement points left, and the Gunships, since they have 4 moves, still have 3 moves left. So they can all keep moving.

I'm not sure where it does the movement calculations for the "predictions". If I can find that, it should be easy to fix. Obviously it'll be less easy to fix if I can't find it. ;)

Bh

Hey, thanks for looking into this.

I seem to remember that when moving gunships by themselves, the movement prediction is calculated correctly. Why would the game assume roads when the gunships are moved with other units?
 
It's the Gunships that are causing the problem.
[...]

The problem also occures when no gunships are involved. It seems to happen when mounted and unmounted units are selected together. I attached a savegame. To reproduce the bug select one of the stacks in the south of Karthago. If you try to move it to Paris, the prediction says, that it will take 2 turns. But the units can get there in the same turn still having movement points left.

alex
 
I think it may also have to do with the "early game" units in _alphabeta_'s stack. I think tres' and cats' might make the wrong calculations on a railroad- i seem to remember this from early vanilla.
 
The problem also occures when no gunships are involved. It seems to happen when mounted and unmounted units are selected together. I attached a savegame. To reproduce the bug select one of the stacks in the south of Karthago. If you try to move it to Paris, the prediction says, that it will take 2 turns. But the units can get there in the same turn still having movement points left.

Hmm, perhaps I did come to the wrong conclusion. It definitely has something to do with mixing units with different movement points. In your save, the prediction is always accurate until you mix the cavalry with any single movement unit.

Might be slightly trickier to track down.

Bh
 
Well, seems like a good news/bad news scenario. And while the good news is that I've figured out what the problem is, the bad news is there's not likely anything I can do about it.

The technical explanation:
Spoiler :
Each "movement point" translates into 60 points for game terms. A unit that moves 2 squares would have 120 points, for example. So when the game checks how many movement points it takes to move from one square to another, it uses that, not the "1 MP" that we think of.

The cost to move from one railroaded square to another is 1/10th a unit's total movement points. That means, contrary to what you might expect, a unit that has 1 MP will move the exact same number of squares over railroads as a unit that has 2 MPs. The same is not true for roads, which is why the bug doesn't show up there - a unit with 1 MP can move 2 (3 with Engineering) squares, and a unit with 2 MPs can move 4 (6 with Engineering) squares.

The problem comes into play when you've got units with multiple MP values in the same grouping. Consider the original paragraph - a unit with a single MP has 60 movement points, a unit with 2 MPs has 120. But over railroads they both can only move 10 squares. That means that a single square is taking away 6 movement points for the single MP unit, and 12 movement points for a 2 MPs unit. But for the "group move" calculation it uses the movement points of the group (ie, the lowest movement points the group has), which is 60. However, it is still using the individual unit's movement point cost, which means that the cost for units with 2 MPs is 12 movement points per square instead of 6 movement points for 1 MP units. So they end up appearing to only be able to move 1/2 the number of squares they really can. The number scales to the number of MPs the unit has (ie, a unit with 3 MPs would appear to only be able to move 1/3 the number of squares it really can).

Normally, using the "group" movement points works - because the cost to move on a square is independent of the total MPs a unit has. But once that changes with railroads, it starts causing these sorts of problems.


I'm going to see if there's any way to get it to check whether it's flat or percentage based movement costs, but I don't think that'll be possible.

edit: Wait - when did they change to a flat 10-square movement for railroads? Was it always like that? The Civilopedia claims that railroaded squares should cost 1/10th movement points, meaning that a unit with 2 MPs should be able to move 20 squares.

Bh
 
^ There are probably a few other cases of that (moving over non-roaded non-flat terrain with a stack containing Keshiks/Impis/Explorers/Guerilla2/Woods2/Gunships?)
 
Not really, it'll only happen when the flat cost for movement in a square is less than the normal movement cost - which only happens for railroaded squares.

Bh
 
Honestly, I can't see how this would be a huge issue for anyone. Seriously, you group a stack with different movement rates and with different terrain movement modifiers. What's the expectation there? It's a total mixed bag.

I wouldn't put this even 1/10 of the same level as something there there is an intuitive expectation.

You sit down, having never played before, and do certain game actions, you often expect a specific result, simply because it's intuitive. For example, the "movement preview". You hold down the mouse, and the game shows you a path that the unit will move to get there. However, you let go the mouse, and when it actually moves, it sometimes follows a different path. This, to me, is 10x worse than the issue with multiple-grouped units. Seriously... what's the expectation with the latter? I can't see there is any... so however it works is fine.

Wodan
 
I'm going to see if there's any way to get it to check whether it's flat or percentage based movement costs, but I don't think that'll be possible.

edit: Wait - when did they change to a flat 10-square movement for railroads? Was it always like that? The Civilopedia claims that railroaded squares should cost 1/10th movement points, meaning that a unit with 2 MPs should be able to move 20 squares.

Bh

It has always been like that, so I guess it's the civilopedia that is wrong here. The movement rule along railroads is also quite logical since the units aren't moving themselves but are using train movement (in reality).

Calculating the movement range will be especially difficult when the stack of units uses a combination of roads and railroads.

The way to accurately calculate the movement range would be by first splitting the units in several groups according to maximum movement speed (movement 1,2,3,4 or 5) and calculating the range for each group and then taking the minimum range of these groups. However, this would also result in problems since each group might not even have the same minimal path to the target.
 
It has always been like that, so I guess it's the civilopedia that is wrong here. The movement rule along railroads is also quite logical since the units aren't moving themselves but are using train movement (in reality).

Calculating the movement range will be especially difficult when the stack of units uses a combination of roads and railroads.

The way to accurately calculate the movement range would be by first splitting the units in several groups according to maximum movement speed (movement 1,2,3,4 or 5) and calculating the range for each group and then taking the minimum range of these groups. However, this would also result in problems since each group might not even have the same minimal path to the target.
I am very sure that they actually fixed it in 1.61 so that gunships get 12 tiles movement on railroad instead of 10 since a 4 movement gunship on road is faster than on railroad otherwise
(Edit: here it is:
1.61 changelog said:
Gunships now move faster over rails
)
Apparently they "unfixed" it :crazyeye:
But it never was 1/10 of movement points that is probably one of the many remnants of the Vanilla Beta Tests in the Civilopedia, but I won't get started on my pet peeve today :)
 
I am very sure that they actually fixed it in 1.61 so that gunships get 12 tiles movement on railroad instead of 10 since a 4 movement gunship on road is faster than on railroad otherwise

Apparently they "unfixed" it

No, Gunships still get 12 moves. Basically, any unit that has > (iMovement / iFlatMovement) MPs will use their MPs. Currently that's only Gunships, but if someone created a custom unit with 4+ MPs (anything less than 4 MPs will get the flat movement) they'd also move with their MPs.

Bh
 
No, Gunships still get 12 moves. Basically, any unit that has > (iMovement / iFlatMovement) MPs will use their MPs. Currently that's only Gunships, but if someone created a custom unit with 4+ MPs (anything less than 4 MPs will get the flat movement) they'd also move with their MPs.

Bh
Ah ok - shows that my games currently end prior to gunships :lol:
 
wodan wrote:You sit down, having never played before, and do certain game actions, you often expect a specific result, simply because it's intuitive. For example, the "movement preview". You hold down the mouse, and the game shows you a path that the unit will move to get there. However, you let go the mouse, and when it actually moves, it sometimes follows a different path. This, to me, is 10x worse than the issue with multiple-grouped units.

This is something about the CIV series that has always bothered me too.

So most of the time I have to manually move the unit(s) 1 tile at a time.

I do understand the game taking the defense of the terrain into account. But there are times I want the Unit(s) to move in as straight a path as possible. It maybe that I'm racing the AI to claim a Plumb of a city site. If I let the game do it I generally lose out. Cause it made my settler and Horse Archer to follow the hills and forest route 1 tile at a time instead of taking the flat tiles 2 at a time.

Just my 2 cents and a chime in with wodan.

Now if you can fix this other problem great too!

I'll be quiet now. :mischief:

:D

JosEPh
 
Top Bottom