Thats what i was about. If its already just 1-3 such days, then possibly Reserves could just end way prior it in Go Ahead, as they spawn about twice faster than usual Hard.

Fast Anims are about speeding up merc's movements, while keeping game controls manageable. If everything is supposed be faster, maybe it could be achieved with DosBox cycles? Actually i dont think FastAnims that important, afterall movement speeds are so different in turn-based in real-time already anyway, why not see them as default speed if they increase quality of life for you? I just mentioned them as a thing, that is obviously merely interface thnig, in reality having an effect on an actual gameplay, it happens surprizingly often.

Knives surely could help to save ammo for TreatedSpectra ShieldedVest late guys, they are indeed impossible to be shot outright, i defnitely forgot about it, thanks.

Yes, quicksave with some short description like ones you wrote above is ideal.

Afterthought i think i have a valid explanation of it, and its looks its, oddly enough, pretty normal situations. Enemy mercs, spotted by player are kept drawn on screen till they will move, or till their turn will start. In both cases new visibility check(s) will be performed, and they will disappear from the game screen if they will be out of sight. While player's mercs could change their position in their turn, and lose the sight on enemy mercs; that will not disappear those enemies from the screen to make player's life easier (as player in theory would been able to "write down" the coords of enemies, who are not move anyway, and still be able to "see" them). But as some calculations are actually checking if merc do actually see another merc at the moment (with CtH calculation in non-AIM enabled game oddly not included in the list), player can use F9 option to check the whom the certain merc do actually see.
Your screenshot cannot be really explained from it ofc, in part why it stated as "sees 2 enemies". Personally i failed to notice actual enemy seen by merc more than once tho, as they do see them out of game screen (im not pretending it be real explanation).

Yes, it seems possible that with a lot of back and forth losing-regaining a sector the Reserves would end. You may add about 50.

Knives: You say late guys, but it starts on the very first day, some of them are not really vulnerable to .38 ammo already.

Out of game screen - no way, it was clearly about the 2 seen in noF9.jpg, there were no others in map view. I'm not even sure which information was erroneous: that Hurl sees 2 enemies or the shooting one not being drawn in F9. Hurl kept having a problem with seen enemies for the rest of the fight (he had been seeing "1 enemy" according to the message, while clearly he actually did not see any). So maybe the problem was: the "new" enemy came and stood between us. Then the covered one became unseen indeed, but due to some bug he wasn't substracted from the number of seen enemies.

5. I think the "mystery" of missing items has been solved. I have entered S36 on day9 and threw a stun grenade at the crate with oil can. The crate is now empty, others normal. So that was it, indeed.
Save:
[url=]https://www.dropbox.com/s/lju0o68ckkxb6h7/QUICK.SAV?dl=0[/url]

I recall now, i thought it worked the way i initially wrote, but i decided to not fix it after i realized it only provide additional bonus roll for hitting a target (and not as if i decided its just overall fine, as i erroneously thought when i wrote it first).

I thought about 200 tbh. But i need to check the actual amount of Reserves at end of game, and im still not able to find a time for.

In day 1 normally only Kevlar-level guys appear. I did managed to collaps some of them instead of killing a few times, but its something really rare from my experience. I mean they indeed take hits really slowly, but they still die first instead of falling down. Treated Spectra ones are likely to survive salvos of pointblank Beretta and collaps at spot alive, instead.

I think there is something bad in updating of states of enemies, according to that bug description and screenshots. Sadly i cannot get it still, and unable to create a such situation. There is clear oddity with laying mercs, as they cannot see, only hear, and they do not update their known enemies who moved out of sight, and they still think they see them, even if they do not anymore. But i cannot make it persistent in my experiments, they update their knowledge when they rise up and see what they actually do not see ones, whom they thought they does. I hope you could be able to get a save with that bug eventually.

Not really sure what to look there. You said it worked as described, right?

Id say that quick test clearly show that the amount spent is the same for dfferently skilled mers for a given amount of bandaged health, yes.

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.

Stuff about Interrupts in JA, continued

