Slitherine

Please see attached screen shot. Why is my skoutatoi allowed to move through the ZOC of the sub-roman foot to his front?

Its because you are also in the secondary zoc of the cavalry unit. You are in two secondary zocs, and the game lets you move "away" from zoc, it has picked the cavalry one as more threatening and will let you move away from it. If the infantry was facing you directly you would be in their primary zoc, which would be more threatening than the cavalry's secondary zoc and you would be stuck.

Gaznak wrote: ↑Thu Sep 05, 2019 1:43 am Its because you are also in the secondary zoc of the cavalry unit. You are in two secondary zocs, and the game lets you move "away" from zoc, it has picked the cavalry one as more threatening and will let you move away from it. If the infantry was facing you directly you would be in their primary zoc, which would be more threatening than the cavalry's secondary zoc and you would be stuck.

If the cavalry wasn't there then I could not move passed the sub-roman foot. The game isn't picking the cavalry as more threatening it is because I'm facing in that direction.

Cunningcairn wrote: ↑Thu Sep 05, 2019 2:00 am

Gaznak wrote: ↑Thu Sep 05, 2019 1:43 am Its because you are also in the secondary zoc of the cavalry unit. You are in two secondary zocs, and the game lets you move "away" from zoc, it has picked the cavalry one as more threatening and will let you move away from it. If the infantry was facing you directly you would be in their primary zoc, which would be more threatening than the cavalry's secondary zoc and you would be stuck.

If the cavalry wasn't there then I could not move passed the sub-roman foot. The game isn't picking the cavalry as more threatening it is because I'm facing in that direction.

When you are in more than one ZOC of equal priority, the game only makes you obey one of the ZOCs - this is as per the tabletop rules. In FOG2, which one applies is whichever one the code finds first. This is therefore indeterminate, but it wasn't considered worthwhile coding a priority system.

rbodleyscott wrote: ↑Thu Sep 05, 2019 6:36 am

Cunningcairn wrote: ↑Thu Sep 05, 2019 2:00 am

Gaznak wrote: ↑Thu Sep 05, 2019 1:43 am Its because you are also in the secondary zoc of the cavalry unit. You are in two secondary zocs, and the game lets you move "away" from zoc, it has picked the cavalry one as more threatening and will let you move away from it. If the infantry was facing you directly you would be in their primary zoc, which would be more threatening than the cavalry's secondary zoc and you would be stuck.

If the cavalry wasn't there then I could not move passed the sub-roman foot. The game isn't picking the cavalry as more threatening it is because I'm facing in that direction.

When you are in more than one ZOC of equal priority, the game only makes you obey one of the ZOCs - this is as per the tabletop rules. In FOG2, which one applies is whichever one the code finds first. This is therefore indeterminate, but it wasn't considered worthwhile coding a priority system.

Well that explains why in previous incidents like this I was unable to move at all. The game obviously prioritised the unit I was facing. May I ask why this is done? Why not just leave the ZOC rules the same as if there was only one ZOC'ng unit? Does this mean you can move completely across the front of a unit that is not found first by the code?

Cunningcairn wrote: ↑Thu Sep 05, 2019 9:20 am

rbodleyscott wrote: ↑Thu Sep 05, 2019 6:36 am

Cunningcairn wrote: ↑Thu Sep 05, 2019 2:00 am

If the cavalry wasn't there then I could not move passed the sub-roman foot. The game isn't picking the cavalry as more threatening it is because I'm facing in that direction.

When you are in more than one ZOC of equal priority, the game only makes you obey one of the ZOCs - this is as per the tabletop rules. In FOG2, which one applies is whichever one the code finds first. This is therefore indeterminate, but it wasn't considered worthwhile coding a priority system.

Well that explains why in previous incidents like this I was unable to move at all. The game obviously prioritised the unit I was facing. May I ask why this is done? Why not just leave the ZOC rules the same as if there was only one ZOC'ng unit? Does this mean you can move completely across the front of a unit that is not found first by the code?

It is the way it was in the tabletop version - mainly to stop the gamey use of ZOCs to engineer an enemy unit into a situation where it can't do anything at all. It also made programming it easier - having to take into account the directional movement rules from multiple enemy ZOCs would greatly complicate the code.

rbodleyscott wrote: ↑Thu Sep 05, 2019 9:49 am

Cunningcairn wrote: ↑Thu Sep 05, 2019 9:20 am

rbodleyscott wrote: ↑Thu Sep 05, 2019 6:36 am

