Posted March 21, 2020
Ah yes, that did it. Thanks again for your quick help!
Eliazor
New User
Registered: Mar 2020
From Germany
DarzaR
New User
Registered: Sep 2013
From Russian Federation
Posted March 21, 2020
No, thanks all the way to you for finding it. Updated Readme to have a right settings mentioned there. As i use the Normal core only i totally overlooked it in tests (tho i still cannot reasonably explain why it do have that problem on Dynamic, but im not DOSbox expert in any sense). In case of some other problems or questions will arise, tell please.
Post edited March 21, 2020 by DarzaR
Ameryr
New User
Registered: Oct 2018
From United States
Posted March 24, 2020
I have the GOG version which is 1.13 I dragged the jay115.exe to the DOSBox shortcut it says problem reading the CD rom.
How to solve this.
How to solve this.
DarzaR
New User
Registered: Sep 2013
From Russian Federation
Posted March 24, 2020
You need to mount the disc image in DOSbox autoexec too. Alternatively, easiest way is to change ja.exe to jay115.exe in GOG config. Actually early part of Readme is about installation, better to read it first.
DarzaR
New User
Registered: Sep 2013
From Russian Federation
Posted July 12, 2020
After reading some questions by some reading-impaired people on some other game-selling place about JA, i decided what covering some water-related mechanics (thus answering one of questions there) is pretty worthy on its own, so i did wrote some stuff about it. Possible covering of other questions from there is depends on ability of reading of one who's asking (as ofc there is no point in asking about a question and not reading an answer to it).
"1. Swimming
There's a lot of conditions to avoid drown or be killed by a snake, from my experience it's hard to reach a 100% guaranty.
- The mercenary is important, some sim badly; some swim very well.
- Have in right hand knife, you can equip the knife once the fight with a snake started, but it will lower your chance.
- Have in inventory a canteen, two canteen would be a maximal care. The point is here is during the real time snake combat, even in turn based, you can open mercenary inventory and make him drink water to refill breath bar, I'd say do it before it reach 60%.
- Minimize the swimming path, don't believe the pathfinding of the game, experiment and vary the start points. A walk in water without swimming is zero danger. The mercenary will never drown, but also I never seen a snake attack.
- Unequip the armor, particularly Spectra Armor. I think you can put it left hand but not sure. What Im' sure is even Ivan which is probably the best swimmer can drown/be drowned by a snake, but he was wearing a Spectra armor.
I'm' not sure yet that apply all tricks can guaranty a safe result, for some mercenaries."
1. Swimming
Some theory not touched in actual questions below is better to be mentioned still.
There are a few dangers from the water (bridges, located on water, sometimes counterintuitively treated as water still in game):
1. Inability to use items, unless on a bridge.
2. Ceasing a Camo effect on a water tiles, even on a bridge.
3. Drowning due to out of breath, in case of swimming only (not on bridge, not while walking in any shallow), possibly leading to a death of merc.
4. Snake attacks, only during swimming or walking in "deep shallow", possibly leading to a death of merc.
1&2 are pretty selfexplanatory, 3&4 will require some words about.
3. Normally AP >5 left at the end of previous turn cause a breath increase at the beginning of turn. Exception here is swimming, where they are actually cause an additional lose of breath. Thats it, counterintuitively its optimal to spend all AP while swimming. There is no way to gain breath during swimming except canteens, even non-moving in "resting" animation will still cause a losing of breath in deep water. Losing a breath to 0 will not cause a collapse like on a dry ground. Drowning due to lack of breath (process, totally unrelated to snakes) is not happening in shallow water of both types at all, as intentional decision of authors (so, counterintuitively, merc with 0 breath can freely walk for any amount of turns in shallow water, while would be collapsed to ground on a dry earth, and had to wait for breath to restore to be able walk again). In deeper water, it will not cause immediate drowning too, but instead of it 2+roll[0-9]+roll[0-9] damage will be dealt every new turn or every tile drowning merc will move (as being out of breath not causing collapse in water, merc still can move), with that damage doubled for mercs with Non-swimmer trait. Merc will actually drown only when will have a less than 1 HP (yes, incapacitated due to HP<15 mercs still will be floating yet, while not being able to move anymore).
4. Snakes attacks happens during beginning of turn, or when merc is moving, in case condition of being (for beginning of turn) or moving to (for move) deep water or deep shallow water is met, and roll of sector-tied value is succeed. For example, chance for S34 (river with "snake-infested waters") is 1/5 (tied as most probable in game), while chance for S60 (home sector) is 1/20 (tied as least probable in game). In addition to it, Metavira Natives will have that attack chance to be 5 times less probable during moving (but not at the beginning of the turn). To complicate things slightly, game is drawing snake attack animation to happen on a tile, merc is moving from, while actual attack is happens on destination tile. So, in case of moving from very shallow water tile to a deeper waters one, and triggering a snake attack, it would looks like as if attack happens on very shallow tile, contrary to info above. Thats the way game is work, trigger is about type of tile to move AT or staying ON, not about moving FROM, despite misleading visuals. Snakes, being drawn swimming around have no direct connection to actual attack, tho frequencies of their appearing is related to a same sector-tied chance (in short: there are no some actual snakes in waters, only tile based chance to snake to appear).
There's a lot of conditions to avoid drown or be killed by a snake, from my experience it's hard to reach a 100% guaranty.
- The mercenary is important, some sim badly; some swim very well.
Its not hard, its impossible, as no matter conditions, there's always 5% chance to be killed by snake. Drowning, on the other hand is way simpler: merc will start to drown next turn or move after receiving warning about, err, drowning, caused by dropping breath to 0 (note: non-swimmer trait cause breath to drop faster than usual by swimming).
- Have in right hand knife, you can equip the knife once the fight with a snake started, but it will lower your chance.
Formula for roll vs snake is:
RvsS = [(Health + BandagedHealth/2)*Breath/100 - (100 - Dext)/4]
further modified by having a knife in active hand [RvsS + 80% if knife or +0% otherwise] and additional +40% for being Native or Enemy.
In case final RvsS value is above 95, its set at 95.
Then roll[100] is made vs it, and if higher, the snake won and merc is dying.
Beside is, there is special roll for auto-equipping knife from the other slot:
[Dexterity vs roll[100]]
this roll should succeed twice in a row to move a knife to main hand (so merc with Dex100 with always re-equip knife, and merc with Dex50 will do so 1/4 of times).
Being a Native or Enemy will cause this roll to always succeed.
Type or condition of knife is not affect snake battle.
Moreother, winning the snake battle without knife treated as "wrong way", and merc will suffer a roll[0-29] hit and get less exp rolls for the winning. So yes, strongly preferred to have a knife in active hand, and autoequip is not something to rely on. Statement about "it will lower your chance" about manual equipping after the snake animation had started is just a fantasy, as knife location do matter only at the moment of actual roll, so its even possible to have a single knife for a whole group of mercs to pass it to one in need, assuming they swim together (its not preferred tho).
- Have in inventory a canteen, two canteen would be a maximal care. The point is here is during the real time snake combat, even in turn based, you can open mercenary inventory and make him drink water to refill breath bar, I'd say do it before it reach 60%.
Having canteens in disposal is right, "two as maximal" is baseless assumption, as well as "before it reach 60%". Correct statement would be "as much as needed", as 60% is very unreliably low, danger is too high already, so max possible breath is preferred. Beside it, after attack started, there is a 1/5 chance in process instead of "stab" roll to happen (ending the battle), to battle animation to resume again (ones, who played enough ofc noticed that sometimes battle take more time), resulting in spending more breath in process. Thus player cannot predict the amount of breath to be spent, so guessing about "maximal care" such way is wrong. Actual "maximal care" here would be "all canteens possible to collect in game".
- Minimize the swimming path, don't believe the pathfinding of the game, experiment and vary the start points. A walk in water without swimming is zero danger. The mercenary will never drown, but also I never seen a snake attack.
Partially right, game is trying to chose a fastest route. "A walk in water" is not zero danger tho, as there is 3 types of "water tiles", not 2:
Very shallow water - 6/8 AP/tile, about knee-deep animation, no snake attacks.
Shallow water - 7 AP/tile, about waist-deep animation, snake attacks.
Deep water - 7 AP/tile, swimming animation, snake attacks.
So yes, game could make a shorter path with danger to snakes instead of possible slower and safe one. About damage and drowning see above.
- Unequip the armor, particularly Spectra Armor. I think you can put it left hand but not sure. What Im' sure is even Ivan which is probably the best swimmer can drown/be drowned by a snake, but he was wearing a Spectra armor.
Thats a pure fantasy, there is no weight of items in JA1, and from all the items only knives have an effect on snakes. Also as we can see from the info above "best swimmer" is Elio, not Ivan.
- I'm' not sure yet that apply all tricks can guaranty a safe result, for some mercenaries.
As no trick beside reloading could guarantee a 100% safe result here, its strongly recommended to swim as few as possible (id say its really needed only in Brenda mission and S27 plant). There is 2 not mentioned exploits to increase a chance tho (they could be treated as unfair, as they likely are overlooks of designers):
1. Traverse out of sector. Fighting a snake not treated as condition preventing traverse, so in case other conditions for it is met, team could go freely, stopping snake attack in process.
2. Swapping the mercs by X button. Works better in real-time mode, and only one of many possible exploits of overall mighty and broken Swap-by-X mechanic. Will break attack sequence for a swapped-out merc, and will not reinitialize it for a swapped-in merc.
"1. Swimming
There's a lot of conditions to avoid drown or be killed by a snake, from my experience it's hard to reach a 100% guaranty.
- The mercenary is important, some sim badly; some swim very well.
- Have in right hand knife, you can equip the knife once the fight with a snake started, but it will lower your chance.
- Have in inventory a canteen, two canteen would be a maximal care. The point is here is during the real time snake combat, even in turn based, you can open mercenary inventory and make him drink water to refill breath bar, I'd say do it before it reach 60%.
- Minimize the swimming path, don't believe the pathfinding of the game, experiment and vary the start points. A walk in water without swimming is zero danger. The mercenary will never drown, but also I never seen a snake attack.
- Unequip the armor, particularly Spectra Armor. I think you can put it left hand but not sure. What Im' sure is even Ivan which is probably the best swimmer can drown/be drowned by a snake, but he was wearing a Spectra armor.
I'm' not sure yet that apply all tricks can guaranty a safe result, for some mercenaries."
1. Swimming
Some theory not touched in actual questions below is better to be mentioned still.
There are a few dangers from the water (bridges, located on water, sometimes counterintuitively treated as water still in game):
1. Inability to use items, unless on a bridge.
2. Ceasing a Camo effect on a water tiles, even on a bridge.
3. Drowning due to out of breath, in case of swimming only (not on bridge, not while walking in any shallow), possibly leading to a death of merc.
4. Snake attacks, only during swimming or walking in "deep shallow", possibly leading to a death of merc.
1&2 are pretty selfexplanatory, 3&4 will require some words about.
3. Normally AP >5 left at the end of previous turn cause a breath increase at the beginning of turn. Exception here is swimming, where they are actually cause an additional lose of breath. Thats it, counterintuitively its optimal to spend all AP while swimming. There is no way to gain breath during swimming except canteens, even non-moving in "resting" animation will still cause a losing of breath in deep water. Losing a breath to 0 will not cause a collapse like on a dry ground. Drowning due to lack of breath (process, totally unrelated to snakes) is not happening in shallow water of both types at all, as intentional decision of authors (so, counterintuitively, merc with 0 breath can freely walk for any amount of turns in shallow water, while would be collapsed to ground on a dry earth, and had to wait for breath to restore to be able walk again). In deeper water, it will not cause immediate drowning too, but instead of it 2+roll[0-9]+roll[0-9] damage will be dealt every new turn or every tile drowning merc will move (as being out of breath not causing collapse in water, merc still can move), with that damage doubled for mercs with Non-swimmer trait. Merc will actually drown only when will have a less than 1 HP (yes, incapacitated due to HP<15 mercs still will be floating yet, while not being able to move anymore).
4. Snakes attacks happens during beginning of turn, or when merc is moving, in case condition of being (for beginning of turn) or moving to (for move) deep water or deep shallow water is met, and roll of sector-tied value is succeed. For example, chance for S34 (river with "snake-infested waters") is 1/5 (tied as most probable in game), while chance for S60 (home sector) is 1/20 (tied as least probable in game). In addition to it, Metavira Natives will have that attack chance to be 5 times less probable during moving (but not at the beginning of the turn). To complicate things slightly, game is drawing snake attack animation to happen on a tile, merc is moving from, while actual attack is happens on destination tile. So, in case of moving from very shallow water tile to a deeper waters one, and triggering a snake attack, it would looks like as if attack happens on very shallow tile, contrary to info above. Thats the way game is work, trigger is about type of tile to move AT or staying ON, not about moving FROM, despite misleading visuals. Snakes, being drawn swimming around have no direct connection to actual attack, tho frequencies of their appearing is related to a same sector-tied chance (in short: there are no some actual snakes in waters, only tile based chance to snake to appear).
There's a lot of conditions to avoid drown or be killed by a snake, from my experience it's hard to reach a 100% guaranty.
- The mercenary is important, some sim badly; some swim very well.
Its not hard, its impossible, as no matter conditions, there's always 5% chance to be killed by snake. Drowning, on the other hand is way simpler: merc will start to drown next turn or move after receiving warning about, err, drowning, caused by dropping breath to 0 (note: non-swimmer trait cause breath to drop faster than usual by swimming).
- Have in right hand knife, you can equip the knife once the fight with a snake started, but it will lower your chance.
Formula for roll vs snake is:
RvsS = [(Health + BandagedHealth/2)*Breath/100 - (100 - Dext)/4]
further modified by having a knife in active hand [RvsS + 80% if knife or +0% otherwise] and additional +40% for being Native or Enemy.
In case final RvsS value is above 95, its set at 95.
Then roll[100] is made vs it, and if higher, the snake won and merc is dying.
Beside is, there is special roll for auto-equipping knife from the other slot:
[Dexterity vs roll[100]]
this roll should succeed twice in a row to move a knife to main hand (so merc with Dex100 with always re-equip knife, and merc with Dex50 will do so 1/4 of times).
Being a Native or Enemy will cause this roll to always succeed.
Type or condition of knife is not affect snake battle.
Moreother, winning the snake battle without knife treated as "wrong way", and merc will suffer a roll[0-29] hit and get less exp rolls for the winning. So yes, strongly preferred to have a knife in active hand, and autoequip is not something to rely on. Statement about "it will lower your chance" about manual equipping after the snake animation had started is just a fantasy, as knife location do matter only at the moment of actual roll, so its even possible to have a single knife for a whole group of mercs to pass it to one in need, assuming they swim together (its not preferred tho).
- Have in inventory a canteen, two canteen would be a maximal care. The point is here is during the real time snake combat, even in turn based, you can open mercenary inventory and make him drink water to refill breath bar, I'd say do it before it reach 60%.
Having canteens in disposal is right, "two as maximal" is baseless assumption, as well as "before it reach 60%". Correct statement would be "as much as needed", as 60% is very unreliably low, danger is too high already, so max possible breath is preferred. Beside it, after attack started, there is a 1/5 chance in process instead of "stab" roll to happen (ending the battle), to battle animation to resume again (ones, who played enough ofc noticed that sometimes battle take more time), resulting in spending more breath in process. Thus player cannot predict the amount of breath to be spent, so guessing about "maximal care" such way is wrong. Actual "maximal care" here would be "all canteens possible to collect in game".
- Minimize the swimming path, don't believe the pathfinding of the game, experiment and vary the start points. A walk in water without swimming is zero danger. The mercenary will never drown, but also I never seen a snake attack.
Partially right, game is trying to chose a fastest route. "A walk in water" is not zero danger tho, as there is 3 types of "water tiles", not 2:
Very shallow water - 6/8 AP/tile, about knee-deep animation, no snake attacks.
Shallow water - 7 AP/tile, about waist-deep animation, snake attacks.
Deep water - 7 AP/tile, swimming animation, snake attacks.
So yes, game could make a shorter path with danger to snakes instead of possible slower and safe one. About damage and drowning see above.
- Unequip the armor, particularly Spectra Armor. I think you can put it left hand but not sure. What Im' sure is even Ivan which is probably the best swimmer can drown/be drowned by a snake, but he was wearing a Spectra armor.
Thats a pure fantasy, there is no weight of items in JA1, and from all the items only knives have an effect on snakes. Also as we can see from the info above "best swimmer" is Elio, not Ivan.
- I'm' not sure yet that apply all tricks can guaranty a safe result, for some mercenaries.
As no trick beside reloading could guarantee a 100% safe result here, its strongly recommended to swim as few as possible (id say its really needed only in Brenda mission and S27 plant). There is 2 not mentioned exploits to increase a chance tho (they could be treated as unfair, as they likely are overlooks of designers):
1. Traverse out of sector. Fighting a snake not treated as condition preventing traverse, so in case other conditions for it is met, team could go freely, stopping snake attack in process.
2. Swapping the mercs by X button. Works better in real-time mode, and only one of many possible exploits of overall mighty and broken Swap-by-X mechanic. Will break attack sequence for a swapped-out merc, and will not reinitialize it for a swapped-in merc.
Post edited August 01, 2020 by DarzaR
DarzaR
New User
Registered: Sep 2013
From Russian Federation
Posted August 02, 2020
While info on JA1 outside those stuffs is pretty close to non-existence, there is at least couple of easy to find counter-to-some-extent-examples: some old and good for its times, but pretty obsolete by now guide of mid-90s; and page by Blueskirt, containing data from the book Jagged Alliance Strategy Guide by the great Brenda Garno.
https://www.gog.com/forum/jagged_alliance_series/jagged_alliance_1_strategy_guide/post85
blueskirt42
It's not that holy grail to be honest, you've got a chart of all character statistics, including the hidden ones, which I uploaded on the Jagged Alliance Wikia a bunch of years ago.
http://jaggedalliance.wikia.com/wiki/List_of_mercenaries_in_Jagged_Alliance
As this page contains a really useful and structured data its of a really good value. Sadly, it also contains some misleading info aswell, partially because of wrong data in book itself, but also sometimes due to wrong interpretation by page author. So i decided to provide an edited and more full explanations to the table values there, upgrading it to a better usability. As i dont want those edits to appear on Jawiki, ill post them here, providing the link to main page in Blueskirt's quote. Those edits are based on page's revision of June 3 2019 (even in case it will be edited later, its possible to refer to certain given revision in case in change history).
As this stuff will be mostly about game formulae used to calculate the values from the tables, ill add a mention of another obscure (and worthy some stuff on its own) mechanic possible affecting them - Breath. Most often it modify the calculated value as a simple percentage [FinalValue = Value*Breath/100], but there could be also other factors to affect it beside. Other difficulty with Breath is inability to check its actual value by in-game methods. But as knowing if Breath affect a given calculation or not is useful even in "compact description" i'll mention it in comment to a values being explained below (ofc course Breath could affect only field-based mechanics).
All the values in tables are listed for a given merc with not changed starting stats and full breath. Note that i didnt checked all the actual numbers in tables, and, while i will mention some wrong ones i did notice, it doesnt means that not-mentioned ones assumed as having a right values.
Note, that all calculations below are in whole numbers.
--------------------------------------------------------------------------------
"APs: Shows how many action points a fully healed and fully rested mercenary can regenerate in one turn. Also remember that up to five unspent action points can carry over from a previous turn."
Good one to start with:
[CurrentMaxAP = (MaxHealth + 2*Agility + Dexterity + 10*ExpLevel + 10)/20] Affected by Breath.
Min AP is 8, max is 25.
Note, that due to game bug AP value is also penalized by BandagedHealth, instead of being benefited from it. Command line option HEALTHY of patch 1.15 provide an optional fix for it. For more info about Command line options see patch 1.15 Readme.
--------------------------------------------------------------------------------
"Traits: Shows tendencies a mercenary has:"
Merc could have only one trait.
No trait: no trait-related effects.
"Extremely Nervous: Will whine if not accompanied at all time."
This one is very simple and correct: once per every game hour, merc with this trait will complain in a message if not having an other merc in 5 tiles radius. No other game effect.
"Forgetful: Will forget orders at the cost of APs."
Have a 1/15 chance to stop per tile, but only if amount of tiles already passed for a given route command is more than 5 in turn-based or than 15 in real-time (so there is 0 chance to stop for tiles 1-5; 1/15 chance for tile 6; 1/15 chance for tile 7 and so on). In case of triggered stop in turn-based, merc will also lose AP's equal to roll from remaining AP's at the moment of stop (for example 100% 1 AP in case of 1 AP; 50% for 1 AP and 50% for 2 AP in case of 2 AP and so on). Exploitable, as player can easily prevent a trigger by ordering move not further than 5 tiles at time. Require attention in real-time tho, as stopping in a bridge would likely causing mercs who follow Forgetful one to try to went water instead, as a new possible route.
"Hopeless Shot: Marksmanship improvement is a great challenge."
Very simple one too: the calculated chance for an experience roll for Marksmanship is divided by 5. No other game effect.
"Snitch: Will report on any dissatisfaction your team might have with your management. Although unrelated, in Jagged Alliance, mercenaries with this trait are extremely loyal and won't steal money found on the battlefield. This is not always the case in Deadly Games."
Will simulate for every other merc a check for Fatality (called as Death in table), Turnover, Non-Payment, and Fail rates as if its already a next day, and rates values increased on 1 each. In case merc will reach the amount to complain, Snitch will report it with message. While Snitch in charge at current day will not report about self, having more than one Snitch in team would lead to choosing one of them in random over course of days to work.
Dont know about Deadly Games, or from what idea about "although unrelated" appeared, but in JA1 Snitch trait directly affect if the merc in question will steal money or not. While Snitches also technically have a need to get a hand on a cash 99 times their salary to steal, and while its not really possible in non-modded game, even if you will modify the steal value or salary of a given Snitch merc - that merc still will not steal any money. Because being Snitch (or Native) is directly related to it - to not steal money they carry no matter the sum.
"Heat Resistant: Unaffected by the heat waves that randomly rolls on Metavira.
Native Guide: Native Guides are free of charge, give tidbits of info on the various sectors of Metavira, are unaffected by heat waves, receive bonus to avoid and kill Metaviran water snakes, are familiar with the Metaviran natives' language and are extremely loyal. Death or discharge of Native Guides do not affect A.I.M. death and turnover rates."
Now its the complicated case. Those two traits mentioned above is an one trait in reality + some special treatment of certain mercs (Native Guides). I dont know why Blueskirt separated them this way, as the Book call them both "Heat Resistant". As i have to use other name for this trait ill try "Native" (probably "South-Atlantic Native" would suit more, as both Venezuela and Metavira fit it). To clarify effects of it, separation of actual "Native" trait and "Native Guide" is required:
Native trait (Elio, Hamous, Juan, Wahan, Hector + Guards + Tappers):
Not unaffected, but suffer 5 times less penalty from HeatWave (extra hot day).
Will not steal money (see Snitch above).
Native Guide (Elio, Hamous, Juan, Wahan):
Will provide info about sectors they currently are (note: not all sectors have messages, attributed to them).
Will translate a message on Metavirean from the Note in their inventory.
Additionally, all non-AIM personnel (NativeGuides, Guards, Enemies):
Will have a 5 times lower chance to be attacked by a WaterSnake when moving.
Will always re-equip a knife if attacked, and will get +40% bonus to roll VS snake.
"Non-Swimmer: Don't know how to swim and will rapidly lose their breath while swimming."
Indeed, will spend 5 time more Breath while swimming. Also will suffer double damage while drowning.
"Over Enthusiastic: Will refuse to move or change target once they're engaged with an enemy. Have the tendency to kill teammates they dislike at night."
The most complicated trait. Maniac (to shorten it) effects include:
Will refuse to move or change target if target is merc (no matter enemy or not), and that target is on the same tile still, that it was on when was chosen as target (so if target will move from initial tile it will cease Maniac effect), and if Maniac have a read-to-use weapon in main hand (so empty or jammed/broken gun will cease Maniac effect). Could be exploited to cease by removing a weapon from active hand or, as a way milder exploit, via swap-by-X (will not cease effect, but still move Maniac to other tile).
Will not forget own target when suffer a hit - so will keep a bonus of "firing the previous target". Non-Maniac mercs would still keep their weapons readied in this case, but would "lose concentration" on their target.
Will not complain if got friendly merc as a target.
Will generate more noise when moving (originally only when trying to Sneak, then changed to all cases by Sir-tech official patches somewhere prior v 1.13).
Will join player's team even if merc, hated by Maniac, is there, and will comment it with a threat.
Will kill the hated merc at the morning.
Will not care about other mercs being fired or dumped to a river.
"Wimpy Conscience: This merc will quit the team and resign from A.I.M. as soon he kills someone on the battlefield."
Strictly speaking not "as soon he kills someone", but "the evening of day he kills someone". Despite invoking a Bribe process, actually cannot be bribed to stay. Still affect Turnover rate.
--------------------------------------------------------------------------------
"IMP: "Yes" indicates this mercenary can improve his or her attributes and skills either on the battlefield or through training. "No" means this merc cannot improve his or her abilities in any ways, and "Reverse" indicates this merc is a hopeless case whose abilities can only go downhill."
Looks very good by me.
https://www.gog.com/forum/jagged_alliance_series/jagged_alliance_1_strategy_guide/post85
blueskirt42
It's not that holy grail to be honest, you've got a chart of all character statistics, including the hidden ones, which I uploaded on the Jagged Alliance Wikia a bunch of years ago.
http://jaggedalliance.wikia.com/wiki/List_of_mercenaries_in_Jagged_Alliance
As this stuff will be mostly about game formulae used to calculate the values from the tables, ill add a mention of another obscure (and worthy some stuff on its own) mechanic possible affecting them - Breath. Most often it modify the calculated value as a simple percentage [FinalValue = Value*Breath/100], but there could be also other factors to affect it beside. Other difficulty with Breath is inability to check its actual value by in-game methods. But as knowing if Breath affect a given calculation or not is useful even in "compact description" i'll mention it in comment to a values being explained below (ofc course Breath could affect only field-based mechanics).
All the values in tables are listed for a given merc with not changed starting stats and full breath. Note that i didnt checked all the actual numbers in tables, and, while i will mention some wrong ones i did notice, it doesnt means that not-mentioned ones assumed as having a right values.
Note, that all calculations below are in whole numbers.
--------------------------------------------------------------------------------
"APs: Shows how many action points a fully healed and fully rested mercenary can regenerate in one turn. Also remember that up to five unspent action points can carry over from a previous turn."
Good one to start with:
[CurrentMaxAP = (MaxHealth + 2*Agility + Dexterity + 10*ExpLevel + 10)/20] Affected by Breath.
Min AP is 8, max is 25.
Note, that due to game bug AP value is also penalized by BandagedHealth, instead of being benefited from it. Command line option HEALTHY of patch 1.15 provide an optional fix for it. For more info about Command line options see patch 1.15 Readme.
--------------------------------------------------------------------------------
"Traits: Shows tendencies a mercenary has:"
Merc could have only one trait.
No trait: no trait-related effects.
"Extremely Nervous: Will whine if not accompanied at all time."
This one is very simple and correct: once per every game hour, merc with this trait will complain in a message if not having an other merc in 5 tiles radius. No other game effect.
"Forgetful: Will forget orders at the cost of APs."
Have a 1/15 chance to stop per tile, but only if amount of tiles already passed for a given route command is more than 5 in turn-based or than 15 in real-time (so there is 0 chance to stop for tiles 1-5; 1/15 chance for tile 6; 1/15 chance for tile 7 and so on). In case of triggered stop in turn-based, merc will also lose AP's equal to roll from remaining AP's at the moment of stop (for example 100% 1 AP in case of 1 AP; 50% for 1 AP and 50% for 2 AP in case of 2 AP and so on). Exploitable, as player can easily prevent a trigger by ordering move not further than 5 tiles at time. Require attention in real-time tho, as stopping in a bridge would likely causing mercs who follow Forgetful one to try to went water instead, as a new possible route.
"Hopeless Shot: Marksmanship improvement is a great challenge."
Very simple one too: the calculated chance for an experience roll for Marksmanship is divided by 5. No other game effect.
"Snitch: Will report on any dissatisfaction your team might have with your management. Although unrelated, in Jagged Alliance, mercenaries with this trait are extremely loyal and won't steal money found on the battlefield. This is not always the case in Deadly Games."
Will simulate for every other merc a check for Fatality (called as Death in table), Turnover, Non-Payment, and Fail rates as if its already a next day, and rates values increased on 1 each. In case merc will reach the amount to complain, Snitch will report it with message. While Snitch in charge at current day will not report about self, having more than one Snitch in team would lead to choosing one of them in random over course of days to work.
Dont know about Deadly Games, or from what idea about "although unrelated" appeared, but in JA1 Snitch trait directly affect if the merc in question will steal money or not. While Snitches also technically have a need to get a hand on a cash 99 times their salary to steal, and while its not really possible in non-modded game, even if you will modify the steal value or salary of a given Snitch merc - that merc still will not steal any money. Because being Snitch (or Native) is directly related to it - to not steal money they carry no matter the sum.
"Heat Resistant: Unaffected by the heat waves that randomly rolls on Metavira.
Native Guide: Native Guides are free of charge, give tidbits of info on the various sectors of Metavira, are unaffected by heat waves, receive bonus to avoid and kill Metaviran water snakes, are familiar with the Metaviran natives' language and are extremely loyal. Death or discharge of Native Guides do not affect A.I.M. death and turnover rates."
Now its the complicated case. Those two traits mentioned above is an one trait in reality + some special treatment of certain mercs (Native Guides). I dont know why Blueskirt separated them this way, as the Book call them both "Heat Resistant". As i have to use other name for this trait ill try "Native" (probably "South-Atlantic Native" would suit more, as both Venezuela and Metavira fit it). To clarify effects of it, separation of actual "Native" trait and "Native Guide" is required:
Native trait (Elio, Hamous, Juan, Wahan, Hector + Guards + Tappers):
Not unaffected, but suffer 5 times less penalty from HeatWave (extra hot day).
Will not steal money (see Snitch above).
Native Guide (Elio, Hamous, Juan, Wahan):
Will provide info about sectors they currently are (note: not all sectors have messages, attributed to them).
Will translate a message on Metavirean from the Note in their inventory.
Additionally, all non-AIM personnel (NativeGuides, Guards, Enemies):
Will have a 5 times lower chance to be attacked by a WaterSnake when moving.
Will always re-equip a knife if attacked, and will get +40% bonus to roll VS snake.
"Non-Swimmer: Don't know how to swim and will rapidly lose their breath while swimming."
Indeed, will spend 5 time more Breath while swimming. Also will suffer double damage while drowning.
"Over Enthusiastic: Will refuse to move or change target once they're engaged with an enemy. Have the tendency to kill teammates they dislike at night."
The most complicated trait. Maniac (to shorten it) effects include:
Will refuse to move or change target if target is merc (no matter enemy or not), and that target is on the same tile still, that it was on when was chosen as target (so if target will move from initial tile it will cease Maniac effect), and if Maniac have a read-to-use weapon in main hand (so empty or jammed/broken gun will cease Maniac effect). Could be exploited to cease by removing a weapon from active hand or, as a way milder exploit, via swap-by-X (will not cease effect, but still move Maniac to other tile).
Will not forget own target when suffer a hit - so will keep a bonus of "firing the previous target". Non-Maniac mercs would still keep their weapons readied in this case, but would "lose concentration" on their target.
Will not complain if got friendly merc as a target.
Will generate more noise when moving (originally only when trying to Sneak, then changed to all cases by Sir-tech official patches somewhere prior v 1.13).
Will join player's team even if merc, hated by Maniac, is there, and will comment it with a threat.
Will kill the hated merc at the morning.
Will not care about other mercs being fired or dumped to a river.
"Wimpy Conscience: This merc will quit the team and resign from A.I.M. as soon he kills someone on the battlefield."
Strictly speaking not "as soon he kills someone", but "the evening of day he kills someone". Despite invoking a Bribe process, actually cannot be bribed to stay. Still affect Turnover rate.
--------------------------------------------------------------------------------
"IMP: "Yes" indicates this mercenary can improve his or her attributes and skills either on the battlefield or through training. "No" means this merc cannot improve his or her abilities in any ways, and "Reverse" indicates this merc is a hopeless case whose abilities can only go downhill."
Looks very good by me.
Post edited August 02, 2020 by DarzaR
DarzaR
New User
Registered: Sep 2013
From Russian Federation
Posted August 02, 2020
"It's worth noting that although rivalries between mercenaries exist in the first Jagged Alliance game, friendship between mercs have not been implemented in this early chapter. Instead, every time a merc is treated unjustly (fired, non-payment, body tossed into the river, etc.) one or two random mercenaries may (or may not) hear about your misconducts. If this happen, these mercenaries will only accept to work for you at double their salaries. However, if they learn you toss bodies into the river, no amount of money will make these mercenaries work for you."
Thats not very true. Actually only Firing and RiverBurial are of matter in this context. About Non-Payment related bugs and fixes refer patch 1.15 Readme (no matter those bugs it still would be out of context here anyway tho). So cases are:
Fire a merc. When a non-Guide, already joined a team, merc is fired (its of no penalty to "hire/fire/rehire etc" somebody while that somebody hadnt yet brought to island by a copter):
That merc will leave, handling all his/her equipment to player and will refuse to ever join back later.
Depending on days the fired merc was employed amount of rolls to "set buddies" is generated. In case of merc fired very same day as arrival amount is 4. In other cases amount is randomly chosen 1, 2, or 3, but only if roll of amount of days merc was employed above first one is "won" (so merc, fired after 2 days will have 100% chance to generate 1-3 "buddy rolls"; fired after 3 days 50% chance; after 4 days 33% chance, and so on). "Buddy rolls" are not guaranteed to succeed tho. Each roll chose a one from 60 mercenaries, but to become Buddy, that merc have to meet several criteria:
Not be that currently fired merc;
Not be currently employed in player's team;
Not have a Maniac trait;
Not have a Buddy already;
Not Hate the currently fired merc (this one is very exploitable, say player can fire Kaboom and be sure it will not affect Magic, making Kaboom very strong for the first day).
Not be a Wink Dickerson.
In case any of criteria fail, that "buddy roll" is used up. So, its not "one or two", but "up to four" mercs, who could randomly turn into buddies, demanding a salary doubled.
Note: the info above is valid for v.1.13+, as Sir-tech official patches somewhere prior it changed behavior to described from:
Amount of "buddy rolls" are always randomly 1, 2, or 3, but days employed-based roll cannot have a chance lower than 25% (so merc fired after 5 days or 20 days have the same chance to complain, unlike later version). Also likely during that change Wink's unique case has been added, as original game ver1.0 had him as a valid Buddy. Thats make Wink the most special of all the mercs, the only one, who got own hardcoded check, beside NativeGuides (who also have them not personally, but as Guides only).
Toss merc to a river. When a non-Guide merc(s) is/are dead, and player not order a helicopter to take bodies out:
Per each RiverBuried body roll to determine 1 or 2 "set enraged" is generated. Each roll is also chose a one from 60 mercenaries, but have some differences to BuddyFired mechanic. The merc, chosen by roll should also meet several criteria:
Not have a Maniac trait;
Not be in Enraged state already;
Not hate that RiverBuried merc.
Depending on status of employment of Enraged merc there is a difference tho, as, unlike Buddy roll, merc, who is currently in team, also could be Enraged. Thus it lead to 2 different effects:
Enraged merc is currently not in team: that merc will never agree to join a player's team from now.
Enraged merc is currently in team: that merc will complain about RiverBurial, but could be Bribed to change own mind about it (so will stay in team if bribed successfully).
Note what both Buddy and Enraged rolls doesnt specially check for dead mercs, so actually they could be wasted on dead (or already fired, so unavailable anyway) mercs too, reducing the chance even more.
--------------------------------------------------------------------------------
"Hirable: Indicates how many days must have passed, or how many success points you must have collected before this mercenary accepts to work for you. Success points are scored by getting positive ratings from Jack at the end of a day (Good is worth 1 point; Excellent is worth 2 points; Outstanding is worth 3 points.)"
One of most dangerously misleading parts. The described mechanic is correct only for Go Ahead difficulty setting of patch 1.15. In regular game, due to odd designers decision, or maybe due to bug, Success Points amount per day have no hard limit set (while Jack indeed have his messages only up to +-3 points). So, while Excellent is indeed always worth 2 points, Outstanding could mean 3 points, or 12 points (important to earn at day 1 to be able to hire Magic) or 19 points (possible on day 1 on Hard with 11 sectors won). Refer to Readme of patch 1.15 for more detailed explanation. Every day's end, DaySuccessPoints are added to SuccessPoint amount, used to check if merc in question will or will not agree to join.
[DaySuccessPoints =
(10*{Difference_of_ProcessingPlants_amount_of_the_day} +
5*Difference_of_SectorsOwned_amount_of_the_day} +
{Difference_of_TreesOwned_amount_of_the_day} +
{Difference_of_TreesSafetoTap_amount_of_the_day} +
{Difference_of_TreesTapped_amount_of_the_day} +
#Enemies_killed_during_the_day -
#Natives_killed_during_the_day -
5*#Mercs_killed_during_the_day)/10, rounded up]
For very late game days (50 and more) there is additional penalties.
Having a negative DaySuccessPoint cause a Fail value to increase. Amassing a 5 Fail points causing a loss of game. Any day player have a non-negative DaySuccessPoints amount tho, Fail points are set back to 0 (even 0 DaySuccessPoints will do a work).
--------------------------------------------------------------------------------
"Native guides are hired in a special way. If you have one free slot in your team at the start of the day, Jack might offers you one of his four trusted assistants to accompany you on the field. The first one of these will be Elio, then Hamous, Juan and finally Wahan. Elio will not be offered until Day 2, and all subsequent guides will be offered only two days after the previous guide has been fired or killed. Please note that it is entirely random whether Jack will offer you a guide at the start of the day or not."
Only "entirely random" part is slightly misleading. Every morning, the DaysWithoutGuide counter is increased, and if its above 1, the roll for Guide happens:
[GuideRoll = 70 + 5*DaysWithoutGuide - 20*AmountOfHiredGuides],
if roll succeed, Jack offers a Guide to player and DaysWithoutGuide set to 0. If player accept the Guide, AmountOfHiredGuides value is increased. If AmountOfHiredGuides reach 4, rolls for a Guide are stopped, as there is no 5-th Guide. So chance to get a proposed Elio at day 2 is already 80% and few days later it could reach a 100% chance.
--------------------------------------------------------------------------------
"Hates: The merc can't stand the guy in this column, when asked to work with this guy, the merc will threaten to leave the team or refuse to join unless the other guy is fired. Will Hate: The merc has initially no problem working with the guy in this column, but after a few days it will become apparent that they cannot work together. The merc will threaten to leave unless the other guy is fired. If an asterisk follows a name in the Hates or Will Hate columns, rather than threaten to leave, the merc will try to kill the person they dislike."
Hate affect the Maniac's kills, marked as asterisks in table, and also a FireMerc & RiverBurial mechanics (see above). "Few Days" for WillHate actually means "one day". Note, that unlike many other dissatisfactions of mercs, Hate cannot be bribed.
--------------------------------------------------------------------------------
"Death, Turnover and Non-Payment: The merc will threaten to leave or refuse to join should your Death, Turnover or Non-Payment rates reach this value. Native deaths or discharges do not affect these values."
Looks very good by me.
--------------------------------------------------------------------------------
"Fail: The merc will threaten to leave or refuse to join should Jack gives you less than a Fair rating for this number of days in a row. Should you screw up more than five days in a row, you'll find yourself without a job."
This one is misleading - should be read as: Should you screw up more than FOUR days in a row, you'll find yourself without a job (Game Over). Table entries for 5 in Fail column actually would be more convenient as dashes for N/A as in other columns, as value 5 there means merc in question doesnt care about Fail value in regard of joining.
Thats not very true. Actually only Firing and RiverBurial are of matter in this context. About Non-Payment related bugs and fixes refer patch 1.15 Readme (no matter those bugs it still would be out of context here anyway tho). So cases are:
Fire a merc. When a non-Guide, already joined a team, merc is fired (its of no penalty to "hire/fire/rehire etc" somebody while that somebody hadnt yet brought to island by a copter):
That merc will leave, handling all his/her equipment to player and will refuse to ever join back later.
Depending on days the fired merc was employed amount of rolls to "set buddies" is generated. In case of merc fired very same day as arrival amount is 4. In other cases amount is randomly chosen 1, 2, or 3, but only if roll of amount of days merc was employed above first one is "won" (so merc, fired after 2 days will have 100% chance to generate 1-3 "buddy rolls"; fired after 3 days 50% chance; after 4 days 33% chance, and so on). "Buddy rolls" are not guaranteed to succeed tho. Each roll chose a one from 60 mercenaries, but to become Buddy, that merc have to meet several criteria:
Not be that currently fired merc;
Not be currently employed in player's team;
Not have a Maniac trait;
Not have a Buddy already;
Not Hate the currently fired merc (this one is very exploitable, say player can fire Kaboom and be sure it will not affect Magic, making Kaboom very strong for the first day).
Not be a Wink Dickerson.
In case any of criteria fail, that "buddy roll" is used up. So, its not "one or two", but "up to four" mercs, who could randomly turn into buddies, demanding a salary doubled.
Note: the info above is valid for v.1.13+, as Sir-tech official patches somewhere prior it changed behavior to described from:
Amount of "buddy rolls" are always randomly 1, 2, or 3, but days employed-based roll cannot have a chance lower than 25% (so merc fired after 5 days or 20 days have the same chance to complain, unlike later version). Also likely during that change Wink's unique case has been added, as original game ver1.0 had him as a valid Buddy. Thats make Wink the most special of all the mercs, the only one, who got own hardcoded check, beside NativeGuides (who also have them not personally, but as Guides only).
Toss merc to a river. When a non-Guide merc(s) is/are dead, and player not order a helicopter to take bodies out:
Per each RiverBuried body roll to determine 1 or 2 "set enraged" is generated. Each roll is also chose a one from 60 mercenaries, but have some differences to BuddyFired mechanic. The merc, chosen by roll should also meet several criteria:
Not have a Maniac trait;
Not be in Enraged state already;
Not hate that RiverBuried merc.
Depending on status of employment of Enraged merc there is a difference tho, as, unlike Buddy roll, merc, who is currently in team, also could be Enraged. Thus it lead to 2 different effects:
Enraged merc is currently not in team: that merc will never agree to join a player's team from now.
Enraged merc is currently in team: that merc will complain about RiverBurial, but could be Bribed to change own mind about it (so will stay in team if bribed successfully).
Note what both Buddy and Enraged rolls doesnt specially check for dead mercs, so actually they could be wasted on dead (or already fired, so unavailable anyway) mercs too, reducing the chance even more.
--------------------------------------------------------------------------------
"Hirable: Indicates how many days must have passed, or how many success points you must have collected before this mercenary accepts to work for you. Success points are scored by getting positive ratings from Jack at the end of a day (Good is worth 1 point; Excellent is worth 2 points; Outstanding is worth 3 points.)"
One of most dangerously misleading parts. The described mechanic is correct only for Go Ahead difficulty setting of patch 1.15. In regular game, due to odd designers decision, or maybe due to bug, Success Points amount per day have no hard limit set (while Jack indeed have his messages only up to +-3 points). So, while Excellent is indeed always worth 2 points, Outstanding could mean 3 points, or 12 points (important to earn at day 1 to be able to hire Magic) or 19 points (possible on day 1 on Hard with 11 sectors won). Refer to Readme of patch 1.15 for more detailed explanation. Every day's end, DaySuccessPoints are added to SuccessPoint amount, used to check if merc in question will or will not agree to join.
[DaySuccessPoints =
(10*{Difference_of_ProcessingPlants_amount_of_the_day} +
5*Difference_of_SectorsOwned_amount_of_the_day} +
{Difference_of_TreesOwned_amount_of_the_day} +
{Difference_of_TreesSafetoTap_amount_of_the_day} +
{Difference_of_TreesTapped_amount_of_the_day} +
#Enemies_killed_during_the_day -
#Natives_killed_during_the_day -
5*#Mercs_killed_during_the_day)/10, rounded up]
For very late game days (50 and more) there is additional penalties.
Having a negative DaySuccessPoint cause a Fail value to increase. Amassing a 5 Fail points causing a loss of game. Any day player have a non-negative DaySuccessPoints amount tho, Fail points are set back to 0 (even 0 DaySuccessPoints will do a work).
--------------------------------------------------------------------------------
"Native guides are hired in a special way. If you have one free slot in your team at the start of the day, Jack might offers you one of his four trusted assistants to accompany you on the field. The first one of these will be Elio, then Hamous, Juan and finally Wahan. Elio will not be offered until Day 2, and all subsequent guides will be offered only two days after the previous guide has been fired or killed. Please note that it is entirely random whether Jack will offer you a guide at the start of the day or not."
Only "entirely random" part is slightly misleading. Every morning, the DaysWithoutGuide counter is increased, and if its above 1, the roll for Guide happens:
[GuideRoll = 70 + 5*DaysWithoutGuide - 20*AmountOfHiredGuides],
if roll succeed, Jack offers a Guide to player and DaysWithoutGuide set to 0. If player accept the Guide, AmountOfHiredGuides value is increased. If AmountOfHiredGuides reach 4, rolls for a Guide are stopped, as there is no 5-th Guide. So chance to get a proposed Elio at day 2 is already 80% and few days later it could reach a 100% chance.
--------------------------------------------------------------------------------
"Hates: The merc can't stand the guy in this column, when asked to work with this guy, the merc will threaten to leave the team or refuse to join unless the other guy is fired. Will Hate: The merc has initially no problem working with the guy in this column, but after a few days it will become apparent that they cannot work together. The merc will threaten to leave unless the other guy is fired. If an asterisk follows a name in the Hates or Will Hate columns, rather than threaten to leave, the merc will try to kill the person they dislike."
Hate affect the Maniac's kills, marked as asterisks in table, and also a FireMerc & RiverBurial mechanics (see above). "Few Days" for WillHate actually means "one day". Note, that unlike many other dissatisfactions of mercs, Hate cannot be bribed.
--------------------------------------------------------------------------------
"Death, Turnover and Non-Payment: The merc will threaten to leave or refuse to join should your Death, Turnover or Non-Payment rates reach this value. Native deaths or discharges do not affect these values."
Looks very good by me.
--------------------------------------------------------------------------------
"Fail: The merc will threaten to leave or refuse to join should Jack gives you less than a Fair rating for this number of days in a row. Should you screw up more than five days in a row, you'll find yourself without a job."
This one is misleading - should be read as: Should you screw up more than FOUR days in a row, you'll find yourself without a job (Game Over). Table entries for 5 in Fail column actually would be more convenient as dashes for N/A as in other columns, as value 5 there means merc in question doesnt care about Fail value in regard of joining.
Post edited August 02, 2020 by DarzaR
DarzaR
New User
Registered: Sep 2013
From Russian Federation
Posted August 02, 2020
"Bribe %: If the merc decides to quit for one reason or another, he might be willing to stay for this percentage increase to his salary (For example, if a merc whose salary is $1000 asks for a 200% raise, that means you must pay him $3000). Of course, some mercs cannot be bribed."
Valid Bribe reasons are merc's, who is currently in player's team, dissatisfaction with Fatality, Turnover, Non-Payment, or Fail Rates and Enraging with RiverBurial. Succesful bribing will forever prevent merc from further bothering with certain Rate value, while Enraged state could be later re-triggered by another RiverBurial. WimpyConscience trait effect cannot result in successful bribe, no matter the salary offered (while Biff also cannot be bribed for other reasons, its not related to WimpyConscience). Amount of bribe percentage is the same for all valid reasons.
Actual Bribe mechanic is slightly more complex than covered by the table tho. It use not only a value of "BribeSuccess%", listed in table, but also "BribeRetry%" and "RetriesAmount". As far i can understand they are not present in the Book, as knowledge of BribeSuccess% make other 2 values already redundant to actual player.
Every time player chose some amount of salary increase and press OK, the SalariesDifference% is compared to BribeSuccess%, and merc is successfully bribed if its not less. Otherwise its compared to BribeRetry%, and if its not less, player have a chance to continue to rise a salary and retry, if number of RetriesAmount is not reached yet. Some mercs are indeed cannot be bribed.
--------------------------------------------------------------------------------
"Steal: Anyone who kills for a living probably isn't that ethical. Multiply this number by the merc's salary. Should you find cash on the battlefield, equal or greater to this number, and order that merc to carry it to the base, he might just decide that Hawaii is a better island for him and your money. Native Guides and mercs with the Snitch trait won't steal your money."
See info about Snitches and Natives traits above. Contrary to "he might just decide that Hawaii is a better island for him and your money." there is nothing random-based in this mechanic: in case non-Snitch non-Native merc will bring enough money to steal - he/she will quit with all equipment (except special quest items like Purifier), will increase Turnover Rate, but will be available to re-hire with all stuff in possession (xcept stolen money) back after 14 days (well, thus, in reality, "never"). Also note, that max amount of cash to carry by a merc in theory is only 35000$, so while some technically not loyal merc have that value written, they cant steal in non-modded game (despite have a related messages assigned to them). Furthermore, in actual game v1.13 the actual max possible (as it includes a random value in it) amount of cash is only 14860$ in 34 items (thus they all CAN be collected to be brought to a base by a single merc). If those 34 instead of 35 (max carriable) items is a result of an error or planned i cannot know.
--------------------------------------------------------------------------------
"Shooting Speed: The higher the number, the less the action points the merc will use to shoot a gun."
"Stabbing Speed: The higher the number, the less the action points required to attack with a knife."
Use the same formula with difference in one modifier, displayed in tables:
................................................Marksmanship .............Shooting Speed, used for attack with Pistol, Shotgun, or Rifle
[BaseMercAttackSpeed = ........................................]
................................................(Agility + Dexterity)/2 ....Stabbing Speed, used for attack with Knife,
further modified as:
[MercAttackSpeed = BaseMercAttackSpeed/2 + 50]
Note: to complicate things up, the table shows MercAttackSpeed value for Shooting Speed, but BaseMercAttackSpeed value for Stabbing Speed
Basic formula for Shooting/StabbingSpeed:
[Shooting/StabbingSpeed = (CurrentMaxAP*200/(WeaponRateOfFire*MercAttackSpeed)/2) + 1)/2
Indirectly affected by Breath, as it use CurrentMaxAP in calculation.
Later modified by:
+[WeaponReadyTime], if weapon not readied yet;
+1, if weapon is already readied, but attack require a turning;
+1, if not attacking the previously set target (setting a new target / changing a target).
--------------------------------------------------------------------------------
"Throwing Speed: The higher the number, the less the action points required to toss an object like a grenade"
...To toss a Grenade-like explosive object or Rock. Use simplified formula, due to lack of weapon-related factor and inability to keep previous target.
[MercThrowingSpeed = Dexterity/2 + 50]
[ThrowngSpeed = (CurrentMaxAP*200/(MercThrowingSpeed*2) + 1)/2
Indirectly affected by Breath, as it use CurrentMaxAP in calculation.
Note: originally Throwing cost also been affected by {+1, if attack require a turning}, with that modifier removed later by Sir-tech official patches somewhere prior v 1.13.
--------------------------------------------------------------------------------
Shooting Accuracy:
Not covered by tables, but worthy mention too. Basic formula is the simplest one: [ShootingAccuracy = Marksmanship].
WeaponCondition (displayed in %) modify it, in case WeaponCondition is lower than Marksmanship to:
[WeaponQualityAffectedShootingAccuracy = (Marksmanship + WeaponQuality)/2] Affected by Breath.
Note, that due to game bug all the three Accuracy values are also penalized by BandagedHealth, instead of being benefited from it. Command line option HEALTHY of patch 1.15 provide an optional fix for it. For more info about Command line options see patch 1.15 Readme.
--------------------------------------------------------------------------------
"Throwing Accuracy: The base accuracy when throwing an object at a specific spot"
Very simple one too. Condition of Throwing weapon not affect accuracy.
[ThrowingAccuracy = (Dexterity + Marksmanship)/2] Affected by Breath.
--------------------------------------------------------------------------------
"Throwing Range: The maximum distance (in squares) this merc can throw an object"
Column with many +-1 deviations in values. From page history its not even easily possible to get if the column originating from the Book, or its just some result of Blueskirt's own tests. Deviation in values could be result of mixing 2 possible definitions of "Throwing Range" in game. One, normally used in calculations there is:
[ThrowingRange = (CurrentHealth - 50 + 15*ThrowingObjectRange)/15] Affected by Breath.
ThrowingObjectRange = 8 for all throwable objects in non-modded game.
ThrowingRange is displayed in game by non-flashing Throw cursor. Flashing cursor shows that the tile is out of ThrowingRange. However, The maximum distance (in squares) this merc can throw an object is actually a ThrowingRange+1. While the table data is inconsistent with both ThrowingRange and ThrowingRange+1 values, its not really a "hidden" value on its own, due to easy way to check by in-game method.
--------------------------------------------------------------------------------
"Stabbing Accuracy: The base ability to hit an opponent with a stabbing attack."
Most complicated from Accuracies. Condition of Knife not affect accuracy.
[StabbingAccuracy = (MaxHealth + Agility + 3*Dexterity + 10*ExpLevel)/6] Affected by Breath.
Note, that stabbing a target, who is not see an attacker, result in armor-piercing attack with 99% accuracy no matter StabbingAccuracy and StabbingDefence are.
--------------------------------------------------------------------------------
"Stabbing Defense: The base ability to defend against an opponent's stab attack."
Paired one to a StabbingAccuracy:
[StabbingDefence = (MaxHealth + 3*Agility + Dexterity + 10*ExpLevel)/6] Affected by Breath.
Note, that due to game bug StabbingDefence value is also penalized by BandagedHealth, instead of being benefited from it. Command line option HEALTHY of patch 1.15 provide an optional fix for it. For more info about Command line options see patch 1.15 Readme.
--------------------------------------------------------------------------------
"Ready Knife: The chance of automatically readying a knife while encountering a snake while moving through water."
See a Stuff about Water for more detailed explanation.
Roll for auto-equipping knife from the other slot: [Dexterity vs roll[100]] Not affected by Breath.
this roll should succeed twice in a row to move a knife to main hand (so merc with Dex100 with always re-equip knife, and merc with Dex50 will do so 1/4 of times).
Being a NativeGuide, Guard or Enemy will cause this roll to always succeed.
Note, that this value is in % of success chance. Pops is listed as having a 0% chance, while he actually have a real 1/625 chance, so more than 0%. (<1 would be more correct value for table).
--------------------------------------------------------------------------------
"Kill Snake: The base chance of defeating a snake when attacked. The knife, naturally, improves this chance greatly."
See a Stuff about Water for more detailed explanation. Type or condition of knife is not affect snake battle.
[KillSnakeRoll = (CurrentHealth + BandagedHealth/2)*Breath/100 - (100 - Dexterity)/4] Affected by Breath.
Further modified by having a knife in active hand [+80% if knife or +0% otherwise],
and additional +40% for being NativeGuide, Guard or Enemy.
In case final KillSnakeRoll value is above 95, its set at 95.
Then Roll 100 is made vs it, and if higher, the snake won and merc is dying.
Valid Bribe reasons are merc's, who is currently in player's team, dissatisfaction with Fatality, Turnover, Non-Payment, or Fail Rates and Enraging with RiverBurial. Succesful bribing will forever prevent merc from further bothering with certain Rate value, while Enraged state could be later re-triggered by another RiverBurial. WimpyConscience trait effect cannot result in successful bribe, no matter the salary offered (while Biff also cannot be bribed for other reasons, its not related to WimpyConscience). Amount of bribe percentage is the same for all valid reasons.
Actual Bribe mechanic is slightly more complex than covered by the table tho. It use not only a value of "BribeSuccess%", listed in table, but also "BribeRetry%" and "RetriesAmount". As far i can understand they are not present in the Book, as knowledge of BribeSuccess% make other 2 values already redundant to actual player.
Every time player chose some amount of salary increase and press OK, the SalariesDifference% is compared to BribeSuccess%, and merc is successfully bribed if its not less. Otherwise its compared to BribeRetry%, and if its not less, player have a chance to continue to rise a salary and retry, if number of RetriesAmount is not reached yet. Some mercs are indeed cannot be bribed.
--------------------------------------------------------------------------------
"Steal: Anyone who kills for a living probably isn't that ethical. Multiply this number by the merc's salary. Should you find cash on the battlefield, equal or greater to this number, and order that merc to carry it to the base, he might just decide that Hawaii is a better island for him and your money. Native Guides and mercs with the Snitch trait won't steal your money."
See info about Snitches and Natives traits above. Contrary to "he might just decide that Hawaii is a better island for him and your money." there is nothing random-based in this mechanic: in case non-Snitch non-Native merc will bring enough money to steal - he/she will quit with all equipment (except special quest items like Purifier), will increase Turnover Rate, but will be available to re-hire with all stuff in possession (xcept stolen money) back after 14 days (well, thus, in reality, "never"). Also note, that max amount of cash to carry by a merc in theory is only 35000$, so while some technically not loyal merc have that value written, they cant steal in non-modded game (despite have a related messages assigned to them). Furthermore, in actual game v1.13 the actual max possible (as it includes a random value in it) amount of cash is only 14860$ in 34 items (thus they all CAN be collected to be brought to a base by a single merc). If those 34 instead of 35 (max carriable) items is a result of an error or planned i cannot know.
--------------------------------------------------------------------------------
"Shooting Speed: The higher the number, the less the action points the merc will use to shoot a gun."
"Stabbing Speed: The higher the number, the less the action points required to attack with a knife."
Use the same formula with difference in one modifier, displayed in tables:
................................................Marksmanship .............Shooting Speed, used for attack with Pistol, Shotgun, or Rifle
[BaseMercAttackSpeed = ........................................]
................................................(Agility + Dexterity)/2 ....Stabbing Speed, used for attack with Knife,
further modified as:
[MercAttackSpeed = BaseMercAttackSpeed/2 + 50]
Note: to complicate things up, the table shows MercAttackSpeed value for Shooting Speed, but BaseMercAttackSpeed value for Stabbing Speed
Basic formula for Shooting/StabbingSpeed:
[Shooting/StabbingSpeed = (CurrentMaxAP*200/(WeaponRateOfFire*MercAttackSpeed)/2) + 1)/2
Indirectly affected by Breath, as it use CurrentMaxAP in calculation.
Later modified by:
+[WeaponReadyTime], if weapon not readied yet;
+1, if weapon is already readied, but attack require a turning;
+1, if not attacking the previously set target (setting a new target / changing a target).
--------------------------------------------------------------------------------
"Throwing Speed: The higher the number, the less the action points required to toss an object like a grenade"
...To toss a Grenade-like explosive object or Rock. Use simplified formula, due to lack of weapon-related factor and inability to keep previous target.
[MercThrowingSpeed = Dexterity/2 + 50]
[ThrowngSpeed = (CurrentMaxAP*200/(MercThrowingSpeed*2) + 1)/2
Indirectly affected by Breath, as it use CurrentMaxAP in calculation.
Note: originally Throwing cost also been affected by {+1, if attack require a turning}, with that modifier removed later by Sir-tech official patches somewhere prior v 1.13.
--------------------------------------------------------------------------------
Shooting Accuracy:
Not covered by tables, but worthy mention too. Basic formula is the simplest one: [ShootingAccuracy = Marksmanship].
WeaponCondition (displayed in %) modify it, in case WeaponCondition is lower than Marksmanship to:
[WeaponQualityAffectedShootingAccuracy = (Marksmanship + WeaponQuality)/2] Affected by Breath.
Note, that due to game bug all the three Accuracy values are also penalized by BandagedHealth, instead of being benefited from it. Command line option HEALTHY of patch 1.15 provide an optional fix for it. For more info about Command line options see patch 1.15 Readme.
--------------------------------------------------------------------------------
"Throwing Accuracy: The base accuracy when throwing an object at a specific spot"
Very simple one too. Condition of Throwing weapon not affect accuracy.
[ThrowingAccuracy = (Dexterity + Marksmanship)/2] Affected by Breath.
--------------------------------------------------------------------------------
"Throwing Range: The maximum distance (in squares) this merc can throw an object"
Column with many +-1 deviations in values. From page history its not even easily possible to get if the column originating from the Book, or its just some result of Blueskirt's own tests. Deviation in values could be result of mixing 2 possible definitions of "Throwing Range" in game. One, normally used in calculations there is:
[ThrowingRange = (CurrentHealth - 50 + 15*ThrowingObjectRange)/15] Affected by Breath.
ThrowingObjectRange = 8 for all throwable objects in non-modded game.
ThrowingRange is displayed in game by non-flashing Throw cursor. Flashing cursor shows that the tile is out of ThrowingRange. However, The maximum distance (in squares) this merc can throw an object is actually a ThrowingRange+1. While the table data is inconsistent with both ThrowingRange and ThrowingRange+1 values, its not really a "hidden" value on its own, due to easy way to check by in-game method.
--------------------------------------------------------------------------------
"Stabbing Accuracy: The base ability to hit an opponent with a stabbing attack."
Most complicated from Accuracies. Condition of Knife not affect accuracy.
[StabbingAccuracy = (MaxHealth + Agility + 3*Dexterity + 10*ExpLevel)/6] Affected by Breath.
Note, that stabbing a target, who is not see an attacker, result in armor-piercing attack with 99% accuracy no matter StabbingAccuracy and StabbingDefence are.
--------------------------------------------------------------------------------
"Stabbing Defense: The base ability to defend against an opponent's stab attack."
Paired one to a StabbingAccuracy:
[StabbingDefence = (MaxHealth + 3*Agility + Dexterity + 10*ExpLevel)/6] Affected by Breath.
Note, that due to game bug StabbingDefence value is also penalized by BandagedHealth, instead of being benefited from it. Command line option HEALTHY of patch 1.15 provide an optional fix for it. For more info about Command line options see patch 1.15 Readme.
--------------------------------------------------------------------------------
"Ready Knife: The chance of automatically readying a knife while encountering a snake while moving through water."
See a Stuff about Water for more detailed explanation.
Roll for auto-equipping knife from the other slot: [Dexterity vs roll[100]] Not affected by Breath.
this roll should succeed twice in a row to move a knife to main hand (so merc with Dex100 with always re-equip knife, and merc with Dex50 will do so 1/4 of times).
Being a NativeGuide, Guard or Enemy will cause this roll to always succeed.
Note, that this value is in % of success chance. Pops is listed as having a 0% chance, while he actually have a real 1/625 chance, so more than 0%. (<1 would be more correct value for table).
--------------------------------------------------------------------------------
"Kill Snake: The base chance of defeating a snake when attacked. The knife, naturally, improves this chance greatly."
See a Stuff about Water for more detailed explanation. Type or condition of knife is not affect snake battle.
[KillSnakeRoll = (CurrentHealth + BandagedHealth/2)*Breath/100 - (100 - Dexterity)/4] Affected by Breath.
Further modified by having a knife in active hand [+80% if knife or +0% otherwise],
and additional +40% for being NativeGuide, Guard or Enemy.
In case final KillSnakeRoll value is above 95, its set at 95.
Then Roll 100 is made vs it, and if higher, the snake won and merc is dying.
Post edited October 18, 2020 by DarzaR
DarzaR
New User
Registered: Sep 2013
From Russian Federation
Posted August 02, 2020
"Detect Bomb: The level of the bomb trap that the merc is capable of detecting.
Formula: (EXP / 30) + LVL "
Strictly speaking, the formula used by table is about detection of traps, the merc is "touching by hands":
[DetectTrapWhileTouching = Explosives/30 + ExpLevel] Not affected by Breath.
Formula for detection of traps (not Mines), triggered by "stepping on them" is simply:
[DetectTrapWhileWalking = ExpLevel] Not affected by Breath.
Unlike other traps, Mines cannot be detected without using a MetalDetector. Contrary to common belief, no check on merc stats is performed (thats it, merc dont have to be any good in Explosives skill to detect Mines). Every step a merc with working MetalDetector move, every tile in range of 1 is checked for Metal object there, if Condition of MetalDetector won a roll vs 100 (so MetalDetector in 100% condition would detect every Mine in range; while its bad condition could lead to leaving some of them unnoticed).
--------------------------------------------------------------------------------
"Disarm Bomb: The chance of the merc successfully disarming a known bomb trap."
Known trap is one, thats already been detected by some merc (not necessary one, who is performing Disarm now), using DetectTrapWhileTouching. Touching a non-detected trap will not cause a Disarm check to be performed, and will lead to triggering the effect of trap, with exception of traps, already marked by BlueFlags (say, Mines). In this case, even if actual trap level is too high for DetectTrapWhileTouching (usual case with Mines), DisarmTrap check is still performed, and could succeed (just in case merc is unable to detect a trap under BlueFlag he/she is touching, there wouldnt be a dialog box about confirmation of Disarm attempt).
[DisarmTrap = 20*Dexterity/100 + 70*Explosives/100 + ExpLevel - (100 - Wisdom)/5] Not affected by Breath.
DisarmTrap value is compared to roll 100, and if not less than it, trap is disarmed. Note, the trap level itself doesnt affect DisarmTrap roll, only DetectTrap.
--------------------------------------------------------------------------------
"First Aid: The number of points of health a merc can bandage per turn that he spends fully attending wounds with complete medical supplies"
Excessively complicated formula, also with many discrepancies in values in table (maybe caused by small changes applied by Sir-tech in process). Table values for this column not only assume complete medical supplies, they are calculated using the default AP values of mercs (without carried on AP's).
[FirstAid = ((200 + Dexterity + 3*Medical + 10*ExpLevel)/7)*DefaultAP/50] Not affected by Breath.
Using a MedicalKit also add +50% to that value.
--------------------------------------------------------------------------------
"Doctor: The base number of points a merc can heal per day when assigned to heal patients and doctor their wounds."
Probably most surprising formula - Experience of Doctor doesnt matter at all for the work done:
[HealingPoints = ((Wisdom - 20*(100 - Dexterity)/100)*Medical/100)*2] Not affected by Breath.
Each HealingPoint can restore a Health point for Patient merc. The way points are distributed could be not fully obvious tho. First, Doctor tries to spend them for own health restore. Then, in case HealingPoints still left, they are equally distributed between all other Doctors and Patients, with points provided above a need of a certain patient being lost, and not re-distributed to other ones.
Example:
Doctor A with 11 damage and 10 HealingPoints
Doctor B with 1 damage and 102 HealingPoints
Patient C with 80 damage
Patient D with 20 damage
First Doctor A spend all 10 HealingPoints on himself, and remains with 1 damage.
Then Doctor B spend 1 HealingPoint on himself and then distribute remained 101 DoctorPoints equally for A C & D: 101/3=33 HealingPoint to each.
Doctor A heals 1 remained damage spending all 33 HealingPoints provided by B.
Patient C heals 33 damage spending all 33 HealingPoints provided by B and remains with 47 damage.
Patient D heals all 20 damage spending all 33 HealingPoints provided by B.
After the equal distribution and speding of HealingPoints, Doctor B still have remain of 2 points not distributed, so now trying to equally distribute them further to ones in need:
A is fully healed already, so not provided with a point.
C is still with 47 damage, so provided with 1 point, and remains with 46 damage.
D is fully healed already, so not provided with a point.
Note, that despite sum of DamagePoints among 4 mercs was equal to sum of DoctorPoints among them, merc C remained with damage to heal still. Moreother, for Exp reasons, only HealingPoints actually converted to Health matters, so while Doctor A converted all his own 10 points, Doctor B actually converted only 56 from 102, and got Exp rolls for those 56 only.
--------------------------------------------------------------------------------
"Repair: The base number of condition percentage points a merc can repair when assigned to repair for the day."
Experience of Mechanic does matter, unlike a Doctor's, but, well, still laughable not much:
[RepairPoints = 3*(Dexterity*Mechanical + (ExpLevel - 1)*5)/200] Not affected by Breath.
Weird enough, is that values from table are to the formula above, changed by Sir-tech official patches somewhere prior v 1.13 from the:
[RepairPointsVer1.0 = (3*Dexterity*Mechanical + (ExpLevel - 1)*5)/200],
with ExpLevel value tripled to a whooping 3/40 (!) RepairPoints per level above first. Dont know if the Book already came out with updated formula used, or Blueskirt fixed values to match patched version (Bernie is easiest case to notice, with his 2 RepairPoints under ver1.0 changed to 3 in version 1.13 (maybe they patched it after printing a wrong value to make game match the Book instead?)).
Repair process on its own way more simple than Doctor: RepairPoints are converted to condition points of items starting with secondary hand, then from top to bottom placed items in Vest. Multiple items in hand\pocket will be repaired one-after-one, while attachments will not. A nonbasic thing to mention is that jammed guns would take 2 RepairPoints for unjam.
--------------------------------------------------------------------------------
"Merge: The chance of successfully performing a mechanical skill-dependent item merge. (Please note that Explosives, Molotov Cocktails and Eagle Bombs crafting are all explosive skill-dependent item merges and should be performed by explosive experts, not mechanics.)
Formula: DEX * MEC / 100"
Now there is a serious one - the formula used in actual game is totally different, and all data in this column is plain wrong (while correspond to deciphered formula listed above). Its likely due to game rules change happened after the Book went to print. There is an oddity with it tho - formula used for Merge didnt changed from ver1.0 to ver1.13, while table list already updated from ver1.0 formula for RepairPoints. Actual in-game formula for Merge is:
[MergeChance = Mechanical - (100 - Dexterity)/2] Not affected by Breath.
MergeChance is compared with Roll 100 after, and Merge is succesful if its not less. Note, that this formula used only for creating Modified weapons from some weapon and ChunkOfSteel. Unsuccessful merge likely would result in damage (based on how much the failed roll was failed) of one or both merging items (while their conditions on its own is not affecting the chance). Applying a damage equal or more than item condition will lead to destroying that item entirely. Other non-explosive merges have no chance to fail.
Explosive items merges use a Roll 100 and Explosives skill, but instead of check for success or fail, using them for determining the condition of merged item instead (together with conditions of merging items involved, unlike a ChunkOfSteel merge). Those merges cannot fail, and worst possible condition of merged item could be not less than 10% (thats it, any merc could safely merge any explosive items, with only danger arising from it is possibility of creating a low-quality item).
--------------------------------------------------------------------------------
"Unjam Gun: The chance of a merc successfully unjamming a weapon by trying to fire it.
Formula: (MEC / 2) + 20 "
This one is correct and very simple:
[UnjamChance = Mechanical/2 + 20] Not affected by Breath.
UnjamChance is compared with Roll 100 after, and Unjam is successful if UnjamChance is not less. Condition of weapon do not matter.
Note: while technically speaking, Ammo DO have condition% set to it, its not used in actual game; the only thing affecting Jamming is gun condition:
[JammingChance = GunCondition + rnd{0-49}]
JammingChance is compared with Roll 100 when gun is fired, and its not Jammed if JammingChance is not less (so gun in 99% condition can jam, unlike a gun in 100% condition).
--------------------------------------------------------------------------------
"Pick Locks: The level of the lock that this merc is capable of unlocking with a Locksmith Kit in perfect condition.
Formula: MEC * WIS/100 * DEX/100 + LVL * 5"
See a stuff about Doors for more detailed explanation. As the formula above already has been taken from it, its correct indeed:
[Picklock = (Dexterity*(Wisdom*Mechanical/100)/100 + 5*ExpLevel)*LocksmithKitCondition/100] Not affected by Breath.
Picklock is compared to DoorStrength value later to at least meet it for success.
Game also use a version of this formula with a different rounding (with possible better results for some mercs) for the JournalSafe:
[PicklockJournaSafe = (Dexterity*Wisdom*Mechanical/10000 + 5*ExpLevel)*LocksmithKitCondition/100] Not affected by Breath.
Formula: (EXP / 30) + LVL "
Strictly speaking, the formula used by table is about detection of traps, the merc is "touching by hands":
[DetectTrapWhileTouching = Explosives/30 + ExpLevel] Not affected by Breath.
Formula for detection of traps (not Mines), triggered by "stepping on them" is simply:
[DetectTrapWhileWalking = ExpLevel] Not affected by Breath.
Unlike other traps, Mines cannot be detected without using a MetalDetector. Contrary to common belief, no check on merc stats is performed (thats it, merc dont have to be any good in Explosives skill to detect Mines). Every step a merc with working MetalDetector move, every tile in range of 1 is checked for Metal object there, if Condition of MetalDetector won a roll vs 100 (so MetalDetector in 100% condition would detect every Mine in range; while its bad condition could lead to leaving some of them unnoticed).
--------------------------------------------------------------------------------
"Disarm Bomb: The chance of the merc successfully disarming a known bomb trap."
Known trap is one, thats already been detected by some merc (not necessary one, who is performing Disarm now), using DetectTrapWhileTouching. Touching a non-detected trap will not cause a Disarm check to be performed, and will lead to triggering the effect of trap, with exception of traps, already marked by BlueFlags (say, Mines). In this case, even if actual trap level is too high for DetectTrapWhileTouching (usual case with Mines), DisarmTrap check is still performed, and could succeed (just in case merc is unable to detect a trap under BlueFlag he/she is touching, there wouldnt be a dialog box about confirmation of Disarm attempt).
[DisarmTrap = 20*Dexterity/100 + 70*Explosives/100 + ExpLevel - (100 - Wisdom)/5] Not affected by Breath.
DisarmTrap value is compared to roll 100, and if not less than it, trap is disarmed. Note, the trap level itself doesnt affect DisarmTrap roll, only DetectTrap.
--------------------------------------------------------------------------------
"First Aid: The number of points of health a merc can bandage per turn that he spends fully attending wounds with complete medical supplies"
Excessively complicated formula, also with many discrepancies in values in table (maybe caused by small changes applied by Sir-tech in process). Table values for this column not only assume complete medical supplies, they are calculated using the default AP values of mercs (without carried on AP's).
[FirstAid = ((200 + Dexterity + 3*Medical + 10*ExpLevel)/7)*DefaultAP/50] Not affected by Breath.
Using a MedicalKit also add +50% to that value.
--------------------------------------------------------------------------------
"Doctor: The base number of points a merc can heal per day when assigned to heal patients and doctor their wounds."
Probably most surprising formula - Experience of Doctor doesnt matter at all for the work done:
[HealingPoints = ((Wisdom - 20*(100 - Dexterity)/100)*Medical/100)*2] Not affected by Breath.
Each HealingPoint can restore a Health point for Patient merc. The way points are distributed could be not fully obvious tho. First, Doctor tries to spend them for own health restore. Then, in case HealingPoints still left, they are equally distributed between all other Doctors and Patients, with points provided above a need of a certain patient being lost, and not re-distributed to other ones.
Example:
Doctor A with 11 damage and 10 HealingPoints
Doctor B with 1 damage and 102 HealingPoints
Patient C with 80 damage
Patient D with 20 damage
First Doctor A spend all 10 HealingPoints on himself, and remains with 1 damage.
Then Doctor B spend 1 HealingPoint on himself and then distribute remained 101 DoctorPoints equally for A C & D: 101/3=33 HealingPoint to each.
Doctor A heals 1 remained damage spending all 33 HealingPoints provided by B.
Patient C heals 33 damage spending all 33 HealingPoints provided by B and remains with 47 damage.
Patient D heals all 20 damage spending all 33 HealingPoints provided by B.
After the equal distribution and speding of HealingPoints, Doctor B still have remain of 2 points not distributed, so now trying to equally distribute them further to ones in need:
A is fully healed already, so not provided with a point.
C is still with 47 damage, so provided with 1 point, and remains with 46 damage.
D is fully healed already, so not provided with a point.
Note, that despite sum of DamagePoints among 4 mercs was equal to sum of DoctorPoints among them, merc C remained with damage to heal still. Moreother, for Exp reasons, only HealingPoints actually converted to Health matters, so while Doctor A converted all his own 10 points, Doctor B actually converted only 56 from 102, and got Exp rolls for those 56 only.
--------------------------------------------------------------------------------
"Repair: The base number of condition percentage points a merc can repair when assigned to repair for the day."
Experience of Mechanic does matter, unlike a Doctor's, but, well, still laughable not much:
[RepairPoints = 3*(Dexterity*Mechanical + (ExpLevel - 1)*5)/200] Not affected by Breath.
Weird enough, is that values from table are to the formula above, changed by Sir-tech official patches somewhere prior v 1.13 from the:
[RepairPointsVer1.0 = (3*Dexterity*Mechanical + (ExpLevel - 1)*5)/200],
with ExpLevel value tripled to a whooping 3/40 (!) RepairPoints per level above first. Dont know if the Book already came out with updated formula used, or Blueskirt fixed values to match patched version (Bernie is easiest case to notice, with his 2 RepairPoints under ver1.0 changed to 3 in version 1.13 (maybe they patched it after printing a wrong value to make game match the Book instead?)).
Repair process on its own way more simple than Doctor: RepairPoints are converted to condition points of items starting with secondary hand, then from top to bottom placed items in Vest. Multiple items in hand\pocket will be repaired one-after-one, while attachments will not. A nonbasic thing to mention is that jammed guns would take 2 RepairPoints for unjam.
--------------------------------------------------------------------------------
"Merge: The chance of successfully performing a mechanical skill-dependent item merge. (Please note that Explosives, Molotov Cocktails and Eagle Bombs crafting are all explosive skill-dependent item merges and should be performed by explosive experts, not mechanics.)
Formula: DEX * MEC / 100"
Now there is a serious one - the formula used in actual game is totally different, and all data in this column is plain wrong (while correspond to deciphered formula listed above). Its likely due to game rules change happened after the Book went to print. There is an oddity with it tho - formula used for Merge didnt changed from ver1.0 to ver1.13, while table list already updated from ver1.0 formula for RepairPoints. Actual in-game formula for Merge is:
[MergeChance = Mechanical - (100 - Dexterity)/2] Not affected by Breath.
MergeChance is compared with Roll 100 after, and Merge is succesful if its not less. Note, that this formula used only for creating Modified weapons from some weapon and ChunkOfSteel. Unsuccessful merge likely would result in damage (based on how much the failed roll was failed) of one or both merging items (while their conditions on its own is not affecting the chance). Applying a damage equal or more than item condition will lead to destroying that item entirely. Other non-explosive merges have no chance to fail.
Explosive items merges use a Roll 100 and Explosives skill, but instead of check for success or fail, using them for determining the condition of merged item instead (together with conditions of merging items involved, unlike a ChunkOfSteel merge). Those merges cannot fail, and worst possible condition of merged item could be not less than 10% (thats it, any merc could safely merge any explosive items, with only danger arising from it is possibility of creating a low-quality item).
--------------------------------------------------------------------------------
"Unjam Gun: The chance of a merc successfully unjamming a weapon by trying to fire it.
Formula: (MEC / 2) + 20 "
This one is correct and very simple:
[UnjamChance = Mechanical/2 + 20] Not affected by Breath.
UnjamChance is compared with Roll 100 after, and Unjam is successful if UnjamChance is not less. Condition of weapon do not matter.
Note: while technically speaking, Ammo DO have condition% set to it, its not used in actual game; the only thing affecting Jamming is gun condition:
[JammingChance = GunCondition + rnd{0-49}]
JammingChance is compared with Roll 100 when gun is fired, and its not Jammed if JammingChance is not less (so gun in 99% condition can jam, unlike a gun in 100% condition).
--------------------------------------------------------------------------------
"Pick Locks: The level of the lock that this merc is capable of unlocking with a Locksmith Kit in perfect condition.
Formula: MEC * WIS/100 * DEX/100 + LVL * 5"
See a stuff about Doors for more detailed explanation. As the formula above already has been taken from it, its correct indeed:
[Picklock = (Dexterity*(Wisdom*Mechanical/100)/100 + 5*ExpLevel)*LocksmithKitCondition/100] Not affected by Breath.
Picklock is compared to DoorStrength value later to at least meet it for success.
Game also use a version of this formula with a different rounding (with possible better results for some mercs) for the JournalSafe:
[PicklockJournaSafe = (Dexterity*Wisdom*Mechanical/10000 + 5*ExpLevel)*LocksmithKitCondition/100] Not affected by Breath.
Post edited August 02, 2020 by DarzaR
DarzaR
New User
Registered: Sep 2013
From Russian Federation
Posted August 02, 2020
"Force Doors: The level of the lock that this merc is capable of prying open with a crowbar, with perfect health and fully rested.
Formula: (HEA / 4) + (HEA / 8)
Force Crates: The base strength to open boxes by force, with perfect health and fully rested. A crowbar increases this ability.
Formula: (HEA / 2)"
See a stuff about Doors for more detailed explanation.
[BaseStrength = (CurrentHealth + BandagedHealth/2)/2*Breath/100],
further modified by [CrowbarBonus = BaseStrength/2],
resulting in [Strength = BaseStrength + CrowbarBonus]. Affected by Breath.
Strength is compared to CrateStrength value, with Crowbar using being optional, or to DoorStrength*2 value, where Crowbar using is mandatory.
Note, that despite table values looks like right (i didnt checked all of them), Formula: (HEA / 4) + (HEA / 8) for doors is misleading, as it results in different rounding for some mercs. Say, it would provide a wrong value for Pops ({38/2 + 38/4 = 14*2}, but {38/4 + 38/8 = 13}).
--------------------------------------------------------------------------------
"Stealth: The base ability to move quietly. It affects how far away the merc's movements can be heard by opponent and how successful any attempts to sneak are likely to be. (Not to be confused with camouflage, which determines how good a merc is at not being seen.)
Formula: (DEX / 2) + (LVL * 5)"
Another simple one, but additionally affected by many other factors.
[Stealth = Dexterity/2 + 5*ExpLevel] Affected by Breath.
Note, that despite base formula for Stealth remained the same, rule for walking/swimming generated noise was changed by Sir-tech official patches somewhere prior v 1.13. Due to it, now non-stealth movements tends to produce more noise, while stealth attempts are more probable to succeed (while still pretty much useless, as main ways of detection are unaffected by stealth).
Formula: (HEA / 4) + (HEA / 8)
Force Crates: The base strength to open boxes by force, with perfect health and fully rested. A crowbar increases this ability.
Formula: (HEA / 2)"
See a stuff about Doors for more detailed explanation.
[BaseStrength = (CurrentHealth + BandagedHealth/2)/2*Breath/100],
further modified by [CrowbarBonus = BaseStrength/2],
resulting in [Strength = BaseStrength + CrowbarBonus]. Affected by Breath.
Strength is compared to CrateStrength value, with Crowbar using being optional, or to DoorStrength*2 value, where Crowbar using is mandatory.
Note, that despite table values looks like right (i didnt checked all of them), Formula: (HEA / 4) + (HEA / 8) for doors is misleading, as it results in different rounding for some mercs. Say, it would provide a wrong value for Pops ({38/2 + 38/4 = 14*2}, but {38/4 + 38/8 = 13}).
--------------------------------------------------------------------------------
"Stealth: The base ability to move quietly. It affects how far away the merc's movements can be heard by opponent and how successful any attempts to sneak are likely to be. (Not to be confused with camouflage, which determines how good a merc is at not being seen.)
Formula: (DEX / 2) + (LVL * 5)"
Another simple one, but additionally affected by many other factors.
[Stealth = Dexterity/2 + 5*ExpLevel] Affected by Breath.
Note, that despite base formula for Stealth remained the same, rule for walking/swimming generated noise was changed by Sir-tech official patches somewhere prior v 1.13. Due to it, now non-stealth movements tends to produce more noise, while stealth attempts are more probable to succeed (while still pretty much useless, as main ways of detection are unaffected by stealth).
Post edited August 02, 2020 by DarzaR
gamesfreak64
Service with a smile :D
Registered: Sep 2014
From Netherlands
Posted August 02, 2020
Omg, JA1? thats the first jagged alliance game with the huge pixel characters?
That game is almost ancient i bought it as soon as i saw it in the shops after it was released.
It had a nice paper manual with a shiny hardcover, those where the days, retail games with paper manuals.
That game is almost ancient i bought it as soon as i saw it in the shops after it was released.
It had a nice paper manual with a shiny hardcover, those where the days, retail games with paper manuals.
Jee20Pee
New User
Registered: Mar 2017
From Germany
Posted November 19, 2020
deleted
Post edited November 20, 2020 by Jee20Pee
thedkm
New User
Registered: Oct 2012
From France
Posted December 15, 2020
(deleted)
Post edited December 15, 2020 by thedkm
DarzaR
New User
Registered: Sep 2013
From Russian Federation
Posted December 15, 2020
Post edited December 15, 2020 by DarzaR
thedkm
New User
Registered: Oct 2012
From France
Posted December 15, 2020
(deleted)
Post edited December 15, 2020 by thedkm