Stuff about Interrupts in JA.
This one had to be splitted in 2 unequal parts: one about the Interrupt Test itself (rather simple one), and other, about pre-requisites to it (sadly, more complex).
At first, an easy part. So, if conditions leading to the Interrupt Test is met (about conditions themselves later), a sum of values of some parameters of Interrupter (merc, who just seen, heard, or received a hit) compared to a sum of values of of some parameters of Victim (merc, who just moved into view range, produced a sound, shot a close bullet, or dealt a hit to Interrupter (this making the term counterintuitive, but i cant imagine better one, Interruptee sound too close and weird)), and if sum of Interrupter's is more, Interrupt happens, and active turn goes to that Interrupter merc from Victim merc.
Sum of Interrupt value for Enemy consist of:
a) Exp Level of that Merc;
b) + 1, if Status of Merc we're testing against is "AlreadySeen by This Merc", or 0 otherwise;
c) - n, where n = [AmountOfOpponentsThisMercSeeNow above than 1] (so if Merc see 3 opponents, n=2);
d) - 1, if Interrupter, and Status of Merc we're testing against is "CurrentlyHeard by This Merc", or 0 otherwise;
e) - DamagePenalty of Damage/10 if Interrupter;
f) + 1, if Status of Merc we're testing against is "CurrentlySeen by Our Team", or 0 otherwise;
g) + Difficulty bonus of [-1; 0; +1] per Difficulty level.
Sum of Interrupt value for Player's merc consist of:
a) Exp Level of that Merc;
b) + 1, if Status of Merc we're testing against is "AlreadySeen by This Merc", or 0 otherwise;
c) - n, where n = [AmountOfOpponentsMercsSeeNow above than 1] (so if Merc see 1 opponent, n=0);
d) - 1, if Interrupter, and Status of Merc we're testing against is "CurrentlyHeard by This Merc", or 0 otherwise;
e) - DamagePenalty of Damage/10 if Interrupter.
To make it any useful, there is a need in explanation for Status of Merc mentioned there. They also required for the pre-requsites.
Data about each Merc's "knowledge status" to each opponent's Merc's are stored in 3 different places, for each type of Status. Every Merc have a full knowledge of other Mercs from the same Side, so its not stored.
1) Merc's Own list of opponents. Initially starting as NotKnown for each, their values could change to CurrentlySeen (if seen) or CurrentlyHeard (strictly speaking "Known Unseen", as it could be also set by a hit, but as usually its about detection of Noise, ill use "Hear" for a short of) on detection of an opponent. As that list is update on various actions, performed by mercs, say movements, Status could be further updated to value RecentlySeen, if Merc will lose a sight on opponent being seen this turn. If no contact is re-established, values would degrade to SeenLastTurn and HeardLastTurn on beginning of next turn, and to SeenTurnAgo and HeardTurnAgo on beginning of next to next turn; if contact is not re-estabilished still, it will set to NotKnown at next turn.
Seen and Heard is mutually exclusive, with Seen taking priority, making Heard redundant if set. The value in d) is a penalty for Interrupter for not actually seeing a Victim. But the real importance of the Own Current list is that, while merc is having any value more than NotKnown for some opponent, he/she will perform a visual check for that opponent at max distance (13-14 tiles) no matter of Facing direction, and without help of Camo for the latter (note, that detection "by ear" works the same way, full distance and no Facing direction importance). Thus, if opponent, who is merely HeardTurnAgo (or better value, ofc) for some Merc, will move behind that merc at 12 tiles even in Camo, that Merc will make a visual contact.
2) Merc's Seen list of opponent. Way more simple, with only 3 states and without complex refreshing. Initially starting as NotSeen for each, their values could change to JustSeen on Visual detection, and then to AlreadySeen on next status update. After that, it stay this way for the rest of battle. Mostly used in Interrupts, say as value b), this is supposed to present "surprize" or "confidence" on a contact or resume of contact. Due to way it works, it turns from JustSeen to AlreadySeen on any update, resulting in odd exploit of performing seemingly redundant action to change an outcome.
Example: Merc move a tile and Visually detect an Enemy, who not looking that Merc direction and not see him. As result of detection, that Enemy changed status in that Merc Seen listfrom NotSeen to JustSeen. If Merc will fire a shot at Enemy, in possible Interrupt Test the bonus for AlreadySeen will not be applied. But if Merc will move (reasonable, but costly), or merely look to Enemy (Turning into the same Facing, with 0 RP cost), Status will be updated to AlreadySeen, and bonus will be applied. Id said its not an essentially exploit on its own, more like interface limitation, as some actions, that supposedly should update it (like shooting) do not, so manual approach sometimes needed.
3) Team list of opponents. Works different for Player side and Enemies. For PlayerTeam best value of some Merc Own list is used and shared ("radioed") with other teammates (so if Merc see Enemy, that enemy appear on Team (default) view as "Seen". player can use F9 button to change Team view on selected Merc's Own view instead, using only Own list's data to display) for free. For Enemies, tho, to "radio" a value of Own's list, a special action of 5AP cost is needed, and that action is not necessary outweight other alternatives. So getting a value above NotKnown for some opponent of EnemyTeam is a some achievement on its own, unlike for PlayerTeam, so f) applied to them only. Its value affect Producing of Sound detection trigger: CurrentlySeen by Team merc do not initiate such detection. Otherwise it work similar to Own list, with same type of values and rules, so if value not updated to a more current one, it will be set back to NotKnown after TurnAgo. Note, that for player's display on screen, only CurrentlySeen Enemies are shown, and there is no fair in-game way to check other Statuses.
Now its possible to explain pre-requisites, as not every action results in Interrupt Test. While it pretty useful, as otherwise game would become an interrupt fest, it also lead to very exploitable limitations.
To initiate an actual Interrupt Test, action should have a following criteria met in order:
I) One of condition for occurred detection is met: (Visual (normally moving into view range); Producing of Sound (various ways, walking, firing, etc, but victim merc shouldnt be CurrentlySeen by Our Team (while its irrelevant in other conditions)); Close Missing a Target (meaning that even if that bullet is not hit close enough to be heard on impact, but flied close enough, it will be enough for detection attempt; another case of is missing of stab attempt); Receiving a Hit (except stabs); Special "New Turn" case).
Visual detection could happen and possibly trigger Interrupt even if a non-Visual one happened prior, but not vice versa (so, if CurrentlyHeard merc become CurrentlySeen by moving into range its good enough to possibly trigger Interrupt, but if CurrentlySeen merc fire bullet, it doesnt matter for changing a status, even if that bullet will hit the other one, as CurrentlySeen is a best possible detection).
- For Visual detection, Status of Victim in Interrupter's Own list should also turn to CurrentlySeen from any state except CurrentlySeen or RecentlySeen, normally it happens if merc is moving, or, counterintuitively, looking "the same Facing direction" with zero AP cost, but NOT by a turning, that change the Facing, with one AP cost, that action is not leading to visual detection of turning merc (possibly a bug) (note: turning caused by shot is not cause a looking at all, so if merc is ordered to fire at a target that is behind him, he will turn to that target, but will not see it, until next action of looking will happens)). Its possible only if visual contact could be established on that distance, so it cannot happen on a distance more than 14 tiles. Normally this distance is achieved only on Facing Direction cone, and reduced up to 0 for Backward Direction; but under cases mentioned in Own list description above it could be a "oval with maximum values of 14 tiles vertical, 13 tiles horizontal (FullMaxRound)". Even more confusing: actually any other actions that possibly lead to detection (namely, producing a sound, shot a close bullet, or dealing a (non-knife) hit, in addition to moving or looking) is triggering a FullMaxRound Visible detection attempt, where Camo is not in effect, but map objects are in (so, say, wall will still block visual range, and prevent such detection), and pure Visual detection's range reduce described above is an exception to it.
