UFOpaedia - User contributions [en]

Talk:UNITPOS.DAT

2010-08-22T18:42:47Z

Renegrade: /* Offsets 4-7 */

Just a note:

Bullets fired from large units always go from the primary quarter - i.e. the very first unit in unitpos - or the top-left quarter of the unit (relatively speaking, the top most quarter on your screen).

I think the bullet origin is higher than the unit's hit-box (to mimic firing from a turret) or is at least offset so that it doesn't strike its other quarters.

Until more information is gathered, I don't think the bitflags that flag sometimes for tanks would determine where the bullet is fired from. Sorry, yet another bit to identify... oh well.

[[User:NKF|NKF]] 02:04, 15 Oct 2005 (PDT)

----
I just compared two unitpos.dat files. One was where a Chryssalid was not spotted. The other was after the Chryssalid was spotted. The only difference between the two files was offset 10 (column 11). Unspotted: value of 34 (100010), spotted: value of 35 (100011). Not sure how that fits in the offset 10 description in the article page so I dumped this info here for now. Someone with more knowledge of bytes, hex, dec and bin please look this over and try and incorporate it into the text. -[[User:Zombie|Zombie]] 23:59, 29 September 2006 (PDT)

Unexpected terminology. XCOM units always have the bit with significance 1 (bit 0) set, so equating "spotted" with "visible" makes the article summarize this without changes.
--[[User:Zaimoni|Zaimoni]] 10:23, 1 Oct 2006 (CDT)

:Agreed. The lowest bit is a flag for visible/spotted. I never noticed that that's where it was stored (and not in Unitref) until now... I'll add a little more text to the page so it stands out a little better (for slow folks like me!). Good work with FC, Z. P.S. You can delete all this after reading, if you want. --[[User:MikeTheRed|MikeTheRed]] 10:23, 1 October 2006 (PDT)

----

Comparing end-of-turn saves with the consecutive begin-of-turn saves: in patrol-mode AI with no X-COM units spotted during the turn, '''only''' position bytes are updated during patrol mode AI when no X-COM units are spotted. The other bytes aren't changed simply by expending energy on the next turn, either.

In particular, the visible/spotted bit (significance 1) isn't reset. Not worth updating until whether this bit can reset is inducted properly.

--[[User:Zaimoni|Zaimoni]] 16:21, 1 Oct 2006 (CST)

== Offset 8 ==

Ok I did some comparing of offset 8 in saves. I seem to have confirmed what BB has said only that XCom units are set to 255 at the beginning of combat, and aliens are set to 1. As I placed in the article this seems to be a counter that increases every turn the unit goes unseen ''per se''. Even if you 'sneak' up on an alien facing away from you, both counters will be reset (yours and the aliens). I'm not sure if an alien sneaks up on you if the counters reset or not. (I won't be shown the movement so I can't confirm)

I'm about 90% sure that even if a soldier cannot 'see' the other alien (out of sight range), but fires and hits the alien, including with AoE that soldier's counter is reset.

Now for my theory: 
I think this has to do with the ''intellegence'' value in [[UNITREF.DAT]] offset 73. If this counter is greater than the value at offset 73, then they will not know where the unit is. Hence why all human soldiers have 'intelligence' set to 0, else you would know the location of aliens after they have moved out of your sight, and why their counters are set to 255 at first otherwise the aliens would know where you were to begin with.

Also, I think I might have noticed the AI run a bit faster once my soldiers were above their 'intelligence' value, the turns ran much faster when some of my soldiers hit the 6-8 mark. Thus maybe the AI only processes soldiers that fit this condition.

I remember reading somewhere about the aliens knowing where you are from the start, but I can't remember the details.
[[User:Pi Masta|Pi Masta]] 20:26, 14 February 2007 (PST)

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

I'm pretty sure you're right; I never tested to see what this value did over time, I just noticed it reset when you spotted something. I never twigged that it'd be to do with the intellegence byte as I only noticed it change when I spotted aliens (as opposed to when they spotted ME!).

The rumor goes that if the aliens know where one of your units is, they know where ALL of them are until they "forget". This has to be that counter byte. The only question I have is when it increments (when you have your turn, when the aliens have theirs, or both).

I suspect the byte is somewhat redundant in the case of aliens, as a seperate "visibility" flag (see offset 10) is used so you can keep track of enemies. Still, it might be interesting to boost one of your own units intellegence somewhat and see what happens.

- [[User:Bomb Bloke|Bomb Bloke]] 03:15, 25 April 2007 (PDT)

== Offsets 4-7 ==

Looks like it's a raw memory pointer to unitref data. For big units, the 4 parts seems to points to the same data.

- [[User:Seb76|Seb76]]

------

O_O

You've gotta be right; the values increment by 124 (the UnitRef record size).

(Could you please sign your Talk comments? Just stick in four consecutive tildes (~), the Wiki'll convert that to the time/date/username info).

- [[User:Bomb Bloke|Bomb Bloke]] 20:01, 9 February 2008 (PST)

----

Is this the only reference tying UNITPOS and UNITREF together, aside from the position on disk/in memory? I'm guessing after the file is reloaded, they step through UNITREF, and use something there to determine whether or not there are 1 or 4 UNITPOS records associated and update this pointer correctly. But then how are UNITPOS records updated while the game runs? They must either have some internal memory-only linkage that isn't saved, or are always updating/using UNITREF from the state of UNITPOS? Having to search every UNITPOS's pointer to find the UNITPOS from the UNITREF record's side would be rather expensive if it has to be repeated :S

An additional thought occurred to me: there's 80 of these, and 80 of UNITREF, yet there could be as many as 320 UNITPOS records for a set of 80 large units in UNITREF. Could the crashes relating to overstuffed base defense missions have something to do with there being too many UNITPOS entries for the UNITPOS array? Perhaps in XCOM's early stages, UNITPOS and UNITREF were 1:1 and large units were added later?

~ [[User:Renegrade|Renegrade]] 12:02, 22 August 2010 (EDT)

Talk:UNITPOS.DAT

2010-08-22T16:02:16Z

Renegrade: /* Offsets 4-7 */

Just a note:

Bullets fired from large units always go from the primary quarter - i.e. the very first unit in unitpos - or the top-left quarter of the unit (relatively speaking, the top most quarter on your screen).

I think the bullet origin is higher than the unit's hit-box (to mimic firing from a turret) or is at least offset so that it doesn't strike its other quarters.

Until more information is gathered, I don't think the bitflags that flag sometimes for tanks would determine where the bullet is fired from. Sorry, yet another bit to identify... oh well.

[[User:NKF|NKF]] 02:04, 15 Oct 2005 (PDT)

----
I just compared two unitpos.dat files. One was where a Chryssalid was not spotted. The other was after the Chryssalid was spotted. The only difference between the two files was offset 10 (column 11). Unspotted: value of 34 (100010), spotted: value of 35 (100011). Not sure how that fits in the offset 10 description in the article page so I dumped this info here for now. Someone with more knowledge of bytes, hex, dec and bin please look this over and try and incorporate it into the text. -[[User:Zombie|Zombie]] 23:59, 29 September 2006 (PDT)

Unexpected terminology. XCOM units always have the bit with significance 1 (bit 0) set, so equating "spotted" with "visible" makes the article summarize this without changes.
--[[User:Zaimoni|Zaimoni]] 10:23, 1 Oct 2006 (CDT)

:Agreed. The lowest bit is a flag for visible/spotted. I never noticed that that's where it was stored (and not in Unitref) until now... I'll add a little more text to the page so it stands out a little better (for slow folks like me!). Good work with FC, Z. P.S. You can delete all this after reading, if you want. --[[User:MikeTheRed|MikeTheRed]] 10:23, 1 October 2006 (PDT)

----

Comparing end-of-turn saves with the consecutive begin-of-turn saves: in patrol-mode AI with no X-COM units spotted during the turn, '''only''' position bytes are updated during patrol mode AI when no X-COM units are spotted. The other bytes aren't changed simply by expending energy on the next turn, either.

In particular, the visible/spotted bit (significance 1) isn't reset. Not worth updating until whether this bit can reset is inducted properly.

--[[User:Zaimoni|Zaimoni]] 16:21, 1 Oct 2006 (CST)

== Offset 8 ==

Ok I did some comparing of offset 8 in saves. I seem to have confirmed what BB has said only that XCom units are set to 255 at the beginning of combat, and aliens are set to 1. As I placed in the article this seems to be a counter that increases every turn the unit goes unseen ''per se''. Even if you 'sneak' up on an alien facing away from you, both counters will be reset (yours and the aliens). I'm not sure if an alien sneaks up on you if the counters reset or not. (I won't be shown the movement so I can't confirm)

I'm about 90% sure that even if a soldier cannot 'see' the other alien (out of sight range), but fires and hits the alien, including with AoE that soldier's counter is reset.

Now for my theory: 
I think this has to do with the ''intellegence'' value in [[UNITREF.DAT]] offset 73. If this counter is greater than the value at offset 73, then they will not know where the unit is. Hence why all human soldiers have 'intelligence' set to 0, else you would know the location of aliens after they have moved out of your sight, and why their counters are set to 255 at first otherwise the aliens would know where you were to begin with.

Also, I think I might have noticed the AI run a bit faster once my soldiers were above their 'intelligence' value, the turns ran much faster when some of my soldiers hit the 6-8 mark. Thus maybe the AI only processes soldiers that fit this condition.

I remember reading somewhere about the aliens knowing where you are from the start, but I can't remember the details.
[[User:Pi Masta|Pi Masta]] 20:26, 14 February 2007 (PST)

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

I'm pretty sure you're right; I never tested to see what this value did over time, I just noticed it reset when you spotted something. I never twigged that it'd be to do with the intellegence byte as I only noticed it change when I spotted aliens (as opposed to when they spotted ME!).

The rumor goes that if the aliens know where one of your units is, they know where ALL of them are until they "forget". This has to be that counter byte. The only question I have is when it increments (when you have your turn, when the aliens have theirs, or both).

I suspect the byte is somewhat redundant in the case of aliens, as a seperate "visibility" flag (see offset 10) is used so you can keep track of enemies. Still, it might be interesting to boost one of your own units intellegence somewhat and see what happens.

- [[User:Bomb Bloke|Bomb Bloke]] 03:15, 25 April 2007 (PDT)

== Offsets 4-7 ==

Looks like it's a raw memory pointer to unitref data. For big units, the 4 parts seems to points to the same data.

- [[User:Seb76|Seb76]]

------

O_O

You've gotta be right; the values increment by 124 (the UnitRef record size).

(Could you please sign your Talk comments? Just stick in four consecutive tildes (~), the Wiki'll convert that to the time/date/username info).

- [[User:Bomb Bloke|Bomb Bloke]] 20:01, 9 February 2008 (PST)

----

Is this the only reference tying UNITPOS and UNITREF together, aside from the position on disk/in memory? I'm guessing after the file is reloaded, they step through UNITREF, and use something there to determine whether or not there are 1 or 4 UNITPOS records associated and update this pointer correctly. But then how are UNITPOS records updated while the game runs? They must either have some internal memory-only linkage that isn't saved, or are always updating/using UNITREF from the state of UNITPOS? Having to search every UNITPOS's pointer to find the UNITPOS from the UNITREF record's side would be rather expensive if it has to be repeated :S

~ [[User:Renegrade|Renegrade]] 12:02, 22 August 2010 (EDT)

Wish List (EU)

2010-08-19T17:30:04Z

Renegrade: /* Game option: sell only researched items */

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

= I Wish... =
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"

== Geoscape and Strategic ==

=== Smarter Aircraft Movement Around Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

=== Smart Interception ===

Aircraft intercepting a UFO just head straight toward the UFOs current position at all times. Unless the UFO is already on a head-on course, this results in the interceptor travelling through a closing parabolic spiral path, and often missing the UFO and ending up in a tail-chase, and then just falling further behind unless the UFO stops or reverses course. This is pretty basic stuff, fighter pilots have known how to do this better for nearly a hundred years. It is particularly important if the aircraft you are trying to intercept is moving faster than you (eg if you are flying an Interceptor).

What is needed is to plot the UFO's current course and speed (which X-Com has from radar data), and plot an intercept course. The maths for this is pretty easy (the intersection of 2 vectors) and can be implemented in a few lines of code, if we can find out where the current interception algorithm is, and patch it.

Actually the radar bearing shown on screen is only accurate to within 45 degrees. I presume that X-Com does actually know the UFO's bearing, since it can clearly track the UFO's movements. Finding where that variable is located might be different.

While we're at it, it would be nice if the UFO detection information displayed the actual bearing in degrees, rather than just the compass direction (North East, South, etc).

Even if the improved intercept algorithm only used a bearing accurate to within 45 degrees, that would still be better for remote UFOs. You might need to switch to "head straight for it" once you get to very close range. [[User:Spike|Spike]]

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
::: A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

:::: Ummm, it seems the best solution (I, for one, can't think of any better), but wouldn't it assume that only the BattleShip really locates the player's base? All those scouts for nothing? [Still the best solution, though] [[User:N|n]] 15:01, 16 August 2010 (GMT+1)

=== All Aircraft Weapons Useful ===

In a balanced game, all weapons should have their uses, or at least a niche, but sadly this is not so:

The Cannon is only useful for shooting down Small Scouts, and even that is practically impossible, due to the difficulty in closing to 10km range with any UFO, particularly the fast-accelerating Small Scout.

The Stingray is not even useful for shooting down Small Scouts (destroys them 57% of the time) and the Avalanche is better in every meaningful way. It also takes twice as long to rearm, making it operationally much worse than the Avalanche.

The Laser Cannon is inferior to the Avalanche for everything. It does have a higher payload but this is hardly relevant. If attacking a UFO that you would struggle to kill with Avalanches, you are unlikely to own an aircraft that will survive long enough to inflict more damage than an Avalanche if it mounted Laser Cannon.

The Fusion Ball Launcher has a [[Talk:Craft_Armaments#Fusion_Balls_better_than_Plasma_Beams.3F¦possible niche]] in fighting Battleships when mounted on Interceptors. Even then, it is difficult and expensive to have aircraft configured to fight only one enemy.

Unfortunately, the optimum path for craft weapon development is all-Avalanche followed by all-Plasma Beam. This is a shame.

Suggestions to 'tune up' the other weapons:

*Cannon - Increase the damage to 20 or 25. So at least there is a pay-off if you manage to get in close.
*Stingray - Double the rearm rate so it can be reloaded as fast as an Avalanche launcher. Increase the ammo capacity to 9 or 12. Then up the rearm rate again (triple or quadruple) so it can still be reloaded as fast as Avalanche. Even then, it's probably not better than the Avalanche, so maybe it make it ''more'' accurate than the Avalanche instead of less. Raise Stingray to 90%, or to 80% but drop Avalanche to 65%.
*Laser Cannon - increase accuracy to 50% and damage to 100. Give it infinite ammunition.
*FBL - increase the ammo from 2 to 3. Increase damage to 250 or even 255. It's far and away the most expensive weapon to operate so it might as well pack the biggest punch.

It might be worth considering 'tune down' the Plasma Beam as well, particularly its stand-off range.
[[User:Spike|Spike]] 06:59, 14 February 2010 (EST)

=== Tougher UFOs ===

==== The Problem ====

So let me get this straight. The first hybrid airborne weapon that humans ever build, and it immediately outclasses every weapon the aliens ever built, including their Battleship weapon? After all the Aliens have only been building plasma weapons for a few million years, us humans have been doing it for ''months''!

More to the point, once you get Plasma Beams, downing UFOs is like shooting fish in a barrel. Even Battleships aren't that exciting if you show up with enough ships.

What is needed is to push up the range, damage, and rate of fire of all the UFO weapons, particularly the UFOs you will be fighting by the time you have plasma beams. At a minimum, the weapon on a Battleship should be at least as powerful as, say, 2 Plasma Beams (as found on the XCom craft it is fighting)? Instead of slightly less than half as powerful? Compared to a single Plasma Beam, only the Battleship weapon has better range. It has double the accuracy, slightly higher damage, but half the fire rate. Net 5.7% more firepower than one Plasma Beam, but no match for 2. And the Battleship weapon of course is the most powerful in the alien arsenal.

Possible tune ups for UFOs:

*Battleship - increase to 255 weapon power, improve reload rate to 12 (from 24). Now roughly equivalent to 4 Plasma Beams in total firepower (on Beginner difficulty). Increase range to 69km, so that the Battleship commences fire as soon as an XCom craft begins its attack run. Or better, increase range to 70+km, the limit of the interception window, so that the Battleship starts firing immediately the XCom craft enters air combat range. This would disrupt XCom aircrafts' ability to form up into a flight of 4, prior to commencing their attack. Overall, this would make it much harder to down Battleships. Increasing weapon range to 70+km would also make it much harder to tail a Battleship - manual control in the Geoscape would be needed to hold off outside of combat range. Really, the Battleship should not sit there like a sitting duck. Does it think XCom are friendly?
*Terror Ship - increase range to 52 (or decrease Plasma Beam range to 42), so stand-off kills are not possible with Plasma Beams?
*Actually maybe all the larger UFOs should have weapon range 69-70+km, so they behave very aggressively toward XCom craft.

NB: Strange effects occur if weapon range goes over 70km so it's probably best to leave it at 70km rather than 75km.

NB: Also, changes to rate of fire need to be looked at carefully though because Difficulty Level also reduces reload rate for UFOs. Between Beginner (Difficulty 0) and Superhuman (Difficulty 4), rate of fire (and thus firepower) for Battleships, Terror Ships and Supply Ships increases by 24/(24-4x2=16) or 50%. But if the base reload rate for these weapons was reduced to 12, the transition from Beginner to Advanced would increase firepower '''three''' times for these 3 UFOs (less so for the smaller UFOs). It is less risky to increase the weapon power. Unfortunately there are only 2 firepower variables to play with - damage and reload rate - so there are not a lot of options, especially for the Battleship which already has weapon strength 148 out of a probable maximum of 255.

:More detail on this. For Medium Scout, Large Scout and Abductor, with nominal reload rate 48gs, the rate of fire improves +20% between Beginner and Superhuman. For Harvester (32gs) it improves one third. For Large UFOs (Terror Ship, Supply Ship, Battleship - 24gs) the improvement is +50%. [[User:Spike|Spike]] 20:28, 14 February 2010 (EST)

I think we should assume that the Battleship, which is bigger than the entire XCom base, is engaging XCom craft with its secondary weapons rather than its main armament, which could probably destroy Manhattan with a glancing hit.

I would really like to see the hypothetical Mega-Battleship go up against XCom's finest - a flight of 4 Avengers armed with dual Plasma Cannon or dual Fusion Ball Launchers. With the Battleship having 70+km range, 255 weapon power, and an effective fire rate on Superhuman triple that of the PB, it would have the firepower of 11 Plasma Beams - 36% more firepower than the whole attacking XCom force combined. To be honest I think that would be carnage, not sure XCom could win. So that would be tuning the Battleship up too much. The 3-fold increase in rate of fire when on Superhuman is just too much. Maybe just max out the damage to 255 and range to 75. This gives a 72% increase in firepower, and a challenging tactical problem for XCom (forming up and approaching under fire).

The smaller UFOs can probably stay as they are. It is not until later in the game that XCom advances so that even large UFOs are easy pickings. What is the crossover point? Maybe the medium UFOs. So it might be good to reduce the reload times of the medium UFOs from 48 / 32 to 24, a good increase in firepower.

In general I think all UFOs energy weapons should have at least as good range as the XCom energy weapons, even the Medium Scout. Again, they have been using these weapons for millions of years and we only just figured out how to copy them from the aliens, how could our weapons be better than the aliens? How did our first plasma weapon out-range and out-perform all but the hugest UFO plasma beam? And on an airframe the size of a Small Scout we mount ''two'' such weapons? On the battlefield we only are able to replicate alien weapons; how is it that in the air we are able to improve on them ''masssively''?

Perhaps there should never be a stand-off advantage, except possibly with missiles -which should be less accurate with longer range. The XCom stand off advantage is really unfair because as far as I have seen the UFOs never attempt to close to effective range, even when they are getting killed. They don't break off much, either, though I think I have seen that happen on occasion.

==== Specific Proposals ====

===== No Standoff Beam Attacks =====

Increase ''all'' UFO plasma weapon ranges to at least 55km (compared to 52km for the XCom plasma weapon). Now only launched XCom weapons (Avalanche and Fusion Ball) have standoff advantage. Probably also reduce the accuracy of the Avalanche to 60% and buff Stingray accuracy to 80%, providing both weapons with a useful niche role.

===== No Standoff Attacks =====

Increase ''all'' UFO plasma weapon ranges to 66km (compared to 52km for the XCom plasma weapon). Now ''no'' XCom weapon has standoff advantage. (The benefit of a longer range weapon is simply spending less time being fired on by the UFO.)

===== Twitchy Aliens =====

Increase all UFO ranges to 69km. They will attack as soon as XCom aircraft commence any attack run.

===== Hostile Aliens =====

Increase all UFO ranges to 70km. They will attack as soon as XCom aircraft enter intercept range. UFOs now fire first, and tailing them unchallenged is impossible.

===== Improved Medium UFOs =====

Reduce (improve) the nominal reload time of Medium UFOs, Abductors and Harvesters, from 48gs and 32gs to 24gs. This increases the challenge in the early-mid game, when XCom might first be deploying advanced weapons.

===== Improved Battleships =====

Increase damage to 255. They're firing (bigger) Fusion Balls! A Battleship now has the same firepower as one XCom Craft with dual Plasma Beams (gosh wow!). It's a start, but what if we...

===== Super Battleships =====

... also reduce nominal reload time to 18gs. Giving a further one-third extra firepower on Beginner, 60% more on Superhuman.

===== Mega Battleships =====

... or for a real challenge, reduce reload time to 12gs. A further doubling of the firepower on Beginner - a further ''four'' times increase on Superhuman. Now Superhuman Battleships out-gun the biggest fleet XCom can throw at them!

[[User:Spike|Spike]] 00:25, 19 February 2010 (EST)

: the flip side of this is weakening Xcom craft - apart from firepower issues there is also the issue of range: the ranges of the transport craft are such that really no more than 1 manned base is necessary to cover the globe for terror site defense. Setting e.g. the fuel capacity of the Skyranger to 500 results in roughly 1 base per continent required. This has interesting strategic consequences: need for more bases makes the ecomics more challenging (and thus slows down research). [[User:Emphyrio|Emphyrio]] 08:43, 9 August 2010 (EDT)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

Some of these variant scenarios have been implemented by [[User:Seb76#Mods|Seb76]].

===Recruit Certain Alien Types===

Consider that not all aliens are loyal to their master (most TFTD alien has a device lodged to its brain), it would be interesting (or at least cool) if we could recuit such aliens to the XCOM cause. Maybe we can remove the controling devices from captive aliens after research on that species. Or convince the head of the Snakemen that it would be far more benefit to his race to help us instead of the Ethereals [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

Only certain alien types should be recruitable. Ones that should NOT be include Mutons (as they are directly controlled by Ethereals), Chrysallids (unbalancing), etc. It would be nice to be able to reverse-engineer Cyberdiscs or Sectopods, or make it that a Cyberdisc must be researched to build hovertanks/etc.
[[User:MagicJuggler|MagicJuggler]] 13:32, 18 September 2008 (PDT)
: It's pretty obvious which ones should be recruitable: non-robotic terror units that are captured alive. Chryssalids should simply do melee damage instead of impregnating (as the resulting spawn would not be mind-controlled and therefore XCOM wouldn't do it). Silacoids would be pretty ineffectual, and reapers slightly less so, but both would be disposable scouts. Celatids might actually have some use (eating through hulls with acid, and arcing over walls) but are fragile. All of these would require capturing a terror alien alive after researching Psi Amp. The two robotic units should require a live alien Engineer researched as well as UFO Construction, and the materials for building one would be one corpse of the appropriate type, Alien alloys and Elerium (to repair and refuel the husk). The Sectopod should probably be nerfed somewhat, so that it isn't quite so invincible to Heavy Plasma shots - after all, it was probably a twisted and melted modern art piece by the time it finally went down). [[User:Stubbs|Stubbs]]

=== Game option: sell only researched items ===

The fact that you may sell the alien items for the best price once you get them, without any research, is illogical. Such staff would never get on the market, being top secret and potentially dangerous to the humanity.

Selling without proper research does not help the replay value of the game either: once you know the "right path" to get the best items, you simply sell anything else immediately and ignore the unnecessary research. Too easy.

Therefore I wish for this game option: unknown items are sold for 0 (including the alien corpses), the known ones for their full price. This makes the sustainable economics much harder to develop and it gives sense to the "useless" research. Last but not least, it adds a lot of depth to the gameplay: will you choose research of a new weapon you need on the field, or of a mind probe that will earn you millions in sales? --[[User:Kyrub|Kyrub]] 15:55, 6 April 2009 (EDT)

: I really like this option, it's a great idea. Makes the game harder and makes it more interesting, more varied. Gives extra value to the otherwise "useless" research paths. Good thinking! [[User:Spike|Spike]] 15:06, 24 August 2009 (EDT)

: I'd prefer that unresearched artifacts/corpses sold for a fraction of their original value (no more than 25%). It makes no sense that nobody would pay to research them for themselves. Additionally, Laser Cannon sell price needs to be nerfed. [[User:Stubbs|Stubbs]]

: This would have the added benefit that you would know if it was 'safe' or not to sell an item research wise. Coloring the un-researched items differently on the Sell/Sack screen would be good too ~ [[User:Renegrade|Renegrade]] 13:30, 19 August 2010 (EDT)

=== New Research Mechanics ===

The above comments spurred some ideas to make the research more realistic and the path to victory less obvious.

For flavor reasons, give research options vague names instead of exact names. This already exists in some research topics, such as "New Fighter Craft" instead of "Firestorm". So, research topics might read "Alien Hovertank Wreck" instead of "Cyberdisc Corpse", "Grey Alien Corpse" instead of "Sectoid Corpse" or "Alien Pistol" instead of "Plasma Pistol". The names would be revealed in the UFOpaedia entry, and certain items would then be renamed as per common sense.

Hide the ranks of aliens in captivity until they are researched (so you'd see Live Grey Alien #1, Live Grey Alien #2 if you had two Sectoids available for research). However, if you happened to have two Soldier ranks in containment, you'd only see one topic. The same rank/race combination would never appear again, but you might have to research several specimens of the same species to get the useful one you want. The alternative would be to have researched Mind Probe, which would tell you exactly what you had in containment (just as it does on the battlefield).

Once an alien or its corpse is researched, then all other instances of that alien or its body are renamed appropriately. For example, research a live Muton and Muton corpses become obvious, and vice versa. "Live Green Humanoid Alien" is also renamed to "Live Muton".

Finally, there should be a few more prerequisites in place to make less useful research more necessary. As someone else has mentioned, you should need a Cyberdisc Corpse to research Hovertanks. I'd also suggest that Psi Amp and Mind Shield require the research of Mind Probe (seeing as both entail scanning for minds as a logical first step), and that Flying Suits require Floater Corpse, Cyberdisc Corpse or a live Floater researched as an additional prerequisite (not Ethereals, as they fly with the power of their huge brains). [[User:Stubbs|Stubbs]]

:These are all good suggestions and make a lot of sense. An alternative explanation of the names (seen in some fan fiction) is that these names are not the real names, but are made up by XCom troops based on some limited battlefield experience of them. But revealing the "real" alien race names through Research is a fun idea. [[User:Spike|Spike]] 08:44, 1 September 2009 (EDT)

=== Keyboard shortcuts at bases ===

I wish we had (customised, maybe?) keyboard shortcuts at the base screen. Numbers (at the "base information" screen as well) would switch bases, R for research, E for equip craft, T for transfer, M for manufacture, S for soldiers, B for build new base, P for purchase+recruit (or "B" for "buy" - let people double-bind if they need it), I for base information. The doubles (soldiers/sell+sack) could be solved by using the key under the primary one (x for sell+sack). - n (16:26, 16 Aug 2010 (GMT+1))

== Battlescape and Tactical ==

===Equipment Management===

All wishes are currently implemented!

===Fog of War Improvements===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Prior Recon of Battlefield====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

:Returning to AQ's original suggestion, it wouldn't be too hard would it for the dropship to "radar map" the target, and then have the basic map show up on your scanner on Turn 1? [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

====Dynamic Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Crushed Buildings====

Why don't we see any crushed or destroyed buildings? Does a UFO always fall like a rock, perpendicular to the ground? No marks on the ground? Such impact would do massive damage to the land (a small meteor can do much if it has a high speed...). (Also, at the [debatedly] "real" UFO crash zones UFO parts were scattered over miles)

I'd like to see chopped buildings, entering UFO's through a barns; entering an abductor from a immediate house's roof if I have plasma and no flying suits yet. - [[User:N|n]] 15:01, 16 August 2010 (GMT+1)

: The Pocket PC remake of the game did this, though it seems the site it concern has vanished off the face of the net. Could probably find a copy if you're interested.

: By the way, you can generate a time/date stamped signature by typing four tildes (<nowiki>~~~~</nowiki>). - [[User:Bomb Bloke|Bomb Bloke]] 23:04, 16 August 2010 (EDT)

:: Amazingly enough (is it Truman Show of me or just a coincidence :)?), my GF found a low-tech palmtop (with/in a case)... on the pavement. With no personal data and means to find the owner; when I laid my hands on it, I actually found and installed Ufo:EU there, but it wouldn't run :(. [And thanks! again for the 4 tildes name/timestamp trick] - [[User:N|n]] 19:18, 18 August 2010 (EDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

: That would be great. It would be exactly consistent with a 'spoon' type hand grenade. The timer only starts when you release the grenade, but after that it explodes at a definite time regardless of whether you pick it up or not. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[Explosions|HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

:Wouldn't it be nice though if it had gradients other than "day: 20 squares" "night: 9 squares" ? Like.. "early morning/late evening: 10-19 squares" ? I find the cut off from full daylight to full night kinda disturbing. ~ [[User:Renegrade|Renegrade]] 10:41, 19 August 2010 (EDT)

===Throwing over stuff===
'''(Moved to Talk, as this is not a bug and so does not need fixing.)'''

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

Taking off with troops onboard would be perfectly safe (for the aliens) and justifiable if one assumes that alien ships in flight are inherently inhospitable for humans. This is easily done by saying that they undergo accelerations that humans can't withstand (splat), can't withstand for any length of time (pass out), or that they intentionally make rapid accelerations in different directions, either normally or just if they're trying to bash some intruders around. Naturally, the aliens themselves would either be immune to these (tough physique / their built-in antigrav devices?), or be in acceleration chairs, safe from all this.

Alternatively, when you get the warning that the UFO is going to take off, you've got a certain amount of time to either get everyone '''off''' the UFO, or to get everyone '''on''' it (or as many as you can). There could be a follow-up mission that takes place in "sky" terrain, where the outdoors is either impassable (the easy way) or else instantly withdraws units from combat (flying suits / parachutes). The soldiers' goals would be to either take out the aliens and presumably safely land and salvage the UFO, or take out the UFO's means of flying (power cores / navigator?). In the latter case, they might have a certain number of turns to withdraw or be caught in the crash, with possible casualties just like the aliens, mitigated to some degree by their armour and maybe where inside the UFO they are.

In the case of a crash, there could be a final mission to finish off the surviving aliens, using the X-COM soldiers that survive the crash, and no landing craft (it's still back at the old landing site). Alternatively, you could say that there '''is''' an X-COM landing craft parked outside (with all remaining members of the original landing party), since the in-flight time / distance was presumably low and the original X-COM craft quickly packed up and flew to the new landing site. — [[User:Wisq|Wisq]] 17:11, 18 April 2010 (EDT)

===Alien AI===

====Attempts to rearm====
Aliens cannot pick up items, but I wish they would. If an alien has no useful weapons in inventory they should either head for cover or head for a plasma weapon. Panicked aliens drop their weapons but never seem to pick them up when they managed to pull themselves together. It would be nice if they tried to arm themselves again. --[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

:Even if it's too hard to make aliens head towards weapons (is it safe?, could it be used to trap them, not to mention the complexities of route finding) - it would still be good if an unarmed alien checked for usable weapons in every square it moved through, and at least picked up one loaded weapon or grenade per turn. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

Fixing the AI for this could be really hard. Apart from all the possible exploits by XCom, the AI is probably a really hard part of the game to reverse engineer. You could say that an unarmed alien is no threat anyway (we are only concerned about aliens without psi or built in weapons). So nothing is lost even with an exploitable method of re-arming. By exploitable I mean the XCom player can manipulate re-arming, e.g. by leaving weapons out in the open as bait for traps.

Maybe the simplest modification would be to ''not'' drop weapons when the alien panics? This does not require delving in to the AI, just intercepting the panic effects. Dont make aliens drop any weapons when they panic. It would be reasonable to return the weapon in hand to inventory, so there is a TU cost for the alien to bring the weapon back into play again.

This would not work for aliens who were stunned and wake up, or who were mind controlled by XCom and made to drop their weapons. But it would probably catch 80% of cases.

Another cheat, short of fixing the AI, is just to pick up weapons that the alien walks over. It could also pick up "spare" weapons from adjacent aliens (cheating on TUs - basically just teleporting the items to the unarmed alien). Spare alien weapons are almost invariably grenades. I have not had a lot of success in getting unarmed aliens to use grenades, so more research is needed here. Maybe only certain types of aliens use grenades, or only in certain circumstances?

Really, really cheating would be to teleport any weapon laying around the battlefield into the alien's inventory. But I think it is more fair just to say panicked aliens dont drop their equipment. [[User:Spike|Spike]] 16:13, 13 February 2010 (EST)

==== End Psi Bullying and Psi Baiting ====
When the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?

: Not a bad idea to randomise this a bit, because while initially this tactic helps the aliens, it becomes so predictable that it can be used against them by deploying unarmed "Psi Bait" soldiers to draw off all the attacks. (Or make aliens avoid controlling/panicking soldiers who have no loaded weapons. But then folks would just give them pea shooters and wear armour.) [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== 80 Item Limit on Base Defense Mission ===
: Well you get the 80 item limit on every mission, but it hurts more on a Base Defence as you have more limited ability, or sometimes no ability, to manage what goes into those 80 items. I was thinking about a couple of (theoretical) ways to fix this and I hit on a new one (new for me anyway): Why not take the 80 items from the Transport(s), first Transport then second Transport until you run out of items or hit 80. This has a few benefits:
:* Ready made interface to manage the 80-item limit, the Stores <> Craft (Equip Craft) Screen.
:* If you have no warning at all, the 80 items will probably make good tactical sense in general terms, even if they are are not totally optimised for Base Defence (no proximity mines, etc).
: I think that copying the Transport inventory into the Battlescape inventory would be relatively to implement (though what do I know?). As a simplification, you could move only the inventory in the ''first available'' Transport that is present in the Base, into the Battlescape, and not bother looking in more than one place (other Transports, Base Stores) to get up to 80. It would then be a bit of a drag if your Transports are all out on a mission when your Base gets attacked though. Or perhaps inspect the inventory of Transport 1 (wherever it is in the world), and then attempt to copy its inventory, using equipment present in the Base?
: Another way of doing it which has been mentioned elsewhere is to try to reverse the order of the items in the Stores list. This has the effect of putting the more advanced weapons first, rather than the more basic weapons. There could be all kinds of unwanted side effects of this, depending on various programming issues.
: Actually there is already a fix for the 80-item limit in XComUtil. XComUtil records a standard assign weapon set for each of your troops, and then teleports those weapons to the Battlescape from your Base Stores, regardless of the 80-item limit (but still subject to the Battlescape's 170-item limit). Not 100% sure if this works for Base Defence missions though.
:[[User:Spike|Spike]] 13:22, 24 November 2008 (CST)

=== Collision Detection Bugs ===
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!

=== Base Defence Systems Cause Alien Casualties ===

I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).

: The general view is probably that Base Defence missions are a boon to XCOM already, so why make them any easier. At very least there would need to be more damage to the loot than there was to the Alien's combat effectiveness, otherwise this unbalances the game in favour of XCOM. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== Alien vs Alien ===
This one is way out there. Alien v Alien battles out with main game, just random battlescape maps. Sectoid and their terrorists against Floaters and theirs etc. One side human controlled the other computer. Choice of ships involved etc.

:I actually love this idea. It might just about be possible using XComUtil, if someone is a total XComUtil guru.

----

There was a utility to do this from Devisraad. it has long since been removed from his site, but someone may still have it. The basics was you renamed unit and it automatically replaced graphics flag to swap out the units. Didn't work on the Large Aliens but still was a fun mod --[[User:BladeFireLight|BladeFireLight]] 02:20, 6 January 2010 (EST)

=== Aircraft in Base Defence Battlescape ===

New graphics for the Interceptor and Firestorm on the battlescape. All your ships could remain in their hangers when the aliens attack your base. Don’t understand why Mythos did not do this originally.

----

Simply for one reason: the limit on the size of the battlescape. UFO maps are usually limited to 10000 tiles (50x50x4), on Bases you have 9600 (60x60x3), the last level one being dirt. You need 3 levels to display X-COM craft. [[User:Hobbes|Hobbes]] 14:28, 23 September 2008 (PDT)

----

Could you not do it but clip off the top level of the craft - leaving the ground level and 'deck' level? It would be a cool terrain area to fight in. I like the fact that in TFTD you can still see your subs during a base defence. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

----

It is possible to edit the map files to include the Skyranger, but you'll have to use Xcomutil to play with that terrain and I think it would never launch during base defense missions (but I'm not sure on that - never tried editing the X-COM base terrain). [[User:Hobbes|Hobbes]] 19:25, 4 December 2009 (EST)

----

This could be done by creating new "hangar" map modules, each containing one of the five possible X-COM craft. Bung the modules into [[GEODATA.DAT]] at index 0C, and you're done. The catch is you can't have all craft or the MCD array will overflow. The base terrain uses ~160 tiles as it is (out of the max of 256), while the craft use about 60 each (on average). Putting them all in would take the table above 300 entries (that is to say, the game'd crash).

'Cause XcomUtil already provides us with an Intercepter design made up of SkyRanger parts, I suppose the way to go would be to only implement those two craft. If you have any alien technology ships, they could either be left out ("they were fast enough to escape") or rendered as SkyRangers.

It should also be noted that bases are made up of two levels, not three. Luckily, all the craft are only three levels high, so cutting out the landing gear still works. - [[User:Bomb Bloke|Bomb Bloke]] 19:56, 4 December 2009 (EST)

----

Very true about the MCD limit, that's why I only mentioned the Skyranger but the Interceptor could be added as well (and would not make much sense to have your first defense mission with a nice Avenger parked on the hangar while your Interceptors are being blow to bits by Battleships). The bases are 3 levels but you can only modify two of them. The game engine automatically adds a layer of 'dirt modules' either at top or bottom. Hmmm, this just gave me an idea for the wish list... [[User:Hobbes|Hobbes]] 20:29, 4 December 2009 (EST)

----

Both alien and X-Com bases ''are'' only two levels. There must be something screwy in your game; XcomUtil maybe?

It occurs to me that removing landing gear and stuff might make it ''just'' possible to jam in the Lightning tiles as well (as the MCD requirements would also shrink slightly). That'd make it possible to add the Firestorm, too. Seems a shame to get that far then leave out the Avenger, though...

- [[User:Bomb Bloke|Bomb Bloke]] 21:30, 4 December 2009 (EST)

----

Nevermind, I completely misread your previous post. Yes, they are two levels only, could be Xcomutil that adds the 3rd level.

- [[User:Hobbes|Hobbes]] 22:30, 4 December 2009 (EST)

----
You may be able to get 3 levels in an X-Com Base but not 4. EU has a smaller amount of memory alocated. I dont know the limit but 60x60x4 will crash EU. TFTD has no problem --[[User:BladeFireLight|BladeFireLight]] 02:25, 6 January 2010 (EST)

----

I got partway through this and then decided to change my methods entirely and start from scratch. So I thought I might as well post my progress anyways, as it's already about on par with the crude TFTD implementation: You always have the same craft appear in your hanger regardless of what is (or isn't!) there.

[[Image:Skyranger In Hanger.rar]]

- [[User:Bomb Bloke|Bomb Bloke]] 05:40, 17 December 2009 (EST)

----

Hey BB, a while ago I have modded the plane terrain files so that the Skyranger appears facing east instead of south. If you want to use that one (to make it a little different) let me know. [[User:Hobbes|Hobbes]] 08:23, 17 December 2009 (EST)

----

Thanks, but don't worry about it for now: it'll make the MCD arrays larger still, so I'll consider it when I get all the other stuff done.

- [[User:Bomb Bloke|Bomb Bloke]] 17:01, 19 December 2009 (EST)

----

The completed mod is now included in my toolpack. As usual, I've only done cursory testing on it, but I'm pretty sure it's stable enough.

- [[User:Bomb Bloke|Bomb Bloke]] 06:40, 20 January 2010 (EST)

=== Fixed firing TUs ===

Something that always bugged me was how the weapons used percentages for firing TUs. It doesn't make sense that the faster a soldier got, the longer it would take to fire a weapon.
: This is because you can't fire an automatic weapon any faster than it will shoot. However, it otherwise makes minimal sense, as you point out. I suggest two alternative solutions. Firstly, that only automatic fire modes use a fixed percentage of a soldier's time units, and other modes use a fixed number of TUs. This would entail the newer soldiers spraying and your most elite taking fast, selective single shots. The alternative is that each firing mode for each weapon entails its own formula (revealed in the UFOpaedia but essentially hidden during the battlescape) along the lines of "X% of TUs + Y TUs". Snap fire would be a low % of total plus a low fixed cost, Aimed would be a low % of total with a high fixed cost, and Auto would be a high % of total with a low fixed cost. While this is somewhat complex, in-game you wouldn't have to worry, and it accounts for what can be reduced (i.e. aiming speed) and what can never be improved by a soldier (i.e. cyclic rate of fire or time for a missile to lock). [[User:Stubbs|Stubbs]]
:: These observations are very sensible. However we also need to consider the impact on game balance. If you implement this in an even-handed way, alien rates of fire will increase as they have high TUs. Or, if you fudge it so that alien rates of fire remain the same, then X-Com's advantage will increase as the game progresses. Neither of these are desirable. It would be extremely hard to implement this and still maintain game balance. [[User:Spike|Spike]] 08:41, 1 September 2009 (EDT)
:::Each turn has the exact same duration, but is divided into TUs separately for each soldier. That's a simplification that works well in a turn-based game and reflects the fact that a soldier is fast or slow. However, weapons need to be aimed and will not fire faster than normal, thus they require a fixed percentage of the turn duration. In other words, soldiers gain movement speed, but fire at the same rate. This is both desirable and logical, just not self-explanatory. Thus, I would definitely stick to how TUs consumption is solved currently. [[User:mingos|mingos]]

=== In-flight Interception ===

Yes, I know that this idea is nigh-impossible, but I was thinking, wouldn't it be awesome to infiltrate a battleship, kill the aliens inside and escape, with the geoscape being shown zooming past underneath? Also, in a similar vein to the "aliens dust off after 3 turns" idea, after killing the aliens ( or blowing up the power cores, maybe?)you would have to get as many troops as possible to the drop ship in 3 turns(in retrospect I guess that you could only do this with the Lightning because of the doors) or the ship crashes and all troops not in the dropship are missing in action. Yes, this idea is impractical and would be really hard to program, but the idea of blowing a UFO up from the inside just seems epic to me. [[User:WolfenMage|WolfenMage]]

=== Impose cost to using Psionic attacks===

I think everyone agrees Psi attacks are too powerful. I would propose to impose a cost to using Psionic attacks. This could take the form of decreasing the physical stats after using a PSi attack (after all all: the psionic races are physically weak). This could for example lead to a soldier becoming a weakling or even fainting or dying from using psi-attack. Another possibility is to decrease mental stats (in this case the ratio would be that humans are not really being adapted to psi: you could be expected to go crazy playing mind games) leading to a decrease in psionic powers or maybe panicking or beserking the soldier using psi. Together with limiting psi attacks of MCed units proposed elsewhere this would rebalance the later game somewhat... [[User:Emphyrio|Emphyrio]] 07:22, 9 August 2010 (EDT)

== Miscellaneous ==

===Fix All Bugs===

Oh no [[User:Seb76#Bug Fixes|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

= I Wished (And My Wish Came True)... =

== Geoscape and Strategic ==

=== Fuel Ready always ===
[[User:Seb76#Mods|Implemented - here]]

I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

===Base Build Stacking===
[[User:Seb76#Base Building Stacking|Implemented - here]]

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

See also: Discussion on [[Talk:Wish List|Talk page]].

== Battlescape and Tactical ==

=== Equipment Management ===

==== Soldiers remembers THEIR equipment ====
[[XcomUtil|Implemented - here]]

I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====
[[User:Seb76#Equipment Screen|Mostly implemented - here]]

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===
[[User:Seb76#Range_Based_Accuracy|Brilliantly implemented - here]]

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

...discussed [http://www.ufopaedia.org/index.php?title=Talk:Wish_list here]

===Enough Smoke===
[[User:Seb76#Mods|Implemented - here]]

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)
:I did something for that on my loader. Heavy testing is required because it is hard to be make sure smoke still works as before (testing is the hardest part actually). [[User:Seb76|Seb76]] 14:09, 18 September 2008 (PDT)

=== Alien AI ===

====Aliens better with explosions====
Partly implemented [[User:Seb76#Bug Fixes|here (waypoint bug fix)]] and [[User:Seb76#Mods|here (Blaster drift)]]. ''(Possibly move this to talk, as notwithstanding these 2 bugs, apparently the Aliens are fairly safe with lethal explosives.)''

I wish that aliens using grenades or blaster bombs or stun bombs (anything that goes boom) would use more sense. They should not want to use items that go boom when they are guaranteed to be caught in the blast radius. The alien can use grenades and blaster bombs by going out of line of sight before the explosion goes off. That may not save them if the explosion blows out the walls. At least it would be less stupid then firing a point blank blaster bomb vs taking 5 steps and setting up another waypoint. Units with morale above 100 or mind controlled should still be suicidal as normal.--[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

: Actually, the aliens are quite careful with their explosives, they just seem to be prone to the occasional accident. They're not likely to fire off a blaster or grenade too close to them - as evident by the strategy where if you see an alien with a BB but can't shoot back, the safest place is to stand next to it. The blaster bomb vertical waypoint fix in the loader also eliminates the 'oops' moments where they plot a vertical right angle too close to themselves and there just happens to be a wall to the south. However, they do need more care with stun bombs as you often get to see an alien fire a stun bomb point blank into a HWP parked next to it. But I guess we are talking about three different weapon types here, so they may not be as careful with a standard firearm as they are with grenades and the BB. Wish the Apocalypse aliens at least had as much sense as the UFO/TFTD aliens. In that game, they're utterly psychotic with explosives and ignore nearby allies. -[[User:NKF|NKF]] 14:34, 19 September 2008 (PDT)

=== Mind Controlled then Hostile ===
If you mind control a human (civilians) in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control.
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

=== Mind Controlled then MIA ===
Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
: I believe XComUtil fixes this MIA issue. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)
:: XcomUtil 9.6 also restores all DOA if you win to. Not what was intended. This feature has been removed as of 9.7 until I can fix it. --[[User:BladeFireLight|BladeFireLight]] 02:27, 6 January 2010 (EST)
: Now also fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

=== Open Doors But Don't Enter/Exit ===

Open doors like they do in TFTD (I know this is mentioned above with the good stun grenades idea).
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

= Category =
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

Wish List (EU)

2010-08-19T14:41:31Z

Renegrade: /* Night Vision */

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

= I Wish... =
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"

== Geoscape and Strategic ==

=== Smarter Aircraft Movement Around Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

=== Smart Interception ===

Aircraft intercepting a UFO just head straight toward the UFOs current position at all times. Unless the UFO is already on a head-on course, this results in the interceptor travelling through a closing parabolic spiral path, and often missing the UFO and ending up in a tail-chase, and then just falling further behind unless the UFO stops or reverses course. This is pretty basic stuff, fighter pilots have known how to do this better for nearly a hundred years. It is particularly important if the aircraft you are trying to intercept is moving faster than you (eg if you are flying an Interceptor).

What is needed is to plot the UFO's current course and speed (which X-Com has from radar data), and plot an intercept course. The maths for this is pretty easy (the intersection of 2 vectors) and can be implemented in a few lines of code, if we can find out where the current interception algorithm is, and patch it.

Actually the radar bearing shown on screen is only accurate to within 45 degrees. I presume that X-Com does actually know the UFO's bearing, since it can clearly track the UFO's movements. Finding where that variable is located might be different.

While we're at it, it would be nice if the UFO detection information displayed the actual bearing in degrees, rather than just the compass direction (North East, South, etc).

Even if the improved intercept algorithm only used a bearing accurate to within 45 degrees, that would still be better for remote UFOs. You might need to switch to "head straight for it" once you get to very close range. [[User:Spike|Spike]]

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
::: A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

:::: Ummm, it seems the best solution (I, for one, can't think of any better), but wouldn't it assume that only the BattleShip really locates the player's base? All those scouts for nothing? [Still the best solution, though] [[User:N|n]] 15:01, 16 August 2010 (GMT+1)

=== All Aircraft Weapons Useful ===

In a balanced game, all weapons should have their uses, or at least a niche, but sadly this is not so:

The Cannon is only useful for shooting down Small Scouts, and even that is practically impossible, due to the difficulty in closing to 10km range with any UFO, particularly the fast-accelerating Small Scout.

The Stingray is not even useful for shooting down Small Scouts (destroys them 57% of the time) and the Avalanche is better in every meaningful way. It also takes twice as long to rearm, making it operationally much worse than the Avalanche.

The Laser Cannon is inferior to the Avalanche for everything. It does have a higher payload but this is hardly relevant. If attacking a UFO that you would struggle to kill with Avalanches, you are unlikely to own an aircraft that will survive long enough to inflict more damage than an Avalanche if it mounted Laser Cannon.

The Fusion Ball Launcher has a [[Talk:Craft_Armaments#Fusion_Balls_better_than_Plasma_Beams.3F¦possible niche]] in fighting Battleships when mounted on Interceptors. Even then, it is difficult and expensive to have aircraft configured to fight only one enemy.

Unfortunately, the optimum path for craft weapon development is all-Avalanche followed by all-Plasma Beam. This is a shame.

Suggestions to 'tune up' the other weapons:

*Cannon - Increase the damage to 20 or 25. So at least there is a pay-off if you manage to get in close.
*Stingray - Double the rearm rate so it can be reloaded as fast as an Avalanche launcher. Increase the ammo capacity to 9 or 12. Then up the rearm rate again (triple or quadruple) so it can still be reloaded as fast as Avalanche. Even then, it's probably not better than the Avalanche, so maybe it make it ''more'' accurate than the Avalanche instead of less. Raise Stingray to 90%, or to 80% but drop Avalanche to 65%.
*Laser Cannon - increase accuracy to 50% and damage to 100. Give it infinite ammunition.
*FBL - increase the ammo from 2 to 3. Increase damage to 250 or even 255. It's far and away the most expensive weapon to operate so it might as well pack the biggest punch.

It might be worth considering 'tune down' the Plasma Beam as well, particularly its stand-off range.
[[User:Spike|Spike]] 06:59, 14 February 2010 (EST)

=== Tougher UFOs ===

==== The Problem ====

So let me get this straight. The first hybrid airborne weapon that humans ever build, and it immediately outclasses every weapon the aliens ever built, including their Battleship weapon? After all the Aliens have only been building plasma weapons for a few million years, us humans have been doing it for ''months''!

More to the point, once you get Plasma Beams, downing UFOs is like shooting fish in a barrel. Even Battleships aren't that exciting if you show up with enough ships.

What is needed is to push up the range, damage, and rate of fire of all the UFO weapons, particularly the UFOs you will be fighting by the time you have plasma beams. At a minimum, the weapon on a Battleship should be at least as powerful as, say, 2 Plasma Beams (as found on the XCom craft it is fighting)? Instead of slightly less than half as powerful? Compared to a single Plasma Beam, only the Battleship weapon has better range. It has double the accuracy, slightly higher damage, but half the fire rate. Net 5.7% more firepower than one Plasma Beam, but no match for 2. And the Battleship weapon of course is the most powerful in the alien arsenal.

Possible tune ups for UFOs:

*Battleship - increase to 255 weapon power, improve reload rate to 12 (from 24). Now roughly equivalent to 4 Plasma Beams in total firepower (on Beginner difficulty). Increase range to 69km, so that the Battleship commences fire as soon as an XCom craft begins its attack run. Or better, increase range to 70+km, the limit of the interception window, so that the Battleship starts firing immediately the XCom craft enters air combat range. This would disrupt XCom aircrafts' ability to form up into a flight of 4, prior to commencing their attack. Overall, this would make it much harder to down Battleships. Increasing weapon range to 70+km would also make it much harder to tail a Battleship - manual control in the Geoscape would be needed to hold off outside of combat range. Really, the Battleship should not sit there like a sitting duck. Does it think XCom are friendly?
*Terror Ship - increase range to 52 (or decrease Plasma Beam range to 42), so stand-off kills are not possible with Plasma Beams?
*Actually maybe all the larger UFOs should have weapon range 69-70+km, so they behave very aggressively toward XCom craft.

NB: Strange effects occur if weapon range goes over 70km so it's probably best to leave it at 70km rather than 75km.

NB: Also, changes to rate of fire need to be looked at carefully though because Difficulty Level also reduces reload rate for UFOs. Between Beginner (Difficulty 0) and Superhuman (Difficulty 4), rate of fire (and thus firepower) for Battleships, Terror Ships and Supply Ships increases by 24/(24-4x2=16) or 50%. But if the base reload rate for these weapons was reduced to 12, the transition from Beginner to Advanced would increase firepower '''three''' times for these 3 UFOs (less so for the smaller UFOs). It is less risky to increase the weapon power. Unfortunately there are only 2 firepower variables to play with - damage and reload rate - so there are not a lot of options, especially for the Battleship which already has weapon strength 148 out of a probable maximum of 255.

:More detail on this. For Medium Scout, Large Scout and Abductor, with nominal reload rate 48gs, the rate of fire improves +20% between Beginner and Superhuman. For Harvester (32gs) it improves one third. For Large UFOs (Terror Ship, Supply Ship, Battleship - 24gs) the improvement is +50%. [[User:Spike|Spike]] 20:28, 14 February 2010 (EST)

I think we should assume that the Battleship, which is bigger than the entire XCom base, is engaging XCom craft with its secondary weapons rather than its main armament, which could probably destroy Manhattan with a glancing hit.

I would really like to see the hypothetical Mega-Battleship go up against XCom's finest - a flight of 4 Avengers armed with dual Plasma Cannon or dual Fusion Ball Launchers. With the Battleship having 70+km range, 255 weapon power, and an effective fire rate on Superhuman triple that of the PB, it would have the firepower of 11 Plasma Beams - 36% more firepower than the whole attacking XCom force combined. To be honest I think that would be carnage, not sure XCom could win. So that would be tuning the Battleship up too much. The 3-fold increase in rate of fire when on Superhuman is just too much. Maybe just max out the damage to 255 and range to 75. This gives a 72% increase in firepower, and a challenging tactical problem for XCom (forming up and approaching under fire).

The smaller UFOs can probably stay as they are. It is not until later in the game that XCom advances so that even large UFOs are easy pickings. What is the crossover point? Maybe the medium UFOs. So it might be good to reduce the reload times of the medium UFOs from 48 / 32 to 24, a good increase in firepower.

In general I think all UFOs energy weapons should have at least as good range as the XCom energy weapons, even the Medium Scout. Again, they have been using these weapons for millions of years and we only just figured out how to copy them from the aliens, how could our weapons be better than the aliens? How did our first plasma weapon out-range and out-perform all but the hugest UFO plasma beam? And on an airframe the size of a Small Scout we mount ''two'' such weapons? On the battlefield we only are able to replicate alien weapons; how is it that in the air we are able to improve on them ''masssively''?

Perhaps there should never be a stand-off advantage, except possibly with missiles -which should be less accurate with longer range. The XCom stand off advantage is really unfair because as far as I have seen the UFOs never attempt to close to effective range, even when they are getting killed. They don't break off much, either, though I think I have seen that happen on occasion.

==== Specific Proposals ====

===== No Standoff Beam Attacks =====

Increase ''all'' UFO plasma weapon ranges to at least 55km (compared to 52km for the XCom plasma weapon). Now only launched XCom weapons (Avalanche and Fusion Ball) have standoff advantage. Probably also reduce the accuracy of the Avalanche to 60% and buff Stingray accuracy to 80%, providing both weapons with a useful niche role.

===== No Standoff Attacks =====

Increase ''all'' UFO plasma weapon ranges to 66km (compared to 52km for the XCom plasma weapon). Now ''no'' XCom weapon has standoff advantage. (The benefit of a longer range weapon is simply spending less time being fired on by the UFO.)

===== Twitchy Aliens =====

Increase all UFO ranges to 69km. They will attack as soon as XCom aircraft commence any attack run.

===== Hostile Aliens =====

Increase all UFO ranges to 70km. They will attack as soon as XCom aircraft enter intercept range. UFOs now fire first, and tailing them unchallenged is impossible.

===== Improved Medium UFOs =====

Reduce (improve) the nominal reload time of Medium UFOs, Abductors and Harvesters, from 48gs and 32gs to 24gs. This increases the challenge in the early-mid game, when XCom might first be deploying advanced weapons.

===== Improved Battleships =====

Increase damage to 255. They're firing (bigger) Fusion Balls! A Battleship now has the same firepower as one XCom Craft with dual Plasma Beams (gosh wow!). It's a start, but what if we...

===== Super Battleships =====

... also reduce nominal reload time to 18gs. Giving a further one-third extra firepower on Beginner, 60% more on Superhuman.

===== Mega Battleships =====

... or for a real challenge, reduce reload time to 12gs. A further doubling of the firepower on Beginner - a further ''four'' times increase on Superhuman. Now Superhuman Battleships out-gun the biggest fleet XCom can throw at them!

[[User:Spike|Spike]] 00:25, 19 February 2010 (EST)

: the flip side of this is weakening Xcom craft - apart from firepower issues there is also the issue of range: the ranges of the transport craft are such that really no more than 1 manned base is necessary to cover the globe for terror site defense. Setting e.g. the fuel capacity of the Skyranger to 500 results in roughly 1 base per continent required. This has interesting strategic consequences: need for more bases makes the ecomics more challenging (and thus slows down research). [[User:Emphyrio|Emphyrio]] 08:43, 9 August 2010 (EDT)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

Some of these variant scenarios have been implemented by [[User:Seb76#Mods|Seb76]].

===Recruit Certain Alien Types===

Consider that not all aliens are loyal to their master (most TFTD alien has a device lodged to its brain), it would be interesting (or at least cool) if we could recuit such aliens to the XCOM cause. Maybe we can remove the controling devices from captive aliens after research on that species. Or convince the head of the Snakemen that it would be far more benefit to his race to help us instead of the Ethereals [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

Only certain alien types should be recruitable. Ones that should NOT be include Mutons (as they are directly controlled by Ethereals), Chrysallids (unbalancing), etc. It would be nice to be able to reverse-engineer Cyberdiscs or Sectopods, or make it that a Cyberdisc must be researched to build hovertanks/etc.
[[User:MagicJuggler|MagicJuggler]] 13:32, 18 September 2008 (PDT)
: It's pretty obvious which ones should be recruitable: non-robotic terror units that are captured alive. Chryssalids should simply do melee damage instead of impregnating (as the resulting spawn would not be mind-controlled and therefore XCOM wouldn't do it). Silacoids would be pretty ineffectual, and reapers slightly less so, but both would be disposable scouts. Celatids might actually have some use (eating through hulls with acid, and arcing over walls) but are fragile. All of these would require capturing a terror alien alive after researching Psi Amp. The two robotic units should require a live alien Engineer researched as well as UFO Construction, and the materials for building one would be one corpse of the appropriate type, Alien alloys and Elerium (to repair and refuel the husk). The Sectopod should probably be nerfed somewhat, so that it isn't quite so invincible to Heavy Plasma shots - after all, it was probably a twisted and melted modern art piece by the time it finally went down). [[User:Stubbs|Stubbs]]

=== Game option: sell only researched items ===

The fact that you may sell the alien items for the best price once you get them, without any research, is illogical. Such staff would never get on the market, being top secret and potentially dangerous to the humanity.

Selling without proper research does not help the replay value of the game either: once you know the "right path" to get the best items, you simply sell anything else immediately and ignore the unnecessary research. Too easy.

Therefore I wish for this game option: unknown items are sold for 0 (including the alien corpses), the known ones for their full price. This makes the sustainable economics much harder to develop and it gives sense to the "useless" research. Last but not least, it adds a lot of depth to the gameplay: will you choose research of a new weapon you need on the field, or of a mind probe that will earn you millions in sales? --[[User:Kyrub|Kyrub]] 15:55, 6 April 2009 (EDT)

: I really like this option, it's a great idea. Makes the game harder and makes it more interesting, more varied. Gives extra value to the otherwise "useless" research paths. Good thinking! [[User:Spike|Spike]] 15:06, 24 August 2009 (EDT)

: I'd prefer that unresearched artifacts/corpses sold for a fraction of their original value (no more than 25%). It makes no sense that nobody would pay to research them for themselves. Additionally, Laser Cannon sell price needs to be nerfed. [[User:Stubbs|Stubbs]]

=== New Research Mechanics ===

The above comments spurred some ideas to make the research more realistic and the path to victory less obvious.

For flavor reasons, give research options vague names instead of exact names. This already exists in some research topics, such as "New Fighter Craft" instead of "Firestorm". So, research topics might read "Alien Hovertank Wreck" instead of "Cyberdisc Corpse", "Grey Alien Corpse" instead of "Sectoid Corpse" or "Alien Pistol" instead of "Plasma Pistol". The names would be revealed in the UFOpaedia entry, and certain items would then be renamed as per common sense.

Hide the ranks of aliens in captivity until they are researched (so you'd see Live Grey Alien #1, Live Grey Alien #2 if you had two Sectoids available for research). However, if you happened to have two Soldier ranks in containment, you'd only see one topic. The same rank/race combination would never appear again, but you might have to research several specimens of the same species to get the useful one you want. The alternative would be to have researched Mind Probe, which would tell you exactly what you had in containment (just as it does on the battlefield).

Once an alien or its corpse is researched, then all other instances of that alien or its body are renamed appropriately. For example, research a live Muton and Muton corpses become obvious, and vice versa. "Live Green Humanoid Alien" is also renamed to "Live Muton".

Finally, there should be a few more prerequisites in place to make less useful research more necessary. As someone else has mentioned, you should need a Cyberdisc Corpse to research Hovertanks. I'd also suggest that Psi Amp and Mind Shield require the research of Mind Probe (seeing as both entail scanning for minds as a logical first step), and that Flying Suits require Floater Corpse, Cyberdisc Corpse or a live Floater researched as an additional prerequisite (not Ethereals, as they fly with the power of their huge brains). [[User:Stubbs|Stubbs]]

:These are all good suggestions and make a lot of sense. An alternative explanation of the names (seen in some fan fiction) is that these names are not the real names, but are made up by XCom troops based on some limited battlefield experience of them. But revealing the "real" alien race names through Research is a fun idea. [[User:Spike|Spike]] 08:44, 1 September 2009 (EDT)

=== Keyboard shortcuts at bases ===

I wish we had (customised, maybe?) keyboard shortcuts at the base screen. Numbers (at the "base information" screen as well) would switch bases, R for research, E for equip craft, T for transfer, M for manufacture, S for soldiers, B for build new base, P for purchase+recruit (or "B" for "buy" - let people double-bind if they need it), I for base information. The doubles (soldiers/sell+sack) could be solved by using the key under the primary one (x for sell+sack). - n (16:26, 16 Aug 2010 (GMT+1))

== Battlescape and Tactical ==

===Equipment Management===

All wishes are currently implemented!

===Fog of War Improvements===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Prior Recon of Battlefield====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

:Returning to AQ's original suggestion, it wouldn't be too hard would it for the dropship to "radar map" the target, and then have the basic map show up on your scanner on Turn 1? [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

====Dynamic Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Crushed Buildings====

Why don't we see any crushed or destroyed buildings? Does a UFO always fall like a rock, perpendicular to the ground? No marks on the ground? Such impact would do massive damage to the land (a small meteor can do much if it has a high speed...). (Also, at the [debatedly] "real" UFO crash zones UFO parts were scattered over miles)

I'd like to see chopped buildings, entering UFO's through a barns; entering an abductor from a immediate house's roof if I have plasma and no flying suits yet. - [[User:N|n]] 15:01, 16 August 2010 (GMT+1)

: The Pocket PC remake of the game did this, though it seems the site it concern has vanished off the face of the net. Could probably find a copy if you're interested.

: By the way, you can generate a time/date stamped signature by typing four tildes (<nowiki>~~~~</nowiki>). - [[User:Bomb Bloke|Bomb Bloke]] 23:04, 16 August 2010 (EDT)

:: Amazingly enough (is it Truman Show of me or just a coincidence :)?), my GF found a low-tech palmtop (with/in a case)... on the pavement. With no personal data and means to find the owner; when I laid my hands on it, I actually found and installed Ufo:EU there, but it wouldn't run :(. [And thanks! again for the 4 tildes name/timestamp trick] - [[User:N|n]] 19:18, 18 August 2010 (EDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

: That would be great. It would be exactly consistent with a 'spoon' type hand grenade. The timer only starts when you release the grenade, but after that it explodes at a definite time regardless of whether you pick it up or not. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[Explosions|HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

:Wouldn't it be nice though if it had gradients other than "day: 20 squares" "night: 9 squares" ? Like.. "early morning/late evening: 10-19 squares" ? I find the cut off from full daylight to full night kinda disturbing. ~ [[User:Renegrade|Renegrade]] 10:41, 19 August 2010 (EDT)

===Throwing over stuff===
'''(Moved to Talk, as this is not a bug and so does not need fixing.)'''

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

Taking off with troops onboard would be perfectly safe (for the aliens) and justifiable if one assumes that alien ships in flight are inherently inhospitable for humans. This is easily done by saying that they undergo accelerations that humans can't withstand (splat), can't withstand for any length of time (pass out), or that they intentionally make rapid accelerations in different directions, either normally or just if they're trying to bash some intruders around. Naturally, the aliens themselves would either be immune to these (tough physique / their built-in antigrav devices?), or be in acceleration chairs, safe from all this.

Alternatively, when you get the warning that the UFO is going to take off, you've got a certain amount of time to either get everyone '''off''' the UFO, or to get everyone '''on''' it (or as many as you can). There could be a follow-up mission that takes place in "sky" terrain, where the outdoors is either impassable (the easy way) or else instantly withdraws units from combat (flying suits / parachutes). The soldiers' goals would be to either take out the aliens and presumably safely land and salvage the UFO, or take out the UFO's means of flying (power cores / navigator?). In the latter case, they might have a certain number of turns to withdraw or be caught in the crash, with possible casualties just like the aliens, mitigated to some degree by their armour and maybe where inside the UFO they are.

In the case of a crash, there could be a final mission to finish off the surviving aliens, using the X-COM soldiers that survive the crash, and no landing craft (it's still back at the old landing site). Alternatively, you could say that there '''is''' an X-COM landing craft parked outside (with all remaining members of the original landing party), since the in-flight time / distance was presumably low and the original X-COM craft quickly packed up and flew to the new landing site. — [[User:Wisq|Wisq]] 17:11, 18 April 2010 (EDT)

===Alien AI===

====Attempts to rearm====
Aliens cannot pick up items, but I wish they would. If an alien has no useful weapons in inventory they should either head for cover or head for a plasma weapon. Panicked aliens drop their weapons but never seem to pick them up when they managed to pull themselves together. It would be nice if they tried to arm themselves again. --[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

:Even if it's too hard to make aliens head towards weapons (is it safe?, could it be used to trap them, not to mention the complexities of route finding) - it would still be good if an unarmed alien checked for usable weapons in every square it moved through, and at least picked up one loaded weapon or grenade per turn. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

Fixing the AI for this could be really hard. Apart from all the possible exploits by XCom, the AI is probably a really hard part of the game to reverse engineer. You could say that an unarmed alien is no threat anyway (we are only concerned about aliens without psi or built in weapons). So nothing is lost even with an exploitable method of re-arming. By exploitable I mean the XCom player can manipulate re-arming, e.g. by leaving weapons out in the open as bait for traps.

Maybe the simplest modification would be to ''not'' drop weapons when the alien panics? This does not require delving in to the AI, just intercepting the panic effects. Dont make aliens drop any weapons when they panic. It would be reasonable to return the weapon in hand to inventory, so there is a TU cost for the alien to bring the weapon back into play again.

This would not work for aliens who were stunned and wake up, or who were mind controlled by XCom and made to drop their weapons. But it would probably catch 80% of cases.

Another cheat, short of fixing the AI, is just to pick up weapons that the alien walks over. It could also pick up "spare" weapons from adjacent aliens (cheating on TUs - basically just teleporting the items to the unarmed alien). Spare alien weapons are almost invariably grenades. I have not had a lot of success in getting unarmed aliens to use grenades, so more research is needed here. Maybe only certain types of aliens use grenades, or only in certain circumstances?

Really, really cheating would be to teleport any weapon laying around the battlefield into the alien's inventory. But I think it is more fair just to say panicked aliens dont drop their equipment. [[User:Spike|Spike]] 16:13, 13 February 2010 (EST)

==== End Psi Bullying and Psi Baiting ====
When the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?

: Not a bad idea to randomise this a bit, because while initially this tactic helps the aliens, it becomes so predictable that it can be used against them by deploying unarmed "Psi Bait" soldiers to draw off all the attacks. (Or make aliens avoid controlling/panicking soldiers who have no loaded weapons. But then folks would just give them pea shooters and wear armour.) [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== 80 Item Limit on Base Defense Mission ===
: Well you get the 80 item limit on every mission, but it hurts more on a Base Defence as you have more limited ability, or sometimes no ability, to manage what goes into those 80 items. I was thinking about a couple of (theoretical) ways to fix this and I hit on a new one (new for me anyway): Why not take the 80 items from the Transport(s), first Transport then second Transport until you run out of items or hit 80. This has a few benefits:
:* Ready made interface to manage the 80-item limit, the Stores <> Craft (Equip Craft) Screen.
:* If you have no warning at all, the 80 items will probably make good tactical sense in general terms, even if they are are not totally optimised for Base Defence (no proximity mines, etc).
: I think that copying the Transport inventory into the Battlescape inventory would be relatively to implement (though what do I know?). As a simplification, you could move only the inventory in the ''first available'' Transport that is present in the Base, into the Battlescape, and not bother looking in more than one place (other Transports, Base Stores) to get up to 80. It would then be a bit of a drag if your Transports are all out on a mission when your Base gets attacked though. Or perhaps inspect the inventory of Transport 1 (wherever it is in the world), and then attempt to copy its inventory, using equipment present in the Base?
: Another way of doing it which has been mentioned elsewhere is to try to reverse the order of the items in the Stores list. This has the effect of putting the more advanced weapons first, rather than the more basic weapons. There could be all kinds of unwanted side effects of this, depending on various programming issues.
: Actually there is already a fix for the 80-item limit in XComUtil. XComUtil records a standard assign weapon set for each of your troops, and then teleports those weapons to the Battlescape from your Base Stores, regardless of the 80-item limit (but still subject to the Battlescape's 170-item limit). Not 100% sure if this works for Base Defence missions though.
:[[User:Spike|Spike]] 13:22, 24 November 2008 (CST)

=== Collision Detection Bugs ===
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!

=== Base Defence Systems Cause Alien Casualties ===

I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).

: The general view is probably that Base Defence missions are a boon to XCOM already, so why make them any easier. At very least there would need to be more damage to the loot than there was to the Alien's combat effectiveness, otherwise this unbalances the game in favour of XCOM. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== Alien vs Alien ===
This one is way out there. Alien v Alien battles out with main game, just random battlescape maps. Sectoid and their terrorists against Floaters and theirs etc. One side human controlled the other computer. Choice of ships involved etc.

:I actually love this idea. It might just about be possible using XComUtil, if someone is a total XComUtil guru.

----

There was a utility to do this from Devisraad. it has long since been removed from his site, but someone may still have it. The basics was you renamed unit and it automatically replaced graphics flag to swap out the units. Didn't work on the Large Aliens but still was a fun mod --[[User:BladeFireLight|BladeFireLight]] 02:20, 6 January 2010 (EST)

=== Aircraft in Base Defence Battlescape ===

New graphics for the Interceptor and Firestorm on the battlescape. All your ships could remain in their hangers when the aliens attack your base. Don’t understand why Mythos did not do this originally.

----

Simply for one reason: the limit on the size of the battlescape. UFO maps are usually limited to 10000 tiles (50x50x4), on Bases you have 9600 (60x60x3), the last level one being dirt. You need 3 levels to display X-COM craft. [[User:Hobbes|Hobbes]] 14:28, 23 September 2008 (PDT)

----

Could you not do it but clip off the top level of the craft - leaving the ground level and 'deck' level? It would be a cool terrain area to fight in. I like the fact that in TFTD you can still see your subs during a base defence. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

----

It is possible to edit the map files to include the Skyranger, but you'll have to use Xcomutil to play with that terrain and I think it would never launch during base defense missions (but I'm not sure on that - never tried editing the X-COM base terrain). [[User:Hobbes|Hobbes]] 19:25, 4 December 2009 (EST)

----

This could be done by creating new "hangar" map modules, each containing one of the five possible X-COM craft. Bung the modules into [[GEODATA.DAT]] at index 0C, and you're done. The catch is you can't have all craft or the MCD array will overflow. The base terrain uses ~160 tiles as it is (out of the max of 256), while the craft use about 60 each (on average). Putting them all in would take the table above 300 entries (that is to say, the game'd crash).

'Cause XcomUtil already provides us with an Intercepter design made up of SkyRanger parts, I suppose the way to go would be to only implement those two craft. If you have any alien technology ships, they could either be left out ("they were fast enough to escape") or rendered as SkyRangers.

It should also be noted that bases are made up of two levels, not three. Luckily, all the craft are only three levels high, so cutting out the landing gear still works. - [[User:Bomb Bloke|Bomb Bloke]] 19:56, 4 December 2009 (EST)

----

Very true about the MCD limit, that's why I only mentioned the Skyranger but the Interceptor could be added as well (and would not make much sense to have your first defense mission with a nice Avenger parked on the hangar while your Interceptors are being blow to bits by Battleships). The bases are 3 levels but you can only modify two of them. The game engine automatically adds a layer of 'dirt modules' either at top or bottom. Hmmm, this just gave me an idea for the wish list... [[User:Hobbes|Hobbes]] 20:29, 4 December 2009 (EST)

----

Both alien and X-Com bases ''are'' only two levels. There must be something screwy in your game; XcomUtil maybe?

It occurs to me that removing landing gear and stuff might make it ''just'' possible to jam in the Lightning tiles as well (as the MCD requirements would also shrink slightly). That'd make it possible to add the Firestorm, too. Seems a shame to get that far then leave out the Avenger, though...

- [[User:Bomb Bloke|Bomb Bloke]] 21:30, 4 December 2009 (EST)

----

Nevermind, I completely misread your previous post. Yes, they are two levels only, could be Xcomutil that adds the 3rd level.

- [[User:Hobbes|Hobbes]] 22:30, 4 December 2009 (EST)

----
You may be able to get 3 levels in an X-Com Base but not 4. EU has a smaller amount of memory alocated. I dont know the limit but 60x60x4 will crash EU. TFTD has no problem --[[User:BladeFireLight|BladeFireLight]] 02:25, 6 January 2010 (EST)

----

I got partway through this and then decided to change my methods entirely and start from scratch. So I thought I might as well post my progress anyways, as it's already about on par with the crude TFTD implementation: You always have the same craft appear in your hanger regardless of what is (or isn't!) there.

[[Image:Skyranger In Hanger.rar]]

- [[User:Bomb Bloke|Bomb Bloke]] 05:40, 17 December 2009 (EST)

----

Hey BB, a while ago I have modded the plane terrain files so that the Skyranger appears facing east instead of south. If you want to use that one (to make it a little different) let me know. [[User:Hobbes|Hobbes]] 08:23, 17 December 2009 (EST)

----

Thanks, but don't worry about it for now: it'll make the MCD arrays larger still, so I'll consider it when I get all the other stuff done.

- [[User:Bomb Bloke|Bomb Bloke]] 17:01, 19 December 2009 (EST)

----

The completed mod is now included in my toolpack. As usual, I've only done cursory testing on it, but I'm pretty sure it's stable enough.

- [[User:Bomb Bloke|Bomb Bloke]] 06:40, 20 January 2010 (EST)

=== Fixed firing TUs ===

Something that always bugged me was how the weapons used percentages for firing TUs. It doesn't make sense that the faster a soldier got, the longer it would take to fire a weapon.
: This is because you can't fire an automatic weapon any faster than it will shoot. However, it otherwise makes minimal sense, as you point out. I suggest two alternative solutions. Firstly, that only automatic fire modes use a fixed percentage of a soldier's time units, and other modes use a fixed number of TUs. This would entail the newer soldiers spraying and your most elite taking fast, selective single shots. The alternative is that each firing mode for each weapon entails its own formula (revealed in the UFOpaedia but essentially hidden during the battlescape) along the lines of "X% of TUs + Y TUs". Snap fire would be a low % of total plus a low fixed cost, Aimed would be a low % of total with a high fixed cost, and Auto would be a high % of total with a low fixed cost. While this is somewhat complex, in-game you wouldn't have to worry, and it accounts for what can be reduced (i.e. aiming speed) and what can never be improved by a soldier (i.e. cyclic rate of fire or time for a missile to lock). [[User:Stubbs|Stubbs]]
:: These observations are very sensible. However we also need to consider the impact on game balance. If you implement this in an even-handed way, alien rates of fire will increase as they have high TUs. Or, if you fudge it so that alien rates of fire remain the same, then X-Com's advantage will increase as the game progresses. Neither of these are desirable. It would be extremely hard to implement this and still maintain game balance. [[User:Spike|Spike]] 08:41, 1 September 2009 (EDT)
:::Each turn has the exact same duration, but is divided into TUs separately for each soldier. That's a simplification that works well in a turn-based game and reflects the fact that a soldier is fast or slow. However, weapons need to be aimed and will not fire faster than normal, thus they require a fixed percentage of the turn duration. In other words, soldiers gain movement speed, but fire at the same rate. This is both desirable and logical, just not self-explanatory. Thus, I would definitely stick to how TUs consumption is solved currently. [[User:mingos|mingos]]

=== In-flight Interception ===

Yes, I know that this idea is nigh-impossible, but I was thinking, wouldn't it be awesome to infiltrate a battleship, kill the aliens inside and escape, with the geoscape being shown zooming past underneath? Also, in a similar vein to the "aliens dust off after 3 turns" idea, after killing the aliens ( or blowing up the power cores, maybe?)you would have to get as many troops as possible to the drop ship in 3 turns(in retrospect I guess that you could only do this with the Lightning because of the doors) or the ship crashes and all troops not in the dropship are missing in action. Yes, this idea is impractical and would be really hard to program, but the idea of blowing a UFO up from the inside just seems epic to me. [[User:WolfenMage|WolfenMage]]

=== Impose cost to using Psionic attacks===

I think everyone agrees Psi attacks are too powerful. I would propose to impose a cost to using Psionic attacks. This could take the form of decreasing the physical stats after using a PSi attack (after all all: the psionic races are physically weak). This could for example lead to a soldier becoming a weakling or even fainting or dying from using psi-attack. Another possibility is to decrease mental stats (in this case the ratio would be that humans are not really being adapted to psi: you could be expected to go crazy playing mind games) leading to a decrease in psionic powers or maybe panicking or beserking the soldier using psi. Together with limiting psi attacks of MCed units proposed elsewhere this would rebalance the later game somewhat... [[User:Emphyrio|Emphyrio]] 07:22, 9 August 2010 (EDT)

== Miscellaneous ==

===Fix All Bugs===

Oh no [[User:Seb76#Bug Fixes|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

= I Wished (And My Wish Came True)... =

== Geoscape and Strategic ==

=== Fuel Ready always ===
[[User:Seb76#Mods|Implemented - here]]

I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

===Base Build Stacking===
[[User:Seb76#Base Building Stacking|Implemented - here]]

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

See also: Discussion on [[Talk:Wish List|Talk page]].

== Battlescape and Tactical ==

=== Equipment Management ===

==== Soldiers remembers THEIR equipment ====
[[XcomUtil|Implemented - here]]

I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====
[[User:Seb76#Equipment Screen|Mostly implemented - here]]

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===
[[User:Seb76#Range_Based_Accuracy|Brilliantly implemented - here]]

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

...discussed [http://www.ufopaedia.org/index.php?title=Talk:Wish_list here]

===Enough Smoke===
[[User:Seb76#Mods|Implemented - here]]

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)
:I did something for that on my loader. Heavy testing is required because it is hard to be make sure smoke still works as before (testing is the hardest part actually). [[User:Seb76|Seb76]] 14:09, 18 September 2008 (PDT)

=== Alien AI ===

====Aliens better with explosions====
Partly implemented [[User:Seb76#Bug Fixes|here (waypoint bug fix)]] and [[User:Seb76#Mods|here (Blaster drift)]]. ''(Possibly move this to talk, as notwithstanding these 2 bugs, apparently the Aliens are fairly safe with lethal explosives.)''

I wish that aliens using grenades or blaster bombs or stun bombs (anything that goes boom) would use more sense. They should not want to use items that go boom when they are guaranteed to be caught in the blast radius. The alien can use grenades and blaster bombs by going out of line of sight before the explosion goes off. That may not save them if the explosion blows out the walls. At least it would be less stupid then firing a point blank blaster bomb vs taking 5 steps and setting up another waypoint. Units with morale above 100 or mind controlled should still be suicidal as normal.--[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

: Actually, the aliens are quite careful with their explosives, they just seem to be prone to the occasional accident. They're not likely to fire off a blaster or grenade too close to them - as evident by the strategy where if you see an alien with a BB but can't shoot back, the safest place is to stand next to it. The blaster bomb vertical waypoint fix in the loader also eliminates the 'oops' moments where they plot a vertical right angle too close to themselves and there just happens to be a wall to the south. However, they do need more care with stun bombs as you often get to see an alien fire a stun bomb point blank into a HWP parked next to it. But I guess we are talking about three different weapon types here, so they may not be as careful with a standard firearm as they are with grenades and the BB. Wish the Apocalypse aliens at least had as much sense as the UFO/TFTD aliens. In that game, they're utterly psychotic with explosives and ignore nearby allies. -[[User:NKF|NKF]] 14:34, 19 September 2008 (PDT)

=== Mind Controlled then Hostile ===
If you mind control a human (civilians) in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control.
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

=== Mind Controlled then MIA ===
Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
: I believe XComUtil fixes this MIA issue. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)
:: XcomUtil 9.6 also restores all DOA if you win to. Not what was intended. This feature has been removed as of 9.7 until I can fix it. --[[User:BladeFireLight|BladeFireLight]] 02:27, 6 January 2010 (EST)
: Now also fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

=== Open Doors But Don't Enter/Exit ===

Open doors like they do in TFTD (I know this is mentioned above with the good stun grenades idea).
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

= Category =
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

Talk:Image Formats

2010-08-19T14:23:57Z

Renegrade: /* BDY format algorithm */

== BDY format algorithm ==

The following line isn't quite right:

''If "a" is 129 or greater, then draw 257-a pixels of the next byte; otherwise, '''read "a" bytes''' from the file and draw those colors sequentially.''

It appears to be "read a+1 bytes" for BDY files, which makes sense. If this were not the case, the value of '0' would mean "read 0 bytes and draw", which would be wasting a whole code.

~ [[User:Renegrade|Renegrade]] 10:23, 19 August 2010 (EDT)

User:Renegrade

2010-08-19T14:23:38Z

Renegrade: /* Enemy Unknown */

Just an old DOS/Amiga programmer from Canada who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.

== Various Utilities ==

I've made some quick and dirty utilities that I'll be posting up on my homepage soon, after I make them less "dirty". That is, properly documented and with proper checks and neatly formatted code.

=== dirt.exe ===

dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It fixes the 'paying for dirt' bug, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>

=== Paperdoll Improvement Project ===

==== Enemy Unknown ====

I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file.

To do:
* Improve Color Indexing algorithm.
* Clean up code.
* Make some art~
* Writing out and compressing BDYs

Done:
* Reading BMPs (this has been improved somewhat)
* Color Indexing (may need improvement)
* Writing out Uncompressed SPK
* Compressing SPKs
* Merge sub-programs
* Decompress BDYs

I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

I'll be providing the executables, with source, under BSD-style licensing, so that people can create their own backgrounds from whatever BMPs they can create (hint: MSPaint can create BMPs from any cut-paste operation).

The current version supports OS/2 V1 and Win V3 BMPs only, but most things use Win V3 anyways (including MSPaint for XP, and Paint for Vista/7).

==== TFTD ====

I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.

=== NameStat ===

It's a little program like the StatString one. This one ranks the agents based on a scaling grade in terms of reaction and aiming, and optionally gives psi ability data. Agents are ranked from 0-9 (with a special 'E' symbol for ones who Exceed the caps), with 0 meaning someone with the lowest possible recruit score, and 9/E being a maximum-skill agent.

=== UnitScan ===

A little cheat program to scan a battlescape save to show what's going on. I use it to find that last alien or two who's hiding in some obscure corner of the map. Especially useful for TFTD and it's complicated maps.

=== Mission Item Recovery Enhancement ===

The MIRE system - a simple DOS program that is inserted between the tactical and geoscape executables which does more intelligent recovery of ammo. It's still in progress, but once it's done, it will sum up all the various ammo types left in the game after a tactical mission, and "pack" them into the right number of clips.

Example 1:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 8 of them fire 1 shot (8 bullets)
** 4 of them fire 2 shots (8 more bullets)

That makes 8 clips with 19 shots left, and 4 clips with 18 shots, for a total of 152+72 = 224/240 rifle bullets. While only 16 bullets have been spent, the game would delete all 12 clips. Instead, I propose to fill up 11 of the clips to full bullet value, and then deleting the one partially filled clip.

Ideally the extra 4 bullets lost would be stored somewhere, but even if they can't be, 4 bullets lost is a lot better than 240 bullets lost, especially if we're talking Elerium based bullets. Also, the production cost could be refunded for any 'surplus' bullets, possibly.

Example 2:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 5 of them fire 2 shots (10 bullets)
** 3 of them fire 5 shots (15 more)
** 2 of them fire 12 shots (24 more)
** 1 of them empties an entire clip (20 more)

Sum: 69 shot of 240. 171/240 bullets left. After compacting, there would be 3 entirely empty clips (discarded), plus one clip with 9 shots left (also discarded), leaving 8 clips of 12.

A possible alteration of this design would be to save the last clip if it was half full or better, discard otherwise. Over time, that should average out to being the right number of bullets saved, roughly.

The other possibility, refunding, would give back some cash value for each bullet, depending on it's type. A rifle bullet, for instance, is $10 to buy, or $7.50 to sell. (200/20 or 150/20 respectively). This isn't quite as good as getting a fractional elerium unit back, but better than nothing.

=== Z-Com ===

One day, time permitting, I'd like to write an X-Com emulator (I've code-named this 'Z-Com' after Sluggy Freelance's Z-Com: UFO Defensiveness gag), which would re-create as much of the original X-COM feeling, but with the following enhancements:

* 3D accelerated engine (no more lag on the upper levels of Battleships!)
* Enhanced art, but with the same ''style'' as the original
* Higher resolution graphics (less jaggies!)
* Better stores/soldiers/ammo management capabilities
* Better compatibility (I'd like to point out that one of my oldest DirectX games, written for Pentium MMX/DirectX 3-5, runs just fine on my Windows 7/64 system. I don't see how these professional developers can mess things up like DirectX surface stride)

Unfortunately it would involve a lot of work, and I may never have enough free time to do it.

If it did happen though, it would likely happen in stages:

# A drop-in executable that would load/save using existing XCOM files/savegames/etc, using the original graphics.
# Enhancements to above (MIRE, XCU* style soldier kits, except maybe more permanent)
# Specification for user-created advanced graphics files (3D models instead of sprites, 24-bit backgrounds, etc)
# Implementation of user-created graphics sets

The final version would run entirely on it's own without any original XCOM data.

Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

==== Random Z-Com thoughts ====

(things to consider implementing in Z-Com)

* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:
# prohibit access to the inventory entirely. Skip over it when toggling through troops.
# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

* Show the current AND expected stock in the Buy screen; ie, including transfers 'in flight' to that base. Could work one of two ways:
# Show it as non-summed items. Ex: Rifle Clip 14 (20) --> 14 rifle clips at the base, 20 en route via transfers from purchasing or other bases.
# Show it as summed items. Ex: Rifle Clip 14 (34) --> 14 rifle clips at the base, with 20 enroute = a total of 34. I tend to favor this approach as it eliminates the possibility of faults with mental math.

* Fix the manufacturing bug. I actually have a hard time imagining the code that causes it, yet still allows proper rollover of hours. If something takes 5 engineering hours, and there's 12 engineers working on it, it should produce ''two'' on the hour, and save 2 engineer hours for the next '''anything''' (including new projects), with an ideal design.

* Also, the manufacturing page suggests that resources are gathered too quickly and/or not returned properly when cancelling. The best design for that would be that every time a new item in a batch is initiated, the cash and items required are extracted from the base stock, but then 'stored' in the manufacturing data. If that item is cancelled, then that stored cash/item list can be restored to the base's main stock.

Talk:Image Formats

2010-08-19T14:22:24Z

Renegrade: BDY format algorithm

Talk:ASTORE.DAT

2010-08-18T13:33:44Z

Renegrade: /* TFTD astore.dat */

Just two observations I had while running a test on this file.

* While aliens are in transit, the game will stop you from removing the living quarters at the destination (assuming you're in a situation where you want to get rid of all your living quarters) even though all X-Com staff have vacated the base.
* A base that is dismantled (while aliens are still in transit) all the way down to the ground will not cause the aliens stored in astore.dat to be deleted. If the base is later rebuilt, the aliens will still be present.
**This was with deconstruction of the base. Must test again with base destruction.

- [[User:NKF|NKF]]

== Windows version different ==

In the Windows version of the game, the structure of AStore.dat seems to be different. The file is a fixed size of 3600 bytes, and at a quick inspection, the format does not appear to match what's posted on the main page. I'll post more once I know it. --[[User:RobinHood70|RobinHood70]] 14:56, 24 March 2008 (PDT)

== TFTD astore.dat ==

The TFTD version of astore.dat (this is from an older version that only makes the 600 byte file) seems to have a lot of extra data in it.

From one of my TFTD games:
<PRE>
[ 0] Alien: Aquatoid(Squad Leader) Base: 0 Extra: 00 28 00 14 00 00 00 00 00
[ 1] Alien: Aquatoid(Soldier) Base: 0 Extra: 51 53 fc 8b 5e 10 c4 7e 00
[ 2] Alien: Aquatoid(Medic) Base: 0 Extra: 7e 0b c5 76 0a 8b 4e 0e 00
[ 3] Alien: Aquatoid(Medic) Base: 0 Extra: f0 5b 59 5f 5e 1f 07 c9 00
[ 4] Alien: Gill Man(Commander) Base: 0 Extra: c0 66 0f b7 db 66 0f b7 00
[ 5] Alien: Gill Man(Technician) Base: 0 Extra: d2 66 0f b7 ff 66 0f b7 00
[ 6] Alien: Gill Man(Soldier) Base: 0 Extra: 00 00 66 0f b7 46 06 0b 00
[ 7] Alien: Gill Man(Soldier) Base: 0 Extra: db 66 0f 02 c0 eb 00 66 00
[ 8] Alien: Gill Man(Squad Leader) Base: 0 Extra: ea 10 c9 cb c8 00 00 00 00
[ 9] Alien: Aquatoid(Medic) Base: 0 Extra: 06 0b c0 74 06 66 0f 03 00
[10] Alien: Deep One(Terrorist) Base: 0 Extra: 8b d0 66 c1 ea 10 c9 cb 00
[11] Alien: Deep One(Terrorist) Base: 0 Extra: 00 1e b8 88 3c 8e d8 c7 00
[12] Alien: Deep One(Terrorist) Base: 0 Extra: 8b 46 0a 89 46 ea 8b 46 00
[13] Alien: Gill Man(Squad Leader) Base: 0 Extra: 8a 46 06 b4 3d 89 46 fe 00
</PRE>

The "Extra" field is showing the bytes past the first three (type, rank, base) known fields. None of these aliens are, or have ever been, transferred.

The last field is generally 0, and I understand that one turns to 0xFF during transfers.

Could the extra data have something to do with location of capture or such? Or date and time? Or is it just random uninitialized garbage?

I'm almost suspecting the "random unitialized garbage" theory as the rest of the file looks like garbage:
<PRE>
...
[ 45]: 00 fe eb 03 b8 ff ff 1f c9 ca 08 00
[ 46]: 00 08 00 00 1e b8 88 3c 8e d8 c4 00
[ 47]: 00 ff 46 06 26 8a 07 c4 5e 0a ff 00
[ 48]: 00 26 88 07 0a c0 75 ea 8b 46 fc 00
...
</PRE>

Save for two fields (alien type and the 'transferring' flag), which are both 0. The original XCOM fields are cleaner, the unused ones are largely zero, save ones where an alien was researched, which definitely clears the first byte (but not the second one indicating rank)

Here's one from the original game, no transfers, although some have been researched:

<PRE>
[ 0] Alien: Floater(Medic) Base: 0 Extra: 00 28 10 14 00 00 00 00 00
[ 1] Alien: Floater(Medic) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[ 2] Alien: Muton(Navigator) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
(unused)
[ 4] Alien: Floater(Engineer) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[ 5] Alien: Floater(Medic) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
(unused)
(unused)
[ 8] Alien: Floater(Soldier) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[ 9] Alien: Floater(Soldier) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[10] Alien: Floater(Engineer) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[11] Alien: Sectoid(Navigator) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[12] Alien: Sectoid(Leader) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[13] Alien: Floater(Navigator) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[14] Alien: Sectoid(Leader) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[15] Alien: Floater(Medic) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[16] Alien: Sectoid(Leader) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[17] Alien: Sectoid(Leader) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
[18] Alien: Sectoid(Medic) Base: 0 Extra: 00 00 00 00 00 00 00 00 00
</PRE>

Most of those unknown fields are 0 in the original, although that 00 28 xx 14 pattern on the first record looks familiar from the first record of TFTD's file.

...

If that is garbage, is it possible that it's being pulled out of a "template" file in the executable from an incorrect address?

----

When the game runs, it assigns structs and arrays to certain positions in memory, but doesn't bother to clear the previous contents (at least, the DOS versions of the games certainly don't, though I think CE might). "Uninitialised bytes" always have a flag somewhere that indicates whether you're supposed to pay attention to them or not, but the games don't care about these flags when saving/loading - they just grab whatever's there and copy it byte for byte.

Hence if a certain area of assigned memory space never actually gets used, then yes, you'll get garbage data. This might belong to previous save games, or even entirely different applications - for eg, running DOS UFO under Windows 9x would often result in registery extracts, web history, etc getting embedded in your saves. A common place you can find such garbage data is in the padding space of fixed length null-terminated strings (eg soldier names).

Another point, even the CE versions of the games don't clean the previous save game files before writing to them. If you save in a slot that's been saved in before without manually deleting the previous save files first, then you WILL see data from multiple save games in the same files. A good example of this is [[MAP.DAT]]. - [[User:Bomb Bloke|Bomb Bloke]] 21:46, 17 August 2010 (EDT)

----

That sounds like it's allocating from the heap -- given all of the fixed size structures in the game ( ASTORE[50] this, BASE[8] that, OBPOS[160] here, SOLDIER[250] there) I have been assuming up until now that these are static allocations, out of the BSS or Data areas, which are always initialized at runtime (BSS to zero, data to whatever you specified in the source). Generally it's best practice to statically allocate static structures (as implied by the name) as it reduces the risk of pointer screw-ups and reduces memory fragmentation and malloc's overhead.

If it's coming from the heap though, they should have been less stingy with the maximums.. 'specially on ASTORE, OBPOS, and such. I mean, the whole advantage of the heap is that it's NOT static.. :S

However, this wouldn't be the first time that I've seen less-than-optimal coding...

It would also have been nice if they had cleared the old junk out before saving (I noticed soldier.dat is like that: "Rene Buchard\0ski\0\0\0...") as it would make savegames compress better, for those with that doublespace thingy, or those of us zipping up savegames. The overhead from calloc and memset isn't quite so bad if it's handled intelligently. For example, they'd only have to do that once on startup for the entire soldier.dat array, and then just on an individual soldier marked as deceased at the time that they're removed from the game..

Hey, do you think they'll ever release the source on EU/TFTD? That never hurt any of the other companies that did it on legacy products (Homeworld, Quake, etc)

Talk:ASTORE.DAT

2010-08-17T14:16:04Z

Renegrade: New section: TFTD astore.dat

Talk:Manufacturing Profitability

2010-08-16T11:52:26Z

Renegrade: /* Salary / Hourly */

Dumas, re: your point about Alien Alloys being plentiful - That section about LCs versus FBLs addresses a common early misperception. In actuality, both LCs and FBLs make the same amount of profit each ($18k), '''''but''''' you can make ~33% more LCs per month with a given number of engineers. In other words, LCs are 33% more profitable than FBLs, period.

''Unless'' you want to make your FBLs one at a time, so that they don't need AAs. Then, they're just barely (2%) more profitable than LCs. (If you play with the spreadsheet, this is clear.)

So it doesn't really have anything to do with AAs. LCs are a far better deal than FBLs, ''unless'' you want to hassle with making FBLs one at a time. Either way, you never needed a single AA. (And if you've got a big surplus of AAs, then just sell'em! smile)

Let me know if I'm missing something - [[User:MikeTheRed|MikeTheRed]] 18:41, 9 November 2006 (PST)

I see. So that's what the AA thing means. It's not explained very clearly. I'll fix that.--[[User:Dumas|Dumas]] 04:58, 10 November 2006 (PST)

Hmm, we go straight from Workshop to Manufacturing Profitability - there really should be a Manufacturing topic around that sits between them I think, to cover all the basics and key points. Might start it myself in next few days if no-one else does.

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

Oh and of course, another note is that the values for maintenance on Living Quarters and Workshops being fed into the equations are wrong, but you cant tell what they are going to cost unless you know what row of the base they are built on. Could make the numbers a little fuzzy (not likely to make a big difference, as the average cost is just over 17, so that would probably make these two items a little cheaper than the 22.5 currently assigned to them.

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

Huh, good point. I only just learned about that maintenance glitch today. For the time being, I'll stick in a note that those numbers are probably slightly high. For that matter, the maintenance glitch page could probably use a few notes about how much the other costs of 1) facilities in general are (e.g. for likely base configs - average cost per building as per UFOpaedia vs. actual average cost as per bug), and 2) other costs of the game in general. IOW I suspect that maintenance costs are a small part of a serious X-COM operation, relative to country funding, loot, and manufacturing profit. Which, if true, would lead to a wrap-up statement re: the maintenance bug of something like, "as can be seen, maint. costs are only a few percent of likely revenue and expenses; all in all, this base placement bug doesn't impact much, and can easily be totally ignored, if you like".

Edit: This could also go on that page dedicated to the bug. Maybe that's a better place for a longer explanation/analysis, and the Bugs page would just have that wrap-up sentence.

- [[User:MikeTheRed|MikeTheRed]] 19:15, 1 March 2007 (PST)

Yeah, thats along the same lines as I was thinking when I created the new page, try to avoid any bugs in that section from getting too large, if they have a lot of related detail it should be linked too, so that the bugs list is as concise as possible, most people are going to want to make sure they arent falling foul of any serious issue due to their play style and little more, if they want more information they can drill down to the dedicated topics related to it.

--[[User:Sfnhltb|Sfnhltb]] 21:02, 1 March 2007 (PST)

[[Image:MTR-FirstBase.png|thumb|left|100px|MTR - first base]][[Image:MTR-SecondLine.png|thumb|right|100px|MTR - 2nd & 3rd base]] Works for me. It brings up an interesting question - what kinds of bases do people make? (Which would affect the average facility cost, depending on where they put facilities.) For newbies, the average cost is probably the best guess. But for vet players like us wiki folks, we probably all have our own styles. I make research at my first base in Europe, and fudge around the original Access Lift relative to base attacks. My first base has a crack squad, as do two more that look like the second inset. Then as you can see from the tiny base outlines, I have several more that are hangars up top and psi labs/LQ below, then a few more that are just LQ and hangars, for screening [[Hiring/firing#General_Information|large recruit batches]]. (Good'uns are sent to the psi bases.) Manufacturing is light in 1st, heavy in 2nd, and 3rd depends how greedy I am. They all have a Stores or two, of course. And it's prior to knowing about the Maintenance Bug, naturally. (FWIW, my game date there is August 1999.)

Just some ideas about how bases might be. I'm sure the rest of you have your own styles. Heck it might be fun to make an informal area where folks show their current base layouts. - [[User:MikeTheRed|MikeTheRed]] 21:30, 1 March 2007 (PST)

==Non integer math?==
:''Those who know XCOM, know that it suffers from integer truncation in a number of places. This could've hurt profitability badly if it occurred there; for example, if an item needs 100 engineer hours but you only assign 99, it might've taken twice as long, and halved your production and profit potential. Fortunately, this is not the case with manufacturing; it does not truncate production time this way.''

I would be surprised if it was storing progress as any sort of non integer value. What it likely does is treat the entire batch as one unit, creating at the end of the hour as it knocks them off - so it saves an integral number of hours of progress against the next item in the list.

To explain with your example, but run a batch of 10 of them:

1st hour - 99 production, not to 100, no output
2nd hour - 99 stored + 99 production = 198 done, take off 100 to make one unit to leave 98 stored for next hour
3rd hour - 98 + 99 = 197, make one store 97.

What this essentially means is that on short projects you would want to run them in batches to minimise wastage, or with a number of engineers that divides into the unit production time with no remainder if you want to build single units at a time (whyever would you want to do that? ...)

--[[User:Sfnhltb|Sfnhltb]] 13:33, 2 March 2007 (PST)

Obviously it could as easily store 10 x 100 = 1000 as the hours for the entire project to complete, and produce each time it drops by 100, whichever way (I think mine is more likely because then adding/removing units in the production screen doesnt require it to recalculate the hours left for the entire project each time, but BPROD.DAT or whatever could probably easily be tested to find which it is.

--[[User:Sfnhltb|Sfnhltb]] 13:35, 2 March 2007 (PST)

Hiya Sfn; back from some time spent on things at work -

What you say makes plenty of sense. I too was surprised to think they might've used floating point here; your thought didn't occur to me at that time, but a simple carry-over makes perfect sense. In support of what you say, I did not test vs. the production time of individual items; I only tested total production vs. longer amounts of time. Shouldn't take long to try 99 scientists vs. a 100 hour item. But in the long run, it doesn't matter - there's no truncation. - [[User:MikeTheRed|MikeTheRed]] 18:46, 9 March 2007 (PST)

== A free market in armaments ==

Hi I'm back... Some thoughts I would like to post but I'm not sure where to put them:

I was getting VERY bored of manufacturing things just to get money and it occurred to me that there might be a wider economy in the world outside XCom with an industrial base that could do some of the grunt work for me, more efficiently.

What I would like to do is just provide the Elirium and Alien Alloys to an industrial concern and let them handle all the dull logistics

The effect of this is that the "market clearing" price of Elerium should be about $15K and Alloys about $25K. Rather than producing a PsiAmp for sale to convert 1 Elirium into $15K profit (net of all costs), or building an FBL in order to convert 1 AA into net $25K... just correct the market price of AA and E115 to reflect the potential profits that can be made by some other industrial organisation.

Let's assume as a simplification that these external industrial organisations have better economy of scale than XCom (factories are large scale, near transport hubs and not hidden beneath volcanic islands with false sliding craters over the Interceptor pads). Assume that this improved economy of scale allows the arms companies to cover their capital costs and still make a profit on PsiAmp & FBL production despite paying what would be (for XCom) the break-even price for the required exotic materials.

Interestingly even at a resale price of $25K it's still not worth manufacturing AAs for profit.

In game terms what I do is, once I have the necessary technology, I just sell off the alloys/elirium and use a money editor to give myself the extra cash from the "higher" price.

Possibly this could be an XComUtil mod that actually hacks the game data files to change the sale price of AA and E115 after each money-making technology is researched.

If anyone is interested in this idea I could work up a full table of increases in the market value of AA and Elirium with each technology advance. For now I have just calculated the maximum values, based on having PsiAmp (E115) and FBL (AA) technology.

In theory if there was a high resale value for craft, this could also push up the market price for UFO Navigation and UFO Power Source.

Another indulgence that I might allow myself (using a game editor) is to assume that I can buy items (anything from Medkits to Avengers)from these external industrial concerns. I would have to pay the full price (from the manufacturing spreadsheet attached to this article), plus the same buy/sell spread used for conventional items. I guess the normal delivery times could be used - or maybe 2x normal.

This would require using a base editor to simulate these purchases. Or again an XcomUtil-like 3rd party program could act as the "Arms Merchant", selling and delivering equipment.

The last scenario for those like me who get bored by manufacturing logistics is: technology licencing (royalties). This means just letting some other organisation produce the Motion Sensors and Laser Cannon, under licence from XCom Holdings Inc. As there seems to be infinite and price-inelastic demand for these products it would be a great and mutually profitable partnership. :)

As infinite income is a bit unbalancing, some kind of compromise is needed. Maybe, when the technology is researched, total monthly Funding is increased by the amount shown as the monthly net gain in the spreadsheet. This would be spread across all funding countries.

:Interesting idea. But in all honesty, it's not like money is particularly hard to come by if you're doing halfway decently. By about June, almost every alien you wax is worth 142 grand, minimum; 20K for the corpse and a 122K for the extra Heavy Plasma, when you're already drowning in them. Then you've got spare clips, alien alloys, UFO Power Sources, UFO Navigations, grenades...even Elerium. I can, in a regular game, easily build a fleet of 30 avengers without breaking the bank so long as I have a halfway decent Laser Cannon operation going on somewhere and enough recovery missions to bring in raw materials. [[User:Arrow Quivershaft|Arrow Quivershaft]] 17:28, 24 February 2008 (PST)

==XComUtil Manufacturing Profitability Discussion==

For some reason the [[XcomUtil]] "new laser weapons" manufacturing option only affects beam weapons. It does not make the manufacture of Fusion explosives and projectiles any harder, so the FBL economics are unaffected. Hovertank/Launchers, Blaster Bombs & Launchers, and Alien Grenades are also unaffected (but were never very profitable). The Hovertank/Plasma is redesignated (in name at least) a Hovertank/LaserCannon, in effect saying that the only Plasma weapon that can be produced is the craft Plasma Beam, and that with great difficulty.

Arguably to handicap the plasma weapons so much, but not to in any way handicap the alien launched / explosive / fusion weapons, seems to create an anomaly in the progression of X-COM firepower, rather than the presumed intent of making the game harder overall. Instead the midphase of the game is harder but the endphase is pretty much the same.

It appears that XComUtil prohibits the production of alien plasma small arms in a rather clumsy way, by increasing the workshop requirements to an extreme level in [[PRODUCT.DAT]]. We now know the location of the flag set to indicate if an item is manufacturable, so that could be used instead by a (hypothetical) update to XComUtil.

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

== Bored Industrialist ==

AQ, agreed the lion's share of cash comes from wasting aliens. For me this is more about what to do in the dry periods when intercepts are scarce (a whole other topic there).

Because I use the XcomUtil setting to make manufacturing profitability a lot harder I don't have the Laser Cannon factory option to boost my base level of funding/profit.

I guess for me the real solution is how to increase my number of recovery missions since I prefer that part of the gameplay.

30 Avengers though by June? That is impressive. On Superhuman? Apart from money time and parts to build them I wonder where you get the Elirium to keep them all flying. [[User:Spike|Spike]]

:I didn't catch that you had used the modified laser weapons; my bad. I said nothing about the rate at which I could put 30 Avengers together. Usually it takes me about a year of game time to get the fleet well underway(I could launch Cydonia at any time, but where's the fun in THAT?! ;) ) Also, since I've only been playing for a bit over a year myself, I don't play on Superhuman often. The aliens still have this nasty tendency to kick me around like a soccer ball if I do. :( [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:21, 25 February 2008 (PST)

One good way to ensure frequent battles is to milk supply ships off alien bases. Even one alien base will keep you well supplied for the rest of the game.

If you don't choose to use that strategy (some find the regularity of the supply ship unnatural - although you still have to risk life and limb in a real battle to win the loot), there should still be enough from the first couple of missions to get you off the ground if you spend your money wisely - not counting a production business.

Also, Superhuman actually nets you more profit from loot sales. There'll be many more aliens in a battle, and the UFO activity tends to be a bit more aggressive. That's where the higher difficulty pays off - pun and all. - [[User:NKF|NKF]] 20:50, 25 February 2008 (PST)

Yes good point about Superhuman - higher risk brings higher reward which is a good thing.

I do need to figure out how to milk supply ships, or some other method to boost my plunder rate. I guess I need to stop indiscriminately crashing all the UFOs - learn to recognise the base-building missions and let the aliens get on with it?

(By the way sorry that I keep adding sections. The edit window in the mobile phone browser I am using isn't big enough to safely edit the whole page. Don't want to mess the page up!) [[User:Spike|Spike]]

:Generally, base-building missions consist of 2 Battleships and a Supply Ship or two, and maybe a few others. They'll all show up at about the same time in the same area(of course, if you're using Radar, you may not detect them all...if you're using a Hyper Wave Decoder, you should already know its a base mission.) Once the base is built, Supply Ships will be dispatched randomly to service it(Supply Ships on Supply missions are always launched at 00:30.) Make sure the base is in Africa or Western Asia so you get to raid the aliens during the day.! [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:13, 26 February 2008 (PST)

== Thanks, Article ==

I just feel like expressing the usefulness of this article. I'm currently constructing a new Workshop (on top of a couple others); I have more than enough Living Quarters to support the 50 Engineers I plan on getting. But the Workshop is scheduled to be completed about 10 days before the month's end. With some quick calculations I found that 50 Engineers working for 10 days on Laser Cannons wouldn't produce as much profit as their net salaries! So those guys will just have to wait an extra 11 or so days to get jobs, hurting the global economy (tear). [[User:NightChime|NightChime]] 21:01, 26 January 2009 (CST)

:Hire them on the 2nd or 3rd last day of the month. It takes 72 hours for personnel, (whether soldier, engineer, or scientist) to arrive at a base. (They're probably doing a background check.) Salaried staff in transit when the month changes [[ExploitsA#Free_Wages|don't get paid]]. Assuming your month has 30 days, if you hire them at 01:00 on the 28th, the 29th and 30th will tick by, and they'll arrive at 01:00 on the 1st of the next month, meaning you can put them right to work! (While this 'feature' is listed on exploits and I consider it to be such if you're needlessly shuffling personnel around just before the end of the month, I consider it fair game if you hire them right at the end of the month.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:55, 26 January 2009 (CST)

== Salary / Hourly ==

Just a quick note here-

The figure given for a salary is $35/hour.

Doesn't that depend more on the month in question?

Enemy Unknown treats 1999 as a standard, non-leap year, so the hourly wage of an engineer should be:

<PRE>
(month - hourly wage)
1 - 33.602/hour (744 hours)
2 - 37.202/hour (672 hours)
3 - 33.602/hour (744 hours)
4 - 34.722/hour (720 hours)
5 - 33.602/hour (744 hours)
6 - 34.722/hour (720 hours)
7 - 33.602/hour (744 hours)
8 - 33.602/hour (744 hours)
9 - 34.722/hour (720 hours)
10 - 33.602/hour (744 hours)
11 - 34.722/hour (720 hours)
12 - 33.602/hour (744 hours)
</PRE>

The average salary over the year breaks down to $34.247/hour but will vary considerably in any given month.

Manufacturers-for-profit will have to watch out for February especially.

[[User:Renegrade|Renegrade]] 18:23, 7 August 2010 (EDT)

:Yeah you're right bro. As you see in the spreadsheet I made, I just used 30.5 days per month. I didn't look closer at exactly what the game is doing. Good catch! And great to hear from you.
:We have to use the resources of earth as wisely as possible if we are to live through this threat to our existence.
:: -[[User:MikeTheRed|MikeTheRed]] 23:21, 7 August 2010 (EDT)

::: No problemo! BTW, Saving the Earth is rather expensive, and the governments are being kinda cheap! Also, these Engineers are making 300K/year...where can I sign up? ~ [[User:Renegrade|Renegrade]] 07:52, 16 August 2010 (EDT)

Talk:OBPOS.DAT

2010-08-16T11:46:17Z

Renegrade: /* Record offsets 6 and 7 */

My version of TFTD (Collector's Edition) has a file size of 3360 bytes. At 16 bytes per record, that comes to 210 records. I guess the programmers increased the size of this file a bit from the DOS version which only has 200 records of 16 bytes for a total file size of 3200 bytes. --[[User:Zombie|Zombie]] 22:39, 30 December 2009 (EST)
:Worrying! Is it possible to check if the extra entries are used or not? It's possible they are just padding. [[User:Spike|Spike]]

== Record offsets 6 and 7 ==

The record offsets at 6/7 are showing as this:

6/06: Object the current item is loaded into. -1/255 by default for no item. (Uses obpos item index - first object in obpos is 0).

7/07: -1/255 by default, otherwise 0 if the item is loaded into something.

It would seem likely to me, based on that, and examining the file myself, that 6 and 7 form a 16-bit value (uint16_t or int16_t), with 0xFFFF being 'not loaded' and the full 16-bit value being what it's loaded into. It's possible at the time that field was defined that they expected more than 255 items in the file. Note that 170/200 is getting close to the limit, and no other field here appears to be related to offsets in this file. I'm surprised even that they skimped on these filesizes -- putting 400 records in here would only add 3200 bytes to the memory/disk load. Note too that address 6 is word-aligned.

Also, I don't find it that odd that they don't update the physical position of an item that's being carried. Updating a carried item's position would increase the overhead significantly for little gain, as the position can be easily calculated when needed from the location of the unit carrying it. (ex, if the unit drops it in any way, simply update the field there and then. The border between carried and dropped should be fairly well defined) ~ [[User:Renegrade|Renegrade]]

Talk:GEOSCAPE.EXE

2010-08-16T11:45:12Z

Renegrade: /* Difficulty patch information wrong? */

I just remembered something: Some bitmaps are stored in the executable. I think one such bitmap belongs to the Geoscape side bar. If the offsets for this can be located in the executable, you should be able to sign it off as an irrelevant section if you're hunting for particular variables in the executable.

But that's the hard part. Where do you look? And what image width are we looking at?

I once tried creating a program that took in an offset number, a line width number and how many bytes you want displayed from then on as the parameters. It would then open up one of the executables and draw the bytes on the screen as a bitmap of sorts. Kind of never got off the ground - I got distracted and now a year has passed and all my programming knowledge has gone into a vegetative state. I wonder if a program like this would be useful in locating tables or images in the file?

- [[User:NKF|NKF]]

----

The Geoscape side bar? Isn't that in [[GEOBORD.SCR]]?

Regardless, something to mask out known offsets in the file would certainly come in handy.

- [[User:Bomb Bloke|Bomb Bloke]] 22:41, 21 October 2006 (PDT)

== Offsets ==

This page is going to get rather long if we explain in detail all of the offsets here. I don't know if we should merge the Alien stats to the [[Alien Stats]] page or make a new page for it?

Also technically the Weapon stats are stored in Tactical so probably should be put on that page.

I've found some other offsets and if I keep digging I'm sure I'll find more. See my talk page for a mock-up of what I'm thinking for the format. [[User:Pi Masta|Pi Masta]] 15:21, 12 March 2007 (PDT)

:Well, in terms of length, it is (or is going to be) much like other game files: lots and lots of offsets, and their descriptions. It's not a page a casual player is going to reference.--[[User:Ethereal Cereal|Ethereal Cereal]] 15:56, 12 March 2007 (PDT)

Added the Detection Range offsets that Seb76 found. By the way fwiw my view is that only technically minded people will be looking at the wiki entry for a game save file so it's ok to fill this page with a lot of offsets. [[User:Spike|Spike]] 16:13, 9 March 2008 (PDT)
----
Well then, if you don't mind about huge posts, I guess it is a good place to put some stuff I discovered with static dissassembly of the executable [before my hard drive burns down ;)], some info may already be known (gold edition, sorry about the crude format...):

===Damage modifiers===
.data:0046DE74 damageModifierIncendiary dw 64h,64h,50h, 0,28h,46h,46h,64h, 0,50h,0AAh,64h,64h,64h; 0
.data:0046DE74 ; DATA XREF: sub_429CA0+2B�r
.data:0046DE74 ; sub_429CA0+132�r ...
.data:0046DE90 damageModifierHE dw 64h,64h,64h,64h,4Bh,64h,64h,64h,82h,64h,64h,50h,3Ch,50h; 0
.data:0046DEAC damageModifierLaser dw 64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,96h,64h,46h; 0
.data:0046DEC8 damageModifierPlasma dw 64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,50h,64h,46h; 0
.data:0046DEE4 damageModifierStun dw 64h,64h,5Ah,50h,64h,64h,50h,64h,64h,5Ah,64h,64h,64h, 0; 0
.data:0046DF00 damageModifierMelee dw 64h,78h,64h,64h,5Ah,64h,64h,64h,64h,64h,64h,64h,64h,64h; 0
.data:0046DF1C damageModifierAcidSpit dw 64h,0A0h,6Eh,64h,28h,64h,64h,64h,64h,64h,64h,64h,64h,64h; 0

===HWP weapons data===
.data:0046D57C builtinWeaponStats structBuiltinWeaponStats <0, 4, 3Ch, 3Ch, 21h, 0, 0, 5Ah, 50h, 0>; 0
.data:0046D57C ; DATA XREF: sub_403350+99�r
.data:0046D57C ; sub_40FF70+105�r ...
.data:0046D57C structBuiltinWeaponStats <2, 0Ch, 55h, 37h, 2Dh, 0, 0, 73h, 4Bh, 0>; 1
.data:0046D57C structBuiltinWeaponStats <3, 11h, 6Eh, 32h, 21h, 0, 0, 55h, 4Bh, 0>; 2
.data:0046D57C structBuiltinWeaponStats <4, 24h, 6Eh, 56h, 1Eh, 0, 0, 64h, 3Ch, 0>; 3
.data:0046D57C structBuiltinWeaponStats <2, 28h, 8Ch, 0, 0, 0, 0, 78h, 50h, 1>; 4
.data:0046D57C structBuiltinWeaponStats <7, 26h, 8Ch, 4Bh, 1Eh, 0, 0, 6Eh, 3Ch, 0>; 5
.data:0046D57C structBuiltinWeaponStats <4, 22h, 82h, 4Bh, 1Eh, 0, 0, 6Eh, 3Ch, 0>; 6
.data:0046D57C structBuiltinWeaponStats <3, 22h, 64h, 4Bh, 1Eh, 32h, 23h, 6Eh, 3Ch, 0>; 7
The structure is:
00000000 structBuiltinWeaponStats struc ; (sizeof=0x14)
00000000 damageType dw ?
00000002 ammoType dw ?
00000004 damage dw ?
00000006 snapshotAcc dw ?
00000008 snapshotTU dw ?
0000000A autoshotAcc dw ?
0000000C autoshotTU dw ?
0000000E aimshotAcc dw ?
00000010 aimshotTU dw ?
00000012 blasterEffect dw ?
00000014 structBuiltinWeaponStats ends

===Funding countries borders polylines===
.data:00474AD4 GeoBordersData dw 0FFFFh ; DATA XREF: GeoDrawBorders+3�r
.data:00474AD4 ; GeoDrawBorders+C�o
.data:00474AD6 dw 221h
.data:00474AD8 dw 0FF43h
.data:00474ADA dw 238h
.data:00474ADC dw 0FF3Dh
.data:00474ADE dw 22Ch
.data:00474AE0 dw 0FF28h
.data:00474AE2 dw 233h
.data:00474AE4 dw 0FF1Fh
.data:00474AE6 dw 236h
...
TFDT-CE(CRC32:C2F6C035): 0x0008AE00..0x0008B00F. 
use: rivers instead of country borders. 
data: lon,lat,lon,lat.. streams, Flags: lon = -1(NewLine), lon = -2(EndOfSection).

===Funding countries names coordinates===
.data:00474DF8 GeoCountryNamesData dw 280h ; DATA XREF: GeoDrawCountryNames+6�o
.data:00474DFA dw 0FF40h
.data:00474DFC dw 263h
.data:00474DFE dw 0B30h
.data:00474E00 dw 0FE53h
.data:00474E02 dw 25Ch
.data:00474E04 dw 0B2Ch
.data:00474E06 dw 0FEABh
.data:00474E08 dw 260h
.data:00474E0A dw 14h
.data:00474E0C dw 0FE8Ch
...
TFDT-CE(CRC32:C2F6C035): 0x0008B010..0x0008B06F. ((16*2)*3:lon,lat,Nid)

===Craft type data===
.data:0046F9A8 ; DATA XREF: sub_432B90+1C�r
.data:0046F9A8 ; sub_436970+59�r ...
craftsData
.data:0046F9A8 structCraftData <23Ah, 65336, 0, 760, 2, 1500, 150, 4, 0, 0, 0, 0Eh, 0,\
.data:0046F9A8 3, 0> ; 0 ''Skyranger''
.data:0046F9A8 structCraftData <23Bh, 65236, 1, 3100, 8, 30, 800, 4, 0, 0, 0, 0Ch, 0,\
.data:0046F9A8 0, 0> ; 1 ''Lightning''
.data:0046F9A8 structCraftData <23Ch, 65136, 2, 5400, 0Ah, 60, 1200, 4, 0, 0, 0, 1Ah,\
.data:0046F9A8 0, 4, 0> ; 2 ''Avenger''
.data:0046F9A8 structCraftData <23Dh, 65286, 2, 2100, 3, 1000, 100, 4, 0, 0, 0, 0, 0,\
.data:0046F9A8 0, 0> ; 3 ''Interceptor''
.data:0046F9A8 structCraftData <23Eh, 65286, 2, 4200, 9, 20, 500, 4, 0, 0, 0, 0, 0, 0,\
.data:0046F9A8 0> ; 4 ''Firestorm''
.data:0046F9A8 structCraftData <2B2h, 100, 2, 2200, 0Ch, 0, 50, 5, 38h, 0C8h, 0, 0, 0,\
.data:0046F9A8 0, 0> ; 5 ''Small Scout (VS)''
.data:0046F9A8 structCraftData <2B3h, 150, 2, 2400, 9, 0, 200, 4, 38h, 0FAh, 140078h,\
.data:0046F9A8 0, 0, 0, 0> ; 6 ''Medium Scout (S)''
.data:0046F9A8 structCraftData <2B4h, 250, 2, 2700, 9, 0, 250, 4, 30h, 12Ch, 140110h,\
.data:0046F9A8 0, 0, 0, 0> ; 7 ''Large Scout (S)''
.data:0046F9A8 structCraftData <2B5h, 500, 2, 4000, 8, 0, 500, 3, 30h, 1F4h, 2800B0h,\
.data:0046F9A8 0, 0, 0, 0> ; 8 ''Abductor (M)''
.data:0046F9A8 structCraftData <2B6h, 500, 2, 4300, 8, 0, 500, 3, 20h, 1F4h, 2800A0h,\
.data:0046F9A8 0, 0, 0, 0> ; 9 ''Harvester (M)''
.data:0046F9A8 structCraftData <2B7h, 1000, 2, 4800, 6, 0, 1200, 2, 18h, 7D0h, \
.data:0046F9A8 780150h, 0, 0, 0, 0> ; 10 ''Terror Ship (L)''
.data:0046F9A8 structCraftData <2B8h, 1400, 2, 5000, 6, 0, 3000, 1, 18h, 0FA0h, \
.data:0046F9A8 8C0208h, 0, 0, 0, 0> ; 11 ''Battleship (VL'')
.data:0046F9A8 structCraftData <2B9h, 800, 2, 3200, 6, 0, 2200, 2, 18h, 0BB8h, \
.data:0046F9A8 3C0120h, 0, 0, 0, 0> ; 12 ''Supply Ship (L)''

Craft type known fields: (14 x 2-byte dwords per record)
00000000 structCraftData struc ; (sizeof=0x1C)
00000000 nameIdx dw ?
00000002 scoreDestroyed dw ? ; base 10
00000004 weaponPods dw ? ''always 2 for UFOs. is this used for UFOs? how?''
00000006 maxSpeed dw ? ''in knots'' ; base 10
00000008 acceleration dw ?
0000000A fuelCapacity dw ? ; base 10
0000000C damageCapacity dw ? ; base 10
0000000E ufoSize dw ?
''5 - Very Small / 4 - Small (inc. XCom) / 3 - Medium / 2 - Large / 1 - Very Large -spike''
00000010 ufoReload dw ?
''UFO only. Firing interval. Values: 56=S/MSct 48=LSct/Abd 32=Harv 24=Suppl/Terr/BS. -spike''
00000012 ufoUnknown dw ?
''Unknown. Score related? SS=200 MS=250 LS=300 A=500 H=500 TS=2000 BS=4000 SS=3000 -spike''
00000014 ufoRange dw ? ''alien weapon distance in km*8 -kyrub/spike''
00000016 ufoPower dw ? ''alien weapon damage -kyrub/spike''
00000018 TroopSpace dw ? ''Troop capacity ''
0000001A HWPSpace dw ? ''HWP capacity -spike''
0000001C structCraftData ends

While the 9th [dword] could be UFO weapon Accuracy or even rate of fire, it seems unlikely. All the values are a multiple of 8 just like distance, so it may be related to that. That's my guess. I'm sure someone like Seb would know more. --[[User:Zombie|Zombie]] 23:56, 4 July 2009 (EDT)

:Sorry I didn't sign those theory guesses, I will do so now. Actually, evidence is building up that the byte at 0x10 within structCraftData is an inverse co-factor - i.e. a divisor - of the net total damage output of UFO attacks. In other words, it could well be a firing interval value such as is seen for XCom craft weapons. I have done 3-4 sets of ten tests so far (XCom craft survival-time tests, deducing UFO damage output). 1 set was for Medium Scout vs Interceptor, 2 sets were for Terror Ship vs Avenger. (I also did multiple attacker sets but those are harder to compare directly to this scenario). So far all 3 test sets are a reasonably good fit for this formula:

UFO net damage output =
<big>(</big>Weapon power x 75% ''(avg of randomisation)'' x 2/3 ''(accuracy)'' <big>)</big>
x <big>(</big> time ''(in game seconds)'' / 0x10 offset ''(firing interval)'' <big>)</big>

: What I want to do next is take one or both of those test scenarios, hack the 0x10 offset up or down, and see if the observed damage output varies inversely. If so, I think that will be pretty strong evidence. Even in my data, there is definitely still also some variation going on that is not fully accounted for in the formula above. As you say it is interesting the 0x10 values are all multiples of 8, suggesting distances. I will keep testing and see what I come up with! Cheers, [[User:Spike|Spike]] 06:39, 5 July 2009 (EDT)

I'm enclined to agree with the rate of fire theory. A countdown is stored in [[CRAFT.DAT]] at offset 0x26 and when it hits 0, the UFO fires. It is reset for the next shot with this formula:
tmp = offset10-2*difficultyLevel
nextShot = RAND(0,tmp)+tmp

Edit: Although the attack type does not appear here, I suspect that while a missile is "traveling", the countdown is not changed. As a result, closer ranges means higher rates of fire. [[User:Seb76|Seb76]] 07:36, 5 July 2009 (EDT)

:Excellent timing Seb! I was just about to start my tests. I could've coped with the random element, since I'm only measuring averages over time, but the presence of a 2nd factor (difficultyLevel), I was not expecting. It would have completely thrown my numbers. Also I might've crashed the game since I'd set offset10 to 0x08 on difficulty level Superhuman (=5?), creating a negative rate of fire! For simplicity I might do my tests on Beginner from now on, and repeat the earlier tests on Beginner.

:It's interesting that you don't see any reference to Attack Mode. So the changing rate of fire could indeed be a "Space Invaders Effect" as you say. Perhaps the reason this is not seen for cannon fire is that cannon fire is resolved instantly, whereas missiles are plotted as objects on the map? Is there any indication that missiles and cannon are handled differently by these routines?

:My test scenarios are probably too simplistic at the moment. But, I am sure I am seeing different rates of fire for missiles at the same range, dependent on whether they are in Standard or Cautious attack mode. I will recheck this. [[User:Spike|Spike]] 08:07, 5 July 2009 (EDT)

:Seb, I realise your formula above for variable firing intervals, from 100%-200% of the base value, explains the 2/3 factor I found which I thought might be UFO Accuracy. The average of a 100-200% range is 1.5, and the inverse of this is 2/3. So perhaps there is no accuracy factor in UFO weapon damage at all. Possibly you just have a base damage and a base firing interval, plus a 50%-100% variation on the base damage and a 100%-200% variation on the firing interval. This would certainly match the data I have so far.

:I have done a couple of tests of varying this offset 0x10 value and they show the right "sign": increasing this value decreases UFO damage output over time, and decreasing this value increases UFO damage output. The effect is strong, and approximately linear, i.e. halving the value roughly doubles the damage, etc (testing on Superhuman). To quantify it more exactly I need to go back and control for Difficulty Level which I did not expect to be a variable. I'm also going to control for the time taken for the UFO to close into firing range - by increasing the UFO weapon range in the tests to 70 or 75km.

:One thing that is worrying me though is that the firing interval is random. Since I'm using the firing interval of a cannon as my "timer" to measure the duration of all other events, it means I'm measuring with a yardstick that randomly changes size. I have to hope that my sample sizes are large enough that the averages will dominate over the fluctuations.

:More worrying is the idea that rate of fire varies with range (as opposed to with Attack Mode). That would be an elastic yardstick, worse than a random one. I thought I had disproved this but I need to go back and do it again, more carefully. I need to test the same weapon at the same range with different attack modes, again. I may well be guilty of building my hypothesis into my test scenario as an assumption! I will also double check the assumption that hacking the firing interval values for XCom weapons has no effect. I'm pretty sure that, even if the absolute firing interval changes with range, the relative ratios of firing interval when comparing different weapons, does not change. But I'll double check.

:In the code, do you see any evidence of cannon-type weapons being treated differenly from missile weapons? For example, do cannon rounds not "travel"? Also, do you see the same '''rnd (0,tmp) + tmp''' function being applied to the firing interval of XCom air attacks? Regards, [[User:Spike|Spike]] 14:30, 5 July 2009 (EDT)

===Base components data===
.data:00470640 baseElements baseComponentStruct <249h, 300, 1, 4, 0, 0, 5>; 0
.data:00470640 ; DATA XREF: BaseEditDrawSideBar_sub_432EF0+12D�r
.data:00470640 ; BuildFacilities+74�o ...
.data:00470640 baseComponentStruct <24Ah, 400, 16, 10, 1Eh, 0, 4>; 1
.data:00470640 baseComponentStruct <24Bh, 750, 26, 30, 0Ah, 0, 4>; 2
.data:00470640 baseComponentStruct <24Ch, 800, 32, 35, 32h, 0, 4>; 3
.data:00470640 baseComponentStruct <24Dh, 500, 12, 10, 0, 0, 5>; 4
.data:00470640 baseComponentStruct <24Eh, 800, 25, 15, 0, 0, 4>; 5
.data:00470640 baseComponentStruct <24Fh, 200, 16, 5, 0, 3201F4h, 5>; 6
.data:00470640 baseComponentStruct <250h, 150, 10, 5, 0FAh, 0, 4>; 7
.data:00470640 baseComponentStruct <251h, 400, 18, 15, 0Ah, 0, 4>; 8
.data:00470640 baseComponentStruct <252h, 400, 24, 10, 0, 3C0258h, 0Ah>; 9
.data:00470640 baseComponentStruct <253h, 600, 34, 12, 0, 460384h, 0Ah>; 10
.data:00470640 baseComponentStruct <254h, 800, 34, 14, 0, 5004B0h, 0Ah>; 11
.data:00470640 baseComponentStruct <255h, 1200, 38, 15, 0, 0, 9>; 12
.data:00470640 baseComponentStruct <256h, 1300, 33, 5, 0, 0, 9>; 13
.data:00470640 baseComponentStruct <257h, 750, 24, 16, 0Ah, 0, 8>; 14
.data:00470640 baseComponentStruct <258h, 1400, 26, 30, 0, 0, 9>; 15
.data:00470640 baseComponentStruct <259h, 200, 25, 25, 1, 0, 4>; 16
fields:
00000000 baseComponentStruct struc ; (sizeof=0x10)
00000000 stringId dw ?
00000002 cost dw ? ; base 10
00000004 constructionTime db ? ; base 10
00000005 maintenance db ? ; base 10
00000006 anonymous_4 dw ?
00000008 anonymous_5 dd ?
0000000C anonymous_8 dd ?
00000010 baseComponentStruct ends

===Alien missions data===
(I made another post for this one in missions.dat):
.data:00470E70 alienMissionData structAlienMission <5, 1, 0, 12Ch> ; 0
.data:00470E70 ; DATA XREF: SpawnAlienShip+10D�r
.data:00470E70 ; UpdateAlienMissions+78�r ...
.data:00470E70 structAlienMission <6, 1, 2, 104h> ; 1 ;
.data:00470E70 structAlienMission <7, 2, 4, 12Ch> ; 2 ;
.data:00470E70 structAlienMission 5 dup(<0FFFFh, 0FFFFh, 0FFFFh, 0FFFFh>); 3
...
fields:
00000000 structAlienMission struc ; (sizeof=0x8)
00000000 ufoType dw ?
00000002 numUfoToSpawn dw ?
00000004 unknown dw ?
00000006 timeCounter dw ?
00000008 structAlienMission ends

===Ground patches===
(used to spawn locations on continents):
.data:00471278 randPlaces structArea <640h, 0FDF8h, 0A0h, 28h> ; 0
.data:00471278 ; DATA XREF: GetRandomPositionOnContinent+2D�r
.data:00471278 ; GetRandomPositionOnContinent+46�r ...
.data:00471278 structArea <730h, 0FDF8h, 0F0h, 50h> ; 1
.data:00471278 structArea <8C0h, 0FE70h, 50h, 50h> ; 2
.data:00471278 structArea <730h, 0FE70h, 0A0h, 50h> ; 3
.data:00471278 structArea <820h, 0FE70h, 0A0h, 50h> ; 4
.data:00471278 structArea <730h, 0FEC0h, 0A0h, 50h> ; 5
.data:00471278 structArea <7D0h, 0FEC0h, 0B0h, 60h> ; 6
.data:00471278 structArea <870h, 0FEB0h, 0A0h, 88h> ; 7

00000000 structArea struc ; (sizeof=0x8)
00000000 xstart dw ?
00000002 ystart dw ?
00000004 width dw ?
00000006 height dw ?
00000008 structArea ends

===Zones sectors===
(used to get the zone number for a world coordinate):
.data:00474F38 geo_globe_zones structGlobeZone <618h, 987h, 0FDD0h, 0FE47h, 0>; 0
.data:00474F38 ; DATA XREF: GetWorldZoneFromPos+10�o
.data:00474F38 structGlobeZone <730h, 987h, 0FE48h, 0FF0Fh, 0>; 1
.data:00474F38 structGlobeZone <780h, 95Fh, 0FF10h, 0FFAFh, 0>; 2
.data:00474F38 structGlobeZone <0, 0B3Fh, 0FD30h, 0FDCFh, 1>; 3
.data:00474F38 structGlobeZone <0, 0B3Fh, 1E0h, 2D0h, 2>; 4
.data:00474F38 structGlobeZone <870h, 9D7h, 0FFB0h, 0FFFFh, 3>; 5
.data:00474F38 structGlobeZone <898h, 0A4Fh, 0, 77h, 3>; 6
.data:00474F38 structGlobeZone <898h, 0A27h, 78h, 1DFh, 3>; 7
.data:00474F38 structGlobeZone <0A78h, 1DFh, 0FDD0h, 0FEE7h, 4>; 8
.data:00474F38 structGlobeZone <0A78h, 13Fh, 0FEE8h, 0FF87h, 5>; 9
.data:00474F38 structGlobeZone <0A78h, 1B7h, 0FF88h, 0FFFFh, 5>; 10
.data:00474F38 structGlobeZone <28h, 1B7h, 0, 13Fh, 6> ; 11
.data:00474F38 structGlobeZone <140h, 22Fh, 0FEE8h, 0FF87h, 7>; 12
.data:00474F38 structGlobeZone <1E0h, 2CFh, 0FE70h, 0FEE7h, 7>; 13
.data:00474F38 structGlobeZone <230h, 2CFh, 0FEE8h, 0FFD7h, 7>; 14
.data:00474F38 structGlobeZone <2D0h, 347h, 0FE70h, 4Fh, 8>; 15
.data:00474F38 structGlobeZone <348h, 4AFh, 0FE70h, 0FFD7h, 8>; 16
.data:00474F38 structGlobeZone <1E0h, 59Fh, 0FDD0h, 0FE6Fh, 9>; 17
.data:00474F38 structGlobeZone <348h, 59Fh, 0FFD8h, 18Fh, 0Ah>; 18
.data:00474F38 structGlobeZone <5A0h, 617h, 0FDD0h, 0FE47h, 0Bh>; 19
.data:00474F38 structGlobeZone <5A0h, 72Fh, 0FE48h, 0FF0Fh, 0Bh>; 20
.data:00474F38 structGlobeZone <5A0h, 77Fh, 0FF10h, 0FFAFh, 0Bh>; 21
.data:00474F38 structGlobeZone <5A0h, 86Fh, 0FFB0h, 0FFFFh, 0Bh>; 22
.data:00474F38 structGlobeZone <5A0h, 897h, 0, 1DFh, 0Bh>; 23
.data:00474F38 structGlobeZone <4B0h, 59Fh, 0FE70h, 0FFD7h, 0Bh>; 24
.data:00474F38 structGlobeZone <988h, 0A77h, 0FDD0h, 0FF0Fh, 0Ch>; 25
.data:00474F38 structGlobeZone <960h, 0A77h, 0FF10h, 0FFAFh, 0Ch>; 26
.data:00474F38 structGlobeZone <9D8h, 0A77h, 0FFB0h, 0FFFFh, 0Ch>; 27
.data:00474F38 structGlobeZone <0A50h, 27h, 0, 77h, 0Dh>; 28
.data:00474F38 structGlobeZone <0A28h, 27h, 78h, 1DFh, 0Dh>; 29
.data:00474F38 structGlobeZone <28h, 1B8h, 140h, 1DFh, 0Dh>; 30
.data:00474F38 structGlobeZone <1B8h, 22Fh, 0FF88h, 4Fh, 0Eh>; 31
.data:00474F38 structGlobeZone <230h, 2CFh, 0FFD8h, 4Fh, 0Eh>; 32
.data:00474F38 structGlobeZone <1B8h, 347h, 50h, 1DFh, 0Eh>; 33

Same for country zones:
.data:00475090 geo_glob_country_zones structGlobeZone <758h, 7F8h, 0FE78h, 0FF00h, 0>; 0
.data:00475090 ; DATA XREF: GetCountryFromPos+11�o
.data:00475090 structGlobeZone <7F8h, 8ACh, 0FE78h, 0FF18h, 0>; 1
.data:00475090 structGlobeZone <820h, 848h, 0FF18h, 0FF30h, 0>; 2
.data:00475090 structGlobeZone <8A8h, 8C0h, 0FF00h, 0FF38h, 0>; 3
.data:00475090 structGlobeZone <8ACh, 8F0h, 0FEA0h, 0FF00h, 0>; 4
.data:00475090 structGlobeZone <8F0h, 924h, 0FE94h, 0FEC0h, 0>; 5
.data:00475090 structGlobeZone <0F0h, 190h, 0FDD0h, 0FE98h, 1>; 6
.data:00475090 structGlobeZone <0C0h, 0F0h, 0FE20h, 0FEB0h, 1>; 7
.data:00475090 structGlobeZone <190h, 258h, 0FD98h, 0FEC0h, 1>; 8
.data:00475090 structGlobeZone <258h, 528h, 0FD80h, 0FE70h, 1>; 9
.data:00475090 structGlobeZone <528h, 550h, 0FDD0h, 0FE28h, 1>; 10
.data:00475090 structGlobeZone <0B00h, 10h, 0FE20h, 0FE70h, 2>; 11
.data:00475090 structGlobeZone <0B18h, 38h, 0FE70h, 0FEA8h, 3>; 12
.data:00475090 structGlobeZone <30h, 78h, 0FE48h, 0FE84h, 4>; 13
.data:00475090 structGlobeZone <38h, 78h, 0FE8Ch, 0FEA8h, 5>; 14
.data:00475090 structGlobeZone <58h, 90h, 0FEA8h, 0FED8h, 5>; 15
...

===Dot color data for LOC.DAT entries===
shawn on world map (can't think of a better name...):
.data:00475202 locationColor dw 0, 0Dh, 0Bh, 9, 1, 5, 7, 3 ; 0
.data:00475202 ; DATA XREF: geoDrawLocations+ED�r

Just after that are data describing the mask for drawing the location (I don't remember the format, but it shouldn't be something too complicated to decypher)

===Flare pattern===
(tactical mode):
.data:0046C558 flarePattern db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 0
.data:0046C558 ; DATA XREF: LightmapAddFlarePattern+7�o
.data:0046C558 ; LightmapAddFlarePattern+19�o
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 31
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 62
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h; 93
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h; 124
.data:0046C558 db 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Ah, 0Ah, 0Ah, 0Ah, 0Ah, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h; 155
.data:0046C558 db 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 0Ah, 9, 9, 9, 9, 9, 0Ah, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h; 186
.data:0046C558 db 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 9, 9, 8, 8, 8, 8, 8, 9, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h; 217
.data:0046C558 db 10h, 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 9, 8, 8, 7, 7, 7, 7, 7, 8, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 10h, 10h; 248
.data:0046C558 db 10h, 0Fh, 0Eh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 9, 8, 7, 7, 6, 6, 6, 6, 6, 7, 7, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Eh, 0Fh, 10h; 279
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 0Ah, 9, 8, 7, 6, 6, 6, 5, 5, 5, 6, 6, 6, 7, 8, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 310
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 5, 4, 4, 4, 5, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 341
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 4, 3, 3, 3, 4, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh; 372
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 4, 3, 2, 2, 2, 3, 4, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 403
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 3, 2, 1, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 434
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 465
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 3, 2, 1, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 496
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 4, 3, 2, 2, 2, 3, 4, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 527
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 4, 3, 3, 3, 4, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh; 558
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 5, 4, 4, 4, 5, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 589
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 0Ah, 9, 8, 7, 6, 6, 6, 5, 5, 5, 6, 6, 6, 7, 8, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 620
.data:0046C558 db 10h, 0Fh, 0Eh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 9, 8, 7, 7, 6, 6, 6, 6, 6, 7, 7, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Eh, 0Fh, 10h; 651
.data:0046C558 db 10h, 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 9, 8, 8, 7, 7, 7, 7, 7, 8, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 10h, 10h; 682
.data:0046C558 db 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 9, 9, 8, 8, 8, 8, 8, 9, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h; 713
.data:0046C558 db 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 0Ah, 9, 9, 9, 9, 9, 0Ah, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h; 744
.data:0046C558 db 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Ah, 0Ah, 0Ah, 0Ah, 0Ah, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h; 775
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h; 806
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h; 837
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 868
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 899
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 930

Sorry for the big post and the raw format... [[User:Seb76|Seb76]] 13:59, 10 March 2008 (PDT)

Construction costs for access lifts:
.data:0046E69C basePrice dd 800000, 950000, 900000, 600000, 1000000, 650000, 550000, 500000, 750000; 0
.data:0046E69C dd 800000, 750000, 600000, 3 dup(500000); 9
[[User:Seb76|Seb76]] 11:01, 16 March 2008 (PDT)

=== Craft weapon stats ===

I guess the craft weapon stats could be in here too?
as far I can see these are at 353378 (plain 1.4), 18 bytes, 9x2 byte: 
index/range/acc/dmg/??/time/no of ammo/??/ammo 
--[[User:Emphyrio|Emphyrio]] 15:25, 1 March 2009 (CST)

----

In the WinCE version (unpatched) the craft weapon stats start at offset 0x6fb18. Or search for this signature:

40 02 1e 00 46 00 46 00 01 00 0f 00 06 00 01 00 06 00

Fields are:
Index - Range (km) - Hit% - Damage - ?X? - reload time - ammo cap - ?Y? - ammo type

Weapon X Y
Stingray 1 1
Avalanche 3 1
Cannon 8 100
FBL 5 1
Laser C 10 50
Plasma C 12 50

I would speculate that value "Y" is the re-arming rate on the ground. I think this data differs slighly from what is stated at [[Rearming]] so it might be worth double checking that.

Value "X" could be a bitmask, an index to a sound effect, or just about anything. It's possible the lowest bit is a flag that is set for a missile weapon, unset for a cannon-type weapon.

[[User:Spike|Spike]] 19:43, 5 July 2009 (EDT)

The "reload time" value (as it is called in the in-game UFOPaedia) does not seem to be used by the executable. Instead, hard coded values are used. See [[UFO Interception#Observed Rates of Fire|Observed Rates of Fire]]. [[User:Spike|Spike]] 20:31, 13 July 2009 (EDT)

I checked and the rearming rates in the wiki article are correct, i.e. 100 rds per hour for all Cannon types. Maybe this "Y" data was intended as the rearming rate but is unused? The next step would be to hack the "Y" values and look for any effect. It would also be interesting to hack the low bit of the "X" value and see if that has any effect, such as controlling the missile weapon firing interval behaviour (RoF changes based on attack mode), or sound effect.

Here is X as a bitmask

Weapon X Bitmask
Stingray 1 00000001
Avalanche 3 00000011
FBL 5 00000101
Cannon 8 00001000
Laser C 10 00001010
Plasma C 12 00001100

[[User:Spike|Spike]] 18:18, 16 February 2010 (EST)

Actually it looks like the low order 3 bits are just a sequence/ID number (ascending damage?). The next higher bit is launched (0) vs cannon (1).

Weapon X Bitmask Seq Cannon?
Cannon 8 00001000 0 1
Stingray 1 00000001 1 0
Laser C 10 00001010 2 1
Avalanche 3 00000011 3 0
Plasma C 12 00001100 4 1
FBL 5 00000101 5 0

[[User:Spike|Spike]] 19:49, 14 March 2010 (EDT)

=== Manufacturing stats? ===

Has someone worked out the manufacturing stats at offset <s>355596</s> 355600 (vanilla 1.4)??
As far as I can see it looks like 35 records of 18 bytes 
 
:See the [[PRODUCT.DAT]] page. --[[User:Zombie|Zombie]] 16:25, 24 February 2009 (CST)
:: ok, this is actually is a useful bit of information, I <s>would</s> have put it in the article.. --[[User:Emphyrio|Emphyrio]] 07:06, 25 February 2009 (CST)
:Good deal. I also added a note to the top of [[PRODUCT.DAT]] (and linked the [[Manufacturing_Profitability]] to PRODUCT.DAT - that should've been there, too). -[[User:MikeTheRed|MikeTheRed]] 11:17, 25 February 2009 (CST)

==New Bundles==

The "Complete Package" and such versions of X-Com from Steam, interestingly enough, include both versions of the game, at least .exe wise. The one that runs when you just launch from the Steam menu is the original European version, 1.2, so I wonder exactly why they included the other version. -[[User:Elliotw2|Elliotw2]] 2009-01-15 18:01:37

:Hiya Elliotw2! I wasn't watching this page's Talk page before, but I am now.
:As for the various versions, I dusted off some 10 y.o. DOS floppies a few years ago. They still worked, and I ran with it (U.S. DOS v. 1.4). Although I've read a lot about the other versions on this wiki, I'll let the other vets here address what you just said (smile). I personally would have chosen the U.S. version... Vets, why would they have both versions in the bundle, but make the default be the European version?
:Elliotw2, please leave a mini-review (or repeat what you just said) at [[GEOSCAPE.EXE#X-COM_Complete_Packages]] (see my new "mini-review" format request there). Sorry for the mess, newcomers - especially having this tucked away under GEOSCAPE, but it makes sense to us grognards. As always, we will change and grow as needed, and "us" easily includes "you". For now, we're just trying to make sure that newcomers can find what they need here, and that there's a place for info on the Complete Packages to be voiced.
:-[[User:MikeTheRed|MikeTheRed]] 03:49, 19 January 2009 (CST)

== Difficulty patch information wrong? ==

It appears that the information for patching the difficulty is wrong on this page.

I have what I believe is the US version of XCOM 1.4, and I patched the file as per the data given for 1.4, and yet it still created a 60-byte IGLOB.DAT file. Further, DOSBOX complained of illegal memory accesses after the patch (which it did not do before).

33ea0819e6888f0450f9a1e5e19dc98b *GEOSCAPE.EXE (binary MD5SUM -- file is 382,957 bytes, created 1995-02-28 @ 10:24 PM)

There actually was a 60 byte (0x3c) at the location given, but I have a feeling it was something other than the size_t in question.

:If you search for:
<pre>3C 00 00 00 57 2B C9 49</pre>
:you will fined the iglob.dat length for all versions of UFO. --[[User:BladeFireLight|BladeFireLight]] 19:45, 16 February 2010 (EST)

Yeah, that was my fault, I just put the same value as was in 1.0. It's corrected now.
[[User:Hatfarm|Hatfarm]] 18:45, 5 June 2010 (EDT)

I tried that out, it seems to work perfectly. Thank you both! FYI; the above is the XCOM package available from <s>GOG.com</s> Direct2Drive. [[User:Renegrade|Renegrade]] 20:23, 17 July 2010 (EDT)

Talk:SOLDIER.DAT

2010-08-16T11:40:25Z

Renegrade: /* the NAME field */

Why would Missions and Kills be signed? You're never going to have negative values. Shouldn't they be unsigned??

- Danial

----

You would think that, wouldn't you? At least that's what I would've done in their place. You can't owe a few kills or missions!

But if you enter values of 0xFFFF into each, the base screen shows -1. Hence why they're signed.

- [[User:NKF|NKF]]

----

Zombie, I've changed back your recent change to offset 63, as you've been mislead a bit by corrupt data...

The files MAN_A.SPK through to MAN_N.SPK do not exist in a normal install of UFO, I'm afraid, and it was never intended for Soldier.Dat to point to them. They are simply the file names I chose when I coded my [http://www.strategycore.co.uk/files/index.php?dlid=428 custom uniform mod], so that aliens wouldn't display as troopers in the inventory screens anymore. I later added the same effect to my [http://www.strategycore.co.uk/files/index.php?dlid=470 map editer] as well. This affected the inventory screens and nothing else, by tweaking [[UNITREF.DAT|UnitRef[1]]] - The installation of either of my programs obviously adds the required MAN files to your game (as referring to any MAN file that does not exist causes a crash).

On the other hand, modifying Soldier[63] apparently changes the way the unit appears in the battlescape display, as well as what it turns into when it dies! This means that it is not only used to determine UnitRef[1] when battle begins, but UnitRef[0]/[38] as well, and most likely others...

That is to say, this byte gets set when you give a trooper armor. Armor dictates how a unit appears. However, it also indicates a units defensive values, and what item it will turn into when it dies. You didn't mention defense in your edit, but I would assume it also gets set to garbage when you fiddle with this offset.

I'll check this with a byte comparer when I get the time. With any luck, this'll also show me any remaining UnitRef offsets that are affected by this one. I'll update the article when I get some results.

- [[User:Bomb Bloke|Bomb Bloke]] 05:41, 6 November 2006 (PST)

----
My fault, but problems like these could easily be avoided with a readme file indicating what modifications are made to the game files. Never thought that an editor had modding chunks tossed in. That'll teach me a lesson.

Changing the armor field in soldier.dat ([63] or [062] or whatever the darn offset is), changes the image sprite in the battlescape without too many problems, but running through your unit list in the equip screen will crash the game if the number here is greater than 3 as there aren't any MAN.spk images to refer back to. Like you mention, the actual armor attributes are garbage (albeit '''''consistent''''' garbage as the numbers do not change). Just for giggles I did a couple dry runs with varying values to see what would happen to the death item and armor attributes. This may or may not be useful.

<table {{StdCenterTable}}>
<tr {{StdDescTable_Heading}}><th>Value</th><th>Unit</th><th>Death Item</th><th>Fr</th><th>Le</th><th>Ri</th><th>Re</th><th>Un</th></tr>
<tr><td>4</td><td>Sectoid</td><td>HP Clip</td><td>127</td><td>0</td><td>115</td><td>116</td><td>117</td></tr>
<tr><td>5</td><td>Snakeman</td><td>Plasma Rifle</td><td>118</td><td>119</td><td>120</td><td>121</td><td>122</td></tr>
<tr><td>6</td><td>Ethereal</td><td>PR Clip</td><td>123</td><td>124</td><td>125</td><td>126</td><td>18</td></tr>
<tr><td>7</td><td>Muton</td><td>Plasma Pistol</td><td>4</td><td>16</td><td>8</td><td>15</td><td>10</td></tr>
<tr><td>8</td><td>Floater</td><td>PP Clip</td><td>14</td><td>20</td><td>20</td><td>0</td><td>0</td></tr>
<tr><td>9</td><td>Celatid</td><td>Blaster Launcher</td><td>0</td><td>0</td><td>25</td><td>0</td><td>35</td></tr>
<tr><td>10</td><td>Silacoid</td><td>Blaster Bomb</td><td>0</td><td>24</td><td>18</td><td>0</td><td>10</td></tr>
<tr><td>11</td><td>Chryssalid</td><td>Small Launcher</td><td>15</td><td>6</td><td>0</td><td>8</td><td>8</td></tr>
<tr><td>12</td><td>Reaper</td><td>Stun Bomb</td><td>0</td><td>7</td><td>8</td><td>9</td><td>0</td></tr>
<tr><td>13</td><td>Sectopod</td><td>Alien Grenade</td><td>5</td><td>10</td><td>0</td><td>8</td><td>21</td></tr>
<tr><td>14</td><td>Cyberdisc</td><td>Elerium-115?</td><td>8</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>15</td><td>Male Civilian</td><td>Variable</td><td>1</td><td>3</td><td>5</td><td>5</td><td>5</td></tr>
<tr><td>16</td><td>Female Civilian</td><td>Psi-Amp</td><td>0</td><td>0</td><td>52</td><td>0</td><td>80</td></tr>
<tr><td>17</td><td>Zombie</td><td>Unknown</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>18</td><td>Invisible</td><td>Mind Probe</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>19</td><td>Invisible</td><td>Sectoid Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>20</td><td>Invisible</td><td>Snakeman Corpse</td><td>80</td><td>0</td><td>104</td><td>0</td><td>80</td></tr>
<tr><td>21</td><td>Invisible</td><td>Ethereal Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>22</td><td>Invisible</td><td>Muton Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>23</td><td>Invisible</td><td>Crashes (FLT?)</td><td>0</td><td>80</td><td>0</td><td>104</td><td>0</td></tr>
<tr><td>24</td><td>Invisible</td><td>Celatid Corpse</td><td>0</td><td>0</td><td>104</td><td>0</td><td>160</td></tr>
<tr><td>25</td><td>Invisible</td><td>Silacoid Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>26</td><td>Invisible</td><td>Chryssalid Corpse</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td>27</td><td>Invisible</td><td>Reaper1 Corpse</td><td>0</td><td>160</td><td>0</td><td>104</td><td>0</td></tr>
<tr><td>28</td><td>Invisible</td><td>Reaper2 Corpse</td><td>0</td><td>0</td><td>104</td><td>0</td><td>160</td></tr></table>
I couldn't find out what item the Cyberdisc "unit" gives up when it dies, as the explosion happens even with Stun Bombs. I assume it's Elerium-115 as it follows the normal item list. The male civilian is a tough nut to crack also. I saw a death item of a Laser Rifle and a Small Rocket a few times - it's probably random or semi-random. Still, you can't stand over the "corpse" and pick up the item as it is invisible in the equip soldier screen. The Zombie is also strange as it cannot be killed by incendiary, most likely a hacked armor value will make the game assume you are wearing a suit of armor greater than Personal and apply the 0% modifier. A value of 23 will crash the game if you try and kill the unit so it's just an assumption that the death item is a Floater corpse.

I should also mention that some of the invisible units higher up on the list are probably tanks as the sound usually correlates to image. This doesn't hold for units lower in the list as I heard a movement noise of a Pistol or Rifle shooting rapidly for one of them! Strange stuff, but it can probably all be tied together once we know where the pointers are going.

- Zombie

-----

That's an easy one at least. As you mentioned, they follow the normal [[OBDATA.DAT|item list]] when turning into death items. Simply put, a unit will turn into object X, where X is 31 + Soldier[63]. That is to say, by default, a unit with no armor (value 0) will turn into a normal corpse (31). But if you crank the value up to, say, 19 (an illegal value), you get a sectoid corpse (31 + 19 = object 50). Pointers to items in the list that were never implemented in the game create weird results.

As for why the floater crashes when dying, perhaps it uses an illegal death scream or something. The corpse value seems legal enough.

The units which sound like tanks, aren't. The reason they makes those noises is because each unit has it's own movement [[SOUND|sound set]], which is determined by some value in [[UNITREF.DAT|UnitRef]]. It's one of the values I've been meaning to hunt down but never got around to...

Furthermore, some units slide, and some units walk. This is another value I've yet to hunt down, but it's important, because sliding units (snakemen, tanks) sound the same regardless of the terrain they're moving over. They also incur different TU costs as per [[MCD|MCD[39]-[41]]].

So obviously one or both of those values are also being determined by Soldier[63]. That'll make them easier to find in UnitRef.

Remember that a soldier is a soldier whether he's in armor or out of it. His armor does change the way he appears, and a few other things, but he's still a soldier at the end of the day. That said, a mod could easily be made that turns units wearing certain (hacked) armor types into aliens when combat begins, hence allowing you to easily deploy them at will. But there's no way it can be done just by tweaking values in save files, I'm afraid.

- [[User:Bomb Bloke|Bomb Bloke]] 14:45, 6 November 2006 (PST)

== Base Reference ==

As I was tinkering around with some files, namely for my Python XCOM 'editor' I noticed that on some of my soldiers the base reference was set to a crash site in loc.dat. So I'm thinking it got mislabled as a base referense when it should be a current location reference.

I haven't completely verified this yet, but just wanted to throw it out there.
-[[User:Pi Masta|Pi Masta]] 20:13, 6 February 2007 (PST)

== Book of the Dead ==

So after reading [http://www.quartertothree.com/game-talk/showthread.php?t=32835&page=4 this excellent XCOM thread] I was reminded I'd like to have some way of logging the names of who actually died in a mission. You forget the rookies so quickly...and there's all those letters to write. After a while you even forget your heroes, custom names or no. This would keep track of the names for the memorial.

I can see one way of doing this would be to just compare SOLDIER.DAT (or UNITREF.DAT) in two different saved games, pull out the names of the dead soldiers (along with rank, missions, kills info), and append it to a text file. Is a record in SOLDIER.DAT changed when the soldier dies, or what's the best way to determine who has died? Any advice from the experts? I see a bit in UNITREF.DAT but that's only for Battlescape saves, right?

Maybe later this could be linked to the DOS game's batch file, so every transition between Battlescape and Geoscape updates the Book of the Dead. --[[User:JellyfishGreen|JellyfishGreen]] 08:47, 7 May 2008 (PDT)

----

I'm sure that with a little bit of tweaking, Bomb Blokes logger could be programmed to do this. It might be a bit of work, but it's certainly possible. --[[User:Zombie|Zombie]] 09:07, 7 May 2008 (PDT)

----

Yes. SOLDIER.DAT is updated without destroying most of the information (not quite sure what is lost as I don't have a savegame with dead soldiers on hand), think rank is lost (first two bytes reset to FF FF) but soldier value and missions are not lost so that can be recalculated for non-hacked games). The kill count won't include any kills on the mission before being killed.

Hiring a new soldier will overwrite all of this.

--[[User:Zaimoni|Zaimoni]] 13:39, 7 May 2008 (CDT)

----

In a technical sense it's easy enough, the main problem is when the logging should be done...

My first thought would be to do it at the end of combat (by checking [[UNIREF2.DAT]] and [[UNITPOS.DAT (MISSDAT)]]), but the problem with doing that is that if the players save then quit mid-mission (with the intention of resuming later), most of their squad would mistakenly be listed as MIA. It gets even messier should the game crash.

On the other hand, doing the check when the player quits the game entirely is even harder to swing, because how does is know which save games to check?

Perhaps prompting the user whenever combat ends as to whether they wish to log or not? This isn't exactly transparent, but it's the best I can think up. Any thoughts?

- [[User:Bomb Bloke|Bomb Bloke]] 02:27, 8 May 2008 (PDT)

== Offset 6 ==

To test Seb76's theory I wounded 4 soldiers on a mission (close range pistol shots in the Skyranger) and flew straight back to base. From a save file taken as soon as they were back at base, all 4 soldiers showed positive wound recovery time, offset 4 = FF FF, offset 6 = FF FF. So apparently no record of what craft they were in unfortunately. [[User:Spike|Spike]] 14:19, 12 November 2008 (CST)
:This is quite unfortunate indeed because the code is crytal clear: offset 4 is copied into offset 6 before being cleared (offset 0xc is set inbetween but it is a detail) :( Maybe there is a bug in the game and the craft is already cleared elsewhere? What happens when the soldiers recover, do they get back to their original craft? [[User:Seb76|Seb76]] 14:37, 12 November 2008 (CST)

Maybe something changes between tactical.exe and geoscape.exe, I'll go back and check. By the time they get back to base, the wounded soldiers are indistinguishable from other unassigned soldiers, apart from Offset 0xC (wound recovery time). - No, in the tactical save, the offset 4, 6 and 12 values are unchanged from what they were pre-mission. So the update to these fields is done at the end of combat - as you have probably found out. I will check if I'm using XcomUtil, that might be interfering with the files somehow. Also, I checked and recovered soldiers don't get reassigned to a craft, they are assigned to NONE. This does sound like you have discovered the intended behaviour, but it's failing due to a bug. There would be a logical difficulty - if the craft is already full when you try to re-assign a recovered soldier to that craft, how would the game handle that situation? (I made sure I had enough free slots on my craft but still no re-assignment). [[User:Spike|Spike]] 15:07, 12 November 2008 (CST)

Hmm. Even if I hack the craft value (copied from the unwounded soldiers) into offset 6 of the wounded soldiers, they still don't re-assign back to the craft once they are recovered from their wounds. [[User:Spike|Spike]] 15:23, 12 November 2008 (CST)

Oops! It was XcomUtil that was interfering with the behaviour you deduced. Probably Scott Jones did not understand this behaviour? When I remove XcomUtil (actually I used a virgin re-install), I can see the changes you are reporting in Soldier.Dat - offset 6 is set to the craft number, offset 4 is FFFF. I've used different craft to confirm it is the craft number that gets written to offset 6. However, when the soldier recovers from wounds, they are still assigned to NONE - they don't get reassigned to the previous craft. Even with the correct values in offset 4, placed there by the game, there doesn't seem to be any behaviour that uses that data. So it seems like this is a half-implemented feature? [[User:Spike|Spike]] 16:18, 12 November 2008 (CST)
:They probably removed it because it is too error prone: as you mentionned, if the craft is full when the soldier comes back, it must not be reassigned to the ship. Also the ship may no longer exist (the entry could even be reassigned to another craft, which could be fighter only or worst: a UFO). That must be why the feature was not kept. [[User:Seb76|Seb76]] 16:45, 12 November 2008 (CST)

== Offset 64/0x41 Promotion flag ==

This generally flags as 1 if the soldier was last promoted in the last combat.

I was just checking a soldier listing and had a rookie with this field flagged. Does this field get flagged if the soldier was eligible for promotion even though there was no room? -[[User:NKF|NKF]] 08:46, 19 July 2009 (EDT)

== the NAME field ==

I've just been testing with TFTD, and ran the same tests here.

The NAME field is a cstring, or "ASCIIZ" field. Care must be taken not to overwrite the last character of the name with anything but a 0 (NUL) character, otherwise the game will happily continue loading and rendering bytes past that point. Fortunately, the transfer fields (which follow name) are usually 0 as the soldiers are not usually transferring, so those ''usually'' act as a terminating null.

Thus, although one can get away with using that last byte, it's definitely not 'best practice' in any way.

Meh..forgot to sign. ~ [[User:Renegrade|Renegrade]] 07:40, 16 August 2010 (EDT)

Talk:SOLDIER.DAT

2010-08-12T12:35:24Z

Renegrade: New section: the NAME field

Talk:SOLDIER.DAT (TFTD)

2010-08-12T12:18:31Z

Renegrade:

Hi Zombie. I've just checked and the maximum length of an Aquanaut name that can be entered in-game is 19 characters. 20 bytes including a null-terminating byte? It would also be good to hack the name and see if it's possible to display more than 19 characters, I'll try that next. [[User:Spike|Spike]] 14:49, 10 November 2008 (CST)

:Actually you can enter 21 characters within the game. There is room to hex edit the name up to 27 characters (doesn't need to be null terminated, the final 27th character shows up just fine). The name is the reason why EU's and TFTD's file sizes differ (68 vs. 70 bytes). The programmers gave TFTD 2 more characters to play around with. I'm using the Collector's Edition by the way. --[[User:Zombie|Zombie]] 15:46, 10 November 2008 (CST)

Interesting. I'm using the Steam version which is also CE I think. Looks like the character name input in-game is limited to some maximum pixel width, or 21 bytes, whichever is less. E.g. use all capital Ws for the name and you only get to enter 14 bytes. Use digit 1 (narrowest character?) or lower case a and you can enter 21 bytes.

I could hex edit 26 + null and it displayed, but overwrote the next column in the Aquanaut display - probably why there is a pixel width limit. I didn't try non null terminated. That's also interesting as it suggests they may be storing the string length somewhere, which could be one of the Unknown records. [[User:Spike|Spike]] 04:15, 11 November 2008 (CST)

:Ah, I was using lowercase letters to fill the string - that's why I had 21 characters. Apparently the game uses the [[BIGLETS.DAT]] character set for editing soldier names. Each character block is 16x16 pixels, but the game doesn't use whitespace. This limits the max height to something like 13 pixels. For the capital letter W, you can have 14 characters total in the display, and that breaks down to 13 pixels wide for a total string length of 182 pixels. For the capital letter I you can put 21 of them in the display. Each letter is 4 pixels wide for a total width of 84 pixels. The max display width possible without wraparound is 21 large characters (such as W or M) which works out to 273 pixels.

:For the Aquanaut listing screen, it uses the [[SMALLSET.DAT]] character set so things are a little different there. To prevent the name from running into the rank field, the max length is 19 large letters such as W or M. Effective length is around 115 pixels. Surprisingly, the biggest characters in the smallset list is the number sign or the asterisk. Those fill the entire field, and the game actually overwrites part of one character on to the next one so instead of 8 pixels, it breaks down to a little over 6. The programmers should have changed those characters to include a 1-pixel whitespace buffer to prevent overwriting, but maybe that would have made the character look strange. Eh, whatever. --[[User:Zombie|Zombie]] 21:44, 11 November 2008 (CST)

Just a little note here on null terminated strings (c-strings or "ASCIIZ") -- while you can handle fixed width strings in C with custom functions or some of the more exotic uses of v/s/printf, it's generally not used. I'd like to warn people that name[27] is followed by bravery_improvement, which is likely zero on most soldiers.

As a test, I filled in a soldier's name with lowercase 'i', as it's nice and narrow, and then 'b' after the 27th byte (it was originally 'a' and 'b' but it was hard to see the results due to font size). My soldier ended up with 720 bravery, but the name continued. I then continued on, filling in any zero bytes, and the soldier became even more screwy, with an ever increasing name length.

I'd STRONGLY recommend limiting string usage to a proper char string[27] length -- that is, null terminate the string at the 27th character, ie, string[26]=0. Assuming that the byte(s) at the end ARE part of the string, and not some stat which is doing something strange. Like, an unknown 'luck' stat or something. ~ [[User:Renegrade|Renegrade]] 08:18, 12 August 2010 (EDT)

User:Renegrade

2010-08-10T11:19:36Z

Renegrade: /* Random Z-Com thoughts */

Just an old DOS/Amiga programmer from Canada who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.

== Various Utilities ==

I've made some quick and dirty utilities that I'll be posting up on my homepage soon, after I make them less "dirty". That is, properly documented and with proper checks and neatly formatted code.

=== dirt.exe ===

dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It fixes the 'paying for dirt' bug, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>

=== Paperdoll Improvement Project ===

==== Enemy Unknown ====

I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file.

To do:
* Improve Color Indexing algorithm.
* Clean up code.
* Make some art~

Done:
* Reading BMPs (this has been improved somewhat)
* Color Indexing (may need improvement)
* Writing out Uncompressed SPK
* Compressing SPKs
* Merge sub-programs

I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

I'll be providing the executables, with source, under BSD-style licensing, so that people can create their own backgrounds from whatever BMPs they can create (hint: MSPaint can create BMPs from any cut-paste operation).

The current version supports OS/2 V1 and Win V3 BMPs only, but most things use Win V3 anyways (including MSPaint for XP, and Paint for Vista/7).

==== TFTD ====

I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.

=== NameStat ===

It's a little program like the StatString one. This one ranks the agents based on a scaling grade in terms of reaction and aiming, and optionally gives psi ability data. Agents are ranked from 0-9 (with a special 'E' symbol for ones who Exceed the caps), with 0 meaning someone with the lowest possible recruit score, and 9/E being a maximum-skill agent.

=== UnitScan ===

A little cheat program to scan a battlescape save to show what's going on. I use it to find that last alien or two who's hiding in some obscure corner of the map. Especially useful for TFTD and it's complicated maps.

=== Mission Item Recovery Enhancement ===

The MIRE system - a simple DOS program that is inserted between the tactical and geoscape executables which does more intelligent recovery of ammo. It's still in progress, but once it's done, it will sum up all the various ammo types left in the game after a tactical mission, and "pack" them into the right number of clips.

Example 1:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 8 of them fire 1 shot (8 bullets)
** 4 of them fire 2 shots (8 more bullets)

That makes 8 clips with 19 shots left, and 4 clips with 18 shots, for a total of 152+72 = 224/240 rifle bullets. While only 16 bullets have been spent, the game would delete all 12 clips. Instead, I propose to fill up 11 of the clips to full bullet value, and then deleting the one partially filled clip.

Ideally the extra 4 bullets lost would be stored somewhere, but even if they can't be, 4 bullets lost is a lot better than 240 bullets lost, especially if we're talking Elerium based bullets. Also, the production cost could be refunded for any 'surplus' bullets, possibly.

Example 2:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 5 of them fire 2 shots (10 bullets)
** 3 of them fire 5 shots (15 more)
** 2 of them fire 12 shots (24 more)
** 1 of them empties an entire clip (20 more)

Sum: 69 shot of 240. 171/240 bullets left. After compacting, there would be 3 entirely empty clips (discarded), plus one clip with 9 shots left (also discarded), leaving 8 clips of 12.

A possible alteration of this design would be to save the last clip if it was half full or better, discard otherwise. Over time, that should average out to being the right number of bullets saved, roughly.

The other possibility, refunding, would give back some cash value for each bullet, depending on it's type. A rifle bullet, for instance, is $10 to buy, or $7.50 to sell. (200/20 or 150/20 respectively). This isn't quite as good as getting a fractional elerium unit back, but better than nothing.

=== Z-Com ===

One day, time permitting, I'd like to write an X-Com emulator (I've code-named this 'Z-Com' after Sluggy Freelance's Z-Com: UFO Defensiveness gag), which would re-create as much of the original X-COM feeling, but with the following enhancements:

* 3D accelerated engine (no more lag on the upper levels of Battleships!)
* Enhanced art, but with the same ''style'' as the original
* Higher resolution graphics (less jaggies!)
* Better stores/soldiers/ammo management capabilities
* Better compatibility (I'd like to point out that one of my oldest DirectX games, written for Pentium MMX/DirectX 3-5, runs just fine on my Windows 7/64 system. I don't see how these professional developers can mess things up like DirectX surface stride)

Unfortunately it would involve a lot of work, and I may never have enough free time to do it.

If it did happen though, it would likely happen in stages:

# A drop-in executable that would load/save using existing XCOM files/savegames/etc, using the original graphics.
# Enhancements to above (MIRE, XCU* style soldier kits, except maybe more permanent)
# Specification for user-created advanced graphics files (3D models instead of sprites, 24-bit backgrounds, etc)
# Implementation of user-created graphics sets

The final version would run entirely on it's own without any original XCOM data.

Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

==== Random Z-Com thoughts ====

(things to consider implementing in Z-Com)

* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:
# prohibit access to the inventory entirely. Skip over it when toggling through troops.
# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

* Show the current AND expected stock in the Buy screen; ie, including transfers 'in flight' to that base. Could work one of two ways:
# Show it as non-summed items. Ex: Rifle Clip 14 (20) --> 14 rifle clips at the base, 20 en route via transfers from purchasing or other bases.
# Show it as summed items. Ex: Rifle Clip 14 (34) --> 14 rifle clips at the base, with 20 enroute = a total of 34. I tend to favor this approach as it eliminates the possibility of faults with mental math.

* Fix the manufacturing bug. I actually have a hard time imagining the code that causes it, yet still allows proper rollover of hours. If something takes 5 engineering hours, and there's 12 engineers working on it, it should produce ''two'' on the hour, and save 2 engineer hours for the next '''anything''' (including new projects), with an ideal design.

* Also, the manufacturing page suggests that resources are gathered too quickly and/or not returned properly when cancelling. The best design for that would be that every time a new item in a batch is initiated, the cash and items required are extracted from the base stock, but then 'stored' in the manufacturing data. If that item is cancelled, then that stored cash/item list can be restored to the base's main stock.

User:Renegrade

2010-08-10T11:13:44Z

Renegrade: /* Random Z-Com thoughts */

Just an old DOS/Amiga programmer from Canada who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.

== Various Utilities ==

I've made some quick and dirty utilities that I'll be posting up on my homepage soon, after I make them less "dirty". That is, properly documented and with proper checks and neatly formatted code.

=== dirt.exe ===

dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It fixes the 'paying for dirt' bug, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>

=== Paperdoll Improvement Project ===

==== Enemy Unknown ====

I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file.

To do:
* Improve Color Indexing algorithm.
* Clean up code.
* Make some art~

Done:
* Reading BMPs (this has been improved somewhat)
* Color Indexing (may need improvement)
* Writing out Uncompressed SPK
* Compressing SPKs
* Merge sub-programs

I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

I'll be providing the executables, with source, under BSD-style licensing, so that people can create their own backgrounds from whatever BMPs they can create (hint: MSPaint can create BMPs from any cut-paste operation).

The current version supports OS/2 V1 and Win V3 BMPs only, but most things use Win V3 anyways (including MSPaint for XP, and Paint for Vista/7).

==== TFTD ====

I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.

=== NameStat ===

It's a little program like the StatString one. This one ranks the agents based on a scaling grade in terms of reaction and aiming, and optionally gives psi ability data. Agents are ranked from 0-9 (with a special 'E' symbol for ones who Exceed the caps), with 0 meaning someone with the lowest possible recruit score, and 9/E being a maximum-skill agent.

=== UnitScan ===

A little cheat program to scan a battlescape save to show what's going on. I use it to find that last alien or two who's hiding in some obscure corner of the map. Especially useful for TFTD and it's complicated maps.

=== Mission Item Recovery Enhancement ===

The MIRE system - a simple DOS program that is inserted between the tactical and geoscape executables which does more intelligent recovery of ammo. It's still in progress, but once it's done, it will sum up all the various ammo types left in the game after a tactical mission, and "pack" them into the right number of clips.

Example 1:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 8 of them fire 1 shot (8 bullets)
** 4 of them fire 2 shots (8 more bullets)

That makes 8 clips with 19 shots left, and 4 clips with 18 shots, for a total of 152+72 = 224/240 rifle bullets. While only 16 bullets have been spent, the game would delete all 12 clips. Instead, I propose to fill up 11 of the clips to full bullet value, and then deleting the one partially filled clip.

Ideally the extra 4 bullets lost would be stored somewhere, but even if they can't be, 4 bullets lost is a lot better than 240 bullets lost, especially if we're talking Elerium based bullets. Also, the production cost could be refunded for any 'surplus' bullets, possibly.

Example 2:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 5 of them fire 2 shots (10 bullets)
** 3 of them fire 5 shots (15 more)
** 2 of them fire 12 shots (24 more)
** 1 of them empties an entire clip (20 more)

Sum: 69 shot of 240. 171/240 bullets left. After compacting, there would be 3 entirely empty clips (discarded), plus one clip with 9 shots left (also discarded), leaving 8 clips of 12.

A possible alteration of this design would be to save the last clip if it was half full or better, discard otherwise. Over time, that should average out to being the right number of bullets saved, roughly.

The other possibility, refunding, would give back some cash value for each bullet, depending on it's type. A rifle bullet, for instance, is $10 to buy, or $7.50 to sell. (200/20 or 150/20 respectively). This isn't quite as good as getting a fractional elerium unit back, but better than nothing.

=== Z-Com ===

One day, time permitting, I'd like to write an X-Com emulator (I've code-named this 'Z-Com' after Sluggy Freelance's Z-Com: UFO Defensiveness gag), which would re-create as much of the original X-COM feeling, but with the following enhancements:

* 3D accelerated engine (no more lag on the upper levels of Battleships!)
* Enhanced art, but with the same ''style'' as the original
* Higher resolution graphics (less jaggies!)
* Better stores/soldiers/ammo management capabilities
* Better compatibility (I'd like to point out that one of my oldest DirectX games, written for Pentium MMX/DirectX 3-5, runs just fine on my Windows 7/64 system. I don't see how these professional developers can mess things up like DirectX surface stride)

Unfortunately it would involve a lot of work, and I may never have enough free time to do it.

If it did happen though, it would likely happen in stages:

# A drop-in executable that would load/save using existing XCOM files/savegames/etc, using the original graphics.
# Enhancements to above (MIRE, XCU* style soldier kits, except maybe more permanent)
# Specification for user-created advanced graphics files (3D models instead of sprites, 24-bit backgrounds, etc)
# Implementation of user-created graphics sets

The final version would run entirely on it's own without any original XCOM data.

Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

==== Random Z-Com thoughts ====

(things to consider implementing in Z-Com)

* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:
# prohibit access to the inventory entirely. Skip over it when toggling through troops.
# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

* Show the current AND expected stock in the Buy screen; ie, including transfers 'in flight' to that base. Could work one of two ways:
# Show it as non-summed items. Ex: Rifle Clip 14 (20) --> 14 rifle clips at the base, 20 en route via transfers from purchasing or other bases.
# Show it as summed items. Ex: Rifle Clip 14 (34) --> 14 rifle clips at the base, with 20 enroute = a total of 34. I tend to favor this approach as it eliminates the possibility of faults with mental math.

Talk:OBPOS.DAT

2010-08-08T02:15:10Z

Renegrade: New section: Record offsets 6 and 7

Talk:Manufacturing Profitability

2010-08-07T22:23:50Z

Renegrade: New section: Salary / Hourly

User talk:Renegrade

2010-08-07T15:43:23Z

Renegrade:

Hiya, a few notes you might find of interest:

* Notes on how the game image compression formats work can be found [[Image Formats|here]]. Note that just because a file has a certain extension, doesn't ''always'' mean it uses the associated format: though TFTD inventories do use BDY.
* TFTD's battlescape [[PALETTES.DAT|palettes]] are embedded into the game executable somewhere. You can find pre-dumped versions of them in my [http://www.strategycore.co.uk/files/index.php?dlid=686 toolkit], in the file "Pal.java". There's lots of other bits of sample code in the kit you might find interesting, though I'd consider it messy even by the standards of those who like high-level languages. ;)
* New attempts to "remake" UFO are forever popping up. If you wish to try one, I'd recommend joining a project already under way. Two of the more recent ones: [http://ufotts.ninex.info/ UFO: The Two Sides] is a closed-source example (dunno if there's any openings for recruits), it cleans up many of the graphics nicely. There's also [http://openxcom.ninex.info OpenXcom], which as the name implies, is open-source. The most ''advanced'' project, by far, would be [http://ufo2000.sourceforge.net/ UFO2000] - though that's aimed squarely at the tactical aspects of the original and little else.
* Regarding alien/HWP inventories, HWPs require code editing to access, and aliens can't be accessed at all in TFTD. Alien inventory screens for UFO are included in my toolkit (based on their UFOpedia images).

- [[User:Bomb Bloke|Bomb Bloke]] 22:35, 6 August 2010 (EDT)

Hi, Bomb Bloke! Thanks for your input! I'll reply point by point below:

* I've already been all over [[Image Formats]]. It is indeed very helpful. Regarding extensions being wrong - I can understand that. I can't begin to count the times my own tools have warned me "This is not a BMP" when I save something from MSPAINT and forget to change the dropdown from whatever the source file was. (mspaint isn't quite smart enough to realize that 'image.bmp' shouldn't be a PNG image anymore)

* I'm going through your toolkit right now, and I like what I see, it's very cool. You probably have enough data format handling routines to handle something like Z-COM stage one right now. (Java-Com?)

* About those other projects - most of them are not being done in my favorite platform - OpenGL / C99. The Two Sides is a single man coding project from what I read (I haven't seen it before though); OpenXCom is more in line with what you suggested, but it's SDL/C++... Also, I tend to program as a personal challenge, with useful utilities, games, or such resulting as a happy side effect rather than being the main goal. X-COM: Ufo Defense/Enemy Unknown is by far my favorite tile-based, isometric game, and having never written anything like that, it would be something of a learning experience.

* I'm also looking through the UFOGRAPH folder with the images you mentioned (a quick three line one-off shell script turned 'em all into BMPs so windows won't 'durr' at them) -- they're very nice, using the UFOpedia entry images for the paperdolls is very clever, and looks pretty good. I'd like to know how you managed to get X-COM to load those, though. XComUtil, I guess? Anyhow, my own plans regarding inventories had to do with Z-Com rather than X-Com directly. x86 assembly makes my skin itch, I come from a 68K background (I never played the PC version of X-Com prior to it showing up on gog.com -- my original X-Com experience is Amiga-based), so I'd never be able to mod the original PC X-Com without a serious amount of allergy medication.

FYI though - I've already completed a rough draft version of my SPK conversion suite. It works against 24-bit BMPs, although some of the sub-tools can extract palettes from .PNG files that DOSBOX makes. It can import any image from any source (so long as it's 320x200, I didn't bother making it directly scalable, although it wouldn't be hard to fix that up)

~ [[User:Renegrade|Renegrade]] 11:43, 7 August 2010 (EDT)

User:Renegrade

2010-08-06T09:25:21Z

Renegrade: /* Enemy Unknown */

Just an old DOS/Amiga programmer from Canada who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.

== Various Utilities ==

I've made some quick and dirty utilities that I'll be posting up on my homepage soon, after I make them less "dirty". That is, properly documented and with proper checks and neatly formatted code.

=== dirt.exe ===

dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It fixes the 'paying for dirt' bug, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>

=== Paperdoll Improvement Project ===

==== Enemy Unknown ====

I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file.

To do:
* Improve Color Indexing algorithm.
* Clean up code.
* Make some art~

Done:
* Reading BMPs (this has been improved somewhat)
* Color Indexing (may need improvement)
* Writing out Uncompressed SPK
* Compressing SPKs
* Merge sub-programs

I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

I'll be providing the executables, with source, under BSD-style licensing, so that people can create their own backgrounds from whatever BMPs they can create (hint: MSPaint can create BMPs from any cut-paste operation).

The current version supports OS/2 V1 and Win V3 BMPs only, but most things use Win V3 anyways (including MSPaint for XP, and Paint for Vista/7).

==== TFTD ====

I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.

=== NameStat ===

It's a little program like the StatString one. This one ranks the agents based on a scaling grade in terms of reaction and aiming, and optionally gives psi ability data. Agents are ranked from 0-9 (with a special 'E' symbol for ones who Exceed the caps), with 0 meaning someone with the lowest possible recruit score, and 9/E being a maximum-skill agent.

=== UnitScan ===

A little cheat program to scan a battlescape save to show what's going on. I use it to find that last alien or two who's hiding in some obscure corner of the map. Especially useful for TFTD and it's complicated maps.

=== Mission Item Recovery Enhancement ===

The MIRE system - a simple DOS program that is inserted between the tactical and geoscape executables which does more intelligent recovery of ammo. It's still in progress, but once it's done, it will sum up all the various ammo types left in the game after a tactical mission, and "pack" them into the right number of clips.

Example 1:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 8 of them fire 1 shot (8 bullets)
** 4 of them fire 2 shots (8 more bullets)

That makes 8 clips with 19 shots left, and 4 clips with 18 shots, for a total of 152+72 = 224/240 rifle bullets. While only 16 bullets have been spent, the game would delete all 12 clips. Instead, I propose to fill up 11 of the clips to full bullet value, and then deleting the one partially filled clip.

Ideally the extra 4 bullets lost would be stored somewhere, but even if they can't be, 4 bullets lost is a lot better than 240 bullets lost, especially if we're talking Elerium based bullets. Also, the production cost could be refunded for any 'surplus' bullets, possibly.

Example 2:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 5 of them fire 2 shots (10 bullets)
** 3 of them fire 5 shots (15 more)
** 2 of them fire 12 shots (24 more)
** 1 of them empties an entire clip (20 more)

Sum: 69 shot of 240. 171/240 bullets left. After compacting, there would be 3 entirely empty clips (discarded), plus one clip with 9 shots left (also discarded), leaving 8 clips of 12.

A possible alteration of this design would be to save the last clip if it was half full or better, discard otherwise. Over time, that should average out to being the right number of bullets saved, roughly.

The other possibility, refunding, would give back some cash value for each bullet, depending on it's type. A rifle bullet, for instance, is $10 to buy, or $7.50 to sell. (200/20 or 150/20 respectively). This isn't quite as good as getting a fractional elerium unit back, but better than nothing.

=== Z-Com ===

One day, time permitting, I'd like to write an X-Com emulator (I've code-named this 'Z-Com' after Sluggy Freelance's Z-Com: UFO Defensiveness gag), which would re-create as much of the original X-COM feeling, but with the following enhancements:

* 3D accelerated engine (no more lag on the upper levels of Battleships!)
* Enhanced art, but with the same ''style'' as the original
* Higher resolution graphics (less jaggies!)
* Better stores/soldiers/ammo management capabilities
* Better compatibility (I'd like to point out that one of my oldest DirectX games, written for Pentium MMX/DirectX 3-5, runs just fine on my Windows 7/64 system. I don't see how these professional developers can mess things up like DirectX surface stride)

Unfortunately it would involve a lot of work, and I may never have enough free time to do it.

If it did happen though, it would likely happen in stages:

# A drop-in executable that would load/save using existing XCOM files/savegames/etc, using the original graphics.
# Enhancements to above (MIRE, XCU* style soldier kits, except maybe more permanent)
# Specification for user-created advanced graphics files (3D models instead of sprites, 24-bit backgrounds, etc)
# Implementation of user-created graphics sets

The final version would run entirely on it's own without any original XCOM data.

Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

==== Random Z-Com thoughts ====

* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:
# prohibit access to the inventory entirely. Skip over it when toggling through troops.
# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

User:Renegrade

2010-08-05T07:54:47Z

Renegrade: /* Enemy Unknown */

Just an old DOS/Amiga programmer from Canada who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.

== Various Utilities ==

I've made some quick and dirty utilities that I'll be posting up on my homepage soon, after I make them less "dirty". That is, properly documented and with proper checks and neatly formatted code.

=== dirt.exe ===

dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It fixes the 'paying for dirt' bug, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>

=== Paperdoll Improvement Project ===

==== Enemy Unknown ====

I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file.

To do:
* Improve Color Indexing algorithm.
* Clean up code, merge sub-programs
* Make some art~

Done:
* Reading BMPs (this has been improved somewhat)
* Color Indexing (may need improvement)
* Writing out Uncompressed SPK
* Compressing SPKs

I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

I'll be providing the executables, with source, under BSD-style licensing, so that people can create their own backgrounds from whatever BMPs they can create (hint: MSPaint can create BMPs from any cut-paste operation).

The current version supports OS/2 V1 and Win V3 BMPs only, but most things use Win V3 anyways (including MSPaint for XP, and Paint for Vista/7).

==== TFTD ====

I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.

=== NameStat ===

It's a little program like the StatString one. This one ranks the agents based on a scaling grade in terms of reaction and aiming, and optionally gives psi ability data. Agents are ranked from 0-9 (with a special 'E' symbol for ones who Exceed the caps), with 0 meaning someone with the lowest possible recruit score, and 9/E being a maximum-skill agent.

=== UnitScan ===

A little cheat program to scan a battlescape save to show what's going on. I use it to find that last alien or two who's hiding in some obscure corner of the map. Especially useful for TFTD and it's complicated maps.

=== Mission Item Recovery Enhancement ===

The MIRE system - a simple DOS program that is inserted between the tactical and geoscape executables which does more intelligent recovery of ammo. It's still in progress, but once it's done, it will sum up all the various ammo types left in the game after a tactical mission, and "pack" them into the right number of clips.

Example 1:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 8 of them fire 1 shot (8 bullets)
** 4 of them fire 2 shots (8 more bullets)

That makes 8 clips with 19 shots left, and 4 clips with 18 shots, for a total of 152+72 = 224/240 rifle bullets. While only 16 bullets have been spent, the game would delete all 12 clips. Instead, I propose to fill up 11 of the clips to full bullet value, and then deleting the one partially filled clip.

Ideally the extra 4 bullets lost would be stored somewhere, but even if they can't be, 4 bullets lost is a lot better than 240 bullets lost, especially if we're talking Elerium based bullets. Also, the production cost could be refunded for any 'surplus' bullets, possibly.

Example 2:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 5 of them fire 2 shots (10 bullets)
** 3 of them fire 5 shots (15 more)
** 2 of them fire 12 shots (24 more)
** 1 of them empties an entire clip (20 more)

Sum: 69 shot of 240. 171/240 bullets left. After compacting, there would be 3 entirely empty clips (discarded), plus one clip with 9 shots left (also discarded), leaving 8 clips of 12.

A possible alteration of this design would be to save the last clip if it was half full or better, discard otherwise. Over time, that should average out to being the right number of bullets saved, roughly.

The other possibility, refunding, would give back some cash value for each bullet, depending on it's type. A rifle bullet, for instance, is $10 to buy, or $7.50 to sell. (200/20 or 150/20 respectively). This isn't quite as good as getting a fractional elerium unit back, but better than nothing.

=== Z-Com ===

One day, time permitting, I'd like to write an X-Com emulator (I've code-named this 'Z-Com' after Sluggy Freelance's Z-Com: UFO Defensiveness gag), which would re-create as much of the original X-COM feeling, but with the following enhancements:

* 3D accelerated engine (no more lag on the upper levels of Battleships!)
* Enhanced art, but with the same ''style'' as the original
* Higher resolution graphics (less jaggies!)
* Better stores/soldiers/ammo management capabilities
* Better compatibility (I'd like to point out that one of my oldest DirectX games, written for Pentium MMX/DirectX 3-5, runs just fine on my Windows 7/64 system. I don't see how these professional developers can mess things up like DirectX surface stride)

Unfortunately it would involve a lot of work, and I may never have enough free time to do it.

If it did happen though, it would likely happen in stages:

# A drop-in executable that would load/save using existing XCOM files/savegames/etc, using the original graphics.
# Enhancements to above (MIRE, XCU* style soldier kits, except maybe more permanent)
# Specification for user-created advanced graphics files (3D models instead of sprites, 24-bit backgrounds, etc)
# Implementation of user-created graphics sets

The final version would run entirely on it's own without any original XCOM data.

Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

==== Random Z-Com thoughts ====

* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:
# prohibit access to the inventory entirely. Skip over it when toggling through troops.
# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

User:Renegrade

2010-08-04T09:15:11Z

Renegrade: /* Various Utilities */

Just an old DOS/Amiga programmer from Canada who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.

== Various Utilities ==

I've made some quick and dirty utilities that I'll be posting up on my homepage soon, after I make them less "dirty". That is, properly documented and with proper checks and neatly formatted code.

=== dirt.exe ===

dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It fixes the 'paying for dirt' bug, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>

=== Paperdoll Improvement Project ===

==== Enemy Unknown ====

I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file.

To do:
* Improve Color Indexing algorithm.
* Clean up code, merge sub-programs
* Make some art~

Done:
* Reading BMPs
* Color Indexing (may need improvement)
* Writing out Uncompressed SPK
* Compressing SPKs

I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

I'll be providing the executables, with source, under BSD-style licensing, so that people can create their own backgrounds from whatever BMPs they can create (hint: MSPaint can create BMPs from any cut-paste operation).

The current version supports OS/2 V1 and Win V3 BMPs only, but most things use Win V3 anyways (including MSPaint for XP, and Paint for Vista/7).

==== TFTD ====

I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.

=== NameStat ===

It's a little program like the StatString one. This one ranks the agents based on a scaling grade in terms of reaction and aiming, and optionally gives psi ability data. Agents are ranked from 0-9 (with a special 'E' symbol for ones who Exceed the caps), with 0 meaning someone with the lowest possible recruit score, and 9/E being a maximum-skill agent.

=== UnitScan ===

A little cheat program to scan a battlescape save to show what's going on. I use it to find that last alien or two who's hiding in some obscure corner of the map. Especially useful for TFTD and it's complicated maps.

=== Mission Item Recovery Enhancement ===

The MIRE system - a simple DOS program that is inserted between the tactical and geoscape executables which does more intelligent recovery of ammo. It's still in progress, but once it's done, it will sum up all the various ammo types left in the game after a tactical mission, and "pack" them into the right number of clips.

Example 1:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 8 of them fire 1 shot (8 bullets)
** 4 of them fire 2 shots (8 more bullets)

That makes 8 clips with 19 shots left, and 4 clips with 18 shots, for a total of 152+72 = 224/240 rifle bullets. While only 16 bullets have been spent, the game would delete all 12 clips. Instead, I propose to fill up 11 of the clips to full bullet value, and then deleting the one partially filled clip.

Ideally the extra 4 bullets lost would be stored somewhere, but even if they can't be, 4 bullets lost is a lot better than 240 bullets lost, especially if we're talking Elerium based bullets. Also, the production cost could be refunded for any 'surplus' bullets, possibly.

Example 2:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 5 of them fire 2 shots (10 bullets)
** 3 of them fire 5 shots (15 more)
** 2 of them fire 12 shots (24 more)
** 1 of them empties an entire clip (20 more)

Sum: 69 shot of 240. 171/240 bullets left. After compacting, there would be 3 entirely empty clips (discarded), plus one clip with 9 shots left (also discarded), leaving 8 clips of 12.

A possible alteration of this design would be to save the last clip if it was half full or better, discard otherwise. Over time, that should average out to being the right number of bullets saved, roughly.

The other possibility, refunding, would give back some cash value for each bullet, depending on it's type. A rifle bullet, for instance, is $10 to buy, or $7.50 to sell. (200/20 or 150/20 respectively). This isn't quite as good as getting a fractional elerium unit back, but better than nothing.

=== Z-Com ===

One day, time permitting, I'd like to write an X-Com emulator (I've code-named this 'Z-Com' after Sluggy Freelance's Z-Com: UFO Defensiveness gag), which would re-create as much of the original X-COM feeling, but with the following enhancements:

* 3D accelerated engine (no more lag on the upper levels of Battleships!)
* Enhanced art, but with the same ''style'' as the original
* Higher resolution graphics (less jaggies!)
* Better stores/soldiers/ammo management capabilities
* Better compatibility (I'd like to point out that one of my oldest DirectX games, written for Pentium MMX/DirectX 3-5, runs just fine on my Windows 7/64 system. I don't see how these professional developers can mess things up like DirectX surface stride)

Unfortunately it would involve a lot of work, and I may never have enough free time to do it.

If it did happen though, it would likely happen in stages:

# A drop-in executable that would load/save using existing XCOM files/savegames/etc, using the original graphics.
# Enhancements to above (MIRE, XCU* style soldier kits, except maybe more permanent)
# Specification for user-created advanced graphics files (3D models instead of sprites, 24-bit backgrounds, etc)
# Implementation of user-created graphics sets

The final version would run entirely on it's own without any original XCOM data.

Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

==== Random Z-Com thoughts ====

* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:
# prohibit access to the inventory entirely. Skip over it when toggling through troops.
# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

User:Renegrade

2010-08-04T05:26:48Z

Renegrade: /* Z-Com */

Just an old DOS/Amiga programmer from Canada who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.

== Various Utilities ==

I've made some quick and dirty utilities that I'll be posting up on my homepage soon, after I make them less "dirty". That is, properly documented and with proper checks and neatly formatted code.

=== dirt.exe ===

dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It does the same thing, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>

=== Paperdoll Improvement Project ===

==== Enemy Unknown ====

I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file. (Current progress: reading BMPs, color indexing, and writing out an SPK format file is done. Todo: compress the SPK with RLE)

I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

I'll be providing the executables, with source, under BSD-style licensing, so that people can create their own backgrounds from whatever BMPs they can create (hint: MSPaint can create BMPs from any cut-paste operation).

The current version supports OS/2 V1 and Win V3 BMPs only, but most things use Win V3 anyways (including MSPaint for XP, and Paint for Vista/7).

==== TFTD ====

I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.

=== Mission Item Recovery Enhancement ===

The MIRE system - a simple DOS program that is inserted between the tactical and geoscape executables which does more intelligent recovery of ammo. It's still in progress, but once it's done, it will sum up all the various ammo types left in the game after a tactical mission, and "pack" them into the right number of clips.

Example 1:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 8 of them fire 1 shot (8 bullets)
** 4 of them fire 2 shots (8 more bullets)

That makes 8 clips with 19 shots left, and 4 clips with 18 shots, for a total of 152+72 = 224/240 rifle bullets. While only 16 bullets have been spent, the game would delete all 12 clips. Instead, I propose to fill up 11 of the clips to full bullet value, and then deleting the one partially filled clip.

Ideally the extra 4 bullets lost would be stored somewhere, but even if they can't be, 4 bullets lost is a lot better than 240 bullets lost, especially if we're talking Elerium based bullets. Also, the production cost could be refunded for any 'surplus' bullets, possibly.

Example 2:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 5 of them fire 2 shots (10 bullets)
** 3 of them fire 5 shots (15 more)
** 2 of them fire 12 shots (24 more)
** 1 of them empties an entire clip (20 more)

Sum: 69 shot of 240. 171/240 bullets left. After compacting, there would be 3 entirely empty clips (discarded), plus one clip with 9 shots left (also discarded), leaving 8 clips of 12.

A possible alteration of this design would be to save the last clip if it was half full or better, discard otherwise. Over time, that should average out to being the right number of bullets saved, roughly.

The other possibility, refunding, would give back some cash value for each bullet, depending on it's type. A rifle bullet, for instance, is $10 to buy, or $7.50 to sell. (200/20 or 150/20 respectively). This isn't quite as good as getting a fractional elerium unit back, but better than nothing.

=== Z-Com ===

One day, time permitting, I'd like to write an X-Com emulator (I've code-named this 'Z-Com' after Sluggy Freelance's Z-Com: UFO Defensiveness gag), which would re-create as much of the original X-COM feeling, but with the following enhancements:

* 3D accelerated engine (no more lag on the upper levels of Battleships!)
* Enhanced art, but with the same ''style'' as the original
* Higher resolution graphics (less jaggies!)
* Better stores/soldiers/ammo management capabilities
* Better compatibility (I'd like to point out that one of my oldest DirectX games, written for Pentium MMX/DirectX 3-5, runs just fine on my Windows 7/64 system. I don't see how these professional developers can mess things up like DirectX surface stride)

Unfortunately it would involve a lot of work, and I may never have enough free time to do it.

If it did happen though, it would likely happen in stages:

# A drop-in executable that would load/save using existing XCOM files/savegames/etc, using the original graphics.
# Enhancements to above (MIRE, XCU* style soldier kits, except maybe more permanent)
# Specification for user-created advanced graphics files (3D models instead of sprites, 24-bit backgrounds, etc)
# Implementation of user-created graphics sets

The final version would run entirely on it's own without any original XCOM data.

Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

==== Random Z-Com thoughts ====

* The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:
# prohibit access to the inventory entirely. Skip over it when toggling through troops.
# allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

User:Renegrade

2010-08-04T05:23:24Z

Renegrade:

Just an old DOS/Amiga programmer from Canada who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.

== Various Utilities ==

I've made some quick and dirty utilities that I'll be posting up on my homepage soon, after I make them less "dirty". That is, properly documented and with proper checks and neatly formatted code.

=== dirt.exe ===

dirt.exe is an executable (w/included C source) based on Spike's BaseFixer Python script. It does the same thing, only it doesn't require a python environment to be installed. The C runtime is needed (rants about Microsoft and their poor understanding of ABIs needs it's own dedicated ''wiki''), but it's usually present anyways. I might see about compiling it statically, so that the CRT isn't needed at all.

<insert additional rant about the good old days and how Amigas could actually run C programs ''without'' the runtime environment by directly calling the necessary system functions which were actually usable unlike those found in other modern systems blahblahblah>

=== Paperdoll Improvement Project ===

==== Enemy Unknown ====

I consider the built-in paper doll artwork in XCOM to be "acceptable", but I'm drafting up utilities that could take a 24-bit BMP file create a replacement MAN_XXX.SPK file, by color-matching the BMP, compressing with the RLE encoding that SPKs use, and then writing out a .SPK formatted file. (Current progress: reading BMPs, color indexing, and writing out an SPK format file is done. Todo: compress the SPK with RLE)

I'd love to commission Niklas Jansson ([http://www.itchstudios.com/psg/rebelsquad/rebelsquad.htm#art Examples]) to this end.

I'll be providing the executables, with source, under BSD-style licensing, so that people can create their own backgrounds from whatever BMPs they can create (hint: MSPaint can create BMPs from any cut-paste operation).

The current version supports OS/2 V1 and Win V3 BMPs only, but most things use Win V3 anyways (including MSPaint for XP, and Paint for Vista/7).

==== TFTD ====

I think the TFTD paperdolls are ebil-looking, so they're next. My preliminary research here indicates that it's a different file format, with a different palette, so a new utility will be needed. This should be fairly straightforward to do, though. The only downside might be that my distaste of the TFTD paperdolls might be a palette issue rather than an art issue, and any image so converted might befall the same curse.

=== Mission Item Recovery Enhancement ===

The MIRE system - a simple DOS program that is inserted between the tactical and geoscape executables which does more intelligent recovery of ammo. It's still in progress, but once it's done, it will sum up all the various ammo types left in the game after a tactical mission, and "pack" them into the right number of clips.

Example 1:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 8 of them fire 1 shot (8 bullets)
** 4 of them fire 2 shots (8 more bullets)

That makes 8 clips with 19 shots left, and 4 clips with 18 shots, for a total of 152+72 = 224/240 rifle bullets. While only 16 bullets have been spent, the game would delete all 12 clips. Instead, I propose to fill up 11 of the clips to full bullet value, and then deleting the one partially filled clip.

Ideally the extra 4 bullets lost would be stored somewhere, but even if they can't be, 4 bullets lost is a lot better than 240 bullets lost, especially if we're talking Elerium based bullets. Also, the production cost could be refunded for any 'surplus' bullets, possibly.

Example 2:
* 12 soldiers with rifles, with only the one loaded clip. (20 rounds/clip)
** 5 of them fire 2 shots (10 bullets)
** 3 of them fire 5 shots (15 more)
** 2 of them fire 12 shots (24 more)
** 1 of them empties an entire clip (20 more)

Sum: 69 shot of 240. 171/240 bullets left. After compacting, there would be 3 entirely empty clips (discarded), plus one clip with 9 shots left (also discarded), leaving 8 clips of 12.

A possible alteration of this design would be to save the last clip if it was half full or better, discard otherwise. Over time, that should average out to being the right number of bullets saved, roughly.

The other possibility, refunding, would give back some cash value for each bullet, depending on it's type. A rifle bullet, for instance, is $10 to buy, or $7.50 to sell. (200/20 or 150/20 respectively). This isn't quite as good as getting a fractional elerium unit back, but better than nothing.

=== Z-Com ===

One day, time permitting, I'd like to write an X-Com emulator (I've code-named this 'Z-Com' after Sluggy Freelance's Z-Com: UFO Defensiveness gag), which would re-create as much of the original X-COM feeling, but with the following enhancements:

* 3D accelerated engine (no more lag on the upper levels of Battleships!)
* Enhanced art, but with the same ''style'' as the original
* Higher resolution graphics (less jaggies!)
* Better stores/soldiers/ammo management capabilities
* Better compatibility (I'd like to point out that one of my oldest DirectX games, written for Pentium MMX/DirectX 3-5, runs just fine on my Windows 7/64 system. I don't see how these professional developers can mess things up like DirectX surface stride)

Unfortunately it would involve a lot of work, and I may never have enough free time to do it.

If it did happen though, it would likely happen in stages:

# A drop-in executable that would load/save using existing XCOM files/savegames/etc, using the original graphics.
# Enhancements to above (MIRE, XCU* style soldier kits, except maybe more permanent)
# Specification for user-created advanced graphics files (3D models instead of sprites, 24-bit backgrounds, etc)
# Implementation of user-created graphics sets

The final version would run entirely on it's own without any original XCOM data.

Asterisk = disclaimer - I've never used XCU, I don't know how those kits work, but I imagine it would be very handy if implemented properly.

User:Spike

2010-08-04T05:14:41Z

Renegrade: /* Base Fixer */

Hi, my name is Spike. I live in London. My mates all played XCom when it came out, when they were feckless students, but I had a job so I didn't get to play. I'm making up for lost time now. I love retro tactical SF games. I like to play Laser Squad, MegaTraveller, any old rubbish.

I think one of the reasons is these TU-based tactical games are all variants of the old miniatures rules by GDW - Snapshot, Mayday, Azanti High Lighting etc. In the day, how we wished for a computer program to help us with the tedium of playing those games by hand. Even Laser Squad would have blown us away.

Having said that I don't play any head-to-head stuff, like X-Com 2000. I imagine I would get my arse kicked.

This site is fantastic to use, so it's nice to be able to make some small contributions to the site, and the game.

= Musings =

To avoid spamming the site Discussion pages, and spamming people with 'watch' enabled on those pages, I'm going to start doing the decent thing and composing my musings here on my own page. If I get my thoughts edited and reasonably coherent I will then transfer them to Discussion pages and then onto actual articles.

Here are some of the topics I am interested in at the moment...

== Economics ==

The Geoscape game is a classic resource game and delivers lots of great game play in its own right, even when not intercepting or doing tactical missions. Economics is key. Looking at the the economic articles on the site at the moment, they focus on making money. What I am interesting in is 'fixing' the economics so it all makes more sense.

=== Efficient market ===

At the moment it is possible to sell lots of things for either profit or loss that does not make sense. I would like to fix the buy and sell prices so that they balance out and there are no egregious opportunities for arbitrage, or the reverse. For example I've calculated that based on the maximum profit you can make out of Elerium and Alloys (the raw materials in the economy of XCom), the price of Alloys and Elerium should both be quite a lot higher. Or alternatively some of the prices of manufactured products should be lower.

I would like to just true up all the prices of everything to reflect the economic costs of production, and to allow them to be sold at a modest profit. (And bought at a modest premium, see below). It's not good that there are so many 'black hole' items that are hideously unprofitable to produce, and a few 'optimum' items that everyone manufactures all the time.

==== See Also ====

Until I incorporate them here, see also my sections in [[Talk:Manufacturing_Profitability]]

==== Capital costs and interest ====

Correct pricing needs to take account not only of raw materials, labour and maintenance inputs, but also capital costs (initial hiring, facility building). For this an interest rate (cost of capital) needs to be posited for XCom. Given XCom's status as a covert internationally funded organisation, reasonable access to money markets could be assumed. For game purposes a capital cost of 5% - 10% is probably fine. Even 1% per month would probably work fine given the game's short time horizons.

Actually the return to capital can probably be calculated quite easily (based on production costs vs profits on the most profitable items). If X-COM were actually to be allowed to borrow, it should be charged at least near to this much interest or otherwise a free money machine is created. Because of X-COM's short-term, high stakes objectives and potentially massive future cash flow, it would probably borrow very heavily if it could to build up a strong position. But then, who would lend to an entity that not only doesn't exist, but is fighting a life or death struggle against powerful forces beyond our comprehension?

A tricky question though with capital costs is how to amortise them over the production of multiple items. Obviously the worst case is to charge the entire capital cost to the first unit produced (a possibility worth considering under 'External Markets - Buying', below). We could make some educated guesses about the order of magnitude, based on the likely market size. Again, see below under 'Inelastic Demand' for some guesstimates - thousands for small arms, hundreds for aircraft weapons, dozens for aircraft. Unfortunately this is a better 'efficiency of scale' than X-COM gets in the standard game, so it would make the game easier. For purposes of game balance over realism, we need to amortise over numbers that make sense in the time frame of a single X-COM campaign. For balance, that might be more like ten for small arms, 2-4 for craft weapons and 1 for aircraft. This comes in to play more with the 'External Markets' angle.

=== External market ===

At the moment you can buy and sell conventional equipment but only sell some advanced equipment (and not all of that), and not buy any of it.

==== Selling ====

As long as egregious profits are not being made (see preceding section), I think you should be able to sell all manufactured products eg aircraft. After all, the funding nations (and others) would no doubt like to get their hands on aircraft with such advanced characteristics. The problem of course is setting a fair sale price. Probably the game designers didn't have the time to do the exhaustive manufacturing analysis that has since been done on this site and other fan sites. With the benefit of this data, we can set fair prices for all manufactured components and allow them to be sold (by editing [[PURCHASE.DAT]]). Standard (or higher?) fixed profit ratios would apply for buy vs. sell pricing of manufactured goods.

===== Inelastic demand =====

Demand for advanced, alien and conventional items is totally inelastic in the standard game: the price does not drop no matter how many units you sell. On reflection, I don't think this is that unrealistic. For conventional items, XCom purchases and sales are a microscopic part of the whole traded economy in such items - outfitting a maximum of 250-odd soldiers will not make a dent. For advanced and alien items, demand is never really going to drop. Once the US special forces have been outfitted with Heavy Plasmas, the Israeli, Russian, and French special forces will want to catch up. (And the British SAS might get around to buying some Laser Rifles, ha ha).

Much less would the nations of the world say no to purchasing high performance hybrid aircraft. They would pay millions (and perhaps this is why the game designers did not permit the sale of aircraft).

I can see buyer fatigue setting in if hundreds or thousands of laser cannon are produced for sale, as these are limited to combat aircraft and there are only a few thousand front line combat aircraft in service at any given time. Another reason to diversify the options away from a handful of 'optimum' manufacturing items.

If you wanted a cap you could probably specify about $1 billion of inelastic demand for advanced items of each type. 7000 Heavy plasmas - about enough to equip 12 special forces battalions. A hundred or so of each aircraft type. After that the market might start to get a bit soft. And maybe the market for e.g. Mind Probes would be more limited.

I think there's a case that the very first few examples of each item would have a much higher price. But perhaps we can posit that as part of its funding agreement, XCom has agreed to sell recovered weapons etc back to the Funding Council nation at reasonable and stable prices. Possibly the sales are allocated to funding nations by rota in the early stages - that would make sense. The funding nations get allocated artefacts "by lots" and are then free to resell them to each other or, eventually, on the open market.

==== Buying ====

Slightly more interesting is allowing the 'External Market', in the form of military-industrial firms with links to the funding nations, to produce advanced items. This would then allow XCom to simply buy, rather than manufacture, items such as Avengers.

The pricing would simply be the total economic cost, as determined by the 'Efficient Market' process above, plus some profit margin - probably the standard buy/sell profit margin which is about 33%.

Now obviously you don't want to make advanced items available from the start, that would defeat a lot of the challenge of the game. From a game play point of view what you want to do is give the player a reasonable alternative of buying vs manufacturing the item, once they have done the necessary research.

Options for doing this... say that an item can be bought on the open market:

:1. Once the item has been captured.
:2. Once one (or more?) examples of the item have been sold onto the market.
:3. Once the item has been researched by XCom.
:4. Once one example has been manufactured by XCom (this could be hard to check for though).
:5. Any of the above, plus a time delay. For 1-2 this would be related to the Research time.

In cases 1-2 the Research is being done outside of XCom which really changes the game. In this case there should be a big premium payable to the external arms company that owns the patents etc. This can be done in PURCHASE.DAT as the buy and sell prices can be set independently of each other, so set the Buy price at 200% of Sell price (vs the more normal 133% of sell price). Or at the very least we could put the price of the item up by say 50-100%. Keep in mind that as part of 'Efficient Pricing' we have (in theory!) already factored in the cost of the research effort (scientists, labs, capital etc).

In general though I don't favour bypassing the Research tree so that favours options 3-5. 3 is easy to check for in the game files. 4 is tricky, at least for alien items, because while you can see items under construction, you might miss the moment they are constructed. For non-alien items, the mere existence of the item in the game proves it has been manufactured.

As an extra variant you might say that only hybrid items, not pure alien items, can be manufactured by the external firms. So while laser rifles, a power suit or an Avenger can be built, and indeed mass produced, by a high tech arms company, only X-COMs "Deep Black" science labs can painstakingly assemble small numbers of genuine alien items like Mind Probes, Blaster Launchers, etc.

I'd be quite comfortable with this variant (hybrid only) and it makes it easier to police option 4 which is the most challenging and probably the best for gameplay. Or you could mix 3 and 4, charging a 50%-100% premium on purchases until such time as X-COM has produced their own example of an item.

There is also the question of delivery times. Delivery times for the Avenger are very long and compressing that to 72 hrs would seriously affect the game balance. I think that PURCHASE.DAT can be hacked to lengthen the delivery times for specific items. Probably the delivery time should be based on a reasonable setup such as a 100-space workshop with as many engineers will fit. We don't really want to provide advantages to buying the Avenger, we just want it to be a not unreasonable option.

One final question is availability of resources, especially Elerium which is the only thing that can't be manufactured. The price of Alloys can be computed with a floor equal to the labour & capital costs of production, and a ceiling based on the most profitable item you can produce with Alloys (Mind Probes I think from memory). The price of Elerium should be at least the value derived from the most profitable item you can build with Elerium. Potentially it is much higher, since Elerium is scarce and has other very valuable irreplaceable functions (hybrid aircraft fuel, winning tactical missions, saving the world...).

A strict interpretation would be track the amount of Elerium sold (and anything else that can't yet be manufactured by the external market at that time, eg Alloys / UFO Power Sources / UFO Navigations). You would then not be allowed to buy more manufactured items than could be built using the total resources sold up to date to the 'external market'. But apart from patching the game I can't think of any way to do this kind of double accounting. Actually I can, in XComUtil you could record all UFO recoverables after each mission, and then subtract from that all XCom stores and the inputs to all existing manufactured items (ignoring anything destroyed - presume comprehensive recycling of such valuable scrap). But that would be a hassle to code up.

There is an argument for a highly elastic price for Elerium, based on the total supply. Of course, as players we 'know' that (apart from variant self-imposed rules like 1-Mission or No Detection etc) there is ample Elerium just around the corner. That's the reality of the standard game, so in a standard game a fixed price for Elerium is probably justified.

=== The Elerium Standard ===

This brings me back to the beginning in a logical circle. Prices are all relative, so what is the reference point? You can do this one of two ways. Either take the most profitable item in the game, and work back from that to deduce the correct price for Elerium (pricing all other components along the way, eg Alloys, Power, Navigation). Or, you can take the price of Elerium as it is, and work your way 'up' the chain, correcting the prices for everything built from Elerium. I like the first method because it has the least impact on existing revenue-generating options from manufacturing. The revenue a player can create should stay exactly the same (proportionate to the inputs of labour, capital, raw materials); they just have many more ways of generating that revenue.

=== Realistic External Demand ===

Realism is often the enemy of game balance when it comes to selling. The things that governments (and others) would pay highly for, are also the things that are useful to XCom. And the prices that governments would pay would distort the cash balance of XCom. The best explanation is that prices to XCom are merely commissions or honoraria, and the prices of these are "fixed" by the Council of Funding Nations (CFN). Still it's interesting to speculate what governments would actually pay for advanced equipment.

In general governments would pay most for items that affect the strategic balance, and less for items that are of merely tactical value. In the tactical realm, they would pay most for items that create "step change" improvements, rather than just incremental increase in effectiveness.

Potentially the biggest strategic impact comes from the psionic technology, the Psi Lab and Psi Amp as well as the Mind Probe. These offer massive advantages to intelligence agencies, diplomats, security agencies, and repressive or paranoid regimes. It is reasonable to assume these technologies will '''not''' be for sale outside the CFN. The offensive capabilities are too great - mind control of Presidents, mind reading of negotiators and senior officials. Even the very existence of these capabilities would need to be kept totally secret. It's not clear how much non-tactical information can be gleaned from a Mind Probe. If we assume that Mind Probes could detect a mind-controlled individual - "which ''side'' is he on?" - then for defensive measures versus aliens (or other CFN nations), that require no special abilities to use, these items would be in high demand.

The other major strategic impact is air superiority. Creating or denying air superiority can have a major effect on the strategic balance of power. An aircraft that could enter an attack another country's airspace with near impunity - perhaps carrying nuclear weapons - would be a major power shift. So aircraft, and aircraft weapons, are the next major group. Whether it is the weapons or the aircraft that make the difference depend on the specifics. However I would suspect it is the aircraft. Advanced XCom aircraft have aerodynamic performance characteristics far in advance of the most advanced terrestrial aircraft (the Interceptor). Regardless of combat performance, the aerodynamic performance means that advanced aircraft can avoid any combat that is not on favourable terms. This means that as a strike aircraft they would defeat air superiority and in fact be nearly unstoppable - except by other aircraft with the same performance characteristics. Therefore I believe the advanced aircraft would be the most expensive selling item, after the the psionic technologies.

If we look at the combat capabilities of advanced hybrid aircraft and advanced craft weapons, as opposed to their flight capabilities, there is not such a "step change" in these capabilities. The improvement on the defensive side is more significant than the offensive side, which again suggests that the aircraft platform is more important than the weapons. A Firestorm, Lightning, or Avenger has 5x, 8x, or 12x the damage capacity of an Interceptor. A Plasma Beam has less than twice the firepower (damage per unit of time) of Avalanche missiles.

Defensively, it takes an average of 20 Avalanche launches (10 dual volleys) to bring down an Avenger, versus an average of 1.66 launches (0.83 dual volleys) to bring down an Interceptor. A single Avenger armed only with Avalanches, fighting 4 Interceptors armed with dual Avalanches, would likely kill 3 opponents, sustaining 8 x 60 + 6 x 60 + 4 x 60 = 1080/1200 damage. An Avenger can't carry enough Avalanche ammunition to kill a 4th opponent, but if it did, or if it mounted a single Plasma beam, the odds are about even to wipe out the whole enemy flight. (An interesting thought - max ammo capacity should really be based on the aircraft size not just the weapon type.)

On the offensive side, vs Interceptors the weapons don't make much difference. A dual Plasma beam will bring down an Interceptor on the first volley, on average. So will the first volley from dual Avalanches - albeit the Avalanches (even on Aggressive) take twice as long to reload for the next volley, compared to the Plasma Beam. So not a great deal is gained against conventional opponents by having advanced weapons. In fact, an Interceptor armed with Avalanches will most likely kill an Interceptor armed with Plasma Beams before it enters weapon range. So better weapons are only really needed if you are concerned about fighting UFOs, or advanced hybrid aircraft.

None of the infantry offensive or defensive equipment really gives a decisive advantage. The top items are probably the Power Suit / Flying Suit and the Blaster Launcher / Stun Launcher. The Power Suit gives a soldier the defensive power of a light tank. meaning that accurate or repeated or concentrated fire from squad support weapons is required to stop him. The Flying Suit is slightly stronger and the novelty of flight would attract special forces use. While these are all "force multipliers", as is Personal Armour to a lesser extent, there are no real "step changes" in the infantry area. The Blaster Launcher is the closest thing to a step change, probably, with extremly high destructive power and incredible guided capability. This would again make it a desirable item for special forces, especially those contemplating going up against aliens. But it is expensive to operate, not an essential item, and not a true step change. The Stun Launcher is just a specialised item that would attract special forces because of the ability to more easily capture hostile targets (human or alien).

In all these issues there is an obvious "arms race" effect. Once one government knows other governments have psionics, or Mind Probes, it will want them urgently for itself. Once advanced aircraft are in the enemy fleet, advanced fighters ''and'' advanced aircraft weapons become imperative. At the tactical level, advanced infantry armour becomes a strong driver for procuring advanced infantry weapons, and (less crucially) the same kind of armour.

In summary, the demand price ranking of technologies, in order of most expensive first, should be:

Psionics - Primarily Offensive

*Psionic Laboratory
*Psionic Amplifier

Psionics - Primarily (not entirely) Defensive

*Mind Probe

Air Superiority

*Avenger
*Firestorm
*Lightning
*Elerium - required to operate these craft

Air Combat Weapons

*Fusion Ball Launcher (very limited market as it requires Elerium-based ammo)
*Plasma Beam
*Laser Cannon (if fixed to be useful - might even be the most popular since requires no Elerium)

Battlefield Equipment

*Blaster Launcher (specialised market as it requires Elerium-based ammo)
*Power Suit (biggest market)
*Flying Suit (specialised market)
*Stun Launcher (specialised market)
*Hovertank chassis, though none of the weapons are interesting compared to their man carried versions
*Plasma Weapons (specialised due to ammo requirements)
*Personal Armour (mass market)
*Laser Weapons and tanks - non-hybrid tech, serious nations can research this themselves?

== Detection ==

=== Detection by Aircraft ===

See my sections in [[Talk:UFO_Detection#Detection]]

=== Fixing Multiple Radar ===

See my section in [[Talk:UFO_Detection#Multiple_Radar_Effectiveness_Algorithm_and_Hack]]

[[User:Seb76|Seb76]] now has a brilliant fix for this bug in his UFO Extender. Also see the Tools section below for the Base Fixer.

The algorithm I used for the Base Fixer was:

: smallf = (0.9) ** nsmallradar
: largef = (0.8) ** nlargeradar
: xdetshort = int (round ((1 - smallf * largef ) * 100))
: xdetlong = int (round ((1 - largef ) * 100))
: #special case backward compatible
: if nsmallradar == 1 and nlargeradar == 1 :
:: xdetshort = 30
:: xdetlong = 20

I've confirmed TFTD also sufffers from a "Sonar Stacking" bug and is in fact identical to UFO:EU, the only difference being a different offset in [[BASE.DAT]].

===Phantom Radar Bug (Talk) ===

Is listed at [[ExploitsA#Phantom_Radar_Trick]]. Thanks for adding, though. Also, I'm under the impression that building a new structure, even starting one, eliminated Phantom Radar; so upgrading-in-place cannot be done. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:52, 17 March 2008 (PDT)

:OK thanks for that. i will test but you are probably right! removed this text:
This bug allows you to "upgrade in place", for example building a new Hyper-Wave Decoder over the top of an existing Large Radar, and retaining the detection capability of the Large Radar until the Hyper-Wave Decoder completes building. (Unless something else completes building first).

[[User:Spike|Spike]] 02:10, 18 March 2008 (PDT)

: For XCOM CE (since I stare at this in a hex editor a lot):
: * Completing any new structure causes the radar stats to be recalculated at the base the structure completes at.
: * Starting new structures is perfectly safe.
: -- [[User:Zaimoni|Zaimoni]] 7:49 18 March 2008 (CDT)

OK I've done some tests and confirmed what Zaimoni said is right. Upgrade in place is possible. If you dismantle a small radar and build a large radar over it, the SR detection value applies until the large radar (or any other facility) completes building in that base. I see the detection values in base.dat and I also get detections/intercepts from the base that has "no radar". The Base Information screen detection strength shows zero but base.dat shows 10%.

Reinstating the "upgrade in place" comments in the Known Bugs entry!

[[User:Spike|Spike]] 17:47, 19 March 2008 (PDT)

== Balancing Infantry Weapons ==

=== Starting Weapons ===

[[Talk:Rifle#Rifle Rebalancing|Rifle]] (and the Pistol too, really)

The Heavy Cannon and Autocannon are so finely balanced that it's too close to call, so no work to do there.

High Explosive is already useful as a mega-grenade thrown by Schwarzenegger types, so there is no need to boost it to tear open UFO hulls, in my opinion.

Grenades and Proximity Grenades work fine. Nothing to do.

=== Rockets ===

Might be nice to replace the Small Rocket with something more useful, as really this is a wasted weapon. Illumination or smoke rocket? Flechette round - how could that be implemented? A bit like Seb76's Heavy Laser, with say 20 rds of AP autofire into a limited arc? Or how about a proper anti-armour round, something that might punch a hole in a Cyberdisc or a UFO hull. A shaped charge would require hefty coding though, not just fiddling with OBDATA.DAT. All the explosions in XCom are omni-directional (well, planar). Even crimping an explosion down to one hex would be tricky I think? And not terribly realistic. What you actually need is a high-yield HE (190+) that drops off much faster than the standard 10 pts of HE per tile. Say 50 per tile. Is that doable as a UFO Extender mod? "If weapon == HEAT Rocket, explosion_reduction := 50"? A wackier way of doing a shaped charge would be to use a regular HE round but mod the tiles on the near side of the blast to have massive HE block. Then restore normal HE block after the explosion. Again sounds very tricksy.

=== Laser Weapons ===

Practically perfect. A curmudgeon might be tempted to toy with the Laser Pistol, suggesting it is overpowered. I dont care. Dumb but effective, it is XCom's first great equaliser in the fight against the aliens. Cant give up that great feeling.

The Laser Rifle of course is immaculate, a masterpiece of human engineering. Cydonia must fall to the Laser Rifle! Plasma is for wimps!

There are various Heavy Laser buffs, including XComUtil and UFO Extender. Any of these is fine.

=== Plasma Weapons ===

The Plasma weapons might need to be toned down a bit as there is no incentive to ever use anything else (bar some special situations, e.g. those that have Laser Rifle written all over them). Ultra light, almost no TU penalty for auto fire. Snap shots kind of pointless, especially given the high ammo capacity. In a lot of ways the basic mechanics of them defy explanation. It seems you just kind of wave these guns at the target and kill it. But then, they are "ray guns from outer space". One of the best nerfs is the XComUtil option where you can no longer manufacture them, only use them (and make ammo). But then it's not as if they are in short supply.

It would be good if the Heavy Plasma was not quite so optimum. Making it actually heavy (a UFO Extender option) is a small but good idea. Reduced ammo capacity, more like the Sonic Cannon, would be better. I think the designers of TFTD realised the Sonic Cannon was going to fall into enemy hands, and nerfed the ammo accordingly. Let's face it, aliens don't usually get the chance to run out of ammo. So high ammo capacity favours XCom.

To be honest I have not thought much about Plasma Weapons and I don't have a strong opinion, or barely an opinion at all. But the Plasma Rifle seems odd. More accurate than Heavy Plasma in Snap and Auto, but less accurate in Aimed? How do we make sense of that? A more distinctive role for the Plasma Rifle would be good. Some people hoard them as allegedly great sniper weapons. I don't see that, really. It just seems to be a mostly inferior Heavy Plasma to be tossed aside when its big brother is available. In alien hands, it is just the Heavy Plasma Lite. It is just a "Medium Plasma". It's not a "Rifle" in any sense, is it? You might just want to rename all these weapons, devices, whatever-they-are, "Small Plasma Unit", "Medium Plasma Unit", "Large Plasma Unit". Maybe you aim them with mind waves, like UFO Navigation. Maybe accuracy should be based on Psi Skill. I am rambling now.

What kind of weapon is a Heavy Plasma, anyway? It comes across as a kind of Cosmic Kalashnikov, for when you "absolutely, positively gotta kill every cloner-cloning alien in the room".

You could do some interesting things to restrict the ammunition. You could make it not manufacturable. But there is a lot of ammo laying around. You could make the weapons ''not reloadable''. Now that would be interesting. We can't make them and we can't reload them. We can only fire them. They recharge by being hooked up to a UFO reactor in a way we cannot reproduce. Or hey, they are alien weapons, maybe they just don't recharge them, they are disposable weapons. Certainly explains why there are none left by the time of TFTD.

=== Tank Weapons ===

It has often been observed that HWP weapons are often less powerful than their man-carried equivalents. Seems odd on something at least 4 times bigger than a man, which is designed to carry weapons.

But presumably this was a conscious game balance decision by the designers, and not just an accident?

Would it hurt much to uprate the HWP weapons to the same damage level as the man carried equivalent (where that is a higher value)? Not really. Accuracy and RoF would still be HWP levels of accuracy.

== Balancing Aircraft Weapons ==

=== General Principles ===

*All weapons should at least have some niche role in which they are most effective or at least most cost-effective.
*Historical realism should be observed if possible but not at the expense of game balance.
*Trade off between offence (firepower, payload) and defence (range, especially stand-off range)
*Trade off between range and firepower
*Trade off between firepower and payload
*Trade off between all factors vs cost (purchase cost and operate cost)
*Cost factors need to be significant within the context of the game, i.e. relative to XCom budget, income, and yield from Crash Recovery missions.

=== Roles ===

*Cannon-type weapons should be for close-in, aggressive actions, where defence of the XCom aircraft is neglected. Since the XCom aircraft will take damage while closing the range, the firepower (not just the payload) should be better than the longer ranged weapons.
*Missiles therefore, if they have standoff advantage, should have lower total overall reliability for killing UFOs than cannon-type weapons.
*Another role for Cannon is finishing the job after missiles have only partly damaged the target. That rarely happens at the moment. Missiles would need to be less powerful for that to happen. Even then, it would never make sense to mount one less missile launcher and replace it with a Cannon.
*In real life a cannon is often a built in weapon so there is no choice between having missiles and a cannon. A built in cannon is an auxilliary weapon, a freebie, that is not the primary air to air weapon but can be used in certain situations. An aircraft with a pod-carried cannon that used up missile slots would be unlikely to mount that weapon in an air superiority configuration.
*It is odd that XCom is even bothering to mount Cannon on its aircraft, given how difficult the problem of air superiority vs UFOs is known to be, even before the creation of XCom. We almost need to ''invent'' a reason why XCom craft carry Cannon. Apart from just shooting down Small Scouts. It's debatable whether Cannon really are effective even in that role. They are more likely to bring the Small Scout down in one piece IF they get in to firing range. It is so much easier to get into range with Stingrays that despite the high rate of total destruction (57%) you would still generate more Crash Recovery missions per intercept by using Stingrays instead of Cannon.
*Similarly Stingrays need some justification for their existence.

=== Common Elements ===

These elements are needed, regardless of which approach to rebalancing is adopted.

==== Fusion Ball Launcher ====

As Cesium suggests in [[Talk:Craft_Armaments#Fusion_Balls_better_than_Plasma_Beams.3F|this discussion]], the FBL needs to be buffed to be useful and the main thing is to increase the ammo capacity to 3. 2 rounds is such a weird number though, makes me think maybe it was reduced in playtesting. Well if they thought a 3-rd FBL was too powerful in playtesting, the playtesters had too much money. FBLs are very expensive to operate so they ought to have a tactical niche in which they excel. The analysis I did suggests they are tactically superior to Plasma Beams, in terms of 'force protection'. It's a very expensive way of protecting your fleet but it is cost-effective. It is still debatable whether the hassle of switching weapons is justified, because FBLs are only really appropriate for the Big Battleship Defence missions.

I don't think its necessary to increase the FBL damage as well. Particularly since in my Tougher UFOs rebalance I want to reserve 255 damage for the Battleship weapon.

However the 3 rd FBL is the only other mod required to make the Cost Based Solution work. In fact it fits in nicely with the Cost Based Solution because it is yet another bloody ridiculously expensive (but effective) launched weapon.

==== Extra Initial Cannon Ammo ====

Normally Commanders immediately throw away most or all of the initial 4 Cannon and ammo provided. If, instead, the Cannon is rebalanced and becomes a useable weapon, the initial Cannon logistics are revealed as being unhelpful (maybe the playtesters never used the Cannon either). Perhaps the XCOM Quartermaster astutely realises that the (unmodified) Cannon is not much use, and conserves store space. Unlike all the other starting aircraft weapons, you don't have enough ammo even to load all the weapons you are given. In fact you barely have enough spare ammo (only 50 rds) to operate the Cannon as a weapon and still be able to keep your initially mounted weapons fully loaded. This is despite the fact that Cannon ammo is far and away the cheapest.

Unfortunately extra Cannon rounds, like all aircraft ammunition types, take 4 days (96hrs) to arrive. This will seriously cramp the style of anyone wanting to use a Cannon strategy, especially if they want to mount dual Cannons on 1 or more aircraft. This is not possible with the initial ammo stocks (because in the rearming sequence, the left weapon must be fully loaded before the right weapon begins to load). Even taking down a single Medium Scout will take about 48 Cannon rounds, nearly the entire initial "reserve".

Therefore as part of Cannon rebalancing, the initial Cannon ammo stocks should be increased by at least 10 units / 500 rds - a $12,400 cost-price value, hardly destabilising. Those that don't want to use the Cannon can still sell everything to clear space and raise a little cash. Their choice of strategy is not cramped in anyway.

(Interestingly it's possible sometimes at least to shoot down a Medium Scout, which is armed, without sustaining ''any'' damage to the dual-Cannon-armed aircraft, which maybe suggests the first UFO return fire only occurs after 1 random firing interval of the UFO weapon has elapsed?)

=== Cost Based Rebalancing ===

Rather than tuning the stats of the weapons you could just increase the costs. For example [[Talk:Realistic_Equivalents#Aircraft_Weapons|realistic prices for missiles]] (Avalanche $386,000, Stingray $125,000) would give a reason to use Cannon and Stingrays, and make Commanders strongly consider arming only a single missile launcher on each aircraft, rather than always dual mounting.

*A simple solution to bring Cannon and Stingrays back to life would be to increase the costs of an Avalanche. The Avalanche is clearly a very advanced weapon. Probably the AIM-120 AMRAAM which was in service by the mid 1990s. Nominal range 30nm, around 65km. This weapon cost $386K per missile in 1999. Although you could probably not lease an aircraft to fly it in a high-risk environment for $600K a month. That might cover the fuel...
*On the other hand the Stingray is probably the AIM-7 Sparrow with max range 30km. Cost $125K in 1999.
*Cannon ammo costs are basically correct in UFO. So this is more balanced and more realistic.
*Realistic pricing would also fix the Laser Cannon. It would be suddenly incredibly useful, as it has similar capability to Stingrays but is free to operate.

What about the Launcher prices (Avalanche Launcher etc). Are we just talking about a pair of rails here? Even they probably cost more than $17,000. The full radar and avionics to control a missile launch is going to cost a fair chunk of the purchase price of an advanced fighter aircraft. But then we are not realistically leasing those either.

Realistically, the Funding Nations are providing the aircraft and their launchers for free. The $600,000 is a kickback to cover the costs of maintenance and jet fuel. The $17,000 for the launcher is the cost of ''delivering'' it to XCom's base. And $3,000 / $9,000, that was just the cost of ''delivering'' the missiles.

If we did charge realistic prices for the Launcher, you would not want to be able to sell them, as it would give a huge amount of extra startup cash. Similarly with the missiles. The sell price should be next to nothing, just like aircraft sell price. The Funding Nations say "ok if you want us to take them off your hands, fine, we wont charge for taking them back". Buying and selling launchers for accurate prices is impossible, the realistic launcher costs would be in the millions, off the charts. Basically all these aircraft, rented or built, must be considered to be already Stingray- and Avalanche- capable.

The game-balance-neutral solution is to leave the Sell Price of Avalanche and Stingray the same as in the unmodified game. This is a derisory sum, but it makes sure the missile stocks at the start of the game don't turn into a massive cash cow.

Nonetheless this means the starting missile stock of 37 Stingrays and 10 Avalanche is worth $8,485,000. I would expect that, under this option, new missiles are purchased very sparingly, if at all, and there is a strong emphasis on developing Laser Cannon and Plasma Cannon.

=== Stat Based Rebalancing ===

This seems hard to do now that I came up with the easier Cost Based option. :)

But basically you need to:

*Increase Cannon firepower x3 (15 dmg, 50% hit) to exceed missile firepower (but at very short range)
*Increase Laser Cannon firepower x2 (100 dmg, 50% hit) to be a more powerful, longer range Cannon
*Ensure the Cannon rearming rates (back at base) match or exceed other weapons
*Improve Stingray relative to Avalanche.
**Raise Stingray accuracy to 80% and lower Avalanche to 60%, giving the Stingray greater firepower at shorter range.
**Also increase the rearming rate from 3 to 6, so a full ship rearms as fast as a full ship of Avalanches. (It's not clear where the rearming rate is set, however)
*Increase Fusion Ball Launcher ammo capacity from 2 to 3

=== Remaining Issues ===

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

Something also needs to be done about the Plasma Beam, as it is still just too optimal, even with a buffed FBL. You could use the XComUtil alternate manufacturing. NKF's suggestion to reduce ammo capacity to 10 is a good idea. Or you could give it cannon-like range, i.e. much less than 52km, so it is a close-in weapon like the other cannons. Or you could make the ammo cost money. Or require Elerium to reload, just like advanced craft need Elerium to refuel.

== Tank mods ==

I think it would be cool to mod the HWP / SWSs to have additional functions. This would add tactical variety and thus add play value. Of course it would give even more advantage to XCom, which is a concern.

I see this as having a few levels:

At the simplest level, the tank is available during the Equip screen, and you could put an item into its second "hand" slot. This could be a scanner or a medkit.

A step up from this would be an explosive pack, smoke charge, or other grenade, that could be armed and/or dropped, but not thrown.

There would still be no access to the Inventory screen in battle, so no reloading or switching items.

If Inventory access (only) is allowed, this gives the possibility of a Logistics/Recovery Tank that can collect casualties or equipment, friendly or not, and move them to safety. Actions with the second slot could be disabled or restricted.

If Arm/Throw actions are allowed, this can become a much improved Minelayer / Mine Thrower / Smokelayer / Demolition tank.

A Stun Rod -armed Taser Tank is an interesting idea.

Actually arming tanks with man carried weapons, even if they can't reload them, makes the tanks full cyborgs and is probably going too far. Save that for the next war plus one.

:A few suggestions: a) Make the tanks have multiple weapons b) Make some weapons on a tank capable of autofire c) Possibly make the tanks have two sets of TU, one for firing and one for moving (NO idea how this could be implemented, maybe make Energy into move-TU and TU into fire-TU) d) Balance this with the same modifications to alien HWP equivalents (ie Cyberdisks, Sectopods, Bio-Drones, Triscenes, Xarquids) [[User:Magic9mushroom|Magic9mushroom]] 08:38, 17 August 2009 (EDT)

:: Well personally I'm not too keen on adding more direct fire weapon options to tanks, that wasn't my intention, as I think it would be unbalancing without being really much different in terms of game play. I just thought it would be interesting to have different kinds of "Support Vehicles". But you are right, dual weapons on a tank could be interesting.

::I don't think creating 2 pools of TUs is necessary (or feasible) for tanks. You can just reduce the TU cost of firing the weapon until it's negligible relative to the movement costs. And for real armoured vehicles, rate of (effective) fire and movement speed have an inverse relationship, so it's not unrealistic for the same pool of TUs to be used for both tasks. As for alien terror units, some of them already have multiple attacks (in TFTD anyway). I'm not sure what would be gained. Aliens would need new AI to figure out which weapon to use in which situation. The AI can't really handle additional flexibility. But it might be able to handle weapons that are more powerful. Having two of them would hardly matter, except in cases of launcher weapons with very limited ammo. What might work, is to just give alien terrorists tougher weapons - Sectopods with dual Blaster Launchers, anyone? [[User:Spike|Spike]] 11:04, 17 August 2009 (EDT)

=== How to Mod Tanks ===

First of all you need a hex editor as I found out, the BB Toolkit unfortunately does some strange things trying to edit these fields for tanks. :)

To get to the inventory of a tank in the Battlescape you need to set UNITREF.DAT 0x71 from 01 back to 00. This enables inventory access but also makes the tank affected by stun. As the turret weapon overrides anything in the left or right hand, you cant use any functions like Arm, Throw or firing weapons, or attack with a Stun Rod. You could use the tank as a recovery tank, picking stuff up and moving it around. If someone else armed an HE pack, the tank could carry it into position and drop it. In fact it could be multiple HE packs. Or the tank could suicide with one or more armed HE packs on board. I kind of like the idea actually that tanks would not be able to self-arm explosives, that a soldier would have to do it. It is a good field safety procedure.

To actually get the tank to use other equipment, you need to disable the turret weapon by setting UNITREF.DAT 0x75 to 255 (0xff). If pre-battle Equip Screen and in-battle Inventory access is also enabled, this then makes the tank a "full cyborg" - it can do anything a soldier can do, carry and use any weapon or item. This is probably overpowered, even if the tank has lost its turret weapon. Man carried weapons are often as good, or better, especially given the tank can reload, change ammo types, etc. A tank with an HE Autocannon and a Rocket Launcher is pretty fearsome.

Using this method I have got a HE Pack-throwing, HE Autocannon-firing tank. (Tanks seem to have 0% Throwing Accuracy, which is good as I would not expect them to be as good as soldiers, and they have higher Strength than initial soldiers. The results aren't terrible, but lack the precision of a skilled soldier).

The techniques above could be used for any of the tank scenarios as long as the player exercises self restraint, and is willing to live with the tank being stunnable. I dont think I have a problem with that actually. It simulates the common situation where an armoured vehicle is disabled, rather than destroyed, by some mechanical or systems failure.

Things to investigate:

*Creating a correct paperdoll image and layout file for the tank in the inventory screen using combinations of UNITREF.DAT offsets 0x01, 0x117. E.g. set 0x01 to 4, then get/create MAN_4.SPK and .xsp.
*Possible create new SPK files for the paperdoll images for the tanks. Or use the SPK files from BBs Toolkit actually.
*How to enable access to the pre-battle Equip screen as well or instead as the Inventory screen. Without crashing due to mismatches of the paperdoll image and layout file. Or just ask Bomb Bloke how he did it. ;-)
*If the logic for the turret weapon overriding the held weapons or items can be found and NO-OPd. Thus allowing use of a 2nd item or weapon '''in addition to''' the turret weapon.
*If it is possible to make an item undroppable, so it is "fixed" in a slot. Thus allowing Inventory access for logistics and reloading but not for changing of weapons/items.
*If the turret is disabled but Inventory is not enabled, then the tank should be able to use only the items placed in its "hand" slots. Not clear how to place them though - either during the Equip phase or by using a game file editor (or UFO Extender!). The tank would also be immune to stun again. This would be a good way to make variant tank types that were not too unbalanced, since then the tank can't reload.
*Might be able to trick XComUtil EQP into giving equipment to tanks, IF you could hack the name of the tank to contain a /Class suffix?
*See [[UNITREF.DAT]] offset 0x2E for mention of an alternate tank layout. Also for ability to have blank turret graphics (e.g. if turret weapon is disabled).

:Not 100% sure, but putting offset 0x71 to 0 may also render your tank susceptible to fatal wounds. [[User:Seb76|Seb76]] 13:37, 30 August 2009 (EDT)

=== UFO Extender Tanks ===

For a mod under Seb76s UFOExtender, you could maybe add a configuration section that says something like - replace turret for tank type X with objects Y and Z (with ammo A and B if they are ammo using weapons). So you could say: replace all Cannon tanks with tanks that have a AP auto cannon plus a Medkit, or plus an HE Pack, or plus a Stun Rod. This would be pretty balanced as the main weapon is weaker. An HE Auto Cannon might be slightly overpowered, though in a way it is a mid point between a Cannon tank and a Rocket tank. It would be nice for the mod to sanity check that the relevant tech is available, or even that the relevant equipment is available (on the transport), and to deduct it from existing stocks.

Basically this would be an extension of the Equipment Screen code of UFOExtender. But probably dealt with under its own configuration section. However there are interdependencies - such as the same pool of equipment - so it needs to be dealt with in the same code.

Here's a mock-up. It's a bit over-complicated, a simpler version would be pretty cool too.

[Tracked Tank Armour]
Apply=0
Health=90
ArmourF=90
ArmourS=75
ArmourR=60
ArmourB=60

[Hover Tank Armour]
Apply=0
Health=90
ArmourF=130
ArmourS=130
ArmourR=130
ArmourB=100

[Tank Equipment]
Apply=1

;apply to first Tank/Cannon in Battlescape (if present)
[Tank/Cannon 1]
DisableTurret=1
EnableEquip=0
EnableInventory=0
ItemRight=High Explosive
ItemLeft=High Explosive
;Mine-Thrower Tank with only 2 charges

;apply to second Tank/Cannon in Battlescape (if present)
[Tank/Cannon 2]
DisableTurret=1
EnableEquip=1
EnableInventory=1
ItemRight=Heavy Cannon
ItemRightAmmo=Cannon HE-Ammo
ItemLeft=High Explosive
;Demolition Tank that can carry additional charges (or change weapons/reload)

;apply to third Tank/Cannon in Battlescape (if present)
[Tank/Cannon 3]
DisableTurret=1
EnableEquip=1
EnableInventory=0
ItemRight=0
ItemLeft=0
;Tank that can be Equipped with any 2 items, but not change them (or reload) during battle

;apply to any/all other Tank/Cannons in Battlescape
[Tank/Cannon *]
;normal Tank setup
DisableTurret=0
EnableEquip=0
EnableInventory=0
ItemRight=0
ItemLeft=0

;apply to all Tank/Rockets in Battlescape
[Tank/Rocket *]
;retain turret Rockets but also use as a Logistics tank
DisableTurret=0
EnableEquip=1
EnableInventory=1
ItemRight=0
ItemLeft=0

;apply to first Hovertank/Plasma in Battlescape
[Hovertank/Plasma 1]
;Very expensive air ambulance!
DisableTurret=1
EnableEquip=0
EnableInventory=1
ItemRight=Medi-Kit
ItemLeft=Medi-Kit
;Inventory access allows loading and recovery of casualties.
;(As we have enabled Inventory access, the ambulance ''could'' be re-fitted with weapons/items once in the field)

;apply to second Hovertank/Plasma in Battlescape
[Hovertank/Plasma 2]
;Very expensive alien capturing and retrieval vehicle!
DisableTurret=1
EnableEquip=1
EnableInventory=1
ItemRight=Small Launcher
ItemRightAmmo=Stun Missile
ItemLeft=Stun Rod
;Inventory access allows reloading the Launcher and loading/recovery of stunned Aliens.
;As we have enabled Inventory access, the tank ''could'' be re-fitted with other weapons/items once in the field
;Equip access allows spare Stun Missiles to be equipped at the start
;As we have enabled Equip access, the tank could be reconfigured in a variety of other ways pre-battle.
;Or perhaps we can pre-equip it using a syntax along the lines of:
;Item[9]=Stun Missile
;Item[10]=Stun Missile
;Item[11]=Stun Missile
;Item[12]=Stun Missile

=Tools=

==Data Tables and Spreadsheets==

=== Tactical Firepower ===

*[[Media:Firepower.xls|X-COM (EU and TFTD) Battlescape Firepower]] - Spreadsheet comparing "close range/shock firepower" and "long range/skirmish firepower" of Battlescape weapons - it covers XCom and Alien hand-held weapons, XCom HWP weapons, and Alien Terrorist built-in attacks. Includes XComUtil variant weapons. The results are specific to a Target Type (Muton, X-COM Power Suit, etc) and you can set the attacker's combat skill levels. Also includes "lethality" calculations such as the probability of a first-shot-kill, the average number of hits to get a kill, and the average amount of TUs to get a kill.
*Includes some info for TFTD weapons, not yet including SWS weapons or Alien built-in attacks. The necessary information on TFTD Alien attacks is hard to find. I still need to merge in the TFTD Alien stats from the draft TFTD version of my Firepower spreadsheet.

==== Tactical Firepower Model ====

*Formula for Weapon Rankings

In a nutshell, I figure out the average armour-adjusted damage per direct hit (average of min + max, adjusted for % of range that is zero), then multiply that by the average # of direct hits per 100% TUs (assuming Firing Accuracy = 50). I then divide the target Health by the resulting value, to obtain the "%TUs per kill".

The "Weapon Ranking' number given is for whichever firing mode (auto, snap or aimed) gives the best value. I should probably list what the best mode is!

If your soldiers have a better average FA, it all scales linearly. So if you have FA=100 just cut (improve) the values by half. I picked FA=50 as its a typical starting value, and it was particularly the starting weapons I was interested in.

I tried lots of different "figures of merit" for weapons but I like this one best.

All HE is considered a direct hit on the Alien. For 4-square targets I add the reduced, armour-adjusted damage on the other 3 squares.

I did not bother with Incendiary as the damage model for incendiary is almost totally independent of the weapon used (the only weapon based factor is whether you get the target inside the area of effect or not, and how many times).

The very low (good) average values, such as for Heavy Plasma, will be very volatile around the average. The high (bad) numbers will be more consistent.

This Figure of Merit probably works best when the number is in the range 25% - 75%. Below that level, there is high volatilty and also I may not have accounted for overkill (minimum penetrating damage > Health) properly. Above that level, I have not accounted for reload time, nor "turn rounding errors" - such as: you can't burst-fire an AC 2.5 times a turn, you can only burst-fire it twice.

Another thing to note about this metric is that it is accuracy-weighted, so it assumes a non-trivial "firing problem". For situations such as point-blank where accuracy is not an issue, the rankings will be very different. I'll work on a different metric for point-blank.
My Firepower spreadsheet, which generated these rankings, allows you to toggle the "turn rounding" on or off. With "turn rounding" off, the calculations are "instantaneous" measures of lethality, which make sense for intra-turn decisions, or when a mix of fire and movement is important (as it usually is). With "turn rounding" on, you get a better assessment of "continuous" firepower - e.g. when firing continuously over multiple turns.

It would also be good to have others check my assumptions in the spreadsheet!

[[User:Spike|Spike]] 22:22, 27 February 2009 (CST)

=====Near Miss Modelling=====

One thing I don't calculate is the effects of any area effect/HE near misses. So the figures I give should be taken as a minimum. In practice, HE effectiveness will be somewhat higher due to the extra damage from near misses - but by how much? It depends on a lot of factors, some I don't know and some that are highly variable (density of terrain / map objects etc).

Calculating the range and average damage done by any given near miss is complex but not impossible. There are a large number of calculations, one for every possible 'near miss' square with different GZ+X distance, different armour facings, etc.

What is truly difficult is estimating the absolute and relative frequency of rounds landing in all these possible 'near miss' squares. With sound knowledge of the error angles (vertical as well as lateral) generated by the game engine, it might be possible to estimate a probability distribution, for each possible range from launcher to target - but only for a flat, featureless plain. It's the terrain features - fixed and mobile - that introduce the biggest uncertainty about where a stray round will detonate. This is almost possible to model. Without modelling for collisions with map objects, the 'flat plain' model of near-misses will predict a worst case (minimal) damage level from near-misses. (Assuming that in the typical case, the accurate path from firer to target is relatively unobstructed. When this is not the case, the 'flat plain' scenario might actually predict better results than obtain in reality.)

One more problem with modelling Near Misses: the benefit of lucky near misses - whatever its value - is inversely proportional to overall accuracy. A perfect shooter gets exactly '''zero''' benefit from near misses. Which raises an interesting possibility. Maybe the "near miss benefit" could be estimated using a repeated experiments with a logger and a shooter with Firing Accuracy=0. Any damage done to the target would be due to a lucky near miss. This would be the other limiting case - the opposite of the perfect shooter. Then extrapolate between those two extremes to find a "near miss benefit" for that weapon as some function of {TA, range].

: A lot of people have noticed this factor when playing, lol... A fresh low accuracy can't hit an alien at 30 feet... UNLESS you give him a rocket launcer or AC-HE, and then he suddenly turns into this deadly killing machine. It's... quite ridiculous. [[User:Jasonred|Jasonred]] 07:12, 22 March 2009 (EDT)

=== Other Tables ===

Data table comparing the "firepower", "payload" and other obscure characteristics of aircraft weapons:
[[Aircraft Firepower Table]]

Also I have uploaded some spreadsheets concerning [[Media:XCOMUtil Profits.xls|XcomUtil manufacturing profitability]]; [[Media:Detection chart.xls|efficiency of aircraft as radar detection platforms]]; [[Media:Multiple radar.xls|effect of my proposed multiple radar fix on detection probability]].

I have a version of the Manufacturing Profitability spreadsheet for TFTD, which I will put on the main pages when I can figure out how to wikify it.
Also, this version calculates full Technician/Engineer costs, including fixed as well as variable costs, and calculates the payback/breakeven period.

== Base Fixer ==

I've written a Python script that

* fixes the [[Known Bugs#Paying for Dirt|Paying for Dirt]] bug
* fixes the [[Known Bugs#Phantom Radar|Phantom Radar]] bug
* fixes the [[Known Bugs#Radar Stacking|Radar Stacking]] bug and implements my algorithm for improved effectiveness of multiple radars

It's working reasonably well now so I've uploaded the [[Media:BaseFixer.zip|BaseFixer]] utility and documentation to this site. You will also need to install Python for it to work. I have also used XcomUtil's hook facility to integrate BaseFixer into XcomUtil, so it runs automatically as you play (updates whenever you switch from tactical battlescape to the geoscape view). [[User:Spike|Spike]] 12:00, 24 March 2008 (PDT)
:I haven't given this much of a whirl, but I did have one problem: it searches for 'base.dat' in lowercase, and my BASE.DAT files were in uppercase (UFO is run in dosbox under Linux, and dosbos puts every created file in uppercase). Changing the script to use BASE.DAT in uppercase fixed that, but may break some other case-sensitive system where base.dat is in lowercase (Maybe UFO/Amiga?). Probably best to check for both styles? Also, it returned a somewhat funky result with a TFTD save, but I guess it wasn't meant for TFTD... [[User:Cesium|Cesium]] 20:28, 30 December 2009 (EST)
:: Yeah pretty sure it won't work on TFTD as I think the base.dat format is different. All these fixes are now included in Seb76's UFOExtender loader, so I would recommend using that instead. [[User:Spike|Spike]] 19:33, 31 December 2009 (EST)
:: I don't recall if base.dat was lowercase or not on the Amiga, but it doesn't matter, as although Amigas remember case, they use case-insensitive compare when accessing files. "BASE.DAT" == "base.dat" to an Amiga running on the native filesystems (OFS/FFS). [[User:Renegrade|Renegrade]] 01:14, 4 August 2010 (EDT)

==TU Efficiency==

Analysis and fixes (game file patches) relating to the fact that Aimed fire is less efficient than Snap fire. See [[Accuracy vs TU Efficiency]].

=Work in Progress=

==Underway==

*[[User:Spike#Balancing_Aircraft_Weapons|Craft Weapon Rebalancing]]
*[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
*Specific Proposals for XCU for craft weapon rebalancing and for tougher UFOs
*[[Air Combat Mechanics]] research
**Confirm whether XCom RoF randomises in the same way UFO RoF does
***Crucially, determine if the "Cannon timer" is ''itself a variable length of time''
:Experimental model - do timer tests of XCom weapon RoF vs UFO weapon RoF. UFO weapon RoF is known to be variable, by Seb 76's code decompilation.
:Try to give UFOs limited ammunition. Try to force UFO damage to a fixed value (e.g. 1) so that XCom damage becomes a "hit counter". Basically need to use small samples, small N, instead of large N. Instead of getting convergence on an average, you need to do the opposite, which is to look at the range of variation. Use the highest possible ratio of XCom RoF to UFO RoF (eg 2::96 reload rates) in order to expose the variation more easily? You need a histogram that shows the minimum and maximum divergence from the average. This will show whether a. more linear, more moderate variation := XCom RoF is fixed and UFO RoF is variable or b. more gaussian, more extreme variation := both RoFs are variable. Eg if both are variable, min variation would be 4:96, max would be 2:192. If XCom is not variable, min variation will be 2:96, max will be 2:192. So you need to do a large number of runs and find the minimum variation. But it needs to be a very large number of runs because the cannon RoF will tend strongly to the median value when firing 16 to 96 rounds per UFO attack. It's difficult to do without a logger. It would be nice to be able to peek the INTER.DAT-equivalent in-memory structure. Actually maybe it's easier to do if the XCom RoF and UFO RoF are matched at a high reload value, eg both at 96? Need to think this through more. If matched, min variation for static XCom RoF is 96:96, max variation is 96:192. OK, there's the strategy. Match the weapon reload rates, at 96 to make it easier to observe, and if the UFO ever fires faster than XCom, that proves XCom is (also) variable. That should be fairly easy to test. Maybe just use extreme slowdown in DOSBox to be able to manually count the "Interceptor Hit" messages.
***If the "cannon timer" is variable, what implications does this have? For overall firepower I don't think it has any, it's more or less my current (implicit) assumption. If the cannon timer is ''not'' variable, that has a bigger impact, because if XCom does not have variable RoF, XCom firepower just went up by 50%, unless there is some other compensating factor.
**Write up the results that are reasonably certain, and do high level updates to the relevant articles.
**Deciphering [[INTER.DAT]]
*[[User:Spike#Balancing_Infantry_Weapons|Rebalancing Infantry Weapons]]
*General game improvement suggestions for UFO Extender and/or XComUtil and/or [[Enemy_Unknown_Extended|"Standard XCom"]]

=== Older Stuff ===
*Craft Firepower table for TFTD - haven't I finished this? need to upload it. probably need to rewrite it based on new RoF first.

==To Do List==

*[[Enemy_Unknown_Extended|"Standard XCom"]] definitions
*Continue TFTD game in TFTD Blog
*[[Air_Combat_Mechanics#Effect_of_Attack_Mode_on_UFO_RoF]]

=== Older Stuff ===
*Incendiary Research
*Firing Accuracy Research - with Bomb Bloke's data, maybe using special terrain as a 3D scatter mask
*Seb76 UFOExtender
**Use "View All Locations" to empirically check the effect of (fixed) multiple radars - does having greater %detection at the same range really increase UFO detections, or will the same UFO get deteced eventually anyway?
*Gameplay
**Play an "Aliens Own Earth" game
**Play a "Funding Only" game
**Do a Cydonia mission - I've never stuck it out that far. Then do the mission again, but with conventional weapons and no Psi.
*Firepower Tables
**Add all missing TFTD target and weapons data, in line with EU targets and weapons - mostly vehicles
*Economics
**It would be interesting (and easy) to calculate the cost incurred when damage is sustained by aircraft. It would then be possible to put an economic value on the stand-off capability of weapons. - done as part of FBL discussion
**Efficient Market - Rational Costs
***Understand impact of Research costs (capital and expense) on Manufacturing Profitability, and thus on "rational costs"
****Necessary first step: Create a tree structure with the fully inclusive research costs to reach each node in the tree. If everything were profitable, it might make sense to attribute only the current nodes costs to any given item. Maybe it makes sense to amortise all research costs incurred since the last profitable item on the current branch? Or to share out the total costs along all paths, weighted by the profitability of each of the profitable nodes? - tree structure done and published on this site but with some errors where I thought there were prerequisites, but there are none. It would be great if there was an actual research tree on the site for both games.
***Adjusted buy & sell prices that better reflect the actual economic costs of manufactured items (assuming there would be demand for them outside X-COM). Then put this in a modified PURCHASE.DAT. The purpose of this would be to better harmonise manufacturing profitability of various item types.
***Also make it possible to buy (rather than build) the manufacture-only item types. Calculate appropriate prices based on fully inclusive costs, normal buy-sell spread, and some estimation of capital costs including Research costs. (See discussion in Economics - External Market, above.)
***Re-calculate manufacturing profitability, and manufacturing costs, based on Opportunity cost of diverting manufacturing away from profitable Laser Cannon.

=Apocalypse Blog=

==Apocalypse: The Verdict==

I got bored of this game very quickly. The real time combat is interesting to mess around with but ultimately a bit frustrating. I don't particularly like RTS's anyway, and this is not a great one. But it's the strategic game play that really falls flat. There is no story arc as in X-COM 1, I just didn't care about this artifical city and the weird alien invasion. Maybe it would've been better if the game was just about warring megacorporations without the alien "sub-plot". Then they could've built in some more plot.

If you took out the aliens and added in some more structured scenarios, it would work as a good remake of Laser Squad - the weapon mix, tactical focus and time frame seem to be similar.

==Snags and Hassles==

Like everyone I found it impossible to figure out how to load soldiers into a vehicle for a mission. Eventually I had to download and RTFM. I still don't know how to persuade the soldiers to take a vehicle home from a mission, so they walk home. Maybe I need to click on the building, or vehicle assignment screen, right away before they walk out of it, and reassign them to the vehicle before they start walking? Anyway, for now the walk will do them good. Good exercise and they can walk off all that aggression.

It seems like you automatically strip equipment off dead enemies, but you don't automatically strip the equipment off your own casualties, even if you win the battlefield. I am sure this is true because I am not only loosing armour, I am loosing Mind Benders. That's a hassle, if I have to manually take equipment off my dead guys, and make sure I do it before the mission ends. Maybe the equipment is just being blown up by HE? I noticed that the enemy seemed to be surprisingly vigorous in attacking the dead bodies of some of my guys, so maybe that's it.

It was totally non-obvious to me that you should raid neutral organisations for profit and plunder. I could've played for years without doing that, had I not read about it in strategy guides etc. It seems very cynical, not the vibe I would expect.

I don't like the Dual Wield stuff. Lots of games have dual wield, and I think it's always nonsense. Twin cannons, twin rifles? Give me a break. It is catering to the Arnie / Ninja crowd. If you use a 2 hand weapon in each hand you should get a big penalty on the primary and an even bigger penalty on the secondary. It would only ever be viable if you had no need for speed or accuracy and just wanted pure volume of fire. I can just about buy it with handguns, but not with anything else. Even handguns are supposed to be used with two hands, except for snap fire. If you think dual wield is accurate, ask yourself why no military, police or special forces unit anywhere, ever, uses this technique. It's only from dumb movies. I am annoyed that the mechanics of Apoc make dual wield advantageous. Apart from being stupid, it's an unfair advantage over the enemy since they don't use it (or do they?). I suppose I could just be self disciplined and just not use any weapons in dual wield. Stick to my principles!

I guess dual wield makes it harder to use grenades. Although apparently there is no TU penalty in Real Time mode for shouldering your rifle to grab a grenade? I find it too fiddly though. I need to learn, as grenades are powerful and they give an edge to the enemy if I can't use them.

==Weapon Mixes==

At the start it looks like the priorities are:

*Improve Agents' experience
*Conserve money
*Conserve ammunition

It looks to me like the Sniper rifle and M4000 have about the same firepower (accuracy x fire rate x damage), but the M4000 has much higher ammo consumption (both per unit of time and per hit). So the top choice would be the Sniper rifle. As there are not that many around at start, I would give the Sniper rifles to the people with the lowest Accuracy score (contrary to the USG advice), and then M4000s to the rest. As I capture more Rifles I would put the M4000s into stores (for the next batch of recruits).

Of course the Plasma gun has greater firepower but it's so rare and the ammo so limited and expensive at the beginning that I would only issue it to the Agents with the highest accuracy, and then only during a UFO recovery or alien capture, not during a regular raid. Train up combat skills using cheaper and more plentiful weapons, and save the Plasma gun ammo for the critical missions.

The Autocannon I would only issue to a minimum number of agents with the highest accuracy and strength, and use it as a support weapon. Probably to your starting Androids. One or two Agents with autocannon is fine. Also I would not bother with the AP rounds. Because of the low accuracy and low rate of fire, the AP firepower is lower than the other starting weapons. I would stick to using the area munitions (HE/IN), employing the autocannon as a support weapon. The one exception for AP would be against armoured targets - a very specialised mission in the early game.

Actually, according to my theoretical calculations, in Dual Wield the highest firepower (apart from the rare and expensive Plasma gun) is actually a pair of Lawpistols. This is because the lack of one-handed penalty pushes their firepower ahead of the M4000 and Laser rifle. Of course the ammo capacity is the worst, and the range is not good, and at close range maybe accuracy is less important.

Anyway, if we have the Marsec M4000, where's the Marsec Auto-Gun? That was always superior to the M4000, in Laser Squad anyway.

As I don't really understand the mechanics, the above may be totally wrong. Maybe some kind of TU factor gives a disadvantage to the Laser Rifle. For example, in Real Time, maybe a fast moving target won't be acquired in time by a slow weapon like a sniper rifle, even in snap fire mode. I think the Sniper rifle is the best for experience gain but I could be wrong about that too. The USG says experience gain is per ''shot''. This is almost certainly wrong - surely it's per ''hit'' - but if it's right, the M4000 would be the experience-meister, since it spews out (inaccurate) rounds.

In terms of purchases, I found I pretty much buy all the personal arms on the market (apart from some of the armour and AP grenades). I'll probably find a use for all of it. Definitely buy all the Mind Benders and Laser Rifles as these are relatively rare - especially the Mind Benders.

==Psionics and Psi Raids==

There is not a lot of info out there on the net that I can find about the Psi mechanics and Psi training mechanics. The USG has an illegible formula that I can't decipher, and it's not clear if it applies to field/combat experience or just to Psi-Lab training.

I'm trying to figure out the Psionics by experiment, and in pursuit of this I've invented a variant of the Stun Raid, the Psi Raid.

As with a Stun Raid you can go on a Psi Raid and keep all weapons locked, and just use Psi, and you don't get shot at. Even if you come off the borders of the map and walk in and around the building. You get 0 mission points but you don't trigger any Organisational hostility from the organisation you are raiding. I was doing successful Stuns (well I got the hammer on the head icon, but no one actually fell over). I was doing successful Scans. None of it provoked any gang guards to attack with weapons. I did get one Psi attack on me. I don't have anyone who can attempt Mind Control, but I should also do some Panics to see if that provokes hostility. Maybe if I actually knocked someone out with Psi, that would provoke hostility. I have 4 Agents capable of Stun and one capable of Scan only, but even piling up on one target I could not actually make them pass out from a Stun attack. Still they are all only Rookies.

My intention was to train up the Psi skills from combat experience, but I did not see any noticeable improvements after combat. Certainly any improvements were less than 1.0 stats. Maybe you need to make Kills to gain experience. Maybe it can only be trained in the Base, not in combat. (In X-Com 1 and 2, raising Psi stats in combat creates a runaway feedback loop that is unbalancing, and also makes Psi Labs pointless apart from for screening, so maybe they fixed that in X-Com 3)

What would a successful stun look like? Does it decrease Health with a white bar like X-Com 1 and 2 (apparently not), or decrease Psi Strength until you go unconscious? Maybe use will use Scan in conjunction with Stun Gas to see how Stun Gas works.

It seems like not only can you not do a psi attack if you are not in Line of Sight (fair enough), but also not unless you are on the same map level as the target. So even if you are one square in front of a target and up one level, you can't use Psi on them. Maybe something else was happening. Two of my Agents seemed to start getting 0% all the time, even if they were on the same level, in LoS, without having moved, full TUs and full Psi Strength. Is there a maximum number of attacks you can make in one mission, or a maximum amount of Psi strength you can expend? Do the Mind Benders actually need to recharge back at base at some point?

- OK I think this was just due to targeting stronger opponents (higher Psi defence) and the probability, particularly of Stun, dropped to 0%. You definitely '''can''' do a Psi attack from a different level. And I don't think you ever run out of Psi attacks during a mission, having done a lot more attacks now. Also, Panic attacks also don't trigger hostility. But then, I still haven't managed to do a Stun or Panic attack that actually seemed to affect the target at all. The attacks are "successful" but don't seem to do anything to the target, or reduce any of its stats (as viewed via Probe). Hmm.

Also (not a Psi note but a general one), switching weapons to and from any area takes no TUs. The only thing that takes TUs is picking up. Dropping is free. So the backpack is no different from a holster. Swapping your autocannon into your backpack and pulling a grenade takes 0 TUs. Presumably the effect is similar in Real Time mode. Not sure I really like that, it seems sloppy on the part of the programmers.

= TFTD Blog =

After a few goes of mucking about with TFTD over the last year, I started a proper campaign. It has been very
interesting so far.

I have much more favourable impression of TFTD now than I did before. Yes, it is more buggy than UFO. But luckily we
have the guidance from the [[TRTBAG]] and from this Ufopaedia wiki to guide us. I have to say, I didn't feel
comfortable starting on TFTD until I was familiar with the "gotchas" which (fortunately) are documented here. And
it's also true that Ufopaedia is patchier on TFTD than it is on UFO. Some of the gaps are hard to find - I've been
trying to fill some of them in as I go along.

TFTD is definitely a more challenging game. But it also unexpectedly better balanced than UFO in some ways. It's not
just a case of buffing the bad guys (though that happens of course). I have been finding that in TFTD every decision
is much more finely balanced. The trade-offs between different technologies, different weapons, and different
tactics and strategies are giving me much more of a headache. In UFO, there is often a well known "optimum
strategy". Things aren't so cut and dried in TFTD. I found the technology decisions really hard. There's not a lot
of stuff that you don't need (unlike in UFO where you can skip a lot of it, or where research is so easy you just
get everything). I've been struggling for months over whether to prioritise craft weapons (Sonic Oscillator),
tactical weapons (eg Thermal Shok Launcher), or Transmission Resolver. Mind Control, Subs, and Armour I am not even
thinking about. But even these three categories are very tough decide.

Luckily the game forced my hand, due to another increased challenge - shooting down USOs. In UFO this is not a big
deal. In the first few months you can shoot any small-medium craft down easily with dual Avalanches, maybe 2
aircraft, and you have this capability from the first week. Anything you can't shoot down, you can often just tail,
and it will conveniently land. Not so in TFTD. In many cases you can't even reach the USO to intercept it, let alone
win the battle. They either out run you or go too deep - much harder than in UFO. There is no pain-free stand off
combat, either. And the USO return fire is ''harsh''. By month 2 it was quickly becoming apparent that my subs were
outclassed and I was going to fail most engagements - and lose my ships in the bargain. I realised this was the
strategic imperative. Winning the battlefield with inferior weapons would be a challenge, but without success in sub
battle, there just weren't going to be enough battlefields. I needed something to even the odds on the Geoscape, or
I was doomed. Going for improved Sub technology just takes too long, I would be dead by the time I got it, so
instead I am going for improved sub weapons - in other words, the Sonic Oscillator.

Of course, they make Craft Gauss Cannon look like a waste of effort for purely weapon purposes. I thought long and
hard whether I would go down the "Gauss Cannon Factory" route, but decided not to. The Particle Disturbance Sensor
is 50% as cash-generating as the Gauss Cannon, and you can be up and running in days. I didn't research it until I
had that realisation in the teeth of the "what do I research" dilemma. In hindsight I would've researched PDS first,
since it was nearly 2 months before my Technicians had anything much do.

So anyway, I went with Sonic Oscillator, and of course this has the benefit of picking up the battlefield sonic
weapons along the way, conferring (battlefield) tactical advantage. Now it's early March, and I've just got
capability to use Sonic Cannon, and this had made me realise something else. When you use Sonic Weapons (or Plasma
in UFO), it really costs you money! Some people think these weapons are free when you pick them up off the
battlefield but, not at all. You pay full cash value for these weapons in foregone revenue. That means other things
are starved of investment. For the price of a single Sonic Cannon and clip, you can build seriously useful buildings
on your base! To put it another way, if you had to pay $200,000 cash for a Sonic Cannon, I wonder who would bother?
Gas Cannon are about 30 times cheaper, and not much less effective (not at the stage I am at now anyway).

Yes I definitely fell in love with Gas Cannon. My standard loadout now in early March is Sonic Pistol (just
acquiring Sonic Cannon), GC loaded with HE in the backpack for those strong enough to carry it (about half or two
thirds of the troops), and/or a Gauss Pistol for close-up 'n personal work on soft targets. And, of course, one to three Sonic
Pulsers. It's a great combination. Just Gas Cannon and Sonic Pulsers worked superbly in January. As most people do,
I ditched the Dart Guns and Dye Grenades immediately, and ditched the JetHarpoons as soon as extra Gas Cannon
arrived. I researched Sonic Pulsers literally as soon as I got one, and they were in field use by the 2nd week. I
tried mixing in the Hydro-Jet Cannon but it just wasn't working for me. And then (despite my posts on the
Ufopaedia), I fell foul of the HJC pitfall - I turned up at a land mission and I'd forgotten to swap out the HJCs
for spare GCs. Doh!

(In my first Port Assault, I made the same mistake by bringing my Coelecanth/AquaJet along. Still, it was a useful
''unarmed'' reconnaissance vehicle!)

The HJC snafu convinced me to no longer put HJCs on the boat, apart from a single phosphor-sprayer for night missions. Sometimes
I gave the guy carrying that an AP clip, but I'm not sure if there was much point. I had nagging doubts that HJC-AP
might be useful in close quarters, frontal assault missions, so I kept them in Stores, at least until the Gauss
Pistol came along and fully displaced that close range assault role.

Of course, the initial joy of watching a crack (ok, rookie) Gas Cannon squad dispatch Aquatoids with GC-AP quickly
wore off. Superhuman Gill-men have a habit of shrugging off a GC-AP round. Nonetheless, I just thanked my lucky stars I wasn't
using anything weaker.

I researched Gauss just to fill in time and because it's so quick. The Gauss Pistol is a big improvement and an
equaliser that it's hard to forgo. So very briefly in late Jan / early Feb I had a Gauss Pistol / Gas Cannon mix.
However, as soon as I captured the first Sonic Pistol I had stopped all research to focus on that, so there was only
about a week between Gauss Pistol adoption, and it's semi-obsolence, as Sonic Pistols were issued to all combatants (I'd built up a stock - one advantage the alien tech has over the human, you can really hit the ground running once it's researched).

(At this stage I was running one ten-man combat team and I had just added a second). Then the primary mix became as
above: Sonic Pistol as main combat weapon, GC-HE as the heavy/support weapon, Gauss Pistol for close quarters work,
and plenty of Sonic Pulsers for anything tactically tricky or scary.

I gave up on the Gauss sequence after the Pistol, after making the decision I would not go down the Gauss Cannon
Factory route. There seemed to be plenty of more important things to research, urgent things that couldn't possibly
be avoided. I didn't feel like I had any luxury of choice. In fact, it felt like I couldn't possibly get it right,
that whatever trade offs I made my skipping technology A in favour of technology B would come back to bite me. I
really do like that in TFTD, I think the research decisions are much more challenging.

The tactics are different in TFTD and also pleasingly challenging. I have to be much more careful than in UFO, and I
like that. Bunching up is definitely out of the question - the aliens are noticeably more aggressive with grenades.
There is much more thought behind the maps. Many of them are really painful. Sometimes it seems a bit contrived, but
it's only fair since the aliens have such a dumb AI - they need an equaliser in their favour.

One thing it made me wish for, aside from a smarter AI, was that aliens would pick up weapons. Because the game
advertises when they panic, and visually shows when they are disarmed, you then pretty much know they are no threat
(within reason: they may have psionics, or grenades). So you can just wander up to these shell shocked aliens and
stun them with impunity.

Good grief, capturing Calcinites is hard! I was prepared to trade a rookie for each captive, but it was much worse
than that. I had to reload after I sent 4 guys into a room to get one Calcinite, and they all died. (Turns out there
were TWO Calcinites in the room!). But I actually like the way it works. It's different enough from "eeny meeny
meiny mo, catch a Navigator by his toe" in UFO. It feels quite a lot like what Scott Jones does in his XcomUtil
option "research help from captured aliens". Ok it's really only a few of the aliens, but capturing them is so
crucial, and also so hard to do, that it really adds to the excitement. Maybe if I'd caught a Deep One on my first
Terror mission I would be more blase about it. Unfortunately I kept shooting the Deep Ones, thinking there would be
another one along later, when things would be just a ''little'' calmer and I could take the time to stun one. Sadly
the game ended and I got no Deep One prisoner. So I had to go after a Calcinite instead. What fun they are! I think
they are the only monster in the game that can shred the front armour of (XcomUtil improved) tanks.

Mind Control, of course, absolutely kills you. This was my biggest dilemma. In the end I figured it's better to get
the missions, and get crucified each time by alien MC, than to not have any missions. No missions means no tech, no
experience, no points, no money. It's a declining spiral. It's possible to manage without MC or even MC Labs. You
just have to note anyone who is influenced, disarm them or stun them immediately, and drop them from the roster when
you get back. Everyone carries a Stun Rod, everyone watches everyone else. In this way, I will just have to tough it
out for now, and get MC Labs later. Of course, I don't doubt that if I don't at least have MC Labs by April, I will
be finished. I played a short campaign before and that's what happened. Plan sailing until April when the Tasoths
showed up - curtains in May. So I need to avoid that. But to get MC technology, and research it, and pay for it, I
need to be able to fight missions. So it's a very high priority but it has to come second. If I have to, I will
fight this war with nothing but Gas Cannons, so long as I get my Sonic Oscillators and then my MC Labs. Transmission
Resolvers, Armour, that's all by-the-by. One day I'll need Subs, I know, but I can't see that far ahead from where
I'm sitting now!

== January ==

'''Setup:''' I'm using the Steam release of TFTD, with XComUtil installed but with most of the defaults turned off (apart from
Improved Tanks). Mainly so I can use the command line '''xcomutil dis''' to see if the mission is something I've played before.
If I've played the scenario, alien type, and map type before, I just tend to do xcomutil "win". This gives me
maximum loot and no casualties, but it also gives me zero experience, so I think it's a fair trade off when I can't
be bothered to do the exact same mission again. If they are small ones I usually do them through even if they are
the same. But anytime there is a new race, new scenario, or new map, I do it all through manually. Very satisfying!
For laughs I'm running the Steam release under DosBox on Ubuntu Linux. This is quite easy, you just copy the steam
files (under "steamapps", "common") to a Linux directory and execute the existing dosbox.conf script. Even easier if
you are using Wubi which sits on the same filesystem as your Windows installation. You can also do groovy things
like add XcomUtil and possibly other third party things, as long as they are pure DOS. I think I put more
instructions in the "Steam Releases" section of this Ufopaedia. For me the main benefit is not having to do that Steam login and update check
each time.

I started on Superhuman with a base in the Straits of Hercules, called "Atlas". Everything went swimmingly. Plenty
of missions, though noticeably more difficult to intercept and shoot down than in UFO. The Gas Cannon-AP reigns
supreme. How I love the satisfying "chumf" of the cannon as it takes big hunks out of the bad guys. And crazily
accurate as a sniper weapon.

Got Sonic Pulsers researched as absolute top priority and they are almost too powerful, you don't need them really
except to rearrange the landscape. Or get yourself out of a tight situation - about ten times at last count. :) It
was nice not to really have to learn how to chuck Magna-Packs around.

Developed a second strike base, Shiva, in the Indian Ocean, as that was the red hot activity area this month. I
never know if it's worth building a base in the hot spot, it seems you are always chasing your tail as the activity
moves on by the time the base is built. Still, I suppose, you've got to build 'em somewhere. As long as the
locations make reasonable sense, why not?

At the end of January, an Island attack on the Seychelles. This was a lot of good clean killing fun. As noted above,
my guys were enthusiastically dropping the Deep Ones and nobody stopped to think we should perhaps stun one. Why did
we built that Alien Containment thing anyway? (Actually I hadn't read the TRTBAG properly at this point so I didn't
realise how crucial it is to capture a live Deep One. The Research section for TFTD could probably use some tidying
up, as it assumes you have a research tree to hand such as from the USG, but actually, we don't have that on here).

== February ==

First time through, February was a disaster. A lost month that cost humanity its future. But literally, nothing
happened the whole month. I just thought it was one of those "drought" months that teach you not to over-commit on
your base buildup and costs. I watched the graphs (or so I thought) and there was nothing for me to intercept, even
though I had Barracudas out as much as possible as sonar pickets. Then at the end of the month, funding cuts all
round, huge loss of score, alien Colony in Antarctica, and an immediate port attack in the US - way out of reach of
my only Triton as it limped back from an abortive Colony raid. How are you supposed to raid a Colony in February for
heavens' sake? Well I thought it was pretty clear that the Committee were going to hand me my behind if I didn't go
and take of the problem.

I only fought the upper Colony level, thinking I could maybe bag some useful corpses and items and then abort, learn
some lessons, and come back stronger. I got absolutely crucified. We made them pay though. Gas Cannon HE really
stuffs a Hallucinoid. And Sonic Pistols are fine for taking down Tasoths. But the MC, and the Tentaculats - it was
too much. I think the guy who wrote the Colony Assault article is probably right, don't attempt it without DPLs,
armour, and good MC. All I had vaguely in that league was one Thermal Shok Launcher and 3 rounds, plus Sonic Pistols
and Gas Cannon. Here, the Sonic Pulsers really came in to their own, but I was using so many, and taking so many
casualties, that I ran out. But it was the MC that was the killer. In the end only the tank survived, along with one
Aquanaut who wigged out early enough in the battle to be stunned and safely stashed in the Triton. I actually waited
out 30 nail-biting turns with my tank gun pointing out the door of the Triton until she woke up to fly that boat
home. But I realised I'd had enough.

Anyway I replayed from the start of Feb, developed 2 Tritons and 2 combat teams, 2nd and 3rd bases, and played
''much'' closer attention to the graphs. This time, when Brazil and Antarctica and the US picked up on the graphs, I
sent long range Triton pickets and sat them there. I still didn't intercept anything, not a single mission or even a
detection in the affected areas. But I guess somehow my presence scared them off, because this time around I got a
massive score in February instead of a massive slapping. Quite odd, as literally all I did was park Tritons over the
affected area, I never fired a shot.

I managed to down a Battle Ship somwhere around the GIUK gap, (and I realise a TFTD Battle Ship is one down from a
UFO Battleship) by using everything I had, which was just 2 Barracudas and DUPs. I got lucky (I know I got lucky
because I replayed it 3 times, so I got 3rd time lucky.) Even so, one Barracuda was over 90% damaged and out for
most of the rest of the month. But it was worth it, as there was a famine of missions and I needed the loot. Luckily
it was just Aquatoids with Hallucinoids, and the MC wasn't too harsh - just enough to teach me who was weak, and
rotate them out. And the Hallucinoids make a superb "popping" sound when you hit them with the last GC-HE. :)

Started a 3rd base in Antarctica since the bad guys were hitting that really hard - according to the graphs, but I
never saw a single craft. I only got my sonar up about the 25th of the month though. Normally in a new base I build a standard sonar
as well as large one, so I get the traffic picture 15 days earlier. This time I economised. I guess we will never
know what those green skinned blighters were up to down there. :)

And this time at the end of the month was a surprise and luckily not a disaster. I was doing one of those tricky
"order it 72 hrs before the end of the month" moves. And it turns out February 2040 is, indeed, a leap year - ending
on the 29th and not the 28th. And I thought for a moment it might be a bug. Just a little Easter Egg for us from the
good Brothers. :)

== March ==

First week.

First Port Terror Mission. I love the map. It feels like fighting urban warfare. It's clever without being
contrived. I didn't get the chance to explore the water feature. If there were any aliens in there, they came out,
since I won without exploring it. Extremely tricksy to get a tank in there. There is only one ramp for the tank, and
it has debris you need to clear, but if you use a Sonic Pulser that destroys the ramp. I could've tried a GC-HE
instead maybe. Maybe next time. Apart from anything else I wanted to get my tank in the water because I stupidly
brought a Coelecanth/AquaJet to a land mission. It was brand new, it's first outing as well. (Remember that quote in
the Untouchables: "Just like a Mick to bring a knife to gun fight" - I felt like that.) I tried quite a few times to
get the tank to reaction fire its rockets, leaving it with nearly full TUs and my guys all cleared back behind the
firing arc, but no dice. Maybe that only applies to human-carried underwater weapons?

Got Sonic Cannon. Working through the other Sonic techs to get Sonic Oscillator which is the real prize. Using Sonic
Cannon tactically is a curse in disguise, it robs too much cash. I may have to consider if it's really needed.

I am, as usual, dirt poor, building and selling Particle Sensors to keep the lights on. Selling 8 or so Sonic Cannon
instead of giving them as toys to the boys in the boat might've made a difference - like about a $1million or so!

And, I've just realised... I fought the Port mission from my new rookie base in Antarctica. I have to hand it to those guys, they did an amazing job, all absolute first timers and only 2 out of 10 dead, for 18 aliens zeroed. But... I didn't have Alien Containment in the new base! Aargh! What a rookie mistake. And if I'd realised that, no one would've died, we would'nt've been running around trying to stun Calcinites like John Cleese from the Ministry of Silly Walks. We'd've just nuked the blighters. Oh well, live and learn!

''To Be Continued'' (Famous last words!)

Talk:PALETTES.DAT

2010-08-04T03:23:27Z

Renegrade: New section: Tactical Palette - last 16 colors.

Just for a bit of general --[[User:Darkfred|Darkfred]] 07:29, 13 June 2007 (PDT)information, it might be worth mentioning that some of the palette entries are used for colour cycling. For example the radar pings on the intercept console. That's achieved by shifting a whole block of palette entries to give the effect of movement. (Think KITT's chasing lights) The image doesn't change, but the colour that you see does. It results in a wave movement. If anyone remembers the shifting colours on ye olde Windows startup screens, this was achieved in the same way.

Other palette swaps include the greyscale background bitmaps that are used in the Geoscape screens. They keep the same palette entry, and the game only needs to shift these entries to different shades to change the shades of the backgrounds.

Come to think of it, anyone know what conditions change the normal backgrounds from red to purple? It seems to vary.

Also another random technical tidbit, the game uses mode 13h for its display. In other words 320x200x256clr VGA mode. It used to come standard on all SVGA cards as a safe mode to revert to. The first fifteen colours after the transparency were probably left behind for use by the console. They appear to match the old text mode 16 colour palette.

- [[User:NKF|NKF]]

-----------

In the case of the background images, the palette swaps are pulled from [[BACKPALS.DAT]], but I never realised the intercept radar was a palette cycle, though it does make sense - I assume that's handled entirely by the executable.

Oooh, I didn't know mode 13 was a *real* display mode! I thought it was just a "prebuilt" mode that QBasic provided to "script kiddies". XD

Not sure what you mean about those fifteen colors and how "They appear to match the old text mode 16 colour palette". I checked QBasic's idea of what the default mode 7 palette should look like (mode 7 being a sixteen color only version of mode 13, but with multiple "screens" you could flip in and out of the display buffer - guess you could call it EGA?) and it doesn't match the colors in any of UFO's palettes. But, I dunno if the palettes QBasic used followed any real standard, or if I even know what I'm talking about. :)

- [[User:Bomb Bloke|Bomb Bloke]] 04:56, 12 June 2007 (PDT)
: Xcom was built for mode 13h with a 6 bit ramdac, (hence the 0-64 color values). This was one of the few modes which was widely available and worked the same on all early pc's. It was started via interrupt 13h also called MCGA and the bios did all the setup work. I don't think there was a default mcga palette, but it could be the default EGA palette.
: The palette animation could be done either way, I will check on this, but it might just be easier to switch the pal to grayscale, and take a screenshot during the animation. Then look at the color values. In the windows version the palettes are entirely faked anyway so doing it via code wouldn't be any slower.--[[User:Darkfred|Darkfred]] 07:58, 12 June 2007 (PDT)
:: It's actually interrupt 0x10, with AH=0, AL=0x13. The 6/18 bit entries in the palette table was, and still is standard for 8-bit palette modes in VGA. [http://en.wikipedia.org/wiki/MCGA MCGA] was also an actual card, between EGA and true VGA. Mode 13 has an additional benefit for 16-bit DOS mode programmers in that the entire memory map for the card (320x200x1 byte/pixel = 64,000 bytes) is available within a single segment, meaning no bank swapping is necessary (much faster). The Amiga version(s) of XCOM would have used a 4/12 or 8/24 bit color resolution though, depending on whether it was OCS/ECS or AGA. I can't remember which Amiga version I had though, or whether or not it looked "ECS-y" or not. -- [[User:Renegrade|Renegrade]] 09:47, 2 February 2010 (EST)

-------

Not sure what you mean by "palette faking"... I know that if you take a screenshot in the CE version of the game (F12), the resulting image will be a 256 color job using whatever palette the game was supposed to be using at the time.

Hence my thought was to just take multiple screenshots of the animation, and check to see what the palette looked like. Sure enough, colors 112 through to 127 (16 in all) cycle through shades of green, whereas the image itself doesn't actually change.

- [[User:Bomb Bloke|Bomb Bloke]] 17:53, 12 June 2007 (PDT)
: Good work! Very cool.
: This may be boring but I will explain what I meant by palette faking. Its interesting but not terribly useful unless you wanna mod the exe.
: Palette Faking: The CE version of UFO is actually rendered in 32bit color at 640x400. You can take a screenshot of this version using the PrnScn key on your keyboard. The image you get when you press F12 is from UFO's fake internal MCGA buffer.
: When UFO was converted to a windows application the developers cheated, they made a copy of the mode13h memory in the executable, which they use as if it was the actual screen. They also make a fake copy of the palette. Then after each frame is drawn they copy this into the 32bit DirectDraw surface. They convert from the MCGA format into 32bit and run an upsampling filter (2x to 640x400). This is why the edges of letters look smoother in-game then in screenshots.
: The upshot is that the CE game is the exact same game code, only wrapped with a mode13 emulator. Cool huh. This is what allows the Exe Splitter and filter changing mods to work, 90% of the work is already done. --[[User:Darkfred|Darkfred]] 22:03, 12 June 2007 (PDT)
:: It also implies that those who did the Windows conversion were not the same programs who made the game. The original programmers would have done it seemlessly rendering into the DirectX buffer. The CE programmers may not have even had the sourcecode, the hack could be done without it. (although audio might not be so easy I donno). --[[User:Darkfred|Darkfred]] 22:07, 12 June 2007 (PDT)

:::I believe the programmers that did the Win32 port may have had access to the source of the original executables. Lots of constants and other tables for both the executables seem to be lumped together at the end, which is why you can't always get a rough match for some variable offsets in the dos version and the executable version. They aren't just both of the original executables mushed together with a bit tacked on the end(or front) to get it to work with Direct X, as I originally thought.

:::Come to think of it, pressing print screen in the CE does take screenshots, but the palette information isn't carried over, so the bitmap that ends up on the clipboard is ruined. - [[User:NKF|NKF]]

::::My UFO version is calling DirectDraw and requesting a 640x400x32bit display mode. It also makes nice 32bit screenshots when i press printscreen, I just verified this. It may be that there is some difference between our versions? --[[User:Darkfred|Darkfred]] 23:34, 12 June 2007 (PDT)

:::::It's not the game. I think it might just be the way some implementations of Windows handles screen captures. For lots of players, the screenshots palette will not be captured, and because the individual pixel index colours aren't saved, the image on the clipboard is ruined and cannot be recovered. I guess your clipboard works a lot better than most of us! (Or I suppose it could be your display mode). Using Printscreen with the dos version of the game works fine though, and the palette information isn't destroyed. My old copy of Windows 95 used to doubled the dos screen's pixels as well. Oh well. For now, the Collectors Edition's special F12 screen capture key for UFO/TFTD is still the most reliable method to capture screenshots. No matter how the game is displayed, the screenshot is stored as a 320x200x8 TGA file in the game directory- [[User:NKF|NKF]] 00:36, 13 June 2007 (PDT)
:::::: I don't see how the palette could be the problem though, my version of the game simply has NO palette. It is all converted to 32bit being put on the screen. And the screen doubling is using the SuperSai algorithm, which only works on 32bit buffers. The only thing I can think of is that perhaps it is receiving a 8bit buffer instead of the 32bit one it requests, but this doesn't make any sense. The most likely explanation is that the color problem is either a difference in our versions or a bug in your video drivers. --[[User:Darkfred|Darkfred]] 07:29, 13 June 2007 (PDT)

::::::: I doubt it -- it's almost certainly a matter of exact environment. UFO/CE/W2K with the graphics fixup loader against NVidia drivers is palette-corrupted (just tested), so any chance of PrintScreen working normally on this platform is from using PrintScreen against an emulator. --[[User:Zaimoni|Zaimoni]] 16:28, 13 June 2007 (CDT)

::::::::I am beginning to think that my highres 32bit version is the result of one of the mods I installed, i just don't know which. This would explain why the code is done in this way, stubbed into the beginning of the executable. Come to think of it I don't have any flashing screen problems like I did before either. hmmm. Well it works and I really don't care at this point. --[[User:Darkfred|Darkfred]] 16:40, 13 June 2007 (PDT)

------

Under CE, a printscreen will give you an image with a corrupt palette. F12 gives you a proper image.

The only way (that I know of) to get a 2xSaI effect is to run [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's executable]. Best I could make out, most of his extra code is tacked onto the end of the file... Printscreen will work "correctly" with this version, though F12 will still give unscaled images. This version of the game also has a variety of other differences to the usual engine (never checked the full list, but I gather there's some timing tweaks as well as a different way of handling sound).

The game uses DirectDraw regardless. Without f0dder/Mok's patches, the graphics (usually) won't render correctly. f0dder blames the DirectDraw implementation in his patch documentation, which'll be why disabling hardware acceleration is another way of fixing things up.

The CE game is remarkably similar to the Dos version, but there's a handful of differences. Although the game handles most errors by either ignoring them or crashing, it actually responds to some of them with intellegent messages. For example, if you pass it an over-filled [[MCD|MCD array]] (easy to do when running my damage testing tileset, just visit anything larger then a scout ship in the desert), you'll get a pop up box complaining about there being "too many map codes". You also get missing file messages if the game can't find inventory screen images.

The most famous difference is the vertical waypoint bug (where a blaster bomb missile told to go directly up or down will instead fly off on an angle - The aliens often kill themselves with this one). Though it's still my guess that the coders who ported the game just changed as much code as they felt was needed to make the game compile as a windows executable, and left it at that.

- [[User:Bomb Bloke|Bomb Bloke]] 02:06, 14 June 2007 (PDT)

== TFTD's Depths ==

Just recalling what I deduced ages ago while playing the game using X-Comutil and the map and depth picker, I agree that the palettes are adjusted on the fly. Having a sea bed map appear grey on land but appearing blue in water was quite strange - it wouldn't make sense to duplicate all the images for the various depths. The simplest way to achieve this effect would be to tint the palette with blue, and just darkening the images to simulate depth would be quite easy. Also I recalled that in UFO that the background images in the various screens were all grey, but on-the-fly changes to the palette allow them to change between colours like red, olive and purple. They have their designated set of colours in the palette too if I'm not mistaken.

One good way to find out would probably be to replace an entire row of colours with the same colour, then observe what happens in the various depths. I was going to suggest pure white, but then you couldn't go up any further which would be needed for the tint. Perhaps a middling value like 128, 128, 128 for a flat grey.

- [[User:NKF|NKF]]

----

I started looking into the palettes in more detail so I could convert UFO graphics to TFTD's colors, and vice versa. I took a screenshot of TFTD CE and ripped the palette from that (as the colors for the battlescape didn't seem to be in Palettes.Dat).

After the first conversion, most of the colors seemed "ok" but some (eg. rocks) came out blue when Daishiva's PCK viewer declared them to be grey - and surface terrain (eg. grass and trees) looked decidedly off...

I then took a ton of screengrabs and eventually decided on a total of four palettes. I'd completely forgotten that TFTD used depth settings as well as time of day so it took me a little while to work out why the things kept changing.

It wasn't until I loaded up XcomUtil to force certain map types that I finally saw the light. Four palettes, four depth settings. One good example of the effect is the "atlantis" terrain (which makes heavy use of grey stone).

- [[User:Bomb Bloke|Bomb Bloke]] 20:16, 1 January 2008 (PST)

-----

I've been doing some stuff with the color-swapping SCR files and noticed that they index E0-EF, the second-to-final 16 palette entries. Currently the page says the BACKPALS.DAT palettes replace the 16 final entries. Is the page wrong or is there something I'm missing?

- [[User:Majorlag|Majorlag]]

== Tactical Palette - last 16 colors. ==

The last 16 colors of the Tactical Palette are more exactly this, I believe:

<PRE>
240: 39,40,40
241: 35,37,37
242: 32,34,35
243: 29,31,32
244: 26,29,30
245: 23,26,27
246: 21,23,25
247: 18,20,22
248: 15,17,20
249: 13,14,17
250: 11,12,15
251: 9,9,12
252: 6,7,10
253: 5,5,7
254: 3,3,5
255: 0,0,0
</PRE>

(these are out of 63, rather than out of 255, as per VGA hardware registers)

I did a dosbox screencap from XCOM-DOS v1.4 and extracted the exact palette from the resulting PNG and got values that were evenly divisible by four, suggesting that dosbox merely multiplies the value of the register by 4 (left shift by 2) to make 24-bit graphics.

These values make more sense to me than the values I was extracting from the PNG.

[[User:Renegrade|Renegrade]] 23:23, 3 August 2010 (EDT)

Talk:GEOSCAPE.EXE

2010-07-18T00:23:42Z

Renegrade: /* Difficulty patch information wrong? */

I just remembered something: Some bitmaps are stored in the executable. I think one such bitmap belongs to the Geoscape side bar. If the offsets for this can be located in the executable, you should be able to sign it off as an irrelevant section if you're hunting for particular variables in the executable.

But that's the hard part. Where do you look? And what image width are we looking at?

I once tried creating a program that took in an offset number, a line width number and how many bytes you want displayed from then on as the parameters. It would then open up one of the executables and draw the bytes on the screen as a bitmap of sorts. Kind of never got off the ground - I got distracted and now a year has passed and all my programming knowledge has gone into a vegetative state. I wonder if a program like this would be useful in locating tables or images in the file?

- [[User:NKF|NKF]]

----

The Geoscape side bar? Isn't that in [[GEOBORD.SCR]]?

Regardless, something to mask out known offsets in the file would certainly come in handy.

- [[User:Bomb Bloke|Bomb Bloke]] 22:41, 21 October 2006 (PDT)

== Offsets ==

This page is going to get rather long if we explain in detail all of the offsets here. I don't know if we should merge the Alien stats to the [[Alien Stats]] page or make a new page for it?

Also technically the Weapon stats are stored in Tactical so probably should be put on that page.

I've found some other offsets and if I keep digging I'm sure I'll find more. See my talk page for a mock-up of what I'm thinking for the format. [[User:Pi Masta|Pi Masta]] 15:21, 12 March 2007 (PDT)

:Well, in terms of length, it is (or is going to be) much like other game files: lots and lots of offsets, and their descriptions. It's not a page a casual player is going to reference.--[[User:Ethereal Cereal|Ethereal Cereal]] 15:56, 12 March 2007 (PDT)

Added the Detection Range offsets that Seb76 found. By the way fwiw my view is that only technically minded people will be looking at the wiki entry for a game save file so it's ok to fill this page with a lot of offsets. [[User:Spike|Spike]] 16:13, 9 March 2008 (PDT)
----
Well then, if you don't mind about huge posts, I guess it is a good place to put some stuff I discovered with static dissassembly of the executable [before my hard drive burns down ;)], some info may already be known (gold edition, sorry about the crude format...):

===Damage modifiers===
.data:0046DE74 damageModifierIncendiary dw 64h,64h,50h, 0,28h,46h,46h,64h, 0,50h,0AAh,64h,64h,64h; 0
.data:0046DE74 ; DATA XREF: sub_429CA0+2B�r
.data:0046DE74 ; sub_429CA0+132�r ...
.data:0046DE90 damageModifierHE dw 64h,64h,64h,64h,4Bh,64h,64h,64h,82h,64h,64h,50h,3Ch,50h; 0
.data:0046DEAC damageModifierLaser dw 64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,96h,64h,46h; 0
.data:0046DEC8 damageModifierPlasma dw 64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,50h,64h,46h; 0
.data:0046DEE4 damageModifierStun dw 64h,64h,5Ah,50h,64h,64h,50h,64h,64h,5Ah,64h,64h,64h, 0; 0
.data:0046DF00 damageModifierMelee dw 64h,78h,64h,64h,5Ah,64h,64h,64h,64h,64h,64h,64h,64h,64h; 0
.data:0046DF1C damageModifierAcidSpit dw 64h,0A0h,6Eh,64h,28h,64h,64h,64h,64h,64h,64h,64h,64h,64h; 0

===HWP weapons data===
.data:0046D57C builtinWeaponStats structBuiltinWeaponStats <0, 4, 3Ch, 3Ch, 21h, 0, 0, 5Ah, 50h, 0>; 0
.data:0046D57C ; DATA XREF: sub_403350+99�r
.data:0046D57C ; sub_40FF70+105�r ...
.data:0046D57C structBuiltinWeaponStats <2, 0Ch, 55h, 37h, 2Dh, 0, 0, 73h, 4Bh, 0>; 1
.data:0046D57C structBuiltinWeaponStats <3, 11h, 6Eh, 32h, 21h, 0, 0, 55h, 4Bh, 0>; 2
.data:0046D57C structBuiltinWeaponStats <4, 24h, 6Eh, 56h, 1Eh, 0, 0, 64h, 3Ch, 0>; 3
.data:0046D57C structBuiltinWeaponStats <2, 28h, 8Ch, 0, 0, 0, 0, 78h, 50h, 1>; 4
.data:0046D57C structBuiltinWeaponStats <7, 26h, 8Ch, 4Bh, 1Eh, 0, 0, 6Eh, 3Ch, 0>; 5
.data:0046D57C structBuiltinWeaponStats <4, 22h, 82h, 4Bh, 1Eh, 0, 0, 6Eh, 3Ch, 0>; 6
.data:0046D57C structBuiltinWeaponStats <3, 22h, 64h, 4Bh, 1Eh, 32h, 23h, 6Eh, 3Ch, 0>; 7
The structure is:
00000000 structBuiltinWeaponStats struc ; (sizeof=0x14)
00000000 damageType dw ?
00000002 ammoType dw ?
00000004 damage dw ?
00000006 snapshotAcc dw ?
00000008 snapshotTU dw ?
0000000A autoshotAcc dw ?
0000000C autoshotTU dw ?
0000000E aimshotAcc dw ?
00000010 aimshotTU dw ?
00000012 blasterEffect dw ?
00000014 structBuiltinWeaponStats ends

===Funding countries borders polylines===
.data:00474AD4 GeoBordersData dw 0FFFFh ; DATA XREF: GeoDrawBorders+3�r
.data:00474AD4 ; GeoDrawBorders+C�o
.data:00474AD6 dw 221h
.data:00474AD8 dw 0FF43h
.data:00474ADA dw 238h
.data:00474ADC dw 0FF3Dh
.data:00474ADE dw 22Ch
.data:00474AE0 dw 0FF28h
.data:00474AE2 dw 233h
.data:00474AE4 dw 0FF1Fh
.data:00474AE6 dw 236h
...
TFDT-CE(CRC32:C2F6C035): 0x0008AE00..0x0008B00F. 
use: rivers instead of country borders. 
data: lon,lat,lon,lat.. streams, Flags: lon = -1(NewLine), lon = -2(EndOfSection).

===Funding countries names coordinates===
.data:00474DF8 GeoCountryNamesData dw 280h ; DATA XREF: GeoDrawCountryNames+6�o
.data:00474DFA dw 0FF40h
.data:00474DFC dw 263h
.data:00474DFE dw 0B30h
.data:00474E00 dw 0FE53h
.data:00474E02 dw 25Ch
.data:00474E04 dw 0B2Ch
.data:00474E06 dw 0FEABh
.data:00474E08 dw 260h
.data:00474E0A dw 14h
.data:00474E0C dw 0FE8Ch
...
TFDT-CE(CRC32:C2F6C035): 0x0008B010..0x0008B06F. ((16*2)*3:lon,lat,Nid)

===Craft type data===
.data:0046F9A8 ; DATA XREF: sub_432B90+1C�r
.data:0046F9A8 ; sub_436970+59�r ...
craftsData
.data:0046F9A8 structCraftData <23Ah, 65336, 0, 760, 2, 1500, 150, 4, 0, 0, 0, 0Eh, 0,\
.data:0046F9A8 3, 0> ; 0 ''Skyranger''
.data:0046F9A8 structCraftData <23Bh, 65236, 1, 3100, 8, 30, 800, 4, 0, 0, 0, 0Ch, 0,\
.data:0046F9A8 0, 0> ; 1 ''Lightning''
.data:0046F9A8 structCraftData <23Ch, 65136, 2, 5400, 0Ah, 60, 1200, 4, 0, 0, 0, 1Ah,\
.data:0046F9A8 0, 4, 0> ; 2 ''Avenger''
.data:0046F9A8 structCraftData <23Dh, 65286, 2, 2100, 3, 1000, 100, 4, 0, 0, 0, 0, 0,\
.data:0046F9A8 0, 0> ; 3 ''Interceptor''
.data:0046F9A8 structCraftData <23Eh, 65286, 2, 4200, 9, 20, 500, 4, 0, 0, 0, 0, 0, 0,\
.data:0046F9A8 0> ; 4 ''Firestorm''
.data:0046F9A8 structCraftData <2B2h, 100, 2, 2200, 0Ch, 0, 50, 5, 38h, 0C8h, 0, 0, 0,\
.data:0046F9A8 0, 0> ; 5 ''Small Scout (VS)''
.data:0046F9A8 structCraftData <2B3h, 150, 2, 2400, 9, 0, 200, 4, 38h, 0FAh, 140078h,\
.data:0046F9A8 0, 0, 0, 0> ; 6 ''Medium Scout (S)''
.data:0046F9A8 structCraftData <2B4h, 250, 2, 2700, 9, 0, 250, 4, 30h, 12Ch, 140110h,\
.data:0046F9A8 0, 0, 0, 0> ; 7 ''Large Scout (S)''
.data:0046F9A8 structCraftData <2B5h, 500, 2, 4000, 8, 0, 500, 3, 30h, 1F4h, 2800B0h,\
.data:0046F9A8 0, 0, 0, 0> ; 8 ''Abductor (M)''
.data:0046F9A8 structCraftData <2B6h, 500, 2, 4300, 8, 0, 500, 3, 20h, 1F4h, 2800A0h,\
.data:0046F9A8 0, 0, 0, 0> ; 9 ''Harvester (M)''
.data:0046F9A8 structCraftData <2B7h, 1000, 2, 4800, 6, 0, 1200, 2, 18h, 7D0h, \
.data:0046F9A8 780150h, 0, 0, 0, 0> ; 10 ''Terror Ship (L)''
.data:0046F9A8 structCraftData <2B8h, 1400, 2, 5000, 6, 0, 3000, 1, 18h, 0FA0h, \
.data:0046F9A8 8C0208h, 0, 0, 0, 0> ; 11 ''Battleship (VL'')
.data:0046F9A8 structCraftData <2B9h, 800, 2, 3200, 6, 0, 2200, 2, 18h, 0BB8h, \
.data:0046F9A8 3C0120h, 0, 0, 0, 0> ; 12 ''Supply Ship (L)''

Craft type known fields: (14 x 2-byte dwords per record)
00000000 structCraftData struc ; (sizeof=0x1C)
00000000 nameIdx dw ?
00000002 scoreDestroyed dw ? ; base 10
00000004 weaponPods dw ? ''always 2 for UFOs. is this used for UFOs? how?''
00000006 maxSpeed dw ? ''in knots'' ; base 10
00000008 acceleration dw ?
0000000A fuelCapacity dw ? ; base 10
0000000C damageCapacity dw ? ; base 10
0000000E ufoSize dw ?
''5 - Very Small / 4 - Small (inc. XCom) / 3 - Medium / 2 - Large / 1 - Very Large -spike''
00000010 ufoReload dw ?
''UFO only. Firing interval. Values: 56=S/MSct 48=LSct/Abd 32=Harv 24=Suppl/Terr/BS. -spike''
00000012 ufoUnknown dw ?
''Unknown. Score related? SS=200 MS=250 LS=300 A=500 H=500 TS=2000 BS=4000 SS=3000 -spike''
00000014 ufoRange dw ? ''alien weapon distance in km*8 -kyrub/spike''
00000016 ufoPower dw ? ''alien weapon damage -kyrub/spike''
00000018 TroopSpace dw ? ''Troop capacity ''
0000001A HWPSpace dw ? ''HWP capacity -spike''
0000001C structCraftData ends

While the 9th [dword] could be UFO weapon Accuracy or even rate of fire, it seems unlikely. All the values are a multiple of 8 just like distance, so it may be related to that. That's my guess. I'm sure someone like Seb would know more. --[[User:Zombie|Zombie]] 23:56, 4 July 2009 (EDT)

:Sorry I didn't sign those theory guesses, I will do so now. Actually, evidence is building up that the byte at 0x10 within structCraftData is an inverse co-factor - i.e. a divisor - of the net total damage output of UFO attacks. In other words, it could well be a firing interval value such as is seen for XCom craft weapons. I have done 3-4 sets of ten tests so far (XCom craft survival-time tests, deducing UFO damage output). 1 set was for Medium Scout vs Interceptor, 2 sets were for Terror Ship vs Avenger. (I also did multiple attacker sets but those are harder to compare directly to this scenario). So far all 3 test sets are a reasonably good fit for this formula:

UFO net damage output =
<big>(</big>Weapon power x 75% ''(avg of randomisation)'' x 2/3 ''(accuracy)'' <big>)</big>
x <big>(</big> time ''(in game seconds)'' / 0x10 offset ''(firing interval)'' <big>)</big>

: What I want to do next is take one or both of those test scenarios, hack the 0x10 offset up or down, and see if the observed damage output varies inversely. If so, I think that will be pretty strong evidence. Even in my data, there is definitely still also some variation going on that is not fully accounted for in the formula above. As you say it is interesting the 0x10 values are all multiples of 8, suggesting distances. I will keep testing and see what I come up with! Cheers, [[User:Spike|Spike]] 06:39, 5 July 2009 (EDT)

I'm enclined to agree with the rate of fire theory. A countdown is stored in [[CRAFT.DAT]] at offset 0x26 and when it hits 0, the UFO fires. It is reset for the next shot with this formula:
tmp = offset10-2*difficultyLevel
nextShot = RAND(0,tmp)+tmp

Edit: Although the attack type does not appear here, I suspect that while a missile is "traveling", the countdown is not changed. As a result, closer ranges means higher rates of fire. [[User:Seb76|Seb76]] 07:36, 5 July 2009 (EDT)

:Excellent timing Seb! I was just about to start my tests. I could've coped with the random element, since I'm only measuring averages over time, but the presence of a 2nd factor (difficultyLevel), I was not expecting. It would have completely thrown my numbers. Also I might've crashed the game since I'd set offset10 to 0x08 on difficulty level Superhuman (=5?), creating a negative rate of fire! For simplicity I might do my tests on Beginner from now on, and repeat the earlier tests on Beginner.

:It's interesting that you don't see any reference to Attack Mode. So the changing rate of fire could indeed be a "Space Invaders Effect" as you say. Perhaps the reason this is not seen for cannon fire is that cannon fire is resolved instantly, whereas missiles are plotted as objects on the map? Is there any indication that missiles and cannon are handled differently by these routines?

:My test scenarios are probably too simplistic at the moment. But, I am sure I am seeing different rates of fire for missiles at the same range, dependent on whether they are in Standard or Cautious attack mode. I will recheck this. [[User:Spike|Spike]] 08:07, 5 July 2009 (EDT)

:Seb, I realise your formula above for variable firing intervals, from 100%-200% of the base value, explains the 2/3 factor I found which I thought might be UFO Accuracy. The average of a 100-200% range is 1.5, and the inverse of this is 2/3. So perhaps there is no accuracy factor in UFO weapon damage at all. Possibly you just have a base damage and a base firing interval, plus a 50%-100% variation on the base damage and a 100%-200% variation on the firing interval. This would certainly match the data I have so far.

:I have done a couple of tests of varying this offset 0x10 value and they show the right "sign": increasing this value decreases UFO damage output over time, and decreasing this value increases UFO damage output. The effect is strong, and approximately linear, i.e. halving the value roughly doubles the damage, etc (testing on Superhuman). To quantify it more exactly I need to go back and control for Difficulty Level which I did not expect to be a variable. I'm also going to control for the time taken for the UFO to close into firing range - by increasing the UFO weapon range in the tests to 70 or 75km.

:One thing that is worrying me though is that the firing interval is random. Since I'm using the firing interval of a cannon as my "timer" to measure the duration of all other events, it means I'm measuring with a yardstick that randomly changes size. I have to hope that my sample sizes are large enough that the averages will dominate over the fluctuations.

:More worrying is the idea that rate of fire varies with range (as opposed to with Attack Mode). That would be an elastic yardstick, worse than a random one. I thought I had disproved this but I need to go back and do it again, more carefully. I need to test the same weapon at the same range with different attack modes, again. I may well be guilty of building my hypothesis into my test scenario as an assumption! I will also double check the assumption that hacking the firing interval values for XCom weapons has no effect. I'm pretty sure that, even if the absolute firing interval changes with range, the relative ratios of firing interval when comparing different weapons, does not change. But I'll double check.

:In the code, do you see any evidence of cannon-type weapons being treated differenly from missile weapons? For example, do cannon rounds not "travel"? Also, do you see the same '''rnd (0,tmp) + tmp''' function being applied to the firing interval of XCom air attacks? Regards, [[User:Spike|Spike]] 14:30, 5 July 2009 (EDT)

===Base components data===
.data:00470640 baseElements baseComponentStruct <249h, 300, 1, 4, 0, 0, 5>; 0
.data:00470640 ; DATA XREF: BaseEditDrawSideBar_sub_432EF0+12D�r
.data:00470640 ; BuildFacilities+74�o ...
.data:00470640 baseComponentStruct <24Ah, 400, 16, 10, 1Eh, 0, 4>; 1
.data:00470640 baseComponentStruct <24Bh, 750, 26, 30, 0Ah, 0, 4>; 2
.data:00470640 baseComponentStruct <24Ch, 800, 32, 35, 32h, 0, 4>; 3
.data:00470640 baseComponentStruct <24Dh, 500, 12, 10, 0, 0, 5>; 4
.data:00470640 baseComponentStruct <24Eh, 800, 25, 15, 0, 0, 4>; 5
.data:00470640 baseComponentStruct <24Fh, 200, 16, 5, 0, 3201F4h, 5>; 6
.data:00470640 baseComponentStruct <250h, 150, 10, 5, 0FAh, 0, 4>; 7
.data:00470640 baseComponentStruct <251h, 400, 18, 15, 0Ah, 0, 4>; 8
.data:00470640 baseComponentStruct <252h, 400, 24, 10, 0, 3C0258h, 0Ah>; 9
.data:00470640 baseComponentStruct <253h, 600, 34, 12, 0, 460384h, 0Ah>; 10
.data:00470640 baseComponentStruct <254h, 800, 34, 14, 0, 5004B0h, 0Ah>; 11
.data:00470640 baseComponentStruct <255h, 1200, 38, 15, 0, 0, 9>; 12
.data:00470640 baseComponentStruct <256h, 1300, 33, 5, 0, 0, 9>; 13
.data:00470640 baseComponentStruct <257h, 750, 24, 16, 0Ah, 0, 8>; 14
.data:00470640 baseComponentStruct <258h, 1400, 26, 30, 0, 0, 9>; 15
.data:00470640 baseComponentStruct <259h, 200, 25, 25, 1, 0, 4>; 16
fields:
00000000 baseComponentStruct struc ; (sizeof=0x10)
00000000 stringId dw ?
00000002 cost dw ? ; base 10
00000004 constructionTime db ? ; base 10
00000005 maintenance db ? ; base 10
00000006 anonymous_4 dw ?
00000008 anonymous_5 dd ?
0000000C anonymous_8 dd ?
00000010 baseComponentStruct ends

===Alien missions data===
(I made another post for this one in missions.dat):
.data:00470E70 alienMissionData structAlienMission <5, 1, 0, 12Ch> ; 0
.data:00470E70 ; DATA XREF: SpawnAlienShip+10D�r
.data:00470E70 ; UpdateAlienMissions+78�r ...
.data:00470E70 structAlienMission <6, 1, 2, 104h> ; 1 ;
.data:00470E70 structAlienMission <7, 2, 4, 12Ch> ; 2 ;
.data:00470E70 structAlienMission 5 dup(<0FFFFh, 0FFFFh, 0FFFFh, 0FFFFh>); 3
...
fields:
00000000 structAlienMission struc ; (sizeof=0x8)
00000000 ufoType dw ?
00000002 numUfoToSpawn dw ?
00000004 unknown dw ?
00000006 timeCounter dw ?
00000008 structAlienMission ends

===Ground patches===
(used to spawn locations on continents):
.data:00471278 randPlaces structArea <640h, 0FDF8h, 0A0h, 28h> ; 0
.data:00471278 ; DATA XREF: GetRandomPositionOnContinent+2D�r
.data:00471278 ; GetRandomPositionOnContinent+46�r ...
.data:00471278 structArea <730h, 0FDF8h, 0F0h, 50h> ; 1
.data:00471278 structArea <8C0h, 0FE70h, 50h, 50h> ; 2
.data:00471278 structArea <730h, 0FE70h, 0A0h, 50h> ; 3
.data:00471278 structArea <820h, 0FE70h, 0A0h, 50h> ; 4
.data:00471278 structArea <730h, 0FEC0h, 0A0h, 50h> ; 5
.data:00471278 structArea <7D0h, 0FEC0h, 0B0h, 60h> ; 6
.data:00471278 structArea <870h, 0FEB0h, 0A0h, 88h> ; 7

00000000 structArea struc ; (sizeof=0x8)
00000000 xstart dw ?
00000002 ystart dw ?
00000004 width dw ?
00000006 height dw ?
00000008 structArea ends

===Zones sectors===
(used to get the zone number for a world coordinate):
.data:00474F38 geo_globe_zones structGlobeZone <618h, 987h, 0FDD0h, 0FE47h, 0>; 0
.data:00474F38 ; DATA XREF: GetWorldZoneFromPos+10�o
.data:00474F38 structGlobeZone <730h, 987h, 0FE48h, 0FF0Fh, 0>; 1
.data:00474F38 structGlobeZone <780h, 95Fh, 0FF10h, 0FFAFh, 0>; 2
.data:00474F38 structGlobeZone <0, 0B3Fh, 0FD30h, 0FDCFh, 1>; 3
.data:00474F38 structGlobeZone <0, 0B3Fh, 1E0h, 2D0h, 2>; 4
.data:00474F38 structGlobeZone <870h, 9D7h, 0FFB0h, 0FFFFh, 3>; 5
.data:00474F38 structGlobeZone <898h, 0A4Fh, 0, 77h, 3>; 6
.data:00474F38 structGlobeZone <898h, 0A27h, 78h, 1DFh, 3>; 7
.data:00474F38 structGlobeZone <0A78h, 1DFh, 0FDD0h, 0FEE7h, 4>; 8
.data:00474F38 structGlobeZone <0A78h, 13Fh, 0FEE8h, 0FF87h, 5>; 9
.data:00474F38 structGlobeZone <0A78h, 1B7h, 0FF88h, 0FFFFh, 5>; 10
.data:00474F38 structGlobeZone <28h, 1B7h, 0, 13Fh, 6> ; 11
.data:00474F38 structGlobeZone <140h, 22Fh, 0FEE8h, 0FF87h, 7>; 12
.data:00474F38 structGlobeZone <1E0h, 2CFh, 0FE70h, 0FEE7h, 7>; 13
.data:00474F38 structGlobeZone <230h, 2CFh, 0FEE8h, 0FFD7h, 7>; 14
.data:00474F38 structGlobeZone <2D0h, 347h, 0FE70h, 4Fh, 8>; 15
.data:00474F38 structGlobeZone <348h, 4AFh, 0FE70h, 0FFD7h, 8>; 16
.data:00474F38 structGlobeZone <1E0h, 59Fh, 0FDD0h, 0FE6Fh, 9>; 17
.data:00474F38 structGlobeZone <348h, 59Fh, 0FFD8h, 18Fh, 0Ah>; 18
.data:00474F38 structGlobeZone <5A0h, 617h, 0FDD0h, 0FE47h, 0Bh>; 19
.data:00474F38 structGlobeZone <5A0h, 72Fh, 0FE48h, 0FF0Fh, 0Bh>; 20
.data:00474F38 structGlobeZone <5A0h, 77Fh, 0FF10h, 0FFAFh, 0Bh>; 21
.data:00474F38 structGlobeZone <5A0h, 86Fh, 0FFB0h, 0FFFFh, 0Bh>; 22
.data:00474F38 structGlobeZone <5A0h, 897h, 0, 1DFh, 0Bh>; 23
.data:00474F38 structGlobeZone <4B0h, 59Fh, 0FE70h, 0FFD7h, 0Bh>; 24
.data:00474F38 structGlobeZone <988h, 0A77h, 0FDD0h, 0FF0Fh, 0Ch>; 25
.data:00474F38 structGlobeZone <960h, 0A77h, 0FF10h, 0FFAFh, 0Ch>; 26
.data:00474F38 structGlobeZone <9D8h, 0A77h, 0FFB0h, 0FFFFh, 0Ch>; 27
.data:00474F38 structGlobeZone <0A50h, 27h, 0, 77h, 0Dh>; 28
.data:00474F38 structGlobeZone <0A28h, 27h, 78h, 1DFh, 0Dh>; 29
.data:00474F38 structGlobeZone <28h, 1B8h, 140h, 1DFh, 0Dh>; 30
.data:00474F38 structGlobeZone <1B8h, 22Fh, 0FF88h, 4Fh, 0Eh>; 31
.data:00474F38 structGlobeZone <230h, 2CFh, 0FFD8h, 4Fh, 0Eh>; 32
.data:00474F38 structGlobeZone <1B8h, 347h, 50h, 1DFh, 0Eh>; 33

Same for country zones:
.data:00475090 geo_glob_country_zones structGlobeZone <758h, 7F8h, 0FE78h, 0FF00h, 0>; 0
.data:00475090 ; DATA XREF: GetCountryFromPos+11�o
.data:00475090 structGlobeZone <7F8h, 8ACh, 0FE78h, 0FF18h, 0>; 1
.data:00475090 structGlobeZone <820h, 848h, 0FF18h, 0FF30h, 0>; 2
.data:00475090 structGlobeZone <8A8h, 8C0h, 0FF00h, 0FF38h, 0>; 3
.data:00475090 structGlobeZone <8ACh, 8F0h, 0FEA0h, 0FF00h, 0>; 4
.data:00475090 structGlobeZone <8F0h, 924h, 0FE94h, 0FEC0h, 0>; 5
.data:00475090 structGlobeZone <0F0h, 190h, 0FDD0h, 0FE98h, 1>; 6
.data:00475090 structGlobeZone <0C0h, 0F0h, 0FE20h, 0FEB0h, 1>; 7
.data:00475090 structGlobeZone <190h, 258h, 0FD98h, 0FEC0h, 1>; 8
.data:00475090 structGlobeZone <258h, 528h, 0FD80h, 0FE70h, 1>; 9
.data:00475090 structGlobeZone <528h, 550h, 0FDD0h, 0FE28h, 1>; 10
.data:00475090 structGlobeZone <0B00h, 10h, 0FE20h, 0FE70h, 2>; 11
.data:00475090 structGlobeZone <0B18h, 38h, 0FE70h, 0FEA8h, 3>; 12
.data:00475090 structGlobeZone <30h, 78h, 0FE48h, 0FE84h, 4>; 13
.data:00475090 structGlobeZone <38h, 78h, 0FE8Ch, 0FEA8h, 5>; 14
.data:00475090 structGlobeZone <58h, 90h, 0FEA8h, 0FED8h, 5>; 15
...

===Dot color data for LOC.DAT entries===
shawn on world map (can't think of a better name...):
.data:00475202 locationColor dw 0, 0Dh, 0Bh, 9, 1, 5, 7, 3 ; 0
.data:00475202 ; DATA XREF: geoDrawLocations+ED�r

Just after that are data describing the mask for drawing the location (I don't remember the format, but it shouldn't be something too complicated to decypher)

===Flare pattern===
(tactical mode):
.data:0046C558 flarePattern db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 0
.data:0046C558 ; DATA XREF: LightmapAddFlarePattern+7�o
.data:0046C558 ; LightmapAddFlarePattern+19�o
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 31
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 62
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h; 93
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h; 124
.data:0046C558 db 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Ah, 0Ah, 0Ah, 0Ah, 0Ah, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h; 155
.data:0046C558 db 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 0Ah, 9, 9, 9, 9, 9, 0Ah, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h; 186
.data:0046C558 db 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 9, 9, 8, 8, 8, 8, 8, 9, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h; 217
.data:0046C558 db 10h, 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 9, 8, 8, 7, 7, 7, 7, 7, 8, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 10h, 10h; 248
.data:0046C558 db 10h, 0Fh, 0Eh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 9, 8, 7, 7, 6, 6, 6, 6, 6, 7, 7, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Eh, 0Fh, 10h; 279
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 0Ah, 9, 8, 7, 6, 6, 6, 5, 5, 5, 6, 6, 6, 7, 8, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 310
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 5, 4, 4, 4, 5, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 341
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 4, 3, 3, 3, 4, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh; 372
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 4, 3, 2, 2, 2, 3, 4, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 403
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 3, 2, 1, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 434
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 465
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 3, 2, 1, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 496
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 4, 3, 2, 2, 2, 3, 4, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 527
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 4, 3, 3, 3, 4, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh; 558
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 5, 4, 4, 4, 5, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 589
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 0Ah, 9, 8, 7, 6, 6, 6, 5, 5, 5, 6, 6, 6, 7, 8, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 620
.data:0046C558 db 10h, 0Fh, 0Eh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 9, 8, 7, 7, 6, 6, 6, 6, 6, 7, 7, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Eh, 0Fh, 10h; 651
.data:0046C558 db 10h, 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 9, 8, 8, 7, 7, 7, 7, 7, 8, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 10h, 10h; 682
.data:0046C558 db 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 9, 9, 8, 8, 8, 8, 8, 9, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h; 713
.data:0046C558 db 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 0Ah, 9, 9, 9, 9, 9, 0Ah, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h; 744
.data:0046C558 db 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Ah, 0Ah, 0Ah, 0Ah, 0Ah, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h; 775
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h; 806
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h; 837
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 868
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 899
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 930

Sorry for the big post and the raw format... [[User:Seb76|Seb76]] 13:59, 10 March 2008 (PDT)

Construction costs for access lifts:
.data:0046E69C basePrice dd 800000, 950000, 900000, 600000, 1000000, 650000, 550000, 500000, 750000; 0
.data:0046E69C dd 800000, 750000, 600000, 3 dup(500000); 9
[[User:Seb76|Seb76]] 11:01, 16 March 2008 (PDT)

=== Craft weapon stats ===

I guess the craft weapon stats could be in here too?
as far I can see these are at 353378 (plain 1.4), 18 bytes, 9x2 byte: 
index/range/acc/dmg/??/time/no of ammo/??/ammo 
--[[User:Emphyrio|Emphyrio]] 15:25, 1 March 2009 (CST)

----

In the WinCE version (unpatched) the craft weapon stats start at offset 0x6fb18. Or search for this signature:

40 02 1e 00 46 00 46 00 01 00 0f 00 06 00 01 00 06 00

Fields are:
Index - Range (km) - Hit% - Damage - ?X? - reload time - ammo cap - ?Y? - ammo type

Weapon X Y
Stingray 1 1
Avalanche 3 1
Cannon 8 100
FBL 5 1
Laser C 10 50
Plasma C 12 50

I would speculate that value "Y" is the re-arming rate on the ground. I think this data differs slighly from what is stated at [[Rearming]] so it might be worth double checking that.

Value "X" could be a bitmask, an index to a sound effect, or just about anything. It's possible the lowest bit is a flag that is set for a missile weapon, unset for a cannon-type weapon.

[[User:Spike|Spike]] 19:43, 5 July 2009 (EDT)

The "reload time" value (as it is called in the in-game UFOPaedia) does not seem to be used by the executable. Instead, hard coded values are used. See [[UFO Interception#Observed Rates of Fire|Observed Rates of Fire]]. [[User:Spike|Spike]] 20:31, 13 July 2009 (EDT)

I checked and the rearming rates in the wiki article are correct, i.e. 100 rds per hour for all Cannon types. Maybe this "Y" data was intended as the rearming rate but is unused? The next step would be to hack the "Y" values and look for any effect. It would also be interesting to hack the low bit of the "X" value and see if that has any effect, such as controlling the missile weapon firing interval behaviour (RoF changes based on attack mode), or sound effect.

Here is X as a bitmask

Weapon X Bitmask
Stingray 1 00000001
Avalanche 3 00000011
FBL 5 00000101
Cannon 8 00001000
Laser C 10 00001010
Plasma C 12 00001100

[[User:Spike|Spike]] 18:18, 16 February 2010 (EST)

Actually it looks like the low order 3 bits are just a sequence/ID number (ascending damage?). The next higher bit is launched (0) vs cannon (1).

Weapon X Bitmask Seq Cannon?
Cannon 8 00001000 0 1
Stingray 1 00000001 1 0
Laser C 10 00001010 2 1
Avalanche 3 00000011 3 0
Plasma C 12 00001100 4 1
FBL 5 00000101 5 0

[[User:Spike|Spike]] 19:49, 14 March 2010 (EDT)

=== Manufacturing stats? ===

Has someone worked out the manufacturing stats at offset <s>355596</s> 355600 (vanilla 1.4)??
As far as I can see it looks like 35 records of 18 bytes 
 
:See the [[PRODUCT.DAT]] page. --[[User:Zombie|Zombie]] 16:25, 24 February 2009 (CST)
:: ok, this is actually is a useful bit of information, I <s>would</s> have put it in the article.. --[[User:Emphyrio|Emphyrio]] 07:06, 25 February 2009 (CST)
:Good deal. I also added a note to the top of [[PRODUCT.DAT]] (and linked the [[Manufacturing_Profitability]] to PRODUCT.DAT - that should've been there, too). -[[User:MikeTheRed|MikeTheRed]] 11:17, 25 February 2009 (CST)

==New Bundles==

The "Complete Package" and such versions of X-Com from Steam, interestingly enough, include both versions of the game, at least .exe wise. The one that runs when you just launch from the Steam menu is the original European version, 1.2, so I wonder exactly why they included the other version. -[[User:Elliotw2|Elliotw2]] 2009-01-15 18:01:37

:Hiya Elliotw2! I wasn't watching this page's Talk page before, but I am now.
:As for the various versions, I dusted off some 10 y.o. DOS floppies a few years ago. They still worked, and I ran with it (U.S. DOS v. 1.4). Although I've read a lot about the other versions on this wiki, I'll let the other vets here address what you just said (smile). I personally would have chosen the U.S. version... Vets, why would they have both versions in the bundle, but make the default be the European version?
:Elliotw2, please leave a mini-review (or repeat what you just said) at [[GEOSCAPE.EXE#X-COM_Complete_Packages]] (see my new "mini-review" format request there). Sorry for the mess, newcomers - especially having this tucked away under GEOSCAPE, but it makes sense to us grognards. As always, we will change and grow as needed, and "us" easily includes "you". For now, we're just trying to make sure that newcomers can find what they need here, and that there's a place for info on the Complete Packages to be voiced.
:-[[User:MikeTheRed|MikeTheRed]] 03:49, 19 January 2009 (CST)

== Difficulty patch information wrong? ==

It appears that the information for patching the difficulty is wrong on this page.

I have what I believe is the US version of XCOM 1.4, and I patched the file as per the data given for 1.4, and yet it still created a 60-byte IGLOB.DAT file. Further, DOSBOX complained of illegal memory accesses after the patch (which it did not do before).

33ea0819e6888f0450f9a1e5e19dc98b *GEOSCAPE.EXE (binary MD5SUM -- file is 382,957 bytes, created 1995-02-28 @ 10:24 PM)

There actually was a 60 byte (0x3c) at the location given, but I have a feeling it was something other than the size_t in question.

:If you search for:
<pre>3C 00 00 00 57 2B C9 49</pre>
:you will fined the iglob.dat length for all versions of UFO. --[[User:BladeFireLight|BladeFireLight]] 19:45, 16 February 2010 (EST)

Yeah, that was my fault, I just put the same value as was in 1.0. It's corrected now.
[[User:Hatfarm|Hatfarm]] 18:45, 5 June 2010 (EDT)

I tried that out, it seems to work perfectly. Thank you both! FYI; the above is the XCOM package available from GOG.com. [[User:Renegrade|Renegrade]] 20:23, 17 July 2010 (EDT)

User:Renegrade

2010-02-02T14:50:40Z

Renegrade: New page: Just an old DOS/Amiga programmer who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A00...

Just an old DOS/Amiga programmer who thinks these new-fangled, managed-object-oriented-byte-interpreted nonsense is a load of hogwash who misses the good old days of splatting bytes at A000:0000 directly... and some of the games that arose during that era.

Talk:PALETTES.DAT

2010-02-02T14:47:17Z

Renegrade: Regarding mode 13h

Just for a bit of general --[[User:Darkfred|Darkfred]] 07:29, 13 June 2007 (PDT)information, it might be worth mentioning that some of the palette entries are used for colour cycling. For example the radar pings on the intercept console. That's achieved by shifting a whole block of palette entries to give the effect of movement. (Think KITT's chasing lights) The image doesn't change, but the colour that you see does. It results in a wave movement. If anyone remembers the shifting colours on ye olde Windows startup screens, this was achieved in the same way.

Other palette swaps include the greyscale background bitmaps that are used in the Geoscape screens. They keep the same palette entry, and the game only needs to shift these entries to different shades to change the shades of the backgrounds.

Come to think of it, anyone know what conditions change the normal backgrounds from red to purple? It seems to vary.

Also another random technical tidbit, the game uses mode 13h for its display. In other words 320x200x256clr VGA mode. It used to come standard on all SVGA cards as a safe mode to revert to. The first fifteen colours after the transparency were probably left behind for use by the console. They appear to match the old text mode 16 colour palette.

- [[User:NKF|NKF]]

-----------

In the case of the background images, the palette swaps are pulled from [[BACKPALS.DAT]], but I never realised the intercept radar was a palette cycle, though it does make sense - I assume that's handled entirely by the executable.

Oooh, I didn't know mode 13 was a *real* display mode! I thought it was just a "prebuilt" mode that QBasic provided to "script kiddies". XD

Not sure what you mean about those fifteen colors and how "They appear to match the old text mode 16 colour palette". I checked QBasic's idea of what the default mode 7 palette should look like (mode 7 being a sixteen color only version of mode 13, but with multiple "screens" you could flip in and out of the display buffer - guess you could call it EGA?) and it doesn't match the colors in any of UFO's palettes. But, I dunno if the palettes QBasic used followed any real standard, or if I even know what I'm talking about. :)

- [[User:Bomb Bloke|Bomb Bloke]] 04:56, 12 June 2007 (PDT)
: Xcom was built for mode 13h with a 6 bit ramdac, (hence the 0-64 color values). This was one of the few modes which was widely available and worked the same on all early pc's. It was started via interrupt 13h also called MCGA and the bios did all the setup work. I don't think there was a default mcga palette, but it could be the default EGA palette.
: The palette animation could be done either way, I will check on this, but it might just be easier to switch the pal to grayscale, and take a screenshot during the animation. Then look at the color values. In the windows version the palettes are entirely faked anyway so doing it via code wouldn't be any slower.--[[User:Darkfred|Darkfred]] 07:58, 12 June 2007 (PDT)
:: It's actually interrupt 0x10, with AH=0, AL=0x13. The 6/18 bit entries in the palette table was, and still is standard for 8-bit palette modes in VGA. [http://en.wikipedia.org/wiki/MCGA MCGA] was also an actual card, between EGA and true VGA. Mode 13 has an additional benefit for 16-bit DOS mode programmers in that the entire memory map for the card (320x200x1 byte/pixel = 64,000 bytes) is available within a single segment, meaning no bank swapping is necessary (much faster). The Amiga version(s) of XCOM would have used a 4/12 or 8/24 bit color resolution though, depending on whether it was OCS/ECS or AGA. I can't remember which Amiga version I had though, or whether or not it looked "ECS-y" or not. -- [[User:Renegrade|Renegrade]] 09:47, 2 February 2010 (EST)

-------

Not sure what you mean by "palette faking"... I know that if you take a screenshot in the CE version of the game (F12), the resulting image will be a 256 color job using whatever palette the game was supposed to be using at the time.

Hence my thought was to just take multiple screenshots of the animation, and check to see what the palette looked like. Sure enough, colors 112 through to 127 (16 in all) cycle through shades of green, whereas the image itself doesn't actually change.

- [[User:Bomb Bloke|Bomb Bloke]] 17:53, 12 June 2007 (PDT)
: Good work! Very cool.
: This may be boring but I will explain what I meant by palette faking. Its interesting but not terribly useful unless you wanna mod the exe.
: Palette Faking: The CE version of UFO is actually rendered in 32bit color at 640x400. You can take a screenshot of this version using the PrnScn key on your keyboard. The image you get when you press F12 is from UFO's fake internal MCGA buffer.
: When UFO was converted to a windows application the developers cheated, they made a copy of the mode13h memory in the executable, which they use as if it was the actual screen. They also make a fake copy of the palette. Then after each frame is drawn they copy this into the 32bit DirectDraw surface. They convert from the MCGA format into 32bit and run an upsampling filter (2x to 640x400). This is why the edges of letters look smoother in-game then in screenshots.
: The upshot is that the CE game is the exact same game code, only wrapped with a mode13 emulator. Cool huh. This is what allows the Exe Splitter and filter changing mods to work, 90% of the work is already done. --[[User:Darkfred|Darkfred]] 22:03, 12 June 2007 (PDT)
:: It also implies that those who did the Windows conversion were not the same programs who made the game. The original programmers would have done it seemlessly rendering into the DirectX buffer. The CE programmers may not have even had the sourcecode, the hack could be done without it. (although audio might not be so easy I donno). --[[User:Darkfred|Darkfred]] 22:07, 12 June 2007 (PDT)

:::I believe the programmers that did the Win32 port may have had access to the source of the original executables. Lots of constants and other tables for both the executables seem to be lumped together at the end, which is why you can't always get a rough match for some variable offsets in the dos version and the executable version. They aren't just both of the original executables mushed together with a bit tacked on the end(or front) to get it to work with Direct X, as I originally thought.

:::Come to think of it, pressing print screen in the CE does take screenshots, but the palette information isn't carried over, so the bitmap that ends up on the clipboard is ruined. - [[User:NKF|NKF]]

::::My UFO version is calling DirectDraw and requesting a 640x400x32bit display mode. It also makes nice 32bit screenshots when i press printscreen, I just verified this. It may be that there is some difference between our versions? --[[User:Darkfred|Darkfred]] 23:34, 12 June 2007 (PDT)

:::::It's not the game. I think it might just be the way some implementations of Windows handles screen captures. For lots of players, the screenshots palette will not be captured, and because the individual pixel index colours aren't saved, the image on the clipboard is ruined and cannot be recovered. I guess your clipboard works a lot better than most of us! (Or I suppose it could be your display mode). Using Printscreen with the dos version of the game works fine though, and the palette information isn't destroyed. My old copy of Windows 95 used to doubled the dos screen's pixels as well. Oh well. For now, the Collectors Edition's special F12 screen capture key for UFO/TFTD is still the most reliable method to capture screenshots. No matter how the game is displayed, the screenshot is stored as a 320x200x8 TGA file in the game directory- [[User:NKF|NKF]] 00:36, 13 June 2007 (PDT)
:::::: I don't see how the palette could be the problem though, my version of the game simply has NO palette. It is all converted to 32bit being put on the screen. And the screen doubling is using the SuperSai algorithm, which only works on 32bit buffers. The only thing I can think of is that perhaps it is receiving a 8bit buffer instead of the 32bit one it requests, but this doesn't make any sense. The most likely explanation is that the color problem is either a difference in our versions or a bug in your video drivers. --[[User:Darkfred|Darkfred]] 07:29, 13 June 2007 (PDT)

::::::: I doubt it -- it's almost certainly a matter of exact environment. UFO/CE/W2K with the graphics fixup loader against NVidia drivers is palette-corrupted (just tested), so any chance of PrintScreen working normally on this platform is from using PrintScreen against an emulator. --[[User:Zaimoni|Zaimoni]] 16:28, 13 June 2007 (CDT)

::::::::I am beginning to think that my highres 32bit version is the result of one of the mods I installed, i just don't know which. This would explain why the code is done in this way, stubbed into the beginning of the executable. Come to think of it I don't have any flashing screen problems like I did before either. hmmm. Well it works and I really don't care at this point. --[[User:Darkfred|Darkfred]] 16:40, 13 June 2007 (PDT)

------

Under CE, a printscreen will give you an image with a corrupt palette. F12 gives you a proper image.

The only way (that I know of) to get a 2xSaI effect is to run [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's executable]. Best I could make out, most of his extra code is tacked onto the end of the file... Printscreen will work "correctly" with this version, though F12 will still give unscaled images. This version of the game also has a variety of other differences to the usual engine (never checked the full list, but I gather there's some timing tweaks as well as a different way of handling sound).

The game uses DirectDraw regardless. Without f0dder/Mok's patches, the graphics (usually) won't render correctly. f0dder blames the DirectDraw implementation in his patch documentation, which'll be why disabling hardware acceleration is another way of fixing things up.

The CE game is remarkably similar to the Dos version, but there's a handful of differences. Although the game handles most errors by either ignoring them or crashing, it actually responds to some of them with intellegent messages. For example, if you pass it an over-filled [[TERRAIN|MCD array]] (easy to do when running my damage testing tileset, just visit anything larger then a scout ship in the desert), you'll get a pop up box complaining about there being "too many map codes". You also get missing file messages if the game can't find inventory screen images.

The most famous difference is the vertical waypoint bug (where a blaster bomb missile told to go directly up or down will instead fly off on an angle - The aliens often kill themselves with this one). Though it's still my guess that the coders who ported the game just changed as much code as they felt was needed to make the game compile as a windows executable, and left it at that.

- [[User:Bomb Bloke|Bomb Bloke]] 02:06, 14 June 2007 (PDT)

== TFTD's Depths ==

Just recalling what I deduced ages ago while playing the game using X-Comutil and the map and depth picker, I agree that the palettes are adjusted on the fly. Having a sea bed map appear grey on land but appearing blue in water was quite strange - it wouldn't make sense to duplicate all the images for the various depths. The simplest way to achieve this effect would be to tint the palette with blue, and just darkening the images to simulate depth would be quite easy. Also I recalled that in UFO that the background images in the various screens were all grey, but on-the-fly changes to the palette allow them to change between colours like red, olive and purple. They have their designated set of colours in the palette too if I'm not mistaken.

One good way to find out would probably be to replace an entire row of colours with the same colour, then observe what happens in the various depths. I was going to suggest pure white, but then you couldn't go up any further which would be needed for the tint. Perhaps a middling value like 128, 128, 128 for a flat grey.

- [[User:NKF|NKF]]

----

I started looking into the palettes in more detail so I could convert UFO graphics to TFTD's colors, and vice versa. I took a screenshot of TFTD CE and ripped the palette from that (as the colors for the battlescape didn't seem to be in Palettes.Dat).

After the first conversion, most of the colors seemed "ok" but some (eg. rocks) came out blue when Daishiva's PCK viewer declared them to be grey - and surface terrain (eg. grass and trees) looked decidedly off...

I then took a ton of screengrabs and eventually decided on a total of four palettes. I'd completely forgotten that TFTD used depth settings as well as time of day so it took me a little while to work out why the things kept changing.

It wasn't until I loaded up XcomUtil to force certain map types that I finally saw the light. Four palettes, four depth settings. One good example of the effect is the "atlantis" terrain (which makes heavy use of grey stone).

- [[User:Bomb Bloke|Bomb Bloke]] 20:16, 1 January 2008 (PST)

-----

I've been doing some stuff with the color-swapping SCR files and noticed that they index E0-EF, the second-to-final 16 palette entries. Currently the page says the BACKPALS.DAT palettes replace the 16 final entries. Is the page wrong or is there something I'm missing?

- [[User:Majorlag|Majorlag]]

Talk:GEOSCAPE.EXE

2010-01-31T08:20:28Z

Renegrade: New section: Difficulty patch information wrong?

I just remembered something: Some bitmaps are stored in the executable. I think one such bitmap belongs to the Geoscape side bar. If the offsets for this can be located in the executable, you should be able to sign it off as an irrelevant section if you're hunting for particular variables in the executable.

But that's the hard part. Where do you look? And what image width are we looking at?

I once tried creating a program that took in an offset number, a line width number and how many bytes you want displayed from then on as the parameters. It would then open up one of the executables and draw the bytes on the screen as a bitmap of sorts. Kind of never got off the ground - I got distracted and now a year has passed and all my programming knowledge has gone into a vegetative state. I wonder if a program like this would be useful in locating tables or images in the file?

- [[User:NKF|NKF]]

----

The Geoscape side bar? Isn't that in [[GEOBORD.SCR]]?

Regardless, something to mask out known offsets in the file would certainly come in handy.

- [[User:Bomb Bloke|Bomb Bloke]] 22:41, 21 October 2006 (PDT)

== Offsets ==

This page is going to get rather long if we explain in detail all of the offsets here. I don't know if we should merge the Alien stats to the [[Alien Stats]] page or make a new page for it?

Also technically the Weapon stats are stored in Tactical so probably should be put on that page.

I've found some other offsets and if I keep digging I'm sure I'll find more. See my talk page for a mock-up of what I'm thinking for the format. [[User:Pi Masta|Pi Masta]] 15:21, 12 March 2007 (PDT)

:Well, in terms of length, it is (or is going to be) much like other game files: lots and lots of offsets, and their descriptions. It's not a page a casual player is going to reference.--[[User:Ethereal Cereal|Ethereal Cereal]] 15:56, 12 March 2007 (PDT)

Added the Detection Range offsets that Seb76 found. By the way fwiw my view is that only technically minded people will be looking at the wiki entry for a game save file so it's ok to fill this page with a lot of offsets. [[User:Spike|Spike]] 16:13, 9 March 2008 (PDT)
----
Well then, if you don't mind about huge posts, I guess it is a good place to put some stuff I discovered with static dissassembly of the executable [before my hard drive burns down ;)], some info may already be known (gold edition, sorry about the crude format...):

===Damage modifiers===
.data:0046DE74 damageModifierIncendiary dw 64h,64h,50h, 0,28h,46h,46h,64h, 0,50h,0AAh,64h,64h,64h; 0
.data:0046DE74 ; DATA XREF: sub_429CA0+2B�r
.data:0046DE74 ; sub_429CA0+132�r ...
.data:0046DE90 damageModifierHE dw 64h,64h,64h,64h,4Bh,64h,64h,64h,82h,64h,64h,50h,3Ch,50h; 0
.data:0046DEAC damageModifierLaser dw 64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,96h,64h,46h; 0
.data:0046DEC8 damageModifierPlasma dw 64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,64h,50h,64h,46h; 0
.data:0046DEE4 damageModifierStun dw 64h,64h,5Ah,50h,64h,64h,50h,64h,64h,5Ah,64h,64h,64h, 0; 0
.data:0046DF00 damageModifierMelee dw 64h,78h,64h,64h,5Ah,64h,64h,64h,64h,64h,64h,64h,64h,64h; 0
.data:0046DF1C damageModifierAcidSpit dw 64h,0A0h,6Eh,64h,28h,64h,64h,64h,64h,64h,64h,64h,64h,64h; 0

===HWP weapons data===
.data:0046D57C builtinWeaponStats structBuiltinWeaponStats <0, 4, 3Ch, 3Ch, 21h, 0, 0, 5Ah, 50h, 0>; 0
.data:0046D57C ; DATA XREF: sub_403350+99�r
.data:0046D57C ; sub_40FF70+105�r ...
.data:0046D57C structBuiltinWeaponStats <2, 0Ch, 55h, 37h, 2Dh, 0, 0, 73h, 4Bh, 0>; 1
.data:0046D57C structBuiltinWeaponStats <3, 11h, 6Eh, 32h, 21h, 0, 0, 55h, 4Bh, 0>; 2
.data:0046D57C structBuiltinWeaponStats <4, 24h, 6Eh, 56h, 1Eh, 0, 0, 64h, 3Ch, 0>; 3
.data:0046D57C structBuiltinWeaponStats <2, 28h, 8Ch, 0, 0, 0, 0, 78h, 50h, 1>; 4
.data:0046D57C structBuiltinWeaponStats <7, 26h, 8Ch, 4Bh, 1Eh, 0, 0, 6Eh, 3Ch, 0>; 5
.data:0046D57C structBuiltinWeaponStats <4, 22h, 82h, 4Bh, 1Eh, 0, 0, 6Eh, 3Ch, 0>; 6
.data:0046D57C structBuiltinWeaponStats <3, 22h, 64h, 4Bh, 1Eh, 32h, 23h, 6Eh, 3Ch, 0>; 7
The structure is:
00000000 structBuiltinWeaponStats struc ; (sizeof=0x14)
00000000 damageType dw ?
00000002 ammoType dw ?
00000004 damage dw ?
00000006 snapshotAcc dw ?
00000008 snapshotTU dw ?
0000000A autoshotAcc dw ?
0000000C autoshotTU dw ?
0000000E aimshotAcc dw ?
00000010 aimshotTU dw ?
00000012 blasterEffect dw ?
00000014 structBuiltinWeaponStats ends

===Funding countries borders polylines===
.data:00474AD4 GeoBordersData dw 0FFFFh ; DATA XREF: GeoDrawBorders+3�r
.data:00474AD4 ; GeoDrawBorders+C�o
.data:00474AD6 dw 221h
.data:00474AD8 dw 0FF43h
.data:00474ADA dw 238h
.data:00474ADC dw 0FF3Dh
.data:00474ADE dw 22Ch
.data:00474AE0 dw 0FF28h
.data:00474AE2 dw 233h
.data:00474AE4 dw 0FF1Fh
.data:00474AE6 dw 236h
...
TFDT-CE(CRC32:C2F6C035): 0x0008AE00..0x0008B00F. 
use: rivers instead of country borders. 
data: lon,lat,lon,lat.. streams, Flags: lon = -1(NewLine), lon = -2(EndOfSection).

===Funding countries names coordinates===
.data:00474DF8 GeoCountryNamesData dw 280h ; DATA XREF: GeoDrawCountryNames+6�o
.data:00474DFA dw 0FF40h
.data:00474DFC dw 263h
.data:00474DFE dw 0B30h
.data:00474E00 dw 0FE53h
.data:00474E02 dw 25Ch
.data:00474E04 dw 0B2Ch
.data:00474E06 dw 0FEABh
.data:00474E08 dw 260h
.data:00474E0A dw 14h
.data:00474E0C dw 0FE8Ch
...
TFDT-CE(CRC32:C2F6C035): 0x0008B010..0x0008B06F. ((16*2)*3:lon,lat,Nid)

===Craft type data===
.data:0046F9A8 ; DATA XREF: sub_432B90+1C�r
.data:0046F9A8 ; sub_436970+59�r ...
craftsData
.data:0046F9A8 structCraftData <23Ah, 65336, 0, 760, 2, 1500, 150, 4, 0, 0, 0, 0Eh, 0,\
.data:0046F9A8 3, 0> ; 0 ''Skyranger''
.data:0046F9A8 structCraftData <23Bh, 65236, 1, 3100, 8, 30, 800, 4, 0, 0, 0, 0Ch, 0,\
.data:0046F9A8 0, 0> ; 1 ''Lightning''
.data:0046F9A8 structCraftData <23Ch, 65136, 2, 5400, 0Ah, 60, 1200, 4, 0, 0, 0, 1Ah,\
.data:0046F9A8 0, 4, 0> ; 2 ''Avenger''
.data:0046F9A8 structCraftData <23Dh, 65286, 2, 2100, 3, 1000, 100, 4, 0, 0, 0, 0, 0,\
.data:0046F9A8 0, 0> ; 3 ''Interceptor''
.data:0046F9A8 structCraftData <23Eh, 65286, 2, 4200, 9, 20, 500, 4, 0, 0, 0, 0, 0, 0,\
.data:0046F9A8 0> ; 4 ''Firestorm''
.data:0046F9A8 structCraftData <2B2h, 100, 2, 2200, 0Ch, 0, 50, 5, 38h, 0C8h, 0, 0, 0,\
.data:0046F9A8 0, 0> ; 5 ''Small Scout (VS)''
.data:0046F9A8 structCraftData <2B3h, 150, 2, 2400, 9, 0, 200, 4, 38h, 0FAh, 140078h,\
.data:0046F9A8 0, 0, 0, 0> ; 6 ''Medium Scout (S)''
.data:0046F9A8 structCraftData <2B4h, 250, 2, 2700, 9, 0, 250, 4, 30h, 12Ch, 140110h,\
.data:0046F9A8 0, 0, 0, 0> ; 7 ''Large Scout (S)''
.data:0046F9A8 structCraftData <2B5h, 500, 2, 4000, 8, 0, 500, 3, 30h, 1F4h, 2800B0h,\
.data:0046F9A8 0, 0, 0, 0> ; 8 ''Abductor (M)''
.data:0046F9A8 structCraftData <2B6h, 500, 2, 4300, 8, 0, 500, 3, 20h, 1F4h, 2800A0h,\
.data:0046F9A8 0, 0, 0, 0> ; 9 ''Harvester (M)''
.data:0046F9A8 structCraftData <2B7h, 1000, 2, 4800, 6, 0, 1200, 2, 18h, 7D0h, \
.data:0046F9A8 780150h, 0, 0, 0, 0> ; 10 ''Terror Ship (L)''
.data:0046F9A8 structCraftData <2B8h, 1400, 2, 5000, 6, 0, 3000, 1, 18h, 0FA0h, \
.data:0046F9A8 8C0208h, 0, 0, 0, 0> ; 11 ''Battleship (VL'')
.data:0046F9A8 structCraftData <2B9h, 800, 2, 3200, 6, 0, 2200, 2, 18h, 0BB8h, \
.data:0046F9A8 3C0120h, 0, 0, 0, 0> ; 12 ''Supply Ship (L)''

Craft type known fields: (14 x 2-byte dwords per record)
00000000 structCraftData struc ; (sizeof=0x1C)
00000000 nameIdx dw ?
00000002 scoreDestroyed dw ? ; base 10
00000004 weaponPods dw ? ''always 2 for UFOs. is this used for UFOs? how?''
00000006 maxSpeed dw ? ''in knots'' ; base 10
00000008 acceleration dw ?
0000000A fuelCapacity dw ? ; base 10
0000000C damageCapacity dw ? ; base 10
0000000E ufoSize dw ?
''5 - Very Small / 4 - Small (inc. XCom) / 3 - Medium / 2 - Large / 1 - Very Large -spike''
00000010 ufoReload dw ?
''UFO only. Firing interval. Values: 56=S/MSct 48=LSct/Abd 32=Harv 24=Suppl/Terr/BS. -spike''
00000012 ufoUnknown dw ?
''Unknown. Score related? SS=200 MS=250 LS=300 A=500 H=500 TS=2000 BS=4000 SS=3000 -spike''
00000014 ufoRange dw ? ''alien weapon distance in km*8 -kyrub/spike''
00000016 ufoPower dw ? ''alien weapon damage -kyrub/spike''
00000018 TroopSpace dw ? ''Troop capacity ''
0000001A HWPSpace dw ? ''HWP capacity -spike''
0000001C structCraftData ends

While the 9th [dword] could be UFO weapon Accuracy or even rate of fire, it seems unlikely. All the values are a multiple of 8 just like distance, so it may be related to that. That's my guess. I'm sure someone like Seb would know more. --[[User:Zombie|Zombie]] 23:56, 4 July 2009 (EDT)

:Sorry I didn't sign those theory guesses, I will do so now. Actually, evidence is building up that the byte at 0x10 within structCraftData is an inverse co-factor - i.e. a divisor - of the net total damage output of UFO attacks. In other words, it could well be a firing interval value such as is seen for XCom craft weapons. I have done 3-4 sets of ten tests so far (XCom craft survival-time tests, deducing UFO damage output). 1 set was for Medium Scout vs Interceptor, 2 sets were for Terror Ship vs Avenger. (I also did multiple attacker sets but those are harder to compare directly to this scenario). So far all 3 test sets are a reasonably good fit for this formula:

UFO net damage output =
<big>(</big>Weapon power x 75% ''(avg of randomisation)'' x 2/3 ''(accuracy)'' <big>)</big>
x <big>(</big> time ''(in game seconds)'' / 0x10 offset ''(firing interval)'' <big>)</big>

: What I want to do next is take one or both of those test scenarios, hack the 0x10 offset up or down, and see if the observed damage output varies inversely. If so, I think that will be pretty strong evidence. Even in my data, there is definitely still also some variation going on that is not fully accounted for in the formula above. As you say it is interesting the 0x10 values are all multiples of 8, suggesting distances. I will keep testing and see what I come up with! Cheers, [[User:Spike|Spike]] 06:39, 5 July 2009 (EDT)

I'm enclined to agree with the rate of fire theory. A countdown is stored in [[CRAFT.DAT]] at offset 0x26 and when it hits 0, the UFO fires. It is reset for the next shot with this formula:
tmp = offset10-2*difficultyLevel
nextShot = RAND(0,tmp)+tmp

Edit: Although the attack type does not appear here, I suspect that while a missile is "traveling", the countdown is not changed. As a result, closer ranges means higher rates of fire. [[User:Seb76|Seb76]] 07:36, 5 July 2009 (EDT)

:Excellent timing Seb! I was just about to start my tests. I could've coped with the random element, since I'm only measuring averages over time, but the presence of a 2nd factor (difficultyLevel), I was not expecting. It would have completely thrown my numbers. Also I might've crashed the game since I'd set offset10 to 0x08 on difficulty level Superhuman (=5?), creating a negative rate of fire! For simplicity I might do my tests on Beginner from now on, and repeat the earlier tests on Beginner.

:It's interesting that you don't see any reference to Attack Mode. So the changing rate of fire could indeed be a "Space Invaders Effect" as you say. Perhaps the reason this is not seen for cannon fire is that cannon fire is resolved instantly, whereas missiles are plotted as objects on the map? Is there any indication that missiles and cannon are handled differently by these routines?

:My test scenarios are probably too simplistic at the moment. But, I am sure I am seeing different rates of fire for missiles at the same range, dependent on whether they are in Standard or Cautious attack mode. I will recheck this. [[User:Spike|Spike]] 08:07, 5 July 2009 (EDT)

:Seb, I realise your formula above for variable firing intervals, from 100%-200% of the base value, explains the 2/3 factor I found which I thought might be UFO Accuracy. The average of a 100-200% range is 1.5, and the inverse of this is 2/3. So perhaps there is no accuracy factor in UFO weapon damage at all. Possibly you just have a base damage and a base firing interval, plus a 50%-100% variation on the base damage and a 100%-200% variation on the firing interval. This would certainly match the data I have so far.

:I have done a couple of tests of varying this offset 0x10 value and they show the right "sign": increasing this value decreases UFO damage output over time, and decreasing this value increases UFO damage output. The effect is strong, and approximately linear, i.e. halving the value roughly doubles the damage, etc (testing on Superhuman). To quantify it more exactly I need to go back and control for Difficulty Level which I did not expect to be a variable. I'm also going to control for the time taken for the UFO to close into firing range - by increasing the UFO weapon range in the tests to 70 or 75km.

:One thing that is worrying me though is that the firing interval is random. Since I'm using the firing interval of a cannon as my "timer" to measure the duration of all other events, it means I'm measuring with a yardstick that randomly changes size. I have to hope that my sample sizes are large enough that the averages will dominate over the fluctuations.

:More worrying is the idea that rate of fire varies with range (as opposed to with Attack Mode). That would be an elastic yardstick, worse than a random one. I thought I had disproved this but I need to go back and do it again, more carefully. I need to test the same weapon at the same range with different attack modes, again. I may well be guilty of building my hypothesis into my test scenario as an assumption! I will also double check the assumption that hacking the firing interval values for XCom weapons has no effect. I'm pretty sure that, even if the absolute firing interval changes with range, the relative ratios of firing interval when comparing different weapons, does not change. But I'll double check.

:In the code, do you see any evidence of cannon-type weapons being treated differenly from missile weapons? For example, do cannon rounds not "travel"? Also, do you see the same '''rnd (0,tmp) + tmp''' function being applied to the firing interval of XCom air attacks? Regards, [[User:Spike|Spike]] 14:30, 5 July 2009 (EDT)

===Base components data===
.data:00470640 baseElements baseComponentStruct <249h, 300, 1, 4, 0, 0, 5>; 0
.data:00470640 ; DATA XREF: BaseEditDrawSideBar_sub_432EF0+12D�r
.data:00470640 ; BuildFacilities+74�o ...
.data:00470640 baseComponentStruct <24Ah, 400, 16, 10, 1Eh, 0, 4>; 1
.data:00470640 baseComponentStruct <24Bh, 750, 26, 30, 0Ah, 0, 4>; 2
.data:00470640 baseComponentStruct <24Ch, 800, 32, 35, 32h, 0, 4>; 3
.data:00470640 baseComponentStruct <24Dh, 500, 12, 10, 0, 0, 5>; 4
.data:00470640 baseComponentStruct <24Eh, 800, 25, 15, 0, 0, 4>; 5
.data:00470640 baseComponentStruct <24Fh, 200, 16, 5, 0, 3201F4h, 5>; 6
.data:00470640 baseComponentStruct <250h, 150, 10, 5, 0FAh, 0, 4>; 7
.data:00470640 baseComponentStruct <251h, 400, 18, 15, 0Ah, 0, 4>; 8
.data:00470640 baseComponentStruct <252h, 400, 24, 10, 0, 3C0258h, 0Ah>; 9
.data:00470640 baseComponentStruct <253h, 600, 34, 12, 0, 460384h, 0Ah>; 10
.data:00470640 baseComponentStruct <254h, 800, 34, 14, 0, 5004B0h, 0Ah>; 11
.data:00470640 baseComponentStruct <255h, 1200, 38, 15, 0, 0, 9>; 12
.data:00470640 baseComponentStruct <256h, 1300, 33, 5, 0, 0, 9>; 13
.data:00470640 baseComponentStruct <257h, 750, 24, 16, 0Ah, 0, 8>; 14
.data:00470640 baseComponentStruct <258h, 1400, 26, 30, 0, 0, 9>; 15
.data:00470640 baseComponentStruct <259h, 200, 25, 25, 1, 0, 4>; 16
fields:
00000000 baseComponentStruct struc ; (sizeof=0x10)
00000000 stringId dw ?
00000002 cost dw ? ; base 10
00000004 constructionTime db ? ; base 10
00000005 maintenance db ? ; base 10
00000006 anonymous_4 dw ?
00000008 anonymous_5 dd ?
0000000C anonymous_8 dd ?
00000010 baseComponentStruct ends

===Alien missions data===
(I made another post for this one in missions.dat):
.data:00470E70 alienMissionData structAlienMission <5, 1, 0, 12Ch> ; 0
.data:00470E70 ; DATA XREF: SpawnAlienShip+10D�r
.data:00470E70 ; UpdateAlienMissions+78�r ...
.data:00470E70 structAlienMission <6, 1, 2, 104h> ; 1 ;
.data:00470E70 structAlienMission <7, 2, 4, 12Ch> ; 2 ;
.data:00470E70 structAlienMission 5 dup(<0FFFFh, 0FFFFh, 0FFFFh, 0FFFFh>); 3
...
fields:
00000000 structAlienMission struc ; (sizeof=0x8)
00000000 ufoType dw ?
00000002 numUfoToSpawn dw ?
00000004 unknown dw ?
00000006 timeCounter dw ?
00000008 structAlienMission ends

===Ground patches===
(used to spawn locations on continents):
.data:00471278 randPlaces structArea <640h, 0FDF8h, 0A0h, 28h> ; 0
.data:00471278 ; DATA XREF: GetRandomPositionOnContinent+2D�r
.data:00471278 ; GetRandomPositionOnContinent+46�r ...
.data:00471278 structArea <730h, 0FDF8h, 0F0h, 50h> ; 1
.data:00471278 structArea <8C0h, 0FE70h, 50h, 50h> ; 2
.data:00471278 structArea <730h, 0FE70h, 0A0h, 50h> ; 3
.data:00471278 structArea <820h, 0FE70h, 0A0h, 50h> ; 4
.data:00471278 structArea <730h, 0FEC0h, 0A0h, 50h> ; 5
.data:00471278 structArea <7D0h, 0FEC0h, 0B0h, 60h> ; 6
.data:00471278 structArea <870h, 0FEB0h, 0A0h, 88h> ; 7

00000000 structArea struc ; (sizeof=0x8)
00000000 xstart dw ?
00000002 ystart dw ?
00000004 width dw ?
00000006 height dw ?
00000008 structArea ends

===Zones sectors===
(used to get the zone number for a world coordinate):
.data:00474F38 geo_globe_zones structGlobeZone <618h, 987h, 0FDD0h, 0FE47h, 0>; 0
.data:00474F38 ; DATA XREF: GetWorldZoneFromPos+10�o
.data:00474F38 structGlobeZone <730h, 987h, 0FE48h, 0FF0Fh, 0>; 1
.data:00474F38 structGlobeZone <780h, 95Fh, 0FF10h, 0FFAFh, 0>; 2
.data:00474F38 structGlobeZone <0, 0B3Fh, 0FD30h, 0FDCFh, 1>; 3
.data:00474F38 structGlobeZone <0, 0B3Fh, 1E0h, 2D0h, 2>; 4
.data:00474F38 structGlobeZone <870h, 9D7h, 0FFB0h, 0FFFFh, 3>; 5
.data:00474F38 structGlobeZone <898h, 0A4Fh, 0, 77h, 3>; 6
.data:00474F38 structGlobeZone <898h, 0A27h, 78h, 1DFh, 3>; 7
.data:00474F38 structGlobeZone <0A78h, 1DFh, 0FDD0h, 0FEE7h, 4>; 8
.data:00474F38 structGlobeZone <0A78h, 13Fh, 0FEE8h, 0FF87h, 5>; 9
.data:00474F38 structGlobeZone <0A78h, 1B7h, 0FF88h, 0FFFFh, 5>; 10
.data:00474F38 structGlobeZone <28h, 1B7h, 0, 13Fh, 6> ; 11
.data:00474F38 structGlobeZone <140h, 22Fh, 0FEE8h, 0FF87h, 7>; 12
.data:00474F38 structGlobeZone <1E0h, 2CFh, 0FE70h, 0FEE7h, 7>; 13
.data:00474F38 structGlobeZone <230h, 2CFh, 0FEE8h, 0FFD7h, 7>; 14
.data:00474F38 structGlobeZone <2D0h, 347h, 0FE70h, 4Fh, 8>; 15
.data:00474F38 structGlobeZone <348h, 4AFh, 0FE70h, 0FFD7h, 8>; 16
.data:00474F38 structGlobeZone <1E0h, 59Fh, 0FDD0h, 0FE6Fh, 9>; 17
.data:00474F38 structGlobeZone <348h, 59Fh, 0FFD8h, 18Fh, 0Ah>; 18
.data:00474F38 structGlobeZone <5A0h, 617h, 0FDD0h, 0FE47h, 0Bh>; 19
.data:00474F38 structGlobeZone <5A0h, 72Fh, 0FE48h, 0FF0Fh, 0Bh>; 20
.data:00474F38 structGlobeZone <5A0h, 77Fh, 0FF10h, 0FFAFh, 0Bh>; 21
.data:00474F38 structGlobeZone <5A0h, 86Fh, 0FFB0h, 0FFFFh, 0Bh>; 22
.data:00474F38 structGlobeZone <5A0h, 897h, 0, 1DFh, 0Bh>; 23
.data:00474F38 structGlobeZone <4B0h, 59Fh, 0FE70h, 0FFD7h, 0Bh>; 24
.data:00474F38 structGlobeZone <988h, 0A77h, 0FDD0h, 0FF0Fh, 0Ch>; 25
.data:00474F38 structGlobeZone <960h, 0A77h, 0FF10h, 0FFAFh, 0Ch>; 26
.data:00474F38 structGlobeZone <9D8h, 0A77h, 0FFB0h, 0FFFFh, 0Ch>; 27
.data:00474F38 structGlobeZone <0A50h, 27h, 0, 77h, 0Dh>; 28
.data:00474F38 structGlobeZone <0A28h, 27h, 78h, 1DFh, 0Dh>; 29
.data:00474F38 structGlobeZone <28h, 1B8h, 140h, 1DFh, 0Dh>; 30
.data:00474F38 structGlobeZone <1B8h, 22Fh, 0FF88h, 4Fh, 0Eh>; 31
.data:00474F38 structGlobeZone <230h, 2CFh, 0FFD8h, 4Fh, 0Eh>; 32
.data:00474F38 structGlobeZone <1B8h, 347h, 50h, 1DFh, 0Eh>; 33

Same for country zones:
.data:00475090 geo_glob_country_zones structGlobeZone <758h, 7F8h, 0FE78h, 0FF00h, 0>; 0
.data:00475090 ; DATA XREF: GetCountryFromPos+11�o
.data:00475090 structGlobeZone <7F8h, 8ACh, 0FE78h, 0FF18h, 0>; 1
.data:00475090 structGlobeZone <820h, 848h, 0FF18h, 0FF30h, 0>; 2
.data:00475090 structGlobeZone <8A8h, 8C0h, 0FF00h, 0FF38h, 0>; 3
.data:00475090 structGlobeZone <8ACh, 8F0h, 0FEA0h, 0FF00h, 0>; 4
.data:00475090 structGlobeZone <8F0h, 924h, 0FE94h, 0FEC0h, 0>; 5
.data:00475090 structGlobeZone <0F0h, 190h, 0FDD0h, 0FE98h, 1>; 6
.data:00475090 structGlobeZone <0C0h, 0F0h, 0FE20h, 0FEB0h, 1>; 7
.data:00475090 structGlobeZone <190h, 258h, 0FD98h, 0FEC0h, 1>; 8
.data:00475090 structGlobeZone <258h, 528h, 0FD80h, 0FE70h, 1>; 9
.data:00475090 structGlobeZone <528h, 550h, 0FDD0h, 0FE28h, 1>; 10
.data:00475090 structGlobeZone <0B00h, 10h, 0FE20h, 0FE70h, 2>; 11
.data:00475090 structGlobeZone <0B18h, 38h, 0FE70h, 0FEA8h, 3>; 12
.data:00475090 structGlobeZone <30h, 78h, 0FE48h, 0FE84h, 4>; 13
.data:00475090 structGlobeZone <38h, 78h, 0FE8Ch, 0FEA8h, 5>; 14
.data:00475090 structGlobeZone <58h, 90h, 0FEA8h, 0FED8h, 5>; 15
...

===Dot color data for LOC.DAT entries===
shawn on world map (can't think of a better name...):
.data:00475202 locationColor dw 0, 0Dh, 0Bh, 9, 1, 5, 7, 3 ; 0
.data:00475202 ; DATA XREF: geoDrawLocations+ED�r

Just after that are data describing the mask for drawing the location (I don't remember the format, but it shouldn't be something too complicated to decypher)

===Flare pattern===
(tactical mode):
.data:0046C558 flarePattern db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 0
.data:0046C558 ; DATA XREF: LightmapAddFlarePattern+7�o
.data:0046C558 ; LightmapAddFlarePattern+19�o
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 31
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 62
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h; 93
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h; 124
.data:0046C558 db 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Ah, 0Ah, 0Ah, 0Ah, 0Ah, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h; 155
.data:0046C558 db 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 0Ah, 9, 9, 9, 9, 9, 0Ah, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h; 186
.data:0046C558 db 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 9, 9, 8, 8, 8, 8, 8, 9, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h; 217
.data:0046C558 db 10h, 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 9, 8, 8, 7, 7, 7, 7, 7, 8, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 10h, 10h; 248
.data:0046C558 db 10h, 0Fh, 0Eh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 9, 8, 7, 7, 6, 6, 6, 6, 6, 7, 7, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Eh, 0Fh, 10h; 279
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 0Ah, 9, 8, 7, 6, 6, 6, 5, 5, 5, 6, 6, 6, 7, 8, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 310
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 5, 4, 4, 4, 5, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 341
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 4, 3, 3, 3, 4, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh; 372
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 4, 3, 2, 2, 2, 3, 4, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 403
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 3, 2, 1, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 434
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 465
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 3, 2, 1, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 496
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 4, 3, 2, 2, 2, 3, 4, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh; 527
.data:0046C558 db 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 5, 4, 4, 3, 3, 3, 4, 4, 5, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh; 558
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 8, 7, 6, 6, 5, 5, 4, 4, 4, 5, 5, 6, 6, 7, 8, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 589
.data:0046C558 db 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 0Ah, 9, 8, 7, 6, 6, 6, 5, 5, 5, 6, 6, 6, 7, 8, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Fh, 10h; 620
.data:0046C558 db 10h, 0Fh, 0Eh, 0Eh, 0Dh, 0Ch, 0Bh, 0Ah, 9, 9, 8, 7, 7, 6, 6, 6, 6, 6, 7, 7, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Dh, 0Eh, 0Eh, 0Fh, 10h; 651
.data:0046C558 db 10h, 10h, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 9, 9, 8, 8, 7, 7, 7, 7, 7, 8, 8, 9, 9, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 10h, 10h; 682
.data:0046C558 db 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 9, 9, 8, 8, 8, 8, 8, 9, 9, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h; 713
.data:0046C558 db 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Ah, 0Ah, 0Ah, 9, 9, 9, 9, 9, 0Ah, 0Ah, 0Ah, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h; 744
.data:0046C558 db 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Ah, 0Ah, 0Ah, 0Ah, 0Ah, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h; 775
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Bh, 0Bh, 0Bh, 0Bh, 0Bh, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h; 806
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Dh, 0Dh, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Ch, 0Dh, 0Dh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h; 837
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Dh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 868
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Eh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 899
.data:0046C558 db 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 0Fh, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h, 10h; 930

Sorry for the big post and the raw format... [[User:Seb76|Seb76]] 13:59, 10 March 2008 (PDT)

Construction costs for access lifts:
.data:0046E69C basePrice dd 800000, 950000, 900000, 600000, 1000000, 650000, 550000, 500000, 750000; 0
.data:0046E69C dd 800000, 750000, 600000, 3 dup(500000); 9
[[User:Seb76|Seb76]] 11:01, 16 March 2008 (PDT)

=== Craft weapon stats ===

I guess the craft weapon stats could be in here too?
as far I can see these are at 353378 (plain 1.4), 18 bytes, 9x2 byte: 
index/range/acc/dmg/??/time/no of ammo/??/ammo 
--[[User:Emphyrio|Emphyrio]] 15:25, 1 March 2009 (CST)

----

In the WinCE version (unpatched) the craft weapon stats start at offset 0x6fb18. Or search for this signature:

40 02 1e 00 46 00 46 00 01 00 0f 00 06 00 01 00 06 00

Fields are:
Index - Range (km) - Hit% - Damage - ?X? - reload time - ammo cap - ?Y? - ammo type

Weapon X Y
Stingray 1 1
Avalanche 3 1
Cannon 8 100
FBL 5 1
Laser C 10 50
Plasma C 12 50

I would speculate that value "Y" is the re-arming rate on the ground. I think this data differs slighly from what is stated at [[Rearming]] so it might be worth double checking that.

Value "X" could be a bitmask, an index to a sound effect, or just about anything. It's possible the lowest bit is a flag that is set for a missile weapon, unset for a cannon-type weapon.

[[User:Spike|Spike]] 19:43, 5 July 2009 (EDT)

The "reload time" value (as it is called in the in-game UFOPaedia) does not seem to be used by the executable. Instead, hard coded values are used. See [[UFO Interception#Observed Rates of Fire|Observed Rates of Fire]]. [[User:Spike|Spike]] 20:31, 13 July 2009 (EDT)

=== Manufacturing stats? ===

Has someone worked out the manufacturing stats at offset <s>355596</s> 355600 (vanilla 1.4)??
As far as I can see it looks like 35 records of 18 bytes 
 
:See the [[PRODUCT.DAT]] page. --[[User:Zombie|Zombie]] 16:25, 24 February 2009 (CST)
:: ok, this is actually is a useful bit of information, I <s>would</s> have put it in the article.. --[[User:Emphyrio|Emphyrio]] 07:06, 25 February 2009 (CST)
:Good deal. I also added a note to the top of [[PRODUCT.DAT]] (and linked the [[Manufacturing_Profitability]] to PRODUCT.DAT - that should've been there, too). -[[User:MikeTheRed|MikeTheRed]] 11:17, 25 February 2009 (CST)

==New Bundles==

The "Complete Package" and such versions of X-Com from Steam, interestingly enough, include both versions of the game, at least .exe wise. The one that runs when you just launch from the Steam menu is the original European version, 1.2, so I wonder exactly why they included the other version. -[[User:Elliotw2|Elliotw2]] 2009-01-15 18:01:37

:Hiya Elliotw2! I wasn't watching this page's Talk page before, but I am now.
:As for the various versions, I dusted off some 10 y.o. DOS floppies a few years ago. They still worked, and I ran with it (U.S. DOS v. 1.4). Although I've read a lot about the other versions on this wiki, I'll let the other vets here address what you just said (smile). I personally would have chosen the U.S. version... Vets, why would they have both versions in the bundle, but make the default be the European version?
:Elliotw2, please leave a mini-review (or repeat what you just said) at [[GEOSCAPE.EXE#X-COM_Complete_Packages]] (see my new "mini-review" format request there). Sorry for the mess, newcomers - especially having this tucked away under GEOSCAPE, but it makes sense to us grognards. As always, we will change and grow as needed, and "us" easily includes "you". For now, we're just trying to make sure that newcomers can find what they need here, and that there's a place for info on the Complete Packages to be voiced.
:-[[User:MikeTheRed|MikeTheRed]] 03:49, 19 January 2009 (CST)

== Difficulty patch information wrong? ==

It appears that the information for patching the difficulty is wrong on this page.

I have what I believe is the US version of XCOM 1.4, and I patched the file as per the data given for 1.4, and yet it still created a 60-byte IGLOB.DAT file. Further, DOSBOX complained of illegal memory accesses after the patch (which it did not do before).

33ea0819e6888f0450f9a1e5e19dc98b *GEOSCAPE.EXE (binary MD5SUM -- file is 382,957 bytes, created 1995-02-28 @ 10:24 PM)

There actually was a 60 byte (0x3c) at the location given, but I have a feeling it was something other than the size_t in question.