Two units in the same tile - is this a bug?

[Ellye]

I noticed something today:

I had a Rifleman adjacent to an enemy city, and a Cavalry a few tiles away, in a straight line from the Rifleman.

My Rifleman attacked the city.

I ordered my Cavalry to also attack the city, clicking directly on it.
The Cavalry walked forward in a straight line, and ended his move in the same tile as the Rifleman, attacking the city from that tile.

When the turn finished, my Rifleman was automatically pushed back.

Notice that this isn't an automated shortcut - this move couldn't be done, as the Rifleman couldn't normally attack and retreat in the same turn.

 

[Steelyglint]

Bug. If I've told a unit to go somewhere but it's found it can't, and stops on a tile which already has a unit on it, one of the two has to move and neither are allowed to attack from that tile (in case I lose). Shouldn't be allowed.

 

[aatami]

No, it's not a bug. It's intended to work that way.

 

[CoolLizy]

It's a bug. Made especially annoying because it seems to often happens with the AI players. I've seen them attack cities with nearly all their force's melee units in a single tile. It's hilarious when they do it to another AI player; less so when it happens to you...

 

[deanej]

No, it's not a bug. It's intended to work that way.

This. Combat occurs from ATTEMPTING to move onto the same tile* as an enemy unit. This is what allows you to go on the tile with another of your units - since the move order was for the tile with the enemy unit, you're allowed to move onto the tile with yours. However, when the combat occurs, you aren't on that tile yet, and don't move onto it unless you kill the enemy unit (note that despite this, combat modifier's use the enemy's tile, because that's where you're attacking). If you don't believe me, just look at the combat animation. The units are each on the edge of their respective tiles and go back to the center on the end (unless the attacker kills the defender). Only if you kill the enemy does the unit finally move onto that tile.

This is, in fact, how it's always worked in civ. It just becomes more important now because of civ5's combat system (namely the idea that both units can survive combat). But it's noticeable in civ4 with siege and mounted units.

*Yes, civ5 uses hexagons, but using the word tile doesn't have to mean that said tile is shaped like a square.

 

[qemist]

This. Combat occurs from ATTEMPTING to move onto the same tile* as an enemy unit. This is what allows you to go on the tile with another of your units - since the move order was for the tile with the enemy unit, you're allowed to move onto the tile with yours. However, when the combat occurs, you aren't on that tile yet, and don't move onto it unless you kill the enemy unit (note that despite this, combat modifier's use the enemy's tile, because that's where you're attacking).

That doesn't explain the OP's observation. Normally you will not be allowed to attack from a tile where your units are double stacked, and the OP's scenario violates this. I think it's a glitch.

 

[Ranos]

It's a bug. Made especially annoying because it seems to often happens with the AI players. I've seen them attack cities with nearly all their force's melee units in a single tile. It's hilarious when they do it to another AI player; less so when it happens to you...

I have never really seen this happen. If I attempt to attack a unit and will have to do it from a tile that I already have a unit in, the game won't let me do it. This is the whole point of 1UPT, you can't have multiple units in the same tile unless they are moving thru. Combat does not count as moving thru.

 

[headcase]

Sounds like a bug, but if it isn't, it's because mounted units such as your Cavalry are allowed to attack, as long as they have enough moves left afterwards to move to an empty hex afterwards, in which case they will automatically move to that hex after attacking. Quite an interesting undocumented feature

 

[jtb1127]

Yes it is definitely a bug.

 

[joncnunn]

Not always a bug; I was temporarily stacked in the same tile as another players unit when I gave a naval unit the order to go to a fog of war tile when it got revealed it was an illegal tile for a naval unit to enter.

 

[Steelyglint]

You should so have done a poll for this thread Ellye.

 

[aatami]

This. Combat occurs from ATTEMPTING to move onto the same tile* as an enemy unit. This is what allows you to go on the tile with another of your units - since the move order was for the tile with the enemy unit, you're allowed to move onto the tile with yours. However, when the combat occurs, you aren't on that tile yet, and don't move onto it unless you kill the enemy unit (note that despite this, combat modifier's use the enemy's tile, because that's where you're attacking). If you don't believe me, just look at the combat animation. The units are each on the edge of their respective tiles and go back to the center on the end (unless the attacker kills the defender). Only if you kill the enemy does the unit finally move onto that tile.

This is, in fact, how it's always worked in civ. It just becomes more important now because of civ5's combat system (namely the idea that both units can survive combat). But it's noticeable in civ4 with siege and mounted units.

*Yes, civ5 uses hexagons, but using the word tile doesn't have to mean that said tile is shaped like a square.

Read this and come to your senses before you post. It is not a bug.

 

[Ellye]

Read this and come to your senses before you post. It is not a bug.

Uh, this doesn't tell anything, actually.
We all know how 1upt works.

Bugs aren't magical things that appear randomly in a code. They exist for a reason, usually a logical mistake.
And this seems like one. Yes, combat happens when one unit attempts to move in to a tile that is occupied. But the real issue that defines if this is intended or a bug is: should a unit be able to attempt to move to a occupied tile, if this attempt involves it sharing a tile with another unit?

This situation made my Rifleman step backwards after the end of the turn, a move it had no way to actually perform by the game rules (he had no movement points left). So, for me, it's a glitch, a bug.

Also, it's not reliable reproducible. I had pretty much the same situation again, and it didn't happen.

 

[CoolLizy]

This. Combat occurs from ATTEMPTING to move onto the same tile* as an enemy unit. This is what allows you to go on the tile with another of your units - since the move order was for the tile with the enemy unit, you're allowed to move onto the tile with yours. However, when the combat occurs, you aren't on that tile yet, and don't move onto it unless you kill the enemy unit (note that despite this, combat modifier's use the enemy's tile, because that's where you're attacking).