But very important is another additional limitation: no detection test is performed if distance is more than 14 tiles. It lead to really exploitable stuff: no Interrupt is possible, if distance between participants are more than 14 tiles. Being a odd way to prevent excessive interrupts when Interrupter actually unaware of Victim, it turns into pure exploit together with free Team view for Player side (no Enemies will fire into mercs, they dont have in Own list as CurrentlySeen) and absolutely no penalty for firing into non-Seen targets without AIM option enabled. Thus player can fire at Enemy from 15+ tiles and will never be interrupted.
- For Hearing detection, Status of Victim in Interrupter's Own list should also turn to CurrentlyHeard from any state except CurrentlySeen, RecentlySeen, or CurrentlyHeard, it happens as a result of failed FullMaxRound detection attempt, and also cannot happen if distance is more than 14 tiles (it happens if something is blocking visual range, despite Camo have no effect there). Additional exceptions there is that Victim should actually see Interrupter (another means to cut down amount of useless interrupts, between mercs, who unaware about eachother, but it also could be exploited), and that Interrupter shouldnt see any opponent at all already (supposedly too busy to bother with sound then).
- For Special case, normally happening in beginning of turn, where new participants (Mercs, Enemies or Guards) entered a sector (an action not causing actual move, so this case is added), every merc is performing detection check, and for every JustSeen in Seen list Interrupt Test is triggered, with Own list status not of matter there. Exception for it is a X-button mercs swap, that is also trigger Special case. As Seen list change to JustSeen only on Visual detection, later it described in Visual.
II) Interrupter should have enough AP for a type of detection and shouldnt be collapsed to ground.
- For Visual detection free AP of Interrupter should be enough to at least move a tile. It is, again, intended to reduce amount of useless interrupt, but the way they decided to check for "cheapest possible reasonable action", it could lead to situation, when possible Interrupter is denied an action, because do not have enough AP to move, while have enough of them to shoot.
- For Hearing detection free AP of Interrupter should be enough to at least turn to other direction (to look at distraction), so at least 1.
III) Additional checks that could make Interrupt Test itself redundant; meeting any of them them would make Interrupter win outright so they shouldnt happen in order to actual Interrupt Test to be performed.
- Victim should see Interrupter. Its impossible in Hearing interrupts, because of additional rule (see above).
- Interrupter shouldnt be Santino.
There are additional rules for him to be able to interrupt at all. Santino will not interrupt if condition that Victim is also see him is not met (thus its possible to notice him via 1 AP turning without interrupt happen) for Visual detection. However, for Hearing detection this is not checked (obviously buggy), and Santino will interrupt on Hearing even if Victim is not see him (if player will manage to move a merc into Santino's view range without noticing him with that merc) in case. But, not directly related to interrupt itself, but to Santino's AI, he will not speak (and he will detonate bombs only after speech) if nobody seen him that turn, so will do nothing during opportunity, provided by interrupt. [Many thanks to MitchShudlem for ingenious saves to show it.]

Summary and some curiosities related.
Interrupts are not random-based, and somewhat manageable, say bringing many mercs into view range of opponent could reduce his ability to interrupt, or player can fire at Enemy from 15+ tiles and will never be interrupted, but it hard to operate with due to their complexity and non-transparency, as most of Statuses involved are cannot be checked fair way.
Complexity and non-transparency of mechanic is also leading to some odd results, like surprisingly high ability of mercs to interrupt ones, who shoot them in back (as they do not only get a max view range for detection then, but also not penalized by seeing other, distracting, opponents). In reality, most of time, Interrupter detect Victim by sound of Victim's gun (if not detected Visually prior), and that should make Silencers very useful. But in games without IMPACT option enabled, another effect caused confusion and prevented it: bullet target always heard its impact prior an actual damage was dealt, so detection check was performed that time, and DamagePenalty was never applied, so the fact Victim went undetected via gun shot sound prior changed nothing about ability to interrupt.
Another non-obvious stuff is doors. Actually, after merc's action during a turn, normally only refreshes triggered are that Merc's own Statuses, according to mercs he sees, and opponent Team as a whole, but only regarding this merc. So if merc A will move, he could be noticed by opponents team, and could notice some of opponents by his own, but merc B will not be noticed as result of that action, and also will not notice anyone. It result in a counterintuitive case with doors.
Example: Suppose that group of mercs stay near a closed door, and that group would be seen in case a door been opened. Simple case should be enough, with Enemy1, Enemy2, Merc1, Merc2 and Door: they stay on a same tiles row like, with all M's and E's facing Door [M2 M1 D E1 E2]. If M1 will open D, it will result in visual detection of M1 by E1 and E2, and of E1 and E2 by M1, but no status for M2 will be updated. In result, during possible Interrupt Test M1 will be penalized for seeing 2 opponents, but E's will not, as they will not see M2.
Interrupt results differs according to side's turn they happens. If Player side is manage to win own Interrupt during own turn (meaning some Enemy interrupted them already, and now Player's Merc also interrupted an action of that Enemy), the possible action will be granted to a whole Player's side, not only the actual interrupter. The interrupted Enemy will still be able to continue own actions if player will press Done, prior getting AP's replenished in Enemy turn. Its intentional and not bug.
Of course there is also amount of bugs, related to Interrupts in non-patched version (granting a right to action to an unrelated merc as result of interrupt, not granting right to action to valid one etc etc), i hope most of them will be gone by 1.15z.
Special (eh) case is a Rock. If mercs hear the Rock's impact (normally only Enemies does, as only Mercs throw them), they got a free Interrupt, with only one check should be met: Rock still shouldnt be thrown by a CurrentlySeen Merc (as produced noise is not checked then). That is supposedly intended to lure Enemies to trap, its very silly mechanic, its really make game only worse.
The way Rocks are works is especially inconsistent with other Sounds. Merc bother about sound, only if it produced by somebody not CurrentlySeen in Own or Team list. It lead to Enemies to ignore gunshots of other Enemies, as they aware of eachother. But at the same time, Enemy Team list is not update for free, so other Enemies could be unaware about opponent. Yet at the same time they would stoically ignore gunshots of a "sentry" even during the Sabotage mission. They would even ignore bullets of that "sentry" hitting a wall near them, or screams of pain of that "sentry" (thats entirely a "working process"). Those Enemies would possess an absolute perfect hearing tho, as they wouls be able to differs merely on ear if its Player's Merc would fire the same type of weapon, or even get the ownership of a bullet. Thus Enemies would ignore a sudden shots and screams of own guy, sent to spot possible opponents, but would react on a Rock falled somewhere.