When you are in more than one ZOC of equal priority, the game only makes you obey one of the ZOCs - this is as per the tabletop rules. In FOG2, which one applies is whichever one the code finds first. This is therefore indeterminate, but it wasn't considered worthwhile coding a priority system.

Well that explains why in previous incidents like this I was unable to move at all. The game obviously prioritised the unit I was facing. May I ask why this is done? Why not just leave the ZOC rules the same as if there was only one ZOC'ng unit? Does this mean you can move completely across the front of a unit that is not found first by the code?

It is the way it was in the tabletop version - mainly to stop the gamey use of ZOCs to engineer an enemy unit into a situation where it can't do anything at all. It also made programming it easier - having to take into account the directional movement rules from multiple enemy ZOCs would greatly complicate the code.

OK thanks.

Cunningcairn wrote: ↑Thu Sep 05, 2019 9:20 amDoes this mean you can move completely across the front of a unit that is not found first by the code?

The test is done on a square by square basis for each square passed through. Hence the above would only be possible if the unit is still being ZOCd by the original unit while crossing the ZOC of the other, and even then only if the code still found the original unit's ZOC first when testing each square along the route.

In short, probably not, though I won't rule it out as a rare possibility.

rbodleyscott wrote: ↑Thu Sep 05, 2019 10:14 am

Cunningcairn wrote: ↑Thu Sep 05, 2019 9:20 amDoes this mean you can move completely across the front of a unit that is not found first by the code?

The test is done on a square by square basis for each square passed through. Hence the above would only be possible if the unit is still being ZOCd by the original unit while crossing the ZOC of the other, and even then only if the code still found the original unit's ZOC first.

So if I have a unit facing my rear directly behind me and another facing my front directly in front of me and the unit behind is deemed by the software to be the ZOCing unit then I can move diagonally forward passed the unit to my front?

Cunningcairn wrote: ↑Thu Sep 05, 2019 10:17 am

rbodleyscott wrote: ↑Thu Sep 05, 2019 10:14 am

Cunningcairn wrote: ↑Thu Sep 05, 2019 9:20 amDoes this mean you can move completely across the front of a unit that is not found first by the code?

The test is done on a square by square basis for each square passed through. Hence the above would only be possible if the unit is still being ZOCd by the original unit while crossing the ZOC of the other, and even then only if the code still found the original unit's ZOC first.

So if I have a unit facing my rear directly behind me and another facing my front directly in front of me and the unit behind is deemed by the software to be the ZOCing unit then I can move diagonally forward passed the unit to my front?

Yes. (I have just tested it to make sure)

The logic is that ZOCs are mainly psychological, not brick walls, so the unit should be able to do something when "pinned" by two ZOCs.

One could take the view that it is unrealistic for it to be able to ignore one of the ZOCs, but it would be equally unrealistic for it to be unable to do anything.

In the tabletop version the player can choose which ZOC to obey, and which to ignore, but that would be more complicated to code, and we felt that it gives too much freedom of choice - in so far as it means that ZOCing an enemy with two ZOCs is little better than not ZOCing them at all. (It the tabletop game skilled players will avoid ZOCing the same enemy twice, because of this rule, which leads to rather gamey manoeuvring).

All in all, we are happy with the situation as it stands, imperfect though it may be.

The fact that the priority ZOC is indeterminate makes gamey manoeuvres by the ZOCing player less of an issue.

rbodleyscott wrote: ↑Thu Sep 05, 2019 10:23 am

Cunningcairn wrote: ↑Thu Sep 05, 2019 10:17 am

rbodleyscott wrote: ↑Thu Sep 05, 2019 10:14 am

The test is done on a square by square basis for each square passed through. Hence the above would only be possible if the unit is still being ZOCd by the original unit while crossing the ZOC of the other, and even then only if the code still found the original unit's ZOC first.

So if I have a unit facing my rear directly behind me and another facing my front directly in front of me and the unit behind is deemed by the software to be the ZOCing unit then I can move diagonally forward passed the unit to my front?

Yes. (I have just tested it to make sure)

The logic is that ZOCs are mainly psychological, not brick walls, so the unit should be able to do something when "pinned" by two ZOCs.

One could take the view that it is unrealistic for it to be able to ignore one of the ZOCs, but it would be equally unrealistic for it to be unable to do anything.