Except this is incorrect. In Civ 5, even if you are attacking "in" the enemy tile, you must first occupy a tile to attack from. You can't occupy a tile that another unit is in, therefore you can't attack by just "passing through" a tile another unit is in. Moving and attacking are considered two separate actions in Civ 5; it's not just an attempt to move into an enemy tile as it was in past games. Otherwise the game would let you temporarily stack units that have movement points left so that you can undertake a massive attack from a single tile. But it doesn't. The only time it lets you is when the pathfinding gets confused--it doesn't even work 100% of the time! And when the battle is over and the enemy survives, the game has to teleport units around the map to correctly observe 1upt and make it work.

 

[deanej]

I think you misunderstand how movement works. A unit doesn't just magically teleport to a tile with the appropriate amount of moves subtracted off. The unit has to first go though all the other tiles. Civ5 allows a unit to be on a tile with another if said unit's next move is to a different tile. This is why you don't need a clear path to go somewhere and also why you can't move onto an occupied tile individually: if you don't specify an end tile that is unoccupied, the game has no way to know if you intend to move the unit again. Just look at the animations. The unit goes through those tiles.

 

[CoolLizy]

I think you misunderstand how movement works. A unit doesn't just magically teleport to a tile with the appropriate amount of moves subtracted off.

I'm assuming this reply is to me, in which case when did I say this is how movement works?

The topic of discussion is thus: say you have a unit, a spearman for the sake of this example, next to an enemy warrior. The spearman has expended all its movement points and can no longer move. The bug in question is when the player (or AI) commands a second unit--we'll say a swordsman--to attack the enemy warrior and the computer leads the unit into the space with the spearman and initiates the attack from there. This is a bug, because regardless of how many movement points the swordsman has, it's supposed to attack from an open space.

This is where the "teleporting" mentioned comes into play. If the swordsman kills the enemy warrior, you can say all is well and good, but if both swordsman and the warrior survive then the swordsman is left in the tile with the spearman from which it attacked. See the problem? By attacking, the swordsman is left without any movement points, and it's in a tile with another unit, the spearman, that was already there and also has no movement points left. Both units occupy the tile, and neither can move. To compensate for this, the game kicks one unit out, ejecting it from the tile and plopping it down in another adjacent tile to preserve 1upt regardless of the fact neither can move.

if you don't specify an end tile that is unoccupied, the game has no way to know if you intend to move the unit again.

Except that the game already has a way of dealing with this. If two units of the same type occupy a tile (for example, a garrisoned city creates a new military unit) then the task button alerts the player to "Move Stacked Unit". If two units were meant to be allowed to share a space temporally as a means of attacking from a single tile, then it would let you and then tell you to fix it afterwards. But it doesn't.

 

[deanej]

You said "you must first occupy the tile you attack from". Since moving multiple tiles is actually a series of single tile movements, the tile is occupied. The game allows this to happen because it's part of a goto sequence.

Except that the game already has a way of dealing with this. If two units of the same type occupy a tile (for example, a garrisoned city creates a new military unit) then the task button alerts the player to "Move Stacked Unit". If two units were meant to be allowed to share a space temporally as a means of attacking from a single tile, then it would let you and then tell you to fix it afterwards. But it doesn't.

Just denying such moves out of sequence is SO much easier than trying to figure out if there will be somewhere for a unit to go before the end of the turn.

To compensate for this, the game kicks one unit out, ejecting it from the tile and plopping it down in another adjacent tile to preserve 1upt regardless of the fact neither can move.

Do you also have a problem with declaring war and a unit gets kicked out of enemy territory without enough moves for that movement?

 

[CoolLizy]

You said "you must first occupy the tile you attack from". Since moving multiple tiles is actually a series of single tile movements, the tile is occupied. The game allows this to happen because it's part of a goto sequence.

It's not. It's a two-step sequence. Goto, and then attack. Furthermore, if this was intentional then you'd be able to do it all the time. But you can't. Sometimes the game wigs out and lets you do it. Most of the time it doesn't.

Just denying such moves out of sequence is SO much easier than trying to figure out if there will be somewhere for a unit to go before the end of the turn.

Why not just forcibly eject them? If the behavior in question is intentional, the game already does it anyway.

Do you also have a problem with declaring war and a unit gets kicked out of enemy territory without enough moves for that movement?

If it happened every turn, yes. But it doesn't. It happens on a DoW so that you can't game the system and sneak attack. (Or if border treaties run out because there's no option to renegotiate them before it happens, but that's another topic for another day.)

Again, if the behavior in question is intentional, why not just give the player a button "teleport unit to random tile" to get it out of my way before I attack with another unit? It'd be easier and more consistent than the bug. As it stands, you cannot even delete a unit that's in your way if it's out of moves.

If they wanted to let you attack from the same tile with a bunch of different units, they'd have a way to do it. They don't, except for this bug, because that would defeat part of the idea behind 1upt.

 

[Ellye]

A important arguments for this being a bug:

It will not happen if you're manually controlling your unit step by step. It'll only happen if you rely on the pathfinding, and it will only happen if the pathfinding algorithm can't find any free tile around the target.

 

[qemist]

Do you also have a problem with declaring war and a unit gets kicked out of enemy territory without enough moves for that movement?

Seems artifical. A more realistic solution to the RoPR problem would be that units have to travel disarmed through enemy territory, and have zero attack until they return to friendly or neutral territory. Not only would that solve the movement unreality, it would get rid of the situation where units can duke it out in a neutral's territory, or fire with impunity from a neutral's territory. In real life RoPs usually came with the rider that they were for "peaceful" passage only, i.e. you couldn't wage war while you were in the granter's lands.

Any thoughts on how that would work?