Stuff about ChanceToHit in JA

ChanceToHit is a value affecting if attack will succeed or not, by comparing it to Roll100; but not necessary it wholly determine it. Supposedly missed shots could still hit the target, while ones, that of max probability (its 99%, not 100% here), could still hit an obstacles on its way, and miss. There is a 3 types of attack using ChanceToHit, they are using similar, but still different formulas, so they will get their own parts.

Shooting Accuracy:
Used when Gun is fired. Most complex one, though with the most simplest basic formula:
[MercShootingAccuracy = Marksmanship];
WeaponCondition modify it, in case WeaponCondition is lower than Marksmanship to:
[WeaponConditionAffectedShootingAccuracy = (Marksmanship + WeaponCondition)/2];
BaseShootingAccuracy or WeaponConditionAffectedShootingAccuracy later will be called just BaseShootingAccuracy.
It further modified by AimLevel and additional bonus for SameTarget (same as during previous attack with that weapon drawn) and by EnemyDifficultyLevelBonus of [-1; 0; +1] if shot is performed by Enemy:
[ShootingAccuracyBonus = BaseShootingAccuracy + (AimLevel + SameTarget + EnemyDifficultyLevelBonus)*10].
In case Shooter is in process of bandaging, penalty of 20 is applied to ShootingAccuracyBonus.

Another important value used is a [DistanceToTarget ~ TilesToTarget*15], but with about half values used for tiles with Shooter and