In the tabletop version the player can choose which ZOC to obey, and which to ignore, but that would be more complicated to code, and we felt that it gives too much freedom of choice - in so far as it means that ZOCing an enemy with two ZOCs is little better than not ZOCing them at all. (It the tabletop game skilled players will avoid ZOCing the same enemy twice, because of this rule, which leads to rather gamey manoeuvring).

All in all, we are happy with the situation as it stands, imperfect though it may be.

The fact that the priority ZOC is indeterminate makes gamey manoeuvres by the ZOCing player less of an issue.

I have no problem with the logic. What you say makes sense. However not being aware of this I have been ZOCing opponents as described thinking that would prevent their movement. In the past it has stopped them but I didn't realise that it was because my front unit was deemed to be the ZOCing unit and not because I had doubled ZOC'd him. There appear to be a number of "rules" that are not in the manual and only known to a few players. Is this because they have specifically asked in the past or been part of BETA testing or something else?

Cunningcairn wrote: ↑Thu Sep 05, 2019 10:46 amThere appear to be a number of "rules" that are not in the manual and only known to a few players. Is this because they have specifically asked in the past or been part of BETA testing or something else?

No, it is because they are members of the Illuminati and have been made privy to secret arcane knowledge.

Or they may have read it on the boards.

rbodleyscott wrote: ↑Thu Sep 05, 2019 3:54 pm ...it is because they are members of the Illuminati and have been made privy to secret arcane knowledge.

Dammit, I joined the Freemasons and now find out that only the Illuminati get this info...totally unfair, I tell ya!

Well this explains why my brilliant pinning of a unit has led to naught. I think if a unit is "surrounded" by ZOC with an enemy unit at their "12:00 and 6:00", if they are allowed to then escape by coding, they should have to take a cohesion test as they are technically falling back from one unit.

This was discovered a few betas ago, either in RoP or AoB. Ludendorf and I reported it and it was declared a feature and not a bug. The situation was rare enough that we didn't press further.

I am in total agreement with others though, who believe this is more of a rules loophole that needs to be closed up

rbodleyscott wrote: ↑Thu Sep 05, 2019 3:54 pm

Cunningcairn wrote: ↑Thu Sep 05, 2019 10:46 amThere appear to be a number of "rules" that are not in the manual and only known to a few players. Is this because they have specifically asked in the past or been part of BETA testing or something else?

No, it is because they are members of the Illuminati and have been made privy to secret arcane knowledge.

Or they may have read it on the boards.

I wasn't suggesting any form of conspiracy. I have not heard any mention of this prior to this discussion. Shouldn't this type of thing appear in the manual? What other rules are there that are not explained in the manual?

MikeC_81 wrote: ↑Thu Sep 05, 2019 5:43 pm This was discovered a few betas ago, either in RoP or AoB. Ludendorf and I reported it and it was declared a feature and not a bug. The situation was rare enough that we didn't press further.

I am in total agreement with others though, who believe this is more of a rules loophole that needs to be closed up

Thanks for the explanation.

I think a cohesion test to escape these situations seems reasonable. Or coding it so that the unit can either do nothing or charge the unit to its front

Based on the comments in this thread regarding ZOC'ing being a psychological barrier why then should any unit not be able to charge the square it is facing i.e. directly to its front, if occupied by an enemy unit? If you are ZOC'd by more than one unit then surely a charge against an opponent immediately to your front should be one of the most obvious and logical action? This will also negate the "gamey" play of changing a facing away from a unit to prevent it charging as it is being ZOC'd by another of your units.

SnuggleBunnies wrote: ↑Thu Sep 05, 2019 6:24 pm I think a cohesion test to escape these situations seems reasonable. Or coding it so that the unit can either do nothing or charge the unit to its front

I dislike being able to escape the situation at all, CT test or no. If you could escape, then there is no reason why we couldn't have units pass through ZoCs in other situations as well provided they pass a CT. The primary function of ZoCs in an I GO-YOU GO game format is to disallow moves which would only have been made possible by the transition of a real-time event into a turn-based event. Not just in this game, but in any other strategy/tactics game that uses such a turn-based system. The frontal ZoCs, in this case, represents the ability of the off turn player's units to "react" in real-time to things that happen in front of it.

Right now in Cunningcairn's scenario, and others that were encountered, units are being allowed to do things that they are strictly forbidden to do otherwise. If you want to allow a hail mary charge to the frontal unit, sure. But to allow it to just ignore the unit in front of it and avoid certain destruction is wrong imo, even if table top rules are like that.