UFOpaedia - User contributions [en]

Talk:Incendiary

2021-07-09T00:17:26Z

Mugwump: /* Advantages/Disadvantages of using Incendiary for nighttime light */

== General Comments ==

For now, we'll just say the smoke + incendiary stun effects only work on X-Com owned units until some tests can be run to confirm this. It's unusual that only X-Com units are affected, but the game has been known to surprise you even after you think you've worked something out.

- [[User:NKF|NKF]]

----

Given how aliens love to hang around in a smoke-filled crashed UFO, IC rounds would be insanely powerful if they did actually work against aliens in smoke. I'm glad they don't ''seem to'', as I'd be very tempted to cheat with it. They do work against aliens standing in fire, though, which is still quite cheaty...--[[User:Ethereal Cereal|Ethereal Cereal]] 21:35, 5 May 2006 (PDT)

:I do consider the "standing on fire + new IC explosions = damage" a cheat. So I just don't abuse it. I only use IC rounds to illuminate or to finish off hiding aliens. It can also work as a "pass-through-and-die" tactic, the same way Proximity Nades work, although fire damage is pretty sad xD. --[[User:Nekrocow|Nekrocow]] 00:36, 24 June 2012 (EDT)

:: I use it a lot in TFTD to clear out those island bunkers and the upper storage levels of the large train station. Either the aliens roast alive, or they come out. Otherwise yes, it's no doubt a cheat. Well, more a bug exploited as a cheat. -[[User:NKF|NKF]] 02:09, 24 June 2012 (EDT)

-----

I just edited the Incendiary page a bunch, because Brunpal's [[Talk:Experience]] questions about Incendiary sparked my interest... I never did test IN vs. experience. It's a very good question ''if'' it turns out to cause Firing experience. But while reviewing this page, I had a number of questions, for anyone interested. Also, I only tried to clarify things, and don't know Incendiary well, so fix anything you know I got wrong:
#Did I get it right re: the set [ 0, 5, 6, 7, 8, 9, 10 ] for chance of initially catching fire? I over-wrote "linear" because it seemed odd when XCOM usually goes, e.g., 0-10. (Who tested this? - A little help here please. Just making sure.)
#Why flame a zombie unless it's near death (and how can you know if it is)? It's been a long time since I used fire - if you don't have flying armor, why mess around with a zombie by burning it, why not Heavy Plasma it.
#Any research/data on tile flammability versus duration of burning is appreciated. Probably it should go on the [[Terrain]] page byte, but be clearly referenced here. It's just a curiousity, but an interesting one.
#The last line of the page says ''"The damage values listed in the UFOpaedia do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames."'' Does anyone know IN strength vs radius, then? Should be easy to test and post.
#NKF, Zombie, or anyone else... would you mind seeing if Incendiary causes the Experience counter to increase? Brunpal is right that it's important to [[Experience]]... I found [[Small_Launcher#Experience|Stun Bombs]] to count for experience across their whole range, even if no stun damage occurred... if you have 11+ Mutons in a firing squad situation, passing around an [[Auto-Cannon]] with Incendiary may be better than standard pistols, depending on the range of the blast. I could test it, but it's been a long time since I've delved into the files; maybe one of you have them more close to hand. [[User:MikeTheRed|MikeTheRed]]
-----
:Offhand, the only way I could think of to check the remaining HP on a Zombie would be by using a [[Mind Probe]]. Given the relative uselessness of a Mind Probe after Psionics are developed, as well as the time needed to use the Probe once, this seems a rather impractical course of action, unless your Rear Commander has nothing better to do. I agree, Heavy Plasma on Auto is better. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 1 August 2008 (PDT)
-----
#Yeah, the set is correct. When a unit is shot with an incendiary round, the game does a calculation to determine if the unit catches fire. If it doesn't catch fire, the unit takes no damage (the 0 in the set). If the unit does catch fire, it will take between 5-10 damage points. Stupid discontinuous range, but that's what happens. As you may guess, I did the Incendiary trials over at the StrategyCore forums in the Damage Modifier topic - see [http://www.strategycore.co.uk/forums/index.php?s=&showtopic=746&view=findpost&p=39672 this] post for the particulars.
#Why flame a Zombie? Simple. A Zombie which is killed by an Incendiary round doesn't turn into a Chryssalid. Zombies are easily outrun, so you can just keep picking at them from a short distance with Auto-Cannon Incendiary rounds and then running away. Fairly effective, even when your troops do not yet have armor to protect them. And when you do not have the luxury of the Heavy Plasma early in the game, Incendiary is a good way to avoid an overabundance of Chryssalids who are not so easy to kill. As for checking the Zombie's stats, you can only rely on the Mind Probe or Psi. Neither are available early either (the Mind Probe is usually low on the research tree for most people even though you can collect enough, and Psi is difficult to use as a soldier needs to be quite proficient to use MC.
#I have been meaning to do some tests in flammability vs terrain but only recently started fooling with MCD values. It'll be next on my list.
#Here, I uploaded a very recent spreadsheet containing both I and Smoke when damage values are hacked. See [[Media:Incendiary_and_Smoke_Patterns.zip | this file]] which contains both.
#I think I fooled around with Incendiary recently in conjunction with promotions. Soldiers who shot aliens with "I" didn't get promoted. Logically, that would mean the experience counter didn't increment. UNITREF.DAT would need to be checked to verify though. Addendum: indeed, as BB mentioned in the experience page (and a quick glance at the UNITREF.DAT experience counters by myself to triple-check my aging brain), Incendiary rounds do not increase any of the experience counters.

Hope this clears up some of the issues/concerns here. --[[User:Zombie|Zombie]] 21:16, 1 August 2008 (PDT)
----
<i>"The damage values listed in the [[UFOpaedia]] do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames. Fire is unlike other damage; it works at initial blast and then over time, as described above."</i> and
<i>"Initial "impact" damage from incendiary ammunition is either for no points (unit does not catch fire), or between 5-10 points (unit catches fire)."</i>

This should be stressed on ALL the various relevant pages. It's important. 6.4 dmg vs 90 dmg is a significant difference!--[[User:Brunpal|Brunpal]] 09:31, 2 August 2008 (PDT)
----
It looks like Incendiary is gaining some clarity (at least for me), thanks for starting it Brunpal...
*The "6.4" was only for the initial IN round impact (set [ 0, 5-10 ]); it can then burn for 4 more rounds (set [5-10]). Perhaps a short way to state this complicated damage type is "Minimum 0 (unit does not catch on fire) ''OR'' unit catches on fire 1-5 turns, 5-10 damage/turn, 5-50 damage in total (average 21.5)". Does that look right, Zombie? I'm not sure where you got 90 from Brunpal...
:90 is the listed damage from an IN rocket.--[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)
*However, the numbers I just stated do not count possible additional damage from nearby terrain being on fire (as opposed to yourself). Maybe those should be included somehow. (And clearly, fire is much more dangerous outdoors than inside UFOs, where terrain does not burn.) But since terrain fire can last a variable number of turns, I guess you can't have a maximum damage. Average terrain damage from fire would be 6.5/terrain (1-12), but also, it can keep the unit itself burning more than 5 turns... hard to model.
*Good point about flaming zombies, Zombie. I guess you ought to know, eh? :)
*The spreadsheet looks great. Perhaps one of us can pull out the area patterns for non-hacked IN weapons and put them on the relevant pages. When it's done, the spreadsheet itself would be an asset to Incendiary (or maybe [[Damage]], if it's listing all types of damage). As has been stated, it's the size (area) of the blast that actually directly relates to incendiary weapon "strength"... the diameters you found are probably what should be in parentheses next to weapon strength, although damage can appear as well.
*Ok, no experience from Incendiary blasts. It might've been real interesting if there were, but it didn't occur to me to test. (Or maybe I tested it briefly so long ago that I forgot.) I would've guessed that they did, because the stun bomb and explosives do. Oh well.
*P.S. Brunpal, we may not have touched pages in a year, but most/all of us have "Watch this page" turned on, so we get immediate notification of any pages we've edited or Watched. :)
-[[User:MikeTheRed|MikeTheRed]] 09:17, 5 August 2008 (PDT)
----
*Sounds correct MTR. I think Brunpal was just comparing the "damage" (actually strength) of the Incendiary Rocket (90) to the average damage due to the "impact" of the blast (6.4).
*Well, it isn't ''nearby'' terrain on fire which you have to worry about, it's the tile directly underneath a units feet which causes the most concern. If that tile is on fire and the unit doesn't move, it will take 1-12 damage points. While true that terrain on fire can last a variable number of turns, there is a definite upper-limit to how much damage a unit can possibly take. Fires don't last forever, and the combustibles eventually are consumed leaving either scorched earth or a damaged tile. Those damaged/destroyed tiles usually cannot be started on fire again by the spread of flames. They can only be set ablaze with incendiary ammo, and even then for only 1-3 turns (normal for dead tiles). So it's certainly possible to find a max damage. And for the most part, the things that burn the longest are usually objects, not tiles. And most objects you can't stand on anyway. But I totally agree that it's hard to model how fire functions due to the two forces at work: "impact" damage and damage due to standing in fire.

P.S. Some of us are actually around here and don't need to be coaxed back into existence by an email when a watched page is changed either. Just because it's quiet, it doesn't mean nobody's home. :) --[[User:Zombie|Zombie]] 20:34, 5 August 2008 (PDT)
----
While understanding the whole formula for fire and fire damage happens is useful, it was not thinking to go that broad. I was just interested in what occurs from the moment a solider takes his shot, to the time that solider gets his TU back. ie damage from incendiary rounds vs fire damage. --[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)

----
It looks to me that, unlike all other forms of damage, Fire damage ignores armor, goes right past it. If so, this should be made explicit on the main page? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 05:55, 30 May 2021 (UTC)
:Fire damage doesn't ignore armor - power suits for instance can't be damaged by fire, except if the unit is already injured. Read carefully the Damage section - there's a lot of nuances about how fire works. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 03:03, 1 June 2021 (UTC)
:: What I meant is ignore armor ratings for damage calculation. While accounting for the resistances listed on the Damage Modification page, doesn't incendiary act as if front, side, back and under armor are 0 for calculation? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:21, 1 June 2021 (UTC)

== Incendiary vs Large Units ==

We're discussing this in [[Talk:Sectopod#Incendiary vs Sectopod]], and a question came up. When an IN round impacts one segment of a large unit, presumably that segment gets the "Incendiary impact" function, i.e. 6/7 chance of catching on fire for 5-10 damage plus 1-5 turns of being on fire. Does the same "impact" function also apply to the 3 adjacent squares (6/7 chance), or is it just the "standing in fire" chance? If you had multiple regular-sized units standing in the area of effect of an IN round, they would each get "impact" effects (right?). So it ''seems'' logical that all 4 segments of a large unit, inside the area of effect, are also exposed to "impact" effects. But I wanted to check. [[User:Spike|Spike]] 06:34, 9 March 2009 (CDT)

Oh boy! Calculating this not only depends on a lot of unknown assumptions, but is fiendishly complicated - especially if you factor in the "funky fire" bug. And contrary to my noblest efforts, it's impossible to use IN weapons without inadvertently exploiting this bug. Even if you only fire IN at a single target until it's dead, once the target is "standing in fire" you effectively just can't miss.

Anyway back to the Large Targets specifically. The key assumption above is whether all regular-sized units in the area of effect of an IN burst are affected with "impact effects" - 5-10 dmg & 6/7 chance to catch fire. If they are, it's reasonable to assume the same thing happens to the 3 other segments of a Large Unit. However I suspect this is not the case, and strictly speaking "impact" effects should only occur at the single, impact square of an IN round. Testing needed!

More likely, the GZ+1 squares, whether occupied by small or large units, are only subjected to the "standing in fire" effects: 1/3 'catch fire' probability, and 1-12 terrain-based damage. And these effects are applied once per turn, not once per hit.

However, all of this is turned on its head by the 'funky fire' bug. After the first round hits, all units (and all Large Unit segments?) are "standing in fire". (Though maybe these fire damage routines run only for the "control" segment of the Large Unit? Possible, but unlikely.) Since they are standing in fire, the funky fire bug applies and all units/segments are hiit with "impact" effects.

So assuming a Large Unit is ''already'' standing in fire (e.g. from a previous IN hit or near miss), damage per IN round fired is 6.4 x 4
= 25.6 average, 10x4= 40 max. Subject to resistance/vulnerability modifiers, but ignoring armour level. In addition as multiple IN rounds are fired, the chance of all segments catching fire quickly approaches certainty. This not only means the Large Unit will sustain further damage at the end of the turn, it makes it impossible to escape the 'funky fire' trap by moving out of burning squares.

(Any testing needs to be very careful and probably only fire a single IN round per game, otherwise 'funky fire' will skew the results.)

So, in conclusion, the TU/kill factors I put up on the Talk pages for the Large Units ([[Talk:Reaper]], [[Talk:Cyberdisc]],[[Talk:Sectopod]]) should pretty much reflect the 'funky fire' reality after the first round connects, apart from the fact that you actually can't miss. The very first IN round to be fired would have the same effect (for immediate damage) on a Large Target as on a small one. But I really don't want to update the numbers to reflect this fact, it's just too awful. For AC-IN, the firepower factors will be about 6 times better than stated. Maybe I'll just remove them. :(

[[User:Spike|Spike]] 15:51, 10 March 2009 (CDT)

=== Simple Tests ===

I did a small number of tests and found some interesting results. In 5/5 tests, all 4 squares of the target (Reaper) were on fire the following round. (It's hard to tell if they are on fire the same round, as you need to extinguish the fire with smoke to see). Perhaps this makes sense, as it's a UNITREF attribute and so applies to the whole unit, not its 4 component squares?

Looking at the damage, it looks like "impact" and "on fire" damage applies to all 4 squares, i.e. x4 normal. Damage clusters tightly around 16-18 per hit which is roughly the expected value, maybe a bit lower (at x4). And since we '''are''' on fire, should expect an average of 7.5 ({5..10}/6) rather than 6.4 ({0,5..10}/7? Maybe something else is going on here, as these numbers seem a little low - 6.4 x 4 = 25.6 per hit or 7.5 x 4 = 30.0 per "on fire" hit might be expected on a Large Unit.

:Drat. I didn't factor in the Reaper's 170% Susceptibility to Incendiary. So the actual damage levels are more like 10 per hit. Maybe there is no multiplier for the 4 squares? Hard to figure out what's going on here. In tests on hacked humans, armour level is not a factor vs Incendiary damage, otherwise I'd suspect the under-armour or something. 2.5 avg damage per segment seems too low. 10 average damage per alien seems too high - that should be the max, not the average. Is some mechanic pushing the average up to the max? I don't have a clue right now. [[User:Spike|Spike]] 06:53, 11 March 2009 (CDT)

The damage seems to be regardless of "funky fire" effect. A round fired at a target that is not burning / in fire seems to do about the same damage, per hit, as one that is in fire / on fire and so subject to the funky fire bug. So the only 'bad' effect of the bug is that you never miss, and you hit everything that is in fire / on fire. Not quite so bad, and it allows you to play honest by only ever firing at one target, not hitting any other targets by accident (!), and firing from point blank range so it doesn't matter that you never miss.

Burn Time was as high as 7 when multiple IC rounds were fired (on auto). Higher than we thought possible (1-5 range expected). However it sometimes goes DOWN after additional hits. Possibly the value is re-randomised with every new IC impact, but hits are cumulative while firing auto bursts?

Here's the raw test data:

Test 1.
-
2 DH on Reaper, mix of auto and snap, some other IC impacts on others
Burn Time=7 - exceeds known limit of 5
All 4 sq on fire next turn
Is 'on fire' global? It's in Unitref, so maybe
-
Test 2.
-
1 DH on Reaper, only IC shot fired in game.
In firing turn, taken 132/148 = 16 damage. Burn time=3
Start of T+1, taken 122/148 10 more damage, Burn time=2
T+1 Reaper shows all 4 squares burning
-
Test 3.
-
Revisit #2 firing turn... fire another round (this will use funky fire)
So 2nd IC hit, 2nd rd fired, same target.
Health now 114/148, further 18 damage
But Burn time has dropped to 2! Must re-randomise on each hit??
Maybe only accumulates during auto burst?
-
Test 4.
-
Let's try lots of hits. Hack up accuracy to 255
OK 3 out of 3 hits on Auto
T+0 Health=98/148=50 damage (17 avg) Burn=6
T+1 Health=81 (17 more dmg) Burn=5 All 4 squares on fire.
-
Test 5.
-
Revisit #4 and push to 6/6 hits
T+0 Health=41/148=107 (18 avg) damage Burn=7
T+1 Health=21 (20 more dmg) Burn=6 All 4 squares on fire.
-
Methodology (Apart from Test 1) = only ever 1 (same) target in any IC AoE; no misses
(To try to minimise the impact of 'funky fire' effects - but can't eliminate)

[[User:Spike|Spike]] 23:27, 10 March 2009 (CDT)

I re-ran the same simple tests against a regular-sized (Floater) target instead. The results agreed much better with the 'standard model' of [[Incendiary]] effects. All results were within the permitted ranges in the 'standard model', though some values were unexpectedly. I think some variables to look for in Incendiary mechanics are:

* Large Unit vs regular unit behaviour looks to be different
* Auto burst vs single explosion looks to be different (maybe just due to funky fire bug, maybe not)
* Tile MCD "time to burn" value seems to affect one or more of the other calculations / probabilities
* Burn Time on the unit can go up as well as down. New hits seem to re-randomise the value.
* End of turn processing does not always reduce unit Burn Time by 1. Can a terrain fire add to unit Burn Time?

[[User:Spike|Spike]] 21:25, 11 March 2009 (CDT)

:I doubt a terrain fire adds to the time a unit is on fire. Actually, I'm quite positive on this since my tests from a while back were quite thorough. The counter can only tick down to 0, and when it does a terrain fire will have a chance of "reigniting" the soldier again.

:Anyway, I had to start from scratch again on testing due to a few issues with my test scenario. I totally forgot that the first soldier on the unit roster is a bad choice for a "designated hitter" since he can never be automatically selected on a reload. Soldiers lower on the order are much better choices. So I got the shooting automated, but each reload was taking too much time since I had to reselect the shooter, select the shot, move the view down a level, shoot the target and abort. Having the soldier already selected cuts out 2 actions in the list allowing the script to run more efficiently. I'm going to try to get everything properly setup tonight, then start testing tomorrow morning. With a little luck and about 2 hours of babysitting the script to make sure it doesn't quit, I should have some prelims. --[[User:Zombie|Zombie]] 21:55, 11 March 2009 (CDT)

----
Looking forward to seeing that data! I did some more testing just for the special case of Large Units, about 40 tests. My tentative conclusions:

# Damage range per 'impact' hit is the same as regular units, around 5-10 x Vulnerability (maybe + MCD Burn time?)
# Large units go on fire about 1/7 of the time when receiving a direct hit - as expected
# Either all 4 segments go on fire, or no segments go on fire - no 'part segments on fire'
# Unit burn times are not correlated with unit damage received
# Auto fire has the same average damage level per hit as snap fire
# Unit Burn Time can exceed 5, both on Snap and Auto. Highs of 6 (Snap) and 7 (Auto) were seen. Maybe 1-5 + MCD Tile Burn Time?

All my tests were done on the grid-lined pavement tiles from urban terror missions, which have an MCD default burn value of 2. For some of the "setting the large unit on fire" tests, I had the target floating in mid air, because air does not burn even during the turn that the IN round explodes - it makes it easier to see the unit burning.

From Bomb Bloke's editor notes, the 4 potential MCD tiles in a map location are: a North Wall, a West Wall, a Ground tile, an Object tile. All 4 of these MCD tiles might have a burn time value. But Ground and Object are the most likely to be relevant.

[[User:Spike|Spike]] 21:58, 12 March 2009 (CDT)

:Ok, I got the script running and optimized it a bit to cut down some wait cycles. Right now it's cranking out approximately 400 trials per hour which is about as fast as I can make it go without removing some desktop icons (all the icons have to refresh at the end of each logging cycle which takes a little time). Anyhow, just for giggles I stopped it after 400 trials to get some prelims.

:<table {{StdCenterTable}} class="sortable">
:<tr {{StdDescTable_Heading}}><th align="left" width="90">Damage</th><th width="90">Count</th><th width="90">Pct%</th></tr>
:<tr><th align="left">1</th><td>68</td><td>17.0%</td></tr>
:<tr><th align="left">6</th><td>58</td><td>14.5%</td></tr>
:<tr><th align="left">7</th><td>45</td><td>11.3%</td></tr>
:<tr><th align="left">8</th><td>63</td><td>15.8%</td></tr>
:<tr><th align="left">9</th><td>55</td><td>13.8%</td></tr>
:<tr><th align="left">10</th><td>64</td><td>16.0%</td></tr>
:<tr><th align="left">11</th><td>47</td><td>11.8</td></tr>
:</table>
:If you average the percent columns, it comes to 14.28571429% while the expected is 1/7 or 14.285714285714285714285714285714 which is a difference of 4E-09. This means 400 reloads is plenty enough values for this application. Great news! Well, as you can see, instead of the set [0, 5, 6, 7, 8, 9, 10] for MCD of 1, this scenario where the MCD was 0 is shifted up by one [1, 6, 7, 8, 9, 10, 11]. Interesting.

:Tomorrow I'll rerun the MCD 1 scenario again to verify the values and damage set. Then it's on to the MCD of 2. --[[User:Zombie|Zombie]] 01:50, 13 March 2009 (CDT)

:: Extremely interesting! By the way, it was probably a late night but - the average any 7 numbers that (must) add up to 100% is always going to be 1/7th of 100%, so that result doesn't really demonstrate any confidence in the data. It would be the same with one result, or with a trillion results. The 4E-09 discrepancy is just the precision error in your calculator/spreadsheet's calculation of the percentages and the average of the percentages. You've got some considerable variation from 1/7th on the individual numbers, I'm not sure if that's just to be expected with only 400 trials. But for example "0" and "10" are both a bit high so it ''might'' be non-linear (probably not). Anyway we'll see when all your results are in! (To measure the degree of variation from the expected result, what you want is a chi-squared test or something - and I don't know what I'm talking about there so I'll shut up!)

:: I'm checking Bomb Bloke's MCD database, and there are some tiles in there (U_BASE 22-25) with MCD burn value of 30 - I might play with those and see if anything dramatic happens. Oh except looks like they can't be set on fire (255 flammability). There are others that are quite high (8-), and still flammable. Or I could hack an MCD file (scary). Maybe I'll just wait for your results Zombie! [[User:Spike|Spike]] 05:49, 13 March 2009 (CDT)

= Incendiary Research =

== Large Units On Fire ==

Here's another interesting test for setting Large Units on fire. Set AC-I power down from 42 to 1.
At this IC power, there is no area effect. You can't even start a fire on one tile.
All you can do is set units on fire with a direct hit. This means there is no way the other 3 squares of the
Large Unit are in the IC area of effect.

Result: Whether you hit a one square regular unit or a 4-square large unit, if it goes on fire, '''all''' squares of the unit still go on fire. Along with the fact that the inflicted IN damage level vs Large Units is basically normal (see above), this tends to confirm that being on fire is a "unitref" property and, unlike HE and Stun Bombs, is not applied (multiplied) vs the number of squares the unit occupies. (In fact it would be good to check that HE is actually applied separately to each square, with different HE strength, potentially different armour facing, etc. Maybe the engine just simplifies things and multiplies damage by 4?)

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)

== Unit Burn Time ==

Unit Burn Time seems to be considerably '''cyclic''' rather than random. Very often, it just steps down by one from the previous value. I suspect this is because the "impact" routine calls the "end of turn" incendiary/smoke routine (see [[User talk:Seb76#Incendiary Bug]]). Sometimes it does not happen, maybe because some other factor has caused the Burn Time to increase.

Here's some data. This was done against a Reaper with AC-I power set to 1 (and 10% TU Snap fire cost). But I've seen similar results with standard AC-I.

Hit H/H Dmg/Avg Burn Time
1 137/150 13 2
2 126/150 11 1
3 104/150 22 0 Very high damage (=13x1.7). Unit not on fire when game restored.
4 96/150 8 7
5 81/150 15 6
6 66/150 15 5
4,5,6 76/150 /9.33 5 (Auto) 9-10 (=5-6x1.7) is near minimum dmg
7 56 10 4
8 48 8 4 What happened here? didn't cycle. MIN dmg (5x1.7).
9 35 13 6
10 25 10 5
11 10 15 6 New shooter takes over
12 2 8 5

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)
:You're right on spot once again ;-) When a unit takes a direct hit from an IN round, it is set on fire (the duration is randomly chosen between 0 and incendiarydamagemodifier/20). Then the "end of turn" routine is called, which inflicts damage *and* decreases by one the number of turns to be on fire (done for all units). Then it sets on fire units standing in blaze. The duration is calculated as for direct hits; if the unit was already on fire, it'll take the maximum value between the new value calculated and the current value affected to the unit on fire. Not sure it is readable but I think you'll sort it out ;-) [[User:Seb76|Seb76]] 10:51, 15 March 2009 (EDT)

== Incendiary in TFTD ==

I read [[Weapons (TFTD)#Phosphor|somewhere]] there are reduced effects underwater (or enhanced effects on land) for TFTD Phosphor rounds. I couldn't find an exact statement of the quantitative difference - does anyone know this? [[User:Spike|Spike]] 14:53, 9 March 2009 (CDT)

:The effects of Incendiary weapons underwater (or Phosphor, as TFTD refers to it) is halved over the UFO equivalent. Incendiary weapons are doubly effective on the surface(Terror Missions) vs underwater, but of the three weapons that can fire Incendiary, two of them(Torpedo Launcher and Hydro-Jet Cannon) can only be reaction fired on land. The Gas Cannon can be fired in eiither location. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:08, 9 March 2009 (CDT)

:: It's clear that the effect underwater is half the effect on land. But does the base level (in USOPaedia / OBDATA) refer to land use or underwater use? [[User:Spike|Spike]] 15:13, 9 March 2009 (CDT)

:As I recall, the base level is on land. The numbers for Phosphor ammo are close to the UFO Incendiary damage numbers, but I know it spreads less underwater. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:15, 9 March 2009 (CDT)

:: Look at the (puny) area effect pattern sizes underwater, that sounds about right. Can anyone confirm this? [[User:Spike|Spike]] 15:40, 9 March 2009 (CDT)

There is actually no difference between the pattern for the Gas Cannon's P rounds underwater as on land. Both have a r=3, d=7 pattern. (CE version at least). Maybe the pattern is smaller the deeper you go? --[[User:Zombie|Zombie]] 16:45, 9 March 2009 (CDT)

<gallery widths="200">
Image:GC-P (underwater).png|Flame pattern from Gas Cannon Phosphorous rounds underwater.
Image:GC-P (on land).png|Flame pattern from Gas Cannon Phosphorous rounds on land.
</gallery>

:OK now I'm really confused then! (I realise I was getting confused with the Dye grenade's small footprint vs Smoke grenades). If the blast pattern is the same size, that implies the weapon power is unchanged. So in what sense is Phosphorus "half as powerful" underwater? Does it burn half as long? Is the impact and fire damage halved? [[User:Spike|Spike]] 16:49, 9 March 2009 (CDT)

I really doubt the damage to units would be affected if the power of the round was modified. The power of the round only determines the size of the pattern produced, not the damage inflicted to units. I'll have to check the burn times and spread rate but my thought is that the two are identical in the version I'm using. Like I said, the pattern may get smaller the deeper you go underwater. The pic above was for a shallow site. It'll take a while for me to find a deeper site to check it out, otherwise some editing of the game files may be necessary to force the scenario.

I just checked the Dye Grenade underwater and on land. Both produce the same r=1, d=3 pattern. So yeah, they are really pitiful when compared to the Smoke Grenade.

Don't really go for the use of "impact" damage with Incendiary/Phosphorous rounds. There is no real impact since the damage range is discontinuous. The unit either catches fire from the splash of fire (in which case it does 5-10 damage points), or the unit doesn't catch fire and the unit remains unharmed. If there were such a thing as impact damage, the range would be continuous like normal weapons, in this theoretical case it would be [0-10] inclusive (ie the set [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. --[[User:Zombie|Zombie]] 17:36, 9 March 2009 (CDT)

Anyway, the half thing came up because AQ was comparing TFTD to UFO, not comparing the effects in TFTD from underwater and on land. However, further comparisons reveal that a hacked HC-I round of 60 produces the same pattern as a GC-P/60 round. Perhaps this whole dilemma can be traced to the Dye Grenade? --[[User:Zombie|Zombie]] 18:28, 9 March 2009 (CDT)

:That's entirely possible the Dye Grenade is the source. However, several of the pages for the TFTD weapons state that Phosphor is far weaker in water, so I didn't check. My mistake. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:35, 9 March 2009 (CDT)

Thanks for the feedback everyone. So this could just be a recycled rumour? I guess the general assumption is that the game engines are identical, so we would want evidence that TFTD is different. Looks like Zombie has proved that the area effect is equal (at least at shallow depths). That leaves only the fire damage or fire duration. Testing that would require repeated observations to check if fire damage is less than 6/hit, less than 6/turn, and burning for no more than 2-3 turns. [[User:Spike|Spike]] 20:14, 9 March 2009 (CDT)

:As with any wiki where contributions can come from anywhere, there are bound to be problems with validity of the statements made. So unless those statements are backed up by real-life test data instead of memory or hearsay, take them with a grain of salt. The other point is to avoid spreading disinformation at all costs (I have been guilty of this as well, but try to at least quantify them). So there you go. I'm still trying to get a deeper underwater mission to check the size of the pattern produced there. Checking the spread of flames or damage inflicted to units shouldn't take too long though. I'll see if I can't get that done tonight yet. --[[User:Zombie|Zombie]] 20:23, 9 March 2009 (CDT)

:Ok, I ran some trials with an unmodified GC-P round on the normal seabed floor against soldiers having 100 health and 0 all-around armor. For the guy standing at GZ, I saw ending health values of 99, 94, 93, 92, 90, and 89 (n=50). So that comes out to 1, 6, 7, 8, 10 and 11 points of damage respectively. I didn't think 11 damage was possible. Here's where things differ though. All the other guys who were clustered around GZ always received only one point of damage, never more, never less. In EU, the guys around GZ took damage equal to the guy at GZ. Odd. So then it occurred to me that perhaps I should check the MCD values of the seabed (TFTD) and the desert (EU) landscapes. Both are basically identical in terms of armor. But the seafloor has a "time to burn" value of 0 while the desert has a value of 1. So maybe our understanding of normal fire isn't totally complete. I'm going to go back to EU and retest the desert landscape with varying MCD burn time flags to see how that affects damage. ;) --[[User:Zombie|Zombie]] 23:00, 9 March 2009 (CDT)

:: The whole Phosphor being half effective under water is related to the burn time and spread, if I remember correctly. The settings in the MCD files may be the culprit. The actual damage dealt or initial spread may not necessarily be affected.

:: Hey, I just had a wacky idea. XComutil. Use its feature where you can set the depth of a mission. Launch a mission on a island terror site map (again, use XComutil's map picker to get to this faster). Lots of grass to burn there. Set fire to it and count how many turns before the fires die out. Redo the test, but this time set the depth to a deeper level. Try the whole process out again.

:: Next repeat this with one of ye-olde seabed maps. They look really weird without the blue palette shift when played on land, what with the landscape being gray.

:: It's possible that the half-effectiveness relates to the fuel that the fire has to burn more than anything else. Further confirmation on how long the flames stick to a target when on land or underwater may be helpful. -[[User:NKF|NKF]] 01:28, 10 March 2009 (CDT)

:I've been burned one too many times using editors or utilities to mess with saved games. Half the time they introduce some unknown "feature" which isn't documented. Thanks, but no thanks. I only test with an unmodified game, except for the changes I make myself to keep control of the situation. Anyway, I tested a patch of fire on the seabed to see how long it remained lit (which has a "time to burn" value of 0). It only stayed lit the current round the shell detonated. After that the fire went out. So this agrees with what is expected. Will continue to work on this as I get time. --[[User:Zombie|Zombie]] 01:51, 10 March 2009 (CDT)

Well, I suppose my recommendation doesn't necessarily need XComutil. It would've certainly made it easier. But yes, it does introduce a few things that work behind the scenes that we might not know too much about. However, if I remember correctly, one of the battlescape savegame files should hold the depth level of the current map you are playing on. All you'll need to do is tweak that to change the depth of the map.

One other thing, the different effect HE has on the same tiles underwater and when on land (ala the Triton) may also be one of the other culprits behind the belief that phosphor is less effective on land. Being able to blow up the Triton on land, but have it appear virtually indestructable when underwater does that. -[[User:NKF|NKF]] 01:59, 10 March 2009 (CDT)

----

re Zombie's underwater tests, there is normally (i.e. on land in EU) a difference between the IC damage on the target of the direct hit, vs lower damage to others in the area of effect (hmm contrary to my IC kill modelling assumptions: uh oh I may've spoken to soon). But only seeing 1 damage on the others in the AoE does seem low. We need to figure out why. Did any of the other targets catch fire? Does that ever happen underwater? Do tiles ever burn past the turn when the IC round is fired? Any of these factors would reduce total fire damage/effectiveness by '''more''' than half. Actually, doesn't it say the 1-12 damage for "in fire" is ''not'' random, but dependent on terrain type? That could be the answer.

The [[Incendiary]] article actually mentions '''4''' modes of fire damage, only 3 of which are quantified:

#"impact",
#"being in fire"
#"being ''on'' fire"

The 4th mode is "damage from burning ''terrain''. Only a tantalising mention is given, no quantitative details. This could be the source of the discrepancy. In fact it might be a component of "being in fire" that's not fully understood. I think Zombie is right to review the assumptions on this one - nice work! [[User:Spike|Spike]] 04:05, 10 March 2009 (CDT)

:As I recall, "damage from burning terrain" is synonymous with "Standing on a tile that's currently on fire." Thus "Being in fire." But that's me and I'm tired this evening, so I could be wrong. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:30, 10 March 2009 (CDT)

I performed my TFTD Phosphorous tests underwater and after the flames died out some of my men did catch fire. So this part seems to jive with that of EU. Tiles do not burn longer than its "time to burn" value in the MCD files. So for instance, in the seabed underwater testing mission, the tiles have a MCD burn value of 0 which corresponds to the results seen (ie fire didn't stick around into the aliens turn or X-COM's next turn either, it only stayed lit the turn it detonated). There really is only 2 "modes" of I/P/fire damage:

<ol><li>The code used for determining if a unit catches fire: 0 damage (if the unit didn't catch and was able to shrug it off) and 5-10 (if the unit catches).</li>
<li>Standing in fire.</li></ol>
At least from the initial tests in TFTD, units outside GZ are just considered to be standing in fire that turn and always take 1pt of damage. Anyway, I don't want to talk myself into a hole without doing more tests. All the following trials I do will be in EU to hopefully curtail any unknowns in TFTD. Once EU's code is figured out then it can be applied and compared to TFTD. --[[User:Zombie|Zombie]] 09:06, 10 March 2009 (CDT)

: If they are "standing in fire", do you think the 1pt damage/turn is based on the fire characteristics tile/terrain type they are standing on? Is it more generally 1-12/turn, dependent on terrain? Also if you get a chance can you test large units and see what kind of effects they take on the GZ+1 squares? If the GZ+1 squares of a large unit are just 'standing in fire' rather than 'catch fire/5-10 impact damage' this will substantially weaken IC vs large units. And I will have shouted too soon! :) [[User:Spike|Spike]] 09:18, 10 March 2009 (CDT)

I did some ad-hoc tests in TFTD. Actually I just ran around firing GC-P and HJ-P rounds everywhere. :) On a typical seabed layout, I found that most things don't burn - the fires don't last into the next turn. The only things I could get to burn were the green moss stuff and and coral skeleton "trees". Even the barrels do not burn. Also, I did not see much sign of terrain damage caused by the fires. But the moss and coral did burn for the normal period, i.e. 1-5 turns.

I also managed to kill an Aquatoid with a single direct hit from a GC-P, in one turn. He died at the end of my turn or the start of his. That seems unlikely. 5-10 from being hit, plus 1-12 for standing in fire, plus maybe another 5-10 from being on fire? It's just about possible I suppose, to max out near 32 damage (if the terrain offers you "12" when it burns). Anyway those are my unsystematic enquiries. I have the 8 save files of various stages of the battle if anyone wants to take a look. It was from a virgin TFTD installation and there was no editing or jiggery pokery.

OK I've uploaded the save files [[Image:TFTD Incendiary Tests 01 Spike.zip]] and taken a look myself with BB's editor. Prior to being hit (Game_4) our Aquatoid was in rude Health, 30/30. Immediately after being hit (Game_2) he was at 19 Health (no Stun damage) and On Fire, as well as Standing in Fire. That implies 11 Damage from the "impact effect" which is not supposed to happen. As noted, at the end of the same turn or beginning of his next turn, he dies. He looks to be standing on a standard seabed square, just sand, the kind of thing that does not burn. He is next to some of the brown cushion-like coral, but I don't think that burns, at least not over multiple turns. In fact in the same turn he is hit, at the end, you can see him dead (Game_3). Since there was only one alien, he died in the same turn. OK that's slightly confusing, maybe someone can double check the turn numbers in the save files (don't know where they are).

[[User:Spike|Spike]] 13:29, 10 March 2009 (CDT)

Doh. I is a idiot. The Aquatoid was killed by the incendiary fire bug - I fired extra IN rounds at terrain objects after he was on fire. Which explains why he is already dead by the end of my turn. [[User:Spike|Spike]] 15:08, 10 March 2009 (CDT)

:Yeah, you gotta watch that. Well, anyhow, I edited the desert landscape in Enemy Unknown to have the same MCD "time to burn" value of 0 as the seafloor in TFTD. From the limited tests, the results look the same as in TFTD. (Fire burns out after the initial turn it detonated, units around GZ taking 1 unit of damage while the guy at GZ got more). So that means I can focus my efforts on EU with little worry because there will be no issues. I'm going use BB's logger and AHK to automate the data gathering aspect to save me a bunch of time. I'll probably need the full requisite 2000 reloads though, as the guy at GZ is not the same as the 24 soldiers around him. Wish me luck. :) --[[User:Zombie|Zombie]] 15:54, 10 March 2009 (CDT)

Good luck! I just read the MCD article, and it mentions 2 fire-related byte fields in MCD - "likelihood of catching fire" as well as "time to burn". Is the last field variable or fixed? Could the first field determine the damage/turn to units when it's on fire? Also with a possible 4 terrain items that could all be burning, is the maximum damage higher than 12? [[User:Spike|Spike]] 16:10, 10 March 2009 (CDT)

:Offset 45 is the flammability rating of the tile. This most likely controls whether an adjacent fire will spread to the tile in question. (For instance, if a fire is burning and the next tile over is a tree or something, it'll probably spread there fast because of the combustibles present). The other byte is offset 57 which is the one we are after. Don't know about the 4 types of things which can exist on a tile at once. I think the most I have ever seen is 2 (usually ground and a wall). Wouldn't hurt to edit a tile to include all 4, but that's an entirely different test to do. It'll have to wait until we get a better understanding of basic fire. ;) --[[User:Zombie|Zombie]] 19:38, 10 March 2009 (CDT)

::Here's a question. On Large units, if only one segment of the Large unit is on fire, will the fire spreading code allow the other three segments to catch on fire? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:13, 10 March 2009 (CDT)

:I highly doubt it. Unit fires are completely different creatures from terrain fires. Needs testing though. --[[User:Zombie|Zombie]] 20:55, 10 March 2009 (CDT)

::Yes it would have to be a very special case, since afaik fires do not spread from regular units on fire to adjacent terrain or to other adjacent regular units. Though it would make more sense than any of those things. [[User:Spike|Spike]] 21:03, 10 March 2009 (CDT)

== Incendiary Bug ==

(Also known as the [[Known_Bugs#Funky_Fire|Funky Fire/Smoke bug]].) I made some suggestion about why this bug happens, and how the code could be patched to fix it: [[User talk:Seb76#Incendiary Bug]]. [[User:Spike|Spike]] 07:13, 12 March 2009 (CDT) Here is the general discussion of the bug:

With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

I also suspect that other "end of turn" processing happens with every IN round fired. I am pretty sure "fire spreading" checks occur, as I have seen fire spread when using perfectly accurate shots. Either "fire spreading" happens, or there is a random element in incendiary area of effect, that is definite. I want to repeat these tests to see if "catch on fire" effects also happen for those who are standing in fire when an IN round is fired. [[User:Spike|Spike]] 08:59, 31 March 2009 (EDT)

== Mwahaha ==

Was exploiting the Elevator Shield trick on an Alien Base Assault, and I had the forethought to pack lots and lots of Incendiaries. My sick sick mind found it amusing to set all those aliens on fire and watch them roast stupidly and helplessly. (Jasonred)

= Fire Damage =
(moved from talk:UFOextender)

Not sure if the bug is already posted. And Not sure if I should post the bug here or in [[Talk:Incendiary]]. Problem is if you use extender to fix funky fire bug. Incendiary no long does any damage at all. Units only take the small amount of damage after ending turn because they're on fire. Using 1.28.3 extender

To test this. I stripped a soldier of armour. And pounded four incendiary rockets into the soldier in the same turn. No damage. And then next turn, his health drops a little because he's standing in fire. This may not be a problem for most players. But it is still a major bug. I understand the funky fire problem is already difficult to fix, and I say thanks to all who will try to help solve this bug. [[User:Hellblade|Hellblade]] 14:44, 28 September 2012 (EDT)

: That's not a bug, that's the fix. Incendiary damage is only applied at the end of the turn. Think about it... does fire kill faster than a bullet? Faster than a grenade? Can you kill someone with fire faster than they can get a shot off back at you? No, to all these things. To compensate for fixing the bug, fire damage is doubled compared to the previous end-of-turn fire damage (that always existed). It is no longer applied per shot or per impact. All you get "per impact" is another chance to set the target unit itself on fire. Incendiary is a weak attack. It has the benefit of a wide area effect, no HE block, and ignores armour. There are situations when IN is the only effective weapon XCOM possesses. But, like everything, it has strengths and weaknesses. [[User:Spike|Spike]] 15:51, 28 September 2012 (EDT)

:: I see your point but let me elaborate. Heat, not fire, do kill as fast as bullets. The original game mechanics separated heat from fire just as in real life. It intended to have the big heat blast damage first and then the small fire damage per turn.
:: Take the most extreme case, napalm or volcanic lava, you get fully cooked in less than a second - just by heat alone, and you may/may not catch fire later on. And heat blasts travel as fast as bullets, in some cases as fast as light. I believe the game has different Incendiary damage values to do different damage according to how strong the heat is, not the fire afterwards. The damage by fire later on makes sense because natural burning fires aren't that hot comparatively.
:: I understand the difficulty in trying to fix this. But before this fix you could kill a reaper by a few AC-I shots (which is their weakness) and now you can empty the two clips at it and it'll never die. [[User:Hellblade|Hellblade]] 03:11, 4 October 2012 (EDT)

== Advantages/Disadvantages of using Incendiary for nighttime light ==

It seems for most folks that electro-flares are the go-to for night lighting and incendiary rounds are a distant afterthought.
With that in mind I propose this list of pros/cons to using incendiary at least as a major complement to flares.
I believe most people today are playing with OpenXcom or something that fixes the bugs, so I'll trim this of factors arising from bugs/limitations

Cons:
#Low damage, and for each soldier with incendiary rounds loaded they can't attack with more effective weaponry unless
##they unload and reload
##they carry another gun or use 'nades/stun rod
#Not re-usable, will always be depleting stock
#Shooting IC rounds doesn't generate experience/training like throwing throws does for throwing accuracy

Pros:
#Not dependent on throwing limitations of range and arc/trajectory
#Very efficient in terms of light-output per weight, storage space, and time units
#Can set area on fire to illuminate where the enemy is initially, then as the fire burns out you may move into the cover of the smoke it generates
#Does at least some damage to enemies - very unlikely to kill them, but softens them up so future attacks more likely to neutralize
#Area denial - fill a small building or enemy craft with flames and watch them flee out into your reaction fire, or at least out where you can get them, they don't get the drop on you
#At least in OpenXCom the enemies on fire should provide lighting, helping to spot them at a distance
#Fire is less vulnerable to being destroyed by nearby explosions, unlike those wimpy flares. And even if it is snuffed, it isn't something you were counting on re-using
#Reaper vulnerability
#Zombies not re-spawning to 'lids when KO'd by fire splash
#You can dedicate a few number of soldiers to throwing fire around while the rest keep their hands and TU's free to attack
#Soldiers that go berserk/get MC'd can't hurt armored soldiers w IC fire

Now it seems to me that the first Con is major and obvious, but the many Pros are overlooked. Also that big Con could be greatly mitigated by cannon wielders w incendiary carrying a decent secondary weapon: thinking plasma rifle or pistol, laser pistol

any I'm missing? what about putting this on the main page?
(also I meant to make this a main topic, not sub-topic of the above)
[[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 00:09, 9 July 2021 (UTC)

Talk:Incendiary

2021-07-09T00:09:37Z

Mugwump: /* Advantages/Disadvantages of using Incendiary for nighttime light */

== General Comments ==

For now, we'll just say the smoke + incendiary stun effects only work on X-Com owned units until some tests can be run to confirm this. It's unusual that only X-Com units are affected, but the game has been known to surprise you even after you think you've worked something out.

- [[User:NKF|NKF]]

----

Given how aliens love to hang around in a smoke-filled crashed UFO, IC rounds would be insanely powerful if they did actually work against aliens in smoke. I'm glad they don't ''seem to'', as I'd be very tempted to cheat with it. They do work against aliens standing in fire, though, which is still quite cheaty...--[[User:Ethereal Cereal|Ethereal Cereal]] 21:35, 5 May 2006 (PDT)

:I do consider the "standing on fire + new IC explosions = damage" a cheat. So I just don't abuse it. I only use IC rounds to illuminate or to finish off hiding aliens. It can also work as a "pass-through-and-die" tactic, the same way Proximity Nades work, although fire damage is pretty sad xD. --[[User:Nekrocow|Nekrocow]] 00:36, 24 June 2012 (EDT)

:: I use it a lot in TFTD to clear out those island bunkers and the upper storage levels of the large train station. Either the aliens roast alive, or they come out. Otherwise yes, it's no doubt a cheat. Well, more a bug exploited as a cheat. -[[User:NKF|NKF]] 02:09, 24 June 2012 (EDT)

-----

I just edited the Incendiary page a bunch, because Brunpal's [[Talk:Experience]] questions about Incendiary sparked my interest... I never did test IN vs. experience. It's a very good question ''if'' it turns out to cause Firing experience. But while reviewing this page, I had a number of questions, for anyone interested. Also, I only tried to clarify things, and don't know Incendiary well, so fix anything you know I got wrong:
#Did I get it right re: the set [ 0, 5, 6, 7, 8, 9, 10 ] for chance of initially catching fire? I over-wrote "linear" because it seemed odd when XCOM usually goes, e.g., 0-10. (Who tested this? - A little help here please. Just making sure.)
#Why flame a zombie unless it's near death (and how can you know if it is)? It's been a long time since I used fire - if you don't have flying armor, why mess around with a zombie by burning it, why not Heavy Plasma it.
#Any research/data on tile flammability versus duration of burning is appreciated. Probably it should go on the [[Terrain]] page byte, but be clearly referenced here. It's just a curiousity, but an interesting one.
#The last line of the page says ''"The damage values listed in the UFOpaedia do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames."'' Does anyone know IN strength vs radius, then? Should be easy to test and post.
#NKF, Zombie, or anyone else... would you mind seeing if Incendiary causes the Experience counter to increase? Brunpal is right that it's important to [[Experience]]... I found [[Small_Launcher#Experience|Stun Bombs]] to count for experience across their whole range, even if no stun damage occurred... if you have 11+ Mutons in a firing squad situation, passing around an [[Auto-Cannon]] with Incendiary may be better than standard pistols, depending on the range of the blast. I could test it, but it's been a long time since I've delved into the files; maybe one of you have them more close to hand. [[User:MikeTheRed|MikeTheRed]]
-----
:Offhand, the only way I could think of to check the remaining HP on a Zombie would be by using a [[Mind Probe]]. Given the relative uselessness of a Mind Probe after Psionics are developed, as well as the time needed to use the Probe once, this seems a rather impractical course of action, unless your Rear Commander has nothing better to do. I agree, Heavy Plasma on Auto is better. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 1 August 2008 (PDT)
-----
#Yeah, the set is correct. When a unit is shot with an incendiary round, the game does a calculation to determine if the unit catches fire. If it doesn't catch fire, the unit takes no damage (the 0 in the set). If the unit does catch fire, it will take between 5-10 damage points. Stupid discontinuous range, but that's what happens. As you may guess, I did the Incendiary trials over at the StrategyCore forums in the Damage Modifier topic - see [http://www.strategycore.co.uk/forums/index.php?s=&showtopic=746&view=findpost&p=39672 this] post for the particulars.
#Why flame a Zombie? Simple. A Zombie which is killed by an Incendiary round doesn't turn into a Chryssalid. Zombies are easily outrun, so you can just keep picking at them from a short distance with Auto-Cannon Incendiary rounds and then running away. Fairly effective, even when your troops do not yet have armor to protect them. And when you do not have the luxury of the Heavy Plasma early in the game, Incendiary is a good way to avoid an overabundance of Chryssalids who are not so easy to kill. As for checking the Zombie's stats, you can only rely on the Mind Probe or Psi. Neither are available early either (the Mind Probe is usually low on the research tree for most people even though you can collect enough, and Psi is difficult to use as a soldier needs to be quite proficient to use MC.
#I have been meaning to do some tests in flammability vs terrain but only recently started fooling with MCD values. It'll be next on my list.
#Here, I uploaded a very recent spreadsheet containing both I and Smoke when damage values are hacked. See [[Media:Incendiary_and_Smoke_Patterns.zip | this file]] which contains both.
#I think I fooled around with Incendiary recently in conjunction with promotions. Soldiers who shot aliens with "I" didn't get promoted. Logically, that would mean the experience counter didn't increment. UNITREF.DAT would need to be checked to verify though. Addendum: indeed, as BB mentioned in the experience page (and a quick glance at the UNITREF.DAT experience counters by myself to triple-check my aging brain), Incendiary rounds do not increase any of the experience counters.

Hope this clears up some of the issues/concerns here. --[[User:Zombie|Zombie]] 21:16, 1 August 2008 (PDT)
----
<i>"The damage values listed in the [[UFOpaedia]] do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames. Fire is unlike other damage; it works at initial blast and then over time, as described above."</i> and
<i>"Initial "impact" damage from incendiary ammunition is either for no points (unit does not catch fire), or between 5-10 points (unit catches fire)."</i>

This should be stressed on ALL the various relevant pages. It's important. 6.4 dmg vs 90 dmg is a significant difference!--[[User:Brunpal|Brunpal]] 09:31, 2 August 2008 (PDT)
----
It looks like Incendiary is gaining some clarity (at least for me), thanks for starting it Brunpal...
*The "6.4" was only for the initial IN round impact (set [ 0, 5-10 ]); it can then burn for 4 more rounds (set [5-10]). Perhaps a short way to state this complicated damage type is "Minimum 0 (unit does not catch on fire) ''OR'' unit catches on fire 1-5 turns, 5-10 damage/turn, 5-50 damage in total (average 21.5)". Does that look right, Zombie? I'm not sure where you got 90 from Brunpal...
:90 is the listed damage from an IN rocket.--[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)
*However, the numbers I just stated do not count possible additional damage from nearby terrain being on fire (as opposed to yourself). Maybe those should be included somehow. (And clearly, fire is much more dangerous outdoors than inside UFOs, where terrain does not burn.) But since terrain fire can last a variable number of turns, I guess you can't have a maximum damage. Average terrain damage from fire would be 6.5/terrain (1-12), but also, it can keep the unit itself burning more than 5 turns... hard to model.
*Good point about flaming zombies, Zombie. I guess you ought to know, eh? :)
*The spreadsheet looks great. Perhaps one of us can pull out the area patterns for non-hacked IN weapons and put them on the relevant pages. When it's done, the spreadsheet itself would be an asset to Incendiary (or maybe [[Damage]], if it's listing all types of damage). As has been stated, it's the size (area) of the blast that actually directly relates to incendiary weapon "strength"... the diameters you found are probably what should be in parentheses next to weapon strength, although damage can appear as well.
*Ok, no experience from Incendiary blasts. It might've been real interesting if there were, but it didn't occur to me to test. (Or maybe I tested it briefly so long ago that I forgot.) I would've guessed that they did, because the stun bomb and explosives do. Oh well.
*P.S. Brunpal, we may not have touched pages in a year, but most/all of us have "Watch this page" turned on, so we get immediate notification of any pages we've edited or Watched. :)
-[[User:MikeTheRed|MikeTheRed]] 09:17, 5 August 2008 (PDT)
----
*Sounds correct MTR. I think Brunpal was just comparing the "damage" (actually strength) of the Incendiary Rocket (90) to the average damage due to the "impact" of the blast (6.4).
*Well, it isn't ''nearby'' terrain on fire which you have to worry about, it's the tile directly underneath a units feet which causes the most concern. If that tile is on fire and the unit doesn't move, it will take 1-12 damage points. While true that terrain on fire can last a variable number of turns, there is a definite upper-limit to how much damage a unit can possibly take. Fires don't last forever, and the combustibles eventually are consumed leaving either scorched earth or a damaged tile. Those damaged/destroyed tiles usually cannot be started on fire again by the spread of flames. They can only be set ablaze with incendiary ammo, and even then for only 1-3 turns (normal for dead tiles). So it's certainly possible to find a max damage. And for the most part, the things that burn the longest are usually objects, not tiles. And most objects you can't stand on anyway. But I totally agree that it's hard to model how fire functions due to the two forces at work: "impact" damage and damage due to standing in fire.

P.S. Some of us are actually around here and don't need to be coaxed back into existence by an email when a watched page is changed either. Just because it's quiet, it doesn't mean nobody's home. :) --[[User:Zombie|Zombie]] 20:34, 5 August 2008 (PDT)
----
While understanding the whole formula for fire and fire damage happens is useful, it was not thinking to go that broad. I was just interested in what occurs from the moment a solider takes his shot, to the time that solider gets his TU back. ie damage from incendiary rounds vs fire damage. --[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)

----
It looks to me that, unlike all other forms of damage, Fire damage ignores armor, goes right past it. If so, this should be made explicit on the main page? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 05:55, 30 May 2021 (UTC)
:Fire damage doesn't ignore armor - power suits for instance can't be damaged by fire, except if the unit is already injured. Read carefully the Damage section - there's a lot of nuances about how fire works. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 03:03, 1 June 2021 (UTC)
:: What I meant is ignore armor ratings for damage calculation. While accounting for the resistances listed on the Damage Modification page, doesn't incendiary act as if front, side, back and under armor are 0 for calculation? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:21, 1 June 2021 (UTC)

== Incendiary vs Large Units ==

We're discussing this in [[Talk:Sectopod#Incendiary vs Sectopod]], and a question came up. When an IN round impacts one segment of a large unit, presumably that segment gets the "Incendiary impact" function, i.e. 6/7 chance of catching on fire for 5-10 damage plus 1-5 turns of being on fire. Does the same "impact" function also apply to the 3 adjacent squares (6/7 chance), or is it just the "standing in fire" chance? If you had multiple regular-sized units standing in the area of effect of an IN round, they would each get "impact" effects (right?). So it ''seems'' logical that all 4 segments of a large unit, inside the area of effect, are also exposed to "impact" effects. But I wanted to check. [[User:Spike|Spike]] 06:34, 9 March 2009 (CDT)

Oh boy! Calculating this not only depends on a lot of unknown assumptions, but is fiendishly complicated - especially if you factor in the "funky fire" bug. And contrary to my noblest efforts, it's impossible to use IN weapons without inadvertently exploiting this bug. Even if you only fire IN at a single target until it's dead, once the target is "standing in fire" you effectively just can't miss.

Anyway back to the Large Targets specifically. The key assumption above is whether all regular-sized units in the area of effect of an IN burst are affected with "impact effects" - 5-10 dmg & 6/7 chance to catch fire. If they are, it's reasonable to assume the same thing happens to the 3 other segments of a Large Unit. However I suspect this is not the case, and strictly speaking "impact" effects should only occur at the single, impact square of an IN round. Testing needed!

More likely, the GZ+1 squares, whether occupied by small or large units, are only subjected to the "standing in fire" effects: 1/3 'catch fire' probability, and 1-12 terrain-based damage. And these effects are applied once per turn, not once per hit.

However, all of this is turned on its head by the 'funky fire' bug. After the first round hits, all units (and all Large Unit segments?) are "standing in fire". (Though maybe these fire damage routines run only for the "control" segment of the Large Unit? Possible, but unlikely.) Since they are standing in fire, the funky fire bug applies and all units/segments are hiit with "impact" effects.

So assuming a Large Unit is ''already'' standing in fire (e.g. from a previous IN hit or near miss), damage per IN round fired is 6.4 x 4
= 25.6 average, 10x4= 40 max. Subject to resistance/vulnerability modifiers, but ignoring armour level. In addition as multiple IN rounds are fired, the chance of all segments catching fire quickly approaches certainty. This not only means the Large Unit will sustain further damage at the end of the turn, it makes it impossible to escape the 'funky fire' trap by moving out of burning squares.

(Any testing needs to be very careful and probably only fire a single IN round per game, otherwise 'funky fire' will skew the results.)

So, in conclusion, the TU/kill factors I put up on the Talk pages for the Large Units ([[Talk:Reaper]], [[Talk:Cyberdisc]],[[Talk:Sectopod]]) should pretty much reflect the 'funky fire' reality after the first round connects, apart from the fact that you actually can't miss. The very first IN round to be fired would have the same effect (for immediate damage) on a Large Target as on a small one. But I really don't want to update the numbers to reflect this fact, it's just too awful. For AC-IN, the firepower factors will be about 6 times better than stated. Maybe I'll just remove them. :(

[[User:Spike|Spike]] 15:51, 10 March 2009 (CDT)

=== Simple Tests ===

I did a small number of tests and found some interesting results. In 5/5 tests, all 4 squares of the target (Reaper) were on fire the following round. (It's hard to tell if they are on fire the same round, as you need to extinguish the fire with smoke to see). Perhaps this makes sense, as it's a UNITREF attribute and so applies to the whole unit, not its 4 component squares?

Looking at the damage, it looks like "impact" and "on fire" damage applies to all 4 squares, i.e. x4 normal. Damage clusters tightly around 16-18 per hit which is roughly the expected value, maybe a bit lower (at x4). And since we '''are''' on fire, should expect an average of 7.5 ({5..10}/6) rather than 6.4 ({0,5..10}/7? Maybe something else is going on here, as these numbers seem a little low - 6.4 x 4 = 25.6 per hit or 7.5 x 4 = 30.0 per "on fire" hit might be expected on a Large Unit.

:Drat. I didn't factor in the Reaper's 170% Susceptibility to Incendiary. So the actual damage levels are more like 10 per hit. Maybe there is no multiplier for the 4 squares? Hard to figure out what's going on here. In tests on hacked humans, armour level is not a factor vs Incendiary damage, otherwise I'd suspect the under-armour or something. 2.5 avg damage per segment seems too low. 10 average damage per alien seems too high - that should be the max, not the average. Is some mechanic pushing the average up to the max? I don't have a clue right now. [[User:Spike|Spike]] 06:53, 11 March 2009 (CDT)

The damage seems to be regardless of "funky fire" effect. A round fired at a target that is not burning / in fire seems to do about the same damage, per hit, as one that is in fire / on fire and so subject to the funky fire bug. So the only 'bad' effect of the bug is that you never miss, and you hit everything that is in fire / on fire. Not quite so bad, and it allows you to play honest by only ever firing at one target, not hitting any other targets by accident (!), and firing from point blank range so it doesn't matter that you never miss.

Burn Time was as high as 7 when multiple IC rounds were fired (on auto). Higher than we thought possible (1-5 range expected). However it sometimes goes DOWN after additional hits. Possibly the value is re-randomised with every new IC impact, but hits are cumulative while firing auto bursts?

Here's the raw test data:

Test 1.
-
2 DH on Reaper, mix of auto and snap, some other IC impacts on others
Burn Time=7 - exceeds known limit of 5
All 4 sq on fire next turn
Is 'on fire' global? It's in Unitref, so maybe
-
Test 2.
-
1 DH on Reaper, only IC shot fired in game.
In firing turn, taken 132/148 = 16 damage. Burn time=3
Start of T+1, taken 122/148 10 more damage, Burn time=2
T+1 Reaper shows all 4 squares burning
-
Test 3.
-
Revisit #2 firing turn... fire another round (this will use funky fire)
So 2nd IC hit, 2nd rd fired, same target.
Health now 114/148, further 18 damage
But Burn time has dropped to 2! Must re-randomise on each hit??
Maybe only accumulates during auto burst?
-
Test 4.
-
Let's try lots of hits. Hack up accuracy to 255
OK 3 out of 3 hits on Auto
T+0 Health=98/148=50 damage (17 avg) Burn=6
T+1 Health=81 (17 more dmg) Burn=5 All 4 squares on fire.
-
Test 5.
-
Revisit #4 and push to 6/6 hits
T+0 Health=41/148=107 (18 avg) damage Burn=7
T+1 Health=21 (20 more dmg) Burn=6 All 4 squares on fire.
-
Methodology (Apart from Test 1) = only ever 1 (same) target in any IC AoE; no misses
(To try to minimise the impact of 'funky fire' effects - but can't eliminate)

[[User:Spike|Spike]] 23:27, 10 March 2009 (CDT)

I re-ran the same simple tests against a regular-sized (Floater) target instead. The results agreed much better with the 'standard model' of [[Incendiary]] effects. All results were within the permitted ranges in the 'standard model', though some values were unexpectedly. I think some variables to look for in Incendiary mechanics are:

* Large Unit vs regular unit behaviour looks to be different
* Auto burst vs single explosion looks to be different (maybe just due to funky fire bug, maybe not)
* Tile MCD "time to burn" value seems to affect one or more of the other calculations / probabilities
* Burn Time on the unit can go up as well as down. New hits seem to re-randomise the value.
* End of turn processing does not always reduce unit Burn Time by 1. Can a terrain fire add to unit Burn Time?

[[User:Spike|Spike]] 21:25, 11 March 2009 (CDT)

:I doubt a terrain fire adds to the time a unit is on fire. Actually, I'm quite positive on this since my tests from a while back were quite thorough. The counter can only tick down to 0, and when it does a terrain fire will have a chance of "reigniting" the soldier again.

:Anyway, I had to start from scratch again on testing due to a few issues with my test scenario. I totally forgot that the first soldier on the unit roster is a bad choice for a "designated hitter" since he can never be automatically selected on a reload. Soldiers lower on the order are much better choices. So I got the shooting automated, but each reload was taking too much time since I had to reselect the shooter, select the shot, move the view down a level, shoot the target and abort. Having the soldier already selected cuts out 2 actions in the list allowing the script to run more efficiently. I'm going to try to get everything properly setup tonight, then start testing tomorrow morning. With a little luck and about 2 hours of babysitting the script to make sure it doesn't quit, I should have some prelims. --[[User:Zombie|Zombie]] 21:55, 11 March 2009 (CDT)

----
Looking forward to seeing that data! I did some more testing just for the special case of Large Units, about 40 tests. My tentative conclusions:

# Damage range per 'impact' hit is the same as regular units, around 5-10 x Vulnerability (maybe + MCD Burn time?)
# Large units go on fire about 1/7 of the time when receiving a direct hit - as expected
# Either all 4 segments go on fire, or no segments go on fire - no 'part segments on fire'
# Unit burn times are not correlated with unit damage received
# Auto fire has the same average damage level per hit as snap fire
# Unit Burn Time can exceed 5, both on Snap and Auto. Highs of 6 (Snap) and 7 (Auto) were seen. Maybe 1-5 + MCD Tile Burn Time?

All my tests were done on the grid-lined pavement tiles from urban terror missions, which have an MCD default burn value of 2. For some of the "setting the large unit on fire" tests, I had the target floating in mid air, because air does not burn even during the turn that the IN round explodes - it makes it easier to see the unit burning.

From Bomb Bloke's editor notes, the 4 potential MCD tiles in a map location are: a North Wall, a West Wall, a Ground tile, an Object tile. All 4 of these MCD tiles might have a burn time value. But Ground and Object are the most likely to be relevant.

[[User:Spike|Spike]] 21:58, 12 March 2009 (CDT)

:Ok, I got the script running and optimized it a bit to cut down some wait cycles. Right now it's cranking out approximately 400 trials per hour which is about as fast as I can make it go without removing some desktop icons (all the icons have to refresh at the end of each logging cycle which takes a little time). Anyhow, just for giggles I stopped it after 400 trials to get some prelims.

:<table {{StdCenterTable}} class="sortable">
:<tr {{StdDescTable_Heading}}><th align="left" width="90">Damage</th><th width="90">Count</th><th width="90">Pct%</th></tr>
:<tr><th align="left">1</th><td>68</td><td>17.0%</td></tr>
:<tr><th align="left">6</th><td>58</td><td>14.5%</td></tr>
:<tr><th align="left">7</th><td>45</td><td>11.3%</td></tr>
:<tr><th align="left">8</th><td>63</td><td>15.8%</td></tr>
:<tr><th align="left">9</th><td>55</td><td>13.8%</td></tr>
:<tr><th align="left">10</th><td>64</td><td>16.0%</td></tr>
:<tr><th align="left">11</th><td>47</td><td>11.8</td></tr>
:</table>
:If you average the percent columns, it comes to 14.28571429% while the expected is 1/7 or 14.285714285714285714285714285714 which is a difference of 4E-09. This means 400 reloads is plenty enough values for this application. Great news! Well, as you can see, instead of the set [0, 5, 6, 7, 8, 9, 10] for MCD of 1, this scenario where the MCD was 0 is shifted up by one [1, 6, 7, 8, 9, 10, 11]. Interesting.

:Tomorrow I'll rerun the MCD 1 scenario again to verify the values and damage set. Then it's on to the MCD of 2. --[[User:Zombie|Zombie]] 01:50, 13 March 2009 (CDT)

:: Extremely interesting! By the way, it was probably a late night but - the average any 7 numbers that (must) add up to 100% is always going to be 1/7th of 100%, so that result doesn't really demonstrate any confidence in the data. It would be the same with one result, or with a trillion results. The 4E-09 discrepancy is just the precision error in your calculator/spreadsheet's calculation of the percentages and the average of the percentages. You've got some considerable variation from 1/7th on the individual numbers, I'm not sure if that's just to be expected with only 400 trials. But for example "0" and "10" are both a bit high so it ''might'' be non-linear (probably not). Anyway we'll see when all your results are in! (To measure the degree of variation from the expected result, what you want is a chi-squared test or something - and I don't know what I'm talking about there so I'll shut up!)

:: I'm checking Bomb Bloke's MCD database, and there are some tiles in there (U_BASE 22-25) with MCD burn value of 30 - I might play with those and see if anything dramatic happens. Oh except looks like they can't be set on fire (255 flammability). There are others that are quite high (8-), and still flammable. Or I could hack an MCD file (scary). Maybe I'll just wait for your results Zombie! [[User:Spike|Spike]] 05:49, 13 March 2009 (CDT)

= Incendiary Research =

== Large Units On Fire ==

Here's another interesting test for setting Large Units on fire. Set AC-I power down from 42 to 1.
At this IC power, there is no area effect. You can't even start a fire on one tile.
All you can do is set units on fire with a direct hit. This means there is no way the other 3 squares of the
Large Unit are in the IC area of effect.

Result: Whether you hit a one square regular unit or a 4-square large unit, if it goes on fire, '''all''' squares of the unit still go on fire. Along with the fact that the inflicted IN damage level vs Large Units is basically normal (see above), this tends to confirm that being on fire is a "unitref" property and, unlike HE and Stun Bombs, is not applied (multiplied) vs the number of squares the unit occupies. (In fact it would be good to check that HE is actually applied separately to each square, with different HE strength, potentially different armour facing, etc. Maybe the engine just simplifies things and multiplies damage by 4?)

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)

== Unit Burn Time ==

Unit Burn Time seems to be considerably '''cyclic''' rather than random. Very often, it just steps down by one from the previous value. I suspect this is because the "impact" routine calls the "end of turn" incendiary/smoke routine (see [[User talk:Seb76#Incendiary Bug]]). Sometimes it does not happen, maybe because some other factor has caused the Burn Time to increase.

Here's some data. This was done against a Reaper with AC-I power set to 1 (and 10% TU Snap fire cost). But I've seen similar results with standard AC-I.

Hit H/H Dmg/Avg Burn Time
1 137/150 13 2
2 126/150 11 1
3 104/150 22 0 Very high damage (=13x1.7). Unit not on fire when game restored.
4 96/150 8 7
5 81/150 15 6
6 66/150 15 5
4,5,6 76/150 /9.33 5 (Auto) 9-10 (=5-6x1.7) is near minimum dmg
7 56 10 4
8 48 8 4 What happened here? didn't cycle. MIN dmg (5x1.7).
9 35 13 6
10 25 10 5
11 10 15 6 New shooter takes over
12 2 8 5

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)
:You're right on spot once again ;-) When a unit takes a direct hit from an IN round, it is set on fire (the duration is randomly chosen between 0 and incendiarydamagemodifier/20). Then the "end of turn" routine is called, which inflicts damage *and* decreases by one the number of turns to be on fire (done for all units). Then it sets on fire units standing in blaze. The duration is calculated as for direct hits; if the unit was already on fire, it'll take the maximum value between the new value calculated and the current value affected to the unit on fire. Not sure it is readable but I think you'll sort it out ;-) [[User:Seb76|Seb76]] 10:51, 15 March 2009 (EDT)

== Incendiary in TFTD ==

I read [[Weapons (TFTD)#Phosphor|somewhere]] there are reduced effects underwater (or enhanced effects on land) for TFTD Phosphor rounds. I couldn't find an exact statement of the quantitative difference - does anyone know this? [[User:Spike|Spike]] 14:53, 9 March 2009 (CDT)

:The effects of Incendiary weapons underwater (or Phosphor, as TFTD refers to it) is halved over the UFO equivalent. Incendiary weapons are doubly effective on the surface(Terror Missions) vs underwater, but of the three weapons that can fire Incendiary, two of them(Torpedo Launcher and Hydro-Jet Cannon) can only be reaction fired on land. The Gas Cannon can be fired in eiither location. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:08, 9 March 2009 (CDT)

:: It's clear that the effect underwater is half the effect on land. But does the base level (in USOPaedia / OBDATA) refer to land use or underwater use? [[User:Spike|Spike]] 15:13, 9 March 2009 (CDT)

:As I recall, the base level is on land. The numbers for Phosphor ammo are close to the UFO Incendiary damage numbers, but I know it spreads less underwater. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:15, 9 March 2009 (CDT)

:: Look at the (puny) area effect pattern sizes underwater, that sounds about right. Can anyone confirm this? [[User:Spike|Spike]] 15:40, 9 March 2009 (CDT)

There is actually no difference between the pattern for the Gas Cannon's P rounds underwater as on land. Both have a r=3, d=7 pattern. (CE version at least). Maybe the pattern is smaller the deeper you go? --[[User:Zombie|Zombie]] 16:45, 9 March 2009 (CDT)

<gallery widths="200">
Image:GC-P (underwater).png|Flame pattern from Gas Cannon Phosphorous rounds underwater.
Image:GC-P (on land).png|Flame pattern from Gas Cannon Phosphorous rounds on land.
</gallery>

:OK now I'm really confused then! (I realise I was getting confused with the Dye grenade's small footprint vs Smoke grenades). If the blast pattern is the same size, that implies the weapon power is unchanged. So in what sense is Phosphorus "half as powerful" underwater? Does it burn half as long? Is the impact and fire damage halved? [[User:Spike|Spike]] 16:49, 9 March 2009 (CDT)

I really doubt the damage to units would be affected if the power of the round was modified. The power of the round only determines the size of the pattern produced, not the damage inflicted to units. I'll have to check the burn times and spread rate but my thought is that the two are identical in the version I'm using. Like I said, the pattern may get smaller the deeper you go underwater. The pic above was for a shallow site. It'll take a while for me to find a deeper site to check it out, otherwise some editing of the game files may be necessary to force the scenario.

I just checked the Dye Grenade underwater and on land. Both produce the same r=1, d=3 pattern. So yeah, they are really pitiful when compared to the Smoke Grenade.

Don't really go for the use of "impact" damage with Incendiary/Phosphorous rounds. There is no real impact since the damage range is discontinuous. The unit either catches fire from the splash of fire (in which case it does 5-10 damage points), or the unit doesn't catch fire and the unit remains unharmed. If there were such a thing as impact damage, the range would be continuous like normal weapons, in this theoretical case it would be [0-10] inclusive (ie the set [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. --[[User:Zombie|Zombie]] 17:36, 9 March 2009 (CDT)

Anyway, the half thing came up because AQ was comparing TFTD to UFO, not comparing the effects in TFTD from underwater and on land. However, further comparisons reveal that a hacked HC-I round of 60 produces the same pattern as a GC-P/60 round. Perhaps this whole dilemma can be traced to the Dye Grenade? --[[User:Zombie|Zombie]] 18:28, 9 March 2009 (CDT)

:That's entirely possible the Dye Grenade is the source. However, several of the pages for the TFTD weapons state that Phosphor is far weaker in water, so I didn't check. My mistake. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:35, 9 March 2009 (CDT)

Thanks for the feedback everyone. So this could just be a recycled rumour? I guess the general assumption is that the game engines are identical, so we would want evidence that TFTD is different. Looks like Zombie has proved that the area effect is equal (at least at shallow depths). That leaves only the fire damage or fire duration. Testing that would require repeated observations to check if fire damage is less than 6/hit, less than 6/turn, and burning for no more than 2-3 turns. [[User:Spike|Spike]] 20:14, 9 March 2009 (CDT)

:As with any wiki where contributions can come from anywhere, there are bound to be problems with validity of the statements made. So unless those statements are backed up by real-life test data instead of memory or hearsay, take them with a grain of salt. The other point is to avoid spreading disinformation at all costs (I have been guilty of this as well, but try to at least quantify them). So there you go. I'm still trying to get a deeper underwater mission to check the size of the pattern produced there. Checking the spread of flames or damage inflicted to units shouldn't take too long though. I'll see if I can't get that done tonight yet. --[[User:Zombie|Zombie]] 20:23, 9 March 2009 (CDT)

:Ok, I ran some trials with an unmodified GC-P round on the normal seabed floor against soldiers having 100 health and 0 all-around armor. For the guy standing at GZ, I saw ending health values of 99, 94, 93, 92, 90, and 89 (n=50). So that comes out to 1, 6, 7, 8, 10 and 11 points of damage respectively. I didn't think 11 damage was possible. Here's where things differ though. All the other guys who were clustered around GZ always received only one point of damage, never more, never less. In EU, the guys around GZ took damage equal to the guy at GZ. Odd. So then it occurred to me that perhaps I should check the MCD values of the seabed (TFTD) and the desert (EU) landscapes. Both are basically identical in terms of armor. But the seafloor has a "time to burn" value of 0 while the desert has a value of 1. So maybe our understanding of normal fire isn't totally complete. I'm going to go back to EU and retest the desert landscape with varying MCD burn time flags to see how that affects damage. ;) --[[User:Zombie|Zombie]] 23:00, 9 March 2009 (CDT)

:: The whole Phosphor being half effective under water is related to the burn time and spread, if I remember correctly. The settings in the MCD files may be the culprit. The actual damage dealt or initial spread may not necessarily be affected.

:: Hey, I just had a wacky idea. XComutil. Use its feature where you can set the depth of a mission. Launch a mission on a island terror site map (again, use XComutil's map picker to get to this faster). Lots of grass to burn there. Set fire to it and count how many turns before the fires die out. Redo the test, but this time set the depth to a deeper level. Try the whole process out again.

:: Next repeat this with one of ye-olde seabed maps. They look really weird without the blue palette shift when played on land, what with the landscape being gray.

:: It's possible that the half-effectiveness relates to the fuel that the fire has to burn more than anything else. Further confirmation on how long the flames stick to a target when on land or underwater may be helpful. -[[User:NKF|NKF]] 01:28, 10 March 2009 (CDT)

:I've been burned one too many times using editors or utilities to mess with saved games. Half the time they introduce some unknown "feature" which isn't documented. Thanks, but no thanks. I only test with an unmodified game, except for the changes I make myself to keep control of the situation. Anyway, I tested a patch of fire on the seabed to see how long it remained lit (which has a "time to burn" value of 0). It only stayed lit the current round the shell detonated. After that the fire went out. So this agrees with what is expected. Will continue to work on this as I get time. --[[User:Zombie|Zombie]] 01:51, 10 March 2009 (CDT)

Well, I suppose my recommendation doesn't necessarily need XComutil. It would've certainly made it easier. But yes, it does introduce a few things that work behind the scenes that we might not know too much about. However, if I remember correctly, one of the battlescape savegame files should hold the depth level of the current map you are playing on. All you'll need to do is tweak that to change the depth of the map.

One other thing, the different effect HE has on the same tiles underwater and when on land (ala the Triton) may also be one of the other culprits behind the belief that phosphor is less effective on land. Being able to blow up the Triton on land, but have it appear virtually indestructable when underwater does that. -[[User:NKF|NKF]] 01:59, 10 March 2009 (CDT)

----

re Zombie's underwater tests, there is normally (i.e. on land in EU) a difference between the IC damage on the target of the direct hit, vs lower damage to others in the area of effect (hmm contrary to my IC kill modelling assumptions: uh oh I may've spoken to soon). But only seeing 1 damage on the others in the AoE does seem low. We need to figure out why. Did any of the other targets catch fire? Does that ever happen underwater? Do tiles ever burn past the turn when the IC round is fired? Any of these factors would reduce total fire damage/effectiveness by '''more''' than half. Actually, doesn't it say the 1-12 damage for "in fire" is ''not'' random, but dependent on terrain type? That could be the answer.

The [[Incendiary]] article actually mentions '''4''' modes of fire damage, only 3 of which are quantified:

#"impact",
#"being in fire"
#"being ''on'' fire"

The 4th mode is "damage from burning ''terrain''. Only a tantalising mention is given, no quantitative details. This could be the source of the discrepancy. In fact it might be a component of "being in fire" that's not fully understood. I think Zombie is right to review the assumptions on this one - nice work! [[User:Spike|Spike]] 04:05, 10 March 2009 (CDT)

:As I recall, "damage from burning terrain" is synonymous with "Standing on a tile that's currently on fire." Thus "Being in fire." But that's me and I'm tired this evening, so I could be wrong. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:30, 10 March 2009 (CDT)

I performed my TFTD Phosphorous tests underwater and after the flames died out some of my men did catch fire. So this part seems to jive with that of EU. Tiles do not burn longer than its "time to burn" value in the MCD files. So for instance, in the seabed underwater testing mission, the tiles have a MCD burn value of 0 which corresponds to the results seen (ie fire didn't stick around into the aliens turn or X-COM's next turn either, it only stayed lit the turn it detonated). There really is only 2 "modes" of I/P/fire damage:

<ol><li>The code used for determining if a unit catches fire: 0 damage (if the unit didn't catch and was able to shrug it off) and 5-10 (if the unit catches).</li>
<li>Standing in fire.</li></ol>
At least from the initial tests in TFTD, units outside GZ are just considered to be standing in fire that turn and always take 1pt of damage. Anyway, I don't want to talk myself into a hole without doing more tests. All the following trials I do will be in EU to hopefully curtail any unknowns in TFTD. Once EU's code is figured out then it can be applied and compared to TFTD. --[[User:Zombie|Zombie]] 09:06, 10 March 2009 (CDT)

: If they are "standing in fire", do you think the 1pt damage/turn is based on the fire characteristics tile/terrain type they are standing on? Is it more generally 1-12/turn, dependent on terrain? Also if you get a chance can you test large units and see what kind of effects they take on the GZ+1 squares? If the GZ+1 squares of a large unit are just 'standing in fire' rather than 'catch fire/5-10 impact damage' this will substantially weaken IC vs large units. And I will have shouted too soon! :) [[User:Spike|Spike]] 09:18, 10 March 2009 (CDT)

I did some ad-hoc tests in TFTD. Actually I just ran around firing GC-P and HJ-P rounds everywhere. :) On a typical seabed layout, I found that most things don't burn - the fires don't last into the next turn. The only things I could get to burn were the green moss stuff and and coral skeleton "trees". Even the barrels do not burn. Also, I did not see much sign of terrain damage caused by the fires. But the moss and coral did burn for the normal period, i.e. 1-5 turns.

I also managed to kill an Aquatoid with a single direct hit from a GC-P, in one turn. He died at the end of my turn or the start of his. That seems unlikely. 5-10 from being hit, plus 1-12 for standing in fire, plus maybe another 5-10 from being on fire? It's just about possible I suppose, to max out near 32 damage (if the terrain offers you "12" when it burns). Anyway those are my unsystematic enquiries. I have the 8 save files of various stages of the battle if anyone wants to take a look. It was from a virgin TFTD installation and there was no editing or jiggery pokery.

OK I've uploaded the save files [[Image:TFTD Incendiary Tests 01 Spike.zip]] and taken a look myself with BB's editor. Prior to being hit (Game_4) our Aquatoid was in rude Health, 30/30. Immediately after being hit (Game_2) he was at 19 Health (no Stun damage) and On Fire, as well as Standing in Fire. That implies 11 Damage from the "impact effect" which is not supposed to happen. As noted, at the end of the same turn or beginning of his next turn, he dies. He looks to be standing on a standard seabed square, just sand, the kind of thing that does not burn. He is next to some of the brown cushion-like coral, but I don't think that burns, at least not over multiple turns. In fact in the same turn he is hit, at the end, you can see him dead (Game_3). Since there was only one alien, he died in the same turn. OK that's slightly confusing, maybe someone can double check the turn numbers in the save files (don't know where they are).

[[User:Spike|Spike]] 13:29, 10 March 2009 (CDT)

Doh. I is a idiot. The Aquatoid was killed by the incendiary fire bug - I fired extra IN rounds at terrain objects after he was on fire. Which explains why he is already dead by the end of my turn. [[User:Spike|Spike]] 15:08, 10 March 2009 (CDT)

:Yeah, you gotta watch that. Well, anyhow, I edited the desert landscape in Enemy Unknown to have the same MCD "time to burn" value of 0 as the seafloor in TFTD. From the limited tests, the results look the same as in TFTD. (Fire burns out after the initial turn it detonated, units around GZ taking 1 unit of damage while the guy at GZ got more). So that means I can focus my efforts on EU with little worry because there will be no issues. I'm going use BB's logger and AHK to automate the data gathering aspect to save me a bunch of time. I'll probably need the full requisite 2000 reloads though, as the guy at GZ is not the same as the 24 soldiers around him. Wish me luck. :) --[[User:Zombie|Zombie]] 15:54, 10 March 2009 (CDT)

Good luck! I just read the MCD article, and it mentions 2 fire-related byte fields in MCD - "likelihood of catching fire" as well as "time to burn". Is the last field variable or fixed? Could the first field determine the damage/turn to units when it's on fire? Also with a possible 4 terrain items that could all be burning, is the maximum damage higher than 12? [[User:Spike|Spike]] 16:10, 10 March 2009 (CDT)

:Offset 45 is the flammability rating of the tile. This most likely controls whether an adjacent fire will spread to the tile in question. (For instance, if a fire is burning and the next tile over is a tree or something, it'll probably spread there fast because of the combustibles present). The other byte is offset 57 which is the one we are after. Don't know about the 4 types of things which can exist on a tile at once. I think the most I have ever seen is 2 (usually ground and a wall). Wouldn't hurt to edit a tile to include all 4, but that's an entirely different test to do. It'll have to wait until we get a better understanding of basic fire. ;) --[[User:Zombie|Zombie]] 19:38, 10 March 2009 (CDT)

::Here's a question. On Large units, if only one segment of the Large unit is on fire, will the fire spreading code allow the other three segments to catch on fire? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:13, 10 March 2009 (CDT)

:I highly doubt it. Unit fires are completely different creatures from terrain fires. Needs testing though. --[[User:Zombie|Zombie]] 20:55, 10 March 2009 (CDT)

::Yes it would have to be a very special case, since afaik fires do not spread from regular units on fire to adjacent terrain or to other adjacent regular units. Though it would make more sense than any of those things. [[User:Spike|Spike]] 21:03, 10 March 2009 (CDT)

== Incendiary Bug ==

(Also known as the [[Known_Bugs#Funky_Fire|Funky Fire/Smoke bug]].) I made some suggestion about why this bug happens, and how the code could be patched to fix it: [[User talk:Seb76#Incendiary Bug]]. [[User:Spike|Spike]] 07:13, 12 March 2009 (CDT) Here is the general discussion of the bug:

With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

I also suspect that other "end of turn" processing happens with every IN round fired. I am pretty sure "fire spreading" checks occur, as I have seen fire spread when using perfectly accurate shots. Either "fire spreading" happens, or there is a random element in incendiary area of effect, that is definite. I want to repeat these tests to see if "catch on fire" effects also happen for those who are standing in fire when an IN round is fired. [[User:Spike|Spike]] 08:59, 31 March 2009 (EDT)

== Mwahaha ==

Was exploiting the Elevator Shield trick on an Alien Base Assault, and I had the forethought to pack lots and lots of Incendiaries. My sick sick mind found it amusing to set all those aliens on fire and watch them roast stupidly and helplessly. (Jasonred)

= Fire Damage =
(moved from talk:UFOextender)

Not sure if the bug is already posted. And Not sure if I should post the bug here or in [[Talk:Incendiary]]. Problem is if you use extender to fix funky fire bug. Incendiary no long does any damage at all. Units only take the small amount of damage after ending turn because they're on fire. Using 1.28.3 extender

To test this. I stripped a soldier of armour. And pounded four incendiary rockets into the soldier in the same turn. No damage. And then next turn, his health drops a little because he's standing in fire. This may not be a problem for most players. But it is still a major bug. I understand the funky fire problem is already difficult to fix, and I say thanks to all who will try to help solve this bug. [[User:Hellblade|Hellblade]] 14:44, 28 September 2012 (EDT)

: That's not a bug, that's the fix. Incendiary damage is only applied at the end of the turn. Think about it... does fire kill faster than a bullet? Faster than a grenade? Can you kill someone with fire faster than they can get a shot off back at you? No, to all these things. To compensate for fixing the bug, fire damage is doubled compared to the previous end-of-turn fire damage (that always existed). It is no longer applied per shot or per impact. All you get "per impact" is another chance to set the target unit itself on fire. Incendiary is a weak attack. It has the benefit of a wide area effect, no HE block, and ignores armour. There are situations when IN is the only effective weapon XCOM possesses. But, like everything, it has strengths and weaknesses. [[User:Spike|Spike]] 15:51, 28 September 2012 (EDT)

:: I see your point but let me elaborate. Heat, not fire, do kill as fast as bullets. The original game mechanics separated heat from fire just as in real life. It intended to have the big heat blast damage first and then the small fire damage per turn.
:: Take the most extreme case, napalm or volcanic lava, you get fully cooked in less than a second - just by heat alone, and you may/may not catch fire later on. And heat blasts travel as fast as bullets, in some cases as fast as light. I believe the game has different Incendiary damage values to do different damage according to how strong the heat is, not the fire afterwards. The damage by fire later on makes sense because natural burning fires aren't that hot comparatively.
:: I understand the difficulty in trying to fix this. But before this fix you could kill a reaper by a few AC-I shots (which is their weakness) and now you can empty the two clips at it and it'll never die. [[User:Hellblade|Hellblade]] 03:11, 4 October 2012 (EDT)

== Advantages/Disadvantages of using Incendiary for nighttime light ==

It seems for most folks that electro-flares are the go-to for night lighting and incendiary rounds are a distant afterthought.
With that in mind I propose this list of pros/cons to using incendiary at least as a major complement to flares.

Cons:
#Low damage, and for each soldier with incendiary rounds loaded they can't attack with more effective weaponry unless
##they unload and reload
##they carry another gun or use 'nades/stun rod
#Not re-usable, will always be depleting stock
#There'so a limit on the original game to the number of tiles that can be on fire/smoke. Once that limit is reached, additional incendiary and smoke will not be placed on the map until the previous entries are cleared. This can limit the effectiveness of using IN for lightning.
#There's also the [[Known Bugs#Funky Fire|Funky Fire]] bug which adds all sort of chaotic outcomes when generating fire.

Pros:
#Not dependent on throwing limitations of range and arc/trajectory
#Very efficient in terms of light-output per weight, storage space, and time units
#Can set area on fire to illuminate where the enemy is initially, then as the fire burns out you may move into the cover of the smoke it generates
#Does at least some damage to enemies - very unlikely to kill them, but softens them up so future attacks more likely to neutralize
#Area denial - fill a small building or enemy craft with flames and watch them flee out into your reaction fire, or at least out where you can get them, they don't get the drop on you
#At least in OpenXCom the enemies on fire should provide lighting, helping to spot them at a distance
#Fire is less vulnerable to being destroyed by nearby explosions, unlike those wimpy flares. And even if it is snuffed, it isn't something you were counting on re-using
#Reaper vulnerability
#Zombies not re-spawning to 'lids when KO'd by fire splash
#You can dedicate a few number of soldiers to throwing fire around while the rest keep their hands and TU's free to attack
#Soldiers that go berserk/get MC'd can't hurt armored soldiers w IC fire

Now it seems to me that the first Con is major and obvious, but the many Pros are overlooked. Also that big Con could be greatly mitigated by cannon wielders w incendiary carrying a decent secondary weapon: thinking plasma rifle or pistol, laser pistol

any I'm missing? what about putting this on the main page?
(also I meant to make this a main topic, not sub-topic of the above)
[[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 00:09, 9 July 2021 (UTC)

Talk:Incendiary

2021-07-08T17:28:26Z

Mugwump: /* Advantages/Disadvantages of using Incendiary for nighttime light */

== General Comments ==

For now, we'll just say the smoke + incendiary stun effects only work on X-Com owned units until some tests can be run to confirm this. It's unusual that only X-Com units are affected, but the game has been known to surprise you even after you think you've worked something out.

- [[User:NKF|NKF]]

----

Given how aliens love to hang around in a smoke-filled crashed UFO, IC rounds would be insanely powerful if they did actually work against aliens in smoke. I'm glad they don't ''seem to'', as I'd be very tempted to cheat with it. They do work against aliens standing in fire, though, which is still quite cheaty...--[[User:Ethereal Cereal|Ethereal Cereal]] 21:35, 5 May 2006 (PDT)

:I do consider the "standing on fire + new IC explosions = damage" a cheat. So I just don't abuse it. I only use IC rounds to illuminate or to finish off hiding aliens. It can also work as a "pass-through-and-die" tactic, the same way Proximity Nades work, although fire damage is pretty sad xD. --[[User:Nekrocow|Nekrocow]] 00:36, 24 June 2012 (EDT)

:: I use it a lot in TFTD to clear out those island bunkers and the upper storage levels of the large train station. Either the aliens roast alive, or they come out. Otherwise yes, it's no doubt a cheat. Well, more a bug exploited as a cheat. -[[User:NKF|NKF]] 02:09, 24 June 2012 (EDT)

-----

I just edited the Incendiary page a bunch, because Brunpal's [[Talk:Experience]] questions about Incendiary sparked my interest... I never did test IN vs. experience. It's a very good question ''if'' it turns out to cause Firing experience. But while reviewing this page, I had a number of questions, for anyone interested. Also, I only tried to clarify things, and don't know Incendiary well, so fix anything you know I got wrong:
#Did I get it right re: the set [ 0, 5, 6, 7, 8, 9, 10 ] for chance of initially catching fire? I over-wrote "linear" because it seemed odd when XCOM usually goes, e.g., 0-10. (Who tested this? - A little help here please. Just making sure.)
#Why flame a zombie unless it's near death (and how can you know if it is)? It's been a long time since I used fire - if you don't have flying armor, why mess around with a zombie by burning it, why not Heavy Plasma it.
#Any research/data on tile flammability versus duration of burning is appreciated. Probably it should go on the [[Terrain]] page byte, but be clearly referenced here. It's just a curiousity, but an interesting one.
#The last line of the page says ''"The damage values listed in the UFOpaedia do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames."'' Does anyone know IN strength vs radius, then? Should be easy to test and post.
#NKF, Zombie, or anyone else... would you mind seeing if Incendiary causes the Experience counter to increase? Brunpal is right that it's important to [[Experience]]... I found [[Small_Launcher#Experience|Stun Bombs]] to count for experience across their whole range, even if no stun damage occurred... if you have 11+ Mutons in a firing squad situation, passing around an [[Auto-Cannon]] with Incendiary may be better than standard pistols, depending on the range of the blast. I could test it, but it's been a long time since I've delved into the files; maybe one of you have them more close to hand. [[User:MikeTheRed|MikeTheRed]]
-----
:Offhand, the only way I could think of to check the remaining HP on a Zombie would be by using a [[Mind Probe]]. Given the relative uselessness of a Mind Probe after Psionics are developed, as well as the time needed to use the Probe once, this seems a rather impractical course of action, unless your Rear Commander has nothing better to do. I agree, Heavy Plasma on Auto is better. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 1 August 2008 (PDT)
-----
#Yeah, the set is correct. When a unit is shot with an incendiary round, the game does a calculation to determine if the unit catches fire. If it doesn't catch fire, the unit takes no damage (the 0 in the set). If the unit does catch fire, it will take between 5-10 damage points. Stupid discontinuous range, but that's what happens. As you may guess, I did the Incendiary trials over at the StrategyCore forums in the Damage Modifier topic - see [http://www.strategycore.co.uk/forums/index.php?s=&showtopic=746&view=findpost&p=39672 this] post for the particulars.
#Why flame a Zombie? Simple. A Zombie which is killed by an Incendiary round doesn't turn into a Chryssalid. Zombies are easily outrun, so you can just keep picking at them from a short distance with Auto-Cannon Incendiary rounds and then running away. Fairly effective, even when your troops do not yet have armor to protect them. And when you do not have the luxury of the Heavy Plasma early in the game, Incendiary is a good way to avoid an overabundance of Chryssalids who are not so easy to kill. As for checking the Zombie's stats, you can only rely on the Mind Probe or Psi. Neither are available early either (the Mind Probe is usually low on the research tree for most people even though you can collect enough, and Psi is difficult to use as a soldier needs to be quite proficient to use MC.
#I have been meaning to do some tests in flammability vs terrain but only recently started fooling with MCD values. It'll be next on my list.
#Here, I uploaded a very recent spreadsheet containing both I and Smoke when damage values are hacked. See [[Media:Incendiary_and_Smoke_Patterns.zip | this file]] which contains both.
#I think I fooled around with Incendiary recently in conjunction with promotions. Soldiers who shot aliens with "I" didn't get promoted. Logically, that would mean the experience counter didn't increment. UNITREF.DAT would need to be checked to verify though. Addendum: indeed, as BB mentioned in the experience page (and a quick glance at the UNITREF.DAT experience counters by myself to triple-check my aging brain), Incendiary rounds do not increase any of the experience counters.

Hope this clears up some of the issues/concerns here. --[[User:Zombie|Zombie]] 21:16, 1 August 2008 (PDT)
----
<i>"The damage values listed in the [[UFOpaedia]] do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames. Fire is unlike other damage; it works at initial blast and then over time, as described above."</i> and
<i>"Initial "impact" damage from incendiary ammunition is either for no points (unit does not catch fire), or between 5-10 points (unit catches fire)."</i>

This should be stressed on ALL the various relevant pages. It's important. 6.4 dmg vs 90 dmg is a significant difference!--[[User:Brunpal|Brunpal]] 09:31, 2 August 2008 (PDT)
----
It looks like Incendiary is gaining some clarity (at least for me), thanks for starting it Brunpal...
*The "6.4" was only for the initial IN round impact (set [ 0, 5-10 ]); it can then burn for 4 more rounds (set [5-10]). Perhaps a short way to state this complicated damage type is "Minimum 0 (unit does not catch on fire) ''OR'' unit catches on fire 1-5 turns, 5-10 damage/turn, 5-50 damage in total (average 21.5)". Does that look right, Zombie? I'm not sure where you got 90 from Brunpal...
:90 is the listed damage from an IN rocket.--[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)
*However, the numbers I just stated do not count possible additional damage from nearby terrain being on fire (as opposed to yourself). Maybe those should be included somehow. (And clearly, fire is much more dangerous outdoors than inside UFOs, where terrain does not burn.) But since terrain fire can last a variable number of turns, I guess you can't have a maximum damage. Average terrain damage from fire would be 6.5/terrain (1-12), but also, it can keep the unit itself burning more than 5 turns... hard to model.
*Good point about flaming zombies, Zombie. I guess you ought to know, eh? :)
*The spreadsheet looks great. Perhaps one of us can pull out the area patterns for non-hacked IN weapons and put them on the relevant pages. When it's done, the spreadsheet itself would be an asset to Incendiary (or maybe [[Damage]], if it's listing all types of damage). As has been stated, it's the size (area) of the blast that actually directly relates to incendiary weapon "strength"... the diameters you found are probably what should be in parentheses next to weapon strength, although damage can appear as well.
*Ok, no experience from Incendiary blasts. It might've been real interesting if there were, but it didn't occur to me to test. (Or maybe I tested it briefly so long ago that I forgot.) I would've guessed that they did, because the stun bomb and explosives do. Oh well.
*P.S. Brunpal, we may not have touched pages in a year, but most/all of us have "Watch this page" turned on, so we get immediate notification of any pages we've edited or Watched. :)
-[[User:MikeTheRed|MikeTheRed]] 09:17, 5 August 2008 (PDT)
----
*Sounds correct MTR. I think Brunpal was just comparing the "damage" (actually strength) of the Incendiary Rocket (90) to the average damage due to the "impact" of the blast (6.4).
*Well, it isn't ''nearby'' terrain on fire which you have to worry about, it's the tile directly underneath a units feet which causes the most concern. If that tile is on fire and the unit doesn't move, it will take 1-12 damage points. While true that terrain on fire can last a variable number of turns, there is a definite upper-limit to how much damage a unit can possibly take. Fires don't last forever, and the combustibles eventually are consumed leaving either scorched earth or a damaged tile. Those damaged/destroyed tiles usually cannot be started on fire again by the spread of flames. They can only be set ablaze with incendiary ammo, and even then for only 1-3 turns (normal for dead tiles). So it's certainly possible to find a max damage. And for the most part, the things that burn the longest are usually objects, not tiles. And most objects you can't stand on anyway. But I totally agree that it's hard to model how fire functions due to the two forces at work: "impact" damage and damage due to standing in fire.

P.S. Some of us are actually around here and don't need to be coaxed back into existence by an email when a watched page is changed either. Just because it's quiet, it doesn't mean nobody's home. :) --[[User:Zombie|Zombie]] 20:34, 5 August 2008 (PDT)
----
While understanding the whole formula for fire and fire damage happens is useful, it was not thinking to go that broad. I was just interested in what occurs from the moment a solider takes his shot, to the time that solider gets his TU back. ie damage from incendiary rounds vs fire damage. --[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)

----
It looks to me that, unlike all other forms of damage, Fire damage ignores armor, goes right past it. If so, this should be made explicit on the main page? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 05:55, 30 May 2021 (UTC)
:Fire damage doesn't ignore armor - power suits for instance can't be damaged by fire, except if the unit is already injured. Read carefully the Damage section - there's a lot of nuances about how fire works. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 03:03, 1 June 2021 (UTC)
:: What I meant is ignore armor ratings for damage calculation. While accounting for the resistances listed on the Damage Modification page, doesn't incendiary act as if front, side, back and under armor are 0 for calculation? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:21, 1 June 2021 (UTC)

== Incendiary vs Large Units ==

We're discussing this in [[Talk:Sectopod#Incendiary vs Sectopod]], and a question came up. When an IN round impacts one segment of a large unit, presumably that segment gets the "Incendiary impact" function, i.e. 6/7 chance of catching on fire for 5-10 damage plus 1-5 turns of being on fire. Does the same "impact" function also apply to the 3 adjacent squares (6/7 chance), or is it just the "standing in fire" chance? If you had multiple regular-sized units standing in the area of effect of an IN round, they would each get "impact" effects (right?). So it ''seems'' logical that all 4 segments of a large unit, inside the area of effect, are also exposed to "impact" effects. But I wanted to check. [[User:Spike|Spike]] 06:34, 9 March 2009 (CDT)

Oh boy! Calculating this not only depends on a lot of unknown assumptions, but is fiendishly complicated - especially if you factor in the "funky fire" bug. And contrary to my noblest efforts, it's impossible to use IN weapons without inadvertently exploiting this bug. Even if you only fire IN at a single target until it's dead, once the target is "standing in fire" you effectively just can't miss.

Anyway back to the Large Targets specifically. The key assumption above is whether all regular-sized units in the area of effect of an IN burst are affected with "impact effects" - 5-10 dmg & 6/7 chance to catch fire. If they are, it's reasonable to assume the same thing happens to the 3 other segments of a Large Unit. However I suspect this is not the case, and strictly speaking "impact" effects should only occur at the single, impact square of an IN round. Testing needed!

More likely, the GZ+1 squares, whether occupied by small or large units, are only subjected to the "standing in fire" effects: 1/3 'catch fire' probability, and 1-12 terrain-based damage. And these effects are applied once per turn, not once per hit.

However, all of this is turned on its head by the 'funky fire' bug. After the first round hits, all units (and all Large Unit segments?) are "standing in fire". (Though maybe these fire damage routines run only for the "control" segment of the Large Unit? Possible, but unlikely.) Since they are standing in fire, the funky fire bug applies and all units/segments are hiit with "impact" effects.

So assuming a Large Unit is ''already'' standing in fire (e.g. from a previous IN hit or near miss), damage per IN round fired is 6.4 x 4
= 25.6 average, 10x4= 40 max. Subject to resistance/vulnerability modifiers, but ignoring armour level. In addition as multiple IN rounds are fired, the chance of all segments catching fire quickly approaches certainty. This not only means the Large Unit will sustain further damage at the end of the turn, it makes it impossible to escape the 'funky fire' trap by moving out of burning squares.

(Any testing needs to be very careful and probably only fire a single IN round per game, otherwise 'funky fire' will skew the results.)

So, in conclusion, the TU/kill factors I put up on the Talk pages for the Large Units ([[Talk:Reaper]], [[Talk:Cyberdisc]],[[Talk:Sectopod]]) should pretty much reflect the 'funky fire' reality after the first round connects, apart from the fact that you actually can't miss. The very first IN round to be fired would have the same effect (for immediate damage) on a Large Target as on a small one. But I really don't want to update the numbers to reflect this fact, it's just too awful. For AC-IN, the firepower factors will be about 6 times better than stated. Maybe I'll just remove them. :(

[[User:Spike|Spike]] 15:51, 10 March 2009 (CDT)

=== Simple Tests ===

I did a small number of tests and found some interesting results. In 5/5 tests, all 4 squares of the target (Reaper) were on fire the following round. (It's hard to tell if they are on fire the same round, as you need to extinguish the fire with smoke to see). Perhaps this makes sense, as it's a UNITREF attribute and so applies to the whole unit, not its 4 component squares?

Looking at the damage, it looks like "impact" and "on fire" damage applies to all 4 squares, i.e. x4 normal. Damage clusters tightly around 16-18 per hit which is roughly the expected value, maybe a bit lower (at x4). And since we '''are''' on fire, should expect an average of 7.5 ({5..10}/6) rather than 6.4 ({0,5..10}/7? Maybe something else is going on here, as these numbers seem a little low - 6.4 x 4 = 25.6 per hit or 7.5 x 4 = 30.0 per "on fire" hit might be expected on a Large Unit.

:Drat. I didn't factor in the Reaper's 170% Susceptibility to Incendiary. So the actual damage levels are more like 10 per hit. Maybe there is no multiplier for the 4 squares? Hard to figure out what's going on here. In tests on hacked humans, armour level is not a factor vs Incendiary damage, otherwise I'd suspect the under-armour or something. 2.5 avg damage per segment seems too low. 10 average damage per alien seems too high - that should be the max, not the average. Is some mechanic pushing the average up to the max? I don't have a clue right now. [[User:Spike|Spike]] 06:53, 11 March 2009 (CDT)

The damage seems to be regardless of "funky fire" effect. A round fired at a target that is not burning / in fire seems to do about the same damage, per hit, as one that is in fire / on fire and so subject to the funky fire bug. So the only 'bad' effect of the bug is that you never miss, and you hit everything that is in fire / on fire. Not quite so bad, and it allows you to play honest by only ever firing at one target, not hitting any other targets by accident (!), and firing from point blank range so it doesn't matter that you never miss.

Burn Time was as high as 7 when multiple IC rounds were fired (on auto). Higher than we thought possible (1-5 range expected). However it sometimes goes DOWN after additional hits. Possibly the value is re-randomised with every new IC impact, but hits are cumulative while firing auto bursts?

Here's the raw test data:

Test 1.
-
2 DH on Reaper, mix of auto and snap, some other IC impacts on others
Burn Time=7 - exceeds known limit of 5
All 4 sq on fire next turn
Is 'on fire' global? It's in Unitref, so maybe
-
Test 2.
-
1 DH on Reaper, only IC shot fired in game.
In firing turn, taken 132/148 = 16 damage. Burn time=3
Start of T+1, taken 122/148 10 more damage, Burn time=2
T+1 Reaper shows all 4 squares burning
-
Test 3.
-
Revisit #2 firing turn... fire another round (this will use funky fire)
So 2nd IC hit, 2nd rd fired, same target.
Health now 114/148, further 18 damage
But Burn time has dropped to 2! Must re-randomise on each hit??
Maybe only accumulates during auto burst?
-
Test 4.
-
Let's try lots of hits. Hack up accuracy to 255
OK 3 out of 3 hits on Auto
T+0 Health=98/148=50 damage (17 avg) Burn=6
T+1 Health=81 (17 more dmg) Burn=5 All 4 squares on fire.
-
Test 5.
-
Revisit #4 and push to 6/6 hits
T+0 Health=41/148=107 (18 avg) damage Burn=7
T+1 Health=21 (20 more dmg) Burn=6 All 4 squares on fire.
-
Methodology (Apart from Test 1) = only ever 1 (same) target in any IC AoE; no misses
(To try to minimise the impact of 'funky fire' effects - but can't eliminate)

[[User:Spike|Spike]] 23:27, 10 March 2009 (CDT)

I re-ran the same simple tests against a regular-sized (Floater) target instead. The results agreed much better with the 'standard model' of [[Incendiary]] effects. All results were within the permitted ranges in the 'standard model', though some values were unexpectedly. I think some variables to look for in Incendiary mechanics are:

* Large Unit vs regular unit behaviour looks to be different
* Auto burst vs single explosion looks to be different (maybe just due to funky fire bug, maybe not)
* Tile MCD "time to burn" value seems to affect one or more of the other calculations / probabilities
* Burn Time on the unit can go up as well as down. New hits seem to re-randomise the value.
* End of turn processing does not always reduce unit Burn Time by 1. Can a terrain fire add to unit Burn Time?

[[User:Spike|Spike]] 21:25, 11 March 2009 (CDT)

:I doubt a terrain fire adds to the time a unit is on fire. Actually, I'm quite positive on this since my tests from a while back were quite thorough. The counter can only tick down to 0, and when it does a terrain fire will have a chance of "reigniting" the soldier again.

:Anyway, I had to start from scratch again on testing due to a few issues with my test scenario. I totally forgot that the first soldier on the unit roster is a bad choice for a "designated hitter" since he can never be automatically selected on a reload. Soldiers lower on the order are much better choices. So I got the shooting automated, but each reload was taking too much time since I had to reselect the shooter, select the shot, move the view down a level, shoot the target and abort. Having the soldier already selected cuts out 2 actions in the list allowing the script to run more efficiently. I'm going to try to get everything properly setup tonight, then start testing tomorrow morning. With a little luck and about 2 hours of babysitting the script to make sure it doesn't quit, I should have some prelims. --[[User:Zombie|Zombie]] 21:55, 11 March 2009 (CDT)

----
Looking forward to seeing that data! I did some more testing just for the special case of Large Units, about 40 tests. My tentative conclusions:

# Damage range per 'impact' hit is the same as regular units, around 5-10 x Vulnerability (maybe + MCD Burn time?)
# Large units go on fire about 1/7 of the time when receiving a direct hit - as expected
# Either all 4 segments go on fire, or no segments go on fire - no 'part segments on fire'
# Unit burn times are not correlated with unit damage received
# Auto fire has the same average damage level per hit as snap fire
# Unit Burn Time can exceed 5, both on Snap and Auto. Highs of 6 (Snap) and 7 (Auto) were seen. Maybe 1-5 + MCD Tile Burn Time?

All my tests were done on the grid-lined pavement tiles from urban terror missions, which have an MCD default burn value of 2. For some of the "setting the large unit on fire" tests, I had the target floating in mid air, because air does not burn even during the turn that the IN round explodes - it makes it easier to see the unit burning.

From Bomb Bloke's editor notes, the 4 potential MCD tiles in a map location are: a North Wall, a West Wall, a Ground tile, an Object tile. All 4 of these MCD tiles might have a burn time value. But Ground and Object are the most likely to be relevant.

[[User:Spike|Spike]] 21:58, 12 March 2009 (CDT)

:Ok, I got the script running and optimized it a bit to cut down some wait cycles. Right now it's cranking out approximately 400 trials per hour which is about as fast as I can make it go without removing some desktop icons (all the icons have to refresh at the end of each logging cycle which takes a little time). Anyhow, just for giggles I stopped it after 400 trials to get some prelims.

:<table {{StdCenterTable}} class="sortable">
:<tr {{StdDescTable_Heading}}><th align="left" width="90">Damage</th><th width="90">Count</th><th width="90">Pct%</th></tr>
:<tr><th align="left">1</th><td>68</td><td>17.0%</td></tr>
:<tr><th align="left">6</th><td>58</td><td>14.5%</td></tr>
:<tr><th align="left">7</th><td>45</td><td>11.3%</td></tr>
:<tr><th align="left">8</th><td>63</td><td>15.8%</td></tr>
:<tr><th align="left">9</th><td>55</td><td>13.8%</td></tr>
:<tr><th align="left">10</th><td>64</td><td>16.0%</td></tr>
:<tr><th align="left">11</th><td>47</td><td>11.8</td></tr>
:</table>
:If you average the percent columns, it comes to 14.28571429% while the expected is 1/7 or 14.285714285714285714285714285714 which is a difference of 4E-09. This means 400 reloads is plenty enough values for this application. Great news! Well, as you can see, instead of the set [0, 5, 6, 7, 8, 9, 10] for MCD of 1, this scenario where the MCD was 0 is shifted up by one [1, 6, 7, 8, 9, 10, 11]. Interesting.

:Tomorrow I'll rerun the MCD 1 scenario again to verify the values and damage set. Then it's on to the MCD of 2. --[[User:Zombie|Zombie]] 01:50, 13 March 2009 (CDT)

:: Extremely interesting! By the way, it was probably a late night but - the average any 7 numbers that (must) add up to 100% is always going to be 1/7th of 100%, so that result doesn't really demonstrate any confidence in the data. It would be the same with one result, or with a trillion results. The 4E-09 discrepancy is just the precision error in your calculator/spreadsheet's calculation of the percentages and the average of the percentages. You've got some considerable variation from 1/7th on the individual numbers, I'm not sure if that's just to be expected with only 400 trials. But for example "0" and "10" are both a bit high so it ''might'' be non-linear (probably not). Anyway we'll see when all your results are in! (To measure the degree of variation from the expected result, what you want is a chi-squared test or something - and I don't know what I'm talking about there so I'll shut up!)

:: I'm checking Bomb Bloke's MCD database, and there are some tiles in there (U_BASE 22-25) with MCD burn value of 30 - I might play with those and see if anything dramatic happens. Oh except looks like they can't be set on fire (255 flammability). There are others that are quite high (8-), and still flammable. Or I could hack an MCD file (scary). Maybe I'll just wait for your results Zombie! [[User:Spike|Spike]] 05:49, 13 March 2009 (CDT)

= Incendiary Research =

== Large Units On Fire ==

Here's another interesting test for setting Large Units on fire. Set AC-I power down from 42 to 1.
At this IC power, there is no area effect. You can't even start a fire on one tile.
All you can do is set units on fire with a direct hit. This means there is no way the other 3 squares of the
Large Unit are in the IC area of effect.

Result: Whether you hit a one square regular unit or a 4-square large unit, if it goes on fire, '''all''' squares of the unit still go on fire. Along with the fact that the inflicted IN damage level vs Large Units is basically normal (see above), this tends to confirm that being on fire is a "unitref" property and, unlike HE and Stun Bombs, is not applied (multiplied) vs the number of squares the unit occupies. (In fact it would be good to check that HE is actually applied separately to each square, with different HE strength, potentially different armour facing, etc. Maybe the engine just simplifies things and multiplies damage by 4?)

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)

== Unit Burn Time ==

Unit Burn Time seems to be considerably '''cyclic''' rather than random. Very often, it just steps down by one from the previous value. I suspect this is because the "impact" routine calls the "end of turn" incendiary/smoke routine (see [[User talk:Seb76#Incendiary Bug]]). Sometimes it does not happen, maybe because some other factor has caused the Burn Time to increase.

Here's some data. This was done against a Reaper with AC-I power set to 1 (and 10% TU Snap fire cost). But I've seen similar results with standard AC-I.

Hit H/H Dmg/Avg Burn Time
1 137/150 13 2
2 126/150 11 1
3 104/150 22 0 Very high damage (=13x1.7). Unit not on fire when game restored.
4 96/150 8 7
5 81/150 15 6
6 66/150 15 5
4,5,6 76/150 /9.33 5 (Auto) 9-10 (=5-6x1.7) is near minimum dmg
7 56 10 4
8 48 8 4 What happened here? didn't cycle. MIN dmg (5x1.7).
9 35 13 6
10 25 10 5
11 10 15 6 New shooter takes over
12 2 8 5

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)
:You're right on spot once again ;-) When a unit takes a direct hit from an IN round, it is set on fire (the duration is randomly chosen between 0 and incendiarydamagemodifier/20). Then the "end of turn" routine is called, which inflicts damage *and* decreases by one the number of turns to be on fire (done for all units). Then it sets on fire units standing in blaze. The duration is calculated as for direct hits; if the unit was already on fire, it'll take the maximum value between the new value calculated and the current value affected to the unit on fire. Not sure it is readable but I think you'll sort it out ;-) [[User:Seb76|Seb76]] 10:51, 15 March 2009 (EDT)

== Incendiary in TFTD ==

I read [[Weapons (TFTD)#Phosphor|somewhere]] there are reduced effects underwater (or enhanced effects on land) for TFTD Phosphor rounds. I couldn't find an exact statement of the quantitative difference - does anyone know this? [[User:Spike|Spike]] 14:53, 9 March 2009 (CDT)

:The effects of Incendiary weapons underwater (or Phosphor, as TFTD refers to it) is halved over the UFO equivalent. Incendiary weapons are doubly effective on the surface(Terror Missions) vs underwater, but of the three weapons that can fire Incendiary, two of them(Torpedo Launcher and Hydro-Jet Cannon) can only be reaction fired on land. The Gas Cannon can be fired in eiither location. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:08, 9 March 2009 (CDT)

:: It's clear that the effect underwater is half the effect on land. But does the base level (in USOPaedia / OBDATA) refer to land use or underwater use? [[User:Spike|Spike]] 15:13, 9 March 2009 (CDT)

:As I recall, the base level is on land. The numbers for Phosphor ammo are close to the UFO Incendiary damage numbers, but I know it spreads less underwater. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:15, 9 March 2009 (CDT)

:: Look at the (puny) area effect pattern sizes underwater, that sounds about right. Can anyone confirm this? [[User:Spike|Spike]] 15:40, 9 March 2009 (CDT)

There is actually no difference between the pattern for the Gas Cannon's P rounds underwater as on land. Both have a r=3, d=7 pattern. (CE version at least). Maybe the pattern is smaller the deeper you go? --[[User:Zombie|Zombie]] 16:45, 9 March 2009 (CDT)

<gallery widths="200">
Image:GC-P (underwater).png|Flame pattern from Gas Cannon Phosphorous rounds underwater.
Image:GC-P (on land).png|Flame pattern from Gas Cannon Phosphorous rounds on land.
</gallery>

:OK now I'm really confused then! (I realise I was getting confused with the Dye grenade's small footprint vs Smoke grenades). If the blast pattern is the same size, that implies the weapon power is unchanged. So in what sense is Phosphorus "half as powerful" underwater? Does it burn half as long? Is the impact and fire damage halved? [[User:Spike|Spike]] 16:49, 9 March 2009 (CDT)

I really doubt the damage to units would be affected if the power of the round was modified. The power of the round only determines the size of the pattern produced, not the damage inflicted to units. I'll have to check the burn times and spread rate but my thought is that the two are identical in the version I'm using. Like I said, the pattern may get smaller the deeper you go underwater. The pic above was for a shallow site. It'll take a while for me to find a deeper site to check it out, otherwise some editing of the game files may be necessary to force the scenario.

I just checked the Dye Grenade underwater and on land. Both produce the same r=1, d=3 pattern. So yeah, they are really pitiful when compared to the Smoke Grenade.

Don't really go for the use of "impact" damage with Incendiary/Phosphorous rounds. There is no real impact since the damage range is discontinuous. The unit either catches fire from the splash of fire (in which case it does 5-10 damage points), or the unit doesn't catch fire and the unit remains unharmed. If there were such a thing as impact damage, the range would be continuous like normal weapons, in this theoretical case it would be [0-10] inclusive (ie the set [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. --[[User:Zombie|Zombie]] 17:36, 9 March 2009 (CDT)

Anyway, the half thing came up because AQ was comparing TFTD to UFO, not comparing the effects in TFTD from underwater and on land. However, further comparisons reveal that a hacked HC-I round of 60 produces the same pattern as a GC-P/60 round. Perhaps this whole dilemma can be traced to the Dye Grenade? --[[User:Zombie|Zombie]] 18:28, 9 March 2009 (CDT)

:That's entirely possible the Dye Grenade is the source. However, several of the pages for the TFTD weapons state that Phosphor is far weaker in water, so I didn't check. My mistake. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:35, 9 March 2009 (CDT)

Thanks for the feedback everyone. So this could just be a recycled rumour? I guess the general assumption is that the game engines are identical, so we would want evidence that TFTD is different. Looks like Zombie has proved that the area effect is equal (at least at shallow depths). That leaves only the fire damage or fire duration. Testing that would require repeated observations to check if fire damage is less than 6/hit, less than 6/turn, and burning for no more than 2-3 turns. [[User:Spike|Spike]] 20:14, 9 March 2009 (CDT)

:As with any wiki where contributions can come from anywhere, there are bound to be problems with validity of the statements made. So unless those statements are backed up by real-life test data instead of memory or hearsay, take them with a grain of salt. The other point is to avoid spreading disinformation at all costs (I have been guilty of this as well, but try to at least quantify them). So there you go. I'm still trying to get a deeper underwater mission to check the size of the pattern produced there. Checking the spread of flames or damage inflicted to units shouldn't take too long though. I'll see if I can't get that done tonight yet. --[[User:Zombie|Zombie]] 20:23, 9 March 2009 (CDT)

:Ok, I ran some trials with an unmodified GC-P round on the normal seabed floor against soldiers having 100 health and 0 all-around armor. For the guy standing at GZ, I saw ending health values of 99, 94, 93, 92, 90, and 89 (n=50). So that comes out to 1, 6, 7, 8, 10 and 11 points of damage respectively. I didn't think 11 damage was possible. Here's where things differ though. All the other guys who were clustered around GZ always received only one point of damage, never more, never less. In EU, the guys around GZ took damage equal to the guy at GZ. Odd. So then it occurred to me that perhaps I should check the MCD values of the seabed (TFTD) and the desert (EU) landscapes. Both are basically identical in terms of armor. But the seafloor has a "time to burn" value of 0 while the desert has a value of 1. So maybe our understanding of normal fire isn't totally complete. I'm going to go back to EU and retest the desert landscape with varying MCD burn time flags to see how that affects damage. ;) --[[User:Zombie|Zombie]] 23:00, 9 March 2009 (CDT)

:: The whole Phosphor being half effective under water is related to the burn time and spread, if I remember correctly. The settings in the MCD files may be the culprit. The actual damage dealt or initial spread may not necessarily be affected.

:: Hey, I just had a wacky idea. XComutil. Use its feature where you can set the depth of a mission. Launch a mission on a island terror site map (again, use XComutil's map picker to get to this faster). Lots of grass to burn there. Set fire to it and count how many turns before the fires die out. Redo the test, but this time set the depth to a deeper level. Try the whole process out again.

:: Next repeat this with one of ye-olde seabed maps. They look really weird without the blue palette shift when played on land, what with the landscape being gray.

:: It's possible that the half-effectiveness relates to the fuel that the fire has to burn more than anything else. Further confirmation on how long the flames stick to a target when on land or underwater may be helpful. -[[User:NKF|NKF]] 01:28, 10 March 2009 (CDT)

:I've been burned one too many times using editors or utilities to mess with saved games. Half the time they introduce some unknown "feature" which isn't documented. Thanks, but no thanks. I only test with an unmodified game, except for the changes I make myself to keep control of the situation. Anyway, I tested a patch of fire on the seabed to see how long it remained lit (which has a "time to burn" value of 0). It only stayed lit the current round the shell detonated. After that the fire went out. So this agrees with what is expected. Will continue to work on this as I get time. --[[User:Zombie|Zombie]] 01:51, 10 March 2009 (CDT)

Well, I suppose my recommendation doesn't necessarily need XComutil. It would've certainly made it easier. But yes, it does introduce a few things that work behind the scenes that we might not know too much about. However, if I remember correctly, one of the battlescape savegame files should hold the depth level of the current map you are playing on. All you'll need to do is tweak that to change the depth of the map.

One other thing, the different effect HE has on the same tiles underwater and when on land (ala the Triton) may also be one of the other culprits behind the belief that phosphor is less effective on land. Being able to blow up the Triton on land, but have it appear virtually indestructable when underwater does that. -[[User:NKF|NKF]] 01:59, 10 March 2009 (CDT)

----

re Zombie's underwater tests, there is normally (i.e. on land in EU) a difference between the IC damage on the target of the direct hit, vs lower damage to others in the area of effect (hmm contrary to my IC kill modelling assumptions: uh oh I may've spoken to soon). But only seeing 1 damage on the others in the AoE does seem low. We need to figure out why. Did any of the other targets catch fire? Does that ever happen underwater? Do tiles ever burn past the turn when the IC round is fired? Any of these factors would reduce total fire damage/effectiveness by '''more''' than half. Actually, doesn't it say the 1-12 damage for "in fire" is ''not'' random, but dependent on terrain type? That could be the answer.

The [[Incendiary]] article actually mentions '''4''' modes of fire damage, only 3 of which are quantified:

#"impact",
#"being in fire"
#"being ''on'' fire"

The 4th mode is "damage from burning ''terrain''. Only a tantalising mention is given, no quantitative details. This could be the source of the discrepancy. In fact it might be a component of "being in fire" that's not fully understood. I think Zombie is right to review the assumptions on this one - nice work! [[User:Spike|Spike]] 04:05, 10 March 2009 (CDT)

:As I recall, "damage from burning terrain" is synonymous with "Standing on a tile that's currently on fire." Thus "Being in fire." But that's me and I'm tired this evening, so I could be wrong. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:30, 10 March 2009 (CDT)

I performed my TFTD Phosphorous tests underwater and after the flames died out some of my men did catch fire. So this part seems to jive with that of EU. Tiles do not burn longer than its "time to burn" value in the MCD files. So for instance, in the seabed underwater testing mission, the tiles have a MCD burn value of 0 which corresponds to the results seen (ie fire didn't stick around into the aliens turn or X-COM's next turn either, it only stayed lit the turn it detonated). There really is only 2 "modes" of I/P/fire damage:

<ol><li>The code used for determining if a unit catches fire: 0 damage (if the unit didn't catch and was able to shrug it off) and 5-10 (if the unit catches).</li>
<li>Standing in fire.</li></ol>
At least from the initial tests in TFTD, units outside GZ are just considered to be standing in fire that turn and always take 1pt of damage. Anyway, I don't want to talk myself into a hole without doing more tests. All the following trials I do will be in EU to hopefully curtail any unknowns in TFTD. Once EU's code is figured out then it can be applied and compared to TFTD. --[[User:Zombie|Zombie]] 09:06, 10 March 2009 (CDT)

: If they are "standing in fire", do you think the 1pt damage/turn is based on the fire characteristics tile/terrain type they are standing on? Is it more generally 1-12/turn, dependent on terrain? Also if you get a chance can you test large units and see what kind of effects they take on the GZ+1 squares? If the GZ+1 squares of a large unit are just 'standing in fire' rather than 'catch fire/5-10 impact damage' this will substantially weaken IC vs large units. And I will have shouted too soon! :) [[User:Spike|Spike]] 09:18, 10 March 2009 (CDT)

I did some ad-hoc tests in TFTD. Actually I just ran around firing GC-P and HJ-P rounds everywhere. :) On a typical seabed layout, I found that most things don't burn - the fires don't last into the next turn. The only things I could get to burn were the green moss stuff and and coral skeleton "trees". Even the barrels do not burn. Also, I did not see much sign of terrain damage caused by the fires. But the moss and coral did burn for the normal period, i.e. 1-5 turns.

I also managed to kill an Aquatoid with a single direct hit from a GC-P, in one turn. He died at the end of my turn or the start of his. That seems unlikely. 5-10 from being hit, plus 1-12 for standing in fire, plus maybe another 5-10 from being on fire? It's just about possible I suppose, to max out near 32 damage (if the terrain offers you "12" when it burns). Anyway those are my unsystematic enquiries. I have the 8 save files of various stages of the battle if anyone wants to take a look. It was from a virgin TFTD installation and there was no editing or jiggery pokery.

OK I've uploaded the save files [[Image:TFTD Incendiary Tests 01 Spike.zip]] and taken a look myself with BB's editor. Prior to being hit (Game_4) our Aquatoid was in rude Health, 30/30. Immediately after being hit (Game_2) he was at 19 Health (no Stun damage) and On Fire, as well as Standing in Fire. That implies 11 Damage from the "impact effect" which is not supposed to happen. As noted, at the end of the same turn or beginning of his next turn, he dies. He looks to be standing on a standard seabed square, just sand, the kind of thing that does not burn. He is next to some of the brown cushion-like coral, but I don't think that burns, at least not over multiple turns. In fact in the same turn he is hit, at the end, you can see him dead (Game_3). Since there was only one alien, he died in the same turn. OK that's slightly confusing, maybe someone can double check the turn numbers in the save files (don't know where they are).

[[User:Spike|Spike]] 13:29, 10 March 2009 (CDT)

Doh. I is a idiot. The Aquatoid was killed by the incendiary fire bug - I fired extra IN rounds at terrain objects after he was on fire. Which explains why he is already dead by the end of my turn. [[User:Spike|Spike]] 15:08, 10 March 2009 (CDT)

:Yeah, you gotta watch that. Well, anyhow, I edited the desert landscape in Enemy Unknown to have the same MCD "time to burn" value of 0 as the seafloor in TFTD. From the limited tests, the results look the same as in TFTD. (Fire burns out after the initial turn it detonated, units around GZ taking 1 unit of damage while the guy at GZ got more). So that means I can focus my efforts on EU with little worry because there will be no issues. I'm going use BB's logger and AHK to automate the data gathering aspect to save me a bunch of time. I'll probably need the full requisite 2000 reloads though, as the guy at GZ is not the same as the 24 soldiers around him. Wish me luck. :) --[[User:Zombie|Zombie]] 15:54, 10 March 2009 (CDT)

Good luck! I just read the MCD article, and it mentions 2 fire-related byte fields in MCD - "likelihood of catching fire" as well as "time to burn". Is the last field variable or fixed? Could the first field determine the damage/turn to units when it's on fire? Also with a possible 4 terrain items that could all be burning, is the maximum damage higher than 12? [[User:Spike|Spike]] 16:10, 10 March 2009 (CDT)

:Offset 45 is the flammability rating of the tile. This most likely controls whether an adjacent fire will spread to the tile in question. (For instance, if a fire is burning and the next tile over is a tree or something, it'll probably spread there fast because of the combustibles present). The other byte is offset 57 which is the one we are after. Don't know about the 4 types of things which can exist on a tile at once. I think the most I have ever seen is 2 (usually ground and a wall). Wouldn't hurt to edit a tile to include all 4, but that's an entirely different test to do. It'll have to wait until we get a better understanding of basic fire. ;) --[[User:Zombie|Zombie]] 19:38, 10 March 2009 (CDT)

::Here's a question. On Large units, if only one segment of the Large unit is on fire, will the fire spreading code allow the other three segments to catch on fire? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:13, 10 March 2009 (CDT)

:I highly doubt it. Unit fires are completely different creatures from terrain fires. Needs testing though. --[[User:Zombie|Zombie]] 20:55, 10 March 2009 (CDT)

::Yes it would have to be a very special case, since afaik fires do not spread from regular units on fire to adjacent terrain or to other adjacent regular units. Though it would make more sense than any of those things. [[User:Spike|Spike]] 21:03, 10 March 2009 (CDT)

== Incendiary Bug ==

(Also known as the [[Known_Bugs#Funky_Fire|Funky Fire/Smoke bug]].) I made some suggestion about why this bug happens, and how the code could be patched to fix it: [[User talk:Seb76#Incendiary Bug]]. [[User:Spike|Spike]] 07:13, 12 March 2009 (CDT) Here is the general discussion of the bug:

With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

I also suspect that other "end of turn" processing happens with every IN round fired. I am pretty sure "fire spreading" checks occur, as I have seen fire spread when using perfectly accurate shots. Either "fire spreading" happens, or there is a random element in incendiary area of effect, that is definite. I want to repeat these tests to see if "catch on fire" effects also happen for those who are standing in fire when an IN round is fired. [[User:Spike|Spike]] 08:59, 31 March 2009 (EDT)

== Mwahaha ==

Was exploiting the Elevator Shield trick on an Alien Base Assault, and I had the forethought to pack lots and lots of Incendiaries. My sick sick mind found it amusing to set all those aliens on fire and watch them roast stupidly and helplessly. (Jasonred)

= Fire Damage =
(moved from talk:UFOextender)

Not sure if the bug is already posted. And Not sure if I should post the bug here or in [[Talk:Incendiary]]. Problem is if you use extender to fix funky fire bug. Incendiary no long does any damage at all. Units only take the small amount of damage after ending turn because they're on fire. Using 1.28.3 extender

To test this. I stripped a soldier of armour. And pounded four incendiary rockets into the soldier in the same turn. No damage. And then next turn, his health drops a little because he's standing in fire. This may not be a problem for most players. But it is still a major bug. I understand the funky fire problem is already difficult to fix, and I say thanks to all who will try to help solve this bug. [[User:Hellblade|Hellblade]] 14:44, 28 September 2012 (EDT)

: That's not a bug, that's the fix. Incendiary damage is only applied at the end of the turn. Think about it... does fire kill faster than a bullet? Faster than a grenade? Can you kill someone with fire faster than they can get a shot off back at you? No, to all these things. To compensate for fixing the bug, fire damage is doubled compared to the previous end-of-turn fire damage (that always existed). It is no longer applied per shot or per impact. All you get "per impact" is another chance to set the target unit itself on fire. Incendiary is a weak attack. It has the benefit of a wide area effect, no HE block, and ignores armour. There are situations when IN is the only effective weapon XCOM possesses. But, like everything, it has strengths and weaknesses. [[User:Spike|Spike]] 15:51, 28 September 2012 (EDT)

:: I see your point but let me elaborate. Heat, not fire, do kill as fast as bullets. The original game mechanics separated heat from fire just as in real life. It intended to have the big heat blast damage first and then the small fire damage per turn.
:: Take the most extreme case, napalm or volcanic lava, you get fully cooked in less than a second - just by heat alone, and you may/may not catch fire later on. And heat blasts travel as fast as bullets, in some cases as fast as light. I believe the game has different Incendiary damage values to do different damage according to how strong the heat is, not the fire afterwards. The damage by fire later on makes sense because natural burning fires aren't that hot comparatively.
:: I understand the difficulty in trying to fix this. But before this fix you could kill a reaper by a few AC-I shots (which is their weakness) and now you can empty the two clips at it and it'll never die. [[User:Hellblade|Hellblade]] 03:11, 4 October 2012 (EDT)

== Advantages/Disadvantages of using Incendiary for nighttime light ==

It seems for most folks that electro-flares are the go-to for night lighting and incendiary rounds are a distant afterthought.
With that in mind I propose this list of pros/cons to using incendiary at least as a major complement to flares.

Cons:
#Low damage, and for each soldier with incendiary rounds loaded they can't attack with more effective weaponry unless
##they unload and reload
##they carry another gun or use 'nades/stun rod
#Not re-usable, will always be depleting stock

Pros:
#Not dependent on throwing limitations of range and arc/trajectory
#Very efficient in terms of light-output per weight, storage space, and time units
#Can set area on fire to illuminate where the enemy is initially, then as the fire burns out you may move into the cover of the smoke it generates
#Does at least some damage to enemies - very unlikely to kill them, but softens them up so future attacks more likely to neutralize
#Area denial - fill a small building or enemy craft with flames and watch them flee out into your reaction fire, or at least out where you can get them, they don't get the drop on you
#At least in OpenXCom the enemies on fire should provide lighting, helping to spot them at a distance
#Fire is less vulnerable to being destroyed by nearby explosions, unlike those wimpy flares. And even if it is snuffed, it isn't something you were counting on re-using
#Reaper vulnerability
#Zombies not re-spawning to 'lids when KO'd by fire splash
#You can dedicate a few number of soldiers to throwing fire around while the rest keep their hands and TU's free to attack
#Soldiers that go berserk/get MC'd can't hurt armored soldiers w IC fire

Now it seems to me that the first Con is major and obvious, but the many Pros are overlooked. Also that big Con could be greatly mitigated by cannon wielders w incendiary carrying a decent secondary weapon: thinking plasma rifle or pistol, laser pistol

any I'm missing? what about putting this on the main page?

Talk:Incendiary

2021-07-08T16:50:34Z

Mugwump: /* Advantages/Disadvantages of using Incendiary for nighttime light */

== General Comments ==

For now, we'll just say the smoke + incendiary stun effects only work on X-Com owned units until some tests can be run to confirm this. It's unusual that only X-Com units are affected, but the game has been known to surprise you even after you think you've worked something out.

- [[User:NKF|NKF]]

----

Given how aliens love to hang around in a smoke-filled crashed UFO, IC rounds would be insanely powerful if they did actually work against aliens in smoke. I'm glad they don't ''seem to'', as I'd be very tempted to cheat with it. They do work against aliens standing in fire, though, which is still quite cheaty...--[[User:Ethereal Cereal|Ethereal Cereal]] 21:35, 5 May 2006 (PDT)

:I do consider the "standing on fire + new IC explosions = damage" a cheat. So I just don't abuse it. I only use IC rounds to illuminate or to finish off hiding aliens. It can also work as a "pass-through-and-die" tactic, the same way Proximity Nades work, although fire damage is pretty sad xD. --[[User:Nekrocow|Nekrocow]] 00:36, 24 June 2012 (EDT)

:: I use it a lot in TFTD to clear out those island bunkers and the upper storage levels of the large train station. Either the aliens roast alive, or they come out. Otherwise yes, it's no doubt a cheat. Well, more a bug exploited as a cheat. -[[User:NKF|NKF]] 02:09, 24 June 2012 (EDT)

-----

I just edited the Incendiary page a bunch, because Brunpal's [[Talk:Experience]] questions about Incendiary sparked my interest... I never did test IN vs. experience. It's a very good question ''if'' it turns out to cause Firing experience. But while reviewing this page, I had a number of questions, for anyone interested. Also, I only tried to clarify things, and don't know Incendiary well, so fix anything you know I got wrong:
#Did I get it right re: the set [ 0, 5, 6, 7, 8, 9, 10 ] for chance of initially catching fire? I over-wrote "linear" because it seemed odd when XCOM usually goes, e.g., 0-10. (Who tested this? - A little help here please. Just making sure.)
#Why flame a zombie unless it's near death (and how can you know if it is)? It's been a long time since I used fire - if you don't have flying armor, why mess around with a zombie by burning it, why not Heavy Plasma it.
#Any research/data on tile flammability versus duration of burning is appreciated. Probably it should go on the [[Terrain]] page byte, but be clearly referenced here. It's just a curiousity, but an interesting one.
#The last line of the page says ''"The damage values listed in the UFOpaedia do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames."'' Does anyone know IN strength vs radius, then? Should be easy to test and post.
#NKF, Zombie, or anyone else... would you mind seeing if Incendiary causes the Experience counter to increase? Brunpal is right that it's important to [[Experience]]... I found [[Small_Launcher#Experience|Stun Bombs]] to count for experience across their whole range, even if no stun damage occurred... if you have 11+ Mutons in a firing squad situation, passing around an [[Auto-Cannon]] with Incendiary may be better than standard pistols, depending on the range of the blast. I could test it, but it's been a long time since I've delved into the files; maybe one of you have them more close to hand. [[User:MikeTheRed|MikeTheRed]]
-----
:Offhand, the only way I could think of to check the remaining HP on a Zombie would be by using a [[Mind Probe]]. Given the relative uselessness of a Mind Probe after Psionics are developed, as well as the time needed to use the Probe once, this seems a rather impractical course of action, unless your Rear Commander has nothing better to do. I agree, Heavy Plasma on Auto is better. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 1 August 2008 (PDT)
-----
#Yeah, the set is correct. When a unit is shot with an incendiary round, the game does a calculation to determine if the unit catches fire. If it doesn't catch fire, the unit takes no damage (the 0 in the set). If the unit does catch fire, it will take between 5-10 damage points. Stupid discontinuous range, but that's what happens. As you may guess, I did the Incendiary trials over at the StrategyCore forums in the Damage Modifier topic - see [http://www.strategycore.co.uk/forums/index.php?s=&showtopic=746&view=findpost&p=39672 this] post for the particulars.
#Why flame a Zombie? Simple. A Zombie which is killed by an Incendiary round doesn't turn into a Chryssalid. Zombies are easily outrun, so you can just keep picking at them from a short distance with Auto-Cannon Incendiary rounds and then running away. Fairly effective, even when your troops do not yet have armor to protect them. And when you do not have the luxury of the Heavy Plasma early in the game, Incendiary is a good way to avoid an overabundance of Chryssalids who are not so easy to kill. As for checking the Zombie's stats, you can only rely on the Mind Probe or Psi. Neither are available early either (the Mind Probe is usually low on the research tree for most people even though you can collect enough, and Psi is difficult to use as a soldier needs to be quite proficient to use MC.
#I have been meaning to do some tests in flammability vs terrain but only recently started fooling with MCD values. It'll be next on my list.
#Here, I uploaded a very recent spreadsheet containing both I and Smoke when damage values are hacked. See [[Media:Incendiary_and_Smoke_Patterns.zip | this file]] which contains both.
#I think I fooled around with Incendiary recently in conjunction with promotions. Soldiers who shot aliens with "I" didn't get promoted. Logically, that would mean the experience counter didn't increment. UNITREF.DAT would need to be checked to verify though. Addendum: indeed, as BB mentioned in the experience page (and a quick glance at the UNITREF.DAT experience counters by myself to triple-check my aging brain), Incendiary rounds do not increase any of the experience counters.

Hope this clears up some of the issues/concerns here. --[[User:Zombie|Zombie]] 21:16, 1 August 2008 (PDT)
----
<i>"The damage values listed in the [[UFOpaedia]] do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames. Fire is unlike other damage; it works at initial blast and then over time, as described above."</i> and
<i>"Initial "impact" damage from incendiary ammunition is either for no points (unit does not catch fire), or between 5-10 points (unit catches fire)."</i>

This should be stressed on ALL the various relevant pages. It's important. 6.4 dmg vs 90 dmg is a significant difference!--[[User:Brunpal|Brunpal]] 09:31, 2 August 2008 (PDT)
----
It looks like Incendiary is gaining some clarity (at least for me), thanks for starting it Brunpal...
*The "6.4" was only for the initial IN round impact (set [ 0, 5-10 ]); it can then burn for 4 more rounds (set [5-10]). Perhaps a short way to state this complicated damage type is "Minimum 0 (unit does not catch on fire) ''OR'' unit catches on fire 1-5 turns, 5-10 damage/turn, 5-50 damage in total (average 21.5)". Does that look right, Zombie? I'm not sure where you got 90 from Brunpal...
:90 is the listed damage from an IN rocket.--[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)
*However, the numbers I just stated do not count possible additional damage from nearby terrain being on fire (as opposed to yourself). Maybe those should be included somehow. (And clearly, fire is much more dangerous outdoors than inside UFOs, where terrain does not burn.) But since terrain fire can last a variable number of turns, I guess you can't have a maximum damage. Average terrain damage from fire would be 6.5/terrain (1-12), but also, it can keep the unit itself burning more than 5 turns... hard to model.
*Good point about flaming zombies, Zombie. I guess you ought to know, eh? :)
*The spreadsheet looks great. Perhaps one of us can pull out the area patterns for non-hacked IN weapons and put them on the relevant pages. When it's done, the spreadsheet itself would be an asset to Incendiary (or maybe [[Damage]], if it's listing all types of damage). As has been stated, it's the size (area) of the blast that actually directly relates to incendiary weapon "strength"... the diameters you found are probably what should be in parentheses next to weapon strength, although damage can appear as well.
*Ok, no experience from Incendiary blasts. It might've been real interesting if there were, but it didn't occur to me to test. (Or maybe I tested it briefly so long ago that I forgot.) I would've guessed that they did, because the stun bomb and explosives do. Oh well.
*P.S. Brunpal, we may not have touched pages in a year, but most/all of us have "Watch this page" turned on, so we get immediate notification of any pages we've edited or Watched. :)
-[[User:MikeTheRed|MikeTheRed]] 09:17, 5 August 2008 (PDT)
----
*Sounds correct MTR. I think Brunpal was just comparing the "damage" (actually strength) of the Incendiary Rocket (90) to the average damage due to the "impact" of the blast (6.4).
*Well, it isn't ''nearby'' terrain on fire which you have to worry about, it's the tile directly underneath a units feet which causes the most concern. If that tile is on fire and the unit doesn't move, it will take 1-12 damage points. While true that terrain on fire can last a variable number of turns, there is a definite upper-limit to how much damage a unit can possibly take. Fires don't last forever, and the combustibles eventually are consumed leaving either scorched earth or a damaged tile. Those damaged/destroyed tiles usually cannot be started on fire again by the spread of flames. They can only be set ablaze with incendiary ammo, and even then for only 1-3 turns (normal for dead tiles). So it's certainly possible to find a max damage. And for the most part, the things that burn the longest are usually objects, not tiles. And most objects you can't stand on anyway. But I totally agree that it's hard to model how fire functions due to the two forces at work: "impact" damage and damage due to standing in fire.

P.S. Some of us are actually around here and don't need to be coaxed back into existence by an email when a watched page is changed either. Just because it's quiet, it doesn't mean nobody's home. :) --[[User:Zombie|Zombie]] 20:34, 5 August 2008 (PDT)
----
While understanding the whole formula for fire and fire damage happens is useful, it was not thinking to go that broad. I was just interested in what occurs from the moment a solider takes his shot, to the time that solider gets his TU back. ie damage from incendiary rounds vs fire damage. --[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)

----
It looks to me that, unlike all other forms of damage, Fire damage ignores armor, goes right past it. If so, this should be made explicit on the main page? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 05:55, 30 May 2021 (UTC)
:Fire damage doesn't ignore armor - power suits for instance can't be damaged by fire, except if the unit is already injured. Read carefully the Damage section - there's a lot of nuances about how fire works. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 03:03, 1 June 2021 (UTC)
:: What I meant is ignore armor ratings for damage calculation. While accounting for the resistances listed on the Damage Modification page, doesn't incendiary act as if front, side, back and under armor are 0 for calculation? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:21, 1 June 2021 (UTC)

== Incendiary vs Large Units ==

We're discussing this in [[Talk:Sectopod#Incendiary vs Sectopod]], and a question came up. When an IN round impacts one segment of a large unit, presumably that segment gets the "Incendiary impact" function, i.e. 6/7 chance of catching on fire for 5-10 damage plus 1-5 turns of being on fire. Does the same "impact" function also apply to the 3 adjacent squares (6/7 chance), or is it just the "standing in fire" chance? If you had multiple regular-sized units standing in the area of effect of an IN round, they would each get "impact" effects (right?). So it ''seems'' logical that all 4 segments of a large unit, inside the area of effect, are also exposed to "impact" effects. But I wanted to check. [[User:Spike|Spike]] 06:34, 9 March 2009 (CDT)

Oh boy! Calculating this not only depends on a lot of unknown assumptions, but is fiendishly complicated - especially if you factor in the "funky fire" bug. And contrary to my noblest efforts, it's impossible to use IN weapons without inadvertently exploiting this bug. Even if you only fire IN at a single target until it's dead, once the target is "standing in fire" you effectively just can't miss.

Anyway back to the Large Targets specifically. The key assumption above is whether all regular-sized units in the area of effect of an IN burst are affected with "impact effects" - 5-10 dmg & 6/7 chance to catch fire. If they are, it's reasonable to assume the same thing happens to the 3 other segments of a Large Unit. However I suspect this is not the case, and strictly speaking "impact" effects should only occur at the single, impact square of an IN round. Testing needed!

More likely, the GZ+1 squares, whether occupied by small or large units, are only subjected to the "standing in fire" effects: 1/3 'catch fire' probability, and 1-12 terrain-based damage. And these effects are applied once per turn, not once per hit.

However, all of this is turned on its head by the 'funky fire' bug. After the first round hits, all units (and all Large Unit segments?) are "standing in fire". (Though maybe these fire damage routines run only for the "control" segment of the Large Unit? Possible, but unlikely.) Since they are standing in fire, the funky fire bug applies and all units/segments are hiit with "impact" effects.

So assuming a Large Unit is ''already'' standing in fire (e.g. from a previous IN hit or near miss), damage per IN round fired is 6.4 x 4
= 25.6 average, 10x4= 40 max. Subject to resistance/vulnerability modifiers, but ignoring armour level. In addition as multiple IN rounds are fired, the chance of all segments catching fire quickly approaches certainty. This not only means the Large Unit will sustain further damage at the end of the turn, it makes it impossible to escape the 'funky fire' trap by moving out of burning squares.

(Any testing needs to be very careful and probably only fire a single IN round per game, otherwise 'funky fire' will skew the results.)

So, in conclusion, the TU/kill factors I put up on the Talk pages for the Large Units ([[Talk:Reaper]], [[Talk:Cyberdisc]],[[Talk:Sectopod]]) should pretty much reflect the 'funky fire' reality after the first round connects, apart from the fact that you actually can't miss. The very first IN round to be fired would have the same effect (for immediate damage) on a Large Target as on a small one. But I really don't want to update the numbers to reflect this fact, it's just too awful. For AC-IN, the firepower factors will be about 6 times better than stated. Maybe I'll just remove them. :(

[[User:Spike|Spike]] 15:51, 10 March 2009 (CDT)

=== Simple Tests ===

I did a small number of tests and found some interesting results. In 5/5 tests, all 4 squares of the target (Reaper) were on fire the following round. (It's hard to tell if they are on fire the same round, as you need to extinguish the fire with smoke to see). Perhaps this makes sense, as it's a UNITREF attribute and so applies to the whole unit, not its 4 component squares?

Looking at the damage, it looks like "impact" and "on fire" damage applies to all 4 squares, i.e. x4 normal. Damage clusters tightly around 16-18 per hit which is roughly the expected value, maybe a bit lower (at x4). And since we '''are''' on fire, should expect an average of 7.5 ({5..10}/6) rather than 6.4 ({0,5..10}/7? Maybe something else is going on here, as these numbers seem a little low - 6.4 x 4 = 25.6 per hit or 7.5 x 4 = 30.0 per "on fire" hit might be expected on a Large Unit.

:Drat. I didn't factor in the Reaper's 170% Susceptibility to Incendiary. So the actual damage levels are more like 10 per hit. Maybe there is no multiplier for the 4 squares? Hard to figure out what's going on here. In tests on hacked humans, armour level is not a factor vs Incendiary damage, otherwise I'd suspect the under-armour or something. 2.5 avg damage per segment seems too low. 10 average damage per alien seems too high - that should be the max, not the average. Is some mechanic pushing the average up to the max? I don't have a clue right now. [[User:Spike|Spike]] 06:53, 11 March 2009 (CDT)

The damage seems to be regardless of "funky fire" effect. A round fired at a target that is not burning / in fire seems to do about the same damage, per hit, as one that is in fire / on fire and so subject to the funky fire bug. So the only 'bad' effect of the bug is that you never miss, and you hit everything that is in fire / on fire. Not quite so bad, and it allows you to play honest by only ever firing at one target, not hitting any other targets by accident (!), and firing from point blank range so it doesn't matter that you never miss.

Burn Time was as high as 7 when multiple IC rounds were fired (on auto). Higher than we thought possible (1-5 range expected). However it sometimes goes DOWN after additional hits. Possibly the value is re-randomised with every new IC impact, but hits are cumulative while firing auto bursts?

Here's the raw test data:

Test 1.
-
2 DH on Reaper, mix of auto and snap, some other IC impacts on others
Burn Time=7 - exceeds known limit of 5
All 4 sq on fire next turn
Is 'on fire' global? It's in Unitref, so maybe
-
Test 2.
-
1 DH on Reaper, only IC shot fired in game.
In firing turn, taken 132/148 = 16 damage. Burn time=3
Start of T+1, taken 122/148 10 more damage, Burn time=2
T+1 Reaper shows all 4 squares burning
-
Test 3.
-
Revisit #2 firing turn... fire another round (this will use funky fire)
So 2nd IC hit, 2nd rd fired, same target.
Health now 114/148, further 18 damage
But Burn time has dropped to 2! Must re-randomise on each hit??
Maybe only accumulates during auto burst?
-
Test 4.
-
Let's try lots of hits. Hack up accuracy to 255
OK 3 out of 3 hits on Auto
T+0 Health=98/148=50 damage (17 avg) Burn=6
T+1 Health=81 (17 more dmg) Burn=5 All 4 squares on fire.
-
Test 5.
-
Revisit #4 and push to 6/6 hits
T+0 Health=41/148=107 (18 avg) damage Burn=7
T+1 Health=21 (20 more dmg) Burn=6 All 4 squares on fire.
-
Methodology (Apart from Test 1) = only ever 1 (same) target in any IC AoE; no misses
(To try to minimise the impact of 'funky fire' effects - but can't eliminate)

[[User:Spike|Spike]] 23:27, 10 March 2009 (CDT)

I re-ran the same simple tests against a regular-sized (Floater) target instead. The results agreed much better with the 'standard model' of [[Incendiary]] effects. All results were within the permitted ranges in the 'standard model', though some values were unexpectedly. I think some variables to look for in Incendiary mechanics are:

* Large Unit vs regular unit behaviour looks to be different
* Auto burst vs single explosion looks to be different (maybe just due to funky fire bug, maybe not)
* Tile MCD "time to burn" value seems to affect one or more of the other calculations / probabilities
* Burn Time on the unit can go up as well as down. New hits seem to re-randomise the value.
* End of turn processing does not always reduce unit Burn Time by 1. Can a terrain fire add to unit Burn Time?

[[User:Spike|Spike]] 21:25, 11 March 2009 (CDT)

:I doubt a terrain fire adds to the time a unit is on fire. Actually, I'm quite positive on this since my tests from a while back were quite thorough. The counter can only tick down to 0, and when it does a terrain fire will have a chance of "reigniting" the soldier again.

:Anyway, I had to start from scratch again on testing due to a few issues with my test scenario. I totally forgot that the first soldier on the unit roster is a bad choice for a "designated hitter" since he can never be automatically selected on a reload. Soldiers lower on the order are much better choices. So I got the shooting automated, but each reload was taking too much time since I had to reselect the shooter, select the shot, move the view down a level, shoot the target and abort. Having the soldier already selected cuts out 2 actions in the list allowing the script to run more efficiently. I'm going to try to get everything properly setup tonight, then start testing tomorrow morning. With a little luck and about 2 hours of babysitting the script to make sure it doesn't quit, I should have some prelims. --[[User:Zombie|Zombie]] 21:55, 11 March 2009 (CDT)

----
Looking forward to seeing that data! I did some more testing just for the special case of Large Units, about 40 tests. My tentative conclusions:

# Damage range per 'impact' hit is the same as regular units, around 5-10 x Vulnerability (maybe + MCD Burn time?)
# Large units go on fire about 1/7 of the time when receiving a direct hit - as expected
# Either all 4 segments go on fire, or no segments go on fire - no 'part segments on fire'
# Unit burn times are not correlated with unit damage received
# Auto fire has the same average damage level per hit as snap fire
# Unit Burn Time can exceed 5, both on Snap and Auto. Highs of 6 (Snap) and 7 (Auto) were seen. Maybe 1-5 + MCD Tile Burn Time?

All my tests were done on the grid-lined pavement tiles from urban terror missions, which have an MCD default burn value of 2. For some of the "setting the large unit on fire" tests, I had the target floating in mid air, because air does not burn even during the turn that the IN round explodes - it makes it easier to see the unit burning.

From Bomb Bloke's editor notes, the 4 potential MCD tiles in a map location are: a North Wall, a West Wall, a Ground tile, an Object tile. All 4 of these MCD tiles might have a burn time value. But Ground and Object are the most likely to be relevant.

[[User:Spike|Spike]] 21:58, 12 March 2009 (CDT)

:Ok, I got the script running and optimized it a bit to cut down some wait cycles. Right now it's cranking out approximately 400 trials per hour which is about as fast as I can make it go without removing some desktop icons (all the icons have to refresh at the end of each logging cycle which takes a little time). Anyhow, just for giggles I stopped it after 400 trials to get some prelims.

:<table {{StdCenterTable}} class="sortable">
:<tr {{StdDescTable_Heading}}><th align="left" width="90">Damage</th><th width="90">Count</th><th width="90">Pct%</th></tr>
:<tr><th align="left">1</th><td>68</td><td>17.0%</td></tr>
:<tr><th align="left">6</th><td>58</td><td>14.5%</td></tr>
:<tr><th align="left">7</th><td>45</td><td>11.3%</td></tr>
:<tr><th align="left">8</th><td>63</td><td>15.8%</td></tr>
:<tr><th align="left">9</th><td>55</td><td>13.8%</td></tr>
:<tr><th align="left">10</th><td>64</td><td>16.0%</td></tr>
:<tr><th align="left">11</th><td>47</td><td>11.8</td></tr>
:</table>
:If you average the percent columns, it comes to 14.28571429% while the expected is 1/7 or 14.285714285714285714285714285714 which is a difference of 4E-09. This means 400 reloads is plenty enough values for this application. Great news! Well, as you can see, instead of the set [0, 5, 6, 7, 8, 9, 10] for MCD of 1, this scenario where the MCD was 0 is shifted up by one [1, 6, 7, 8, 9, 10, 11]. Interesting.

:Tomorrow I'll rerun the MCD 1 scenario again to verify the values and damage set. Then it's on to the MCD of 2. --[[User:Zombie|Zombie]] 01:50, 13 March 2009 (CDT)

:: Extremely interesting! By the way, it was probably a late night but - the average any 7 numbers that (must) add up to 100% is always going to be 1/7th of 100%, so that result doesn't really demonstrate any confidence in the data. It would be the same with one result, or with a trillion results. The 4E-09 discrepancy is just the precision error in your calculator/spreadsheet's calculation of the percentages and the average of the percentages. You've got some considerable variation from 1/7th on the individual numbers, I'm not sure if that's just to be expected with only 400 trials. But for example "0" and "10" are both a bit high so it ''might'' be non-linear (probably not). Anyway we'll see when all your results are in! (To measure the degree of variation from the expected result, what you want is a chi-squared test or something - and I don't know what I'm talking about there so I'll shut up!)

:: I'm checking Bomb Bloke's MCD database, and there are some tiles in there (U_BASE 22-25) with MCD burn value of 30 - I might play with those and see if anything dramatic happens. Oh except looks like they can't be set on fire (255 flammability). There are others that are quite high (8-), and still flammable. Or I could hack an MCD file (scary). Maybe I'll just wait for your results Zombie! [[User:Spike|Spike]] 05:49, 13 March 2009 (CDT)

= Incendiary Research =

== Large Units On Fire ==

Here's another interesting test for setting Large Units on fire. Set AC-I power down from 42 to 1.
At this IC power, there is no area effect. You can't even start a fire on one tile.
All you can do is set units on fire with a direct hit. This means there is no way the other 3 squares of the
Large Unit are in the IC area of effect.

Result: Whether you hit a one square regular unit or a 4-square large unit, if it goes on fire, '''all''' squares of the unit still go on fire. Along with the fact that the inflicted IN damage level vs Large Units is basically normal (see above), this tends to confirm that being on fire is a "unitref" property and, unlike HE and Stun Bombs, is not applied (multiplied) vs the number of squares the unit occupies. (In fact it would be good to check that HE is actually applied separately to each square, with different HE strength, potentially different armour facing, etc. Maybe the engine just simplifies things and multiplies damage by 4?)

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)

== Unit Burn Time ==

Unit Burn Time seems to be considerably '''cyclic''' rather than random. Very often, it just steps down by one from the previous value. I suspect this is because the "impact" routine calls the "end of turn" incendiary/smoke routine (see [[User talk:Seb76#Incendiary Bug]]). Sometimes it does not happen, maybe because some other factor has caused the Burn Time to increase.

Here's some data. This was done against a Reaper with AC-I power set to 1 (and 10% TU Snap fire cost). But I've seen similar results with standard AC-I.

Hit H/H Dmg/Avg Burn Time
1 137/150 13 2
2 126/150 11 1
3 104/150 22 0 Very high damage (=13x1.7). Unit not on fire when game restored.
4 96/150 8 7
5 81/150 15 6
6 66/150 15 5
4,5,6 76/150 /9.33 5 (Auto) 9-10 (=5-6x1.7) is near minimum dmg
7 56 10 4
8 48 8 4 What happened here? didn't cycle. MIN dmg (5x1.7).
9 35 13 6
10 25 10 5
11 10 15 6 New shooter takes over
12 2 8 5

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)
:You're right on spot once again ;-) When a unit takes a direct hit from an IN round, it is set on fire (the duration is randomly chosen between 0 and incendiarydamagemodifier/20). Then the "end of turn" routine is called, which inflicts damage *and* decreases by one the number of turns to be on fire (done for all units). Then it sets on fire units standing in blaze. The duration is calculated as for direct hits; if the unit was already on fire, it'll take the maximum value between the new value calculated and the current value affected to the unit on fire. Not sure it is readable but I think you'll sort it out ;-) [[User:Seb76|Seb76]] 10:51, 15 March 2009 (EDT)

== Incendiary in TFTD ==

I read [[Weapons (TFTD)#Phosphor|somewhere]] there are reduced effects underwater (or enhanced effects on land) for TFTD Phosphor rounds. I couldn't find an exact statement of the quantitative difference - does anyone know this? [[User:Spike|Spike]] 14:53, 9 March 2009 (CDT)

:The effects of Incendiary weapons underwater (or Phosphor, as TFTD refers to it) is halved over the UFO equivalent. Incendiary weapons are doubly effective on the surface(Terror Missions) vs underwater, but of the three weapons that can fire Incendiary, two of them(Torpedo Launcher and Hydro-Jet Cannon) can only be reaction fired on land. The Gas Cannon can be fired in eiither location. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:08, 9 March 2009 (CDT)

:: It's clear that the effect underwater is half the effect on land. But does the base level (in USOPaedia / OBDATA) refer to land use or underwater use? [[User:Spike|Spike]] 15:13, 9 March 2009 (CDT)

:As I recall, the base level is on land. The numbers for Phosphor ammo are close to the UFO Incendiary damage numbers, but I know it spreads less underwater. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:15, 9 March 2009 (CDT)

:: Look at the (puny) area effect pattern sizes underwater, that sounds about right. Can anyone confirm this? [[User:Spike|Spike]] 15:40, 9 March 2009 (CDT)

There is actually no difference between the pattern for the Gas Cannon's P rounds underwater as on land. Both have a r=3, d=7 pattern. (CE version at least). Maybe the pattern is smaller the deeper you go? --[[User:Zombie|Zombie]] 16:45, 9 March 2009 (CDT)

<gallery widths="200">
Image:GC-P (underwater).png|Flame pattern from Gas Cannon Phosphorous rounds underwater.
Image:GC-P (on land).png|Flame pattern from Gas Cannon Phosphorous rounds on land.
</gallery>

:OK now I'm really confused then! (I realise I was getting confused with the Dye grenade's small footprint vs Smoke grenades). If the blast pattern is the same size, that implies the weapon power is unchanged. So in what sense is Phosphorus "half as powerful" underwater? Does it burn half as long? Is the impact and fire damage halved? [[User:Spike|Spike]] 16:49, 9 March 2009 (CDT)

I really doubt the damage to units would be affected if the power of the round was modified. The power of the round only determines the size of the pattern produced, not the damage inflicted to units. I'll have to check the burn times and spread rate but my thought is that the two are identical in the version I'm using. Like I said, the pattern may get smaller the deeper you go underwater. The pic above was for a shallow site. It'll take a while for me to find a deeper site to check it out, otherwise some editing of the game files may be necessary to force the scenario.

I just checked the Dye Grenade underwater and on land. Both produce the same r=1, d=3 pattern. So yeah, they are really pitiful when compared to the Smoke Grenade.

Don't really go for the use of "impact" damage with Incendiary/Phosphorous rounds. There is no real impact since the damage range is discontinuous. The unit either catches fire from the splash of fire (in which case it does 5-10 damage points), or the unit doesn't catch fire and the unit remains unharmed. If there were such a thing as impact damage, the range would be continuous like normal weapons, in this theoretical case it would be [0-10] inclusive (ie the set [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. --[[User:Zombie|Zombie]] 17:36, 9 March 2009 (CDT)

Anyway, the half thing came up because AQ was comparing TFTD to UFO, not comparing the effects in TFTD from underwater and on land. However, further comparisons reveal that a hacked HC-I round of 60 produces the same pattern as a GC-P/60 round. Perhaps this whole dilemma can be traced to the Dye Grenade? --[[User:Zombie|Zombie]] 18:28, 9 March 2009 (CDT)

:That's entirely possible the Dye Grenade is the source. However, several of the pages for the TFTD weapons state that Phosphor is far weaker in water, so I didn't check. My mistake. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:35, 9 March 2009 (CDT)

Thanks for the feedback everyone. So this could just be a recycled rumour? I guess the general assumption is that the game engines are identical, so we would want evidence that TFTD is different. Looks like Zombie has proved that the area effect is equal (at least at shallow depths). That leaves only the fire damage or fire duration. Testing that would require repeated observations to check if fire damage is less than 6/hit, less than 6/turn, and burning for no more than 2-3 turns. [[User:Spike|Spike]] 20:14, 9 March 2009 (CDT)

:As with any wiki where contributions can come from anywhere, there are bound to be problems with validity of the statements made. So unless those statements are backed up by real-life test data instead of memory or hearsay, take them with a grain of salt. The other point is to avoid spreading disinformation at all costs (I have been guilty of this as well, but try to at least quantify them). So there you go. I'm still trying to get a deeper underwater mission to check the size of the pattern produced there. Checking the spread of flames or damage inflicted to units shouldn't take too long though. I'll see if I can't get that done tonight yet. --[[User:Zombie|Zombie]] 20:23, 9 March 2009 (CDT)

:Ok, I ran some trials with an unmodified GC-P round on the normal seabed floor against soldiers having 100 health and 0 all-around armor. For the guy standing at GZ, I saw ending health values of 99, 94, 93, 92, 90, and 89 (n=50). So that comes out to 1, 6, 7, 8, 10 and 11 points of damage respectively. I didn't think 11 damage was possible. Here's where things differ though. All the other guys who were clustered around GZ always received only one point of damage, never more, never less. In EU, the guys around GZ took damage equal to the guy at GZ. Odd. So then it occurred to me that perhaps I should check the MCD values of the seabed (TFTD) and the desert (EU) landscapes. Both are basically identical in terms of armor. But the seafloor has a "time to burn" value of 0 while the desert has a value of 1. So maybe our understanding of normal fire isn't totally complete. I'm going to go back to EU and retest the desert landscape with varying MCD burn time flags to see how that affects damage. ;) --[[User:Zombie|Zombie]] 23:00, 9 March 2009 (CDT)

:: The whole Phosphor being half effective under water is related to the burn time and spread, if I remember correctly. The settings in the MCD files may be the culprit. The actual damage dealt or initial spread may not necessarily be affected.

:: Hey, I just had a wacky idea. XComutil. Use its feature where you can set the depth of a mission. Launch a mission on a island terror site map (again, use XComutil's map picker to get to this faster). Lots of grass to burn there. Set fire to it and count how many turns before the fires die out. Redo the test, but this time set the depth to a deeper level. Try the whole process out again.

:: Next repeat this with one of ye-olde seabed maps. They look really weird without the blue palette shift when played on land, what with the landscape being gray.

:: It's possible that the half-effectiveness relates to the fuel that the fire has to burn more than anything else. Further confirmation on how long the flames stick to a target when on land or underwater may be helpful. -[[User:NKF|NKF]] 01:28, 10 March 2009 (CDT)

:I've been burned one too many times using editors or utilities to mess with saved games. Half the time they introduce some unknown "feature" which isn't documented. Thanks, but no thanks. I only test with an unmodified game, except for the changes I make myself to keep control of the situation. Anyway, I tested a patch of fire on the seabed to see how long it remained lit (which has a "time to burn" value of 0). It only stayed lit the current round the shell detonated. After that the fire went out. So this agrees with what is expected. Will continue to work on this as I get time. --[[User:Zombie|Zombie]] 01:51, 10 March 2009 (CDT)

Well, I suppose my recommendation doesn't necessarily need XComutil. It would've certainly made it easier. But yes, it does introduce a few things that work behind the scenes that we might not know too much about. However, if I remember correctly, one of the battlescape savegame files should hold the depth level of the current map you are playing on. All you'll need to do is tweak that to change the depth of the map.

One other thing, the different effect HE has on the same tiles underwater and when on land (ala the Triton) may also be one of the other culprits behind the belief that phosphor is less effective on land. Being able to blow up the Triton on land, but have it appear virtually indestructable when underwater does that. -[[User:NKF|NKF]] 01:59, 10 March 2009 (CDT)

----

re Zombie's underwater tests, there is normally (i.e. on land in EU) a difference between the IC damage on the target of the direct hit, vs lower damage to others in the area of effect (hmm contrary to my IC kill modelling assumptions: uh oh I may've spoken to soon). But only seeing 1 damage on the others in the AoE does seem low. We need to figure out why. Did any of the other targets catch fire? Does that ever happen underwater? Do tiles ever burn past the turn when the IC round is fired? Any of these factors would reduce total fire damage/effectiveness by '''more''' than half. Actually, doesn't it say the 1-12 damage for "in fire" is ''not'' random, but dependent on terrain type? That could be the answer.

The [[Incendiary]] article actually mentions '''4''' modes of fire damage, only 3 of which are quantified:

#"impact",
#"being in fire"
#"being ''on'' fire"

The 4th mode is "damage from burning ''terrain''. Only a tantalising mention is given, no quantitative details. This could be the source of the discrepancy. In fact it might be a component of "being in fire" that's not fully understood. I think Zombie is right to review the assumptions on this one - nice work! [[User:Spike|Spike]] 04:05, 10 March 2009 (CDT)

:As I recall, "damage from burning terrain" is synonymous with "Standing on a tile that's currently on fire." Thus "Being in fire." But that's me and I'm tired this evening, so I could be wrong. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:30, 10 March 2009 (CDT)

I performed my TFTD Phosphorous tests underwater and after the flames died out some of my men did catch fire. So this part seems to jive with that of EU. Tiles do not burn longer than its "time to burn" value in the MCD files. So for instance, in the seabed underwater testing mission, the tiles have a MCD burn value of 0 which corresponds to the results seen (ie fire didn't stick around into the aliens turn or X-COM's next turn either, it only stayed lit the turn it detonated). There really is only 2 "modes" of I/P/fire damage:

<ol><li>The code used for determining if a unit catches fire: 0 damage (if the unit didn't catch and was able to shrug it off) and 5-10 (if the unit catches).</li>
<li>Standing in fire.</li></ol>
At least from the initial tests in TFTD, units outside GZ are just considered to be standing in fire that turn and always take 1pt of damage. Anyway, I don't want to talk myself into a hole without doing more tests. All the following trials I do will be in EU to hopefully curtail any unknowns in TFTD. Once EU's code is figured out then it can be applied and compared to TFTD. --[[User:Zombie|Zombie]] 09:06, 10 March 2009 (CDT)

: If they are "standing in fire", do you think the 1pt damage/turn is based on the fire characteristics tile/terrain type they are standing on? Is it more generally 1-12/turn, dependent on terrain? Also if you get a chance can you test large units and see what kind of effects they take on the GZ+1 squares? If the GZ+1 squares of a large unit are just 'standing in fire' rather than 'catch fire/5-10 impact damage' this will substantially weaken IC vs large units. And I will have shouted too soon! :) [[User:Spike|Spike]] 09:18, 10 March 2009 (CDT)

I did some ad-hoc tests in TFTD. Actually I just ran around firing GC-P and HJ-P rounds everywhere. :) On a typical seabed layout, I found that most things don't burn - the fires don't last into the next turn. The only things I could get to burn were the green moss stuff and and coral skeleton "trees". Even the barrels do not burn. Also, I did not see much sign of terrain damage caused by the fires. But the moss and coral did burn for the normal period, i.e. 1-5 turns.

I also managed to kill an Aquatoid with a single direct hit from a GC-P, in one turn. He died at the end of my turn or the start of his. That seems unlikely. 5-10 from being hit, plus 1-12 for standing in fire, plus maybe another 5-10 from being on fire? It's just about possible I suppose, to max out near 32 damage (if the terrain offers you "12" when it burns). Anyway those are my unsystematic enquiries. I have the 8 save files of various stages of the battle if anyone wants to take a look. It was from a virgin TFTD installation and there was no editing or jiggery pokery.

OK I've uploaded the save files [[Image:TFTD Incendiary Tests 01 Spike.zip]] and taken a look myself with BB's editor. Prior to being hit (Game_4) our Aquatoid was in rude Health, 30/30. Immediately after being hit (Game_2) he was at 19 Health (no Stun damage) and On Fire, as well as Standing in Fire. That implies 11 Damage from the "impact effect" which is not supposed to happen. As noted, at the end of the same turn or beginning of his next turn, he dies. He looks to be standing on a standard seabed square, just sand, the kind of thing that does not burn. He is next to some of the brown cushion-like coral, but I don't think that burns, at least not over multiple turns. In fact in the same turn he is hit, at the end, you can see him dead (Game_3). Since there was only one alien, he died in the same turn. OK that's slightly confusing, maybe someone can double check the turn numbers in the save files (don't know where they are).

[[User:Spike|Spike]] 13:29, 10 March 2009 (CDT)

Doh. I is a idiot. The Aquatoid was killed by the incendiary fire bug - I fired extra IN rounds at terrain objects after he was on fire. Which explains why he is already dead by the end of my turn. [[User:Spike|Spike]] 15:08, 10 March 2009 (CDT)

:Yeah, you gotta watch that. Well, anyhow, I edited the desert landscape in Enemy Unknown to have the same MCD "time to burn" value of 0 as the seafloor in TFTD. From the limited tests, the results look the same as in TFTD. (Fire burns out after the initial turn it detonated, units around GZ taking 1 unit of damage while the guy at GZ got more). So that means I can focus my efforts on EU with little worry because there will be no issues. I'm going use BB's logger and AHK to automate the data gathering aspect to save me a bunch of time. I'll probably need the full requisite 2000 reloads though, as the guy at GZ is not the same as the 24 soldiers around him. Wish me luck. :) --[[User:Zombie|Zombie]] 15:54, 10 March 2009 (CDT)

Good luck! I just read the MCD article, and it mentions 2 fire-related byte fields in MCD - "likelihood of catching fire" as well as "time to burn". Is the last field variable or fixed? Could the first field determine the damage/turn to units when it's on fire? Also with a possible 4 terrain items that could all be burning, is the maximum damage higher than 12? [[User:Spike|Spike]] 16:10, 10 March 2009 (CDT)

:Offset 45 is the flammability rating of the tile. This most likely controls whether an adjacent fire will spread to the tile in question. (For instance, if a fire is burning and the next tile over is a tree or something, it'll probably spread there fast because of the combustibles present). The other byte is offset 57 which is the one we are after. Don't know about the 4 types of things which can exist on a tile at once. I think the most I have ever seen is 2 (usually ground and a wall). Wouldn't hurt to edit a tile to include all 4, but that's an entirely different test to do. It'll have to wait until we get a better understanding of basic fire. ;) --[[User:Zombie|Zombie]] 19:38, 10 March 2009 (CDT)

::Here's a question. On Large units, if only one segment of the Large unit is on fire, will the fire spreading code allow the other three segments to catch on fire? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:13, 10 March 2009 (CDT)

:I highly doubt it. Unit fires are completely different creatures from terrain fires. Needs testing though. --[[User:Zombie|Zombie]] 20:55, 10 March 2009 (CDT)

::Yes it would have to be a very special case, since afaik fires do not spread from regular units on fire to adjacent terrain or to other adjacent regular units. Though it would make more sense than any of those things. [[User:Spike|Spike]] 21:03, 10 March 2009 (CDT)

== Incendiary Bug ==

(Also known as the [[Known_Bugs#Funky_Fire|Funky Fire/Smoke bug]].) I made some suggestion about why this bug happens, and how the code could be patched to fix it: [[User talk:Seb76#Incendiary Bug]]. [[User:Spike|Spike]] 07:13, 12 March 2009 (CDT) Here is the general discussion of the bug:

With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

I also suspect that other "end of turn" processing happens with every IN round fired. I am pretty sure "fire spreading" checks occur, as I have seen fire spread when using perfectly accurate shots. Either "fire spreading" happens, or there is a random element in incendiary area of effect, that is definite. I want to repeat these tests to see if "catch on fire" effects also happen for those who are standing in fire when an IN round is fired. [[User:Spike|Spike]] 08:59, 31 March 2009 (EDT)

== Mwahaha ==

Was exploiting the Elevator Shield trick on an Alien Base Assault, and I had the forethought to pack lots and lots of Incendiaries. My sick sick mind found it amusing to set all those aliens on fire and watch them roast stupidly and helplessly. (Jasonred)

= Fire Damage =
(moved from talk:UFOextender)

Not sure if the bug is already posted. And Not sure if I should post the bug here or in [[Talk:Incendiary]]. Problem is if you use extender to fix funky fire bug. Incendiary no long does any damage at all. Units only take the small amount of damage after ending turn because they're on fire. Using 1.28.3 extender

To test this. I stripped a soldier of armour. And pounded four incendiary rockets into the soldier in the same turn. No damage. And then next turn, his health drops a little because he's standing in fire. This may not be a problem for most players. But it is still a major bug. I understand the funky fire problem is already difficult to fix, and I say thanks to all who will try to help solve this bug. [[User:Hellblade|Hellblade]] 14:44, 28 September 2012 (EDT)

: That's not a bug, that's the fix. Incendiary damage is only applied at the end of the turn. Think about it... does fire kill faster than a bullet? Faster than a grenade? Can you kill someone with fire faster than they can get a shot off back at you? No, to all these things. To compensate for fixing the bug, fire damage is doubled compared to the previous end-of-turn fire damage (that always existed). It is no longer applied per shot or per impact. All you get "per impact" is another chance to set the target unit itself on fire. Incendiary is a weak attack. It has the benefit of a wide area effect, no HE block, and ignores armour. There are situations when IN is the only effective weapon XCOM possesses. But, like everything, it has strengths and weaknesses. [[User:Spike|Spike]] 15:51, 28 September 2012 (EDT)

:: I see your point but let me elaborate. Heat, not fire, do kill as fast as bullets. The original game mechanics separated heat from fire just as in real life. It intended to have the big heat blast damage first and then the small fire damage per turn.
:: Take the most extreme case, napalm or volcanic lava, you get fully cooked in less than a second - just by heat alone, and you may/may not catch fire later on. And heat blasts travel as fast as bullets, in some cases as fast as light. I believe the game has different Incendiary damage values to do different damage according to how strong the heat is, not the fire afterwards. The damage by fire later on makes sense because natural burning fires aren't that hot comparatively.
:: I understand the difficulty in trying to fix this. But before this fix you could kill a reaper by a few AC-I shots (which is their weakness) and now you can empty the two clips at it and it'll never die. [[User:Hellblade|Hellblade]] 03:11, 4 October 2012 (EDT)

== Advantages/Disadvantages of using Incendiary for nighttime light ==

It seems for most folks that electro-flares are the go-to for night lighting and incendiary rounds are a distant afterthought.
With that in mind I propose this list of pros/cons to using incendiary at least as a major complement to flares.

Cons:
#Low damage, and for each soldier with incendiary rounds loaded they can't attack with more effective weaponry unless
##they unload and reload
##they carry another gun or use 'nades/stun rod
#Not re-usable, will always be depleting stock

Pros:
#Not dependent on throwing limitations of range and arc/trajectory
#Very efficient in terms of light-output per weight, storage space, and time units
#Can set area on fire to illuminate where the enemy is initially, then as the fire burns out you may move into the cover of the smoke it generates
#Does at least some damage to enemies - very unlikely to kill them, but softens them up so future attacks more likely to neutralize
#Area denial - fill a small building or enemy craft and watch them flee out into your reaction fire, or at least out where you can get them, they don't get the drop on you
#At least in OpenXCom the enemies on fire should provide lighting, helping to spot them at a distance
#Fire is less vulnerable to being destroyed by nearby explosions, unlike those wimpy flares. And even if it is snuffed, it isn't something you were counting on re-using
#Reaper vulnerability
#Zombies not re-spawning to 'lids when KO'd by fire splash
#You can dedicate a few number of soldiers to throwing fire around while the rest keep their hands and TU's free to attack
#Soldiers that go berserk/get MC'd can't hurt armored soldiers w IC fire

Now it seems to me that the first Con is major and obvious, but the many Pros are overlooked. Also that big Con could be greatly mitigated by cannon wielders w incendiary carrying a decent secondary weapon: thinking plasma rifle or pistol, laser pistol

any I'm missing? what about putting this on the main page?

Talk:Incendiary

2021-07-08T16:49:00Z

Mugwump: /* Advantages/Disadvantages of using Incendiary for nighttime light */

== General Comments ==

For now, we'll just say the smoke + incendiary stun effects only work on X-Com owned units until some tests can be run to confirm this. It's unusual that only X-Com units are affected, but the game has been known to surprise you even after you think you've worked something out.

- [[User:NKF|NKF]]

----

Given how aliens love to hang around in a smoke-filled crashed UFO, IC rounds would be insanely powerful if they did actually work against aliens in smoke. I'm glad they don't ''seem to'', as I'd be very tempted to cheat with it. They do work against aliens standing in fire, though, which is still quite cheaty...--[[User:Ethereal Cereal|Ethereal Cereal]] 21:35, 5 May 2006 (PDT)

:I do consider the "standing on fire + new IC explosions = damage" a cheat. So I just don't abuse it. I only use IC rounds to illuminate or to finish off hiding aliens. It can also work as a "pass-through-and-die" tactic, the same way Proximity Nades work, although fire damage is pretty sad xD. --[[User:Nekrocow|Nekrocow]] 00:36, 24 June 2012 (EDT)

:: I use it a lot in TFTD to clear out those island bunkers and the upper storage levels of the large train station. Either the aliens roast alive, or they come out. Otherwise yes, it's no doubt a cheat. Well, more a bug exploited as a cheat. -[[User:NKF|NKF]] 02:09, 24 June 2012 (EDT)

-----

I just edited the Incendiary page a bunch, because Brunpal's [[Talk:Experience]] questions about Incendiary sparked my interest... I never did test IN vs. experience. It's a very good question ''if'' it turns out to cause Firing experience. But while reviewing this page, I had a number of questions, for anyone interested. Also, I only tried to clarify things, and don't know Incendiary well, so fix anything you know I got wrong:
#Did I get it right re: the set [ 0, 5, 6, 7, 8, 9, 10 ] for chance of initially catching fire? I over-wrote "linear" because it seemed odd when XCOM usually goes, e.g., 0-10. (Who tested this? - A little help here please. Just making sure.)
#Why flame a zombie unless it's near death (and how can you know if it is)? It's been a long time since I used fire - if you don't have flying armor, why mess around with a zombie by burning it, why not Heavy Plasma it.
#Any research/data on tile flammability versus duration of burning is appreciated. Probably it should go on the [[Terrain]] page byte, but be clearly referenced here. It's just a curiousity, but an interesting one.
#The last line of the page says ''"The damage values listed in the UFOpaedia do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames."'' Does anyone know IN strength vs radius, then? Should be easy to test and post.
#NKF, Zombie, or anyone else... would you mind seeing if Incendiary causes the Experience counter to increase? Brunpal is right that it's important to [[Experience]]... I found [[Small_Launcher#Experience|Stun Bombs]] to count for experience across their whole range, even if no stun damage occurred... if you have 11+ Mutons in a firing squad situation, passing around an [[Auto-Cannon]] with Incendiary may be better than standard pistols, depending on the range of the blast. I could test it, but it's been a long time since I've delved into the files; maybe one of you have them more close to hand. [[User:MikeTheRed|MikeTheRed]]
-----
:Offhand, the only way I could think of to check the remaining HP on a Zombie would be by using a [[Mind Probe]]. Given the relative uselessness of a Mind Probe after Psionics are developed, as well as the time needed to use the Probe once, this seems a rather impractical course of action, unless your Rear Commander has nothing better to do. I agree, Heavy Plasma on Auto is better. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 1 August 2008 (PDT)
-----
#Yeah, the set is correct. When a unit is shot with an incendiary round, the game does a calculation to determine if the unit catches fire. If it doesn't catch fire, the unit takes no damage (the 0 in the set). If the unit does catch fire, it will take between 5-10 damage points. Stupid discontinuous range, but that's what happens. As you may guess, I did the Incendiary trials over at the StrategyCore forums in the Damage Modifier topic - see [http://www.strategycore.co.uk/forums/index.php?s=&showtopic=746&view=findpost&p=39672 this] post for the particulars.
#Why flame a Zombie? Simple. A Zombie which is killed by an Incendiary round doesn't turn into a Chryssalid. Zombies are easily outrun, so you can just keep picking at them from a short distance with Auto-Cannon Incendiary rounds and then running away. Fairly effective, even when your troops do not yet have armor to protect them. And when you do not have the luxury of the Heavy Plasma early in the game, Incendiary is a good way to avoid an overabundance of Chryssalids who are not so easy to kill. As for checking the Zombie's stats, you can only rely on the Mind Probe or Psi. Neither are available early either (the Mind Probe is usually low on the research tree for most people even though you can collect enough, and Psi is difficult to use as a soldier needs to be quite proficient to use MC.
#I have been meaning to do some tests in flammability vs terrain but only recently started fooling with MCD values. It'll be next on my list.
#Here, I uploaded a very recent spreadsheet containing both I and Smoke when damage values are hacked. See [[Media:Incendiary_and_Smoke_Patterns.zip | this file]] which contains both.
#I think I fooled around with Incendiary recently in conjunction with promotions. Soldiers who shot aliens with "I" didn't get promoted. Logically, that would mean the experience counter didn't increment. UNITREF.DAT would need to be checked to verify though. Addendum: indeed, as BB mentioned in the experience page (and a quick glance at the UNITREF.DAT experience counters by myself to triple-check my aging brain), Incendiary rounds do not increase any of the experience counters.

Hope this clears up some of the issues/concerns here. --[[User:Zombie|Zombie]] 21:16, 1 August 2008 (PDT)
----
<i>"The damage values listed in the [[UFOpaedia]] do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames. Fire is unlike other damage; it works at initial blast and then over time, as described above."</i> and
<i>"Initial "impact" damage from incendiary ammunition is either for no points (unit does not catch fire), or between 5-10 points (unit catches fire)."</i>

This should be stressed on ALL the various relevant pages. It's important. 6.4 dmg vs 90 dmg is a significant difference!--[[User:Brunpal|Brunpal]] 09:31, 2 August 2008 (PDT)
----
It looks like Incendiary is gaining some clarity (at least for me), thanks for starting it Brunpal...
*The "6.4" was only for the initial IN round impact (set [ 0, 5-10 ]); it can then burn for 4 more rounds (set [5-10]). Perhaps a short way to state this complicated damage type is "Minimum 0 (unit does not catch on fire) ''OR'' unit catches on fire 1-5 turns, 5-10 damage/turn, 5-50 damage in total (average 21.5)". Does that look right, Zombie? I'm not sure where you got 90 from Brunpal...
:90 is the listed damage from an IN rocket.--[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)
*However, the numbers I just stated do not count possible additional damage from nearby terrain being on fire (as opposed to yourself). Maybe those should be included somehow. (And clearly, fire is much more dangerous outdoors than inside UFOs, where terrain does not burn.) But since terrain fire can last a variable number of turns, I guess you can't have a maximum damage. Average terrain damage from fire would be 6.5/terrain (1-12), but also, it can keep the unit itself burning more than 5 turns... hard to model.
*Good point about flaming zombies, Zombie. I guess you ought to know, eh? :)
*The spreadsheet looks great. Perhaps one of us can pull out the area patterns for non-hacked IN weapons and put them on the relevant pages. When it's done, the spreadsheet itself would be an asset to Incendiary (or maybe [[Damage]], if it's listing all types of damage). As has been stated, it's the size (area) of the blast that actually directly relates to incendiary weapon "strength"... the diameters you found are probably what should be in parentheses next to weapon strength, although damage can appear as well.
*Ok, no experience from Incendiary blasts. It might've been real interesting if there were, but it didn't occur to me to test. (Or maybe I tested it briefly so long ago that I forgot.) I would've guessed that they did, because the stun bomb and explosives do. Oh well.
*P.S. Brunpal, we may not have touched pages in a year, but most/all of us have "Watch this page" turned on, so we get immediate notification of any pages we've edited or Watched. :)
-[[User:MikeTheRed|MikeTheRed]] 09:17, 5 August 2008 (PDT)
----
*Sounds correct MTR. I think Brunpal was just comparing the "damage" (actually strength) of the Incendiary Rocket (90) to the average damage due to the "impact" of the blast (6.4).
*Well, it isn't ''nearby'' terrain on fire which you have to worry about, it's the tile directly underneath a units feet which causes the most concern. If that tile is on fire and the unit doesn't move, it will take 1-12 damage points. While true that terrain on fire can last a variable number of turns, there is a definite upper-limit to how much damage a unit can possibly take. Fires don't last forever, and the combustibles eventually are consumed leaving either scorched earth or a damaged tile. Those damaged/destroyed tiles usually cannot be started on fire again by the spread of flames. They can only be set ablaze with incendiary ammo, and even then for only 1-3 turns (normal for dead tiles). So it's certainly possible to find a max damage. And for the most part, the things that burn the longest are usually objects, not tiles. And most objects you can't stand on anyway. But I totally agree that it's hard to model how fire functions due to the two forces at work: "impact" damage and damage due to standing in fire.

P.S. Some of us are actually around here and don't need to be coaxed back into existence by an email when a watched page is changed either. Just because it's quiet, it doesn't mean nobody's home. :) --[[User:Zombie|Zombie]] 20:34, 5 August 2008 (PDT)
----
While understanding the whole formula for fire and fire damage happens is useful, it was not thinking to go that broad. I was just interested in what occurs from the moment a solider takes his shot, to the time that solider gets his TU back. ie damage from incendiary rounds vs fire damage. --[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)

----
It looks to me that, unlike all other forms of damage, Fire damage ignores armor, goes right past it. If so, this should be made explicit on the main page? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 05:55, 30 May 2021 (UTC)
:Fire damage doesn't ignore armor - power suits for instance can't be damaged by fire, except if the unit is already injured. Read carefully the Damage section - there's a lot of nuances about how fire works. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 03:03, 1 June 2021 (UTC)
:: What I meant is ignore armor ratings for damage calculation. While accounting for the resistances listed on the Damage Modification page, doesn't incendiary act as if front, side, back and under armor are 0 for calculation? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:21, 1 June 2021 (UTC)

== Incendiary vs Large Units ==

We're discussing this in [[Talk:Sectopod#Incendiary vs Sectopod]], and a question came up. When an IN round impacts one segment of a large unit, presumably that segment gets the "Incendiary impact" function, i.e. 6/7 chance of catching on fire for 5-10 damage plus 1-5 turns of being on fire. Does the same "impact" function also apply to the 3 adjacent squares (6/7 chance), or is it just the "standing in fire" chance? If you had multiple regular-sized units standing in the area of effect of an IN round, they would each get "impact" effects (right?). So it ''seems'' logical that all 4 segments of a large unit, inside the area of effect, are also exposed to "impact" effects. But I wanted to check. [[User:Spike|Spike]] 06:34, 9 March 2009 (CDT)

Oh boy! Calculating this not only depends on a lot of unknown assumptions, but is fiendishly complicated - especially if you factor in the "funky fire" bug. And contrary to my noblest efforts, it's impossible to use IN weapons without inadvertently exploiting this bug. Even if you only fire IN at a single target until it's dead, once the target is "standing in fire" you effectively just can't miss.

Anyway back to the Large Targets specifically. The key assumption above is whether all regular-sized units in the area of effect of an IN burst are affected with "impact effects" - 5-10 dmg & 6/7 chance to catch fire. If they are, it's reasonable to assume the same thing happens to the 3 other segments of a Large Unit. However I suspect this is not the case, and strictly speaking "impact" effects should only occur at the single, impact square of an IN round. Testing needed!

More likely, the GZ+1 squares, whether occupied by small or large units, are only subjected to the "standing in fire" effects: 1/3 'catch fire' probability, and 1-12 terrain-based damage. And these effects are applied once per turn, not once per hit.

However, all of this is turned on its head by the 'funky fire' bug. After the first round hits, all units (and all Large Unit segments?) are "standing in fire". (Though maybe these fire damage routines run only for the "control" segment of the Large Unit? Possible, but unlikely.) Since they are standing in fire, the funky fire bug applies and all units/segments are hiit with "impact" effects.

So assuming a Large Unit is ''already'' standing in fire (e.g. from a previous IN hit or near miss), damage per IN round fired is 6.4 x 4
= 25.6 average, 10x4= 40 max. Subject to resistance/vulnerability modifiers, but ignoring armour level. In addition as multiple IN rounds are fired, the chance of all segments catching fire quickly approaches certainty. This not only means the Large Unit will sustain further damage at the end of the turn, it makes it impossible to escape the 'funky fire' trap by moving out of burning squares.

(Any testing needs to be very careful and probably only fire a single IN round per game, otherwise 'funky fire' will skew the results.)

So, in conclusion, the TU/kill factors I put up on the Talk pages for the Large Units ([[Talk:Reaper]], [[Talk:Cyberdisc]],[[Talk:Sectopod]]) should pretty much reflect the 'funky fire' reality after the first round connects, apart from the fact that you actually can't miss. The very first IN round to be fired would have the same effect (for immediate damage) on a Large Target as on a small one. But I really don't want to update the numbers to reflect this fact, it's just too awful. For AC-IN, the firepower factors will be about 6 times better than stated. Maybe I'll just remove them. :(

[[User:Spike|Spike]] 15:51, 10 March 2009 (CDT)

=== Simple Tests ===

I did a small number of tests and found some interesting results. In 5/5 tests, all 4 squares of the target (Reaper) were on fire the following round. (It's hard to tell if they are on fire the same round, as you need to extinguish the fire with smoke to see). Perhaps this makes sense, as it's a UNITREF attribute and so applies to the whole unit, not its 4 component squares?

Looking at the damage, it looks like "impact" and "on fire" damage applies to all 4 squares, i.e. x4 normal. Damage clusters tightly around 16-18 per hit which is roughly the expected value, maybe a bit lower (at x4). And since we '''are''' on fire, should expect an average of 7.5 ({5..10}/6) rather than 6.4 ({0,5..10}/7? Maybe something else is going on here, as these numbers seem a little low - 6.4 x 4 = 25.6 per hit or 7.5 x 4 = 30.0 per "on fire" hit might be expected on a Large Unit.

:Drat. I didn't factor in the Reaper's 170% Susceptibility to Incendiary. So the actual damage levels are more like 10 per hit. Maybe there is no multiplier for the 4 squares? Hard to figure out what's going on here. In tests on hacked humans, armour level is not a factor vs Incendiary damage, otherwise I'd suspect the under-armour or something. 2.5 avg damage per segment seems too low. 10 average damage per alien seems too high - that should be the max, not the average. Is some mechanic pushing the average up to the max? I don't have a clue right now. [[User:Spike|Spike]] 06:53, 11 March 2009 (CDT)

The damage seems to be regardless of "funky fire" effect. A round fired at a target that is not burning / in fire seems to do about the same damage, per hit, as one that is in fire / on fire and so subject to the funky fire bug. So the only 'bad' effect of the bug is that you never miss, and you hit everything that is in fire / on fire. Not quite so bad, and it allows you to play honest by only ever firing at one target, not hitting any other targets by accident (!), and firing from point blank range so it doesn't matter that you never miss.

Burn Time was as high as 7 when multiple IC rounds were fired (on auto). Higher than we thought possible (1-5 range expected). However it sometimes goes DOWN after additional hits. Possibly the value is re-randomised with every new IC impact, but hits are cumulative while firing auto bursts?

Here's the raw test data:

Test 1.
-
2 DH on Reaper, mix of auto and snap, some other IC impacts on others
Burn Time=7 - exceeds known limit of 5
All 4 sq on fire next turn
Is 'on fire' global? It's in Unitref, so maybe
-
Test 2.
-
1 DH on Reaper, only IC shot fired in game.
In firing turn, taken 132/148 = 16 damage. Burn time=3
Start of T+1, taken 122/148 10 more damage, Burn time=2
T+1 Reaper shows all 4 squares burning
-
Test 3.
-
Revisit #2 firing turn... fire another round (this will use funky fire)
So 2nd IC hit, 2nd rd fired, same target.
Health now 114/148, further 18 damage
But Burn time has dropped to 2! Must re-randomise on each hit??
Maybe only accumulates during auto burst?
-
Test 4.
-
Let's try lots of hits. Hack up accuracy to 255
OK 3 out of 3 hits on Auto
T+0 Health=98/148=50 damage (17 avg) Burn=6
T+1 Health=81 (17 more dmg) Burn=5 All 4 squares on fire.
-
Test 5.
-
Revisit #4 and push to 6/6 hits
T+0 Health=41/148=107 (18 avg) damage Burn=7
T+1 Health=21 (20 more dmg) Burn=6 All 4 squares on fire.
-
Methodology (Apart from Test 1) = only ever 1 (same) target in any IC AoE; no misses
(To try to minimise the impact of 'funky fire' effects - but can't eliminate)

[[User:Spike|Spike]] 23:27, 10 March 2009 (CDT)

I re-ran the same simple tests against a regular-sized (Floater) target instead. The results agreed much better with the 'standard model' of [[Incendiary]] effects. All results were within the permitted ranges in the 'standard model', though some values were unexpectedly. I think some variables to look for in Incendiary mechanics are:

* Large Unit vs regular unit behaviour looks to be different
* Auto burst vs single explosion looks to be different (maybe just due to funky fire bug, maybe not)
* Tile MCD "time to burn" value seems to affect one or more of the other calculations / probabilities
* Burn Time on the unit can go up as well as down. New hits seem to re-randomise the value.
* End of turn processing does not always reduce unit Burn Time by 1. Can a terrain fire add to unit Burn Time?

[[User:Spike|Spike]] 21:25, 11 March 2009 (CDT)

:I doubt a terrain fire adds to the time a unit is on fire. Actually, I'm quite positive on this since my tests from a while back were quite thorough. The counter can only tick down to 0, and when it does a terrain fire will have a chance of "reigniting" the soldier again.

:Anyway, I had to start from scratch again on testing due to a few issues with my test scenario. I totally forgot that the first soldier on the unit roster is a bad choice for a "designated hitter" since he can never be automatically selected on a reload. Soldiers lower on the order are much better choices. So I got the shooting automated, but each reload was taking too much time since I had to reselect the shooter, select the shot, move the view down a level, shoot the target and abort. Having the soldier already selected cuts out 2 actions in the list allowing the script to run more efficiently. I'm going to try to get everything properly setup tonight, then start testing tomorrow morning. With a little luck and about 2 hours of babysitting the script to make sure it doesn't quit, I should have some prelims. --[[User:Zombie|Zombie]] 21:55, 11 March 2009 (CDT)

----
Looking forward to seeing that data! I did some more testing just for the special case of Large Units, about 40 tests. My tentative conclusions:

# Damage range per 'impact' hit is the same as regular units, around 5-10 x Vulnerability (maybe + MCD Burn time?)
# Large units go on fire about 1/7 of the time when receiving a direct hit - as expected
# Either all 4 segments go on fire, or no segments go on fire - no 'part segments on fire'
# Unit burn times are not correlated with unit damage received
# Auto fire has the same average damage level per hit as snap fire
# Unit Burn Time can exceed 5, both on Snap and Auto. Highs of 6 (Snap) and 7 (Auto) were seen. Maybe 1-5 + MCD Tile Burn Time?

All my tests were done on the grid-lined pavement tiles from urban terror missions, which have an MCD default burn value of 2. For some of the "setting the large unit on fire" tests, I had the target floating in mid air, because air does not burn even during the turn that the IN round explodes - it makes it easier to see the unit burning.

From Bomb Bloke's editor notes, the 4 potential MCD tiles in a map location are: a North Wall, a West Wall, a Ground tile, an Object tile. All 4 of these MCD tiles might have a burn time value. But Ground and Object are the most likely to be relevant.

[[User:Spike|Spike]] 21:58, 12 March 2009 (CDT)

:Ok, I got the script running and optimized it a bit to cut down some wait cycles. Right now it's cranking out approximately 400 trials per hour which is about as fast as I can make it go without removing some desktop icons (all the icons have to refresh at the end of each logging cycle which takes a little time). Anyhow, just for giggles I stopped it after 400 trials to get some prelims.

:<table {{StdCenterTable}} class="sortable">
:<tr {{StdDescTable_Heading}}><th align="left" width="90">Damage</th><th width="90">Count</th><th width="90">Pct%</th></tr>
:<tr><th align="left">1</th><td>68</td><td>17.0%</td></tr>
:<tr><th align="left">6</th><td>58</td><td>14.5%</td></tr>
:<tr><th align="left">7</th><td>45</td><td>11.3%</td></tr>
:<tr><th align="left">8</th><td>63</td><td>15.8%</td></tr>
:<tr><th align="left">9</th><td>55</td><td>13.8%</td></tr>
:<tr><th align="left">10</th><td>64</td><td>16.0%</td></tr>
:<tr><th align="left">11</th><td>47</td><td>11.8</td></tr>
:</table>
:If you average the percent columns, it comes to 14.28571429% while the expected is 1/7 or 14.285714285714285714285714285714 which is a difference of 4E-09. This means 400 reloads is plenty enough values for this application. Great news! Well, as you can see, instead of the set [0, 5, 6, 7, 8, 9, 10] for MCD of 1, this scenario where the MCD was 0 is shifted up by one [1, 6, 7, 8, 9, 10, 11]. Interesting.

:Tomorrow I'll rerun the MCD 1 scenario again to verify the values and damage set. Then it's on to the MCD of 2. --[[User:Zombie|Zombie]] 01:50, 13 March 2009 (CDT)

:: Extremely interesting! By the way, it was probably a late night but - the average any 7 numbers that (must) add up to 100% is always going to be 1/7th of 100%, so that result doesn't really demonstrate any confidence in the data. It would be the same with one result, or with a trillion results. The 4E-09 discrepancy is just the precision error in your calculator/spreadsheet's calculation of the percentages and the average of the percentages. You've got some considerable variation from 1/7th on the individual numbers, I'm not sure if that's just to be expected with only 400 trials. But for example "0" and "10" are both a bit high so it ''might'' be non-linear (probably not). Anyway we'll see when all your results are in! (To measure the degree of variation from the expected result, what you want is a chi-squared test or something - and I don't know what I'm talking about there so I'll shut up!)

:: I'm checking Bomb Bloke's MCD database, and there are some tiles in there (U_BASE 22-25) with MCD burn value of 30 - I might play with those and see if anything dramatic happens. Oh except looks like they can't be set on fire (255 flammability). There are others that are quite high (8-), and still flammable. Or I could hack an MCD file (scary). Maybe I'll just wait for your results Zombie! [[User:Spike|Spike]] 05:49, 13 March 2009 (CDT)

= Incendiary Research =

== Large Units On Fire ==

Here's another interesting test for setting Large Units on fire. Set AC-I power down from 42 to 1.
At this IC power, there is no area effect. You can't even start a fire on one tile.
All you can do is set units on fire with a direct hit. This means there is no way the other 3 squares of the
Large Unit are in the IC area of effect.

Result: Whether you hit a one square regular unit or a 4-square large unit, if it goes on fire, '''all''' squares of the unit still go on fire. Along with the fact that the inflicted IN damage level vs Large Units is basically normal (see above), this tends to confirm that being on fire is a "unitref" property and, unlike HE and Stun Bombs, is not applied (multiplied) vs the number of squares the unit occupies. (In fact it would be good to check that HE is actually applied separately to each square, with different HE strength, potentially different armour facing, etc. Maybe the engine just simplifies things and multiplies damage by 4?)

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)

== Unit Burn Time ==

Unit Burn Time seems to be considerably '''cyclic''' rather than random. Very often, it just steps down by one from the previous value. I suspect this is because the "impact" routine calls the "end of turn" incendiary/smoke routine (see [[User talk:Seb76#Incendiary Bug]]). Sometimes it does not happen, maybe because some other factor has caused the Burn Time to increase.

Here's some data. This was done against a Reaper with AC-I power set to 1 (and 10% TU Snap fire cost). But I've seen similar results with standard AC-I.

Hit H/H Dmg/Avg Burn Time
1 137/150 13 2
2 126/150 11 1
3 104/150 22 0 Very high damage (=13x1.7). Unit not on fire when game restored.
4 96/150 8 7
5 81/150 15 6
6 66/150 15 5
4,5,6 76/150 /9.33 5 (Auto) 9-10 (=5-6x1.7) is near minimum dmg
7 56 10 4
8 48 8 4 What happened here? didn't cycle. MIN dmg (5x1.7).
9 35 13 6
10 25 10 5
11 10 15 6 New shooter takes over
12 2 8 5

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)
:You're right on spot once again ;-) When a unit takes a direct hit from an IN round, it is set on fire (the duration is randomly chosen between 0 and incendiarydamagemodifier/20). Then the "end of turn" routine is called, which inflicts damage *and* decreases by one the number of turns to be on fire (done for all units). Then it sets on fire units standing in blaze. The duration is calculated as for direct hits; if the unit was already on fire, it'll take the maximum value between the new value calculated and the current value affected to the unit on fire. Not sure it is readable but I think you'll sort it out ;-) [[User:Seb76|Seb76]] 10:51, 15 March 2009 (EDT)

== Incendiary in TFTD ==

I read [[Weapons (TFTD)#Phosphor|somewhere]] there are reduced effects underwater (or enhanced effects on land) for TFTD Phosphor rounds. I couldn't find an exact statement of the quantitative difference - does anyone know this? [[User:Spike|Spike]] 14:53, 9 March 2009 (CDT)

:The effects of Incendiary weapons underwater (or Phosphor, as TFTD refers to it) is halved over the UFO equivalent. Incendiary weapons are doubly effective on the surface(Terror Missions) vs underwater, but of the three weapons that can fire Incendiary, two of them(Torpedo Launcher and Hydro-Jet Cannon) can only be reaction fired on land. The Gas Cannon can be fired in eiither location. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:08, 9 March 2009 (CDT)

:: It's clear that the effect underwater is half the effect on land. But does the base level (in USOPaedia / OBDATA) refer to land use or underwater use? [[User:Spike|Spike]] 15:13, 9 March 2009 (CDT)

:As I recall, the base level is on land. The numbers for Phosphor ammo are close to the UFO Incendiary damage numbers, but I know it spreads less underwater. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:15, 9 March 2009 (CDT)

:: Look at the (puny) area effect pattern sizes underwater, that sounds about right. Can anyone confirm this? [[User:Spike|Spike]] 15:40, 9 March 2009 (CDT)

There is actually no difference between the pattern for the Gas Cannon's P rounds underwater as on land. Both have a r=3, d=7 pattern. (CE version at least). Maybe the pattern is smaller the deeper you go? --[[User:Zombie|Zombie]] 16:45, 9 March 2009 (CDT)

<gallery widths="200">
Image:GC-P (underwater).png|Flame pattern from Gas Cannon Phosphorous rounds underwater.
Image:GC-P (on land).png|Flame pattern from Gas Cannon Phosphorous rounds on land.
</gallery>

:OK now I'm really confused then! (I realise I was getting confused with the Dye grenade's small footprint vs Smoke grenades). If the blast pattern is the same size, that implies the weapon power is unchanged. So in what sense is Phosphorus "half as powerful" underwater? Does it burn half as long? Is the impact and fire damage halved? [[User:Spike|Spike]] 16:49, 9 March 2009 (CDT)

I really doubt the damage to units would be affected if the power of the round was modified. The power of the round only determines the size of the pattern produced, not the damage inflicted to units. I'll have to check the burn times and spread rate but my thought is that the two are identical in the version I'm using. Like I said, the pattern may get smaller the deeper you go underwater. The pic above was for a shallow site. It'll take a while for me to find a deeper site to check it out, otherwise some editing of the game files may be necessary to force the scenario.

I just checked the Dye Grenade underwater and on land. Both produce the same r=1, d=3 pattern. So yeah, they are really pitiful when compared to the Smoke Grenade.

Don't really go for the use of "impact" damage with Incendiary/Phosphorous rounds. There is no real impact since the damage range is discontinuous. The unit either catches fire from the splash of fire (in which case it does 5-10 damage points), or the unit doesn't catch fire and the unit remains unharmed. If there were such a thing as impact damage, the range would be continuous like normal weapons, in this theoretical case it would be [0-10] inclusive (ie the set [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. --[[User:Zombie|Zombie]] 17:36, 9 March 2009 (CDT)

Anyway, the half thing came up because AQ was comparing TFTD to UFO, not comparing the effects in TFTD from underwater and on land. However, further comparisons reveal that a hacked HC-I round of 60 produces the same pattern as a GC-P/60 round. Perhaps this whole dilemma can be traced to the Dye Grenade? --[[User:Zombie|Zombie]] 18:28, 9 March 2009 (CDT)

:That's entirely possible the Dye Grenade is the source. However, several of the pages for the TFTD weapons state that Phosphor is far weaker in water, so I didn't check. My mistake. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:35, 9 March 2009 (CDT)

Thanks for the feedback everyone. So this could just be a recycled rumour? I guess the general assumption is that the game engines are identical, so we would want evidence that TFTD is different. Looks like Zombie has proved that the area effect is equal (at least at shallow depths). That leaves only the fire damage or fire duration. Testing that would require repeated observations to check if fire damage is less than 6/hit, less than 6/turn, and burning for no more than 2-3 turns. [[User:Spike|Spike]] 20:14, 9 March 2009 (CDT)

:As with any wiki where contributions can come from anywhere, there are bound to be problems with validity of the statements made. So unless those statements are backed up by real-life test data instead of memory or hearsay, take them with a grain of salt. The other point is to avoid spreading disinformation at all costs (I have been guilty of this as well, but try to at least quantify them). So there you go. I'm still trying to get a deeper underwater mission to check the size of the pattern produced there. Checking the spread of flames or damage inflicted to units shouldn't take too long though. I'll see if I can't get that done tonight yet. --[[User:Zombie|Zombie]] 20:23, 9 March 2009 (CDT)

:Ok, I ran some trials with an unmodified GC-P round on the normal seabed floor against soldiers having 100 health and 0 all-around armor. For the guy standing at GZ, I saw ending health values of 99, 94, 93, 92, 90, and 89 (n=50). So that comes out to 1, 6, 7, 8, 10 and 11 points of damage respectively. I didn't think 11 damage was possible. Here's where things differ though. All the other guys who were clustered around GZ always received only one point of damage, never more, never less. In EU, the guys around GZ took damage equal to the guy at GZ. Odd. So then it occurred to me that perhaps I should check the MCD values of the seabed (TFTD) and the desert (EU) landscapes. Both are basically identical in terms of armor. But the seafloor has a "time to burn" value of 0 while the desert has a value of 1. So maybe our understanding of normal fire isn't totally complete. I'm going to go back to EU and retest the desert landscape with varying MCD burn time flags to see how that affects damage. ;) --[[User:Zombie|Zombie]] 23:00, 9 March 2009 (CDT)

:: The whole Phosphor being half effective under water is related to the burn time and spread, if I remember correctly. The settings in the MCD files may be the culprit. The actual damage dealt or initial spread may not necessarily be affected.

:: Hey, I just had a wacky idea. XComutil. Use its feature where you can set the depth of a mission. Launch a mission on a island terror site map (again, use XComutil's map picker to get to this faster). Lots of grass to burn there. Set fire to it and count how many turns before the fires die out. Redo the test, but this time set the depth to a deeper level. Try the whole process out again.

:: Next repeat this with one of ye-olde seabed maps. They look really weird without the blue palette shift when played on land, what with the landscape being gray.

:: It's possible that the half-effectiveness relates to the fuel that the fire has to burn more than anything else. Further confirmation on how long the flames stick to a target when on land or underwater may be helpful. -[[User:NKF|NKF]] 01:28, 10 March 2009 (CDT)

:I've been burned one too many times using editors or utilities to mess with saved games. Half the time they introduce some unknown "feature" which isn't documented. Thanks, but no thanks. I only test with an unmodified game, except for the changes I make myself to keep control of the situation. Anyway, I tested a patch of fire on the seabed to see how long it remained lit (which has a "time to burn" value of 0). It only stayed lit the current round the shell detonated. After that the fire went out. So this agrees with what is expected. Will continue to work on this as I get time. --[[User:Zombie|Zombie]] 01:51, 10 March 2009 (CDT)

Well, I suppose my recommendation doesn't necessarily need XComutil. It would've certainly made it easier. But yes, it does introduce a few things that work behind the scenes that we might not know too much about. However, if I remember correctly, one of the battlescape savegame files should hold the depth level of the current map you are playing on. All you'll need to do is tweak that to change the depth of the map.

One other thing, the different effect HE has on the same tiles underwater and when on land (ala the Triton) may also be one of the other culprits behind the belief that phosphor is less effective on land. Being able to blow up the Triton on land, but have it appear virtually indestructable when underwater does that. -[[User:NKF|NKF]] 01:59, 10 March 2009 (CDT)

----

re Zombie's underwater tests, there is normally (i.e. on land in EU) a difference between the IC damage on the target of the direct hit, vs lower damage to others in the area of effect (hmm contrary to my IC kill modelling assumptions: uh oh I may've spoken to soon). But only seeing 1 damage on the others in the AoE does seem low. We need to figure out why. Did any of the other targets catch fire? Does that ever happen underwater? Do tiles ever burn past the turn when the IC round is fired? Any of these factors would reduce total fire damage/effectiveness by '''more''' than half. Actually, doesn't it say the 1-12 damage for "in fire" is ''not'' random, but dependent on terrain type? That could be the answer.

The [[Incendiary]] article actually mentions '''4''' modes of fire damage, only 3 of which are quantified:

#"impact",
#"being in fire"
#"being ''on'' fire"

The 4th mode is "damage from burning ''terrain''. Only a tantalising mention is given, no quantitative details. This could be the source of the discrepancy. In fact it might be a component of "being in fire" that's not fully understood. I think Zombie is right to review the assumptions on this one - nice work! [[User:Spike|Spike]] 04:05, 10 March 2009 (CDT)

:As I recall, "damage from burning terrain" is synonymous with "Standing on a tile that's currently on fire." Thus "Being in fire." But that's me and I'm tired this evening, so I could be wrong. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:30, 10 March 2009 (CDT)

I performed my TFTD Phosphorous tests underwater and after the flames died out some of my men did catch fire. So this part seems to jive with that of EU. Tiles do not burn longer than its "time to burn" value in the MCD files. So for instance, in the seabed underwater testing mission, the tiles have a MCD burn value of 0 which corresponds to the results seen (ie fire didn't stick around into the aliens turn or X-COM's next turn either, it only stayed lit the turn it detonated). There really is only 2 "modes" of I/P/fire damage:

<ol><li>The code used for determining if a unit catches fire: 0 damage (if the unit didn't catch and was able to shrug it off) and 5-10 (if the unit catches).</li>
<li>Standing in fire.</li></ol>
At least from the initial tests in TFTD, units outside GZ are just considered to be standing in fire that turn and always take 1pt of damage. Anyway, I don't want to talk myself into a hole without doing more tests. All the following trials I do will be in EU to hopefully curtail any unknowns in TFTD. Once EU's code is figured out then it can be applied and compared to TFTD. --[[User:Zombie|Zombie]] 09:06, 10 March 2009 (CDT)

: If they are "standing in fire", do you think the 1pt damage/turn is based on the fire characteristics tile/terrain type they are standing on? Is it more generally 1-12/turn, dependent on terrain? Also if you get a chance can you test large units and see what kind of effects they take on the GZ+1 squares? If the GZ+1 squares of a large unit are just 'standing in fire' rather than 'catch fire/5-10 impact damage' this will substantially weaken IC vs large units. And I will have shouted too soon! :) [[User:Spike|Spike]] 09:18, 10 March 2009 (CDT)

I did some ad-hoc tests in TFTD. Actually I just ran around firing GC-P and HJ-P rounds everywhere. :) On a typical seabed layout, I found that most things don't burn - the fires don't last into the next turn. The only things I could get to burn were the green moss stuff and and coral skeleton "trees". Even the barrels do not burn. Also, I did not see much sign of terrain damage caused by the fires. But the moss and coral did burn for the normal period, i.e. 1-5 turns.

I also managed to kill an Aquatoid with a single direct hit from a GC-P, in one turn. He died at the end of my turn or the start of his. That seems unlikely. 5-10 from being hit, plus 1-12 for standing in fire, plus maybe another 5-10 from being on fire? It's just about possible I suppose, to max out near 32 damage (if the terrain offers you "12" when it burns). Anyway those are my unsystematic enquiries. I have the 8 save files of various stages of the battle if anyone wants to take a look. It was from a virgin TFTD installation and there was no editing or jiggery pokery.

OK I've uploaded the save files [[Image:TFTD Incendiary Tests 01 Spike.zip]] and taken a look myself with BB's editor. Prior to being hit (Game_4) our Aquatoid was in rude Health, 30/30. Immediately after being hit (Game_2) he was at 19 Health (no Stun damage) and On Fire, as well as Standing in Fire. That implies 11 Damage from the "impact effect" which is not supposed to happen. As noted, at the end of the same turn or beginning of his next turn, he dies. He looks to be standing on a standard seabed square, just sand, the kind of thing that does not burn. He is next to some of the brown cushion-like coral, but I don't think that burns, at least not over multiple turns. In fact in the same turn he is hit, at the end, you can see him dead (Game_3). Since there was only one alien, he died in the same turn. OK that's slightly confusing, maybe someone can double check the turn numbers in the save files (don't know where they are).

[[User:Spike|Spike]] 13:29, 10 March 2009 (CDT)

Doh. I is a idiot. The Aquatoid was killed by the incendiary fire bug - I fired extra IN rounds at terrain objects after he was on fire. Which explains why he is already dead by the end of my turn. [[User:Spike|Spike]] 15:08, 10 March 2009 (CDT)

:Yeah, you gotta watch that. Well, anyhow, I edited the desert landscape in Enemy Unknown to have the same MCD "time to burn" value of 0 as the seafloor in TFTD. From the limited tests, the results look the same as in TFTD. (Fire burns out after the initial turn it detonated, units around GZ taking 1 unit of damage while the guy at GZ got more). So that means I can focus my efforts on EU with little worry because there will be no issues. I'm going use BB's logger and AHK to automate the data gathering aspect to save me a bunch of time. I'll probably need the full requisite 2000 reloads though, as the guy at GZ is not the same as the 24 soldiers around him. Wish me luck. :) --[[User:Zombie|Zombie]] 15:54, 10 March 2009 (CDT)

Good luck! I just read the MCD article, and it mentions 2 fire-related byte fields in MCD - "likelihood of catching fire" as well as "time to burn". Is the last field variable or fixed? Could the first field determine the damage/turn to units when it's on fire? Also with a possible 4 terrain items that could all be burning, is the maximum damage higher than 12? [[User:Spike|Spike]] 16:10, 10 March 2009 (CDT)

:Offset 45 is the flammability rating of the tile. This most likely controls whether an adjacent fire will spread to the tile in question. (For instance, if a fire is burning and the next tile over is a tree or something, it'll probably spread there fast because of the combustibles present). The other byte is offset 57 which is the one we are after. Don't know about the 4 types of things which can exist on a tile at once. I think the most I have ever seen is 2 (usually ground and a wall). Wouldn't hurt to edit a tile to include all 4, but that's an entirely different test to do. It'll have to wait until we get a better understanding of basic fire. ;) --[[User:Zombie|Zombie]] 19:38, 10 March 2009 (CDT)

::Here's a question. On Large units, if only one segment of the Large unit is on fire, will the fire spreading code allow the other three segments to catch on fire? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:13, 10 March 2009 (CDT)

:I highly doubt it. Unit fires are completely different creatures from terrain fires. Needs testing though. --[[User:Zombie|Zombie]] 20:55, 10 March 2009 (CDT)

::Yes it would have to be a very special case, since afaik fires do not spread from regular units on fire to adjacent terrain or to other adjacent regular units. Though it would make more sense than any of those things. [[User:Spike|Spike]] 21:03, 10 March 2009 (CDT)

== Incendiary Bug ==

(Also known as the [[Known_Bugs#Funky_Fire|Funky Fire/Smoke bug]].) I made some suggestion about why this bug happens, and how the code could be patched to fix it: [[User talk:Seb76#Incendiary Bug]]. [[User:Spike|Spike]] 07:13, 12 March 2009 (CDT) Here is the general discussion of the bug:

With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

I also suspect that other "end of turn" processing happens with every IN round fired. I am pretty sure "fire spreading" checks occur, as I have seen fire spread when using perfectly accurate shots. Either "fire spreading" happens, or there is a random element in incendiary area of effect, that is definite. I want to repeat these tests to see if "catch on fire" effects also happen for those who are standing in fire when an IN round is fired. [[User:Spike|Spike]] 08:59, 31 March 2009 (EDT)

== Mwahaha ==

Was exploiting the Elevator Shield trick on an Alien Base Assault, and I had the forethought to pack lots and lots of Incendiaries. My sick sick mind found it amusing to set all those aliens on fire and watch them roast stupidly and helplessly. (Jasonred)

= Fire Damage =
(moved from talk:UFOextender)

Not sure if the bug is already posted. And Not sure if I should post the bug here or in [[Talk:Incendiary]]. Problem is if you use extender to fix funky fire bug. Incendiary no long does any damage at all. Units only take the small amount of damage after ending turn because they're on fire. Using 1.28.3 extender

To test this. I stripped a soldier of armour. And pounded four incendiary rockets into the soldier in the same turn. No damage. And then next turn, his health drops a little because he's standing in fire. This may not be a problem for most players. But it is still a major bug. I understand the funky fire problem is already difficult to fix, and I say thanks to all who will try to help solve this bug. [[User:Hellblade|Hellblade]] 14:44, 28 September 2012 (EDT)

: That's not a bug, that's the fix. Incendiary damage is only applied at the end of the turn. Think about it... does fire kill faster than a bullet? Faster than a grenade? Can you kill someone with fire faster than they can get a shot off back at you? No, to all these things. To compensate for fixing the bug, fire damage is doubled compared to the previous end-of-turn fire damage (that always existed). It is no longer applied per shot or per impact. All you get "per impact" is another chance to set the target unit itself on fire. Incendiary is a weak attack. It has the benefit of a wide area effect, no HE block, and ignores armour. There are situations when IN is the only effective weapon XCOM possesses. But, like everything, it has strengths and weaknesses. [[User:Spike|Spike]] 15:51, 28 September 2012 (EDT)

:: I see your point but let me elaborate. Heat, not fire, do kill as fast as bullets. The original game mechanics separated heat from fire just as in real life. It intended to have the big heat blast damage first and then the small fire damage per turn.
:: Take the most extreme case, napalm or volcanic lava, you get fully cooked in less than a second - just by heat alone, and you may/may not catch fire later on. And heat blasts travel as fast as bullets, in some cases as fast as light. I believe the game has different Incendiary damage values to do different damage according to how strong the heat is, not the fire afterwards. The damage by fire later on makes sense because natural burning fires aren't that hot comparatively.
:: I understand the difficulty in trying to fix this. But before this fix you could kill a reaper by a few AC-I shots (which is their weakness) and now you can empty the two clips at it and it'll never die. [[User:Hellblade|Hellblade]] 03:11, 4 October 2012 (EDT)

== Advantages/Disadvantages of using Incendiary for nighttime light ==

It seems for most folks that electro-flares are the go-to for night lighting and incendiary rounds are a distant afterthought.
With that in mind I propose this list of pros/cons to using incendiary at least as a major complement to flares.

Cons:
Low damage, and for each soldier with incendiary rounds loaded they can't attack with more effective weaponry unless
---- they unload and reload
---- they carry another gun or use 'nades/stun rod
Not re-usable, will always be depleting stock

Pros:

Not dependent on throwing limitations of range and arc/trajectory
Very efficient in terms of light-output per weight, storage space, and time units
Can set area on fire to illuminate where the enemy is initially, then as the fire burns out you may move into the cover of the smoke it generates
Does at least some damage to enemies - very unlikely to kill them, but softens them up so future attacks more likely to neutralize
Area denial - fill a small building or enemy craft and watch them flee out into your reaction fire, or at least out where you can get them, they don't get the drop on you
At least in OpenXCom the enemies on fire should provide lighting, helping to spot them at a distance
Fire is less vulnerable to being destroyed by nearby explosions, unlike those wimpy flares. And even if it is snuffed, it isn't something you were counting on re-using
Reaper vulnerability
Zombies not re-spawning to 'lids when KO'd by fire splash
You can dedicate a few number of soldiers to throwing fire around while the rest keep their hands and TU's free to attack
Soldiers that go berserk/get MC'd can't hurt armored soldiers w IC fire

Now it seems to me that the first Con is major and obvious, but the many Pros are overlooked. Also that big Con could be greatly mitigated by cannon wielders w incendiary carrying a decent secondary weapon: thinking plasma rifle or pistol, laser pistol

any I'm missing? what about putting this on the main page?

Talk:Incendiary

2021-07-08T16:48:31Z

Mugwump: /* Advantages/Disadvantages of using Incendiary for nighttime light */ new section

== General Comments ==

For now, we'll just say the smoke + incendiary stun effects only work on X-Com owned units until some tests can be run to confirm this. It's unusual that only X-Com units are affected, but the game has been known to surprise you even after you think you've worked something out.

- [[User:NKF|NKF]]

----

Given how aliens love to hang around in a smoke-filled crashed UFO, IC rounds would be insanely powerful if they did actually work against aliens in smoke. I'm glad they don't ''seem to'', as I'd be very tempted to cheat with it. They do work against aliens standing in fire, though, which is still quite cheaty...--[[User:Ethereal Cereal|Ethereal Cereal]] 21:35, 5 May 2006 (PDT)

:I do consider the "standing on fire + new IC explosions = damage" a cheat. So I just don't abuse it. I only use IC rounds to illuminate or to finish off hiding aliens. It can also work as a "pass-through-and-die" tactic, the same way Proximity Nades work, although fire damage is pretty sad xD. --[[User:Nekrocow|Nekrocow]] 00:36, 24 June 2012 (EDT)

:: I use it a lot in TFTD to clear out those island bunkers and the upper storage levels of the large train station. Either the aliens roast alive, or they come out. Otherwise yes, it's no doubt a cheat. Well, more a bug exploited as a cheat. -[[User:NKF|NKF]] 02:09, 24 June 2012 (EDT)

-----

I just edited the Incendiary page a bunch, because Brunpal's [[Talk:Experience]] questions about Incendiary sparked my interest... I never did test IN vs. experience. It's a very good question ''if'' it turns out to cause Firing experience. But while reviewing this page, I had a number of questions, for anyone interested. Also, I only tried to clarify things, and don't know Incendiary well, so fix anything you know I got wrong:
#Did I get it right re: the set [ 0, 5, 6, 7, 8, 9, 10 ] for chance of initially catching fire? I over-wrote "linear" because it seemed odd when XCOM usually goes, e.g., 0-10. (Who tested this? - A little help here please. Just making sure.)
#Why flame a zombie unless it's near death (and how can you know if it is)? It's been a long time since I used fire - if you don't have flying armor, why mess around with a zombie by burning it, why not Heavy Plasma it.
#Any research/data on tile flammability versus duration of burning is appreciated. Probably it should go on the [[Terrain]] page byte, but be clearly referenced here. It's just a curiousity, but an interesting one.
#The last line of the page says ''"The damage values listed in the UFOpaedia do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames."'' Does anyone know IN strength vs radius, then? Should be easy to test and post.
#NKF, Zombie, or anyone else... would you mind seeing if Incendiary causes the Experience counter to increase? Brunpal is right that it's important to [[Experience]]... I found [[Small_Launcher#Experience|Stun Bombs]] to count for experience across their whole range, even if no stun damage occurred... if you have 11+ Mutons in a firing squad situation, passing around an [[Auto-Cannon]] with Incendiary may be better than standard pistols, depending on the range of the blast. I could test it, but it's been a long time since I've delved into the files; maybe one of you have them more close to hand. [[User:MikeTheRed|MikeTheRed]]
-----
:Offhand, the only way I could think of to check the remaining HP on a Zombie would be by using a [[Mind Probe]]. Given the relative uselessness of a Mind Probe after Psionics are developed, as well as the time needed to use the Probe once, this seems a rather impractical course of action, unless your Rear Commander has nothing better to do. I agree, Heavy Plasma on Auto is better. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 1 August 2008 (PDT)
-----
#Yeah, the set is correct. When a unit is shot with an incendiary round, the game does a calculation to determine if the unit catches fire. If it doesn't catch fire, the unit takes no damage (the 0 in the set). If the unit does catch fire, it will take between 5-10 damage points. Stupid discontinuous range, but that's what happens. As you may guess, I did the Incendiary trials over at the StrategyCore forums in the Damage Modifier topic - see [http://www.strategycore.co.uk/forums/index.php?s=&showtopic=746&view=findpost&p=39672 this] post for the particulars.
#Why flame a Zombie? Simple. A Zombie which is killed by an Incendiary round doesn't turn into a Chryssalid. Zombies are easily outrun, so you can just keep picking at them from a short distance with Auto-Cannon Incendiary rounds and then running away. Fairly effective, even when your troops do not yet have armor to protect them. And when you do not have the luxury of the Heavy Plasma early in the game, Incendiary is a good way to avoid an overabundance of Chryssalids who are not so easy to kill. As for checking the Zombie's stats, you can only rely on the Mind Probe or Psi. Neither are available early either (the Mind Probe is usually low on the research tree for most people even though you can collect enough, and Psi is difficult to use as a soldier needs to be quite proficient to use MC.
#I have been meaning to do some tests in flammability vs terrain but only recently started fooling with MCD values. It'll be next on my list.
#Here, I uploaded a very recent spreadsheet containing both I and Smoke when damage values are hacked. See [[Media:Incendiary_and_Smoke_Patterns.zip | this file]] which contains both.
#I think I fooled around with Incendiary recently in conjunction with promotions. Soldiers who shot aliens with "I" didn't get promoted. Logically, that would mean the experience counter didn't increment. UNITREF.DAT would need to be checked to verify though. Addendum: indeed, as BB mentioned in the experience page (and a quick glance at the UNITREF.DAT experience counters by myself to triple-check my aging brain), Incendiary rounds do not increase any of the experience counters.

Hope this clears up some of the issues/concerns here. --[[User:Zombie|Zombie]] 21:16, 1 August 2008 (PDT)
----
<i>"The damage values listed in the [[UFOpaedia]] do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames. Fire is unlike other damage; it works at initial blast and then over time, as described above."</i> and
<i>"Initial "impact" damage from incendiary ammunition is either for no points (unit does not catch fire), or between 5-10 points (unit catches fire)."</i>

This should be stressed on ALL the various relevant pages. It's important. 6.4 dmg vs 90 dmg is a significant difference!--[[User:Brunpal|Brunpal]] 09:31, 2 August 2008 (PDT)
----
It looks like Incendiary is gaining some clarity (at least for me), thanks for starting it Brunpal...
*The "6.4" was only for the initial IN round impact (set [ 0, 5-10 ]); it can then burn for 4 more rounds (set [5-10]). Perhaps a short way to state this complicated damage type is "Minimum 0 (unit does not catch on fire) ''OR'' unit catches on fire 1-5 turns, 5-10 damage/turn, 5-50 damage in total (average 21.5)". Does that look right, Zombie? I'm not sure where you got 90 from Brunpal...
:90 is the listed damage from an IN rocket.--[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)
*However, the numbers I just stated do not count possible additional damage from nearby terrain being on fire (as opposed to yourself). Maybe those should be included somehow. (And clearly, fire is much more dangerous outdoors than inside UFOs, where terrain does not burn.) But since terrain fire can last a variable number of turns, I guess you can't have a maximum damage. Average terrain damage from fire would be 6.5/terrain (1-12), but also, it can keep the unit itself burning more than 5 turns... hard to model.
*Good point about flaming zombies, Zombie. I guess you ought to know, eh? :)
*The spreadsheet looks great. Perhaps one of us can pull out the area patterns for non-hacked IN weapons and put them on the relevant pages. When it's done, the spreadsheet itself would be an asset to Incendiary (or maybe [[Damage]], if it's listing all types of damage). As has been stated, it's the size (area) of the blast that actually directly relates to incendiary weapon "strength"... the diameters you found are probably what should be in parentheses next to weapon strength, although damage can appear as well.
*Ok, no experience from Incendiary blasts. It might've been real interesting if there were, but it didn't occur to me to test. (Or maybe I tested it briefly so long ago that I forgot.) I would've guessed that they did, because the stun bomb and explosives do. Oh well.
*P.S. Brunpal, we may not have touched pages in a year, but most/all of us have "Watch this page" turned on, so we get immediate notification of any pages we've edited or Watched. :)
-[[User:MikeTheRed|MikeTheRed]] 09:17, 5 August 2008 (PDT)
----
*Sounds correct MTR. I think Brunpal was just comparing the "damage" (actually strength) of the Incendiary Rocket (90) to the average damage due to the "impact" of the blast (6.4).
*Well, it isn't ''nearby'' terrain on fire which you have to worry about, it's the tile directly underneath a units feet which causes the most concern. If that tile is on fire and the unit doesn't move, it will take 1-12 damage points. While true that terrain on fire can last a variable number of turns, there is a definite upper-limit to how much damage a unit can possibly take. Fires don't last forever, and the combustibles eventually are consumed leaving either scorched earth or a damaged tile. Those damaged/destroyed tiles usually cannot be started on fire again by the spread of flames. They can only be set ablaze with incendiary ammo, and even then for only 1-3 turns (normal for dead tiles). So it's certainly possible to find a max damage. And for the most part, the things that burn the longest are usually objects, not tiles. And most objects you can't stand on anyway. But I totally agree that it's hard to model how fire functions due to the two forces at work: "impact" damage and damage due to standing in fire.

P.S. Some of us are actually around here and don't need to be coaxed back into existence by an email when a watched page is changed either. Just because it's quiet, it doesn't mean nobody's home. :) --[[User:Zombie|Zombie]] 20:34, 5 August 2008 (PDT)
----
While understanding the whole formula for fire and fire damage happens is useful, it was not thinking to go that broad. I was just interested in what occurs from the moment a solider takes his shot, to the time that solider gets his TU back. ie damage from incendiary rounds vs fire damage. --[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)

----
It looks to me that, unlike all other forms of damage, Fire damage ignores armor, goes right past it. If so, this should be made explicit on the main page? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 05:55, 30 May 2021 (UTC)
:Fire damage doesn't ignore armor - power suits for instance can't be damaged by fire, except if the unit is already injured. Read carefully the Damage section - there's a lot of nuances about how fire works. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 03:03, 1 June 2021 (UTC)
:: What I meant is ignore armor ratings for damage calculation. While accounting for the resistances listed on the Damage Modification page, doesn't incendiary act as if front, side, back and under armor are 0 for calculation? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:21, 1 June 2021 (UTC)

== Incendiary vs Large Units ==

We're discussing this in [[Talk:Sectopod#Incendiary vs Sectopod]], and a question came up. When an IN round impacts one segment of a large unit, presumably that segment gets the "Incendiary impact" function, i.e. 6/7 chance of catching on fire for 5-10 damage plus 1-5 turns of being on fire. Does the same "impact" function also apply to the 3 adjacent squares (6/7 chance), or is it just the "standing in fire" chance? If you had multiple regular-sized units standing in the area of effect of an IN round, they would each get "impact" effects (right?). So it ''seems'' logical that all 4 segments of a large unit, inside the area of effect, are also exposed to "impact" effects. But I wanted to check. [[User:Spike|Spike]] 06:34, 9 March 2009 (CDT)

Oh boy! Calculating this not only depends on a lot of unknown assumptions, but is fiendishly complicated - especially if you factor in the "funky fire" bug. And contrary to my noblest efforts, it's impossible to use IN weapons without inadvertently exploiting this bug. Even if you only fire IN at a single target until it's dead, once the target is "standing in fire" you effectively just can't miss.

Anyway back to the Large Targets specifically. The key assumption above is whether all regular-sized units in the area of effect of an IN burst are affected with "impact effects" - 5-10 dmg & 6/7 chance to catch fire. If they are, it's reasonable to assume the same thing happens to the 3 other segments of a Large Unit. However I suspect this is not the case, and strictly speaking "impact" effects should only occur at the single, impact square of an IN round. Testing needed!

More likely, the GZ+1 squares, whether occupied by small or large units, are only subjected to the "standing in fire" effects: 1/3 'catch fire' probability, and 1-12 terrain-based damage. And these effects are applied once per turn, not once per hit.

However, all of this is turned on its head by the 'funky fire' bug. After the first round hits, all units (and all Large Unit segments?) are "standing in fire". (Though maybe these fire damage routines run only for the "control" segment of the Large Unit? Possible, but unlikely.) Since they are standing in fire, the funky fire bug applies and all units/segments are hiit with "impact" effects.

So assuming a Large Unit is ''already'' standing in fire (e.g. from a previous IN hit or near miss), damage per IN round fired is 6.4 x 4
= 25.6 average, 10x4= 40 max. Subject to resistance/vulnerability modifiers, but ignoring armour level. In addition as multiple IN rounds are fired, the chance of all segments catching fire quickly approaches certainty. This not only means the Large Unit will sustain further damage at the end of the turn, it makes it impossible to escape the 'funky fire' trap by moving out of burning squares.

(Any testing needs to be very careful and probably only fire a single IN round per game, otherwise 'funky fire' will skew the results.)

So, in conclusion, the TU/kill factors I put up on the Talk pages for the Large Units ([[Talk:Reaper]], [[Talk:Cyberdisc]],[[Talk:Sectopod]]) should pretty much reflect the 'funky fire' reality after the first round connects, apart from the fact that you actually can't miss. The very first IN round to be fired would have the same effect (for immediate damage) on a Large Target as on a small one. But I really don't want to update the numbers to reflect this fact, it's just too awful. For AC-IN, the firepower factors will be about 6 times better than stated. Maybe I'll just remove them. :(

[[User:Spike|Spike]] 15:51, 10 March 2009 (CDT)

=== Simple Tests ===

I did a small number of tests and found some interesting results. In 5/5 tests, all 4 squares of the target (Reaper) were on fire the following round. (It's hard to tell if they are on fire the same round, as you need to extinguish the fire with smoke to see). Perhaps this makes sense, as it's a UNITREF attribute and so applies to the whole unit, not its 4 component squares?

Looking at the damage, it looks like "impact" and "on fire" damage applies to all 4 squares, i.e. x4 normal. Damage clusters tightly around 16-18 per hit which is roughly the expected value, maybe a bit lower (at x4). And since we '''are''' on fire, should expect an average of 7.5 ({5..10}/6) rather than 6.4 ({0,5..10}/7? Maybe something else is going on here, as these numbers seem a little low - 6.4 x 4 = 25.6 per hit or 7.5 x 4 = 30.0 per "on fire" hit might be expected on a Large Unit.

:Drat. I didn't factor in the Reaper's 170% Susceptibility to Incendiary. So the actual damage levels are more like 10 per hit. Maybe there is no multiplier for the 4 squares? Hard to figure out what's going on here. In tests on hacked humans, armour level is not a factor vs Incendiary damage, otherwise I'd suspect the under-armour or something. 2.5 avg damage per segment seems too low. 10 average damage per alien seems too high - that should be the max, not the average. Is some mechanic pushing the average up to the max? I don't have a clue right now. [[User:Spike|Spike]] 06:53, 11 March 2009 (CDT)

The damage seems to be regardless of "funky fire" effect. A round fired at a target that is not burning / in fire seems to do about the same damage, per hit, as one that is in fire / on fire and so subject to the funky fire bug. So the only 'bad' effect of the bug is that you never miss, and you hit everything that is in fire / on fire. Not quite so bad, and it allows you to play honest by only ever firing at one target, not hitting any other targets by accident (!), and firing from point blank range so it doesn't matter that you never miss.

Burn Time was as high as 7 when multiple IC rounds were fired (on auto). Higher than we thought possible (1-5 range expected). However it sometimes goes DOWN after additional hits. Possibly the value is re-randomised with every new IC impact, but hits are cumulative while firing auto bursts?

Here's the raw test data:

Test 1.
-
2 DH on Reaper, mix of auto and snap, some other IC impacts on others
Burn Time=7 - exceeds known limit of 5
All 4 sq on fire next turn
Is 'on fire' global? It's in Unitref, so maybe
-
Test 2.
-
1 DH on Reaper, only IC shot fired in game.
In firing turn, taken 132/148 = 16 damage. Burn time=3
Start of T+1, taken 122/148 10 more damage, Burn time=2
T+1 Reaper shows all 4 squares burning
-
Test 3.
-
Revisit #2 firing turn... fire another round (this will use funky fire)
So 2nd IC hit, 2nd rd fired, same target.
Health now 114/148, further 18 damage
But Burn time has dropped to 2! Must re-randomise on each hit??
Maybe only accumulates during auto burst?
-
Test 4.
-
Let's try lots of hits. Hack up accuracy to 255
OK 3 out of 3 hits on Auto
T+0 Health=98/148=50 damage (17 avg) Burn=6
T+1 Health=81 (17 more dmg) Burn=5 All 4 squares on fire.
-
Test 5.
-
Revisit #4 and push to 6/6 hits
T+0 Health=41/148=107 (18 avg) damage Burn=7
T+1 Health=21 (20 more dmg) Burn=6 All 4 squares on fire.
-
Methodology (Apart from Test 1) = only ever 1 (same) target in any IC AoE; no misses
(To try to minimise the impact of 'funky fire' effects - but can't eliminate)

[[User:Spike|Spike]] 23:27, 10 March 2009 (CDT)

I re-ran the same simple tests against a regular-sized (Floater) target instead. The results agreed much better with the 'standard model' of [[Incendiary]] effects. All results were within the permitted ranges in the 'standard model', though some values were unexpectedly. I think some variables to look for in Incendiary mechanics are:

* Large Unit vs regular unit behaviour looks to be different
* Auto burst vs single explosion looks to be different (maybe just due to funky fire bug, maybe not)
* Tile MCD "time to burn" value seems to affect one or more of the other calculations / probabilities
* Burn Time on the unit can go up as well as down. New hits seem to re-randomise the value.
* End of turn processing does not always reduce unit Burn Time by 1. Can a terrain fire add to unit Burn Time?

[[User:Spike|Spike]] 21:25, 11 March 2009 (CDT)

:I doubt a terrain fire adds to the time a unit is on fire. Actually, I'm quite positive on this since my tests from a while back were quite thorough. The counter can only tick down to 0, and when it does a terrain fire will have a chance of "reigniting" the soldier again.

:Anyway, I had to start from scratch again on testing due to a few issues with my test scenario. I totally forgot that the first soldier on the unit roster is a bad choice for a "designated hitter" since he can never be automatically selected on a reload. Soldiers lower on the order are much better choices. So I got the shooting automated, but each reload was taking too much time since I had to reselect the shooter, select the shot, move the view down a level, shoot the target and abort. Having the soldier already selected cuts out 2 actions in the list allowing the script to run more efficiently. I'm going to try to get everything properly setup tonight, then start testing tomorrow morning. With a little luck and about 2 hours of babysitting the script to make sure it doesn't quit, I should have some prelims. --[[User:Zombie|Zombie]] 21:55, 11 March 2009 (CDT)

----
Looking forward to seeing that data! I did some more testing just for the special case of Large Units, about 40 tests. My tentative conclusions:

# Damage range per 'impact' hit is the same as regular units, around 5-10 x Vulnerability (maybe + MCD Burn time?)
# Large units go on fire about 1/7 of the time when receiving a direct hit - as expected
# Either all 4 segments go on fire, or no segments go on fire - no 'part segments on fire'
# Unit burn times are not correlated with unit damage received
# Auto fire has the same average damage level per hit as snap fire
# Unit Burn Time can exceed 5, both on Snap and Auto. Highs of 6 (Snap) and 7 (Auto) were seen. Maybe 1-5 + MCD Tile Burn Time?

All my tests were done on the grid-lined pavement tiles from urban terror missions, which have an MCD default burn value of 2. For some of the "setting the large unit on fire" tests, I had the target floating in mid air, because air does not burn even during the turn that the IN round explodes - it makes it easier to see the unit burning.

From Bomb Bloke's editor notes, the 4 potential MCD tiles in a map location are: a North Wall, a West Wall, a Ground tile, an Object tile. All 4 of these MCD tiles might have a burn time value. But Ground and Object are the most likely to be relevant.

[[User:Spike|Spike]] 21:58, 12 March 2009 (CDT)

:Ok, I got the script running and optimized it a bit to cut down some wait cycles. Right now it's cranking out approximately 400 trials per hour which is about as fast as I can make it go without removing some desktop icons (all the icons have to refresh at the end of each logging cycle which takes a little time). Anyhow, just for giggles I stopped it after 400 trials to get some prelims.

:<table {{StdCenterTable}} class="sortable">
:<tr {{StdDescTable_Heading}}><th align="left" width="90">Damage</th><th width="90">Count</th><th width="90">Pct%</th></tr>
:<tr><th align="left">1</th><td>68</td><td>17.0%</td></tr>
:<tr><th align="left">6</th><td>58</td><td>14.5%</td></tr>
:<tr><th align="left">7</th><td>45</td><td>11.3%</td></tr>
:<tr><th align="left">8</th><td>63</td><td>15.8%</td></tr>
:<tr><th align="left">9</th><td>55</td><td>13.8%</td></tr>
:<tr><th align="left">10</th><td>64</td><td>16.0%</td></tr>
:<tr><th align="left">11</th><td>47</td><td>11.8</td></tr>
:</table>
:If you average the percent columns, it comes to 14.28571429% while the expected is 1/7 or 14.285714285714285714285714285714 which is a difference of 4E-09. This means 400 reloads is plenty enough values for this application. Great news! Well, as you can see, instead of the set [0, 5, 6, 7, 8, 9, 10] for MCD of 1, this scenario where the MCD was 0 is shifted up by one [1, 6, 7, 8, 9, 10, 11]. Interesting.

:Tomorrow I'll rerun the MCD 1 scenario again to verify the values and damage set. Then it's on to the MCD of 2. --[[User:Zombie|Zombie]] 01:50, 13 March 2009 (CDT)

:: Extremely interesting! By the way, it was probably a late night but - the average any 7 numbers that (must) add up to 100% is always going to be 1/7th of 100%, so that result doesn't really demonstrate any confidence in the data. It would be the same with one result, or with a trillion results. The 4E-09 discrepancy is just the precision error in your calculator/spreadsheet's calculation of the percentages and the average of the percentages. You've got some considerable variation from 1/7th on the individual numbers, I'm not sure if that's just to be expected with only 400 trials. But for example "0" and "10" are both a bit high so it ''might'' be non-linear (probably not). Anyway we'll see when all your results are in! (To measure the degree of variation from the expected result, what you want is a chi-squared test or something - and I don't know what I'm talking about there so I'll shut up!)

:: I'm checking Bomb Bloke's MCD database, and there are some tiles in there (U_BASE 22-25) with MCD burn value of 30 - I might play with those and see if anything dramatic happens. Oh except looks like they can't be set on fire (255 flammability). There are others that are quite high (8-), and still flammable. Or I could hack an MCD file (scary). Maybe I'll just wait for your results Zombie! [[User:Spike|Spike]] 05:49, 13 March 2009 (CDT)

= Incendiary Research =

== Large Units On Fire ==

Here's another interesting test for setting Large Units on fire. Set AC-I power down from 42 to 1.
At this IC power, there is no area effect. You can't even start a fire on one tile.
All you can do is set units on fire with a direct hit. This means there is no way the other 3 squares of the
Large Unit are in the IC area of effect.

Result: Whether you hit a one square regular unit or a 4-square large unit, if it goes on fire, '''all''' squares of the unit still go on fire. Along with the fact that the inflicted IN damage level vs Large Units is basically normal (see above), this tends to confirm that being on fire is a "unitref" property and, unlike HE and Stun Bombs, is not applied (multiplied) vs the number of squares the unit occupies. (In fact it would be good to check that HE is actually applied separately to each square, with different HE strength, potentially different armour facing, etc. Maybe the engine just simplifies things and multiplies damage by 4?)

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)

== Unit Burn Time ==

Unit Burn Time seems to be considerably '''cyclic''' rather than random. Very often, it just steps down by one from the previous value. I suspect this is because the "impact" routine calls the "end of turn" incendiary/smoke routine (see [[User talk:Seb76#Incendiary Bug]]). Sometimes it does not happen, maybe because some other factor has caused the Burn Time to increase.

Here's some data. This was done against a Reaper with AC-I power set to 1 (and 10% TU Snap fire cost). But I've seen similar results with standard AC-I.

Hit H/H Dmg/Avg Burn Time
1 137/150 13 2
2 126/150 11 1
3 104/150 22 0 Very high damage (=13x1.7). Unit not on fire when game restored.
4 96/150 8 7
5 81/150 15 6
6 66/150 15 5
4,5,6 76/150 /9.33 5 (Auto) 9-10 (=5-6x1.7) is near minimum dmg
7 56 10 4
8 48 8 4 What happened here? didn't cycle. MIN dmg (5x1.7).
9 35 13 6
10 25 10 5
11 10 15 6 New shooter takes over
12 2 8 5

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)
:You're right on spot once again ;-) When a unit takes a direct hit from an IN round, it is set on fire (the duration is randomly chosen between 0 and incendiarydamagemodifier/20). Then the "end of turn" routine is called, which inflicts damage *and* decreases by one the number of turns to be on fire (done for all units). Then it sets on fire units standing in blaze. The duration is calculated as for direct hits; if the unit was already on fire, it'll take the maximum value between the new value calculated and the current value affected to the unit on fire. Not sure it is readable but I think you'll sort it out ;-) [[User:Seb76|Seb76]] 10:51, 15 March 2009 (EDT)

== Incendiary in TFTD ==

I read [[Weapons (TFTD)#Phosphor|somewhere]] there are reduced effects underwater (or enhanced effects on land) for TFTD Phosphor rounds. I couldn't find an exact statement of the quantitative difference - does anyone know this? [[User:Spike|Spike]] 14:53, 9 March 2009 (CDT)

:The effects of Incendiary weapons underwater (or Phosphor, as TFTD refers to it) is halved over the UFO equivalent. Incendiary weapons are doubly effective on the surface(Terror Missions) vs underwater, but of the three weapons that can fire Incendiary, two of them(Torpedo Launcher and Hydro-Jet Cannon) can only be reaction fired on land. The Gas Cannon can be fired in eiither location. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:08, 9 March 2009 (CDT)

:: It's clear that the effect underwater is half the effect on land. But does the base level (in USOPaedia / OBDATA) refer to land use or underwater use? [[User:Spike|Spike]] 15:13, 9 March 2009 (CDT)

:As I recall, the base level is on land. The numbers for Phosphor ammo are close to the UFO Incendiary damage numbers, but I know it spreads less underwater. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:15, 9 March 2009 (CDT)

:: Look at the (puny) area effect pattern sizes underwater, that sounds about right. Can anyone confirm this? [[User:Spike|Spike]] 15:40, 9 March 2009 (CDT)

There is actually no difference between the pattern for the Gas Cannon's P rounds underwater as on land. Both have a r=3, d=7 pattern. (CE version at least). Maybe the pattern is smaller the deeper you go? --[[User:Zombie|Zombie]] 16:45, 9 March 2009 (CDT)

<gallery widths="200">
Image:GC-P (underwater).png|Flame pattern from Gas Cannon Phosphorous rounds underwater.
Image:GC-P (on land).png|Flame pattern from Gas Cannon Phosphorous rounds on land.
</gallery>

:OK now I'm really confused then! (I realise I was getting confused with the Dye grenade's small footprint vs Smoke grenades). If the blast pattern is the same size, that implies the weapon power is unchanged. So in what sense is Phosphorus "half as powerful" underwater? Does it burn half as long? Is the impact and fire damage halved? [[User:Spike|Spike]] 16:49, 9 March 2009 (CDT)

I really doubt the damage to units would be affected if the power of the round was modified. The power of the round only determines the size of the pattern produced, not the damage inflicted to units. I'll have to check the burn times and spread rate but my thought is that the two are identical in the version I'm using. Like I said, the pattern may get smaller the deeper you go underwater. The pic above was for a shallow site. It'll take a while for me to find a deeper site to check it out, otherwise some editing of the game files may be necessary to force the scenario.

I just checked the Dye Grenade underwater and on land. Both produce the same r=1, d=3 pattern. So yeah, they are really pitiful when compared to the Smoke Grenade.

Don't really go for the use of "impact" damage with Incendiary/Phosphorous rounds. There is no real impact since the damage range is discontinuous. The unit either catches fire from the splash of fire (in which case it does 5-10 damage points), or the unit doesn't catch fire and the unit remains unharmed. If there were such a thing as impact damage, the range would be continuous like normal weapons, in this theoretical case it would be [0-10] inclusive (ie the set [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. --[[User:Zombie|Zombie]] 17:36, 9 March 2009 (CDT)

Anyway, the half thing came up because AQ was comparing TFTD to UFO, not comparing the effects in TFTD from underwater and on land. However, further comparisons reveal that a hacked HC-I round of 60 produces the same pattern as a GC-P/60 round. Perhaps this whole dilemma can be traced to the Dye Grenade? --[[User:Zombie|Zombie]] 18:28, 9 March 2009 (CDT)

:That's entirely possible the Dye Grenade is the source. However, several of the pages for the TFTD weapons state that Phosphor is far weaker in water, so I didn't check. My mistake. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:35, 9 March 2009 (CDT)

Thanks for the feedback everyone. So this could just be a recycled rumour? I guess the general assumption is that the game engines are identical, so we would want evidence that TFTD is different. Looks like Zombie has proved that the area effect is equal (at least at shallow depths). That leaves only the fire damage or fire duration. Testing that would require repeated observations to check if fire damage is less than 6/hit, less than 6/turn, and burning for no more than 2-3 turns. [[User:Spike|Spike]] 20:14, 9 March 2009 (CDT)

:As with any wiki where contributions can come from anywhere, there are bound to be problems with validity of the statements made. So unless those statements are backed up by real-life test data instead of memory or hearsay, take them with a grain of salt. The other point is to avoid spreading disinformation at all costs (I have been guilty of this as well, but try to at least quantify them). So there you go. I'm still trying to get a deeper underwater mission to check the size of the pattern produced there. Checking the spread of flames or damage inflicted to units shouldn't take too long though. I'll see if I can't get that done tonight yet. --[[User:Zombie|Zombie]] 20:23, 9 March 2009 (CDT)

:Ok, I ran some trials with an unmodified GC-P round on the normal seabed floor against soldiers having 100 health and 0 all-around armor. For the guy standing at GZ, I saw ending health values of 99, 94, 93, 92, 90, and 89 (n=50). So that comes out to 1, 6, 7, 8, 10 and 11 points of damage respectively. I didn't think 11 damage was possible. Here's where things differ though. All the other guys who were clustered around GZ always received only one point of damage, never more, never less. In EU, the guys around GZ took damage equal to the guy at GZ. Odd. So then it occurred to me that perhaps I should check the MCD values of the seabed (TFTD) and the desert (EU) landscapes. Both are basically identical in terms of armor. But the seafloor has a "time to burn" value of 0 while the desert has a value of 1. So maybe our understanding of normal fire isn't totally complete. I'm going to go back to EU and retest the desert landscape with varying MCD burn time flags to see how that affects damage. ;) --[[User:Zombie|Zombie]] 23:00, 9 March 2009 (CDT)

:: The whole Phosphor being half effective under water is related to the burn time and spread, if I remember correctly. The settings in the MCD files may be the culprit. The actual damage dealt or initial spread may not necessarily be affected.

:: Hey, I just had a wacky idea. XComutil. Use its feature where you can set the depth of a mission. Launch a mission on a island terror site map (again, use XComutil's map picker to get to this faster). Lots of grass to burn there. Set fire to it and count how many turns before the fires die out. Redo the test, but this time set the depth to a deeper level. Try the whole process out again.

:: Next repeat this with one of ye-olde seabed maps. They look really weird without the blue palette shift when played on land, what with the landscape being gray.

:: It's possible that the half-effectiveness relates to the fuel that the fire has to burn more than anything else. Further confirmation on how long the flames stick to a target when on land or underwater may be helpful. -[[User:NKF|NKF]] 01:28, 10 March 2009 (CDT)

:I've been burned one too many times using editors or utilities to mess with saved games. Half the time they introduce some unknown "feature" which isn't documented. Thanks, but no thanks. I only test with an unmodified game, except for the changes I make myself to keep control of the situation. Anyway, I tested a patch of fire on the seabed to see how long it remained lit (which has a "time to burn" value of 0). It only stayed lit the current round the shell detonated. After that the fire went out. So this agrees with what is expected. Will continue to work on this as I get time. --[[User:Zombie|Zombie]] 01:51, 10 March 2009 (CDT)

Well, I suppose my recommendation doesn't necessarily need XComutil. It would've certainly made it easier. But yes, it does introduce a few things that work behind the scenes that we might not know too much about. However, if I remember correctly, one of the battlescape savegame files should hold the depth level of the current map you are playing on. All you'll need to do is tweak that to change the depth of the map.

One other thing, the different effect HE has on the same tiles underwater and when on land (ala the Triton) may also be one of the other culprits behind the belief that phosphor is less effective on land. Being able to blow up the Triton on land, but have it appear virtually indestructable when underwater does that. -[[User:NKF|NKF]] 01:59, 10 March 2009 (CDT)

----

re Zombie's underwater tests, there is normally (i.e. on land in EU) a difference between the IC damage on the target of the direct hit, vs lower damage to others in the area of effect (hmm contrary to my IC kill modelling assumptions: uh oh I may've spoken to soon). But only seeing 1 damage on the others in the AoE does seem low. We need to figure out why. Did any of the other targets catch fire? Does that ever happen underwater? Do tiles ever burn past the turn when the IC round is fired? Any of these factors would reduce total fire damage/effectiveness by '''more''' than half. Actually, doesn't it say the 1-12 damage for "in fire" is ''not'' random, but dependent on terrain type? That could be the answer.

The [[Incendiary]] article actually mentions '''4''' modes of fire damage, only 3 of which are quantified:

#"impact",
#"being in fire"
#"being ''on'' fire"

The 4th mode is "damage from burning ''terrain''. Only a tantalising mention is given, no quantitative details. This could be the source of the discrepancy. In fact it might be a component of "being in fire" that's not fully understood. I think Zombie is right to review the assumptions on this one - nice work! [[User:Spike|Spike]] 04:05, 10 March 2009 (CDT)

:As I recall, "damage from burning terrain" is synonymous with "Standing on a tile that's currently on fire." Thus "Being in fire." But that's me and I'm tired this evening, so I could be wrong. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:30, 10 March 2009 (CDT)

I performed my TFTD Phosphorous tests underwater and after the flames died out some of my men did catch fire. So this part seems to jive with that of EU. Tiles do not burn longer than its "time to burn" value in the MCD files. So for instance, in the seabed underwater testing mission, the tiles have a MCD burn value of 0 which corresponds to the results seen (ie fire didn't stick around into the aliens turn or X-COM's next turn either, it only stayed lit the turn it detonated). There really is only 2 "modes" of I/P/fire damage:

<ol><li>The code used for determining if a unit catches fire: 0 damage (if the unit didn't catch and was able to shrug it off) and 5-10 (if the unit catches).</li>
<li>Standing in fire.</li></ol>
At least from the initial tests in TFTD, units outside GZ are just considered to be standing in fire that turn and always take 1pt of damage. Anyway, I don't want to talk myself into a hole without doing more tests. All the following trials I do will be in EU to hopefully curtail any unknowns in TFTD. Once EU's code is figured out then it can be applied and compared to TFTD. --[[User:Zombie|Zombie]] 09:06, 10 March 2009 (CDT)

: If they are "standing in fire", do you think the 1pt damage/turn is based on the fire characteristics tile/terrain type they are standing on? Is it more generally 1-12/turn, dependent on terrain? Also if you get a chance can you test large units and see what kind of effects they take on the GZ+1 squares? If the GZ+1 squares of a large unit are just 'standing in fire' rather than 'catch fire/5-10 impact damage' this will substantially weaken IC vs large units. And I will have shouted too soon! :) [[User:Spike|Spike]] 09:18, 10 March 2009 (CDT)

I did some ad-hoc tests in TFTD. Actually I just ran around firing GC-P and HJ-P rounds everywhere. :) On a typical seabed layout, I found that most things don't burn - the fires don't last into the next turn. The only things I could get to burn were the green moss stuff and and coral skeleton "trees". Even the barrels do not burn. Also, I did not see much sign of terrain damage caused by the fires. But the moss and coral did burn for the normal period, i.e. 1-5 turns.

I also managed to kill an Aquatoid with a single direct hit from a GC-P, in one turn. He died at the end of my turn or the start of his. That seems unlikely. 5-10 from being hit, plus 1-12 for standing in fire, plus maybe another 5-10 from being on fire? It's just about possible I suppose, to max out near 32 damage (if the terrain offers you "12" when it burns). Anyway those are my unsystematic enquiries. I have the 8 save files of various stages of the battle if anyone wants to take a look. It was from a virgin TFTD installation and there was no editing or jiggery pokery.

OK I've uploaded the save files [[Image:TFTD Incendiary Tests 01 Spike.zip]] and taken a look myself with BB's editor. Prior to being hit (Game_4) our Aquatoid was in rude Health, 30/30. Immediately after being hit (Game_2) he was at 19 Health (no Stun damage) and On Fire, as well as Standing in Fire. That implies 11 Damage from the "impact effect" which is not supposed to happen. As noted, at the end of the same turn or beginning of his next turn, he dies. He looks to be standing on a standard seabed square, just sand, the kind of thing that does not burn. He is next to some of the brown cushion-like coral, but I don't think that burns, at least not over multiple turns. In fact in the same turn he is hit, at the end, you can see him dead (Game_3). Since there was only one alien, he died in the same turn. OK that's slightly confusing, maybe someone can double check the turn numbers in the save files (don't know where they are).

[[User:Spike|Spike]] 13:29, 10 March 2009 (CDT)

Doh. I is a idiot. The Aquatoid was killed by the incendiary fire bug - I fired extra IN rounds at terrain objects after he was on fire. Which explains why he is already dead by the end of my turn. [[User:Spike|Spike]] 15:08, 10 March 2009 (CDT)

:Yeah, you gotta watch that. Well, anyhow, I edited the desert landscape in Enemy Unknown to have the same MCD "time to burn" value of 0 as the seafloor in TFTD. From the limited tests, the results look the same as in TFTD. (Fire burns out after the initial turn it detonated, units around GZ taking 1 unit of damage while the guy at GZ got more). So that means I can focus my efforts on EU with little worry because there will be no issues. I'm going use BB's logger and AHK to automate the data gathering aspect to save me a bunch of time. I'll probably need the full requisite 2000 reloads though, as the guy at GZ is not the same as the 24 soldiers around him. Wish me luck. :) --[[User:Zombie|Zombie]] 15:54, 10 March 2009 (CDT)

Good luck! I just read the MCD article, and it mentions 2 fire-related byte fields in MCD - "likelihood of catching fire" as well as "time to burn". Is the last field variable or fixed? Could the first field determine the damage/turn to units when it's on fire? Also with a possible 4 terrain items that could all be burning, is the maximum damage higher than 12? [[User:Spike|Spike]] 16:10, 10 March 2009 (CDT)

:Offset 45 is the flammability rating of the tile. This most likely controls whether an adjacent fire will spread to the tile in question. (For instance, if a fire is burning and the next tile over is a tree or something, it'll probably spread there fast because of the combustibles present). The other byte is offset 57 which is the one we are after. Don't know about the 4 types of things which can exist on a tile at once. I think the most I have ever seen is 2 (usually ground and a wall). Wouldn't hurt to edit a tile to include all 4, but that's an entirely different test to do. It'll have to wait until we get a better understanding of basic fire. ;) --[[User:Zombie|Zombie]] 19:38, 10 March 2009 (CDT)

::Here's a question. On Large units, if only one segment of the Large unit is on fire, will the fire spreading code allow the other three segments to catch on fire? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:13, 10 March 2009 (CDT)

:I highly doubt it. Unit fires are completely different creatures from terrain fires. Needs testing though. --[[User:Zombie|Zombie]] 20:55, 10 March 2009 (CDT)

::Yes it would have to be a very special case, since afaik fires do not spread from regular units on fire to adjacent terrain or to other adjacent regular units. Though it would make more sense than any of those things. [[User:Spike|Spike]] 21:03, 10 March 2009 (CDT)

== Incendiary Bug ==

(Also known as the [[Known_Bugs#Funky_Fire|Funky Fire/Smoke bug]].) I made some suggestion about why this bug happens, and how the code could be patched to fix it: [[User talk:Seb76#Incendiary Bug]]. [[User:Spike|Spike]] 07:13, 12 March 2009 (CDT) Here is the general discussion of the bug:

With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

I also suspect that other "end of turn" processing happens with every IN round fired. I am pretty sure "fire spreading" checks occur, as I have seen fire spread when using perfectly accurate shots. Either "fire spreading" happens, or there is a random element in incendiary area of effect, that is definite. I want to repeat these tests to see if "catch on fire" effects also happen for those who are standing in fire when an IN round is fired. [[User:Spike|Spike]] 08:59, 31 March 2009 (EDT)

== Mwahaha ==

Was exploiting the Elevator Shield trick on an Alien Base Assault, and I had the forethought to pack lots and lots of Incendiaries. My sick sick mind found it amusing to set all those aliens on fire and watch them roast stupidly and helplessly. (Jasonred)

= Fire Damage =
(moved from talk:UFOextender)

Not sure if the bug is already posted. And Not sure if I should post the bug here or in [[Talk:Incendiary]]. Problem is if you use extender to fix funky fire bug. Incendiary no long does any damage at all. Units only take the small amount of damage after ending turn because they're on fire. Using 1.28.3 extender

To test this. I stripped a soldier of armour. And pounded four incendiary rockets into the soldier in the same turn. No damage. And then next turn, his health drops a little because he's standing in fire. This may not be a problem for most players. But it is still a major bug. I understand the funky fire problem is already difficult to fix, and I say thanks to all who will try to help solve this bug. [[User:Hellblade|Hellblade]] 14:44, 28 September 2012 (EDT)

: That's not a bug, that's the fix. Incendiary damage is only applied at the end of the turn. Think about it... does fire kill faster than a bullet? Faster than a grenade? Can you kill someone with fire faster than they can get a shot off back at you? No, to all these things. To compensate for fixing the bug, fire damage is doubled compared to the previous end-of-turn fire damage (that always existed). It is no longer applied per shot or per impact. All you get "per impact" is another chance to set the target unit itself on fire. Incendiary is a weak attack. It has the benefit of a wide area effect, no HE block, and ignores armour. There are situations when IN is the only effective weapon XCOM possesses. But, like everything, it has strengths and weaknesses. [[User:Spike|Spike]] 15:51, 28 September 2012 (EDT)

:: I see your point but let me elaborate. Heat, not fire, do kill as fast as bullets. The original game mechanics separated heat from fire just as in real life. It intended to have the big heat blast damage first and then the small fire damage per turn.
:: Take the most extreme case, napalm or volcanic lava, you get fully cooked in less than a second - just by heat alone, and you may/may not catch fire later on. And heat blasts travel as fast as bullets, in some cases as fast as light. I believe the game has different Incendiary damage values to do different damage according to how strong the heat is, not the fire afterwards. The damage by fire later on makes sense because natural burning fires aren't that hot comparatively.
:: I understand the difficulty in trying to fix this. But before this fix you could kill a reaper by a few AC-I shots (which is their weakness) and now you can empty the two clips at it and it'll never die. [[User:Hellblade|Hellblade]] 03:11, 4 October 2012 (EDT)

== Advantages/Disadvantages of using Incendiary for nighttime light ==

It seems for most folks that electro-flares are the go-to for night lighting and incendiary rounds are a distant afterthought.
With that in mind I propose this list of pros/cons to using incendiary at least as a major complement to flares.

Cons:
Low damage, and for each soldier with incendiary rounds loaded they can't attack with more effective weaponry unless
---- they unload and reload
---- they carry another gun or use 'nades/stun rod
Not re-usable, will always be depleting stock

Pros:
Not dependent on throwing limitations of range and arc/trajectory
Very efficient in terms of light-output per weight, storage space, and time units
Can set area on fire to illuminate where the enemy is initially, then as the fire burns out you may move into the cover of the smoke it generates
Does at least some damage to enemies - very unlikely to kill them, but softens them up so future attacks more likely to neutralize
Area denial - fill a small building or enemy craft and watch them flee out into your reaction fire, or at least out where you can get them, they don't get the drop on you
At least in OpenXCom the enemies on fire should provide lighting, helping to spot them at a distance
Fire is less vulnerable to being destroyed by nearby explosions, unlike those wimpy flares. And even if it is snuffed, it isn't something you were counting on re-using
Reaper vulnerability
Zombies not re-spawning to 'lids when KO'd by fire splash
You can dedicate a few number of soldiers to throwing fire around while the rest keep their hands and TU's free to attack
Soldiers that go berserk/get MC'd can't hurt armored soldiers w IC fire

Now it seems to me that the first Con is major and obvious, but the many Pros are overlooked. Also that big Con could be greatly mitigated by cannon wielders w incendiary carrying a decent secondary weapon: thinking plasma rifle or pistol, laser pistol

any I'm missing? what about putting this on the main page?

Talk:Known Bugs

2021-06-15T22:05:54Z

Mugwump: /* Direct incendiary hit causing no reaction fire? */

= Classification etc =

== Bugs vs Exploits ==

Could someone comment please on the distinction between a bug and an exploit, and where to put each one? I would guess that a bug is something that undesirable and an exploit "might be" desirable, if you want to cheat. But what about exploits that happen by accident, or bugs that need to be forced to happen?

I was going to add the Research Rollover bug to the Exploits sections, but they seem to all be under construction. What's the agreed approach?

[[User:Spike|Spike]] 04:16, 15 March 2008 (PDT)

* i think that an exploit is somthing you can trigger and gain an advantage from. a bug may or may not have a known trigger, and does not give an advantage if it does.
: All exploits are bugs, either in implementation or design. When using a bug to gain advantages that bug is used as an exploit (you are exploiting the bug). [[User:FrederikHertzum|FrederikHertzum]] 13:39, 10 May 2011 (EDT)

:: IMHO, Laser Pistols Gifts to train reactions is an exploit, but it does not involve any bugs. It merely exploits the fact that laser pistols will not penetrate the front armor of Flying Suits. [[User:Jasonred|Jasonred]] 16:31, 10 May 2011 (EDT)

::: I guess the point is to differentiate if it's a bug that's being exploited to your advantage, or it it's something confined within the game mechanics that you are exploiting to your advantage (even if using it as intended). -[[User:NKF|NKF]] 02:31, 11 May 2011 (EDT)

:::: Another definition: An exploit is
::::: a) a move allowed by game interface
::::: b) that sidesteps another part of the game mechanics
::::: c) and creates inadequate advantage for the moving player in the process.
::::: An exploit is not a bug, but it can be connected with a bug, if the latter allows a move mentioned in a). Most obvious exploits render whole parts of game mechanics obsolete (see b) above), because they are always more advantageous. In games that feature equal terms for AI and the player, an exploit can be discerned simply by the fact that AI does not use it (sadly this is not true in X-COM). Clear exploit in X-COM: Transfer soldiers = no monthly payment. Suspect exploits: grenade layout. Most probably not an exploit: Sniping (although the inequality with AI is suspect). Clearly not an exploit: dropping weapons to prevent Psi mass murder (this one is made exploitable by the AI unable to pick up weapons, but is not an exploit per se).--[[User:Kyrub|kyrub]] 05:30, 11 May 2011 (EDT)

The dropping weapons sort of turns into an exploit if you do the "everyone suspect of being a psi weakling drops their weapons at the end of the turn. They all pick up their weapons again if unpsied in the next turn." The grenade layout or grenade hot potato is probably not what the game designers had in mind, but I shudder at the thought of someone who only played X-com then joined the army pulling the pin out of his grenade and then dropping it into his haversack or slinging it on his belt. [[User:Jasonred|Jasonred]] 07:43, 11 May 2011 (EDT)

: Yeah, I think we agreed somewhere that shoving live grenades in your pockets and not having them go off is madness. The relay however is not sensible but certainly possible if only a very short one (if with a live grenade), or to toss a grenade forward and prime it at the second to last person. Or more reasonably, something like a stick of dynamite with an extra long fuse. Even that's very dangerous.

: By the way, what does everyone here think of using the mind probe to check if it's safe to attack an alien while standing in full view of it, or if you're right up next to it? I've been using it a lot lately (in lieu of the psi amp), so you could say I've been exploiting the mind probe to my advantage to help me with my decision making. But is that counted as a cheat since I'm picking my moments to attack up close when the enemy cannot return fire? -[[User:NKF|NKF]] 03:30, 12 May 2011 (EDT)

:: When identifying a mechanic as an "unfair exploit" (as opposed to just a "tactic"), perhaps a simpler checklist is this (though Kyrub's is spot-on):

:: a) Is this something the developers should've expected players to do?
:: b) Is this something the developers could've easily prevented?

:: If the answer to both is "yes", then it seems fair game to me. For eg, sniping at aliens: The game KNOWS whether the soldier can see the target (you get a flashing indicator if so), and so it would've been trivial to prevent it. Is it something the regular gamer will try? Certainly; therefore it can be considered expected behaviour. Ditto for using the Mind Probe to make attacks without fear of reaction fire; those things aren't cheap, they sell for a bunch, so it stands to reason that they'd have tactical value!

:: Things like the transfer bug are clear exploits. The devs would've implemented that system so that, if you order personal near the end of the month, you don't end up paying for them twice before they ever arrive - but in the process, they forgot that "purchase" transfers are treated in the same way as "between-base" transfers. To fix one scenario without breaking the other, they'd've needed to code in some extra stuff so the game could tell the difference - they probably just figured the regular gamer would never notice, assuming they ever realised the problem existed.

:: The "dropping weapons" thing is a little trickier to work out - yes, the devs should've seen it coming, but would it've been easy to fix? Aliens could've been twigged to either ignore un-armed soldiers... but those soldiers could re-equip next turn. Aliens could also've been twigged to attack randomly... but that would make their psi powers far LESS effective! I suppose the fix, if any, would've been unarmed melee attacks, but the implementation they went with seems to be the next best thing IMO.

:: In regards to the "grenades in inventory" thing, it's probably common knowledge by now, but they DO go off in the alpha of the game. Presumably someone made a conscious decision to change that, though it could still just be an accidental bug. - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 09:02, 12 May 2011 (EDT)

Sniping at aliens is a very bizarre case, since almost all players will fall prey to the aliens sniping at you long before they snipe the aliens. The behaviour of the aliens to step within sight radius, take one step back, then fire without fear of retaliation *looks* and *feels* like clear exploitation of the rules, but the computer can't be a cheater, can it? So we humans carry that one step further. Mind you, I think X-com would be in trouble if the aliens could snipe you from across the map once they know your positions... especially since the aliens have cheating "if I spot 1 human, I spot ALL of them" abilities. Especially on maps where the aliens get Blaster Bombs...

An interesting note about sniping and LOS: When I first played Xcom, my first mission was in the jungle. Because of all those plants, when my first soldiers spotted an alien, after he shot at him, I tried to make my 2nd soldier open fire and was informed "NO Line of Fire". I could only get my 2nd soldier to fire by positioning him in such a way that I got the flashing number. Henceforth, I assumed that you could ONLY fire at the aliens when the flashing number was there. LOL. LOF. LOS.

Transfer bug wise, I thought that the devs merely programmed the game to count how many staff were currently in the base, then deduct that from Xcom coffers? As far as ordering personnel near month end goes, you end up paying salary for them if you order them more than 48 hours from month end, right? "realistically", they should make staff draw salaries based on when they were hired, but this would be too much effort.

"dropping weapons" would have been easy enough to fix... just teach alien AI how to pick up weapons. Like they did in Apocalypse.

As far as grenade relays go, if you ever join the army, and you toss a live grenade at your squadmate, you're gonna be court martialled! lol. Xcom grenades are weird cause they presumably come with a computer console where you program them or something that takes a lot of TU, if I already have a grenade in my hand I don't think it takes long to prime it compared to throwing it...

Pretty clear exploit/bug is tossing grenades through the ceiling? That breaks all laws of realism/logic/whatever, and I'm sure the devs didn't plan for THAT to happen! [[User:Jasonred|Jasonred]] 18:18, 12 May 2011 (EDT)

: Turns out the "spot one, spot all" thing was wrong all these years. However, units can be "spotted" by sniping an alien, hitting it, but failing to outright kill it; this may have contributed to the misconception.

: The game considers the base to have the correct amount of personal as soon as you initiate a transfer - if a base has room for ten people, you can't send two groups of ten, as soon as the first is in transit the game will correctly recognise that the destination is now filled up and won't allow you to send any more. Likewise, if you hire soldiers, they'll count towards the allowance of more promotions in your ranks before they ever arrive at a base. That is to say, the payment system deals with personal counts in a different way to every other system in the game, making it look like it's intentional (if badly exploitable) behaviour. In terms of transit times, those seem to vary, I know a purchase of scientists takes 72 hours to arrive.

: Er, yes, getting aliens to pick up weapons would've indeed fixed the dropping thing. Shoulda thought of that...

: The grenade thing is indeed unrealistic however you look at it. Certainly throwing the things through ceilings is a bug, and its use is a large exploit. - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 20:02, 12 May 2011 (EDT)

:: Then how do the aliens "spot" the psi weakling to target him for psi attacks? Doesn't the game ALWAYS start blasting the juiciest target, regardless of LOS? Or is it just coincidence? [[User:Jasonred|Jasonred]] 22:22, 12 May 2011 (EDT)

::: They really have to "[[UNITPOS.DAT#8|spot]]" the target before they can blast them (however, it appears that later in a campaign this rule gets broken). If they've only spotted a psi-''resistant'' trooper, they typically won't bother to make attacks at all. There's a lot of relevant information in [http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html this thread]. - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 23:28, 12 May 2011 (EDT)

: Your talking about your post on http://www.strategycore.co.uk/forums/Can-alien-attempt-Mind-control-Pani-t8115.html&pid=96123&mode=threaded#entry96123 ? Well, I'd just like to point out a massive flaw in your testing logic. You forgot that aliens will launch psi attacks based on chance of success, and chance of success varies based on distance from aliens. In other words, it could easily be that the aliens only attempted psi when your soldier was within sight of them because your soldier was now NEAR to them and therefore they had a strong chance of success.

: Also, as you have noted, it appears that your rule gets broken. In fact, it is not uncommon at all for the Ethereal Commander who is boxed up in the Command Center to launch psi attacks on victims who are separated from him by several layers of walls, as long as their proximity to him is near enough. [[User:Jasonred|Jasonred]] 21:19, 13 May 2011 (EDT)

:: Those are valid points. I've hence built a somewhat more robust testing scenario, which you may wish to [[:Image:Alien Psi Demonstration 1.rar|try for yourself]].

:: The save game consists of cloned Ethereal soldiers (all cranked up to 100 psi strength/skill), and many clones of a single trooper (most of whom have the same psi values). The Ethereals are all cooped up in a sealed room in the SW of the map, with a single trooper who has 140 psi strength/skill.

:: Directly outside the building is another trooper who only has 1 strength/skill. In the NE of the map, in another sealed room, is a soldier with 40 strength/skill. Before placing him there, I had him shoot one of the Ethereals just once, resetting index 8 of his UnitPos record to 0. Only he and the trooper inside the room with the Ethereals have hence been "exposed" to the aliens, but the "best chance of success" is obviously the psi-weakling directly outside the building.

:: If you load the map and end turn, the aliens will first attempt to take control of the dude on the other side of the map, then get to work on the guy in the room with them. Once they've taken these two, they'll completely ignore all other units.

:: In short, aliens can't use psi attacks on a unit UNLESS their UnitPos[8] index is set to less then that of the alien's intelligence stat. - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 05:41, 14 May 2011 (EDT)

::: Good one. That test definitely proves a lot, rather conclusively. [[User:Jasonred|Jasonred]] 06:53, 14 May 2011 (EDT)

== Bugs vs Limits ==

''(Discussion continued from [[Talk:Known Bugs#Soldier Recruiting Bugs Tested|Soldier Recruiting Bugs Tested]])''

The "Soldier Recruiting Limit" is <b>not</b> a bug, it is a limitation of the game. Therefore, this should be removed from the page. If we want it somewhere else (like a new page such as [[Game Limitations]]), that would be appropriate. --[[User:Zombie|Zombie]] 01:42, 9 November 2008 (CST)

::Not sure that's necessarily the best idea, Zombie, since many of the entries on the Known Bugs article(as well as some entries on the Exploits pages) are limitations of the game engine. On just a brief glance through, the following caught my eye as engine limitations: Manufacturing limit, Storage limit, Purchase limit, 80-item limit, Proximity Grenade limit, Large units not waking up from stun, Interception last shot bug, Alien UFL radar blitz-through bug(Passing through the detection range of a radar before the detection check comes up), Free manufacturing, free wages, UFO Redux, point-scoring with Ctrl-C, permanent MC of chryssalids, Zombie-MC resurrection of agents, alien inventory exploits, anything involved with bad collision detection, extinguishing fire with a Smoke Grenade, and even your personal favorite, denying the aliens access to their own spawn points. So in conclusion, maybe it should just be left as it is; conversely, all of these entries could be kept where they are and also on a Game Limitations page, or we could leave the headers there and link them over to the appropriate topics on Game Limitations. What do you think? [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:21, 9 November 2008 (CST)

: I agree with AQ (great list of examples by the way - and the Smoke/Fire limit would be another). Many, if not most, of the bugs are "Limitations" but they are logically inconsistent and not what a player would expect to happen: they are imposed by (at best) memory limitations or (at worst) design/programming oversights. I think the easiest thing to do would be to change the title of the page to Known Bugs and Limitations, or put an explanatory note at the beginning of the section to explain that "Bugs" is taken to included "Limitations". [[User:Spike|Spike]] 13:16, 9 November 2008 (CST)

By the strictest sense of meaning, a "bug" is a mistake or error on the programmers part. Limitations imposed <i>by design</i> or memory are not the same creature as the people involved were consciously aware of the decision. I suppose that to the normal player, any type of behavior which is unexpected/unwanted is automatically dumped in the bug category because to them there is no difference. To those of us who study the game files however, the two are unequivalent. Programming oversights, yes, those are bugs.

Some of those limitations AQ mentions are (to me at least) bugs: free manufacturing, free wages, permanent MC of Cryssies (or actually any alien for that matter), Zombie resurrections and collision detection. Large aliens not waking up from stun is again, a bug. The programmers obviously had some issues when dealing with large units in general and never quite got it right. They made some progress in TFTD by trying to fix mind controlling each section of a large unit, but royally screwed it up by selecting the next 3 entries in UNITPOS.DAT no matter what they pointed to.

Perhaps it's just my background in logic which makes me want to push for a separate category for limitations. Then again, as long as everything is listed somewhere I'm happy. --[[User:Zombie|Zombie]] 22:06, 9 November 2008 (CST)

: Actually, taking a look through the page as a whole there are various other Limits described, and the distinction between Bugs and Limits is made quite rigorously throughout - not just in the Soldier Limits and Bugs section, where the Soldier Recruiting Limit is referred to as a Limit whereas other bugs (such as paying salaries for soldiers you can't recruit) are referred to as Bugs. So we maybe just need to rename the pages "Bugs and Limits" and add an explanatory note on the distinction. From a user point of view, rather than a programmer point of view, a bug is an unexpected (inconsistent or illogical) behaviour, so for that reason I think it makes sense to keep them on the same page but try to ensure they are all correctly classified as Bug or Limit.

: By the way, it could be hard to absolutely distinguish Bugs from Limits as I suspect there are going to be some grey areas where you would have to second-guess the intentions and decisions of the coders to know for sure if something was a designed-in Limit, or just an oversight (Bug). [[User:Spike|Spike]] 06:50, 10 November 2008 (CST)

::If we distinguish in this manner, I suggest the definition of "Limit" should be, "Something imposed by the game files or engine as a limitation, most likely in context to the capabilites of the then-current personal computer." More succinctly, anything that was done to allow the game to run acceptably on what was then a PC. This would include both the Soldier and 80-Item limits, the spawn limit(40 units per side), Smoke/Fire limit, and some of the others listed. (The Purchase limit was probably more of a convienence for the programmers than anything, but it is clearly an intended feature.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:11, 10 November 2008 (CST)

: I would add to this that sometimes a Limit may be imposed as a game design / gameplay decision, rather than in order to conserve a constrained resource in the platform (=PC). Also, I would suggest that ''intended'' Limits are Limits, but ''unintended'' consequences of Limits are Bugs. Obviously, making this distinction involves some guesswork. But I would guess that while the limit on total smoke/fire hexes was an intended Limit (to conserve PC resources), the ability to put out fires with smoke grenades and disperse smoke with IC rounds is probably an unintended consequence of the Limit, and so should probably be considered a Bug. Similarly, Base Defence spawn points are probably an intended limit, but the ability to flood spawn points is an unintended consequence of this, and thus a Bug (and an Exploit). (Spawn points should have been shared out 50/50, not humans-first). [[User:Spike|Spike]] 12:07, 11 November 2008 (CST)

::The limit on Soldier and Interception craft were probably more of a limit imposed because they capped the file and figured that X-COM wouldn't ever need more than 40 interception craft or 250 soldiers. (And I've never needed that many, case in point.)

::As for spawns, its actually difficult to take advantage of it in any reasonably established base. X-COM can spawn up to 40 soldiers in a base defense mission(tanks count as 4 soldiers), as a limit of LOC.DAT. Aliens have the same limit. So in order to take advantage of the bug, the base needs 40 or less spawns total. The Access Lift has 8 spawn points, General Stores(weapon-handling) has 11, Living Quarters has 8 more. This is 27 Spawns just getting soldiers in a base and armed. (Although the General Stores can be cut out if you perform the bug properly). Large Radar and HWD have 6 spawns(Small Radar has 2), and Hangar has 15. So overall, the "Spawn prevention" can be hard to take advantage of with all but the smallest bases. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:48, 11 November 2008 (CST)

Just to clarify, X-COM interception craft are not capped at 40 ships. LOC.DAT has a cap of 50 "things" on the geoscape screen at a time. This is shared between X-COM bases, X-COM ships, alien bases, seen or unseen UFO's, terror sites, crash sites, landing sites and waypoints. In a perfect game world with little alien activity and normally constructed bases, the max number of X-COM craft possible is 44: 5 bases with 8 hangars each plus one base with 4 hangars (or any combination thereof). If you illegally modify your base layout with an editor to get rid of the access lift, the max can be increased to 45 ships (9 hangars in 5 bases). Once clogged, all alien activity will cease.

The base defense limit of 40 units exists because of UNITPOS.DAT which has a cap of 80 entries total (tanks occupy 4 entries in this file). Auto-win missions in a base defense mission by clogging all the spawn points with X-COM units isn't as tough as it sounds, especially if your base is small or doesn't contain hangars. The main thing is getting your full quota of 40 units to spawn (meaning you should try not to have any tanks as they count as 4 units but only occupy one spawn point). This limits the base size to something like 5-6 modules depending on what you build. Still, even having more than 6 modules isn't bad as it forces aliens to spawn intermingled between your troops. With 40 armed guys staring in every direction, you can get positions of all the aliens in the first round and possibly even kill them all (depends on weapons and alien race of course). --[[User:Zombie|Zombie]] 20:12, 11 November 2008 (CST)

: I would say that Limits are the CAUSE of bugs... also, I feel that fire/smoke limit can be called a bug, because a player normally has no way to tell this, other than observation. Whereas the game DIRECTLY and CLEARLY informs you whenever you hit the 80 item or 250 soldier limits, which is more fair. [[User:Jasonred|Jasonred]] 15:22, 23 March 2009 (EDT)

Also IMHO it is not true that, say, 250-soldiers limit is a real game bug. In fact, it is not, it is just a rule of the game, or its limitation. And it is unimportant what its reason is (such or another way to store game data).

A bug is, by definition, an unexpected and involuntary result of programmers' work. However, we can only guess what the programmers wanted to attain, so this definition is both unpractical and impossible to be applied. It would be better to assume that a bug is a feature which has negative influence in the game. To clarify: the (un)famous 250-soldiers limitation does not harm in practice, as the number is really enough to play the game. But the even-more-unfamous 80-item limitation does harm and it has negative consequences - it is enough to recall the disappearing of bodies during some missions.

OK, there is no objective criteria to judge whether a feature of the game is a bug or just a limitation. But sometimes subjective criteria have to be enough. Otherwise, we would have to consider the 8-bases limit a bug. Does it make any sense? And if no, what is the difference between the 8-bases limit and the 250-soldiers limit? I feel neither is a bug. Because neither leads to further negative consequences.

And further, IMHO the buggy nature of some game features is quite obvious. If you cannot send more than 100 "parcels" of items at the same time, it is still not the bug. But if you must pay for an item you are trying to send but you cannot do it - it is a bug, perhaps everybody will agree. And similarly: the 255-scientists limitation is not a bug. But the strange behaviour of the game when you bought the 256th scientist is a bug. It would be just a limitation if the game did not allow to buy another scientist. But it allows while it cannot serve the 256th scientist properly, and that is why it is a bug.

So, I vote for removing the 250-soldiers limit from the bug list. If I am wrong in it, please add to the list also:
# 8-bases limit,
# maps with limited terrain (why should they be limited?),
# base area and base facilities limit (why wouldn't we be able to have 10 hangars in a base?),
# etc.

In yet other words, in my opinion it is not enough to show that the game does not allow to have more certain items or to do more certain actions. In order to count this among bugs, we should show that it really harms during playing the game, or just bears negative consequences.

[[User:Sherlock|Sherlock]] 03:52, 27 December 2012 (EST)

= Specific Bug Discussions =

== Misc Technical Bug ? ==

''(The context of this discussion seems to have been lost)''

This is a technical bug that doesn't happen to everyone and one this article wasn't really meant to chronical - but we won't turn away helping a fellow player if it can't be helped. It's just that there are so many random crash points in this game that it would take far too long to find them all or come up with solutions for them.

Certainly, the transfer crash can happen to some players, but it's not one that can be reproduced easily. It's just like the random crash that some players get when they research a floater medic. It crashes the game for some of us, but others don't seem to notice it at all.

It really depends on your hardware and OS setup, whether or not your copy of the game is damaged or your savegame is damaged, etc.

Does it happen in all games or just this one savegame?

- [[User:NKF|NKF]]

-----

== "Invisible Muton" bug ==

Upon shooting repeatedly a Muton, it sometimes plays its "death" animation without sound (as if falling unconscious) and it is no longer displayed in the screen, while remaining visible to my soldiers (I can center the screen and the cursor appears yellow over them). Under this state, they cannot be targeted by Stun Rods. They may play their death animation anytime they get shot, until they truly die, when they emit their characteristic sound and leave a corpse (along with any items carried).

I'm quite fond of laser weapons, maybe this happens more often with those.

Also, though I remember experiencing this quite often fighting Mutons, it may happen to any other high health race.--[[User:Trotsky|Trotsky]] 02:59, 2 July 2006 (PDT)

-----

Never seen that one myself. Another "unpatched game" thing maybe?

There's a (very rare) bug that allows your soldiers to live if they become stunned by an explosion that happens to kill them. Sometimes the game will register their death, and THEN register that they've been stunned. In every case I've seen this happen, however, the unit will have such a low amount of health that a single fatal wound will render it dead (again) on the next turn. I have a vague memory that other players may have been able to get a medkit to the scene on time...

I dunno if that's related to your issue at all (I doubt it, but... meh). I'd advise using a Mind Probe on the alien the next time it happens so you can check the aliens stun/health levels.

- [[User:Bomb_Bloke|Bomb Bloke]]

----

I'm pretty sure I've seen this with Mutons. Possibly Chrysallids as well, another high health, high armor creature. They were still readily killed by shooting the place they are. Good thought on the MP, BB

---[[User:MikeTheRed|MikeTheRed]] 08:51, 2 July 2006 (PDT)

----

I've been known to have a dying muton(in fire) to spin around and then switch to the female civilian death animation. With the scream and everything. Even got a civilian death registered at the end of the mission. And this didn't just happen once, but on another separate occasion.

Hmm. shape-shifting reptilians in the game! LOL! Happens alot [[User:EsTeR|EsTeR]]

Unusually enough, I once had a sectopod die and then drop a tank corpse. I was using the Lightning at the time for my troop carrier, so you can imagine my surprise.

Then there was one occasion where a floater dropped a snakeman corpse. Let's not even get into the sort of things the aliens like to stuff themselves with.

Your invisible alien bug is quite common, although there appears to be many causes for it. I think one involves a full object table when it comes to invisible aliens in bases. But it can also happen in ordinary missions as well. I'm guessing the game may have tried to do something in the wrong order, and sprite information for the unit may have been lost or corrupted along the way.

Having had an experience where all the chryssalids become invisible in one base defence mission was quite a shocker. I fixed this by saving the game, quitting and then restarting the game. If you ever get an invisible alien again, try this and see if it helps. If it doesn't, well, just keep a careful watch on your map and any alerts that pop up as you play.

There's a similar but less severe bug where a dead alien will still leave its centre-on-unit alert button, but this goes away shortly after you move or turn.

- [[User:NKF|NKF]]

----

That last bug happens when exploding Cyberdiscs kill nearby Sectoids, doesn't it?--[[User:Trotsky|Trotsky]] 23:56, 2 July 2006 (PDT)

----

This is a pretty easy one. I guess this bug occured on UFO recovery on a battleship, an alien base assault or a base defense mission? As soon as there are too many items on the map, the game saves some item slots for the equipment to be displayed (since it is more valuable and more important to research). This would also make stun weapons lethal if the stunned aliens would vanish. therefore the game has a failsafe if an alien is stunned (or badly wounded and becoming uncontious). The downed alien's stun level is set exactly on its left health points therefore resurrecting it instantly. This cycle is broken when the alien is finally killed. This means if you want to stun an alien in such a situation you have to destroy some items first.

- by tequilachef (April 4th 2007)

== Vanishing snakemen ==

I've known snakemen to become invisible when standing on a hay bale. On the first occassion I had a poor tank getting shot while spending numerous turns looking for it. On the second occasion I had an alien under Psi-control, left it on the hay bale, and couldn't find it next turn. - Egor

---

This is not limited to snakemen. Hay bale block visibility quite much when a unit is standing on it. Two possible solutions:
- Destroy the hay before entering
- Shoot at the hay. If it is destroyed any unit on it will become visible (as long as no other bales are blocking the line of sight). You might also hit the enemy directly.

I Dnt know if the aliens are affected by this diminished sight, too. My guess would be no.

- By tequilachef (April 4th, 2007)

== Blaster Bomb Bug ==

I'm currently playing through X-com UFO Defense, I have the collectors edition version. I'm in the process of trying to catch a live alien commander and the blaster bomb bug is making this very difficult. If i remember correctly a commander is always in the command center of the the alien bases. The problem is anytime i get close there is always a dude with a blaster launcher up there that tries to kill my troops. When they try to fire it down at me the bug kicks in and they blow up the whole command room and all the aliens in it because they can't figure out how to get the blaster bomb down the grav lift thing in there. This is making it very dificult to actually catch a live commander. Anyone have any ideas for tactics or anything to breach that room without the aliens trying to fire a blaster launcher up there? - eL Hector

: I can suggest two possible solutions. The first is to wait outside the command room for the alien to move closer to you. If it comes out of the room or if you know it has moved down the lift, you then burst in and stand right next to it to stop it from firing the blaster. This is risky because there could very well be a heavy plasma toting alien in there. The other is to use a small launcher and launch it up at the ceiling near where you think the alien with the blaster is standing. -[[User:NKF|NKF]]

== Disappearing Ammunition ==

I have observed that problem with X-COM 1.2, modded with XCOMUTIL. My stun bombs and heavy rocket missiles, along with clips for the auto cannon went missing.
[[User:Vagabond|Vagabond]]

------

Just run a test using my 1.4 DOS version with XComUtil but my stun bombs didn't disappear: 30 + 1 back in the base they came from, same number after I went tactical and I dusted-off immediately. Are you running XComUtil with Runxcom.bat or did you simply run Xcusetup?

[[User:Hobbes|Hobbes]] 22:12, 22 February 2007 (PST)

:Is it a case of hitting the 80-item limit?--[[User:Ethereal Cereal|Ethereal Cereal]] 12:28, 23 February 2007 (PST)

------
With runxcomw.bat, as everytime. Apologies, I retested and it seems like I was mistakened, but I could have sworn that I lost them dang stunbombs. Had to manufacture some. I will test some more, using four heavy weapons and seeing whether their ammunition disappears at all. Thanks. [[User:Vagabond|Vagabond]]

==MC at end = MIA?==

I am sure I have seen this again recently, where I won a mission with no casualties (I thought), but the last thing I killed was a Commander that had been chain MC'ing a psi-attack-magnet trooper, and that trooper was listed as MIA at the end (presumably because he was on the enemy side at the end of combat). Is this a bug, or is there another way to get MIA's on a completed mission that I might have missed?

Since then I have been waiting for the leaders to panic at the end before killing them (or waiting for a rare resist), so I can safely exit, but am I being overcautious?

--[[User:Sfnhltb|Sfnhltb]] 13:45, 27 February 2007 (PST)

If the trooper was mind controlled on the turn you killed the last alien it will be listed as MIA. No bug there :)

[[User:Hobbes|Hobbes]] 18:16, 1 March 2007 (PST)

Huh, why would that happen - your soldier should recover the very next round, why would he go MIA?

--[[User:Sfnhltb|Sfnhltb]] 18:20, 1 March 2007 (PST)

Doesn't make sense to me as well but that's how the game works.

[[User:Hobbes|Hobbes]] 15:05, 2 March 2007 (PST)

----

It seems that regaining control of units under enemy mind control works different for alien and human players. My guess: aliens under human MC are reverted to alien control AFTER THE ALIEN AND BEFORE THE HUMAN TURN while human units under alien control are reverted RIGHT AT THE BEGINNING OF THE HUMAN TURN. This explains three different phenomenons:

- The discussed MIA "bug" (he unit would be returned in the next human turn, but since it never starts it is lost. The mission is still won since no unit with a "genuine alien" marking is left)

- The fact that a mission is lost when the last human falls under MC while it is not won when this happens to the last standing alien (the aliens get their unit back before their turn starts and therefore have a unit left to pass the "anyone alive?" check, the humans would have no unit left to start a turn with. They WOULD have as soon as the turn starts, but no unit left before turn means bust)

- The fact that aliens still can see all an MCed human saw at the end of the human turn that follows the MC while this is not vice versa (The MCed human can give information to the alien side before reverted while an MCed alien is reverted too early). The result is that aliens can control a human indefinitely without having any alien seeing him until the MC is disrupted for one turn.

All confused? Then I did a good job! No seriously, this must be the explanation, I couldn't think of any other way.

- By tequilachef (April 4th, 2007)

: You're absolutely correct on the first two points. It's a sequence issue - you never get round to recovering the unit before the new turn starts, so you end without any units whatsoever. Makes senses too since the aliens would continue to continue to mind control that same unit over and over indefinitely.

: The third point however: The aliens don't need to know the location of the last MC'd unit. They know the location of all your troops whether they've seen them or not from the very start. They appear to give you a few turns of grace where they won't attack you outright (unless, from my observation, all your soldiers are incredibly weak). This is evident because all of the aliens will eventually make their way towards the nearest soldier even though their movement pattern may seem semi-random. Also, they know where you are because they can initiate psionic attacks without having seen any of your troops. They generally go after the weakest troops first.

: Just to add a semi-related point, but from the alien's perspective. If an MC'd alien unit is in the exits when you abort the mission, this alien is not recovered and in fact simply vanishes. Any equipment it was carrying is recovered, unknown artefacts or otherwise. You could possibly think of this as their version of MIA. However, the aliens differ ever so slightly in that if it's the last alien standing and under temporary mind control by the player, the mission doesn't end straight away. But I guess this is only because the player has everything under control, whereas in the other scenario, the Ai is in control.

: -[[User:NKF|NKF]]

My observations show that, at least in some versions of the game (tested with clean DOS 1.4 version, under DOSBox), the game crashes at the end of the human turn if all alien units which are still alive, are Mind-Controlled. If it was confirmed, it would be another not-listed-yet (serious) bug.

[[User:Sherlock|Sherlock]] 17:52, 26 December 2012 (EST)

== Crash Site in the atlantic ocean ==

That's right, my game generated a crash site on water. Here are the details:

- Crash Site a bit southeast of the USA (which was infiltrated a few days before by sectoids, resulting base had already been taken out), but certainly not on land.

- UFO: battleship, floater, alien harvest

- Geoscape: 8 X-Com Bases, 1 (known) Alien base, 2 other crash sites, 1 other (known) flying UFO (though almost worldwide decoder coverage), 3 X-Com Crafts out, 1 waypoint

- Date: January 2000

- Most Interesting: The Craft that downed the ship was a recently finished Firestorm (first human-alien hybrid craft I had built, I know this is lame for that date. Limited myself on 25 Scientists to improve the challenge) equipped with twin plasma. I had it built and equipped in Antarctica and then transferred to Europe. This base had no Elerium, a fact that enabled me to use the infinite fuel exploit which was in effect when downing the UFO. My craft was only slightly damaged when doing so. The battleship was the first target assigned to the craft, it came directly from my base.

- When shot down, the UFO was not targetted by any other craft.

- I had not lost or sold a single craft to that point.

- When sending a squad to the crash site the game didn't crash but generated a farm land ground combat terrain.

- I was not able to reproduce the bug from the savegame dated 2 hours before downing the UFO

Well guys, any intelligent guesses? I still have the savegames (before and after downing)! If you want to have a look, write here.

- By tequilachef (April 5th 2007)
----
: Well I'm sure you know about crash sites that are near land can sometimes actually be on water, so I'm going to assume that this site is well far away from any land mass. Could it be a weird entry in GEODATA\WORLD.DAT that has a land mass out in the ocean? Also are you sure the game didn't crash? Sometimes when it does it will load the previous mission (and usually 90% are at farm terrain). Are you sure it generated a new map and not load the last one?
:No real guesses but maybe some starting points to look at. I've probably stated some obvious situations you know about and have accounted for, but it never hurts to double check :D
- [[User:Pi Masta|Pi Masta]] 14:23, 5 April 2007 (PDT)

== Inconsistencies in MCing Cyberdiscs and Sectopods ==

I experienced, that when MCing one quadrant of a large terror unit any action it does only affects this quadrant (especially use of time units). That means, when TUs are up for one part, MC another one and continue firing. This however does not work out when moving the unit while it is not under complete control. The TUs used up by the resulting reaction fire from the rest of the unit is also deducted from the TUs "your" part has left (making it impossible for the controlled parts to return fire). This however only happens under reaction fire, not if "your" part fires on it's own. I don't know if this comes up when uncontrolled parts shoot by themselves in the alien turn, since this is hard to find out.

: That's because large units literally are made up of four separate units. They only share the same set of general stats (in unitref.dat). Unfortunately the 'under mind control flag' is unique to the four units, not the shared stats! So you in effect have multiple units under different control sharing the same stats. So if you move and it results in a reaction from the unit, it will spend the TUs you're using.
: Successful mind control automatically fills up the unit's TUs, so each mind controlled sector gets to move or attack again until there are no more sectors to mind control. Useful way of turning reapers into long range scouts!
: In TFTD, they attempted to fix this bug, but in fact made it much-much worse! The only way to mind control the unit properly is to control the upper left quadrant. Only! Any other quadrant will result in a partial (clockwise) control, and you may gain control of units other than that unit, or may even get into situations where you gain permanent 'partial control' of a large unit you haven't even sited. Wackiness all around!

:- [[User:NKF|NKF]]

== Facility Dismantle Bug ==

Boba: I've never experienced this bug myself in all my games in the Collectors Edition. It may very well vary from computer to computer.

-[[User:NKF|NKF]]
:I, however, have experienced it. I lost an entire month's worth of playtime because I couldn't solve it. [[User:Arrow Quivershaft|Arrow Quivershaft]]

::Anyone, any ideas on why it might vary from PC to PC? -[[User:MikeTheRed|MikeTheRed]]

:::I'd check other factors before blaming a given system. Assuming no mods are being used the most obvious is the order in which you initiated the construction of the modules. Then we've got which one was due to be completed first, and I'm sure there's a few other things to test out. Usually, a player won't cancel in-progress modules on a regular basis, so you wouldn't expect this bug to turn up often. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

:Easy way to reproduce: build 2 General Stores. Now delete the "second one" (see offset 16-39 in [[BASE.DAT]] for the order). Wait for the first one to complete. It'll crash immediately after the "end of construction" dialog. A fix is available [[User:Seb76#Bug_Fixes | here]]. [[User:Seb76|Seb76]] 15:52, 22 July 2008 (PDT)

== Manufacturing Limit Bug ==

Unfortunately, Mike, no you did not get it correct. It is the raw number of hours needed to complete the project, not the projected hours. I discussed this on the X-Com Forums a few months back at the following link: http://www.xcomufo.com/forums/index.php?showtopic=242027760&st=0&#entry164411

I did tests at the time in regard to the accuracy of the data given there, but I've lost the results. I'll quickly redo the tests in the next hour or so. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:00, 8 June 2007 (PDT)

:Tests complete. The breakpoints for every item were exactly where I predicted, regardless of number of engineers assigned. (I ran up a huge queue of items at my dedicated factory base on an old game, and then assigned whatever engineers would fit onto one project at a time, canceling projects as data was confirmed. This is only semi-random, but it serves our purposes.) I did run into a single issue, though. It appears that despite having 5 empty hangars at a (different!) base, the workshop there could not queue up more than 3 of any one craft at a time, thus making this bug impossible to replicate with the Firestorm or Lightning, as you must be producing more than three for the bug to occur. However, it still works with the Avenger. Later, I shall see about constructing a dedicated Hangar base with 7 hangars in order to attempt to replicate the bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:33, 8 June 2007 (PDT)

::Sounds great, Arrow. Why not post a simple example that shows how the problem works. As in, "with 1 Eng and 2 Avengers you might think X, but no, it's Y". And please delete my example. And it's a fine pleasure to meet you! Cool - [[User:MikeTheRed|MikeTheRed]]

:::When you say the usual resources are used by the "lost" resources, that includes cash, right? It sounds like if you're willing to foot the extra bill [[Buying/Selling/Transferring#Manufacturable_Prices|money/component-wise]], this could be used to build Avengers slightly faster then normal.

::: The usual time is 34000 hours. Double that and subtract 65535 and you're left with a paltry 2465 hours. Even a single workshop squad of 10 engineers will pull that off in a little over ten days. - [[User:Bomb Bloke|Bomb Bloke]] 01:53, 9 June 2007 (PDT)

::::Sadly, this exploit doesn't work, because the high bit is stored SOMEWHERE. I lack a hex reader and have no code reading skills to speak of, so I'm a bit limited here. If you set up a Workshop as you described, the game would take all the time for 2 Avengers, all the resources for the same, but in the end only produce 1 Avenger. Meanwhile, I'll run more tests on the resources thing. I could swear it consumes the resources, but I'll double check.

:::::There is no need to store the high bits if the actual completion condition (assuming adequate money) is "number made is number ordered", which wouldn't reference the hours remaining at all. - [[User:Zaimoni|Zaimoni]] 01:49, 9 Oct 2007 (CDT)

::::Tests done; I was unable to replicate the 'disappearing item' trick,(Which I didn't test for last night) even with Avengers! It appears I was wrong; this still counts as a bug, though, because the wraparound is a problem.

::::Ironic that so much of this discussion centers around Avengers, because that's where I discovered this in the first place! [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:48, 9 June 2007 (PDT)

----

I'm revisiting XCOM and was working on [[Manufacturing Profitability]]... Arrow, can you (or anyone else) say a little bit more on the Known Bugs page about this [[Known_Bugs#Manufacturing_Limit_Bug]]? It's not clear to me exactly what the bug does, except that it understates hours. Is that all?... does it still take the (non-buggy) amount of time, still use all the same resources, still make the same number, etc.? It sounds like it could be a drastic bug - or is it only a very superficial one, a display bug for the hours? It sounds like you're leaning toward this latter.

Also on a semi-related note... I could swear I saw much more detailed info on the [[Known_Bugs#Facility_Maintenance_Costs]] issue... IIRC, the incorrect amount that's charged for maintenance, depends on exactly where a facility is in the base. IOW, different "rows" of the base cost different amounts. Could somebody provide a link there, and/or flesh the bug out better?

Thanks! - [[User:MikeTheRed|MikeTheRed]] 11:22, 8 October 2007 (PDT)

:I've actually seen the bug work both ways, but I've only been able to actually replicate the more superficial version of the bug. So the bug report up is about a superficial bug that drastically understates production time. If you wish to make this clearer, you have my blessings. As well, that 'different charging based on location' is dealt with here: http://ufopaedia.org/index.php?title=Talk:Base_Facilities ; however, the table has been broken with the Wikiupgrade, and I lack sufficient knowledge of HTML table code to fix it. But it should be of use to you. [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:26, 8 October 2007 (PDT)

::Cool, I fixed [[Talk:Base Facilities]] but also re-organized and expanded [[Base Facilities]] so that it includes that bug in detail, as per Talk... this is an important issue that should be up front. I see that there's a separate [[Maintenance costs]] page, but I can't see having something so important (the maintenance bug explanation) all on its own page (which makes for a rather short page) rather than together with all the rest of the base facility info. If others agree (or don't care), I'll move anything remaining on Maintenance Costs to the Base Facilities page, then delete Maintenance Costs and re-route links. And if somebody does care, then please move my new section to Maintenance Costs, and move all the links, etc. Oh also I put in more words on your Manufacturing Limit Bug - how does it look? - [[User:MikeTheRed|MikeTheRed]] 16:37, 8 October 2007 (PDT)

:Looks pretty good, although it'll wrap fully; if you ask for 120000 hours, it won't be displaying 'almost no' time. The way I discovered it was when building two Avengers; I ordered two, paid for two, waited for two...and got one. But as said, haven't managed to repeat it, so until I do, we'll leave it like that. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:00, 8 October 2007 (PDT)

::I just revised and put in your specific example, because it's certainly possible some of us die-hard players will order up more than 1 Avenger at a time - and it's guaranteed it'd be a pain if 1 of them disappeared, laugh. I wasn't sure how concrete you were on that example but now I hear you say, you are sure it happened at least once. - [[User:MikeTheRed|MikeTheRed]] 18:33, 8 October 2007 (PDT)

:I have a question concerning the manufacturing "bug" which eats a craft in production due to wrap-over of the byte. Arrow (or whoever did the test), did you have a large quantity of craft already built at your bases? If so, I think this bug has more to deal with clogging up [[CRAFT.DAT]]. See, that file has a limit of 50 entries. Each craft takes up one record and each base you have built also consumes one spot. 8 bases allows 42 craft to be housed, while 6 bases allow 44. If you try to buy or manufacture craft once the file is full, nothing shows up in the game even if you have hangar space available. --[[User:Zombie|Zombie]] 19:00, 8 October 2007 (PDT)

::Huh, I never knew that. I don't see it listed on the Bugs page... I'll stick it in there. I've never approached that number, but some folks might. - [[User:MikeTheRed|MikeTheRed]] 19:07, 8 October 2007 (PDT)

:I was able to continue building other Avengers after that project, and they appeared correctly, so I do not believe that is the issue. In any event, I have a very bad case of 'archivism' and probably still have the save game and the CRAFT.DAT file around on my system; in fact, I think I was playing it a few days ago. I can see if I can find it and upload it; it created a 'hole' in the Avenger fleet numbers, where Avenger's x and x+2 were built, but x+1 was not. I'll look for it tonight and tomorrow and upload it to the wiki if I find it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:10, 8 October 2007 (PDT) EDIT: I found the file; I have 28 Avengers and 1 Skyranger in my employ. All Avenger numbers EXCEPT #2(Avenger-2) are accounted for, and I have not sacked or lost any Avengers. So this is where the hole and 'eaten' Avenger is. If anyone wants the CRAFT.DAT file from this game, I'd be happy to forward it. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:20, 8 October 2007 (PDT)

::Sure, send it my way and I'll take a look at it. (Might as well send me the whole saved game as I may want to look at the other files too). I have tried to recreate this bug by manufacturing 1, 2 and 3 Avengers at a clip but all of them always show up. Don't know what else I could do to get this problem to crop up. --[[User:Zombie|Zombie]] 21:32, 8 October 2007 (PDT)

:File emailed. On the side, I've tried the same thing, and never been able to repeat the bug. It's been months since the first discovery, so I can't recall whether it was the first or the second Avenger that didn't appear. So maybe it was just a fluke. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:57, 8 October 2007 (PDT)

== Unconscious Enemy in Equipment Screen ==

The following happened to me repeatedly over the last few days.

In the last tactical Mission a live alien has been captured. When now beginning an UFO crash recovery mission this type of alien (same race and rank) appears in the equipment screen before the mission starts, meaning I can give it to any of my soldiers.
If I do so I can store the alien in the skyranger for the duration of the mission and, if it gains consciousness, kill or stun it at the end of it. A pile of equipment without a corpse will be in the UFO, indicating that the stunned alien is not some kind of duplicate but instead has been taken from the aliens of this mission. This is supported by the fact that in those missions the maximum number of crew members has not been surpassed.
If I do not do so the Alien will be placed in the crashed UFO. Whether it is unconscious or not I do not know, but the fact that it is completely disarmed when encountered in the battle suggests that it is.

So far it seems the following is necessary for the bug to occur:
# An alien has to be captured alive in the last tactical combat
# It has to be of the same race and rank as one of the aliens in the new tactical combat

So far this only worked...:
# If the new tactical combat was an UFO crash recovery of a medium scout.
# For floaters and mutons
# For soldiers and navigators
# If the alien in the last mission was stunned by normal weapon fire (although I do not think this is important) and not picked up (again, not likely to be important) or destroyed (which would mean it has to be actually captured)

It seems NOT to depend on the following:
# The type of the last mission (were, so far: Ground assault battleship, crash recovery large scout, base defense)
# Which squad or vessel was involved capturing the alien
# Where it is locked up
# If it has been transferred since capture or not

Would be interesting to know:
# What happens if the alien in the inventory screen is the only survivor
# If the alien in the invenory screen is one of the aliens randomly killed in the crash or not (it is likely to be one of the killed aliens, so far the equipment piles were always within the UFO)
# If this is not limited on crashed medium scouts: Does this work with terror units? What about large ones?

Maybe this is related to the proximity grenade bug (transfer of item properties to next tactical combat).

Additionally, in one of those mission a part of the terrain was not generated correctly. It was in farm terrain (The house on the right square, or north east square, in [[Image:Terrain-cult.gif|this pic]]). The outer wall right to the right window of the southern wall (1st Floor) was missing. Directly outside of the hole was a floor tile. I could walk a soldier through the wall, but he fell right through the tile. Dunno if this has to do with the stunned alien bug.

Version is collectors edition (the one from abandonia.com).

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

When a mission starts, the GeoScape engine generates the unit and object tables (in MissDat's [[OBPOSREF.DAT]], [[UNIPOS.DAT]], and [[UNIREF.DAT]]) before "shutting down". The Tactical engine then generates the maps, places the aliens on it, and blows up the UFO (if need be). Whether or not map generation and the subsequent events happen before you equip your soldiers I don't yet know.

The test would be to check the aforementioned files to see if they contain an unconcious alien, and/or the body.

Note that you can't see the bodies of large units on the ground (they count as four seperate objects covering four seperate tiles, so allowing the user to pick one up would essentially let you rip them apart).

- [[User:Bomb Bloke|Bomb Bloke]] 06:35, 5 August 2007 (PDT)

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

I honestly have no idea of how all those files work. But I still have a savegame in battlescape that is in one of those missions. So if anyone wants to have a look at those files...

I forgot to mention: I reloaded a geoscape savegame shortly before the battle to recreate the bug, but it seems that reloading in geoscape before the buggy battle eliminates the bug. I guess his should narrow down the possible reasons...

--------

Next time it happens, backup the aforementioned files before you start another mission. I'm afraid a savegame wouldn't be of much help.

- [[User:Bomb Bloke|Bomb Bloke]] 00:54, 7 August 2007 (PDT)

== Soldiers moved to outside of combat screen ==

Hi, I've got a DOS version of UFO:EU, and I've encountered a bug in the tactical combat. Sometimes (rarely) a X-COM soldier changes its location on the map on player's turn start and is placed on outside of the map, one tile north from the (north) border of the field. AFAIR the unit is then selectable (you get the flashing highlight when cursor is above), but is stuck outside of the field. Has anybody encountered this bug? It seems to happen randomly, but more frequently during the terror missions and on early turns (so maybe it's caused by high number of player/alien/civilian units?). --[[User:Maquina|Maquina]] 08:16, 3 September 2007 (PDT)

:I've never encountered this bug in CE of UFO. Presuming AFAIR means "As Far As I Recall," what exactly was the soldier doing? Any equipment data, location, or stat info might help us pin it down. Were afflicted soldiers always carrying a specific equipment set or weapon? Where were they on the map before they got moved? Did they get bumped a few spaces, or teleported halfway across the Battlescape? Does it happen more often on a specific difficulty?(Your theory would suggest this would happen most commonly on Superhuman) Against a certain type of alien? Best of all, if you can recreate the situation in a game, save the game and then you could upload the save file to the forums or this wiki, and the rest of us could take a look for ourselves and the code divers could root around for the cause. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:03, 3 September 2007 (PDT)

:: I've had this happen to me several times in UFO and TFTD. I don't know if it's specific to the Dos version or if it can happen in the CE as well. Sometimes the soldier ends up beyond the boundary of the map right at the start of the mission, at other times it happens after you load a game. This game is glitchy, which is the source for so many of its bugs, so your soldier's coordinates are probably getting corrupted to the point where they are -1 on either the X or Y axis of the maps's normal boundaries. For me it's commonly along the top edge of the map. I don't ever recall it happening mid-mission, only at the start or after a load. I cannot faithfully say whether it happened with or without XComutil, but that could be one of the possibly many causes for this. - [[User:NKF|NKF]]

:: I don't play UFO often, so I rely on just several campaigns played. This happens rarely (I've encountered this bug twice in my last campaign with ~80 missions played), but if you haven't seen this happen then it probably doesn't show up in the CE edition. In my experience the soldier is moved always beyond the north/top map border. I think (but I'm not sure) that this affects the first soldier from the team more commonly than others (or maybe even exclusevily?). The equipment/armor carried is probably not relevant, since the units moved this way don't have any special stuff, and this bug shows up on different stages of the gameplay (ie. sometimes when you have ordinary rifles, sometimes when all your units got heavy plasmas and power suits). --[[User:Maquina|Maquina]] 04:12, 4 September 2007 (PDT)

'''MY ramblings have been moved to my discussion page''' [[User:EsTeR|EsTeR]]

==Great Circle Route==

Should we have the Great Circle Route bug noted on this page at all? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 6 October 2007 (PDT)

: what is the great circle route? [[User:Jasonred|Jasonred]] 07:56, 31 March 2009 (EDT)

:: Pick two points on a globe, then hold a thread or string taut at those two points. That practically minimizes the length of the thread/string on the globe. You're now looking at a great circle arc (or route), the shortest distance between two points on a globe. -- [[User:Zaimoni|Zaimoni]] 11:15 March 2009 (CDT)

: Just as a line is the shortest distance between 2 points on a flat plane, a great circle is the shortest distance between 2 points on the surface of a sphere. The bug, by the way, is that aircraft in the game ''don't'' follow this shortest, "great circle" route. [[User:Spike|Spike]] 12:38, 31 March 2009 (EDT)

:: What a grand sounding name, for something so simple, lol. ... I thought you were talking about when you tell your soldiers to go from point A to point B, and for some reason they figure that Zone A and Zone B are really far apart, despite actually being side by side. (I shot a hole through a wall, clicked to walk to the other side, and my idiot soldier walked one big circle... to use the door! And got ambushed and killed by an alien. ... dum dum DUMB DUMB.)
:: Even the more modern games have problems with their pathfinding algorythms. Admittedly, games like Baldur's Gate had to do it in realtime.
:: On a semi-related note, I remember this guy called E-man, he was chasing a guided laser beam that was going to kill his girl, around the world, but he couldn't outrun it since he couldn't break the speed of light, only equal it by changing into a Laser himself. So... inspiration! He turned into a very powerful laser, and made a shortcut THROUGH THE EARTH... the straight line beats the great circle route, lol.
:: Thanks for the reply guys [[User:Jasonred|Jasonred]] 15:56, 31 March 2009 (EDT)

Added to article. [[User:Spike|Spike]] 16:41, 3 September 2012 (EDT)

==Bug not listed: Missing soldiers during base defense==

I encountered an interesting bug concerning base defense missions:
My base got attacked while about 30 soldiers and 10 HWPs were present. The usual equipment assignment screen was skipped and the mission started instantly with only the HWPs spawned at the map. Not even a single soldier bothered to show up... *sigh*
Although this turned out to be in my favor (you should have seen the puzzled Ethereals trying to panic my tanks) I´d like to avoid this bug if possible. I was able to reproduce this bug several times and with different bases.
Can anyone explain this bug and/or tell me how to avoid it?

Game version: Collectors edition. - [[User:NewJoker|NewJoker]]

-----

Well, ideally, we need to know what your base's construction was to be sure of this, but I think the most likely circumstance is that the HWPs took up all the spawn points. HWPs have maximum priority for spawning(followed by Soldiers, and then Aliens), so if you have enough of them garrisoning a base, it's entirely possible that soldiers and aliens won't spawn. However, this doesn't explain why the soldiers didn't start stealing the Alien spawn points...in any event, you might want to take the save game file, zip it up, and get ready to email it. I'm sure [[User:Zombie|Zombie]] would be quite interested. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:28, 13 November 2007 (PST)

-----

It's not the spawn points, it's a [[UNITPOS.DAT]] limitation. A maximum of forty records (out of the total of eighty) are allocated for your units, and tanks (which take up four records each) get first pick. Having ten tanks means there's no room left for anything else.

Ditch one HWP and you should see four units take it's place. - [[User:Bomb Bloke|Bomb Bloke]] 16:42, 13 November 2007 (PST)

-----

I´ll try with a decreasing number of tanks and report the results. As I wrote above having only HWPs isn´t too bad dependent on what enemy is attacking. [[User:NewJoker|NewJoker]]

----

This should be mentioned in the [[ExploitsE#Base Defence Mission Spawning Issues]] section. The Bugs/Exploits really need to be sorted and consolidated. - [[User:NinthRank|NinthRank]] 16:57, 13 November 2007 (PST)

-----

The limitation to 40 records seems to be the case; each tank I dumped got replaced by four soldiers.
So this can be used to effectively manage unit combination. Thanks for the quick replies! [[User:NewJoker|NewJoker]]

==Bug not listed: Ufo Gold (Windows Vers. abandonia.com) crashing when plasma defense is finished==

I recordnized this bug a few times now. (with hacked AND unhacked game)
If i place a plasma defense in 7 bases at the same Time and they are finished at the same Time, the game crashes sometimes.
In hacked game, it seems to crash even more when Alien containment is finished, plasma defense, shield defense...etc.
couldnt find it here...greetz

: I somehow doubt the sourcing is the issue. [You may want to fund the next XCOM series game with a Take2 re-release of UFO :)] More generally: the game only reports the construction of a given type of facility <b>once</b>, no matter how many bases it completes at simultaneously. I've only tested this <i>in vivo</i> with three-of-a-kind at once across six bases, however. It does seem reasonable that some sort of counter of undisplayed completions would "overflow" (attaining crash). -- [[User:Zaimoni|Zaimoni]] 10:05, Feb. 28 2008 CST

::I've encountered this bug myself with General Stores, actually, not just Plasma Defense(which I never build). EDIT: Some quick tests seem to show that there's a chance the game will crash any time two base facilities are done at the same time, regardless of whether they're in the same base or not or if they're the same facility.(although it seems to happen MUCH more in the event they're in different bases.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:13, 28 February 2008 (PST)

== Soldier Recruiting Bugs Tested ==

Just to note that I have positively tested and replicated the bugs listed under the new(ish) section [[Known Bugs#Soldier Recruiting Bugs|Soldier Recruiting Bugs]]. [[User:Spike|Spike]] 18:08, 19 March 2008 (PDT)

==Floater Medic Bug==

I have not thus far encountered the Floater Medic Bug; in fact, Floater Medics are often used to fill up my Rogue Gallery with interrogations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 06:50, 24 April 2008 (PDT)

Strange, it would always occur in my version. I don't remember where I got it from, but I
know it was a download from the internet. Using the XCom Hack v2.5, I viewed the alien in
the Alien Containment edit. I now have Type (race):____, and a Rank: Soldier for the
Floater Medic. It might just be corruption, but I do not have the resources to look into
it. [[User:Muton commander|Muton commander]] 19:24, 12 May 2008 (Pacific Time Zone)

I've never encountered it either. [[User:Magic9mushroom|Magic9mushroom]] 07:47, 23 July 2009 (EDT)

I think this only happens in the CE version. A disassembly of the code reveals that the stack to hold the matrix for what topics have not yet been researched is too short. It seems that those who ported the code from DOS doubled the local variable sizes blindly. There is already a problem that there are two-few bytes necessary for the entire alien organism section of the UFOpaedia, but double the expected size of the registers and it fills up quite easily unless a lot of autopsies and interrorgations have already been done. The only other situations that are handled by the same routine are the navigator revealing mission data or engineers revealing ship data, but there isn't enough topics in either section to overflow the stack variables. - [[User:Morgan525|Tycho]] 08:27, 22 June 2013 (EDT)

==Strength Overflow==

During one of my games with TFTD I noticed a really annoying thing happen during battles.
As my troops rose up the 'stat.' ladder they got better and better (as you'd expect), until they hit about 50 strentgh and completely lost the ability to throw anything.
Even trying to throw something tiny like a grenade or flare into the adjacent tile resulted in the 'Out of Range' message being displayed.

Anyone come across this before?
This was in TFTD CE.
[[User:Tifi|Tifi]] 07:55, 27 April 2008 (PDT)

:This is fairly well documented. The pathfinding algorithm for throwing objects will balk if anything is in the way of the throw and refuse to allow you to throw. What's happening is that your soldiers have become so strong that their throws are intercepting the 'ceiling' of the Battlescape(the top of L3), and as such the game thinks that the throw is blocked(because in order for the throw to complete, the object would have to be tossed up to the nonexistant L4). There's two ways around this:

:The Normal Way: Try shorter throws, throwing from lower heights, or throwing while kneeling. Beyond that, possibly get some new troops.

:The Sneaky Way: Manually edit the Strength scores of your soldiers in [[SOLDIER.DAT]] so that they're back to a usable strength level. If you set "Initial Strength" (offset 46 decimal or 2E hex) to 0 and "Strength Improvement" (offset 57 decimal or 39 hex) to a value of 50, you can permanently lock the soldiers at 50 strength. (You can lock them higher than that if you so choose, but not lower.

:Other than this, there's no workarounds I can think of offhand. [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:10, 27 April 2008 (PDT)

:: There's normally no problem with the max level of 70 in open settings. However TFTD has a lot of low ceilings such as in the shipping lane missions and colonies, and the lower ceilings impairs your throwing quite a bit. In addition to shorter throws/kneeling, try moving out from under any overhangs if there is one just above you. - [[User:NKF|NKF]] 12:33, 27 April 2008 (PDT)

== Bug not listed: Sticking your head through the ceiling ==
This is something I just discovered: When you step on a small object inside of a building your soldier sticks his/her head through the ceiling and can see what's upstairs. You can even see the soldiers head coming out of the floor and that soldiers can shoot aliens upstairs. When I did this the alien I saw/shot was facing the other way, but I guess you could get shot if the alien was facing you. [[User:RedNifre|RedNifre]] 17:34, 11 May 2008 (PDT)

:That's not listed under "Bugs" because it's covered under "Exploits", right here: [[Exploiting_Collison_Detection#See_Through_A_Ceiling]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:26, 11 May 2008 (PDT)

:: I don't know if it was ever covered anywhere, but there's this neat trick that might sound similar to the walk-through-'wall object'-wall trick except that it involves your unit climbing slopes. They'll appear as though they've gone up a level, but are actually not on that level. They only visually appear to be there, but are really still on the bottom level.

:: It happens a lot when walking up the desert or forest slopes. I think the trick involves standing on ground level, and then ordering the unit to 'move' into the hill rather than setting the waypoint while on level 1. The soldier will move up the slope and perhaps stop on the slope or even reach the top of the slope, but will still appear when you're only viewing the ground map layer. The soldier is really still on the ground level, but will have elevation offset.

:: One really interesting way of using this trick is in the mountain region. If you can find a cliff face and a low hill nearby, you can literally have your soldier scale the cliff by standing the soldier on the hill, and then walking towards the cliff. It's ridiculous, but your soldier never quite reaches the top of the cliff tiles, so ends up walking up a slope.

:: On a side note, standing at the top of the ramp of the Skyranger is the same as standing on ground level - you're only offset a bit. This means that smoke on level 1 and the sides of the Skyranger will not provide protection when you're at the top of the ramp.

:: On another related note in relation: In TFTD (doesn't happen a lot in UFO), you might find it difficult to toss grenades onto underwater slopes. To remedy this, raise the level up by one. It might look like you're tossing at air(and you are), but it'll get the grenade where you want it. Odd, but true. I must remember to put this in the grenade explanation section. -[[User:NKF|NKF]] 23:11, 11 May 2008 (PDT)

== Base Defence bug that causes a crash? ==

Does anyone know about a bug in a base defence mission that causes the game to crash? The game keeps crashing on the 4th or 5th alien turn.

:I've encountered that myself, but it should be noted that overall, X-COM is not the most stable game and is prone to crashing often at anytime. The differences between the hardware it was designed for and the hardware we're running it on cannot be helping matters at all; it's really a small miracle it even runs without an emulator in the first place(I've got games from 1999 that will bluescreen my machine instantly). As such, I'm not sure it's worth noting as a bug, since it's a 'game feature'(albeit a detrimental one). In any case, what're you doing letting the aliens attack you anyways? ;) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:33, 18 July 2008 (PDT)

:It sounds like an alien is in one of the outlying locations and attempting to destroy the top floor item. Possibly a radar or defense station. - [[User:Morgan525|Tycho]]

== Sources for a DOS4GW transplant ==

I was specifically thinking of the LucasArts Dark Forces demo, but I half-recall the actual source I used when testing that ~1999 was Id's DOOM. -- [[User:Zaimoni|Zaimoni]] 16:03, 7 August 2008 (CDT)

== Phantom Carried Casualty ==

You are carrying an unconscious soldier in one hand, and the soldier dies of his/her wounds. The dead soldier remains visible on the "left hand / right hand object" battlescape display, but is no longer visible in the inventory display. The problem can be fixed by moving another object into the same hand.

I've seen this bug with UFO Extender by [[User:Seb76|Seb76]] - possibly might be something to do with his manipulation of the inventory screen, rather than a general bug. I believe I've also seen this with other objects that were being carried in the hands, disappearing from the Inventory screen, but I'm not sure. I don't think it's an item limit bug, as XcomUtil shows 40 item slots free. [[User:Spike|Spike]] 08:58, 21 September 2008 (PDT)

:I think it has to do with the KO units KIA mod. Its doesn't take into account units held so when it tries to detemine where to place the corpse, there is no location. The routine doesn't undo the item-carried-sprite-ID byte for the holder. -[[User:Morgan525|Tycho]]

== Civilians As Enemies to MC'd Aliens ==

I ran across this issue a few times and just wondered if you guys experienced this. I MC'd a part of a Reaper (I always do the lower left for large aliens) on a Terror Site, then moved it a few squares. It suddenly stopped dead in it's tracks and then the alien spotted indicator increased by 1. When I clicked on the indicator to see where the enemy unit was, it brought me to L2 of the large apartment complex. However, nothing was there. When I sent a Flying-Suited soldier up there to peek in the window (eeek! A peeping tom!) he saw a female civilian standing there. This type of problem has happened numerous times to me so it's not a once-off thing. Maybe it's a LOS issue? Or maybe an alien indicator problem? Or a combination of the two? Don't know, but I'm curious if you guys have seen it. --[[User:Zombie|Zombie]] 23:40, 19 December 2008 (CST)

:There are a lot of major issues with MC'ing 4 square aliens. One of them being that you could accidentally MC an alien far off in the corner of the map, IIRC? Anyhow, maybe you should have tried MC'ing all 4 squares of the reaper and see if that changed things. -[[User:Jasonred|Jasonred]]

The long-range MC of other aliens when Mind-Controlling large aliens is only present in Terror From The Deep, due to a workaround to try and resolve the earlier bugs(and exploits) associated with controlling one square of a large unit at the time. In TFTD, successfully MC'ing part of a Large unit will also grant you control of the next three units in UNITPOS.DAT, in order. If you didn't MC the upper left portion of the large unit(the first UNITPOS entry for any large unit), you can potentially wind up in control of other aliens. So this doesn't apply to UFO. As for Zombie's issue, never seen it. And finally...Jasonred, on Talk pages, please indent your statement with colons so it differentiates from other people's comments, and sign your posts with 4 ~'s, like I will now do. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==Elerium Base Bug==

Jasonred: This bug has long since been known about. Elerium units on the Battlescape can be picked up by shooting away the power source; this one item counts as 50 units, and as such ANY elerium item spawned on any Battlescape counts as 50 Elerium. This issue with your own Elerium spawning as collectable loot in a Base Defense mission only occurs in older DOS versions, and is at the whim of the 80 item limit. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:55, 18 February 2009 (CST)

:Base defense does not seem to follow the 80 item limit in that DOS version. There are a lot of bugs that have long been known about. However this one was not included in the ufopedia for some reason.
:Also, the main thing about this bug is that it does not potentially double your elerium stores. It potentially multiplies them 50 times.
:... First time this happened to me, I was pretty flabbergasted. Here I was being conservative with my limited Elerium, refraining from blowing up UFOs when possible, when I perform a base defense and gain 3000 Elerium from it. Holy spit. -[[User:Jasonred|Jasonred]]

Alright, my error. Thanks for clarifying. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:42, 19 February 2009 (CST)

==HWP Fusion Bomb and SWS PWT Displacer Ammo Manufacturing Cost Bug==

At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended. [[User:Arrow Quivershaft|Arrow Quivershaft]] 09:55, 15 November 2008 (CST)

:Hmm, in that case maybe it should be treated as a generic game engine issue and not a TFTD specific issue - but I still think it's a design error. Can you think of any logical reason why the SWS/HWP version of the ammo should be more expensive (in cost and in materials) than both the craft ammo and the (more powerful) personal ammo? It makes no logical sense. Hence I think it's a design error. Nothing can be inferred from the fact it's unchanged from XCOM-EU, that doesn't imply any deliberate decision. It could just be the replication of an original error in XCOM-EU. [[User:Spike|Spike]] 11:17, 15 November 2008 (CST)

:: I can think of a logical reason to justify this: X-Com doesn't understand the technology as well as the aliens do (which is obvious, given the length of time each side has known the tech). Handheld Blaster/Blaster Bombs are just a copy of the alien design and therefor relatively cheap and efficient, but that can't be mounted on a turret. So X-Com has to make a new design, and they obviously didn't do that good a job as the aliens would have done. This explains Tank/Plasma being weaker than Heavy Plasma too. (Why is FBL Craft ammo cheaper than the tank ammo though? Maybe X-Com gave up on/simplified the guidance system and made it just a "dumb" cannon shell/torpedo instead which doesn't have multiple waypoints? Or maybe they just did a better job there?). [[User:Cesium|Cesium]] 04:07, 25 November 2009 (EST)

:Whilst we discuss it, I'll park my original text in here:

* ''Displacer/PWT ammo cost bug - at over $100,000 total cost per round, the ammunition for this SWS weapon is far more expensive to manufacture (both in money and rare materials) than the equivalent ammo for the Aquanaut-carried Disruptor Pulse Launcher, or the craft-based Pulse Wave Torpedo, despite being less powerful than either. This would seem to be a design mistake.''

See Also [[Talk:Displacer/PWT]]

:: I don't like the higher cost either, but I think it's a tradeoff of expense and quality for the convenience of portability. Sort of like an MP3 player to the gramophone... or maybe that's not a good comparison. -[[User:NKF|NKF]] 13:43, 15 November 2008 (CST)

A better comparison might be a desktop computer to a laptop. As a general rule, laptops are more expensive, but a similarly priced desktop gives you more power. Desktops are cheaper and offer power, laptops are more expensive and offer portability(though the gap is rapidly narrowing). [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:49, 15 November 2008 (CST)

:I think those are good analogies. But they don't apply in this case. To continue your analogies: We are paying mainframe prices for a clunky desktop that has only laptop processing power, and we're buying a mainframe for desktop prices. The vehicle version ("desktop") - is ''less'' portable and ''less'' powerful than the personal version (DPL = "laptop"), ''less'' capable than the craft version ("mainframe") - and costs ''more'' than either of the others in total cash and in materials. In particular, it makes no sense that the small missiles on the SWS use up ''more'' of both Zrbite and Aqua Plastics than the Craft version. Do we really think it's logical that a tactical battlefield round, less powerful than its man-carried equivalent, takes more explosive and structural material to produce than both the more powerful man-carried version and also more than the air-to-air round that has 60km range and can take down a major alien combat craft? There is a clearly perverse bang-per-buck here, on every measure. My sincere belief is that this was an original mistake in the XCOM-EU engine that got copied into TFTD as well. The craft round should have the higher base price, but the material requirements that are currently assigned to the SWS/HWP round. It's debatable whether the SWS/HWP rounds should be more expensive than the man-carried rounds. But what I don't think is debatable is that is not logical for the SWS/HWP rounds to be more expensive than the craft rounds. It's clearly a mistake. Even in game balance terms, the only thing the HWP/SWS rounds have going for them is conserving "80-Item Limit" space, which I severely doubt was ever a game design consideration since it's just an awkward programming compromise. Any advantage inherent in the HWP/SWS is already reflected in the very high platform cost - there is no need to inflate the ammo costs as well. The bottom line is that a round for a (mini-)tank does not cost more, does not use more materials, than the same type of round for a long range anti-aircraft weapon that has much greater damage capacity and penetrating capacity. [[User:Spike|Spike]] 14:35, 15 November 2008 (CST)

I'm going to add this to the bug list now. [[User:Spike|Spike]] 16:06, 25 February 2009 (CST)

:Still don't think this is a bug though. Just because it's more expensive to manufacture than the hand-held or craft-mounted ammo, it doesn't mean the stats are wrong. Perhaps the programmers wanted to balance the tactical portion of the game a little more by making the ammo cost more for tanks. It doesn't have to be logical to be intended. Now if you had proof which said that the ammo was supposed to cost less but the stats were wrong, then yes, I'd agree. So if you boil it all down it comes to a disparate logic issue, not a bug.--[[User:Zombie|Zombie]] 21:31, 25 February 2009 (CST)

::I have to side with Zombie here. While the ammo may be disproportionately expensive, by the definition used on the rest of the page for bug, it doesn't fit. All the other bugs are errors in program logic or function or routines that are unintentional problems with the game, most of which are not warned of ahead of time. The ammo for the tank costs exactly what is listed and operates entirely as intended, whereas the rest of the bugs are not intended game features. Even if the numbers were entered wrong, that would be a data entry error, not a program bug. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:28, 26 February 2009 (CST)

:If it was a data entry error, I'd consider that a type of bug... assuming we had proof of the goof so to speak. LOL. --[[User:Zombie|Zombie]] 00:49, 26 February 2009 (CST)

:: It feels too specific an entry to be a data entry error.

:: I'm reminded of the high explosive. I know, I know - it's not an exact parallel to the FBL issue. A High Explosive is practically two grenades. Double weight, double bulk. Slightly above two times the damage. However, it costs five times the price of a standard grenade. Even though you're paying more for not-as-much, I don't think that could be considered a bug. A rip off, yes, but not a bug.

:: Here's a thought: Think about the immediate benefits each of the two controversial ammo types give back to you. Aircraft ammo = activity points. Tank ammo = loot. Yes, I know that aircraft ammo also generate crash sites, but you still have the ground combat to contend with.

:: One other thought: With careful management of your ammo, you'll probably never spend any elerium on the handheld version's ammo. Could it be the handheld that's really at issue here rather than the others? In the end I feel that it doesn't really matter. -[[User:NKF|NKF]] 03:38, 26 February 2009 (CST)

: I'm with Zombie that a data entry error is a bug (we have other examples), but also agree some proof is probably needed. And I agree with NKF that in the scheme of things, it doesn't really matter much. I don't think the HE pack is a good comparison (though the HE pack should be heavier) as it's reasonable to pay disprortionately more to get additional power at the same tech level. The fusion weapons are a case of paying more to actually get ''less'' power. I am not bothered by the handheld vs vehicle balance, not least because the game generally makes handheld weapons better than their vehicle equivalents, so I can accept that as an across-the-board design decision.

: I can also see a game balance argument ''if'' we believe that Fusion Tank ammo is more of an overall game-winning weapon than craft Fusion Bombs. But I'm not sure I agree with that statement. And even if it's true, and there's a game balance argument (in which case it would apply equally to handheld Fusion launchers), it's still illogical. The less powerful, battlefield warhead should not cost massively more in exotic materials than the much more powerful air to air warhead that brings down Battleships. I agree though that just because it's illogical does not prove it's a bug (i.e. unintended). [[User:Spike|Spike]] 07:48, 26 February 2009 (CST)

Ok we more or less seem to be in agreement that this isn't a bug, but it is very confusing/illogical. Maybe we can shift the "bug" text from the article page and roll that into the [[Hovertank/Launcher]] and [[Displacer /P. W. T.]] pages now. Feel free to combine any text from the discussion above if necessary. --[[User:Zombie|Zombie]] 09:22, 26 February 2009 (CST)

: Unless we can ''prove'' it's a data entry error (unlikely), how about calling it an "Anomaly" instead of a bug? [[User:Spike|Spike]] 10:59, 26 February 2009 (CST)

Looks like plain old game imbalance to me.
The way I see it, Hovertank Plasma and Launcher were meant to be stronger. Much much stronger. Let's look at Tank Cannon, Launcher and Laser. The logic is that it's a tank mounted weapon, so the tank can carry a much larger and more powerful version of the same weapon, right?
It's pretty stupid that a Hovertank Plasma is weaker than the Heavy Plasma... you could just mount a Heavy Plasma on a Hovertank and get them exactly equal. In fact, I suspect that the hovertanks were ALSO meant to have more powerful weapons than the man-portable versions.
Unfortunatly, the game designers then realised that this made the hovertanks far too powerful. So... the programmers nerfed the power of the hovertank weapons. BUT they forgot to lower the ammo costs. [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 11:20, 26 February 2009 (CST)

: Well you are opening up a much larger issue there. The Fusion weapons are an anomaly, an inconsistency. But handheld weapons are more powerful than equivalent vehicle weapons across the board, consistently. So that looks like a deliberate design decision, not a mistake. [[User:Spike|Spike]] 17:33, 26 February 2009 (CST)

:: There are two exceptions to the rule: Tank/Cannon: 60AP vs. Heavy Cannon 56AP. Tank/Laser: 110 Laser vs. Heavy Laser: 85 Laser. The hovertank\plasma only differs by a measly 5 (an extra 0 - 10 damage, which means a lot vs. UFO inner hull armour). I guess the trend here was to moderate the area effect tank strengths. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

I'd have to agree with you there Spike. This wasn't a mistake, however odd it may seem. It was a deliberate attempt to try and balance the game. Below is a table I created ages ago for my (now defunct) strategy guide detailing the HWP's and what handheld weapon corresponds to it. When you stick them side-by-side, it really becomes apparent that the programmers were trying to base the HWP weapons off the handheld weapons somewhat. The only thing that doesn't follow a nice and distinct scheme is the damage. That's what is the clincher. --[[User:Zombie|Zombie]] 20:26, 26 February 2009 (CST)
<br>
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th align="left" width="150">Tank Type</th><th width="70">DAM</th><th width="80">Snap</th><th width="90">Aimed</th><th width="90">Aimed</th><th width="80">Snap</th><th width="70">DAM</th><th align="right" width="140">Handheld</th></tr>
<tr><th align="left">Tank/Cannon</th><td>60</td><td>60%</td><td>90%</td><td>90%</td><td>60%</td><td>56<sup>1</sup></td><th align="right">Heavy Cannon</th></tr>
<tr><th align="left">Rocket Launcher</th><td>85</td><td>55%</td><td>115%</td><td>115%</td><td>55%</td><td>87.5<sup>2</sup></td><th align="right">Rocket Launcher</th></tr>
<tr><th align="left">Laser Cannon</th><td>110</td><td>50%</td><td>85%</td><td>84%</td><td>50%</td><td>85</td><th align="right">Heavy Laser</th></tr>
<tr><th align="left">Hovertank/Plasma</th><td>110</td><td>85%</td><td>100%</td><td>100%</td><td>86%</td><td>80</td><th align="right">Plasma Rifle</th></tr>
<tr><th align="left">Hovertank/Launch</th><td>140</td><td>--%</td><td>120%</td><td>120%</td><td>--%</td><td>200</td><th align="right">Blaster Launcher</th></tr>
</table>
<sup>1</sup>AP rounds.<br>
<sup>2</sup>Average between the Small and Large Rocket.

: Hold up! Tank rounds do 60AP. -[[User:NKF|NKF]] 23:22, 26 February 2009 (CST)

So what's wrong? The table says 60 for the Tank/Cannon and 56 for HC-AP. Those are correct, no? --[[User:Zombie|Zombie]] 23:41, 26 February 2009 (CST)

: Sorry, didn't realise it was two tables side by side (or rather mirrored). Eyes only noticed the left side of the table. -[[User:NKF|NKF]] 23:53, 26 February 2009 (CST)

:: If the Hovertank Launcher did 200 damage, or worse if the Hovertank Launcher did EVEN MORE damage than the Blaster Launcher... that would make them easily the most deadly things on the map. As it is, the hovertank launcher is already pretty overpowered, even with 140 power.

I might be six years late here, but I think there could be an explanation for this in RL physics — indeed, in RL nuclear weapons programs. Incoming wall of text.

There are two sorts of nuclear reactions that produce energy: fission of large nuclei, and fusion of small nuclei. Fission can occur under normal temperatures and pressures, but involves a neutron chain reaction. As such, fission devices have to have a certain mass of fissionable material (the ''critical mass'') so that the neutrons stay in the material and cause more fission rather than escaping; this means that such devices cannot be scaled down below about suitcase or large backpack size (not all of this is actually nuclear material; rather, most of it is conventional explosives used to rapidly assemble the supercritical mass from subcritical masses). They also produce large quantities of radioactive fallout, which is problematic. Fusion, on the other hand, requires extreme temperatures and pressures, but does not necessarily require a neutron chain reaction. This means that they can theoretically be scaled down to much smaller sizes... except that the only available compact source (ie, not building-sized) of those extreme temperatures and pressures is the detonation of a fission bomb. Thus, all known fusion weapons currently in existence involve a relatively-small fission stage that detonates a much more powerful fusion stage.

The "Holy Grail" of nuclear weapons research is what's called a [[wikipedia:Pure fusion weapon|pure-fusion weapon]]. Because it has no fission stage, a pure-fusion weapon would release little fallout (note here that fallout is material that emits radiation long '''after''' the detonation; a pure-fusion weapon would emit copious amounts of deadly neutron radiation when actually used, but that would dissipate within seconds) and could be scaled down to grenade-launcher size (though it would obviously be far more powerful than a conventional grenade). They would be far easier to produce, as well; producing weapons-grade uranium and plutonium requires large and powerful isotopic separation equipment and/or a full-sized nuclear reactor, whereas deuterium can be extracted from water with trivial ease and lithium and tritium are relatively simple to obtain and make respectively. The main issue is that while the pressures required to confine the fusion material during the reaction are achievable with chemical explosives, the temperatures necessary for fusion are emphatically not. You need a stronger initiator; some material with a higher energy density even than plutonium. In RL the only initiator strong enough is antimatter — hard to produce and contain, to say the least — but the aliens in X-Com have a source that's stored far more easily... Elerium.

I posit that the "fusion" line of weapons in X-Com are exactly what they're named: tactical fusion bombs, made possible by an Elerium detonator. (A more controlled reaction on those lines — a fusion reactor with Elerium-spiked fuel — in UFO Power Sources would also explain the discrepancy between the calculations based on fuel efficiency and the lack of city-killer blasts when a Power Source's Elerium cooks off.)

Given the assumption that "fusion" weapons are indeed fusion weapons, with Elerium serving only as a detonator, the oddly high Elerium cost of the Hovertank/Launcher's ammunition is finally explainable. The HWP Fusion Bombs are, literally, smaller than Blaster Bombs and craft Fusion Balls (presumably because of size constraints in the launching mechanism in tanks). Having less explosives to compress the fuel means you need an even higher temperature to compensate — thus, more Elerium detonator — but because the actual power of the bomb is mostly from fusion and not Elerium decomposition, the yield is still lower.

I intend to remove this from the list of Known Bugs on this basis if nobody can find a hole in my logic. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:03, 17 April 2015 (EDT)

:I'll have to disagree. Your argument while interesting, is just supposition and an attempt to give validation by taking ideas (that the developers probably never considered) to justify a flaw, very much in the same manner as those who try to explain why UFOs do not respond in interceptions. In truth, like many of the other bugs listed here, they are the result of issues caused by the time constraints the Gallops where under. Much of the production/buying/selling aspects of the game have game balance issues and don't make sense when cross referenced to other similar elements in the game and/or their overall effect to either combat or the strategy layer, especially in regards to the game's economics. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 05:06, 17 April 2015 (EDT)

::Why would they match up in terminology with the actual use to which any military would put Elerium by accident? Because, no shit, if a military got their hands on a substance with Elerium's properties this is literally exactly what they'd do (at least as far as explosives go). I can cite a paper talking about the superiority of antimatter-fusion weapons to pure antimatter weapons if you want; the title is "Fourth Generation Nuclear Weapons: Military effectiveness and collateral effects". [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 05:21, 17 April 2015 (EDT)

:quote all the sources you like, it still doesn't explain the waste in the manufacture process. With elerium being such a "scarce" resource, there is no logic in producing something that require more elerium and delivers less of a battlefield effect. It would be more logical and efficient to have had the platform fire regular blaster bombs, since they only require 3 elerium not 5.[[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])
::IMHO, any logic argument can be presented to why those HWP Elerium Bombs should cost less/more or be more efficient. That is not the point here. A bug is when a game feature is working improperly or/and is causing technical issues, either due to limitations, insufficient testing, whatever. Design choices are a completely different matter: the Heavy Laser is a nearly useless weapon due to its stats but no one ever considers it to be bugged due to its stats. It was a choice, that was slightly changed on TFTD with the Heavy Gauss. To consider the stats of the HWP Fusion a bug then you'd have to label a lot of choices as bugs when they are simply design choices. You may not agree with them but that doesn't make them bugs in the generally accepted definition of the term. And quoting Arrow Quivershaft on the top comment of this discussion: "At a cost of $15000, 400 Tech hours, 5 Zrbite, and 8 Aqua Plastics, this is the exact same cost as the HWP Fusion Bomb from X-COM EU, converted over to the equivalent TFTD resources. As such, it shouldn't be counted as a bug, since it is clearly what Mythos intended"[[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 19:35, 25 April 2015 (EDT)
::Also, the consensus until now expressed by several people that previously discussed this is that this is not a bug. The main supporter of the bug argument seems to be Spike at the beginning but during the discussion but halfway the discussion he says: "I agree though that just because it's illogical does not prove it's a bug (i.e. unintended)" [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 20:54, 25 April 2015 (EDT)
You don't get to claim benefit of the doubt here, Tycho. All game features are assumed to not be bugs unless there is compelling evidence presented otherwise. You claim this is a bug based on the suppositional logic that more powerful weapons should cost more and almost nothing else. The price wasn't altered (and neither was the power) in TFTD, so there's no evidence of mistake there (as an aside, the Displacer/Sonic having its power listed as 130 when it's 110 in the game engine clearly ''is'' a bug). The only bit you might be able to interpret that way would be the description of the Hovertank/Launcher's weapon as causing "immense devastation" compared to the description of the Blaster Bomb as "highly powerful" (the potential implication being that the HWP Fusion Bomb is stronger), but that's iffy at best since there's hardly a graded table of adjectives in use and on those very same pages in the UFOpaedia it lists the damage of each weapon as what it actually is.

The claim that it's a bug is based entirely on theorising about yields. I've given alternate theorising that would explain the yields (and I already explained that the semi-automatic nature of the Hovertank/Launcher and physical space for its high ammo could justify the need for a smaller round), which undercuts that claim. We can't know who's right, but the assumption should always be that the designers knew what they were doing; to assume until proven otherwise that they had no clue is extreme hubris and contempt. Moreover, you are in a minority of one or perhaps of two against a majority of several. Your claim to representing consensus is blatantly false.

Now, I'm going to wait a couple more days to see if anyone comes forward with anything substantive, as I waited a week after my reply to your original non-refutatory dismissal, and then reinstate the removal if nobody puts forward a cogent objection. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 22:57, 25 April 2015 (EDT)
:Now that I think of it, though, an "oddities" page where we talk about this, the shitty Heavy Laser/Heavy Gauss, the No More Soldiers limit, and other not-bug things might be in order. It would help to make this page about actual bugs and not about weirdness that is nevertheless clearly as intended. Thoughts? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 23:04, 25 April 2015 (EDT)

:At the time, I didn't continue the argument as my point was that removing something based on one person's belief, no matter how cleverly thought out, wasn't good enough to warrant removing from the list. (I would have pointed out all the different theories on UFO interception AI, but I see that has already been removed.) I hadn't read all the discussions because I assumed that no consensus had been reached, similar to the Interception AI discussion. Mushroom, could have just pointed out that this issue was already settled years ago but no one bothered to removed it from the list, instead of resurrecting a "dead" discussion as though it had not been settled and just stated that the developers intended to discourage the use of this HWP by making the cost of its ammo high. I still don't agree that the HWP ammo is more efficient and thus justification for its production cost, especially since the developers would have never needed this level of justification or would have had the time to devote to so small an aspect of the game.

:I definitely agree that this page needs to be updated. Another reason I argued so strongly is because so many topics on this page do not fall into the category of bug as has been defined. I thought this page was also devoted to listing all the illogical aspects of the game due to the lack of enforcement on the definition. [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]])

::If I only had a dime for each time someone proposes to change something on this wiki, everyone agrees, and then nobody ends up taking action... :) It's always better to take initiative and edit things. I agree also with an update to this page, and separating bugs from limitations. But definitely no more 'this should have been done this way' arguments to present design decisions as 'bugs' [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 17:43, 26 April 2015 (EDT)

:Okay. I'm planning to rip out the following and stick them on a separate page:

:Great Circle "bug" (this isn't really a "bug" so much as unoptimised code)
:Side-on Intercept "bug" (ditto, but given UFOs' tendency to alter course suddenly it's not even particularly unoptimised)
:Head-on Intercept "bug" (come on, this is just bitching)
:Instant Getaway "bug" (more an anomaly than a bug)
:80-item limit (intentional and the rationale is obvious to boot)
:Purchase limit (working as intended)
:Soldier recruiting limit (being charged for attempting to buy more is a bug, but the limit itself isn't)
:Soldier battlescape limit (there's a consequence of this which is a bug, the CtD with 10+ tanks, but not the limit itself)
:Manufacturing Completion Time Display "bug" (you can look at it and see what time it finishes, and it goes down at the right rate; it may seem a little unintuitive but it isn't "wrong")
:Manufacturing Rate Interruption Loss "bug" (more bitching)
:Manufacturing Rate limit (working as intended; the attempt to get around it in TFTD is bugged, but the EU behaviour isn't)
:HWP Fusion Bomb Ammo Cost "bug" (we're in agreement here it seems)

:There's plenty that need a tidyup on top of that but as far as the page split itself goes, are we agreed? Also, I'm thinking of calling the page "Anomalies and Game Limits", opinions? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 01:58, 3 May 2015 (EDT)

== DOS4GW - What the heck is it? ==

It's been ages since I had to remember this stuff, so those who remember clearer than I do, forgive me if my descriptions aren't accurate. Hopefully the general idea will come across.

Back in ye olde days of computere gamynge - and where there were more E's to go around, memory handling was a tricky beast to handle. Computer memory is divided into several different categories. Conventional, extended and I think expanded. I might be jumbling the terminologies for the last two a bit. Doesn't matter - memory was just cut up into small segments. The two most common memory types to PCs at the time were pretty small but were readily available. The third one - the most expandable (aka the chip with its massive 4 Megs of RAM you just spent your whole month's allowance on!), wasn't as easy to get at.

To get access to the higher memory that was available to the computer, special memory handlers had to be used. Drivers like HIMEM, emm386, etc were used.

DOS4GW is one such handler that lets the game access the computer's available expanded memory. Lots of games that came out at the time use this. Doom, Duke Nukem 3d, Syndicate, Ultima Underworld, X-Com UFO/TFTD, etc. LOTS of games. Any time you ran a game from the dos console and you saw the Dos4GW message flash by briefly it would be assisted by it (well, it stayed on the screen for ages back when processors were slower!).

It took the hassle out of memory handling and let the game access the available memory on the computer as one big flat block of memory to play with.

So what was meant in the article was to simply replace the dos4gw.exe with a more up-to-date version from another game. I think the way to tell its version was just in the message that it displayed. You can just run the dos4gw.exe file in a console window. It'll give an error, but the message it shows will indicate its version. UFO 1.4 uses Dos4gw 1.95, for example.

-[[User:NKF|NKF]] 01:22, 6 March 2009 (CST)
:DOS4GW also switched the processor from 16bit to 32bit mode. [[User:Seb76|Seb76]] 13:58, 6 March 2009 (CST)

== Clipping ==
I have a new bug. Its harmless. I have a savegame (EU CE - modified game) which has a sectoid within another sectoid. In the alien turn, one secturd walked off the roof and dropped down <s>onto</s> into another. (I guess there DNA is indentical afterall, so they 'become one' with the world). If you want the savegame (superhuman edited using UFOloader, UFO Mod v1, xcomed, Khor Chin WeapEdit v0.1) drop me a request on the my page somewhere. [[User:EsTeR|EsTeR]] 01:40, 18 September 2009 (EDT)

: Not something many would encounter, but definitely something that can happen. Units can occupy the same physical space, but the game cannot display them all. It'll only draw one of them. Actually saw this effect happen back in the early days of XComutil when it gained the ability to manually add new aliens into a battlescape. It did this by slotting them into the same spaces occupied by existing aliens. Then the fun would happen when you saw a couple of Mutons suddenly walk out of a sectoid. Not sure how the game determines who gets hurt when struck by a bullet. May very well depend on the order they are stored in the unitpos.dat file.

: There are a couple of ways you can replicate this in-game, but I can only provide theories on how you could do it. Such as shooting the ceiling above you and letting the unit drop through, or moving a tank off a ledge and getting its non-primary segments land directly on top of another unit. By the way, the rear end of tanks get stuck in walls if you attempt to move north or east off any ledges. -[[User:NKF|NKF]] 02:18, 18 September 2009 (EDT)

: Ok, so as long as others know about this, then all is good. I had never seen it and was doing alot of head scratching until I shot the alien.

== Berserk HWP crashes the game ==
In the article page it mentions that aliens which go berserk with their integrated weapons will crash the game. This is only true for Mind Controlled aliens (or units under X-COM control) - alien controlled units which go berserk do not crash the game. I tested an MC'd Celatid just now and it doesn't crash the game either, though it doesn't immediately go berserk - it waits another turn for some odd reason. Someone want to check this to verify my results? --[[User:Zombie|Zombie]] 20:31, 27 December 2009 (EST)

==HWP Morale Loss==

HWPs have 110 Bravery, which [[Morale#Effect_of_Bravery|normally prevents morale loss]], but I wonder if they can still lose morale due to loss of units with a morale-loss modifier. It'd depend on how the math is done. If, for, example, the -20 to morale for a dead unit is static, then multiplied by any [[Morale#Officers|morale loss modifier]], then reduced by 2 for every ten point of bravery, any officer death without another officer on the field will necessarily reduce HWP Morale.

It all depends on how the equation plays out and when modifiers are added. For sake of this post, I propose the following as the morale-loss equation: 20*(rank death modifier)-((Bravery-10)/5)*(1.00-Leadership bonus)=Morale Lost. (Rather than using 22 as a base, I'm going to assume Bravery is internally decremented by 10 for this equation as 0 Bravery is impossible without editing and it makes the math easier for the purpose of the example.)

It makes sense to me that rather than having 110 bravery hard-coded as an exception to "No morale lost", it simply works the same way in the normal equation, but is high enough that it negates most morale loss events, as even if an officer is killed, another officer is usually left on the field to help negate the penalty. That said, if a large portion of the team is wiped out at once, any surviving officers may not be able to negate it all, allowing tanks to start having noticeable morale loss.

So with the death multipliers, we can determine that every XCOM officer killed has a set death value. Rookies and Squaddies are -20, Sergeants are -24, Captains are -26, Colonels -30, and Commanders -35.

For example, under this theory, if a Sergeant is killed with no other ranked units on the field, a Squaddie with 50 Bravery would lose 16 Morale. (20*1.2-(50-10)/5*1.00=16). A HWP would, at the same time, lose 4 morale. The Sergeant's death is worth -24 Morale, and without another officer on the field to ameliorate the loss, the Tank's bravery only can 'absorb' 20 points of the morale lost. If it was instead the Commander lost, with no other officers on the field, the HWP would lose instead 15 points of morale, given that a Commander's death (20*1.75) is worth a whopping 35 points of morale loss if no other officers are present.

And if you have, say, four colonels and the Commander on rear/psi duty, and some alien flings a grenade or a blaster bomb into the back of the Skyranger and blows all three of them up and they were the only officers, the HWP has now lost 55 morale, which gives it a 10% chance of panicking/berserking on the next turn!

In the end this'll probably need to be tested for accuracy, but those are my thoughts right now.

Also, for the record, most units that berserk go to 255 TUs while still using the original TU-expenditure calculations; it's part of what makes berserk units so dangerous. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:34, 11 January 2012 (EST)

:Tested it under vanilla CE. Took a squad out containing just about every rank there is (commander + colonel + captions + sergeants), plus a tank. Blew up and killed all soldiers with a single blaster bomb shell, leaving just the tank, which lost no morale (sorry).

:I also brought a group of rookies along with a single commander + tank, and killed just the ranked unit. Tank lost no morale. A rookie with 60 bravery lost 17 (which matches the loss predicted by the formula currently on the morale page), whereas under your formula he should've lost 25.

:Still, you're on the right track. I've long had my own theory as to why tanks have been known to lose morale. Take a look at [[UNITREF.DAT#42|UNITREF.DAT[42]]] - this is the offset that stores a unit's rank. Notice something? The value gets higher as the X-COM unit's rank gets higher. Works in ''reverse'' for aliens, for whatever reason. I sorta figure it's so killing a mind controlled alien commander doesn't mess with your morale too badly, but there's a big problem with that theory and you can probably tell what it is...

:If the highest this figure gets for an X-COM unit is 5 (commander rank), then a killing a mind controlled alien ''terrorist'' with a rank value of ''7'' should net an even higher morale loss penalty. And indeed it does - I took a rookie and a tank to a terror mission, mind controlled and killed a terrorist, and the tank lost 10 morale. Guess it would've lost six if I'd taken a commander instead of a rookie, but that's still something.

:Note that the formula on the morale page does ''not'' account for this - it states that at bravery 110 the alien's death loss multiplier would always be applied to a base morale loss of 0, but that's obviously wrong. You're spot on in saying that the base morale loss figures are not totally dependant on bravery, and the "death loss" penalty is applied first. Would probably require a few more trials to determine what that penalty ''is'' for alien soldiers and terrorists though.

:Just for kicks, I edited a plasma tank to have 0 morale. It panicked in the normal way (either sitting still or charging off to the SE). When it berserked, the game crashed as soon as I dismissed the status message. - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 18:54, 12 January 2012 (EST)

:: Thought I'd give it a spin. I sent a laser tank in with a squad and had it start shooting at team members. Each time it killed an ally, it would lose morale. Once it was under 50 morale, I waited until it panicked. Since I was playing the dos version, the game didn't crash but I suspect a memory leak of some sort may have occurred that would normally shut down the CE version. What would happen in CE if a soldier were to be edited and granted a tank turret, and then made to panic? Would the game crash? I'm just wondering if it's related to the weapon as opposed to the fact the tank is a treated as a large unit. -[[User:NKF|NKF]] 00:43, 13 January 2012 (EST)

::: Ah, friendly fire! Thought I'd tested for that, but obviously not...

::: Oddly enough, now that I try it, I see that the twenty point hit for killing a unit on the same side can be adjusted by the leadership bonus of the victim. Eg, kill a lone commander and his 35% penalty reduction takes the extra morale lost from 20 down to 13 (which is exactly how much a tank will lose, given that it otherwise wouldn't lose any at all).

::: Of course, this completely messes up my theory about alien soldier/terrorist ranks overriding the 110 bravery score. It doesn't. My tank "only" lost 10 morale because the alien's rank acted as a 50% leadership bonus... Though I suppose that's still interesting to know, because it suggests that keeping a simple alien soldier under mind control is more effective then risking your own commander in the field.

::: I took an otherwise unarmed rookie and assigned him a tank cannon + ammo. He could manually fire this weapon in much the same way a tank can. Forcing him to berserk crashed CE, under DOS he just spun around. - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 21:20, 13 January 2012 (EST)

== 80-items limit on CE edition ==

I have the feeling that the 80-items limit does not apply to the CE edition and is instead a 110-items limit (at least during base defence). Can anyone confirm? [[User:Seb76|Seb76]] 16:24, 24 February 2010 (EST)

:I believe this limit was increased for TFTD. Maybe it was also increased for the CE edition of UFO, and only ever applied to the DOS edition of UFO?? [[User:Spike|Spike]] 20:03, 11 March 2010 (EST)

== Paying for Dirt in TFTD ==

I have the steam version of TFTD and am unable to replicate this bug. Testing with the starting base, I dismantled a few modules, added up my income and expenses, and it reconciled with my cash at the beginning of the next month. I even tried again, dismantling every module except the access lift, and once again saw no income discrepancy. Am I missing something, or is it possible this bug was actually fixed in TFTD? --[[User:Jewcifer|Jewcifer]] 12:18, 16 March 2012 (EDT)

:'twas probably fixed. It would indeed be helpful to add a small note to bugs on this page which are EU-specific but not obviously so (like this one). - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 17:14, 16 March 2012 (EDT)

::Every now and then I get the urge to test some of the more important bugs myself in my steam version of TFTD. Perhaps I will make a more complete effort and record the results somewhere on the wiki. --[[User:Jewcifer|Jewcifer]] 12:08, 21 March 2012 (EDT)

== Paying for dirt: Source of bug discovered! ==

Well, I never have read this anywhere (which kind of strikes me as odd, thinking of how obvious this one seemed to me... And i have NO programming background whatsoever), so I'll post it here, hoping that there are still some active members willing to try and verify my findings. If so, please comment here, because then I will inform bladefirelight to include this in any upcoming xcomutil release. If it had been discovered before, well then I just wasted some time here. Comment below, I will delete this entry.

As the main bug page mentions, when dismantling a facility still under construction the premium will only be paid once it would have been finished. This suggests some connection between paying the premium and building time. Looking into the infos here: [[BASE.DAT]], I quickly discovered what the problem was: When a facility is dismantled, the Bytes related to the location of base facilities are updated correctly. HOWEVER the game omits to update build time to FF (which is "will never finish", an entry only found on unused squares). If the facility is finished when it is dismantled (or destroyed during combat), then the 00 in the build time byte will stand. If it was under construction, the value indicating the remainig build time will continue to tick down towards 00 as if the facility was still there.

Now at the end of the month the following seems to happen: The game checks for ANY 00 entry in the build time bytes, and if there are 00 entries, it will look up in the location bytes the type of structure to determine the amount of maintenance for that 00-construction-time-square. When it finds "dirt", then it will charge the 80 grand (my guess would be that those are somewhere hard-coded).

This explains all phenomena related to this bug, like a dismantled hangar costing 320.000 grand or the premium only popping up after the build time of a dismantled facility that was under construction has expired.

Now the fix is pretty easy: Open the BASE.DAT in a hex-editor and change the bytes in question to FF!

== Minimized Interceptor Bug (Ufo CE) ==

Maybe this bug is not just related to saving, because I had a similar problem last night. The game didn't crash, but it kept restarting the same Battlescape mission.
One Avenger (A-3) was pacing a Battleship, while another Avenger (A-1) was sent to pick up the pieces of a Terror Ship that had been shot down by an Interceptor. Despite having no weapons (oversight on my part), A-3 wanted to attack the Battleship, but I minimized the screen, hoping it would land.
While the screen was minimized, A-1 landed at the Crash Site from the Terror Ship and started this mission. Right after finishing it, I got the message that A-3 was ready to land next to the Battleship. Happy that I'd get the loot, I started the mission.
After cleaning it out, I got the usual Loot and Promotion screens and went back to the Geoscape. A few seconds later, I was back in the equipment screen and the Battleship Mission started again. I played it once more, because - hey - additional loot, right? Err... no. At the end, I got the correct Loot screen for this attempt and the very same promotion I had gotten in the first attempt (A Rookie from another base promoted to Sergeant).
Got back to Geoscape and a few seconds later back to the Equipment screen. I aborted this mission (same Battleship again), got back to Geoscape and - you guessed it - back to the Equipment screen. After aborting this mission as well and getting back to Geoscape, I used the few seconds I had to go to 'Options' and 'Abort Game'. Maybe I could have made A-3 disengage from the Battleship since I think I saw them both on the Geoscape, a yellow diamond and a red plus, but it was pretty late by that time.
--[[User:Matzebrei|Matzebrei]] 15:06, 15 May 2012 (EDT)

This is a known bug. There is a work around. You should patrol the ship with troops and not land... Finish shooting down the other airborne ships first. Then when the ships doing the shooting are returning to base, change patrolling ship with troops to advance to downed ship in order to commence ground combat mission.
--[[User:JGF|JGF]] ([[User talk:JGF|talk]]) 07:55, 9 November 2016 (UTC)

== Activity Overflow Bug ==

This is a potentially campaign-ending bug. This was seen in the Steam distribution, DOS version (on Windows 2003 Server EE). Not sure if UFO Extender was being used - probably it was. End of Jan 1999 turn shows an extreme negative/underflow Monthly Rating score, which in turn is caused by extreme overflow of UFO Activity levels. Note that that funding "score" - the increased funding by countries - was very positive at the same time!:

[[File:dissatisfied customers.png]]

UFO Activity, by Areas and by Countries, is literally off the chart. Clearly some kind of integer overflow:

[[File:ufo-areas.png]]
[[File:ufo-countries.png]]

X-Com activity is also off the chart:

[[File:xcom-areas.png]]
[[File:xcom-countries.png]]

In addition to the likely outcome that I will lose the game in Feb 1999, it means I can't use the graphs to detect UFO activity outside of my radar coverage.

I have only seen this bug once, and (probably very unusually) I am running under Windows 2003 Server EE (!!). My hunch would be that's the cause, Windows 2003 Server is not the best games platform. :)

[[User:Spike|Spike]] 07:22, 3 September 2012 (EDT)

Further information:

I don't necessarily lose the game in Feb or March 1999. The Monthly Ratings from Feb onward are just based on the current month, not historical score to-date. However it still greatly increases the risk of suffering from the [[Known_Bugs#Losing_My_Favourite_Game|Losing My Favourite Game]] bug - which also greatly complicates doing too many controlled experiments on this Activity Overflow bug, because a few restores of the saved game quickly leads to X-Com Project termination (and humanity's doom).

Possibly the Activity Overflow bug is caused by an initial value of the score (or an array of score values) not being correctly zeroed at the start of the game. See this graph, which shows a negative score in May 1998, prior to the start of the game in Jan 1999.

[[File:Prehistoric_negative_score.png]]

[[User:Spike|Spike]] 08:48, 3 September 2012 (EDT)

I encountered the same Activity Overflow Bug in Windows 7 using Steam version, Windows option with UFOExtender latest version.

[[User:Humbe|humbe]] 2012.10.04 09:05 UTC

I encountered the same bug at end of january with latest xcomutil patched CE version (with only bug fixes patched) with ufo extender newest version running (close to default options). Got many saves from that first month. Even if loading very early save where I had done no missions yet, and just did stuff in base, graphs still show negative for various periods in 1998. Sounds more like corruption than something actually overflowing to me.

[[User:Archlight|Archlight]] 18:34, 24 September 2012 (EDT)

== Bad Paths Bug ==

I suggest to add bad paths on UFOs maps to the article, as another bug in the game.

[[User:Sherlock|Sherlock]] 09:25, 26 December 2012 (EST)
:That sounds reasonable to me. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

==Expenditure Graph==
The economy graph for "Expenditure" neglects funds spent on new facilities. I noticed this in my current (DOS) game when I built eight Psi-Labs at the start of April and it didn't increase. I know it counts everything on the Purchase screen; I'm not yet sure whether it counts manufacturing costs.

Is this enough of a bug to be mentioned? Can anyone confirm whether or not it occurs in CE, and whether it counts manufacturing costs? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:40, 17 May 2016 (UTC)

==Workshop Crowding==
It seems there is a bug whereby you can allocate more projects/engineers than available workshop space. This can be triggered by setting up two concurrent manufacturing jobs, setting one of them to have 0 engineers working on it, then set the other to have as many engineers as you can assign to it, filling the workshop space. Then go to the other job with 0 engineers, and it will show a negative workshop space available, now if you assign at least one engineer to this project, you can assign the rest of your engineers however you please.

This is my first edit. I find it hard to believe I'd be the first to find this bug after so many years, can someone please confirm a reproduction and that it isn't documented somewhere I've missed? I am running the DOS version of UFO, but I'm also running XComUtil, not sure if that has an impact, or what patch level I'm on. - [[User:Uncertainty|Uncertainty]] 11:00, 20 Dec 2016 (AEDT) Update: Cannot reproduce on the CE version, still unsure of the patch level of the DOS version I'm running and don't know how to accurately determine that. - [[User:Uncertainty|Uncertainty]] 22:00, 29 Dec 2016 (AEDT)

: An easy way to check is whether you can research Magnetic Navigation after collecting one from an alien sub, or if you have to research a Lobsterman Navigator beforehand. If you can research it right away then you have v2, which is what the CE version is mostly based on. If you can't research it and must get the navigator, then it's the unpatched copy of the game. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 22:24, 29 December 2016 (UTC)

Update 2: Thanks NKF, I'm not running TFTD, but I figured out that I was running v1.2 of XCOM1. I cannot reproduce the bug on v1.4 so the bug only applies to v1.2 and has been patched in newer versions. - [[User:Uncertainty|Uncertainty]] 16:45, 31 Dec 2016 (AEDT)

=Cleanup needed=
Hmm this whole Talk page needs a cleanup. A lot of the Not Listed bugs, should be listed, or are listed. [[User:Spike|Spike]] 10:03, 26 December 2012 (EST)

:So, before it will be made, yet three more observations.

:1. There is no possibility to give back (to stop hiring) a plane without craft weapon.

:2. Alien Reproduction is unavailable in a normal game without hacking/save editing. This is probably connected to further errors on maps. A bug/error/programmers' oversight of the some kind is present in TFTD where it is impossible to obtain Examination Room. It is so because many tiles on maps are wrongly assigned to game's objects. Namely, [[Examination Room (TFTD)]] is treated as Alien Implanter - but there is plenty of errors of this type, on various maps (perhaps also in UFO: EU).

:3. Among soldiers in UFO:EU, there are Russians. Some non-Slavs may not know that Slavic (also Russian) family names have different masculine and feminine forms. For example, Petrov, Belov, Likhachev, Gorokhov, Chukarin, Andianov, Voronin, Maleev are all masculine names; women must be called Petrova, Belova, Likhacheva, Gorokhova, Chukarina, Andianova, Voronina, Maleeva respectively (however, a rule that the feminine form is always made by adding -a is wrong, e.g. Tolstoy - Tolstaya). The soldier's name Mikhail Gorokhova (which is possible in UFO: EU) is just ridiculous (for everyone who has even little knowledge about Russian things). Tatyana Petrov is also an impossible combination. X-Com creators probably assumed that family names are the same for men and women in all languages, and, as a result, they made only mechanisms for storing masculine and feminine forms of first names, not family names. But taking reality under consideration, this is a bug.

: [[User:Sherlock|Sherlock]] 16:22, 26 December 2012 (EST)

== Common bugs vs. UFO EU specific bugs ==

I believethere is one more thing that needs to be cleaned. Namely, both EU and TFTD share the same game engine, so some bugs are common for them both. However, there exists a page with a list of TFTD bugs, and it is clear (or: should be clear) which of the bugs are specific for TFTD. I think the same should be done with EU specific bugs: to hold them apart from bugs common for both games. Some bugs exist in both games but manifest themselves differently (like problems with mind-controlling of big aliens) - they are not true common bugs.

Or even more: one could expect a clear information by each bug, in which game and in which version of the game the bug occurs. And whether a patch exists or not. Sometimes such information is given now, and sometimes it is not. And if one does not know exactly which versions are affected by the bug, it should also be mentioned clearly.

[[User:Sherlock|Sherlock]] 04:13, 27 December 2012 (EST)

== Rename page title to indicate which game this refers to? ==

I was looking for a list of bugs related to XCOM Apocalypse, and it took me a while to realize this was about a totally different game. There are 4 games (not counting the 2 opensource projecrs) here on UFOP - maybe that could be reflected in the article aswell?
[[User:Panzerlol|Panzerlol]] 20:35, 31 March 2013 (EDT)

==New "bugs" submitted directly to main page with no apparent explanation==

WakkaDakka, have you actually managed to replicate this "missing time units" bug, or was it just a one-off freak occurrence? I'm not sure it merits main-page space until we have some idea how to replicate it.

N21, how were you seeing the future to begin with? It's only a bug if it occurs in the normal course of play.

[[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 03:36, 28 May 2015 (EDT)

== Enemy Unknown 1994: Save game bug mid mission. ==

Effect : Loading saved game mid mission just displays a black screen with the cursor at the top left, whilst the music continues to play in the background.
I don't believe the game has crashed out to DOS, having tried both CLS and DIR to no avail. Your can no longer interact with the game, making you force quit the app.

[[File:Screen_shot_2016-11-07_at_19.39.31.png|thumb|left]]<br clear="all">

I'm using Boxer 1.40 on a Mac - which in turn is built off Dosbox 0.74.
I remember seeing this bug years ago on Windows XP too, so I don't think it is platform specific.
I'm currently running it with some of the XCOMUtil patches too - but have had the issue crop up without any of the patches.

Playing on Superhuman level, I use a Skyranger with 14 soldiers equipped with Laser Rifles.

Cause : Hard to be specific. But here are the facts.
I have my suspicions it may be do to with fog of war rendering issues.
I've had it occur frequently when going to the NW edge of a map.

Corruption of the save, seems to coincide with crossing a threshold of a number of actions on a number of soldiers within a turn. After the threshold is crossed each attempt to save on subsequent turns mid mission are all corrupted, leading to the possibility of filling all 10 game slots with trashed saves, forcing a restart of the game from turn 1!
As long as you don't cross the threshold before saving, and there is one remaining action that would corrupt the game on a given turn, progressing to the next turn seems to reset the count on the number of actions, so you can perform multiple actions instead of one the next turn.

Here is a sample save game where the game only needs one specific movement to corrupt a game when you save after the move.

[[File:GAME_10.zip]]
I've uploaded two images to show the move for S Bradley
[[File:Screen_shot_2016-11-11_at_13.50.13.png|thumb|left]]<br clear="all">
and the destination square to move him too. When you complete that move and save the game it corrupts.
[[File:Screen_shot_2016-11-11_at_13.50.17.png|thumb|left]]<br clear="all">

Incidentally there were two downed UFO's at this time, with a second Skyranger en-route to UFO 42. This mission was for UFO 43 with another Skyranger.

The problem frequently occurs.
Ive had it occur recently on the following types of mission:
Terror, Alien Base, Supply ship, Large Scout, predominantly with Sectoids and Cyberdiscs, but also with Mutons and Floaters.
The only thing all these missions have had in common was lots of units on both sides. For example 13 Floaters on a Scout mission, 9 Cyberdiscs on a Terror mission etc.

--

Other quirky things I've seen relating to Stunned units:

1) You can't stun a unit, forcing you to shoot it to complete the mission.
The target being stunned drops to the ground in a heap, but the game says you can still see it and can re-stun unit....

2) Celatids. You stun it, then it wakes up and moves away. The unit no longer renders correctly. It's like a sheet of garbled colored/transparent dots.

3) A stunned unit, other than a Celatid wakes up, and is invisible but you get the '1' in red square for visible enemy. You can stun unit and get the animation for it falling to the ground again.

--

Teleported unit off screen (notice the yellow arrow over the unit, which alas is invisible at the split second I took screenshot - OS/X rendering crap-shoot).
[[File:Screen_shot_2016-11-12_at_14.18.07.png|thumb|left]]<br clear="all">
The unit was teleported from the top of the stairs in an entirely different building, rendering the unit unusable for the mission. I ended up reloading it and doing over.... - [[User:JGF|JGF]]

:Stop spamming [[Special:RecentChanges|the changelog]], please - if you're working on a page and want to see the results of your edits midway through, use the Preview button. Don't hit Save until you are ''done''.

:I can't replicate any issues with your provided save. Bradley doesn't have enough TUs to "complete" the requested move, but asking him to make the attempt anyway, then saving / reloading, works fine for me under 1.4 as well as CE. For what it's worth, as far as I'm aware the game in no way keeps track of the number of actions you've performed during a given turn; at least, I haven't been able to find any such counter embedded in the save files.

:I do suggest you leave your units with more time units - when ending turn, any agents who ''might'' spot an alien during the enemy's turn should ideally have some cover, a kneeling stance, and enough action points to defend themselves with a reaction shot. Using your full TU allocation on movement is somewhat suicidal, and even when you can get away with it, it tends to leave agents without enough energy to move when they really need to.

:Your invisible units may be related to [[Known_Bugs#Invisible_Chryssalids|this bug]] - presumably you can trigger similar behaviour by knocking out all instances of a given alien species within a map, saving / reloading, and then waiting for one of the aliens to awake. I was able to replicate it with an Ethereal, for example.

:Difficult to comment on your garbled Celatid without seeing it first-hand. Ditto for your un-stunnable target. I'd quite like to inspect them with my save editor, though, and ditto for the teleported unit. - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 05:46, 13 November 2016 (UTC)

Thanks for scaling the images nice to see the wiki syntax.
It's odd to here you say he didn't have enough Time Units left, because for me the move is allowed.
Where did you get your 1.4 patch?
I applied 1.4 too and am wondering if I got a bad version.
Also did you get your original XCOM off GOG or some place like that?
I have the original CD. I think it's the US version as I used to live there.

== Time Units reset to 0 when soldier reaches 255 TUs ==

I have been playing an old version of UFO: Enemy Unknown, where there is no limit on TUs for soldiers. At certain point, two of my best soldiers reached the limit of 255 TUs, which rendered them useless at now they have 0 TUs.
I tried to reduce their TUs by editing Soldier.DAT, but it did not help. If I check soldiers from the base menu, I can see that the value has been changed, but in the battle their stats are still the same and thus they have 0 TUs and cannot be moved with.

Do any of you know, how to fix this bug? Where is the limiter located, can I change it so that is will be as in the new versions? In any case, I believe this bug should be mentioned on the page. It is mentioned here though: http://www.ufopaedia.org/index.php/Time_Units --[[User:Achernar|Achernar]] ([[User talk:Achernar|talk]]) 21:13, 9 May 2017 (UTC)

: Feel free to add the issue - the page is a hodge podge of whatever issues folks have at the time or as they come across them.

: While I'm no expert on the file structure of the executable for the first release of the game, I suspect you'll find the cause for the byte roll-over feature is that there were no stat limiters to begin with. Best way to cope with it is to either retire anyone approaching supersoldier status to base defence duty, buy more soldiers and spread the experience out more evenly, or update to 1.4 and find a sound patch to restore the original sound samples.

: For your broken soldier: I'm, assuming you edited the soldier.dat file. If you saved the game while in the battlescape, the game creates a temporary copy of the soldier stats and keeps them in unitref.dat. This is to keep track of in-battle status changes, experience, etc. You'll need to edit the current TU levels in this file as well. Or beat the mission with the soldiers that can move and you'll see your edits reflected in the next battle. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:45, 11 May 2017 (UTC)

== Fire rate bug & German version footsteps ==

These don't seem to be documented for some reason: (DOS Version)

The fire rate always resets to 3 if an alien or an alien mind controlled unit throws a grenade.

If German is chosen as language to play, the footsteps of all soldiers, regardless of the terrain they walk on, will sound as if they are walking on a metal surface like the inside of the Skyranger, UFO or the base. [[User:Bard|Bard]] ([[User talk:Bard|talk]]) 05:38, 8 April 2019 (CEST)

== Direct incendiary hit causing no reaction fire? ==

On the Incendiary page, it is reported that a direct hit will not cause an alien to spin around and return fire. I have tested this in OpenXcom and find that the aliens do, in fact, return fire. If this can be confirmed in original X-Com, it would be good to add to known bugs.

: It's safe to say everything you find on this wiki relating to the classic game pages were gleaned from the original games. OpenXcom, being an independently developed fan project, will have its own list of fixes and changes chronicled in its own documentation. In fact I would not be surprised that good deal of the more technical information on this wiki has been contributed by those that had some input into the OpenXcom project. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 05:16, 8 June 2021 (UTC)

:: Thanks, good to know. Would still love to know if anyone has tested this in classic game. If not, I will when I can, so it can be added to known bugs [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 22:05, 15 June 2021 (UTC)

Talk:Known Bugs

2021-06-03T07:28:38Z

Mugwump: /* Direct incendiary hit causing no reaction fire? */ new section

Talk:Hiring/firing

2021-06-01T21:07:57Z

Mugwump:

I just ran into that problem, Spike - thanks for the tip on the Stingray! ---[[User:MikeTheRed|MikeTheRed]] 22:09, 3 June 2006 (PDT)

----

And on a completely unrelated but otherwise interesting note, transfer of a troop transport.

Transferring a troop transpot will transfar all the equipment in it as well as all the soldiers assigned to it to the next base at the simple cost of the troop tranport's transfer cost (not much of a point with soldiers, as they cost $0 to transfer, but good for the weapons).

You must have enough beds available at the destination in order to transfer the troop transport and all its crew.

It's nothing terribly special and is only a real benefit from a logistic point of view. You get to cart your favourite teams all around the world and not have to transfer them one at a time - clogging up the transfer table. Not that most of us will use up the transfer table...

Still a minor tidbit worth knowing.

- [[User:NKF|NKF]]

----

Everything in the transport thus only needs one line item out of the 100-item transfer queue? That's good to know if you're doing high volume recruit screening! Heck it can even be a way to get "around" it... a "Tip" to transfer equipment in a transport. Thanks for pointing that out!

---[[User:MikeTheRed|MikeTheRed]] 04:10, 5 June 2006 (PDT)

----

When you recruit staff, if the month ends before the personnel arrive do you pay their salary? Or only personnel already in your base ready to use?
[[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:52, 27 May 2021 (UTC)
:Nope. You can use this to avoid paying salaries all together. On the last day of the month transfer all your scientists/engineers from one base to the other, and since they're on transfer you don't have to pay their salaries. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 03:12, 1 June 2021 (UTC)

:: Thanks. That prompted me to look at the OpenXCom differences page and see that the bug is fixed there! Think that should be mentioned on the hiring/firing page? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 21:07, 1 June 2021 (UTC)

Talk:Reaction Fire Weapon Preference

2021-06-01T18:40:46Z

Mugwump: Created page with "Is that left-hand as we are looking at in on inventory menu? That would be soldier's right hand? Perhaps that should be made explicit in main page ~~~~"

Is that left-hand as we are looking at in on inventory menu? That would be soldier's right hand? Perhaps that should be made explicit in main page [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:40, 1 June 2021 (UTC)

Talk:Base Defence Systems

2021-06-01T18:24:32Z

Mugwump: /* Monthly Score */

I added some info about TFTD to the article since it talks about TFTD too. I noticed though that some of the info conflicts with [[Base_Defense (TFTD)]] article. e.g. here it says the item limit has been raised to 110, there it says the limit is still 80. Anyhow, I can verify there's a sorting algorithm from my experience, but not much further. I wonder if it may end up preferring unresearched guns for example.. [[User:Cesium|Cesium]] 20:02, 30 December 2009 (EST)
:Hadn't realized that there was a page for TFTD. I just corrected it to 110 (this number is actually from the Unofficial Strategy Guide but from what I recall it is correct). About the sorting algorithm I can't confirm it. [[User:Hobbes|Hobbes]] 20:40, 30 December 2009 (EST)
::I just ordered a lot of Jet Harpoons, Dart Guns and Chemical Flares to a base and let the aliens find it. The equipment available in the load screen was mainly Sonic Rifles and Sonic Cannons. The Darts, Jets and Flares were not available. Something has to account for the quartermaster being sane, and we do know some attention was given to base defense (since the item limit was raised). I guess only way to be sure is for someone to disassemble the executable and examine the code.... [[User:Cesium|Cesium]] 09:35, 31 December 2009 (EST)
:::Well the quartermaster is mostly sane. However it does not check if you have researched the clip before it packs the shiny new Sonics. So be sure to move them out if you have not or you might end up with lots of guns without ammo. If you want Medikits be sure to reduce the number of spare weapons--[[User:Tauon|Tauon]] 19:32, 16 October 2010 (EDT)
Not sure the 110 number for TFTD is technically correct. When I try to load more than 80 items on a craft I still get a warning. --[[User:Zombie|Zombie]] 22:31, 30 December 2009 (EST)
:The limit for weapons being carried in craft is still 80 but for the base defense missions the game allows for 110 items. [[User:Hobbes|Hobbes]] 22:56, 30 December 2009 (EST)

== Penetration Math ==

"...Missile/Torpedo Defences are the most cost-effective of the defensive base facilities. The odds of penetrating 12 such modules and a Grav/Bombardment Shield are 30 to 1. On average, 30 attack ships will be destroyed before one gets through. Such a system costs $3.7 million. For the same price, 3 Fusion Ball/P.W.T. Defences with a Grav/Bombardment Shield will offer only 9 to 1 protection..."

Huh? Where is this math coming from? From the way I understand it, it's a simple binomial distribution (at least for exclusively one type of base defense module).

In order to bring down a battleship (3200 hits) you need to connect 7 rounds from a missile defense (500 damage). With 12 missile defenses and a grav shield, you have 24 bernoulli trials with a 50% probability of success. The probability of 6 successes or fewer out of 24 trials at 50% I believe is ~0.01133, or 1 out of about 88 ships getting through your defenses. I calculated this in excel via =BINOM.DIST(6,24,0.5,TRUE) so I am confident it is correct.

In the fusion ball case, I believe it is 2 or fewer successes out of 6 trials with 80% probability, =BINOM.DIST(2,6,0.8,TRUE), 0.01696, or 1 out of about 59 ships getting through.

While the original point still stands with my math (missile is more cost effective than fusion), the odds of penetrating either setup are greatly reduced, as is the difference between the performance of the two. Perhaps I do not properly understand the mechanics of base defense modules, or screwed up my thinking or math somewhere along the way.

--[[User:Jewcifer|Jewcifer]] 12:57, 16 March 2012 (EDT)

:I'm not sure if the page mentions it (I've only got time for a quick skim right now), but to further complicate matters the amount of damage the defences do per-shot is randomised. I think it goes from about 50% to 150% of their rated power, can't remember if I was ever able to confirm an exact range. Seven shots from a missile defence may not be enough to down a battleship. - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 17:39, 16 March 2012 (EDT)

::Hmmm, I have seen no mention of variable damage either in-game or anywhere on this wiki (I've been reading through it quite extensively for months before finally getting around to signing up a couple days ago). I think that information should be determined and put somewhere (this article is probably as good a place as any for it). I'm not likely to do that myself (would probably require either extensive simulation or disassembling and hunting through the executable code to determine the range?), but if anyone else does I will run the different calculations appropriately. If the range is 50%-150% it should be only slightly more likely for ships to penetrate in these cases (but not nearly enough to account for the discrepancy), but perhaps if the range is more like 50%-100% (like craft weapons) they would match up with what's in the article. --[[User:Jewcifer|Jewcifer]] 12:24, 21 March 2012 (EDT)
:::I am 100% sure that damage to UFOs from base defences is variable. I have seen Battleships both die and not die from 2 hits with a Fusion Ball Defence while I was using the Battleship Farming exploit. [[User:Magic9mushroom|Magic9mushroom]] 18:19, 21 March 2012 (EDT)

:::Indeed, a defense module may deal more then 100% of its rated damage. I've seen two fusion ball shots take out a battleship, and I've seen some require four - the vast majority drop after three. This "proves" a minimum range of 66%-133% (the damage averages required to achieve 2-4 hit take-downs), which strongly suggests the actual range is 50%-150%.

:::Much of the information on this wiki is written off the top of someone's head, especially articles like this one that deal less in hard statistics and more on handing out strategies and tactics (it doesn't even mention how much damage needs to be done to shoot down a battleship!). Many such errors are only corrected when newcomers come along and spot them. There are plenty there, though, so don't be afraid to question anything you see or correct anything you are certain to be wrong. - <span style="font-size:xx-small"> [[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 04:42, 22 March 2012 (EDT)

::::Thanks guys. Initially I tried to work out a mathematical approach using the probability density function of an irwin–hall distribution, but dealing with variable n due to the accuracy aspect made it way too complicated and confusing for me to handle. Yikes.
::::So I did what any sensible programmer would do and wrote a quick script to run monte carlo simulations of x-com base defense. I ran 1,500,000 simulations of both of the above scenarios for damage ranges of 100%-100%, 50%-100%, 50%-150%, and 0%-200% (using a discrete uniform distribution within the range). The output is the damage range formula used, the base defense setup (i.e. number of shots, damage, and accuracy), and the average number of attacking ships needed for one to get through:
100%-100%
24 shots, 500 damage, 50% accuracy:
89.46 ships
6 shots, 1200 damage, 80% accuracy:
59.12 ships

50%-100%
24 shots, 500 damage, 50% accuracy:
11.63 ships
6 shots, 1200 damage, 80% accuracy:
07.88 ships

50%-150%
24 shots, 500 damage, 50% accuracy:
67.75 ships
6 shots, 1200 damage, 80% accuracy:
25.19 ships

0%-200%
24 shots, 500 damage, 50% accuracy:
31.32 ships
6 shots, 1200 damage, 80% accuracy:
10.86 ships
::::Nicely enough, the 100%-100% numbers (fixed damage) match my earlier calculations reasonably well, and it seems the 0%-200% numbers are very close to what is in the article! So I think unless someone verifies or is already quite confident the damage range is something other than 0 to double, or maybe has some non-uniform distribution, I'll leave it alone.
::::I do think this article should mention somewhere that the damage is a variable range. Perhaps go ahead and say 0%-200%, with a note that this maybe should be verified?
::::Thanks again for the replies!
::::--[[User:Jewcifer|Jewcifer]] 11:36, 29 March 2012 (EDT)
Monte Carlo method should be able to find the damage range, actually. Given a save with a Battleship inbound on a base with 10 Fusion Ball Defences + Grav Shield, one would save-scum (or just keep playing while leaving the Battleship swarms alone) and record the number of Fusion Ball hits needed to down the Battleship on each attempt. If it's 50%-150% (as I suspect it is), then the chance in Collector's Edition (3000 Battleship health) should be 1/8 (12.50%) to down it in two hits, 5/6 (83.33%) to down it in three hits or less, and 383/384 (99.74%) to down it in four hits or less (five hits gives certainty). In DOS (3200 Battleship health) it should be 1/18 (5.56%) to down it in two hits, 241/243 (99.18%) to down it in four hits or less and 933119/933120 (99.9999%) to down it in five hits or less (six hits gives certainty; three hits is more complicated and I CBF doing it right now). If it's 0%-200% then the chance to down it in two hits should be 9/32 (28.12%) in CE and 2/9 (22.22%) in DOS, the chance to down it in three hits or less should be under 5/6 (83%), the chance to down it in four hits should be under 23/24 (96%) and the chance to down it in five hits should be under 119/120 (99.2%) (in all cases by a decent margin, since that's actually the chance of doing under 2400 damage). My recollections don't match that latter set of numbers (I've ''never'' seen four hits fail to down a Battleship in CE, and two-hit kills are fairly rare) but I could be wrong. [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 02:22, 18 February 2016 (EST)

:After analyzing the CE code, it seems the damage range is 50-150%. - [[User:Morgan525|Tycho]] ([[User talk:Morgan525|talk]]) 03:52, 20 February 2016 (EST)

== Monthly Score ==

I guess it's assumed that ships destroyed by your base defenses count toward your monthly score/funding? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:24, 1 June 2021 (UTC)
: Actually there's no indication that they count for your score. UFOs destroyed during aerial interceptions count, but the Base Defense shootout is a different mechanic. So, this is undetermined. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 03:18, 1 June 2021 (UTC)
:: Thanks and I saw somewhere else since that it's believed Base Defense shootout doesn't count [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:24, 1 June 2021 (UTC)

Talk:Base Defence Systems

2021-06-01T18:24:19Z

Mugwump: /* Monthly Score */

Talk:Incendiary

2021-06-01T18:21:17Z

Mugwump:

Talk:Incendiary

2021-06-01T18:20:54Z

Mugwump:

== General Comments ==

For now, we'll just say the smoke + incendiary stun effects only work on X-Com owned units until some tests can be run to confirm this. It's unusual that only X-Com units are affected, but the game has been known to surprise you even after you think you've worked something out.

- [[User:NKF|NKF]]

----

Given how aliens love to hang around in a smoke-filled crashed UFO, IC rounds would be insanely powerful if they did actually work against aliens in smoke. I'm glad they don't ''seem to'', as I'd be very tempted to cheat with it. They do work against aliens standing in fire, though, which is still quite cheaty...--[[User:Ethereal Cereal|Ethereal Cereal]] 21:35, 5 May 2006 (PDT)

:I do consider the "standing on fire + new IC explosions = damage" a cheat. So I just don't abuse it. I only use IC rounds to illuminate or to finish off hiding aliens. It can also work as a "pass-through-and-die" tactic, the same way Proximity Nades work, although fire damage is pretty sad xD. --[[User:Nekrocow|Nekrocow]] 00:36, 24 June 2012 (EDT)

:: I use it a lot in TFTD to clear out those island bunkers and the upper storage levels of the large train station. Either the aliens roast alive, or they come out. Otherwise yes, it's no doubt a cheat. Well, more a bug exploited as a cheat. -[[User:NKF|NKF]] 02:09, 24 June 2012 (EDT)

-----

I just edited the Incendiary page a bunch, because Brunpal's [[Talk:Experience]] questions about Incendiary sparked my interest... I never did test IN vs. experience. It's a very good question ''if'' it turns out to cause Firing experience. But while reviewing this page, I had a number of questions, for anyone interested. Also, I only tried to clarify things, and don't know Incendiary well, so fix anything you know I got wrong:
#Did I get it right re: the set [ 0, 5, 6, 7, 8, 9, 10 ] for chance of initially catching fire? I over-wrote "linear" because it seemed odd when XCOM usually goes, e.g., 0-10. (Who tested this? - A little help here please. Just making sure.)
#Why flame a zombie unless it's near death (and how can you know if it is)? It's been a long time since I used fire - if you don't have flying armor, why mess around with a zombie by burning it, why not Heavy Plasma it.
#Any research/data on tile flammability versus duration of burning is appreciated. Probably it should go on the [[Terrain]] page byte, but be clearly referenced here. It's just a curiousity, but an interesting one.
#The last line of the page says ''"The damage values listed in the UFOpaedia do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames."'' Does anyone know IN strength vs radius, then? Should be easy to test and post.
#NKF, Zombie, or anyone else... would you mind seeing if Incendiary causes the Experience counter to increase? Brunpal is right that it's important to [[Experience]]... I found [[Small_Launcher#Experience|Stun Bombs]] to count for experience across their whole range, even if no stun damage occurred... if you have 11+ Mutons in a firing squad situation, passing around an [[Auto-Cannon]] with Incendiary may be better than standard pistols, depending on the range of the blast. I could test it, but it's been a long time since I've delved into the files; maybe one of you have them more close to hand. [[User:MikeTheRed|MikeTheRed]]
-----
:Offhand, the only way I could think of to check the remaining HP on a Zombie would be by using a [[Mind Probe]]. Given the relative uselessness of a Mind Probe after Psionics are developed, as well as the time needed to use the Probe once, this seems a rather impractical course of action, unless your Rear Commander has nothing better to do. I agree, Heavy Plasma on Auto is better. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 1 August 2008 (PDT)
-----
#Yeah, the set is correct. When a unit is shot with an incendiary round, the game does a calculation to determine if the unit catches fire. If it doesn't catch fire, the unit takes no damage (the 0 in the set). If the unit does catch fire, it will take between 5-10 damage points. Stupid discontinuous range, but that's what happens. As you may guess, I did the Incendiary trials over at the StrategyCore forums in the Damage Modifier topic - see [http://www.strategycore.co.uk/forums/index.php?s=&showtopic=746&view=findpost&p=39672 this] post for the particulars.
#Why flame a Zombie? Simple. A Zombie which is killed by an Incendiary round doesn't turn into a Chryssalid. Zombies are easily outrun, so you can just keep picking at them from a short distance with Auto-Cannon Incendiary rounds and then running away. Fairly effective, even when your troops do not yet have armor to protect them. And when you do not have the luxury of the Heavy Plasma early in the game, Incendiary is a good way to avoid an overabundance of Chryssalids who are not so easy to kill. As for checking the Zombie's stats, you can only rely on the Mind Probe or Psi. Neither are available early either (the Mind Probe is usually low on the research tree for most people even though you can collect enough, and Psi is difficult to use as a soldier needs to be quite proficient to use MC.
#I have been meaning to do some tests in flammability vs terrain but only recently started fooling with MCD values. It'll be next on my list.
#Here, I uploaded a very recent spreadsheet containing both I and Smoke when damage values are hacked. See [[Media:Incendiary_and_Smoke_Patterns.zip | this file]] which contains both.
#I think I fooled around with Incendiary recently in conjunction with promotions. Soldiers who shot aliens with "I" didn't get promoted. Logically, that would mean the experience counter didn't increment. UNITREF.DAT would need to be checked to verify though. Addendum: indeed, as BB mentioned in the experience page (and a quick glance at the UNITREF.DAT experience counters by myself to triple-check my aging brain), Incendiary rounds do not increase any of the experience counters.

Hope this clears up some of the issues/concerns here. --[[User:Zombie|Zombie]] 21:16, 1 August 2008 (PDT)
----
<i>"The damage values listed in the [[UFOpaedia]] do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames. Fire is unlike other damage; it works at initial blast and then over time, as described above."</i> and
<i>"Initial "impact" damage from incendiary ammunition is either for no points (unit does not catch fire), or between 5-10 points (unit catches fire)."</i>

This should be stressed on ALL the various relevant pages. It's important. 6.4 dmg vs 90 dmg is a significant difference!--[[User:Brunpal|Brunpal]] 09:31, 2 August 2008 (PDT)
----
It looks like Incendiary is gaining some clarity (at least for me), thanks for starting it Brunpal...
*The "6.4" was only for the initial IN round impact (set [ 0, 5-10 ]); it can then burn for 4 more rounds (set [5-10]). Perhaps a short way to state this complicated damage type is "Minimum 0 (unit does not catch on fire) ''OR'' unit catches on fire 1-5 turns, 5-10 damage/turn, 5-50 damage in total (average 21.5)". Does that look right, Zombie? I'm not sure where you got 90 from Brunpal...
:90 is the listed damage from an IN rocket.--[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)
*However, the numbers I just stated do not count possible additional damage from nearby terrain being on fire (as opposed to yourself). Maybe those should be included somehow. (And clearly, fire is much more dangerous outdoors than inside UFOs, where terrain does not burn.) But since terrain fire can last a variable number of turns, I guess you can't have a maximum damage. Average terrain damage from fire would be 6.5/terrain (1-12), but also, it can keep the unit itself burning more than 5 turns... hard to model.
*Good point about flaming zombies, Zombie. I guess you ought to know, eh? :)
*The spreadsheet looks great. Perhaps one of us can pull out the area patterns for non-hacked IN weapons and put them on the relevant pages. When it's done, the spreadsheet itself would be an asset to Incendiary (or maybe [[Damage]], if it's listing all types of damage). As has been stated, it's the size (area) of the blast that actually directly relates to incendiary weapon "strength"... the diameters you found are probably what should be in parentheses next to weapon strength, although damage can appear as well.
*Ok, no experience from Incendiary blasts. It might've been real interesting if there were, but it didn't occur to me to test. (Or maybe I tested it briefly so long ago that I forgot.) I would've guessed that they did, because the stun bomb and explosives do. Oh well.
*P.S. Brunpal, we may not have touched pages in a year, but most/all of us have "Watch this page" turned on, so we get immediate notification of any pages we've edited or Watched. :)
-[[User:MikeTheRed|MikeTheRed]] 09:17, 5 August 2008 (PDT)
----
*Sounds correct MTR. I think Brunpal was just comparing the "damage" (actually strength) of the Incendiary Rocket (90) to the average damage due to the "impact" of the blast (6.4).
*Well, it isn't ''nearby'' terrain on fire which you have to worry about, it's the tile directly underneath a units feet which causes the most concern. If that tile is on fire and the unit doesn't move, it will take 1-12 damage points. While true that terrain on fire can last a variable number of turns, there is a definite upper-limit to how much damage a unit can possibly take. Fires don't last forever, and the combustibles eventually are consumed leaving either scorched earth or a damaged tile. Those damaged/destroyed tiles usually cannot be started on fire again by the spread of flames. They can only be set ablaze with incendiary ammo, and even then for only 1-3 turns (normal for dead tiles). So it's certainly possible to find a max damage. And for the most part, the things that burn the longest are usually objects, not tiles. And most objects you can't stand on anyway. But I totally agree that it's hard to model how fire functions due to the two forces at work: "impact" damage and damage due to standing in fire.

P.S. Some of us are actually around here and don't need to be coaxed back into existence by an email when a watched page is changed either. Just because it's quiet, it doesn't mean nobody's home. :) --[[User:Zombie|Zombie]] 20:34, 5 August 2008 (PDT)
----
While understanding the whole formula for fire and fire damage happens is useful, it was not thinking to go that broad. I was just interested in what occurs from the moment a solider takes his shot, to the time that solider gets his TU back. ie damage from incendiary rounds vs fire damage. --[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)

----
It looks to me that, unlike all other forms of damage, Fire damage ignores armor, goes right past it. If so, this should be made explicit on the main page? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 05:55, 30 May 2021 (UTC)
:Fire damage doesn't ignore armor - power suits for instance can't be damaged by fire, except if the unit is already injured. Read carefully the Damage section - there's a lot of nuances about how fire works. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 03:03, 1 June 2021 (UTC)
:: What I meant is ignore armor ratings for damage calculation. While accounting for the resistances listed on the Damage Modification page, doesn't incendiary act as if front, side, back and under armor are 0 for calculation?

== Incendiary vs Large Units ==

We're discussing this in [[Talk:Sectopod#Incendiary vs Sectopod]], and a question came up. When an IN round impacts one segment of a large unit, presumably that segment gets the "Incendiary impact" function, i.e. 6/7 chance of catching on fire for 5-10 damage plus 1-5 turns of being on fire. Does the same "impact" function also apply to the 3 adjacent squares (6/7 chance), or is it just the "standing in fire" chance? If you had multiple regular-sized units standing in the area of effect of an IN round, they would each get "impact" effects (right?). So it ''seems'' logical that all 4 segments of a large unit, inside the area of effect, are also exposed to "impact" effects. But I wanted to check. [[User:Spike|Spike]] 06:34, 9 March 2009 (CDT)

Oh boy! Calculating this not only depends on a lot of unknown assumptions, but is fiendishly complicated - especially if you factor in the "funky fire" bug. And contrary to my noblest efforts, it's impossible to use IN weapons without inadvertently exploiting this bug. Even if you only fire IN at a single target until it's dead, once the target is "standing in fire" you effectively just can't miss.

Anyway back to the Large Targets specifically. The key assumption above is whether all regular-sized units in the area of effect of an IN burst are affected with "impact effects" - 5-10 dmg & 6/7 chance to catch fire. If they are, it's reasonable to assume the same thing happens to the 3 other segments of a Large Unit. However I suspect this is not the case, and strictly speaking "impact" effects should only occur at the single, impact square of an IN round. Testing needed!

More likely, the GZ+1 squares, whether occupied by small or large units, are only subjected to the "standing in fire" effects: 1/3 'catch fire' probability, and 1-12 terrain-based damage. And these effects are applied once per turn, not once per hit.

However, all of this is turned on its head by the 'funky fire' bug. After the first round hits, all units (and all Large Unit segments?) are "standing in fire". (Though maybe these fire damage routines run only for the "control" segment of the Large Unit? Possible, but unlikely.) Since they are standing in fire, the funky fire bug applies and all units/segments are hiit with "impact" effects.

So assuming a Large Unit is ''already'' standing in fire (e.g. from a previous IN hit or near miss), damage per IN round fired is 6.4 x 4
= 25.6 average, 10x4= 40 max. Subject to resistance/vulnerability modifiers, but ignoring armour level. In addition as multiple IN rounds are fired, the chance of all segments catching fire quickly approaches certainty. This not only means the Large Unit will sustain further damage at the end of the turn, it makes it impossible to escape the 'funky fire' trap by moving out of burning squares.

(Any testing needs to be very careful and probably only fire a single IN round per game, otherwise 'funky fire' will skew the results.)

So, in conclusion, the TU/kill factors I put up on the Talk pages for the Large Units ([[Talk:Reaper]], [[Talk:Cyberdisc]],[[Talk:Sectopod]]) should pretty much reflect the 'funky fire' reality after the first round connects, apart from the fact that you actually can't miss. The very first IN round to be fired would have the same effect (for immediate damage) on a Large Target as on a small one. But I really don't want to update the numbers to reflect this fact, it's just too awful. For AC-IN, the firepower factors will be about 6 times better than stated. Maybe I'll just remove them. :(

[[User:Spike|Spike]] 15:51, 10 March 2009 (CDT)

=== Simple Tests ===

I did a small number of tests and found some interesting results. In 5/5 tests, all 4 squares of the target (Reaper) were on fire the following round. (It's hard to tell if they are on fire the same round, as you need to extinguish the fire with smoke to see). Perhaps this makes sense, as it's a UNITREF attribute and so applies to the whole unit, not its 4 component squares?

Looking at the damage, it looks like "impact" and "on fire" damage applies to all 4 squares, i.e. x4 normal. Damage clusters tightly around 16-18 per hit which is roughly the expected value, maybe a bit lower (at x4). And since we '''are''' on fire, should expect an average of 7.5 ({5..10}/6) rather than 6.4 ({0,5..10}/7? Maybe something else is going on here, as these numbers seem a little low - 6.4 x 4 = 25.6 per hit or 7.5 x 4 = 30.0 per "on fire" hit might be expected on a Large Unit.

:Drat. I didn't factor in the Reaper's 170% Susceptibility to Incendiary. So the actual damage levels are more like 10 per hit. Maybe there is no multiplier for the 4 squares? Hard to figure out what's going on here. In tests on hacked humans, armour level is not a factor vs Incendiary damage, otherwise I'd suspect the under-armour or something. 2.5 avg damage per segment seems too low. 10 average damage per alien seems too high - that should be the max, not the average. Is some mechanic pushing the average up to the max? I don't have a clue right now. [[User:Spike|Spike]] 06:53, 11 March 2009 (CDT)

The damage seems to be regardless of "funky fire" effect. A round fired at a target that is not burning / in fire seems to do about the same damage, per hit, as one that is in fire / on fire and so subject to the funky fire bug. So the only 'bad' effect of the bug is that you never miss, and you hit everything that is in fire / on fire. Not quite so bad, and it allows you to play honest by only ever firing at one target, not hitting any other targets by accident (!), and firing from point blank range so it doesn't matter that you never miss.

Burn Time was as high as 7 when multiple IC rounds were fired (on auto). Higher than we thought possible (1-5 range expected). However it sometimes goes DOWN after additional hits. Possibly the value is re-randomised with every new IC impact, but hits are cumulative while firing auto bursts?

Here's the raw test data:

Test 1.
-
2 DH on Reaper, mix of auto and snap, some other IC impacts on others
Burn Time=7 - exceeds known limit of 5
All 4 sq on fire next turn
Is 'on fire' global? It's in Unitref, so maybe
-
Test 2.
-
1 DH on Reaper, only IC shot fired in game.
In firing turn, taken 132/148 = 16 damage. Burn time=3
Start of T+1, taken 122/148 10 more damage, Burn time=2
T+1 Reaper shows all 4 squares burning
-
Test 3.
-
Revisit #2 firing turn... fire another round (this will use funky fire)
So 2nd IC hit, 2nd rd fired, same target.
Health now 114/148, further 18 damage
But Burn time has dropped to 2! Must re-randomise on each hit??
Maybe only accumulates during auto burst?
-
Test 4.
-
Let's try lots of hits. Hack up accuracy to 255
OK 3 out of 3 hits on Auto
T+0 Health=98/148=50 damage (17 avg) Burn=6
T+1 Health=81 (17 more dmg) Burn=5 All 4 squares on fire.
-
Test 5.
-
Revisit #4 and push to 6/6 hits
T+0 Health=41/148=107 (18 avg) damage Burn=7
T+1 Health=21 (20 more dmg) Burn=6 All 4 squares on fire.
-
Methodology (Apart from Test 1) = only ever 1 (same) target in any IC AoE; no misses
(To try to minimise the impact of 'funky fire' effects - but can't eliminate)

[[User:Spike|Spike]] 23:27, 10 March 2009 (CDT)

I re-ran the same simple tests against a regular-sized (Floater) target instead. The results agreed much better with the 'standard model' of [[Incendiary]] effects. All results were within the permitted ranges in the 'standard model', though some values were unexpectedly. I think some variables to look for in Incendiary mechanics are:

* Large Unit vs regular unit behaviour looks to be different
* Auto burst vs single explosion looks to be different (maybe just due to funky fire bug, maybe not)
* Tile MCD "time to burn" value seems to affect one or more of the other calculations / probabilities
* Burn Time on the unit can go up as well as down. New hits seem to re-randomise the value.
* End of turn processing does not always reduce unit Burn Time by 1. Can a terrain fire add to unit Burn Time?

[[User:Spike|Spike]] 21:25, 11 March 2009 (CDT)

:I doubt a terrain fire adds to the time a unit is on fire. Actually, I'm quite positive on this since my tests from a while back were quite thorough. The counter can only tick down to 0, and when it does a terrain fire will have a chance of "reigniting" the soldier again.

:Anyway, I had to start from scratch again on testing due to a few issues with my test scenario. I totally forgot that the first soldier on the unit roster is a bad choice for a "designated hitter" since he can never be automatically selected on a reload. Soldiers lower on the order are much better choices. So I got the shooting automated, but each reload was taking too much time since I had to reselect the shooter, select the shot, move the view down a level, shoot the target and abort. Having the soldier already selected cuts out 2 actions in the list allowing the script to run more efficiently. I'm going to try to get everything properly setup tonight, then start testing tomorrow morning. With a little luck and about 2 hours of babysitting the script to make sure it doesn't quit, I should have some prelims. --[[User:Zombie|Zombie]] 21:55, 11 March 2009 (CDT)

----
Looking forward to seeing that data! I did some more testing just for the special case of Large Units, about 40 tests. My tentative conclusions:

# Damage range per 'impact' hit is the same as regular units, around 5-10 x Vulnerability (maybe + MCD Burn time?)
# Large units go on fire about 1/7 of the time when receiving a direct hit - as expected
# Either all 4 segments go on fire, or no segments go on fire - no 'part segments on fire'
# Unit burn times are not correlated with unit damage received
# Auto fire has the same average damage level per hit as snap fire
# Unit Burn Time can exceed 5, both on Snap and Auto. Highs of 6 (Snap) and 7 (Auto) were seen. Maybe 1-5 + MCD Tile Burn Time?

All my tests were done on the grid-lined pavement tiles from urban terror missions, which have an MCD default burn value of 2. For some of the "setting the large unit on fire" tests, I had the target floating in mid air, because air does not burn even during the turn that the IN round explodes - it makes it easier to see the unit burning.

From Bomb Bloke's editor notes, the 4 potential MCD tiles in a map location are: a North Wall, a West Wall, a Ground tile, an Object tile. All 4 of these MCD tiles might have a burn time value. But Ground and Object are the most likely to be relevant.

[[User:Spike|Spike]] 21:58, 12 March 2009 (CDT)

:Ok, I got the script running and optimized it a bit to cut down some wait cycles. Right now it's cranking out approximately 400 trials per hour which is about as fast as I can make it go without removing some desktop icons (all the icons have to refresh at the end of each logging cycle which takes a little time). Anyhow, just for giggles I stopped it after 400 trials to get some prelims.

:<table {{StdCenterTable}} class="sortable">
:<tr {{StdDescTable_Heading}}><th align="left" width="90">Damage</th><th width="90">Count</th><th width="90">Pct%</th></tr>
:<tr><th align="left">1</th><td>68</td><td>17.0%</td></tr>
:<tr><th align="left">6</th><td>58</td><td>14.5%</td></tr>
:<tr><th align="left">7</th><td>45</td><td>11.3%</td></tr>
:<tr><th align="left">8</th><td>63</td><td>15.8%</td></tr>
:<tr><th align="left">9</th><td>55</td><td>13.8%</td></tr>
:<tr><th align="left">10</th><td>64</td><td>16.0%</td></tr>
:<tr><th align="left">11</th><td>47</td><td>11.8</td></tr>
:</table>
:If you average the percent columns, it comes to 14.28571429% while the expected is 1/7 or 14.285714285714285714285714285714 which is a difference of 4E-09. This means 400 reloads is plenty enough values for this application. Great news! Well, as you can see, instead of the set [0, 5, 6, 7, 8, 9, 10] for MCD of 1, this scenario where the MCD was 0 is shifted up by one [1, 6, 7, 8, 9, 10, 11]. Interesting.

:Tomorrow I'll rerun the MCD 1 scenario again to verify the values and damage set. Then it's on to the MCD of 2. --[[User:Zombie|Zombie]] 01:50, 13 March 2009 (CDT)

:: Extremely interesting! By the way, it was probably a late night but - the average any 7 numbers that (must) add up to 100% is always going to be 1/7th of 100%, so that result doesn't really demonstrate any confidence in the data. It would be the same with one result, or with a trillion results. The 4E-09 discrepancy is just the precision error in your calculator/spreadsheet's calculation of the percentages and the average of the percentages. You've got some considerable variation from 1/7th on the individual numbers, I'm not sure if that's just to be expected with only 400 trials. But for example "0" and "10" are both a bit high so it ''might'' be non-linear (probably not). Anyway we'll see when all your results are in! (To measure the degree of variation from the expected result, what you want is a chi-squared test or something - and I don't know what I'm talking about there so I'll shut up!)

:: I'm checking Bomb Bloke's MCD database, and there are some tiles in there (U_BASE 22-25) with MCD burn value of 30 - I might play with those and see if anything dramatic happens. Oh except looks like they can't be set on fire (255 flammability). There are others that are quite high (8-), and still flammable. Or I could hack an MCD file (scary). Maybe I'll just wait for your results Zombie! [[User:Spike|Spike]] 05:49, 13 March 2009 (CDT)

= Incendiary Research =

== Large Units On Fire ==

Here's another interesting test for setting Large Units on fire. Set AC-I power down from 42 to 1.
At this IC power, there is no area effect. You can't even start a fire on one tile.
All you can do is set units on fire with a direct hit. This means there is no way the other 3 squares of the
Large Unit are in the IC area of effect.

Result: Whether you hit a one square regular unit or a 4-square large unit, if it goes on fire, '''all''' squares of the unit still go on fire. Along with the fact that the inflicted IN damage level vs Large Units is basically normal (see above), this tends to confirm that being on fire is a "unitref" property and, unlike HE and Stun Bombs, is not applied (multiplied) vs the number of squares the unit occupies. (In fact it would be good to check that HE is actually applied separately to each square, with different HE strength, potentially different armour facing, etc. Maybe the engine just simplifies things and multiplies damage by 4?)

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)

== Unit Burn Time ==

Unit Burn Time seems to be considerably '''cyclic''' rather than random. Very often, it just steps down by one from the previous value. I suspect this is because the "impact" routine calls the "end of turn" incendiary/smoke routine (see [[User talk:Seb76#Incendiary Bug]]). Sometimes it does not happen, maybe because some other factor has caused the Burn Time to increase.

Here's some data. This was done against a Reaper with AC-I power set to 1 (and 10% TU Snap fire cost). But I've seen similar results with standard AC-I.

Hit H/H Dmg/Avg Burn Time
1 137/150 13 2
2 126/150 11 1
3 104/150 22 0 Very high damage (=13x1.7). Unit not on fire when game restored.
4 96/150 8 7
5 81/150 15 6
6 66/150 15 5
4,5,6 76/150 /9.33 5 (Auto) 9-10 (=5-6x1.7) is near minimum dmg
7 56 10 4
8 48 8 4 What happened here? didn't cycle. MIN dmg (5x1.7).
9 35 13 6
10 25 10 5
11 10 15 6 New shooter takes over
12 2 8 5

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)
:You're right on spot once again ;-) When a unit takes a direct hit from an IN round, it is set on fire (the duration is randomly chosen between 0 and incendiarydamagemodifier/20). Then the "end of turn" routine is called, which inflicts damage *and* decreases by one the number of turns to be on fire (done for all units). Then it sets on fire units standing in blaze. The duration is calculated as for direct hits; if the unit was already on fire, it'll take the maximum value between the new value calculated and the current value affected to the unit on fire. Not sure it is readable but I think you'll sort it out ;-) [[User:Seb76|Seb76]] 10:51, 15 March 2009 (EDT)

== Incendiary in TFTD ==

I read [[Weapons (TFTD)#Phosphor|somewhere]] there are reduced effects underwater (or enhanced effects on land) for TFTD Phosphor rounds. I couldn't find an exact statement of the quantitative difference - does anyone know this? [[User:Spike|Spike]] 14:53, 9 March 2009 (CDT)

:The effects of Incendiary weapons underwater (or Phosphor, as TFTD refers to it) is halved over the UFO equivalent. Incendiary weapons are doubly effective on the surface(Terror Missions) vs underwater, but of the three weapons that can fire Incendiary, two of them(Torpedo Launcher and Hydro-Jet Cannon) can only be reaction fired on land. The Gas Cannon can be fired in eiither location. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:08, 9 March 2009 (CDT)

:: It's clear that the effect underwater is half the effect on land. But does the base level (in USOPaedia / OBDATA) refer to land use or underwater use? [[User:Spike|Spike]] 15:13, 9 March 2009 (CDT)

:As I recall, the base level is on land. The numbers for Phosphor ammo are close to the UFO Incendiary damage numbers, but I know it spreads less underwater. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:15, 9 March 2009 (CDT)

:: Look at the (puny) area effect pattern sizes underwater, that sounds about right. Can anyone confirm this? [[User:Spike|Spike]] 15:40, 9 March 2009 (CDT)

There is actually no difference between the pattern for the Gas Cannon's P rounds underwater as on land. Both have a r=3, d=7 pattern. (CE version at least). Maybe the pattern is smaller the deeper you go? --[[User:Zombie|Zombie]] 16:45, 9 March 2009 (CDT)

<gallery widths="200">
Image:GC-P (underwater).png|Flame pattern from Gas Cannon Phosphorous rounds underwater.
Image:GC-P (on land).png|Flame pattern from Gas Cannon Phosphorous rounds on land.
</gallery>

:OK now I'm really confused then! (I realise I was getting confused with the Dye grenade's small footprint vs Smoke grenades). If the blast pattern is the same size, that implies the weapon power is unchanged. So in what sense is Phosphorus "half as powerful" underwater? Does it burn half as long? Is the impact and fire damage halved? [[User:Spike|Spike]] 16:49, 9 March 2009 (CDT)

I really doubt the damage to units would be affected if the power of the round was modified. The power of the round only determines the size of the pattern produced, not the damage inflicted to units. I'll have to check the burn times and spread rate but my thought is that the two are identical in the version I'm using. Like I said, the pattern may get smaller the deeper you go underwater. The pic above was for a shallow site. It'll take a while for me to find a deeper site to check it out, otherwise some editing of the game files may be necessary to force the scenario.

I just checked the Dye Grenade underwater and on land. Both produce the same r=1, d=3 pattern. So yeah, they are really pitiful when compared to the Smoke Grenade.

Don't really go for the use of "impact" damage with Incendiary/Phosphorous rounds. There is no real impact since the damage range is discontinuous. The unit either catches fire from the splash of fire (in which case it does 5-10 damage points), or the unit doesn't catch fire and the unit remains unharmed. If there were such a thing as impact damage, the range would be continuous like normal weapons, in this theoretical case it would be [0-10] inclusive (ie the set [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. --[[User:Zombie|Zombie]] 17:36, 9 March 2009 (CDT)

Anyway, the half thing came up because AQ was comparing TFTD to UFO, not comparing the effects in TFTD from underwater and on land. However, further comparisons reveal that a hacked HC-I round of 60 produces the same pattern as a GC-P/60 round. Perhaps this whole dilemma can be traced to the Dye Grenade? --[[User:Zombie|Zombie]] 18:28, 9 March 2009 (CDT)

:That's entirely possible the Dye Grenade is the source. However, several of the pages for the TFTD weapons state that Phosphor is far weaker in water, so I didn't check. My mistake. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:35, 9 March 2009 (CDT)

Thanks for the feedback everyone. So this could just be a recycled rumour? I guess the general assumption is that the game engines are identical, so we would want evidence that TFTD is different. Looks like Zombie has proved that the area effect is equal (at least at shallow depths). That leaves only the fire damage or fire duration. Testing that would require repeated observations to check if fire damage is less than 6/hit, less than 6/turn, and burning for no more than 2-3 turns. [[User:Spike|Spike]] 20:14, 9 March 2009 (CDT)

:As with any wiki where contributions can come from anywhere, there are bound to be problems with validity of the statements made. So unless those statements are backed up by real-life test data instead of memory or hearsay, take them with a grain of salt. The other point is to avoid spreading disinformation at all costs (I have been guilty of this as well, but try to at least quantify them). So there you go. I'm still trying to get a deeper underwater mission to check the size of the pattern produced there. Checking the spread of flames or damage inflicted to units shouldn't take too long though. I'll see if I can't get that done tonight yet. --[[User:Zombie|Zombie]] 20:23, 9 March 2009 (CDT)

:Ok, I ran some trials with an unmodified GC-P round on the normal seabed floor against soldiers having 100 health and 0 all-around armor. For the guy standing at GZ, I saw ending health values of 99, 94, 93, 92, 90, and 89 (n=50). So that comes out to 1, 6, 7, 8, 10 and 11 points of damage respectively. I didn't think 11 damage was possible. Here's where things differ though. All the other guys who were clustered around GZ always received only one point of damage, never more, never less. In EU, the guys around GZ took damage equal to the guy at GZ. Odd. So then it occurred to me that perhaps I should check the MCD values of the seabed (TFTD) and the desert (EU) landscapes. Both are basically identical in terms of armor. But the seafloor has a "time to burn" value of 0 while the desert has a value of 1. So maybe our understanding of normal fire isn't totally complete. I'm going to go back to EU and retest the desert landscape with varying MCD burn time flags to see how that affects damage. ;) --[[User:Zombie|Zombie]] 23:00, 9 March 2009 (CDT)

:: The whole Phosphor being half effective under water is related to the burn time and spread, if I remember correctly. The settings in the MCD files may be the culprit. The actual damage dealt or initial spread may not necessarily be affected.

:: Hey, I just had a wacky idea. XComutil. Use its feature where you can set the depth of a mission. Launch a mission on a island terror site map (again, use XComutil's map picker to get to this faster). Lots of grass to burn there. Set fire to it and count how many turns before the fires die out. Redo the test, but this time set the depth to a deeper level. Try the whole process out again.

:: Next repeat this with one of ye-olde seabed maps. They look really weird without the blue palette shift when played on land, what with the landscape being gray.

:: It's possible that the half-effectiveness relates to the fuel that the fire has to burn more than anything else. Further confirmation on how long the flames stick to a target when on land or underwater may be helpful. -[[User:NKF|NKF]] 01:28, 10 March 2009 (CDT)

:I've been burned one too many times using editors or utilities to mess with saved games. Half the time they introduce some unknown "feature" which isn't documented. Thanks, but no thanks. I only test with an unmodified game, except for the changes I make myself to keep control of the situation. Anyway, I tested a patch of fire on the seabed to see how long it remained lit (which has a "time to burn" value of 0). It only stayed lit the current round the shell detonated. After that the fire went out. So this agrees with what is expected. Will continue to work on this as I get time. --[[User:Zombie|Zombie]] 01:51, 10 March 2009 (CDT)

Well, I suppose my recommendation doesn't necessarily need XComutil. It would've certainly made it easier. But yes, it does introduce a few things that work behind the scenes that we might not know too much about. However, if I remember correctly, one of the battlescape savegame files should hold the depth level of the current map you are playing on. All you'll need to do is tweak that to change the depth of the map.

One other thing, the different effect HE has on the same tiles underwater and when on land (ala the Triton) may also be one of the other culprits behind the belief that phosphor is less effective on land. Being able to blow up the Triton on land, but have it appear virtually indestructable when underwater does that. -[[User:NKF|NKF]] 01:59, 10 March 2009 (CDT)

----

re Zombie's underwater tests, there is normally (i.e. on land in EU) a difference between the IC damage on the target of the direct hit, vs lower damage to others in the area of effect (hmm contrary to my IC kill modelling assumptions: uh oh I may've spoken to soon). But only seeing 1 damage on the others in the AoE does seem low. We need to figure out why. Did any of the other targets catch fire? Does that ever happen underwater? Do tiles ever burn past the turn when the IC round is fired? Any of these factors would reduce total fire damage/effectiveness by '''more''' than half. Actually, doesn't it say the 1-12 damage for "in fire" is ''not'' random, but dependent on terrain type? That could be the answer.

The [[Incendiary]] article actually mentions '''4''' modes of fire damage, only 3 of which are quantified:

#"impact",
#"being in fire"
#"being ''on'' fire"

The 4th mode is "damage from burning ''terrain''. Only a tantalising mention is given, no quantitative details. This could be the source of the discrepancy. In fact it might be a component of "being in fire" that's not fully understood. I think Zombie is right to review the assumptions on this one - nice work! [[User:Spike|Spike]] 04:05, 10 March 2009 (CDT)

:As I recall, "damage from burning terrain" is synonymous with "Standing on a tile that's currently on fire." Thus "Being in fire." But that's me and I'm tired this evening, so I could be wrong. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:30, 10 March 2009 (CDT)

I performed my TFTD Phosphorous tests underwater and after the flames died out some of my men did catch fire. So this part seems to jive with that of EU. Tiles do not burn longer than its "time to burn" value in the MCD files. So for instance, in the seabed underwater testing mission, the tiles have a MCD burn value of 0 which corresponds to the results seen (ie fire didn't stick around into the aliens turn or X-COM's next turn either, it only stayed lit the turn it detonated). There really is only 2 "modes" of I/P/fire damage:

<ol><li>The code used for determining if a unit catches fire: 0 damage (if the unit didn't catch and was able to shrug it off) and 5-10 (if the unit catches).</li>
<li>Standing in fire.</li></ol>
At least from the initial tests in TFTD, units outside GZ are just considered to be standing in fire that turn and always take 1pt of damage. Anyway, I don't want to talk myself into a hole without doing more tests. All the following trials I do will be in EU to hopefully curtail any unknowns in TFTD. Once EU's code is figured out then it can be applied and compared to TFTD. --[[User:Zombie|Zombie]] 09:06, 10 March 2009 (CDT)

: If they are "standing in fire", do you think the 1pt damage/turn is based on the fire characteristics tile/terrain type they are standing on? Is it more generally 1-12/turn, dependent on terrain? Also if you get a chance can you test large units and see what kind of effects they take on the GZ+1 squares? If the GZ+1 squares of a large unit are just 'standing in fire' rather than 'catch fire/5-10 impact damage' this will substantially weaken IC vs large units. And I will have shouted too soon! :) [[User:Spike|Spike]] 09:18, 10 March 2009 (CDT)

I did some ad-hoc tests in TFTD. Actually I just ran around firing GC-P and HJ-P rounds everywhere. :) On a typical seabed layout, I found that most things don't burn - the fires don't last into the next turn. The only things I could get to burn were the green moss stuff and and coral skeleton "trees". Even the barrels do not burn. Also, I did not see much sign of terrain damage caused by the fires. But the moss and coral did burn for the normal period, i.e. 1-5 turns.

I also managed to kill an Aquatoid with a single direct hit from a GC-P, in one turn. He died at the end of my turn or the start of his. That seems unlikely. 5-10 from being hit, plus 1-12 for standing in fire, plus maybe another 5-10 from being on fire? It's just about possible I suppose, to max out near 32 damage (if the terrain offers you "12" when it burns). Anyway those are my unsystematic enquiries. I have the 8 save files of various stages of the battle if anyone wants to take a look. It was from a virgin TFTD installation and there was no editing or jiggery pokery.

OK I've uploaded the save files [[Image:TFTD Incendiary Tests 01 Spike.zip]] and taken a look myself with BB's editor. Prior to being hit (Game_4) our Aquatoid was in rude Health, 30/30. Immediately after being hit (Game_2) he was at 19 Health (no Stun damage) and On Fire, as well as Standing in Fire. That implies 11 Damage from the "impact effect" which is not supposed to happen. As noted, at the end of the same turn or beginning of his next turn, he dies. He looks to be standing on a standard seabed square, just sand, the kind of thing that does not burn. He is next to some of the brown cushion-like coral, but I don't think that burns, at least not over multiple turns. In fact in the same turn he is hit, at the end, you can see him dead (Game_3). Since there was only one alien, he died in the same turn. OK that's slightly confusing, maybe someone can double check the turn numbers in the save files (don't know where they are).

[[User:Spike|Spike]] 13:29, 10 March 2009 (CDT)

Doh. I is a idiot. The Aquatoid was killed by the incendiary fire bug - I fired extra IN rounds at terrain objects after he was on fire. Which explains why he is already dead by the end of my turn. [[User:Spike|Spike]] 15:08, 10 March 2009 (CDT)

:Yeah, you gotta watch that. Well, anyhow, I edited the desert landscape in Enemy Unknown to have the same MCD "time to burn" value of 0 as the seafloor in TFTD. From the limited tests, the results look the same as in TFTD. (Fire burns out after the initial turn it detonated, units around GZ taking 1 unit of damage while the guy at GZ got more). So that means I can focus my efforts on EU with little worry because there will be no issues. I'm going use BB's logger and AHK to automate the data gathering aspect to save me a bunch of time. I'll probably need the full requisite 2000 reloads though, as the guy at GZ is not the same as the 24 soldiers around him. Wish me luck. :) --[[User:Zombie|Zombie]] 15:54, 10 March 2009 (CDT)

Good luck! I just read the MCD article, and it mentions 2 fire-related byte fields in MCD - "likelihood of catching fire" as well as "time to burn". Is the last field variable or fixed? Could the first field determine the damage/turn to units when it's on fire? Also with a possible 4 terrain items that could all be burning, is the maximum damage higher than 12? [[User:Spike|Spike]] 16:10, 10 March 2009 (CDT)

:Offset 45 is the flammability rating of the tile. This most likely controls whether an adjacent fire will spread to the tile in question. (For instance, if a fire is burning and the next tile over is a tree or something, it'll probably spread there fast because of the combustibles present). The other byte is offset 57 which is the one we are after. Don't know about the 4 types of things which can exist on a tile at once. I think the most I have ever seen is 2 (usually ground and a wall). Wouldn't hurt to edit a tile to include all 4, but that's an entirely different test to do. It'll have to wait until we get a better understanding of basic fire. ;) --[[User:Zombie|Zombie]] 19:38, 10 March 2009 (CDT)

::Here's a question. On Large units, if only one segment of the Large unit is on fire, will the fire spreading code allow the other three segments to catch on fire? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:13, 10 March 2009 (CDT)

:I highly doubt it. Unit fires are completely different creatures from terrain fires. Needs testing though. --[[User:Zombie|Zombie]] 20:55, 10 March 2009 (CDT)

::Yes it would have to be a very special case, since afaik fires do not spread from regular units on fire to adjacent terrain or to other adjacent regular units. Though it would make more sense than any of those things. [[User:Spike|Spike]] 21:03, 10 March 2009 (CDT)

== Incendiary Bug ==

(Also known as the [[Known_Bugs#Funky_Fire|Funky Fire/Smoke bug]].) I made some suggestion about why this bug happens, and how the code could be patched to fix it: [[User talk:Seb76#Incendiary Bug]]. [[User:Spike|Spike]] 07:13, 12 March 2009 (CDT) Here is the general discussion of the bug:

With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

I also suspect that other "end of turn" processing happens with every IN round fired. I am pretty sure "fire spreading" checks occur, as I have seen fire spread when using perfectly accurate shots. Either "fire spreading" happens, or there is a random element in incendiary area of effect, that is definite. I want to repeat these tests to see if "catch on fire" effects also happen for those who are standing in fire when an IN round is fired. [[User:Spike|Spike]] 08:59, 31 March 2009 (EDT)

== Mwahaha ==

Was exploiting the Elevator Shield trick on an Alien Base Assault, and I had the forethought to pack lots and lots of Incendiaries. My sick sick mind found it amusing to set all those aliens on fire and watch them roast stupidly and helplessly. (Jasonred)

= Fire Damage =
(moved from talk:UFOextender)

Not sure if the bug is already posted. And Not sure if I should post the bug here or in [[Talk:Incendiary]]. Problem is if you use extender to fix funky fire bug. Incendiary no long does any damage at all. Units only take the small amount of damage after ending turn because they're on fire. Using 1.28.3 extender

To test this. I stripped a soldier of armour. And pounded four incendiary rockets into the soldier in the same turn. No damage. And then next turn, his health drops a little because he's standing in fire. This may not be a problem for most players. But it is still a major bug. I understand the funky fire problem is already difficult to fix, and I say thanks to all who will try to help solve this bug. [[User:Hellblade|Hellblade]] 14:44, 28 September 2012 (EDT)

: That's not a bug, that's the fix. Incendiary damage is only applied at the end of the turn. Think about it... does fire kill faster than a bullet? Faster than a grenade? Can you kill someone with fire faster than they can get a shot off back at you? No, to all these things. To compensate for fixing the bug, fire damage is doubled compared to the previous end-of-turn fire damage (that always existed). It is no longer applied per shot or per impact. All you get "per impact" is another chance to set the target unit itself on fire. Incendiary is a weak attack. It has the benefit of a wide area effect, no HE block, and ignores armour. There are situations when IN is the only effective weapon XCOM possesses. But, like everything, it has strengths and weaknesses. [[User:Spike|Spike]] 15:51, 28 September 2012 (EDT)

:: I see your point but let me elaborate. Heat, not fire, do kill as fast as bullets. The original game mechanics separated heat from fire just as in real life. It intended to have the big heat blast damage first and then the small fire damage per turn.
:: Take the most extreme case, napalm or volcanic lava, you get fully cooked in less than a second - just by heat alone, and you may/may not catch fire later on. And heat blasts travel as fast as bullets, in some cases as fast as light. I believe the game has different Incendiary damage values to do different damage according to how strong the heat is, not the fire afterwards. The damage by fire later on makes sense because natural burning fires aren't that hot comparatively.
:: I understand the difficulty in trying to fix this. But before this fix you could kill a reaper by a few AC-I shots (which is their weakness) and now you can empty the two clips at it and it'll never die. [[User:Hellblade|Hellblade]] 03:11, 4 October 2012 (EDT)

User:Mugwump

2021-05-30T19:08:27Z

Mugwump:

Getting back into X-Com after years away. Really loving OpenXcom and playing it pretty vanilla, initially.

Looking into the "Way of the Privateer" and loving it, thinking I'll do a play-through on Superhuman that way once I get my tactical skills honed some more

Got some ideas for testing:
I believe falling one story causes no damage, but is falling more than one story possible? What damage does it cause?

Moving vertically w a Flying suit onto a prox mine doesn't trigger it, I read. But how about falling onto it?

Is free-loading ammo bug fixed in OpenXcom?

Does it work to throw out grenades/smoke over an HWP while it's still in the transport w you? how about over your own (kneeling) comrades?

If you want cover to extend further under the transport, does it work to throw smoke grenade at the top square of the ramp?

What is the rate of prox mines destroying other prox mines at various distances? Thinking of how to set up an effective prox mine field, either down a corridor or outside of UFO doors

If you have answers to these or ideas on them, please jump into my Discussion page

User:Mugwump

2021-05-30T06:04:04Z

Mugwump:

User:Mugwump

2021-05-30T06:03:21Z

Mugwump:

User:Mugwump

2021-05-30T06:02:52Z

Mugwump: Created page with "Getting back into X-Com after years away. Really loving OpenXcom and playing it pretty vanilla, initially Looking into the "Way of the Privateer" and loving it, thinking I'll..."

Getting back into X-Com after years away. Really loving OpenXcom and playing it pretty vanilla, initially
Looking into the "Way of the Privateer" and loving it, thinking I'll do a play-through on Superhuman that way once I get my tactical skills honed some more

Got some ideas for testing:
I believe falling one story causes no damage, but is falling more than one story possible? What damage does it cause?

Moving vertically w a Flying suit onto a prox mine doesn't trigger it, I read. But how about falling onto it?

Is free-loading ammo bug fixed in OpenXcom?

Does it work to throw out grenades/smoke over an HWP while it's still in the transport w you? how about over your own (kneeling) comrades?

If you want cover to extend further under the transport, does it work to throw smoke grenade at the top square of the ramp?

What is the rate of prox mines destroying other prox mines at various distances? Thinking of how to set up an effective prox mine field, either down a corridor or outside of UFO doors

Talk:Incendiary

2021-05-30T05:55:34Z

Mugwump: /* General Comments */

== General Comments ==

For now, we'll just say the smoke + incendiary stun effects only work on X-Com owned units until some tests can be run to confirm this. It's unusual that only X-Com units are affected, but the game has been known to surprise you even after you think you've worked something out.

- [[User:NKF|NKF]]

----

Given how aliens love to hang around in a smoke-filled crashed UFO, IC rounds would be insanely powerful if they did actually work against aliens in smoke. I'm glad they don't ''seem to'', as I'd be very tempted to cheat with it. They do work against aliens standing in fire, though, which is still quite cheaty...--[[User:Ethereal Cereal|Ethereal Cereal]] 21:35, 5 May 2006 (PDT)

:I do consider the "standing on fire + new IC explosions = damage" a cheat. So I just don't abuse it. I only use IC rounds to illuminate or to finish off hiding aliens. It can also work as a "pass-through-and-die" tactic, the same way Proximity Nades work, although fire damage is pretty sad xD. --[[User:Nekrocow|Nekrocow]] 00:36, 24 June 2012 (EDT)

:: I use it a lot in TFTD to clear out those island bunkers and the upper storage levels of the large train station. Either the aliens roast alive, or they come out. Otherwise yes, it's no doubt a cheat. Well, more a bug exploited as a cheat. -[[User:NKF|NKF]] 02:09, 24 June 2012 (EDT)

-----

I just edited the Incendiary page a bunch, because Brunpal's [[Talk:Experience]] questions about Incendiary sparked my interest... I never did test IN vs. experience. It's a very good question ''if'' it turns out to cause Firing experience. But while reviewing this page, I had a number of questions, for anyone interested. Also, I only tried to clarify things, and don't know Incendiary well, so fix anything you know I got wrong:
#Did I get it right re: the set [ 0, 5, 6, 7, 8, 9, 10 ] for chance of initially catching fire? I over-wrote "linear" because it seemed odd when XCOM usually goes, e.g., 0-10. (Who tested this? - A little help here please. Just making sure.)
#Why flame a zombie unless it's near death (and how can you know if it is)? It's been a long time since I used fire - if you don't have flying armor, why mess around with a zombie by burning it, why not Heavy Plasma it.
#Any research/data on tile flammability versus duration of burning is appreciated. Probably it should go on the [[Terrain]] page byte, but be clearly referenced here. It's just a curiousity, but an interesting one.
#The last line of the page says ''"The damage values listed in the UFOpaedia do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames."'' Does anyone know IN strength vs radius, then? Should be easy to test and post.
#NKF, Zombie, or anyone else... would you mind seeing if Incendiary causes the Experience counter to increase? Brunpal is right that it's important to [[Experience]]... I found [[Small_Launcher#Experience|Stun Bombs]] to count for experience across their whole range, even if no stun damage occurred... if you have 11+ Mutons in a firing squad situation, passing around an [[Auto-Cannon]] with Incendiary may be better than standard pistols, depending on the range of the blast. I could test it, but it's been a long time since I've delved into the files; maybe one of you have them more close to hand. [[User:MikeTheRed|MikeTheRed]]
-----
:Offhand, the only way I could think of to check the remaining HP on a Zombie would be by using a [[Mind Probe]]. Given the relative uselessness of a Mind Probe after Psionics are developed, as well as the time needed to use the Probe once, this seems a rather impractical course of action, unless your Rear Commander has nothing better to do. I agree, Heavy Plasma on Auto is better. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:33, 1 August 2008 (PDT)
-----
#Yeah, the set is correct. When a unit is shot with an incendiary round, the game does a calculation to determine if the unit catches fire. If it doesn't catch fire, the unit takes no damage (the 0 in the set). If the unit does catch fire, it will take between 5-10 damage points. Stupid discontinuous range, but that's what happens. As you may guess, I did the Incendiary trials over at the StrategyCore forums in the Damage Modifier topic - see [http://www.strategycore.co.uk/forums/index.php?s=&showtopic=746&view=findpost&p=39672 this] post for the particulars.
#Why flame a Zombie? Simple. A Zombie which is killed by an Incendiary round doesn't turn into a Chryssalid. Zombies are easily outrun, so you can just keep picking at them from a short distance with Auto-Cannon Incendiary rounds and then running away. Fairly effective, even when your troops do not yet have armor to protect them. And when you do not have the luxury of the Heavy Plasma early in the game, Incendiary is a good way to avoid an overabundance of Chryssalids who are not so easy to kill. As for checking the Zombie's stats, you can only rely on the Mind Probe or Psi. Neither are available early either (the Mind Probe is usually low on the research tree for most people even though you can collect enough, and Psi is difficult to use as a soldier needs to be quite proficient to use MC.
#I have been meaning to do some tests in flammability vs terrain but only recently started fooling with MCD values. It'll be next on my list.
#Here, I uploaded a very recent spreadsheet containing both I and Smoke when damage values are hacked. See [[Media:Incendiary_and_Smoke_Patterns.zip | this file]] which contains both.
#I think I fooled around with Incendiary recently in conjunction with promotions. Soldiers who shot aliens with "I" didn't get promoted. Logically, that would mean the experience counter didn't increment. UNITREF.DAT would need to be checked to verify though. Addendum: indeed, as BB mentioned in the experience page (and a quick glance at the UNITREF.DAT experience counters by myself to triple-check my aging brain), Incendiary rounds do not increase any of the experience counters.

Hope this clears up some of the issues/concerns here. --[[User:Zombie|Zombie]] 21:16, 1 August 2008 (PDT)
----
<i>"The damage values listed in the [[UFOpaedia]] do not determine how powerful an incendiary round deals damage; it only determines how wide an area will be blanketed with flames. Fire is unlike other damage; it works at initial blast and then over time, as described above."</i> and
<i>"Initial "impact" damage from incendiary ammunition is either for no points (unit does not catch fire), or between 5-10 points (unit catches fire)."</i>

This should be stressed on ALL the various relevant pages. It's important. 6.4 dmg vs 90 dmg is a significant difference!--[[User:Brunpal|Brunpal]] 09:31, 2 August 2008 (PDT)
----
It looks like Incendiary is gaining some clarity (at least for me), thanks for starting it Brunpal...
*The "6.4" was only for the initial IN round impact (set [ 0, 5-10 ]); it can then burn for 4 more rounds (set [5-10]). Perhaps a short way to state this complicated damage type is "Minimum 0 (unit does not catch on fire) ''OR'' unit catches on fire 1-5 turns, 5-10 damage/turn, 5-50 damage in total (average 21.5)". Does that look right, Zombie? I'm not sure where you got 90 from Brunpal...
:90 is the listed damage from an IN rocket.--[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)
*However, the numbers I just stated do not count possible additional damage from nearby terrain being on fire (as opposed to yourself). Maybe those should be included somehow. (And clearly, fire is much more dangerous outdoors than inside UFOs, where terrain does not burn.) But since terrain fire can last a variable number of turns, I guess you can't have a maximum damage. Average terrain damage from fire would be 6.5/terrain (1-12), but also, it can keep the unit itself burning more than 5 turns... hard to model.
*Good point about flaming zombies, Zombie. I guess you ought to know, eh? :)
*The spreadsheet looks great. Perhaps one of us can pull out the area patterns for non-hacked IN weapons and put them on the relevant pages. When it's done, the spreadsheet itself would be an asset to Incendiary (or maybe [[Damage]], if it's listing all types of damage). As has been stated, it's the size (area) of the blast that actually directly relates to incendiary weapon "strength"... the diameters you found are probably what should be in parentheses next to weapon strength, although damage can appear as well.
*Ok, no experience from Incendiary blasts. It might've been real interesting if there were, but it didn't occur to me to test. (Or maybe I tested it briefly so long ago that I forgot.) I would've guessed that they did, because the stun bomb and explosives do. Oh well.
*P.S. Brunpal, we may not have touched pages in a year, but most/all of us have "Watch this page" turned on, so we get immediate notification of any pages we've edited or Watched. :)
-[[User:MikeTheRed|MikeTheRed]] 09:17, 5 August 2008 (PDT)
----
*Sounds correct MTR. I think Brunpal was just comparing the "damage" (actually strength) of the Incendiary Rocket (90) to the average damage due to the "impact" of the blast (6.4).
*Well, it isn't ''nearby'' terrain on fire which you have to worry about, it's the tile directly underneath a units feet which causes the most concern. If that tile is on fire and the unit doesn't move, it will take 1-12 damage points. While true that terrain on fire can last a variable number of turns, there is a definite upper-limit to how much damage a unit can possibly take. Fires don't last forever, and the combustibles eventually are consumed leaving either scorched earth or a damaged tile. Those damaged/destroyed tiles usually cannot be started on fire again by the spread of flames. They can only be set ablaze with incendiary ammo, and even then for only 1-3 turns (normal for dead tiles). So it's certainly possible to find a max damage. And for the most part, the things that burn the longest are usually objects, not tiles. And most objects you can't stand on anyway. But I totally agree that it's hard to model how fire functions due to the two forces at work: "impact" damage and damage due to standing in fire.

P.S. Some of us are actually around here and don't need to be coaxed back into existence by an email when a watched page is changed either. Just because it's quiet, it doesn't mean nobody's home. :) --[[User:Zombie|Zombie]] 20:34, 5 August 2008 (PDT)
----
While understanding the whole formula for fire and fire damage happens is useful, it was not thinking to go that broad. I was just interested in what occurs from the moment a solider takes his shot, to the time that solider gets his TU back. ie damage from incendiary rounds vs fire damage. --[[User:Brunpal|Brunpal]] 21:39, 5 August 2008 (PDT)

----
It looks to me that, unlike all other forms of damage, Fire damage ignores armor, goes right past it. If so, this should be made explicit on the main page? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 05:55, 30 May 2021 (UTC)

== Incendiary vs Large Units ==

We're discussing this in [[Talk:Sectopod#Incendiary vs Sectopod]], and a question came up. When an IN round impacts one segment of a large unit, presumably that segment gets the "Incendiary impact" function, i.e. 6/7 chance of catching on fire for 5-10 damage plus 1-5 turns of being on fire. Does the same "impact" function also apply to the 3 adjacent squares (6/7 chance), or is it just the "standing in fire" chance? If you had multiple regular-sized units standing in the area of effect of an IN round, they would each get "impact" effects (right?). So it ''seems'' logical that all 4 segments of a large unit, inside the area of effect, are also exposed to "impact" effects. But I wanted to check. [[User:Spike|Spike]] 06:34, 9 March 2009 (CDT)

Oh boy! Calculating this not only depends on a lot of unknown assumptions, but is fiendishly complicated - especially if you factor in the "funky fire" bug. And contrary to my noblest efforts, it's impossible to use IN weapons without inadvertently exploiting this bug. Even if you only fire IN at a single target until it's dead, once the target is "standing in fire" you effectively just can't miss.

Anyway back to the Large Targets specifically. The key assumption above is whether all regular-sized units in the area of effect of an IN burst are affected with "impact effects" - 5-10 dmg & 6/7 chance to catch fire. If they are, it's reasonable to assume the same thing happens to the 3 other segments of a Large Unit. However I suspect this is not the case, and strictly speaking "impact" effects should only occur at the single, impact square of an IN round. Testing needed!

More likely, the GZ+1 squares, whether occupied by small or large units, are only subjected to the "standing in fire" effects: 1/3 'catch fire' probability, and 1-12 terrain-based damage. And these effects are applied once per turn, not once per hit.

However, all of this is turned on its head by the 'funky fire' bug. After the first round hits, all units (and all Large Unit segments?) are "standing in fire". (Though maybe these fire damage routines run only for the "control" segment of the Large Unit? Possible, but unlikely.) Since they are standing in fire, the funky fire bug applies and all units/segments are hiit with "impact" effects.

So assuming a Large Unit is ''already'' standing in fire (e.g. from a previous IN hit or near miss), damage per IN round fired is 6.4 x 4
= 25.6 average, 10x4= 40 max. Subject to resistance/vulnerability modifiers, but ignoring armour level. In addition as multiple IN rounds are fired, the chance of all segments catching fire quickly approaches certainty. This not only means the Large Unit will sustain further damage at the end of the turn, it makes it impossible to escape the 'funky fire' trap by moving out of burning squares.

(Any testing needs to be very careful and probably only fire a single IN round per game, otherwise 'funky fire' will skew the results.)

So, in conclusion, the TU/kill factors I put up on the Talk pages for the Large Units ([[Talk:Reaper]], [[Talk:Cyberdisc]],[[Talk:Sectopod]]) should pretty much reflect the 'funky fire' reality after the first round connects, apart from the fact that you actually can't miss. The very first IN round to be fired would have the same effect (for immediate damage) on a Large Target as on a small one. But I really don't want to update the numbers to reflect this fact, it's just too awful. For AC-IN, the firepower factors will be about 6 times better than stated. Maybe I'll just remove them. :(

[[User:Spike|Spike]] 15:51, 10 March 2009 (CDT)

=== Simple Tests ===

I did a small number of tests and found some interesting results. In 5/5 tests, all 4 squares of the target (Reaper) were on fire the following round. (It's hard to tell if they are on fire the same round, as you need to extinguish the fire with smoke to see). Perhaps this makes sense, as it's a UNITREF attribute and so applies to the whole unit, not its 4 component squares?

Looking at the damage, it looks like "impact" and "on fire" damage applies to all 4 squares, i.e. x4 normal. Damage clusters tightly around 16-18 per hit which is roughly the expected value, maybe a bit lower (at x4). And since we '''are''' on fire, should expect an average of 7.5 ({5..10}/6) rather than 6.4 ({0,5..10}/7? Maybe something else is going on here, as these numbers seem a little low - 6.4 x 4 = 25.6 per hit or 7.5 x 4 = 30.0 per "on fire" hit might be expected on a Large Unit.

:Drat. I didn't factor in the Reaper's 170% Susceptibility to Incendiary. So the actual damage levels are more like 10 per hit. Maybe there is no multiplier for the 4 squares? Hard to figure out what's going on here. In tests on hacked humans, armour level is not a factor vs Incendiary damage, otherwise I'd suspect the under-armour or something. 2.5 avg damage per segment seems too low. 10 average damage per alien seems too high - that should be the max, not the average. Is some mechanic pushing the average up to the max? I don't have a clue right now. [[User:Spike|Spike]] 06:53, 11 March 2009 (CDT)

The damage seems to be regardless of "funky fire" effect. A round fired at a target that is not burning / in fire seems to do about the same damage, per hit, as one that is in fire / on fire and so subject to the funky fire bug. So the only 'bad' effect of the bug is that you never miss, and you hit everything that is in fire / on fire. Not quite so bad, and it allows you to play honest by only ever firing at one target, not hitting any other targets by accident (!), and firing from point blank range so it doesn't matter that you never miss.

Burn Time was as high as 7 when multiple IC rounds were fired (on auto). Higher than we thought possible (1-5 range expected). However it sometimes goes DOWN after additional hits. Possibly the value is re-randomised with every new IC impact, but hits are cumulative while firing auto bursts?

Here's the raw test data:

Test 1.
-
2 DH on Reaper, mix of auto and snap, some other IC impacts on others
Burn Time=7 - exceeds known limit of 5
All 4 sq on fire next turn
Is 'on fire' global? It's in Unitref, so maybe
-
Test 2.
-
1 DH on Reaper, only IC shot fired in game.
In firing turn, taken 132/148 = 16 damage. Burn time=3
Start of T+1, taken 122/148 10 more damage, Burn time=2
T+1 Reaper shows all 4 squares burning
-
Test 3.
-
Revisit #2 firing turn... fire another round (this will use funky fire)
So 2nd IC hit, 2nd rd fired, same target.
Health now 114/148, further 18 damage
But Burn time has dropped to 2! Must re-randomise on each hit??
Maybe only accumulates during auto burst?
-
Test 4.
-
Let's try lots of hits. Hack up accuracy to 255
OK 3 out of 3 hits on Auto
T+0 Health=98/148=50 damage (17 avg) Burn=6
T+1 Health=81 (17 more dmg) Burn=5 All 4 squares on fire.
-
Test 5.
-
Revisit #4 and push to 6/6 hits
T+0 Health=41/148=107 (18 avg) damage Burn=7
T+1 Health=21 (20 more dmg) Burn=6 All 4 squares on fire.
-
Methodology (Apart from Test 1) = only ever 1 (same) target in any IC AoE; no misses
(To try to minimise the impact of 'funky fire' effects - but can't eliminate)

[[User:Spike|Spike]] 23:27, 10 March 2009 (CDT)

I re-ran the same simple tests against a regular-sized (Floater) target instead. The results agreed much better with the 'standard model' of [[Incendiary]] effects. All results were within the permitted ranges in the 'standard model', though some values were unexpectedly. I think some variables to look for in Incendiary mechanics are:

* Large Unit vs regular unit behaviour looks to be different
* Auto burst vs single explosion looks to be different (maybe just due to funky fire bug, maybe not)
* Tile MCD "time to burn" value seems to affect one or more of the other calculations / probabilities
* Burn Time on the unit can go up as well as down. New hits seem to re-randomise the value.
* End of turn processing does not always reduce unit Burn Time by 1. Can a terrain fire add to unit Burn Time?

[[User:Spike|Spike]] 21:25, 11 March 2009 (CDT)

:I doubt a terrain fire adds to the time a unit is on fire. Actually, I'm quite positive on this since my tests from a while back were quite thorough. The counter can only tick down to 0, and when it does a terrain fire will have a chance of "reigniting" the soldier again.

:Anyway, I had to start from scratch again on testing due to a few issues with my test scenario. I totally forgot that the first soldier on the unit roster is a bad choice for a "designated hitter" since he can never be automatically selected on a reload. Soldiers lower on the order are much better choices. So I got the shooting automated, but each reload was taking too much time since I had to reselect the shooter, select the shot, move the view down a level, shoot the target and abort. Having the soldier already selected cuts out 2 actions in the list allowing the script to run more efficiently. I'm going to try to get everything properly setup tonight, then start testing tomorrow morning. With a little luck and about 2 hours of babysitting the script to make sure it doesn't quit, I should have some prelims. --[[User:Zombie|Zombie]] 21:55, 11 March 2009 (CDT)

----
Looking forward to seeing that data! I did some more testing just for the special case of Large Units, about 40 tests. My tentative conclusions:

# Damage range per 'impact' hit is the same as regular units, around 5-10 x Vulnerability (maybe + MCD Burn time?)
# Large units go on fire about 1/7 of the time when receiving a direct hit - as expected
# Either all 4 segments go on fire, or no segments go on fire - no 'part segments on fire'
# Unit burn times are not correlated with unit damage received
# Auto fire has the same average damage level per hit as snap fire
# Unit Burn Time can exceed 5, both on Snap and Auto. Highs of 6 (Snap) and 7 (Auto) were seen. Maybe 1-5 + MCD Tile Burn Time?

All my tests were done on the grid-lined pavement tiles from urban terror missions, which have an MCD default burn value of 2. For some of the "setting the large unit on fire" tests, I had the target floating in mid air, because air does not burn even during the turn that the IN round explodes - it makes it easier to see the unit burning.

From Bomb Bloke's editor notes, the 4 potential MCD tiles in a map location are: a North Wall, a West Wall, a Ground tile, an Object tile. All 4 of these MCD tiles might have a burn time value. But Ground and Object are the most likely to be relevant.

[[User:Spike|Spike]] 21:58, 12 March 2009 (CDT)

:Ok, I got the script running and optimized it a bit to cut down some wait cycles. Right now it's cranking out approximately 400 trials per hour which is about as fast as I can make it go without removing some desktop icons (all the icons have to refresh at the end of each logging cycle which takes a little time). Anyhow, just for giggles I stopped it after 400 trials to get some prelims.

:<table {{StdCenterTable}} class="sortable">
:<tr {{StdDescTable_Heading}}><th align="left" width="90">Damage</th><th width="90">Count</th><th width="90">Pct%</th></tr>
:<tr><th align="left">1</th><td>68</td><td>17.0%</td></tr>
:<tr><th align="left">6</th><td>58</td><td>14.5%</td></tr>
:<tr><th align="left">7</th><td>45</td><td>11.3%</td></tr>
:<tr><th align="left">8</th><td>63</td><td>15.8%</td></tr>
:<tr><th align="left">9</th><td>55</td><td>13.8%</td></tr>
:<tr><th align="left">10</th><td>64</td><td>16.0%</td></tr>
:<tr><th align="left">11</th><td>47</td><td>11.8</td></tr>
:</table>
:If you average the percent columns, it comes to 14.28571429% while the expected is 1/7 or 14.285714285714285714285714285714 which is a difference of 4E-09. This means 400 reloads is plenty enough values for this application. Great news! Well, as you can see, instead of the set [0, 5, 6, 7, 8, 9, 10] for MCD of 1, this scenario where the MCD was 0 is shifted up by one [1, 6, 7, 8, 9, 10, 11]. Interesting.

:Tomorrow I'll rerun the MCD 1 scenario again to verify the values and damage set. Then it's on to the MCD of 2. --[[User:Zombie|Zombie]] 01:50, 13 March 2009 (CDT)

:: Extremely interesting! By the way, it was probably a late night but - the average any 7 numbers that (must) add up to 100% is always going to be 1/7th of 100%, so that result doesn't really demonstrate any confidence in the data. It would be the same with one result, or with a trillion results. The 4E-09 discrepancy is just the precision error in your calculator/spreadsheet's calculation of the percentages and the average of the percentages. You've got some considerable variation from 1/7th on the individual numbers, I'm not sure if that's just to be expected with only 400 trials. But for example "0" and "10" are both a bit high so it ''might'' be non-linear (probably not). Anyway we'll see when all your results are in! (To measure the degree of variation from the expected result, what you want is a chi-squared test or something - and I don't know what I'm talking about there so I'll shut up!)

:: I'm checking Bomb Bloke's MCD database, and there are some tiles in there (U_BASE 22-25) with MCD burn value of 30 - I might play with those and see if anything dramatic happens. Oh except looks like they can't be set on fire (255 flammability). There are others that are quite high (8-), and still flammable. Or I could hack an MCD file (scary). Maybe I'll just wait for your results Zombie! [[User:Spike|Spike]] 05:49, 13 March 2009 (CDT)

= Incendiary Research =

== Large Units On Fire ==

Here's another interesting test for setting Large Units on fire. Set AC-I power down from 42 to 1.
At this IC power, there is no area effect. You can't even start a fire on one tile.
All you can do is set units on fire with a direct hit. This means there is no way the other 3 squares of the
Large Unit are in the IC area of effect.

Result: Whether you hit a one square regular unit or a 4-square large unit, if it goes on fire, '''all''' squares of the unit still go on fire. Along with the fact that the inflicted IN damage level vs Large Units is basically normal (see above), this tends to confirm that being on fire is a "unitref" property and, unlike HE and Stun Bombs, is not applied (multiplied) vs the number of squares the unit occupies. (In fact it would be good to check that HE is actually applied separately to each square, with different HE strength, potentially different armour facing, etc. Maybe the engine just simplifies things and multiplies damage by 4?)

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)

== Unit Burn Time ==

Unit Burn Time seems to be considerably '''cyclic''' rather than random. Very often, it just steps down by one from the previous value. I suspect this is because the "impact" routine calls the "end of turn" incendiary/smoke routine (see [[User talk:Seb76#Incendiary Bug]]). Sometimes it does not happen, maybe because some other factor has caused the Burn Time to increase.

Here's some data. This was done against a Reaper with AC-I power set to 1 (and 10% TU Snap fire cost). But I've seen similar results with standard AC-I.

Hit H/H Dmg/Avg Burn Time
1 137/150 13 2
2 126/150 11 1
3 104/150 22 0 Very high damage (=13x1.7). Unit not on fire when game restored.
4 96/150 8 7
5 81/150 15 6
6 66/150 15 5
4,5,6 76/150 /9.33 5 (Auto) 9-10 (=5-6x1.7) is near minimum dmg
7 56 10 4
8 48 8 4 What happened here? didn't cycle. MIN dmg (5x1.7).
9 35 13 6
10 25 10 5
11 10 15 6 New shooter takes over
12 2 8 5

[[User:Spike|Spike]] 07:56, 15 March 2009 (EDT)
:You're right on spot once again ;-) When a unit takes a direct hit from an IN round, it is set on fire (the duration is randomly chosen between 0 and incendiarydamagemodifier/20). Then the "end of turn" routine is called, which inflicts damage *and* decreases by one the number of turns to be on fire (done for all units). Then it sets on fire units standing in blaze. The duration is calculated as for direct hits; if the unit was already on fire, it'll take the maximum value between the new value calculated and the current value affected to the unit on fire. Not sure it is readable but I think you'll sort it out ;-) [[User:Seb76|Seb76]] 10:51, 15 March 2009 (EDT)

== Incendiary in TFTD ==

I read [[Weapons (TFTD)#Phosphor|somewhere]] there are reduced effects underwater (or enhanced effects on land) for TFTD Phosphor rounds. I couldn't find an exact statement of the quantitative difference - does anyone know this? [[User:Spike|Spike]] 14:53, 9 March 2009 (CDT)

:The effects of Incendiary weapons underwater (or Phosphor, as TFTD refers to it) is halved over the UFO equivalent. Incendiary weapons are doubly effective on the surface(Terror Missions) vs underwater, but of the three weapons that can fire Incendiary, two of them(Torpedo Launcher and Hydro-Jet Cannon) can only be reaction fired on land. The Gas Cannon can be fired in eiither location. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:08, 9 March 2009 (CDT)

:: It's clear that the effect underwater is half the effect on land. But does the base level (in USOPaedia / OBDATA) refer to land use or underwater use? [[User:Spike|Spike]] 15:13, 9 March 2009 (CDT)

:As I recall, the base level is on land. The numbers for Phosphor ammo are close to the UFO Incendiary damage numbers, but I know it spreads less underwater. [[User:Arrow Quivershaft|Arrow Quivershaft]] 15:15, 9 March 2009 (CDT)

:: Look at the (puny) area effect pattern sizes underwater, that sounds about right. Can anyone confirm this? [[User:Spike|Spike]] 15:40, 9 March 2009 (CDT)

There is actually no difference between the pattern for the Gas Cannon's P rounds underwater as on land. Both have a r=3, d=7 pattern. (CE version at least). Maybe the pattern is smaller the deeper you go? --[[User:Zombie|Zombie]] 16:45, 9 March 2009 (CDT)

<gallery widths="200">
Image:GC-P (underwater).png|Flame pattern from Gas Cannon Phosphorous rounds underwater.
Image:GC-P (on land).png|Flame pattern from Gas Cannon Phosphorous rounds on land.
</gallery>

:OK now I'm really confused then! (I realise I was getting confused with the Dye grenade's small footprint vs Smoke grenades). If the blast pattern is the same size, that implies the weapon power is unchanged. So in what sense is Phosphorus "half as powerful" underwater? Does it burn half as long? Is the impact and fire damage halved? [[User:Spike|Spike]] 16:49, 9 March 2009 (CDT)

I really doubt the damage to units would be affected if the power of the round was modified. The power of the round only determines the size of the pattern produced, not the damage inflicted to units. I'll have to check the burn times and spread rate but my thought is that the two are identical in the version I'm using. Like I said, the pattern may get smaller the deeper you go underwater. The pic above was for a shallow site. It'll take a while for me to find a deeper site to check it out, otherwise some editing of the game files may be necessary to force the scenario.

I just checked the Dye Grenade underwater and on land. Both produce the same r=1, d=3 pattern. So yeah, they are really pitiful when compared to the Smoke Grenade.

Don't really go for the use of "impact" damage with Incendiary/Phosphorous rounds. There is no real impact since the damage range is discontinuous. The unit either catches fire from the splash of fire (in which case it does 5-10 damage points), or the unit doesn't catch fire and the unit remains unharmed. If there were such a thing as impact damage, the range would be continuous like normal weapons, in this theoretical case it would be [0-10] inclusive (ie the set [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]. --[[User:Zombie|Zombie]] 17:36, 9 March 2009 (CDT)

Anyway, the half thing came up because AQ was comparing TFTD to UFO, not comparing the effects in TFTD from underwater and on land. However, further comparisons reveal that a hacked HC-I round of 60 produces the same pattern as a GC-P/60 round. Perhaps this whole dilemma can be traced to the Dye Grenade? --[[User:Zombie|Zombie]] 18:28, 9 March 2009 (CDT)

:That's entirely possible the Dye Grenade is the source. However, several of the pages for the TFTD weapons state that Phosphor is far weaker in water, so I didn't check. My mistake. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:35, 9 March 2009 (CDT)

Thanks for the feedback everyone. So this could just be a recycled rumour? I guess the general assumption is that the game engines are identical, so we would want evidence that TFTD is different. Looks like Zombie has proved that the area effect is equal (at least at shallow depths). That leaves only the fire damage or fire duration. Testing that would require repeated observations to check if fire damage is less than 6/hit, less than 6/turn, and burning for no more than 2-3 turns. [[User:Spike|Spike]] 20:14, 9 March 2009 (CDT)

:As with any wiki where contributions can come from anywhere, there are bound to be problems with validity of the statements made. So unless those statements are backed up by real-life test data instead of memory or hearsay, take them with a grain of salt. The other point is to avoid spreading disinformation at all costs (I have been guilty of this as well, but try to at least quantify them). So there you go. I'm still trying to get a deeper underwater mission to check the size of the pattern produced there. Checking the spread of flames or damage inflicted to units shouldn't take too long though. I'll see if I can't get that done tonight yet. --[[User:Zombie|Zombie]] 20:23, 9 March 2009 (CDT)

:Ok, I ran some trials with an unmodified GC-P round on the normal seabed floor against soldiers having 100 health and 0 all-around armor. For the guy standing at GZ, I saw ending health values of 99, 94, 93, 92, 90, and 89 (n=50). So that comes out to 1, 6, 7, 8, 10 and 11 points of damage respectively. I didn't think 11 damage was possible. Here's where things differ though. All the other guys who were clustered around GZ always received only one point of damage, never more, never less. In EU, the guys around GZ took damage equal to the guy at GZ. Odd. So then it occurred to me that perhaps I should check the MCD values of the seabed (TFTD) and the desert (EU) landscapes. Both are basically identical in terms of armor. But the seafloor has a "time to burn" value of 0 while the desert has a value of 1. So maybe our understanding of normal fire isn't totally complete. I'm going to go back to EU and retest the desert landscape with varying MCD burn time flags to see how that affects damage. ;) --[[User:Zombie|Zombie]] 23:00, 9 March 2009 (CDT)

:: The whole Phosphor being half effective under water is related to the burn time and spread, if I remember correctly. The settings in the MCD files may be the culprit. The actual damage dealt or initial spread may not necessarily be affected.

:: Hey, I just had a wacky idea. XComutil. Use its feature where you can set the depth of a mission. Launch a mission on a island terror site map (again, use XComutil's map picker to get to this faster). Lots of grass to burn there. Set fire to it and count how many turns before the fires die out. Redo the test, but this time set the depth to a deeper level. Try the whole process out again.

:: Next repeat this with one of ye-olde seabed maps. They look really weird without the blue palette shift when played on land, what with the landscape being gray.

:: It's possible that the half-effectiveness relates to the fuel that the fire has to burn more than anything else. Further confirmation on how long the flames stick to a target when on land or underwater may be helpful. -[[User:NKF|NKF]] 01:28, 10 March 2009 (CDT)

:I've been burned one too many times using editors or utilities to mess with saved games. Half the time they introduce some unknown "feature" which isn't documented. Thanks, but no thanks. I only test with an unmodified game, except for the changes I make myself to keep control of the situation. Anyway, I tested a patch of fire on the seabed to see how long it remained lit (which has a "time to burn" value of 0). It only stayed lit the current round the shell detonated. After that the fire went out. So this agrees with what is expected. Will continue to work on this as I get time. --[[User:Zombie|Zombie]] 01:51, 10 March 2009 (CDT)

Well, I suppose my recommendation doesn't necessarily need XComutil. It would've certainly made it easier. But yes, it does introduce a few things that work behind the scenes that we might not know too much about. However, if I remember correctly, one of the battlescape savegame files should hold the depth level of the current map you are playing on. All you'll need to do is tweak that to change the depth of the map.

One other thing, the different effect HE has on the same tiles underwater and when on land (ala the Triton) may also be one of the other culprits behind the belief that phosphor is less effective on land. Being able to blow up the Triton on land, but have it appear virtually indestructable when underwater does that. -[[User:NKF|NKF]] 01:59, 10 March 2009 (CDT)

----

re Zombie's underwater tests, there is normally (i.e. on land in EU) a difference between the IC damage on the target of the direct hit, vs lower damage to others in the area of effect (hmm contrary to my IC kill modelling assumptions: uh oh I may've spoken to soon). But only seeing 1 damage on the others in the AoE does seem low. We need to figure out why. Did any of the other targets catch fire? Does that ever happen underwater? Do tiles ever burn past the turn when the IC round is fired? Any of these factors would reduce total fire damage/effectiveness by '''more''' than half. Actually, doesn't it say the 1-12 damage for "in fire" is ''not'' random, but dependent on terrain type? That could be the answer.

The [[Incendiary]] article actually mentions '''4''' modes of fire damage, only 3 of which are quantified:

#"impact",
#"being in fire"
#"being ''on'' fire"

The 4th mode is "damage from burning ''terrain''. Only a tantalising mention is given, no quantitative details. This could be the source of the discrepancy. In fact it might be a component of "being in fire" that's not fully understood. I think Zombie is right to review the assumptions on this one - nice work! [[User:Spike|Spike]] 04:05, 10 March 2009 (CDT)

:As I recall, "damage from burning terrain" is synonymous with "Standing on a tile that's currently on fire." Thus "Being in fire." But that's me and I'm tired this evening, so I could be wrong. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:30, 10 March 2009 (CDT)

I performed my TFTD Phosphorous tests underwater and after the flames died out some of my men did catch fire. So this part seems to jive with that of EU. Tiles do not burn longer than its "time to burn" value in the MCD files. So for instance, in the seabed underwater testing mission, the tiles have a MCD burn value of 0 which corresponds to the results seen (ie fire didn't stick around into the aliens turn or X-COM's next turn either, it only stayed lit the turn it detonated). There really is only 2 "modes" of I/P/fire damage:

<ol><li>The code used for determining if a unit catches fire: 0 damage (if the unit didn't catch and was able to shrug it off) and 5-10 (if the unit catches).</li>
<li>Standing in fire.</li></ol>
At least from the initial tests in TFTD, units outside GZ are just considered to be standing in fire that turn and always take 1pt of damage. Anyway, I don't want to talk myself into a hole without doing more tests. All the following trials I do will be in EU to hopefully curtail any unknowns in TFTD. Once EU's code is figured out then it can be applied and compared to TFTD. --[[User:Zombie|Zombie]] 09:06, 10 March 2009 (CDT)

: If they are "standing in fire", do you think the 1pt damage/turn is based on the fire characteristics tile/terrain type they are standing on? Is it more generally 1-12/turn, dependent on terrain? Also if you get a chance can you test large units and see what kind of effects they take on the GZ+1 squares? If the GZ+1 squares of a large unit are just 'standing in fire' rather than 'catch fire/5-10 impact damage' this will substantially weaken IC vs large units. And I will have shouted too soon! :) [[User:Spike|Spike]] 09:18, 10 March 2009 (CDT)

I did some ad-hoc tests in TFTD. Actually I just ran around firing GC-P and HJ-P rounds everywhere. :) On a typical seabed layout, I found that most things don't burn - the fires don't last into the next turn. The only things I could get to burn were the green moss stuff and and coral skeleton "trees". Even the barrels do not burn. Also, I did not see much sign of terrain damage caused by the fires. But the moss and coral did burn for the normal period, i.e. 1-5 turns.

I also managed to kill an Aquatoid with a single direct hit from a GC-P, in one turn. He died at the end of my turn or the start of his. That seems unlikely. 5-10 from being hit, plus 1-12 for standing in fire, plus maybe another 5-10 from being on fire? It's just about possible I suppose, to max out near 32 damage (if the terrain offers you "12" when it burns). Anyway those are my unsystematic enquiries. I have the 8 save files of various stages of the battle if anyone wants to take a look. It was from a virgin TFTD installation and there was no editing or jiggery pokery.

OK I've uploaded the save files [[Image:TFTD Incendiary Tests 01 Spike.zip]] and taken a look myself with BB's editor. Prior to being hit (Game_4) our Aquatoid was in rude Health, 30/30. Immediately after being hit (Game_2) he was at 19 Health (no Stun damage) and On Fire, as well as Standing in Fire. That implies 11 Damage from the "impact effect" which is not supposed to happen. As noted, at the end of the same turn or beginning of his next turn, he dies. He looks to be standing on a standard seabed square, just sand, the kind of thing that does not burn. He is next to some of the brown cushion-like coral, but I don't think that burns, at least not over multiple turns. In fact in the same turn he is hit, at the end, you can see him dead (Game_3). Since there was only one alien, he died in the same turn. OK that's slightly confusing, maybe someone can double check the turn numbers in the save files (don't know where they are).

[[User:Spike|Spike]] 13:29, 10 March 2009 (CDT)

Doh. I is a idiot. The Aquatoid was killed by the incendiary fire bug - I fired extra IN rounds at terrain objects after he was on fire. Which explains why he is already dead by the end of my turn. [[User:Spike|Spike]] 15:08, 10 March 2009 (CDT)

:Yeah, you gotta watch that. Well, anyhow, I edited the desert landscape in Enemy Unknown to have the same MCD "time to burn" value of 0 as the seafloor in TFTD. From the limited tests, the results look the same as in TFTD. (Fire burns out after the initial turn it detonated, units around GZ taking 1 unit of damage while the guy at GZ got more). So that means I can focus my efforts on EU with little worry because there will be no issues. I'm going use BB's logger and AHK to automate the data gathering aspect to save me a bunch of time. I'll probably need the full requisite 2000 reloads though, as the guy at GZ is not the same as the 24 soldiers around him. Wish me luck. :) --[[User:Zombie|Zombie]] 15:54, 10 March 2009 (CDT)

Good luck! I just read the MCD article, and it mentions 2 fire-related byte fields in MCD - "likelihood of catching fire" as well as "time to burn". Is the last field variable or fixed? Could the first field determine the damage/turn to units when it's on fire? Also with a possible 4 terrain items that could all be burning, is the maximum damage higher than 12? [[User:Spike|Spike]] 16:10, 10 March 2009 (CDT)

:Offset 45 is the flammability rating of the tile. This most likely controls whether an adjacent fire will spread to the tile in question. (For instance, if a fire is burning and the next tile over is a tree or something, it'll probably spread there fast because of the combustibles present). The other byte is offset 57 which is the one we are after. Don't know about the 4 types of things which can exist on a tile at once. I think the most I have ever seen is 2 (usually ground and a wall). Wouldn't hurt to edit a tile to include all 4, but that's an entirely different test to do. It'll have to wait until we get a better understanding of basic fire. ;) --[[User:Zombie|Zombie]] 19:38, 10 March 2009 (CDT)

::Here's a question. On Large units, if only one segment of the Large unit is on fire, will the fire spreading code allow the other three segments to catch on fire? [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:13, 10 March 2009 (CDT)

:I highly doubt it. Unit fires are completely different creatures from terrain fires. Needs testing though. --[[User:Zombie|Zombie]] 20:55, 10 March 2009 (CDT)

::Yes it would have to be a very special case, since afaik fires do not spread from regular units on fire to adjacent terrain or to other adjacent regular units. Though it would make more sense than any of those things. [[User:Spike|Spike]] 21:03, 10 March 2009 (CDT)

== Incendiary Bug ==

(Also known as the [[Known_Bugs#Funky_Fire|Funky Fire/Smoke bug]].) I made some suggestion about why this bug happens, and how the code could be patched to fix it: [[User talk:Seb76#Incendiary Bug]]. [[User:Spike|Spike]] 07:13, 12 March 2009 (CDT) Here is the general discussion of the bug:

With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the "end of turn" criteria to select units for instantaneous damage/effect when an IN round explodes. I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)

OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:

# In area of effect
##add fire to tiles
##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)
# IF a unit was hit directly
## check to see if it catches fire
## ''possibly'' do "impact" damage.
# Return, '''without''' calling the end-of-turn smoke/fire routine

And it's entirely possible there was never supposed to be any "impact" damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the "impact" damage could just be a side effect of the funky fire bug - applying the 5-10 "on fire" damage right away, when it was meant to be applied at end-of-turn.

[[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)
:Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)

I also suspect that other "end of turn" processing happens with every IN round fired. I am pretty sure "fire spreading" checks occur, as I have seen fire spread when using perfectly accurate shots. Either "fire spreading" happens, or there is a random element in incendiary area of effect, that is definite. I want to repeat these tests to see if "catch on fire" effects also happen for those who are standing in fire when an IN round is fired. [[User:Spike|Spike]] 08:59, 31 March 2009 (EDT)

== Mwahaha ==

Was exploiting the Elevator Shield trick on an Alien Base Assault, and I had the forethought to pack lots and lots of Incendiaries. My sick sick mind found it amusing to set all those aliens on fire and watch them roast stupidly and helplessly. (Jasonred)

= Fire Damage =
(moved from talk:UFOextender)

Not sure if the bug is already posted. And Not sure if I should post the bug here or in [[Talk:Incendiary]]. Problem is if you use extender to fix funky fire bug. Incendiary no long does any damage at all. Units only take the small amount of damage after ending turn because they're on fire. Using 1.28.3 extender

To test this. I stripped a soldier of armour. And pounded four incendiary rockets into the soldier in the same turn. No damage. And then next turn, his health drops a little because he's standing in fire. This may not be a problem for most players. But it is still a major bug. I understand the funky fire problem is already difficult to fix, and I say thanks to all who will try to help solve this bug. [[User:Hellblade|Hellblade]] 14:44, 28 September 2012 (EDT)

: That's not a bug, that's the fix. Incendiary damage is only applied at the end of the turn. Think about it... does fire kill faster than a bullet? Faster than a grenade? Can you kill someone with fire faster than they can get a shot off back at you? No, to all these things. To compensate for fixing the bug, fire damage is doubled compared to the previous end-of-turn fire damage (that always existed). It is no longer applied per shot or per impact. All you get "per impact" is another chance to set the target unit itself on fire. Incendiary is a weak attack. It has the benefit of a wide area effect, no HE block, and ignores armour. There are situations when IN is the only effective weapon XCOM possesses. But, like everything, it has strengths and weaknesses. [[User:Spike|Spike]] 15:51, 28 September 2012 (EDT)

:: I see your point but let me elaborate. Heat, not fire, do kill as fast as bullets. The original game mechanics separated heat from fire just as in real life. It intended to have the big heat blast damage first and then the small fire damage per turn.
:: Take the most extreme case, napalm or volcanic lava, you get fully cooked in less than a second - just by heat alone, and you may/may not catch fire later on. And heat blasts travel as fast as bullets, in some cases as fast as light. I believe the game has different Incendiary damage values to do different damage according to how strong the heat is, not the fire afterwards. The damage by fire later on makes sense because natural burning fires aren't that hot comparatively.
:: I understand the difficulty in trying to fix this. But before this fix you could kill a reaper by a few AC-I shots (which is their weakness) and now you can empty the two clips at it and it'll never die. [[User:Hellblade|Hellblade]] 03:11, 4 October 2012 (EDT)

Morale

2021-05-30T05:34:28Z

Mugwump: /* Events which Affect Morale */

Your soldiers' Morale scores determine whether they will panic or go berserk in the midst of a bad situation. Morale for all units is set at 100 at the start of each mission, and can rise or fall depending on events which occur during combat.

A high [[Bravery]] score will reduce the amount of Morale lost due to bad events, and the presence of a high-[[rank]]ing officer on a mission can reduce Morale penalties as well. The loss of a high-ranking officer can in turn produce large Morale penalties.

When a unit's Morale drops below 50, there is a chance it will panic or go berserk.

== Value Ranges ==
All units, alien and friendly, start with a Morale of 100 at the beginning of combat. Morale can never go higher than 100 or lower than 0 -- but if it falls below 50, a unit may panic or go berserk which will cause it to rise by 15 points.

When morale is between 100-50 units will function normally, but between 49-0 there is an increasing chance of panic or berserk, with a 100% chance when morale is at 0.

== Events which Affect Morale ==
* Own unit killed - surviving units lose 0-35 points, dependent on unit bravery, squad leadership, and rank of lost soldier. Applies even if your soldier was mind-controlled by aliens when killed.
* Own unit knocked unconscious - no effect on squad morale
* Own unit zombified - no effect on squad morale! (however, you must understand that zombification is a completely separate process from being hit, being hurt, and being killed! You can be zombified AND killed by a Chryssalid, or just zombified. Being zombified and KILLED does the same morale loss as being killed.)
* Own unit hurt - no effect on squad morale, unit hurt loses points according to this equation: Morale Loss = INT( (110 - Bravery) * Health Loss / 100) (No morale lost for injury by Incendiary/Fire, however)
* Friendly fire hit - no effect beyond injury morale loss in the soldier hit
* Friendly fire kill - squad loses normal amount, soldier loses 20 extra points adjusted only by leadership. This works both ways; MC three aliens and have them kill three others, and the morale of their entire squad will be in the mid 40s afterwards. It's possible to make Sectoid/Ethereal Leaders or Mutons panic if you understand how morale works, which is also why base Bravery is so important as well.
* Alien hit/hurt - no effect on your morale
* Alien killed - squad gains 10 points, adjusted by squad leadership; soldier gains 20 extra points adjusted by squad leadership
* Panic/berserk - soldier gains 15 points flat
* [[Psionics|Psionic Panic]] attack - A successful attack causes the target to lose 110 points, less bravery (e.g., a unit with 40 bravery would lose 70 points); chance of success is dictated by Psionic formula
* [[Psionics|Psionic Mind Control]] attack - Successful mind control leaves a soldier at 0 Morale. Thus, the turn after Mind Control, they always suffer Panic/Berserk, and end that turn with 15 Morale. This also makes them likely to Panic/Berserk the next turn, as well. (Mind Control - the gift that keeps on giving!)
* Pain killer administered from a [[Medi-Kit]] - can restore Morale equal to the amount of [[Health]] a soldier has lost

== Effect of Bravery ==
The '''base''' morale a unit loses when a comrade dies is dependent on the surviving unit's [[Bravery]] as follows ((110-Bravery)/5):
<table {{StdCenterTable}} class="sortable">
<tr {{StdDescTable_Heading}}><th width="100">Bravery</th><th width="130">Morale Loss</th>
<tr><td>0<sup>1</sup></td><td>22</td></tr>
<tr><td>10</td><td>20</td></tr>
<tr><td>20</td><td>18</td></tr>
<tr><td>30</td><td>16</td></tr>
<tr><td>40</td><td>14</td></tr>
<tr><td>50</td><td>12</td></tr>
<tr><td>60</td><td>10</td></tr>
<tr><td>70</td><td>8</td></tr>
<tr><td>80</td><td>6</td></tr>
<tr><td>90</td><td>4</td></tr>
<tr><td>100</td><td>2</td></tr>
<tr><td>110<sup>2</sup></td><td>0</td></tr>
</table>
<sup>1</sup> A soldier having a bravery of 0 is impossible, except when editing game files.<br />
<sup>2</sup> Only tanks and certain aliens can have a Bravery of 110.

== Officers ==
Having officer on a mission helps in two ways -- they reduce morale loss from negative events, and increase Morale gained from positive events. Your highest-ranking (surviving) officer's Morale modifier is always used -- so if a Colonel is killed, and the next-highest-ranking soldier in the squad is a Sergeant, morale loss from the Colonel's death will still be reduced by 10%.

However, losing an officer produces higher than usual Morale losses, as shown in the table below below. Losing rookies, squaddies and tanks cause normal amounts of lost Morale.

Leadership Death morale
bonus loss
Tank, Rookie, or Squaddie 0% x1.0
Sergeant 10% x1.2
Captain 15% x1.3
Colonel 25% x1.5
Commander 50% x1.75

Morale loss on personnel death equals:
Base morale loss x (100% - Leadership bonus) = adjusted morale loss (drop fractions)
Adjusted morale loss x Rank modifier = final morale loss (drop fractions)

Since the loss of a Colonel produces Morale loss 1.5 times that of a normal unit, the effective Morale lost in the above scenario will be 1.5 (for the Colonel's death) * 0.9 (for the surviving Sergeant's modifier), for a modified Morale penalty of 1.35 times normal.

The actual numbers for the death of a Rookie / Squaddie dependent on the highest ranking officer in the squad are

{| class="wikitable" cellpadding=3
|-
! Bravery !! None !! Sgt !! Cpt !! Col !! Cmd
|-
| 10 / FF || 20 || 18 || 17 || 16 || 13
|-
| 20 || 18 || 16 || 15 || 14 || 12
|-
| 30 || 16 || 14 || 13 || 12 || 10
|-
| 40 || 14 || 12 || 12 || 11 || 9
|-
| 50 || 12 || 10 || 10 || 9 || 8
|-
| 60 || 10 || 9 || 8 || 8 || 6
|-
| 70 || 8 || 7 || 6 || 6 || 5
|-
| 80 || 6 || 5 || 5 || 4 || 4
|-
| 90 || 4 || 3 || 3 || 3 || 2
|-
| 100 || 2 || 1 || 1 || 1 || 1
|}

If the death has been a "friendly fire" incident, then the killer gets an additional penalty equal to that of a soldier with minimum bravery.

To illustrate, consider the following tragic event: While performing weapon cleaning duty during a ceasefire in an otherwise successful battle, under the not so watchful supervision of their commanding captain, not one but three(!) xcom-troopers (bravery 40) - to the horrors of their watching comrades (bravery 10) - each happend to accidentally shoot a bystanding rookie. The squad was completely demoralized, the shooters (morale 100-17-3*13 = 44) understandably more so than the rest of the squad (morale 100-3*17 = 49). They lasted about 8 turns (1/12% = 8.33) while the others resisted for an average of 50 turns (1/2% = 50) before finally succumbing to panic. At the funeral, the captain hit the right tone when stating that "... while their death is a tragedy, their courrage will live on in us." And indeed, after this encouraging speech, most of the squad (88.765%) and even the shooters (50.328%) felt better (+10 bravery) than before.

=== Officer Tactics ===
* Losing an officer (higher rank) has a greater effect on the whole squad's morale than losing a rookie. LZ's are notorious for ambushes and extreme risk. So logically, your highest-ranking soldiers should never be in the front line of deployment.

* By using [[XcomUtil]], you can choose to place you your officers in the rear of the transport, and your rookies in the front.

* Some people extend this tactic and keep the commanding officer in the Skyranger for the entire battle. They're safest there, and with a Blaster Launcher or Mind Probe they can still contribute to the combat. See [[Rear Commander]] for more details.

* Aliens are subject to the same Morale rules as X-COM units. Targeting alien officers first (eg. with a [[Blaster Bomb]] to the UFO bridge) will help create widespread panic among the remaining aliens.

== Panicking and Berserking ==
If a unit's Morale drops below 50, there is a chance that it will [[panic]] or go [[berserk]] before the next turn.

'''Formula:'''

% Panic Chance = 100 - (2 x Morale)

'''Examples:'''

If a soldier has a Morale rating of 40, they have a 20% chance of panicking on the next turn.

Morale of 0 guarantees a panic or berserk.

If a unit has less then 50 Morale on a given turn but does ''not'' panic, they will gain
[[#Morale Loss and Bravery Increases|bravery experience]] instead.

There are three types of "Panic"; a freeze, a flee, and a Berserk, with an theoretically equal chance (33%) of any one of these being triggered. The first two may or may not cause the unit to drop weapons held in the hand slots, while the third causes them to fire wildly (often at a specific unit standing nearby, which you'd best hope to be hostile!). A fleeing unit may run to a location up to 15 tiles to the south and/or up to 15 tiles to the east, never north and/or west.

After a unit has performed a panic action, it will gain 15 morale points, but have no [[TU]]s until its next turn (making it quite vulnerable).

Note: Berserk soldiers temporarily get 255 TUs or slightly under that. This has been observed in the DOS and CE versions as well as TFTD -- however it's not entirely clear if this happens for the Playstation or Amiga versions. Firing costs are still based on the affected unit's max TUs, even if current TUs are well beyond that. In effect this allows a berserk unit to fire more rounds in a turn than is normally possible.

== Aliens Panicking and Berserking ==

The effects of aliens getting into a state of panic or going berserk are similar to the player's side but with a small difference in when it occurs.

For the player's side, the panic/berserk effects kick in just before the start of the turn. For the aliens side, the effects appear to occur during the turn as each unit is taken control of by the AI.

When an alien panics/berserks, the player is usually not informed of this. The player however may find unarmed aliens wandering about or the odd gun lying on the ground. Mysterious gunshot noises that don't appear to be aimed at your side or civilians (if present) are a good indication that one of the aliens has just gone berserk.

On more severe panic/berserk attacks, the player will get a dialog box informing that the alien has panicked or gone berserk. Unless you're using psionics, this is a fairly good indicator that the majority of the alien's squad has been killed, because the cumulative killing of aliens is what will cause their morale to drop sufficiently for a panic to occur.

Additional side benefits that accompany the dialog box would be the revelation of the panicking unit's rank, as well as a hint of where the panicking may be located by having the camera briefly centering on it. This may even reveal other aliens in the panicking aliens' immediate area if the fog of war has been lifted previously.

== Psionic Panicking Attacks ==
There are two kinds of [[psionic]] attacks aliens and Psi-trained soldiers can use: ''Control Unit'' and ''Panic Unit''. ''Panic Unit'' attacks are more likely to succeed. A successful psionic panicking attack immediately subtracts:
110 - [[Bravery]]
points from the target's Morale score. Thus if the target is a towering hero (100 Bravery) only 10 Morale is subtracted; if the target is a cowering worm (10 Bravery, the minimum possible), 100 Morale is subtracted. For alien Bravery stats, see [[Alien Stats]].

Repeated attacks may be needed to bring a unit's Morale below 50, where it has a chance of panicking.

== Morale Loss and Bravery Increases ==
When a unit's Morale is below 50 but it ''does not'' panic or go berserk, it gains "bravery training". Each successfully-resisted panic roll gives the unit an additional ~9% chance of gaining +10 Bravery at the end of the mission, up to a 100% chance after 11 successful resists. See [[Bravery]] for more details.

==See Also==
* [[Panic]]
* [[Berserk]]
{{Unit Stats Navbar}}
[[Category:Soldiers]]
[[Category:Enemy Unknown/UFO Defense]]

Talk:Heavy Cannon

2021-05-28T21:42:21Z

Mugwump:

To be frank, [[User:Bobucles|Bobucles]], I think you're overselling the HC-HE. It's not in fact true that "most aliens have softer underside armour". That's only true (true enough to matter, anyway) for Mutons, non-Leader Snakemen, Reapers and Silacoids (Sectoids are on average 1 point weaker on their underside, less than the difference in damage ratings, and Sectopods have a marked weakness on their underside but due to resistances and damage ranges are immune to the HC-HE and only almost-immune to the HC-AP). Ethereals have identical under armour to the rest of their plates, as do Chryssalids, Celatids, and Cyberdiscs; most Floaters actually have more under armour (Cyberdiscs are large units, but damage ranges and resistances mean they still take more from AP, at 17.1 vs. 3.1 average damage). The main advantages of HE are in the ability to turn near misses into glancing hits and in killing very tight groups of weak aliens (I'm thinking here about Abductors and their infamous kill rooms; basically nowhere else (except in a Medium Scout, where there are immense drawbacks to using HE) are aliens clustered close enough for the HC-HE to be worthwhile), with specialised advantages being the higher kill rate on Sectoids (89% vs. 70%) thanks to the narrower damage range, and obviously the stupid amounts of damage to Reapers (though Reapers are not exactly high-priority targets). The idea about higher minimum damage reducing accuracy of reaction fire is okay in theory, but in practice when you're shooting at aliens you're usually either sniping from beyond visual range (in which case reaction fire can't happen anyway) or you're up close and personal (which means that their accuracy is less relevant, and also means that in the timeframe you're going to be using Heavy Cannons (i.e. January) using HE at that close range is going to wound or kill your own soldier as well as the alien).

Anyone else want to weigh in on this before I tone down the praise? [[User:Magic9mushroom|Magic9mushroom]] ([[User talk:Magic9mushroom|talk]]) 01:40, 9 May 2015 (EDT)
:There's something important missing from this page, IMHO, which is the utility of HC-HE to clear obstacles (walls, vegetation, etc.) and give line of fire to other soldiers carrying pistols/rifles/etc. HC-HE may not be a must have weapons for terrains clear of those obstacles and inside UFOs but in Terror Sites and Farm missions they can be very useful. I'm a major fan of HC-HE for this reason and I always bring 1-2 of them for every mission, the clustered aliens argument isn't too relevant due to the HC-HE's lower blast radius. But after you get laser/plasma they become obsolete when dealing with Mutons and Ethereals. [[User:Hobbes|Hobbes]] ([[User talk:Hobbes|talk]]) 21:56, 9 May 2015 (EDT)

::It's no Gas Cannon, but it's a pretty decent weapon. As for the issue at hand - I think I see the keys points that are trying to be conveyed in the text, but I also see the generalisation that's causing all the fuss. Easily fixed. However I think the point on reducing reaction fire is quite incorrect. Its the accuracy that gets hurt, not the ability to react. [[User:NKF|NKF]] ([[User talk:NKF|talk]]) 03:50, 11 May 2015 (EDT)

Talk:Hiring/firing

2021-05-27T18:53:19Z

Mugwump:

Talk:Hiring/firing

2021-05-27T18:52:48Z

Mugwump:

I just ran into that problem, Spike - thanks for the tip on the Stingray! ---[[User:MikeTheRed|MikeTheRed]] 22:09, 3 June 2006 (PDT)

----

And on a completely unrelated but otherwise interesting note, transfer of a troop transport.

Transferring a troop transpot will transfar all the equipment in it as well as all the soldiers assigned to it to the next base at the simple cost of the troop tranport's transfer cost (not much of a point with soldiers, as they cost $0 to transfer, but good for the weapons).

You must have enough beds available at the destination in order to transfer the troop transport and all its crew.

It's nothing terribly special and is only a real benefit from a logistic point of view. You get to cart your favourite teams all around the world and not have to transfer them one at a time - clogging up the transfer table. Not that most of us will use up the transfer table...

Still a minor tidbit worth knowing.

- [[User:NKF|NKF]]

----

Everything in the transport thus only needs one line item out of the 100-item transfer queue? That's good to know if you're doing high volume recruit screening! Heck it can even be a way to get "around" it... a "Tip" to transfer equipment in a transport. Thanks for pointing that out!

---[[User:MikeTheRed|MikeTheRed]] 04:10, 5 June 2006 (PDT)

When you recruit staff, if the month ends before the personnel arrive do you pay their salary? Or only personnel already in your base ready to use?
---- [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:52, 27 May 2021 (UTC)

Talk:Damage Modifiers

2021-05-27T18:42:20Z

Mugwump:

Is the bug affecting modifiers for Personal Armor confirmed? If so, why is it not in the "Known Bugs" list? [[User:Mugwump|Mugwump]] ([[User talk:Mugwump|talk]]) 18:42, 27 May 2021 (UTC)

Talk:Damage Modifiers

2021-05-27T18:42:05Z

Mugwump: Created page with "Is the bug affecting modifiers for Personal Armor confirmed? If so, why is it not in the "Known Bugs" list?"

Is the bug affecting modifiers for Personal Armor confirmed? If so, why is it not in the "Known Bugs" list?

Talk:Heavy Cannon

2021-05-27T18:39:59Z

Mugwump:

Talk:Stun Rod

2021-05-27T16:51:21Z

Mugwump: /* Attack above or below? */

I have a question: this page says the stun rod is a 2-handed weapon. Normally using a two-handed weapon with one hand results in an accuracy penalty (-20% if I remember). Since I tend to use low-quality soldiers to try and stun aliens early in the game, I am thinking it would be wise to always try and use stun rods two-handed, to avoid the accuracy penalty. Am I right in looking at it this way?

Also, I see a few weapons with their "handedness" listed (mostly if they're two-handed) but most weapons entries don't mention if they're one or two-handed (Small Launcher, for example). This would be a good thing to accurately list for every weapon.

I'm also thinking there could be a separate wiki page for explaining "handedness", the importance of it, thoughts on the tradeoffs, etc. For example, I think the accuracy of the Blaster Bomb is 120% but it is considered a two-handed weapon, so my understanding is, you can put a second item in the other hand with no practical penalty.

- [[User:Erik|Erik]]

--------

I don't think I've ever seen the stun rod miss. This is probably because you have to use it at point blank range - The only way you could fail to hit the target is if your unit actually turned away when you told him to use it. I've only ever seen a weapon misfire that badly once, so I don't think it's much of a risk.

Someone did some tests with the Blaster Launcher a little while ago, and it seems to be as accurate whether you're holding another weapon or not. My personal theory is that the accuracy only effects the initial launching of the weapon, and once it starts following waypoints it's effects are lost.

- [[User:Bomb_Bloke|Bomb Bloke]]

: I just fell victim to a nasty bug. During a base assault, I hit a Floater about 30 TIMES with the stun rod, yet it didn't deal any stun damage! I even tried attacking from the front instead of behind, still no effect! What's going on?--[[User:Amitakartok|amitakartok]] 10:18, 26 October 2009 (EDT)

Either your [[OBDATA.DAT]] file is messed up (unlikely) or you've hit the max number of items possible in a mission (170 items on the battlescape at a time found in the [[OBPOS.DAT]] file). When this happens, you can't create anymore items (such as corpses or stunned aliens) until some items are destroyed. --[[User:Zombie|Zombie]] 14:15, 26 October 2009 (EDT)

----

That someone was me, and Firing Accuracy (high or low) didn't seem to seem to affect any part of the bomb's flight path -- through the first waypoint, or otherwise. It ''might'' have an effect on reaction fire with a Blaster Launcher.

I've never tested to see if a Stun Rod could miss. Sometimes it fails to knock out an alien, but I always assumed that was because it did low damage. I guess we could try hacking its accuracy (and a soldier's melee accuracy) to see if it can miss.

--[[User:Ethereal Cereal|Ethereal Cereal]] 20:16, 2 July 2006 (PDT)

----

Regarding the stun rod, if the game were to use your hidden melee accuracy stat to calculate melee hit accuracy, then the grip would certainly matter. The game appears to have hard coded the melee accuracy to always hit adjacent targets. Whether or not you do any damage is up to the random number generator and the target's defence. So it's okay to use the stun rod with another weapon in the other hand. It's still a two handed weapon, but because accuracy does not matter, it works just as well.

Just an interesting note. The firing cost for the blaster launcher is in actual fact 66%. Not 80% as it is reported in the ufopaedia. The launch command is actually separate from the normal firing modes that we're accustomed to. I'm guessing the accuracy is in the same boat as melee accuracy. It is perhaps a fixed value that works independantly of your soldier's accuracy, so accuracy doesn't matter. Has anyone ever tried it with a 0 accuracy unit, such as what can be found on a mind controlled chryssalid? If you haven't, do give it a try and make what you will of it. Use the inventory trick or the mind controlled zombie trick to get one.

- [[User:NKF|NKF]]

----

I've just got two observations about the stun rod to add.

The first is that I've never ever experienced an alien firing a reaction shot when hit with a stun rod, even when hit from the front. I also think nearby aliens will not reaction fire either.

The second is that if the stun rod does do 65 (stun) damage it seems to take far too many hits to take down any alien. I might try an experiment sometime where I take a skyranger full of flying suit vets with psi amps, mind probes and stun rods to test out exactly how much damage they actually do. If so I will report the results here.

--[[User:Hot Logic|Hot Logic]] 21:11, 7 November 2006 (PST)

----

It has been pointed out in a brief exchange in the article that while the attacks don't trigger the reaction shots, any other action that you do perform that [[reaction fire triggers|triggers]] a reaction shot will cause a reaction shot. Good to know, I guess. So the trick is to keep still if your attempt has failed, and try and get someone else to pull you out of the fire.

As for the damage, don't forget that stun damage is also subject to the random number generator and unit armour. So you will not always be dealing 65 damage. I don't recall if the range of damage from the stun rod is doubled like it is for projectile launched stun damage. Anyway, refer to [[damage]]. Come to think of it, melee damage isn't that heavily covered in that section. Oh well.

- [[User:NKF|NKF]]

== Reaction attack with a Stun Rod? ==

An unusual turn of phrase in the Reaction Fire article ("attacks of opportunity" - why not just "opportunity fire" unless it includes melee?) got me thinking about whether a unit can react with a Stun Rod or with any melee attack? Hard to test so I thought I would ask first. Do Reapers or other melee-only aliens react with their attacks?

(Just for fun I have begun a game using non lethal weapons only, to see if reaction use of a stun rod ever happens. My guys have stun rods and smoke grenades, HE packs for breaching & to clear obstacles, and a tank to hide behind. The tank is not allowed to fire its cannon except to open passages through terrain, and it has to use up its TUs so that it never reaction-fires.)

[[User:Spike|Spike]] 20:07, 21 March 2008 (PDT)

:I have never witnessed reaction fire with any melee attack; I have stood tanks next to various melee aliens and shot at them and never been struck back. So I personally doubt that any melee attack can be used in reaction fire. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:43, 21 March 2008 (PDT)

Seen plenty of opportunities for a "reactive" melee attack, never actually seen one made. It's commonly assumed that they don't happen, NKF or Zombie have very likely done trials on the matter already.

Wouldn't be that hard to test though. Just bung a soldier right next to a Chrys, max out the aliens' reaction/TU stats, and have your man wander around.

Then create a 3x3 room, stick your man in the center with a stun rod and likewise maxed stats, and leave an unarmed muton or something in there with him.

- [[User:Bomb Bloke|Bomb Bloke]] 04:14, 22 March 2008 (PDT)

: If there was code that controlled melee attacks in reaction attacks, we would've seen evidence of it by now with the melee aliens and with your own units armed with a melee weapon (particularly if you've been playing TFTD with its drills). Reaction attacks seem to be an automatic action that all off-turn units can perform if all the conditions are met. Notice how (armed) civilians can use reaction fire, but aren't able to manually shoot at you on their own turn.

: The phrase attack of opportunity, if I'm not mistaken, was either taken or derived from one of the game manuals. -[[User:NKF|NKF]] 07:23, 22 March 2008 (PDT)

Yes it's as much the odd phrase I'm wondering about. The phrase "attack of opportunity" is not in the official X-COM Ufo Defense manual - that manual uses the phrase Opportunity Fire and has a section with that title. Opportunity Fire is also the phrase used in the various GDW games that X-COM is derived from.

I wonder what happens if a unit has a melee weapon as its active weapon and a fire weapon in the other hand. Would it take a reaction shot using the alternate weapon? And presumably no unit will ever reaction-fire with a thrown weapon such as a grenade? Hmm maybe this should move to the Reaction Fire section. [[User:Spike|Spike]] 10:00, 22 March 2008 (PDT)

:No unit will never reaction fire with a thrown weapon(in order to do so, you'd need a good number of TUs, or need to have primed the grenade ahead of time!) In either case, the designers decided(wisely, IMO) that grenades are something that should be used only at player discretion. I've had troops killed by a missed reaction shot...with grenades, you lose your squad, not one man.

:Regarding your second issue...A unit will only switch its reaction fire from one weapon to another after the first weapon runs out of ammo. The Stun Rod has infinite ammo, so it will always pass the "Ammo left?" check. Thus, any unit with a stun rod as the active weapon will never take a reaction shot, even if they're holding a gun in the other hand! [[User:Arrow Quivershaft|Arrow Quivershaft]] 11:42, 22 March 2008 (PDT)

Talk:Base Defence Systems

2021-05-25T17:43:49Z

Mugwump: /* Monthly Score */ new section

Talk:Stun Rod

2021-05-25T17:07:52Z

Mugwump: /* Attack above or below? */

Talk:Stun Rod

2021-05-25T17:07:25Z

Mugwump:

Talk:Stun Rod

2021-05-25T17:05:52Z

Mugwump: /* Attack above or below? */

Talk:Stun Rod

2021-05-25T16:56:48Z

Mugwump: /* Attack above or below? */ new section

Talk:High Explosive

2021-05-24T23:43:55Z

Mugwump:

== Blowing Through Interior Walls ==

How good are (unmodified) High Explosives for blowing through interior walls of alien ships? I see the damage is 110, and that would seem to be enough, compared to other weapons that can blast through interior walls... I'm just wondering if it's a widely used tactic early in the game, prior to better explosives becoming available.

[[User:Eric|Eric]] 17:37, 27 July 2006 (PDT)

----
High Explosives aren't any good for that. 110 normal damage, sure, but against terrain explosives do half damage. 55 isn't even close. I think the Hovertank's Fusion Bomb is enough to poke through inner walls though. --[[User:Zombie|Zombie]] 08:59, 28 July 2006 (PDT)

----

HE (object damage 55) can only take out Navigation consoles (damage 50) -- so in effect, there is only one UFO inner wall that it can destroy: the center-western tile of an [[Abductor]]'s bridge. HWP Fusion can destroy those, flashing walls, and the green computer panel-walls found in a number of places. See [[Destroying_Terrain#UFO_structures]].

--[[User:Ethereal Cereal|Ethereal Cereal]] 10:01, 29 July 2006 (PDT)

== HE Pack - realistic equivalents, tactics, suggested changes ==

I use XcomUtil to play with, which I generally like, as it usually either makes things harder, or at least more realistic, or both (the notable exception being the high performance air superiority fighters that have spare luggage space for 6 heavily armed commandos or a small tank). However I'm getting unhappy with the excessive effectiveness of XcomUtil's version of High Explosive and the tactical difference this makes.

It does seem logical that human explosives could perforate an alien hull. After all, every crashed UFO can be (and probably has been) brought down with conventional explosive warheads as found in a cannon shell, or a Stingray or Avalanche missile warhead (realistic 1999 equivalents - Vulcan, Sidewinder/Sparrow, Phoenix). It's feasible that something similar to the <u>warheads</u> of these aircraft weapons could be man-carried and used in the field with some degree of success.

Also, XcomUtil writer Scott Jones had a good point that you shouldn't put an item in a game if it is useless, it spoils the game and reduces the number of options. So it was good to rehabilitate the HE pack and raise its HE damage power to 200 so that it can be effectively used to breach UFO walls. However after playing this tactically for a day or so I have some fairly random observations:

1. Maybe reduce the HE power a bit, so that the probability of breaching the hull is lower. It seems to work nearly every time. One in two or one in three might be better, to put some risk and uncertainty into the operation. Not sure what that would mean for the HE power. 170 or so? Also that would mean Blaster Bomb rounds are still supreme, which they ought to be.

2. A tactic I've been using is to rip a hole next to the UFO door and then drive into the UFO with a tank. It makes prisoner captures much easier as the aliens focus their fire on the tank. Your guys then swarm in with stun rods - especially if multiple breaches allow you to enter on flanks as well. One tank-sized hole and another personnel-sized hole at 90 degrees to it make short work of any resistance. I found it impossible to make 2 simulaneous adjacent breaches, maybe one charge destroys the other before it detonates properly (not unrealistic). So the tanks have to use the front door - they just widen it a bit. But still this is all getting a bit too easy. Part of the problem is that I'm using XcomUtil tanks and I think Scott Jones has made them a bit <b>too</b> tough. He gives them the same hull strength as the hovertanks have (but hovertanks are Alien Alloy-based). HWPs should be light armoured recon vehicles with fire support, not proper main battle tanks vs the aliens.

3. The really dumb and unrealistic usage of HE packs is <u>throwing</u> them to the impact point. Since the pack only weighs twice the weight of a grenade, you can throw it half as far - a strong soldier can easily throw it further than its blast radius. So there is even the need for judging the timer delay to ensure a safe getaway, with the tactical uncertainty that brings. For game balance, and for realism, you should have to place it carefully against the door. It certainly should only work when in direct contact with the wall (I think that is the case actually). As far as 'realistic' equivalents go, a serious demolition pack is not twice the weight of a grenade and can't be thrown. The Realistic Equivalents section lists a 20lb C4 satchel charge. Something only twice as big as a grenade, say a kilo or so, would just be a 'large HE grenade' for blowing up huts and hovels, nothing that would touch alien hulls. I'm thinking something 20lbs or bigger with a shaped charge warhead that must be set in place. At the very least something like 2-3 TOW anti-tank missile warheads lashed together. No way could you throw that, and if you did throw it two or three squares, if it still exploded at all, it definitely would not breach anything - it would just make a big messy bang. Proper placement is essential (and a skill). The radius HE effect of the HE pack should be seen as an unavoidable side effect of an even more powerful directional shaped charge, purposely designed for armour-breaching.

Anyway I would vote for increasing the weight of the HE charge way up, to maybe 12-18. If we could re-engineer the game I would say that throwing the HE pack automatically disarms it. The pack must be armed and <u>placed</u> directly on the breach area. For now I will just play that as a house rule I guess.

In summary - reduce the HE power a bit, increase the weight a lot, pass them around but don't throw them onto the detonation point, and by the way make the XcomUtil tanks a bit less strong. That's some more work for me to do on the game files then!

Or conversely, keep the same weight and ability to throw, but reduce the HE power down to something like a small rocket warhead, 75 or so. So that in effect it the realistic equivalent becomes a 'heavy grenade'.

[[User:Spike|Spike]] 15:27, 24 March 2008 (PDT)

:In regards to your issues...

:1: Explosives always do half their damage rating listed in the UFOpaedia to terrain objects at Ground Zero. If an explosive is set any lower than 200 damage, the chance of breaching a UFO hull immediately drops to 0%.

:2: Explosives in UFO Defense do destroy each other, yes(TFTD makes explosives invlunerable). Also, yes the main tanks are too tough, but in the early stages of the game, I always found four soldiers better than one tank.

:3: We have no way of determining that 6 weight units are twice as much as 3 weight units; I'd in fact argue against this being true, since a standard human being certainly weighs a LOT more than 7 grenades!(A dead soldier in a Jumpsuit weighs 22 weight units, which is a bit more than 7 grenades. Adding personal armor adds 2 weight units to 24, 8 grenades, and a Power of Flying Suit increases it to 26, a bit less than 9 grenades.) A better way of measuring weight might be encumbrance, or the balance. Grenades and explosives tend to be balanced, whereas humans and larger weapons tend to be heavier in some areas than in others.

:Other than that, increasing the weight of the HE pack is a trivial edit which can be done with any Hex Editing program. Open [[OBDATA.DAT]] in such and change the 'weight' field to the desired number. (It's the 43rd offset for the item.) If you can't do it yourself, drop me a line in email(there's a link on my talk page) with the changes you want to the normal XComUtil stats, and I'll do it for you and send you the file. Just remember how much a human weighs for comparison! [[User:Arrow Quivershaft|Arrow Quivershaft]] 16:16, 24 March 2008 (PDT)

----

A few thoughts of my own. I myself am quite happy the way it is. It doesn't need to be stronger or weaker. It doesn't have to be able to breach UFO walls - that's what makes BBs so special (and what makes spending the elerium worth it - assuming situations where you have to to construct the BBs). As is, the HE packs are still a good bang for the amount of resources you spend on them. But that's just how I see it.

The only reason the HE pack is twice as heavy other grenades is because the other grenades are of weight 3 while the HE pack is weight 6. Effectively doubling its weight and halving the throwing distance. But how much weight it is in realistic terms - now that's where you can argue to you heart's content. The game measures item weight in strength units, not in kg's or pounds.

It's reasonably heavy as it is. A brand new soldier's not going to be lobbing the thing about with ease unless getting one of the higher end starting strength levels. Even then it's not going to be a very far toss.

I also don't think it looks as big as the inventory image depicts it to be. Again, compare the size of bodies. I'm imagining something the size of a small box with a coke tin on its side myself.

There is also a serious flaw with setting charges: messed up experience attribution. Until the object is thrown, the game automatically assumes that unit 0 (if I'm not mistaken, unitpos.dat index numbering) owns the item - i.e. the guy on the equipment pile, or the first HWP on the ship.

So you'll have to either throw the explosive at the ground and pick it up several turns before you set the charge, or throw it at the spot. Alternately, exploit the bug in a short grenade relay before setting the charge to give the experience (if any) to the second to last person in the chain. .

- [[User:NKF|NKF]] 22:06, 24 March 2008 (PDT)

----
Well that gives me plenty to think about. Good point about real weight not being linear with in-game Weight, which does sound more like an 'encumbrance value'. Unfortunately throwing distance <b>is</b> linear with Weight.

Also it's fair to say that regular HE packs can be quite useful as they are, which takes away another argument for changing them. Shame that the results of the explosion can't be random. Oh well.

Thanks for the tip on OBDATA.dat, I will try that.
For the improved (damage=200) HE packs; I will probably take the weight up to about 16, so they are hard to throw and similar to a heavy weapon. Given their 100% effectiveness in breaching a UFO hull, I think that's balanced.

Or maybe I'll just go back to plain vanilla HE packs and quit worrying. :)

[[User:Spike|Spike]] 10:29, 25 March 2008 (PDT)

:I always love to toss HE Packs in through the holes in the roofs of Medium and Large Scouts that I've shot down. I don't even need to go inside; they're all killed that way. Even easier if you have Flying Suits available. [[User:Arrow Quivershaft|Arrow Quivershaft]] 10:39, 25 March 2008 (PDT)

== Blowing Through Exterior UFO in european version ==

Anyone know truth to the rumor I've seen that in the original, UFO: Enemy Unknown, that the High-explosive pack could punch hole through the external UFO walls? maybe it wasn't that the pack had higher damage value, but that the exterior walls were just weak enough.

That could be an interesting mod. I am interested to use High-Ex but think it seems pretty broken/OP in the XcomUtil mod

[[User:Mugwump|Mugwump]] 16:41, 24 July 2021 (PST)