Target, and modified by SunGoggles weared by shooter to:
[GoggleReducedDistance = DistanceToTarget - DistanceToTarget/10];
and then by SniperScope attached to gun to:
[ScopeReduction = (15 *AimingPoints * (GoggleReducedDistance - 150) / 100)*ItemCondition/100] to:
[ActualDistance = (GoggleReducedDistance - ScopeReduction) if ScopeReduction is more than 0 (Scope cannot decrease the ChanceToHit).
Further calculations use ActualDistance, and not real DistanceToTarget, even for check for GunRange, so Goggles and Scope increase an actual range of Gun used, in their presence flashing cursor showing out-of-range tile could be misleading.

ShootingAccuracyBonus and ActualDistance used to calculate PrePenaltyShootingAccuracy together with TargetAccuracyPenalty:
[PrePenaltyShootingAccuracy = ShootingAccuracyBonus + (75 - ActualDistance)/3 - TargetAccuracyPenalty] (so in close shots, distance actually provide a bonus instead of penalty).

Target modify it, if Target is Merc, in case Target is a static object, TargetAccuracyPenalty is 0:
[TargetAccuracyPenalty = TargetPositionPenalty + TargetCamoPenalty + TargetEvadePenalty].
[TargetPositionPenalty = 20 for Crouched position (the only effect of Crouch in game, it doesnt affect Visibility (Tappers also treated as Crouched)) or (ActualDistance - 20)/3 for Prone or Swimming position if its more than 0 (TargetPositionPenalty cannot provide ChanceToHit bonus).
[TargetCamoPenalty = 5 if ActualDistance more than 75 (~5 tiles), and if Merc is at non-Building, non-Water tile (Bridges over Water treated as Water here)].
[TargetEvadePenalty = 5*(DefenceBonus + EvadeBonus - WeaponEvadePenalty{see stuff about Guns})] if its more than 0 (TargetEvadePenalty cannot provide ChanceToHit bonus).
TargetEvadePenalty is more complex, and i will put explanation of AIM option from Readme here:

AIM: controls the calculation of chance-to-hit regarding a bug caused by the carried on Action Points making the used formula heavily non-linear (while it adds a nice twist to the straight-forward to-hit formula, it also offers a possible exploitation by players)::
[DefenceBonus = (MaxAP*SquaresMoved)/(MaxAP-CurrentAP)]
or simply
[DefenceBonus = SquaresMoved]
in case CurrentAP is no less than MaxAP (preventing bad things happening with those carried on 5 AP).
Example: merc with 20 MaxAP also have a 5 carried on APs and move 2 squares on a road (cost 2 AP/square):
[DefenceBonus1 = 2]. {MaxAP (20) < CurrentAP (21), so only SquaresMoved matter}.
Now after a single next similar move, it suddenly turns into:
[DefenceBonus2 = (20*3)/(20-19) = 60], 30 times higher, effectively making a merc in question nearly impossible to hit beside the granted minimal 1% chance or point blank shot.
Enabling the AIM key changes that formula to a linear:
[DefenceBonus = (StartofTurnAP*SquaresMoved)/(StartofTurnAP-CurrentAP)]
when StartofTurnAP > CurrentAP, or:
[DefenceBonus = SquaresMoved]
when StartofTurnAP = CurrentAP.

If Target is CurrentlySee the Shooter in Own list (see Stuff about Interrupts) it provide EvadeBonus, otherwise EvadeBonus is 0:
[EvadeBonus = Agility/20 + ExpLevel/2]

PrePenaltyShootingAccuracy further modified by Damage and Breath penalties into FinalShootingAccuracy:
[FinalShootingAccuracy = (PrePenaltyShootingAccuracy - DamagePenalty) - BreathPenalty].
Penalties are shared between all 3 attack types, so ill write about them in their own part.

In case ActualDistance is more than 15*WeaponRange, the FinalShootingAccuracy is halved.
If FinalShootingAccuracy is less than 1 or more than 99 it set to an according closest valid value.

The FinalShootingAccuracy will be compared to Roll100, and if it will be more than Roll100, shot will fly using direct trajectory, and will hit the target in case of not hitting some objects during it. The chance of hitting to object will increase the farther the object is from Shooter (so Successful shot will pass through shrub next to the Shooter, but could hit a tree the Target standing behind 5 tiles further). Difference of FinalShootingAccuracy and Roll100 will also be used in calculation of damage dealt, so good Accuracy shots will deal more damage. Pointblank shot is a special case - it will always hit, but the difference of ShootingAccuracy and Roll100 will still affect a damage dealt.

-------------------------------------------------------------------------------------------------------------- -------------------------

Throwing Accuracy:
Used when any type of Grenade-like or Rock is thrown. ShootingAccuracy is complex due to heavy influence of Target on it, it is not the case in Throwing, where aiming is applied to hit a desired Tile instead (curiously, it means that its easier to evade a bullet than rock in JA1). Basic formula is simple too:
[BaseThrowingAccuracy = (Dexterity + Marksmanship)/2]. Condition of Throwing weapon not affect accuracy.
It further modified by AimLevel and additional bonus for SameTarget (same as during previous attack with that weapon drawn) and by EnemyDifficultyLevelBonus of [-1; 0; +1] if throw is performed by Enemy:
[ThrowingAccuracyBonus = BaseThrowingAccuracy + (AimLevel + SameTarget + EnemyDifficultyLevelBonus)*10].
In case Thrower is in process of bandaging, penalty of 20 is applied to ThrowingAccuracyBonus (but due to bug, only in 1.15).

Another important value used is a [DistanceToTarget ~ TilesToTarget*15], but with about half values used for tiles with Thrower and Target, and modified by SunGoggles weared by thrower to:
[ActualDistance = DistanceToTarget - DistanceToTarget/10].

Unlike Range of Gun, Thrown Range is not static and calculated from Merc's abilities:
[PrePenaltyThrowingRange = (CurrentHealth - 50 + 15*ThrowingObjectRange)/15]; (ThrowingObjectRange = 8 for all throwable objects in non-modded game)
and it further affected by Breath penalty:
[FinalThrowingRange = PrePenaltyThrowingRange - PrePenaltyThrowingRange*(100 - Breath)/200].

ThrowingAccuracyBonus and ActualDistance used to calculate PrePenaltyShootingAccuracy together with FinalThrowingRange:
[PrePenaltyThrowingAccuracy = ThrowingAccuracyBonus + FinalThrowingRange/2 - ActualDistance].
In case ActualDistance is more than FinalThrowingRange, the PrePenaltyThrowingAccuracy is halved (note, that halving there is prior applying of penalties, unlike in Shooting).

PrePenaltyThrowingAccuracy further modified by Damage and Breath penalties into FinalThrowingAccuracy:
[FinalThrowingAccuracy = (PrePenaltyThrowingAccuracy - DamagePenalty) - BreathPenalty].
Penalties are shared between all 3 attack types, so ill write about them in their own part.

If FinalThrowingAccuracy is less than 1 or more than 99 it set to an according closest valid value.

The FinalShootingAccuracy will be compared to Roll100, and if it will be less than Roll, thrown object will divert from a target Tile. Moreother, if FinalThrowingRange is less than DistanceToTarget (not ActualDistance, Goggles not increase real Throwing Range), thrown object will additionally divert from a target Tile, and it cannot land farther than FinalThrowingRange+1 in any case.

There should be one exception (perhaps too obvious to mention) to this, I think. Since a Stat cannot be less than 1, CriticalHit causes a reduction by Roll[Damage], but not greater than [Stat-1]. Whether it really works like that, that is for you to confirm. As far as I remember, I have had only one hint that it does: Kaboom went down to Wisdom=1. But I'm not sure if the message was correct (should be "...losing 12 points of wisdom").

19. I forgot about one thing. I have kept an old save (https://www.dropbox.com/s/xnrke3ofqf3jlzp/QUICK.SAV?dl=0) presenting a bug concerning Santino's chatacter. The game ends, but Santino remains seen (plus some explosives did not go off) and apparently lives happily ever after in his invincible state. If memory serves well, I have produced this by blowing up southern wall, then not spotting Santino in my turn, then spotting him in ememy turn. Something like that. It isn't anything serious, rather funny, but still a bug (as I cannot believe this would be an intended feature).

EDIT: I have just finished my game and tried to reproduce the above. It appears it has nothing to do with blowing southern wall. This happens when you spot Santino, but for some reason, he does not interrupt (like in this save :https://www.dropbox.com/s/kll3uh54sob3kng/QUICK.SAV?dl=0). Then he delivers his lines in enemy turn, detonates explosives, but not all of them, and lives.

20. Just a minor nuissance, but possibly a bug: between-day saves record all important options (like "fast anims") except for music. Music is always on, even after reload from save (that is, until I switch it off, then a reload would not switch music on). This does not concern quick.sav, in that case the music option is remembered.

Yes, ofc it work essentially the way you wrote. It was already a small offtopic tho, just added it as mentioned effect of various area hits anyway

Really excellent one, man, while i recalled that bug from years ago but been unable to recall the circumstances to reproduce. Its indeed about Santino noticing Merc during Enemy turn. While its not nearly as devastating as similar bug about noticing Brenda during Enemy turn could be, thats definitely worth fixing it for 1.15z (there is still a way to achieve similar result with "alive" Santino even after bugfix, so this curiosity will not be lost entirely).

Thats the way they definitely intentionally made it, they also reset Subtitle option. Is it of any real importance (i just play with sound off, so ive no idea)? Btw Quicksaves are generally preferrable, say in regular Saves they forgot to add a data about a number of sector with last successful Wallprobe use (it prevent the very next eavesdropping attempt the same sector, player have to achieve it in some other sector first), but to fix this one not really complex way means to ruin a savegame compatibility, so i left it out by now (im just do a quicksaves at beginning and at the end of day).

I checked subtitles and they are as saved after reload. Sound FX and music do not change after reload and are on on every launch. But all this is not of much importance, just a nuisance.

So they are preserved in regular save game? I never bothered to check, as they cannot be turned off without sound anyway.

Updated 2 places in Stuff about Interrupts, with italic and bold, didnt realized that 0AP and 1AP "turnings" works differently, and that Lucas Santino is a very buggy man.

Why play without sound at all? You can tell what guns they are firing by their sound.