Talk:GEOSCAPE.EXE

From UFOpaedia
Jump to navigation Jump to search

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?

- 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.

- 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. 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.--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. 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. --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 = 
(Weapon power x 75% (avg of randomisation) x 2/3 (accuracy) ) 
 x ( time (in game seconds) / 0x10 offset (firing interval) )
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, 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. 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. 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, 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... 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

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
--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.

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 Observed Rates of Fire. Spike 20:31, 13 July 2009 (EDT)

Manufacturing stats?

Has someone worked out the manufacturing stats at offset 355596 355600 (vanilla 1.4)?? As far as I can see it looks like 35 records of 18 bytes

See the PRODUCT.DAT page. --Zombie 16:25, 24 February 2009 (CST)
ok, this is actually is a useful bit of information, I would have put it in the article.. --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). -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. -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.
-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.