UFOpaedia - User contributions [en]

Talk:Initial Deployment

2018-08-02T19:18:46Z

Mannon:

I'm somehow missing a very important tip: Wait one turn before deployment.
What you do is have your first two soldiers kneel and face to the side, so they can see and reaction shoot any aliens coming into view during their turns. Of course, if an alien is visible from the beginning, it has to be killed right away.

Advantages if one waits one turn:
# the aliens will all have moved, and will not have their full TU's left for reaction shots
# the motion scanner can pick up signals from aliens nearby

Disadvantage:
# of course, the troops sitting in the open skyranger are an ideal target if spotted by the aliens.

Because of this disadvantage, one must carefully consider the part of the map where the skyranger has landed. If there is a high chance of interception, then the deployment should be immediately performed. [[User:Markho|Markho]] 08:19, 14 December 2011 (EST)

: One solution to that is to drop a smoke grenade inside just by the exit of the Skyranger. This will prevent you from seeing what's outside by the ramp, but then again if you have a smoke grenade at the bottom of the ramp anyway, you generally want those deploying to find any threats you find outside. -[[User:NKF|NKF]] 13:45, 16 December 2011 (EST)

::Thanks NKF; I also discovered that ,wait one turn' is already implemented into the deployment strategy. The advantages of this are just not really detailed, but that isn't so important. [[User:Markho|Markho]] 06:26, 19 December 2011 (EST)

I've found once you develop flying suits that one of the best things is to move soldier to the top of your craft. You can take cover on top from an elevated position which grants additional range for vision as well as a very open field of fire, and the craft gives cover from below. I can usually keep a couple snipers on top for the duration of the mission. [[User:Mannon|Mannon]] ([[User talk:Mannon|talk]]) 21:17, 2 August 2018 (CEST)

User talk:Seb76

2011-04-05T10:40:57Z

Mannon: /* UFOloader and Xcomutil */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

My problem is the following: if I try to run the loader normally, a console window pops up for a few seconds then I get an "illegal instruction" error from NTVDM (and the window disappears, yet it's button remains on the taskbar until I kill the process). If I try to run it with DosBox however, I get "illegal command: UFOLOADER.EXE". Point is, I can't run this at all.--[[User:Amitakartok|amitakartok]] 11:27, 13 October 2009 (EDT)
:Looks like you're trying to use the DOS version here. Only the CE (windows) version is supported. [[User:Seb76|Seb76]] 13:48, 13 October 2009 (EDT)

Hi, is it in any way possilbe to run the Extender in Win98? I just set up an old machine with it and wanted to give it a try but as you said above, it won't work with Win9x. But is there a way to manually mod the game? I am asking becaus on my WinXP Machine the game often crahes in battlescape and that really sucks =(--[[User:Skaw847|Skaw847]] 19:28, 21 May 2010 (EDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)
:::I for one am a huge fan of XcomUtil, though I'm now also a huge fan of UFO Extender! I'm really hoping I can get the two to play nice. I was up until now playing a dos version, myself. Mainly because the version I bought years and years ago was the DOS version on CD and it still worked via dosbox, which also has several filters similar to your HQ4x. (Some run a little faster and I think they can run in a window while I can't get HQ4x to run windowed at all. I don't mind that so much, though the game runs noticeably slower when I run HQ4x and I prefer to run windowed these days so I can more easily multitask. Still I LOVE UFO Extender so I switched to the Windows version just for this.) Some of XcomUtil's features only work in the DOS version with split exe's because it goes back into the batch file and allows XcomUtil to play with things when switching from Geoscape to Battlescape and vice versa. But, it's not that big a deal for me. UFO Loader's feature list is more than robust enough to give that up. As for the sounds the Windows CE versions changed a lot of the sound effects. If you're used to this version then it's Np, but if you played the DOS version and got used to it then it's VERY off putting. Luckily it's easy to patch it back to the DOS sound effects. The "Enemy Unknown Extended" page here lays out an install that includes UFO Extender, the original DOS sounds, ect... It's a good place to start. Anyway, great tool. Now let's see if I can get these to play nice.[[User:Mannon|Mannon]] 04:40, 27 March 2011 (EDT) (I keep forgetting to sign things... too used to forums instead of discussion pages.)
::::Facinatingly XcomUtil actually DOES split the CE's executable into geoscape.exe and tactical.exe! It uses it's own sdump utility to do this during the setup batch file. I misread the above. XcomUtil splits them to preserve it's fuctionality so that it can use the batch file to knit them together like in the original DOS version and insert it's own exe into the mix. This does not make the windows exe run in DOS of course, but it does allow XcomUtil to keep it's functionality. I have to assume it really screws up UFO Extender, though... ;-( [[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)

Decided to look into this as there are a few XcomUtil features I like that aren't reproduced in UFO Extender. XCU does indeed split the exe. It also modifies both of the split exe's. It still loads both via fodder's loader when running them from the batch file. The command lines for that are "start /w xcloader geoscape.exe "0"" and start /w xcloader tactical.exe "1". Replacing xcloader with UFO Loader appears to work for tactical. The command line even appears to point UFO loader to the tactical exe since going into combat causes a problem. If I change the first xcloader call to "start /w xcloader" then the renamed UFO Loader finds the unsplit exe. Going into combat no longer fails like this, but it also prevents XcomUtil from running between phases. This does not prevent the running of XCU completely, but it will cause problems with some features, especially in the placement of soldiers in the new craft maps that XCU adds. Then again, by using the UFO Loader to use the original unsplit exe I believe that you are also bypassing all of XCU's modifications to the exe's as it probably does all those modifications to the geoscape and tactical exe's it created when splitting the exe. It may be possible to recombine those exe's or to find command line parameters that allow UFO Loader to load tactical.exe on it's own. The latter would probably be the best solution since it should allow XCU to function between phases.[[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)
:Splitting of the exe is accomplished by first simply copying it with both of the destination filenames. Then sdump is run on each one using settings from XcomUtil.cfg to essentially transform each one into the geoscape only and battlescape only versions. The settings are available in the cfg, but not documented so I don't really understand them. Though... it is actually starting to make some sense as I compare the cfg to the sdump documentation in XcomUtil.txt. Seems like it would be possible to reverse the patch, though it might require first extracting the correct data from the unsplit version. Note: The split up geoscape.exe and tactical.exe are exactly the same size as the original ufo defense.exe, thus data was not removed by sdump, merely changed. I think the only change needed were to cause geoscape.exe to exit at the right time instead of going immediately to the battlescape, and for tactical.exe to go directly to battlescape loading the mission data like the old DOS version.[[User:Mannon|Mannon]] 22:01, 29 March 2011 (EDT)
::I believe that I have managed to get XcomUtil and UFO Extenter at least working together with a kludge. My method involves using modified versions of XcuSetup.bat and RunXcomW.bat and the creation of a new exe, (to avoid overwriting the original and keep it as a backup). RunXcomW.bat is changed to point to UFOLoader.exe instead of xcloader.exe and points UFOLoader at the new exe UFOmerge.exe. The second call of xcloader which normally initiates the battlescape has been simply disabled as it will never occur under my setup. The changes to XcuSetup.bat are also pretty simple. I allow it to copy the UFO exe into geoscape and tactical because XcomUtil.exe will only modify these exe's. But I disable the patching done to each via sdump which turns them into independent phases of the game. Then in every instance where XcuSetup calls XcomUtil to make a change to the exe's I insert a line after it that uses sdump to merge those exe's back into UFOmerge.exe. Viola! Theoretically this should allow XcomUtil to modify the UFO exe while still allowing UFO Extender to make it's own changes. However... Not all XcomUtil functions will work and some of them will flat out break because it cannot be called when switching phases of the game. So, for example, if you use the larger craft XCU includes then you could be in trouble since XCU cannot be run to place your soldiers properly. I suggest you stick to the normal number of soldiers each craft can carry. If I knew a way to make UFOLoader.exe compatible with tactical.exe then it should be possible to have full functionality. It actually works perfectly fine with geoscape.exe. Seb76, if you're around anymore I can provide you with exactly which bytes are altered in tactical.exe for both UFO and TFTD as they are in XcomUtil.cfg. After looking at the sdump documentation it's actually pretty straitforward. It basically uses hex numbers as commands specifying goto this address, write the next X bytes, skip the next X bytes, ect... I'll make my modified XcomUtil files available on my page if anybody asks for them. Now... to figure out how to disable the XcomUtil base disjoint bug fix. lol I think I'd prefer the UFO Extender fix, and I like having the option to leave the bug in place and use it for tactical options.[[User:Mannon|Mannon]] 05:07, 30 March 2011 (EDT)
:::Kept getting sidetracked, but I finished that part and added it to XcuSetup.bat. All it took was adding the one line, "if exist maps\xbase_01.xcu xcopy maps\xbase_*.xcu maps\xbase_*.map /y" right after XcomUtil does it's map:cfg write. This only leaves the disjoint bug in xcom bases. I could revert the alien bases too, but I figure why bother doing that.[[User:Mannon|Mannon]] 10:56, 30 March 2011 (EDT)
::::NVM '''Skip all this and use XcomUtil 9.7.''' It works just fine with UFO Extender even with split exe's, and makes all the bug fixes optional too.[[User:Mannon|Mannon]] 06:40, 5 April 2011 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Could we get TUs (in current/max format) at the inventory screen while on a mission? It would greatly help with swapping weapons among soldiers.

* Could we get little numbers [like on the screenshot of accuracy mod] showing how much TUs an action on the inventory screen would take? Some players (me, of course, included) can't really remember all that reloading from backpack or from a leg slot TUs. Also...

* a "drop all" button, maybe?

* Soldiers' positioning in Skyranger is very good... but with the Avenger it is not so pretty. The ones at the top are not the ones closest to the trap door. Chooseable patterns, maybe?

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.
: '''Save Equipment''' is under development, still some bugs

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
** Eliminate "infinite fuel" exploit for conventional aircraft.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

* Enable native alien melee attacks within Alien Pets. The Floaters are pleading. (At the moment, Alien Pets+Big Brother means a crashed Superhuman Floater Large Scout costs 6-8 X-COM agents; corresponding crashed Sectoid Superhuman Large Scout is only worth 3-5 X-COM agents. Floater Large Terror Ship on just Big Brother : only one agent, and that was due to the top-of-stair pinning bug providing enough TU to do something.) -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Do something to help out the psi aliens as well within Alien Pets, as above. -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Would it be possible to change the master volume level in the game, or at least have a no sound option? [[User:Epiceuropean|Epiceuropean]] 00:26, 12 January 2010 (EST)

=== A few more ===

Do any of these take your fancy:

* Draw the Radar detection radii onto the map as a circle(s) around the base (also for moving aircraft?)

* Show All UFOs (Ultrawave Detector - like Show All Locations, but doesn't show Alien Bases, you still have to hunt for those).

* Sensible Ammo Recovery = add up all remaining rounds of ammunition at the end of a mission (in the ship, if Aborting), and recover a number of (full) clips equal to that number divided by the clip capacity (rounded down maybe).
: There's a reason I didn't turn Clip Recovery on, and it's that I guessed that it didn't work exactly as it's suggested here. If it did work like this, I would use it. [[User:Stubbs|Stubbs]]

* Implement tactical time limits for UFO Assaults/Recoveries. After a random period (within a pre-defined upper and lower time limit), the aliens leave. Pop up warnings appear at the end of each turn, saying the UFO engines are powering up. When the aliens leave, all aliens/items/equipment inside the UFO is gone - no loot, no score. Any soldiers still inside the UFO are considered MIA. The soldiers are ''captured'' in fact - score penalty worse than MIA? There must be one conscious alien inside the UFO for it to leave or attempt to leave. Maybe any live aliens outside are 'beamed' or 'tractored' inside the UFO, complete with their equipment? (E.g. the mission ends and you don't get score for them or their equipment either - just for the corpses and dropped loot).

* No Milk Please: After XCom withdraws from an Alien Base, randomise the base's location and make it hidden again. Just like what happens to the aliens after they fail to assault an X-Com base. Though you would probably still need to locate it within the same country or region so finding it again wouldn't take long I guess. Would it mess things up to move the base to a random part of the world?

* [[User:Spike#Tank mods|Tank Armour and Equipment Mods]]

But I should probably code this up myself, looking at your source code it doesn't look '''too''' hard. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

[[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

* Burning Zombies

It's more or less impossible to prevent Zombies from hatching into Chryssalids by killing the Zombies with fire, since fire does such a small amount of damage, and the requirement is that the actual killing point of damage is done by an incendiary. Apart from hitting them with an incendiary and running away, then waiting about ten turns for them to die (probably repeating the attack once or twice), this is only ever going to happen by blind luck.

It would be much more viable if the rule was (also?) that a Zombie which is '''on fire''' at the time of death would not hatch into a Chryssalid. This is not exactly easy either, but it is at least possible. It requires hitting the Zombie repeatedly with incendiary weapons until it catches on fire, then killing it right away with regular weapons (before the fire goes out).

A much easier version of this approach would be to say that if the Zombie is killed while it is '''in fire''', it does not hatch. But that is probably too easy.

A way to do this by hacking game files, without code changes, would be to increase the Zombie susceptibility to fire, to 200%. This would make incendiary weapons a viable way of killing them, as well as increasing the likelihood that the killing shot was an incendiary shot.

An alternative approach would be for the Zombie to have a chance of not turning into a Chryssalid, proportional to the percentage of health damage that had been caused by incendiaries. But that's probably too hard to track, it would require an extra/unused field in UNITREF.DAT.

[[User:Spike|Spike]] 13:12, 7 September 2009 (EDT)

* Fear of Fire

Apparently there is no morale effect from [[Incendiary#Damage|Incendiary damage]]. If anything, for humans, and maybe be for other humanoid aliens, fire should probably have a greater morale effect than ordinary damage, not none. A basic fix would treat fire damage the same as normal damage when reducing morale. A more complicated fix could add a weighting to this morale effect: multiply by the creatures susceptibility to fire (or reduce by its resistance to fire). Any creature or soldier that is immune to fire should not have its morale affected. Actually the affects of fire vary quite a lot (different aliens, different human armour types). Maybe this is why the designers didn't get around to implementing morale effects for fire, as it's a bit complicated.

[[User:Spike|Spike]] 13:40, 7 September 2009 (EDT)

=== Multi Stage Missions ===

Between each stage of a multi-stage mission:

* Send all artefacts (non-usable items), corpses and recoverables back to base
* If possible, remember the score for these items, and apply it to the score at the end of the mission
* Alternatively, pop up a score window between the mission stages, and apply the score then?
* Gather all loose usable equipment into the "equipment pile" for the next stage
* Or possibly re-run the Equip Screen between mission stages, again gathering all loose usable items into the equipment pile first.
* Keep an 80 item limit on what you can take into the next stage
* Prune down to the 80 item limit using some sensible rules, not sure what exactly.

This is of limited use in X-Com EU but would be much more use for TFTD, one day. EU has only one multi stage mission, and it ends the game, so only some of these points above will be relevant.

[[User:Spike|Spike]] 20:54, 2 September 2009 (EDT)

=== Even More ===

Tremendous work, you've pretty much made the game worth playing again. Best work since Xcomutil. As with everone else, I have a few requests. [[User:KingMob4313|KingMob4313]] 23:59, 12 August 2009 (EDT)

: Ability to change damage modifier. Right now the damage runs from 0-200% of damage values on the weapon. I'd love to see a way to change it to 50-150%, 75-125% or the like.

: A modifier to increase or decrease the explosion radius modifier. Right now the radius is either keyed to the explosive or to the explosive damage. I'll investigate it further. But it would be nice to have a very small radius, but high powered explosive for use as a breaching charge.
:: There is a "crimping" function on some of the explosions already so it might be possible to exploit that. Check the [[Explosions]] page. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

: A modification of the range based accuracy. One handed weapons have a shorter range, to the point that even their aimed shots have an effective range, two handed weapons have a further range (and no aimed shot effective range) and really heavy two handed weapons have an even further range.

: Ability to enable the Burst fire (5 shots over 3 picked spots) and/or the full auto mod that is on the heavy laser on other weapons (set by a flag).

: A modification so that on the alien's side first turn, they do not have their full time units in reserve for reaction fire. Nothing like getting shot 3 times from the same sectiod after missing ONE shot on them.

:: You could always wait a turn before you open the door. :) [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

::: Good point, I should be doing that anyways.

=== More Exploits to Close ===

* [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]

Probably the worst single exploit in the game. What is needed is to disable any mind control actions for a Psi Amp, if the unit holding the Psi Amp is currently mind controlled.

Also a general mind control bug/exploit fix for:

* [[Exploiting Mind Control#Exponential Mind Control|Civilian Traitors]]
* [[Exploiting Mind Control#Exponential Mind Control|Resurrect Zombified Agents]]
* [[Exploiting Mind Control#Exponential Mind Control|Zombie's Permanent Control of Aliens via Stunning]]
: Above 3 bugs are fixed by '''Hostile Civilians''' fix.

* Probably many other missing/MIA-type bugs

These probably all arise from the daft decision to save a single byte (or even bit), by not recording separately the current vs default "side" a unit is on. The game only tracks the "current side". Consequently when mind control ends, the game often makes dumb decisions as to what side to "restore" the unit to. We could use an unused byte to track the default "side", but that would require overloading a presumed "unused" field and that could be risky. But actually we can always deduce the "default side" from the unit type: XCom for soldiers and tanks, Neutral for Civilians, Alien for everything else. So what is needed is just an end-of-turn check to restore everything to its correct side, based on its unit type. Actually it's slightly complicated by alternating turns. You need to update all (originally) Alien units at the end of the Alien turn, all originally XCom units at the end of the XCom turn. You might also need a special end-of-game update, to avoid the MIA-type bugs. [[User:Spike|Spike]] 12:22, 26 August 2009 (EDT)

: AlienSWP.py implements turnswapping via mind control, like XCOMUtil. Handling the alternating turns, as you described, is necessary to make mind control work properly (a mind-controlled alien remains with X-COM during the alien turn, and so on).

: I would assume that the original programming team had a coding policy forbidding both bitfields, and emulating them with bitwise shifts. That's really the only way I can explain most of the idiosyncrasies of the file format. [[User:Zaimoni|Zaimoni]] 12:07, 26 August 2009 (CDT)

=== Soldier Colouration ===

Not the most "practical" request in terms of changes to gameplay, but still something I feel would be pretty cool if incorporated. Basically, the option to have the battlescape engine display soldiers according to their race/hair colour, as according to their inventory screens, [http://www.strategycore.co.uk/forums/post-a1669-.html like this].

The stored tactical [[PALETTES.DAT|palette]] is made up of 16 groups of 16 colours (256 total), in this order (though the last 16 colours are replaced with a grey-scale shade list at run-time, similar to the other fifteen groups - refer to the page on palette data for more info on that):

[[image:5_BattleScapePal.Png|center|frame]]

Solders are drawn using colours from three of these groups: One for their clothing (x50-x5F for overalls/power armor, xE0-xEF for personal armor), one for their skin (x60-x6F), and one for their hair (x90-x9F). Flying suits use a few extra colours, but they don't matter for the sake of this explanation (they don't show hair/skin anyways).

With my [http://www.strategycore.co.uk/files/index.php?dlid=686 battlescape editor] I incorporated a feature where you could have the program redraw units on the fly (as per the screen shot), changing just the hair/skin colour. For example, to check to see if a colour index was supposed to represent hair, it simply checks if "(''value'' & xF0) == x90", and if so, it'd add or subtract a certain figure to achieve the desired colour.

Well, there's a bit more to it then that (males in personal armor have a different hair colour already), but I'm sure the basic concept is obvious to you by this point. If you're interested, you can see a sample function in a file included in my toolkit - "bb_tact\UnitDrawer.java", line 384. It's not exactly well documented, but if you check the hair/skin arrays it refers to, it should be fairly obvious what it does. While the program is running, the "characteristics" variable is set to "true" by tapping C on your keyboard. Of course, I've no idea how the actual game deals with drawing soldiers, but I assume it decompresses every [[Image_Formats#PCK|PCK]] image every time it wants to draw it, same as my code does.

- [[User:Bomb Bloke|Bomb Bloke]] 09:46, 4 May 2010 (EDT)

=== See Also ===

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

== Completed Items - Thanks Seb! ==

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

* More video options. In particular, an option to put padding at the top and the bottom of the screen to preserve the aspect ratio on a 4:3 monitor. Maybe it's just me, but stretching the original height of the game to fit a 4:3 screen makes the Battlescape look weird. (Actually, if you update the source code link, I could try to do it myself. The current source doesn't seem to include your more recent changes. --[[User:Mikawo|Mikawo]] 20:30, 12 August 2009 (EDT))
** Thanks for uploading the new source code. I managed to add the letterboxing that I wanted. If you wanted to make it an official feature I could upload the updated files. And I don't think I said this before, but thanks for the great loader! --[[User:Mikawo|Mikawo]] 18:40, 14 August 2009 (EDT)
:Go ahead and upload/PM me the file (d3d.cpp I presume?), I'll gladly incorporate your modification. [[User:Seb76|Seb76]] 19:14, 14 August 2009 (EDT)

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

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

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

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

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

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

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."
:The above works perfectly. [[User:KingMob4313|KingMob4313]] 00:05, 13 August 2009 (EDT)

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.
:Fixed via Keyboard Shortcuts - and configurable too.
-- Sorry, I am having trouble finding this addition. Is it in the newest version? I can't see where to configure it if so.

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....
Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)
:I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that 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?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human 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?

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).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
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!
:I think this is a known issue with LOS, not sure though
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).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

There are major issues with your current weight calculations. I'm not exactly sure how it was occurring, but repeatedly messing around unloading and loading weapons, switching clips from the ground them putting them back in... at least one of these functions causes 'phantom weight' to be added to the soldier (e.g. strip them bare and they are still carrying a load). This was happening by 3 units of weight at a time; the weight of a clip. It's so bad that I managed to get 18 phantom weight units on a soldier before getting bored. Occasionally, 3 units of phantom weight would be removed again! It's hard to tell if this was in the original game, due to the lack of weight display in the inventory screen.

Edit: I've worked out what's happening. Add a loaded weapon to a soldier, unload it, and remove the ammo and gun: this ''removes'' 3 phantom weight units. But, add an unloaded weapon to a solider and load it... this ''adds'' 3 phantom weight units. [[User:Stubbs|Stubbs]]
:This is a genuine bug because they forgot to unassign the clip of a weapon when you drop it. Also the default weapon's clip is not initially assigned to the wearer so if you unload and reload the clip, your soldier weights more. [[User:Seb76|Seb76]] 13:27, 3 February 2010 (EST)
:: So is this impossible for you to override and fix? It's really irritating... I've edited lots of item weights, but I guess I'd have to make ammo light and guns heavy to minimize the effects of this bug. [[User:Stubbs|Stubbs]]
:::I second that, it would be great if this could be fixed. [[User:Rovlad|Rovlad]] 17:45, 13 May 2010 (EDT)

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

:: Alien reaction fire works fine for me within Alien Pets. -- [[User:Zaimoni|Zaimoni]] 12:41, August 12 2009 (CDT)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)
:Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)

The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. <3
:Uploaded a new version, you need to add a "HQ4x=1" line under the "Mod" section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)

Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)

Now the question is, how do you use DXWnd with the loader?
[[User:KingMob4313|KingMob4313]] 11:02, 12 August 2009 (EDT)

==Works but won't multitask==

Target system: prefab HP Vista with global data execution prevention. Problem is the same native, with D3D, and/or with HQ4X. (The two do combine nicely, visually, but a bit laggy for my tastes).

ALT-TAB terminates all further screen display on restore; the sea of blackness continues until Task Manager is used to kill the application, at which point D3D admits that it has "lost the device". (This is after the improved error reporting patch. Before, 0xc0000005 as Data Execution Prevention takes over.)

-- [[User:Zaimoni|Zaimoni]] 12:27, 12 August 2009 (CDT)

: Solved on Win7 for the most recent version: Program Properties dialog has an "unblock" button. Unblocking allows the program to survive being alt-tabbed away from. -- [[User:Zaimoni|Zaimoni]] 22:03, 24 June 2010 (CDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)
:That's great ;-) By dev I was refering to the "dev" version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)

Hi Seb, I've been playing the UFO series since the beginning but just joined this wiki. I've tried just about every mod there is for these games, and I must say, yours is one of the best as far as creating a "more complete" and stimulating game experience. My question is in regards to your "Heavy Laser" mod. I liked what you did by creating new "abilities" for the weapon with the Full auto and Burst fire mode, but every time I play I can't help but think that it just doesn't belong to the Heavy Laser as a weapon. I always envisioned the Heavy Laser as more of a long range "Sniper" support weapon, and I like the mod that the X-ComUtil added that gave the Heavy Laser a new life by increasing the accuracy and damage of the weapon making it one of the best Sniper weapons available (even if it is heavy to lug around) as well as finaly giving my troops a greatly needed new weapon for disposing of those pesky sectopods (on any difficulty). I do, however, think that the new fire modes (full auto and burst fire) would be a perfect addition to the Auto-Cannon. The in game image alone has always brought to mind a "mini-gun" type weapon that should be capable of very rapid fire, but at the expense of accuracy due to the encumbering nature of the beastly AC. I never liked how the AC seemed like a generic Heavy Cannon with less damage and only the added auto shot function. Also, I always wondered why that weapon even had an "Aim" function. Who's going to sit there trying to carefully aim a Gatling Gun? Nobody... that's who, you use a weapon like that for mass devistation and shock value, PERIOD! This is why I think that your mod to the Heavy Laser should be reconsidered for the Auto-Cannon. I think, at the very least, it will give people a reason to use the AC in the mid to late portion of the game, and being that it still has weak stats compaired to other weapons, it's not going to be overpowered or infringe on the use of specialty weapons (I think the Heavy Laser with full auto and burst fire is a little un-balanced due to its considerably higher power). If you don't agree that's fine, but since I'm not very knowledgeable about game programing, I was wondering if you could at least give me a hint on how to create similar weapon functions for other weapons, cause I'd like to at least try it out for myself. Thanks for any help you can give me and keep up the good work, you're mod is awesome.

== REng UFO with IDA ==

Hi Seb =)

I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.

So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).

Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.

I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.

My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).

Any advice is deeply appreciated mate =)

XCom forever!
--[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)
:Hi k9,
:Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.
:For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...
:Good luck with your project,
:[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)

:::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...

void InsertCall(int dst, void *func)
{
DWORD oldProtect;
DWORD *pOffset=(DWORD *)(((char *)dst)+1);

VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&oldProtect);
*(char *)dst=(char)0xE8;
*pOffset=(int)func-(int)dst-5;
VirtualProtect((void *)dst,5,oldProtect,&oldProtect);
}

::: This calculation here is interesting:

*pOffset=(int)func-(int)dst-5;

:::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).
:The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).
:The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)

:::Can you suggest some good reading material to better understand this? Cheers!
:::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)
:You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the "UFO Defense" process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)

== D3D ==

If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has.

I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)
:You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)

Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)

OK I ran the dxdiag utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)
:Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.
:Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)
Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)

D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J'ordos]] 19:09, 8 August 2009 (EDT)
:edit: forgot to mention, I have directx 9.0c installed and dxdiag reports no problems. I have a Geforce2 MX *blushes*
:Do you know if this card supports non power of two textures? [[User:Seb76|Seb76]] 05:10, 9 August 2009 (EDT)
::no idea, but since your new version works fine with the D3D option on I assume it doesn't :) [[User:J'ordos|J'ordos]] 11:38, 9 August 2009 (EDT)
:That's great. Spike, does it fix your problems too? [[User:Seb76|Seb76]] 16:04, 9 August 2009 (EDT)
::Sorry for the late reply - yes that fixes my problems too, D3D is working fine now. Thanks, [[User:Spike|Spike]] 15:55, 26 August 2009 (EDT)

== Save equipment ==

Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:

*1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of "invisible" equipment!
*Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips.
*The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.
*Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment.

Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked?

Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)
:Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.
:The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?
:As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.
:I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)
::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a "before" and "after". [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)
:In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)
::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns & ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)
:OK, I'll have a look at this, thanks for the effort.
:Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the "i/b" one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)
::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)
::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)
::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)
:I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)
:: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)
:Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)
::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)

Hmm more problems with Save Equipment. Ammo of all types seems to disappear. Eg I have 6 pistols and 6 pistol clips on the craft, but the Equip screen just gives me 6 empty pistols. Other weapons are short of ammo too. Is the Save feature perhaps "remembering" empty weapons (or loaded weapons) and somehow eliminating the clips. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)
:This looks like an issue with ''UnloadClips''(). I noticed that the clip object's ''loaded_into'' is set to 0xff, but the ''not_loaded'' remains as 0. The game may see this as the clip still being loaded in an object, so the clip effectively disappears. --[[User:Mikawo|Mikawo]] 11:05, 19 August 2009 (EDT)
::This is possible. The wiki is wrong on these 2 fields BTW: it is in fact just one field (loaded_into signed extended to 16bit). I'll have a look at that. [[User:Seb76|Seb76]] 14:33, 19 August 2009 (EDT)

I think Mikawo is right. UnloadClips() should look something like this:

void UnloadClips()
{
obpos_dat *pObPos=pObpos_dat;

for(unsigned char i=0;i<170;i++)
{
if(pObPos->itemType != 0xff && pObPos->not_loaded == 0 && IsXComItem(i))
{
pObPos->loaded_into=0xff;
<big>'''pObPos->not_loaded=0xff;'''</big>
}
pObPos++;
}
}

Quite a few other functions in '''equipment.cpp''' use this check '''pObPos->not_loaded == 0xff''' so it is important to set this flag just for UFOExtender, regardless of whether the game needs it set (which it probably does). Eg items unloaded by UnloadClips will thereafter fail to be found by GetFreeItem, during execution of LoadSoldierEquipment. That probably explains the problems observed.
[[User:Spike|Spike]] 15:24, 26 August 2009 (EDT)

:I did some rework based on that. Do you have other problems? [[User:Seb76|Seb76]] 16:08, 30 August 2009 (EDT)

::Thanks Seb. This seems to be working mostly ok now. Some remaining smaller issues I have seen:

::* The weight calculation is so accurate, it is more accurate than the unmodified game. So the "weight free ammo" (the first clip loaded into a weapon, before the user takes any action in the Equip screen) is no longer weight free. Not sure if you want to "fix" this or not? It is debatable. Really, you have fixed a bug. But the normal game behaviour has changed. Maybe make the "weight free ammo" optional?
::* There is a weird glitch. If I unload a weapon, put it and the clip on the ground seperately, that works fine. But if I pick up the clip '''directly from the ground''' and load it straight into the weapon, then drop the weapon, the weight of the clip is still shown on the soldier. And actually the same thing happens with a clip that is first moved into the soldier's equipment. So in fact the problem is that a clip loaded into a weapon, doesn't get removed from the soldier weight when the weapon is dropped onto the ground. It happens even if the clip is pre-loaded by your routine.
::* Still outstanding - you can't use the right arrow to move onto a second screen of equipment. So you can't have more than one screenload of equipment on the ground. Or maybe you can, if you start the Equip screen with more than one screenload on the ground - I didn't check that.

::[[User:Spike|Spike]] 13:10, 1 September 2009 (EDT)

== Glitch with Alien Pets and Big Brother? ==

Hi Seb. I was trying to do some initial research on the idea of [[User:Spike#Tank mods|Tank mods]] but it looked like these 2 useful features of your Loader, Alien Pets and Big Brother, have both stopped working. Can you test this, on the latest version? I'm using a very recent version (last 2 weeks) but not the absolute latest as I have internet download problems.

Also, have you seen this new Wiki article: [[Enemy Unknown Extended]]. It is a package including your loader plus a few other odds and ends.

cheers,
[[User:Spike|Spike]] 11:16, 17 August 2009 (EDT)
:My mistake, I commented out that part of code a while ago and only recently noticed that. It was corrected one or two versions ago.
:The article is a good idea, it should allow less techies an easy start. [[User:Seb76|Seb76]] 13:51, 17 August 2009 (EDT)
:: OK cool yes the Hacks are back in place, thanks. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)

== Alien Bleeding ==

Test results:

* 1-unit and 4-unit aliens can be healed by anyone (alien or human) holding a Medkit
* 4-unit aliens can be healed by standing in any of their 4 squares
* 4-unit aliens can only be healed while they are stunned. Pointing to their "control" square does not seem to work.
* 1-unit aliens can be healed either while conscious or while stunned
* Wounds on aliens can be correctly seen with Medkits
* The Medkit display shows a human silhouette regardless of the alien type, of course
* Healing aliens with Medkits, stops them from dying of wounds (not 100% tested but seems to be true)
* Aliens (large and small) seem to lose the correct amount of Health per turn from Wounds
* Aliens with wounds that are not treated, eventually die (not 100% tested but seems to be true)
* A Mind Probe can see if an alien has Wounds.

Anomalies:

* I had a lot more reports of Reapers dying than I would expect. I would not have expected any to die, and I had 3 reports of death by wounds. Even heavily wounded Reapers take a long time to die. In my test I was only shooting them with Pistols. Maybe there is a problem with the reporting? Maybe the death of the same Reaper was reported more than once? More testing needed on this.
:I wonder if Reapers are receiving wounds on all 4 sections when hit by explosives (I don't know which weapon you were using). They really shouldn't, although I'm unsure how you'd get around this. If possible, put a cap on the maximum number of wounds something can ever have (perhaps 6). You could argue their multiple hearts really empty their blood out quickly, but I don't think fatal wounds should ever become more dangerous than burning alive.

:: Well, why not: hit four times by one explosive, check for incurring fatal wounds four times. -- [[User:Zaimoni|Zaimoni]], 13:49 Sept. 6 2009 CDT

* Question: should the death of an alien by wounds be reported, or should it die silently? Did I only see these messages because I was using Alien Pets, and so they were on "my" side?
:Regarding death reports, I enabled the dialog for aliens/civilians (it usually only shows up for xcom operatives) to help in testing. The final version will not show them. [[User:Seb76|Seb76]] 14:10, 3 September 2009 (EDT)

Caveats:
* I used the Alien Pets, Big Brother, and Alien Inventory hacks to do this test. I also hacked a save game to give me Pistols, Medkits, PsiAmps and Mind Probes. [[User:Spike|Spike]] 16:03, 3 September 2009 (EDT)

To Do:
* Test if aliens (small, large and mechanical) suffer from [[Fatal Wounds#Other effects of Fatal Wounds|other effects of wounds]], e.g. penalties to Energy, Accuracy, Time Units
* Do Cyberdisks, which have no legs or arms and probably no head, only ever receive Torso wounds?

=== Mechanical Bleeding ===

* Question: Do Cyberdiscs and Sectopods receive Fatal Wounds? I'm wondering whether an unconscious Cyberdisc is safe to be around. Even if they didn't explode, Fatal Wounds would be stupid for a robot. If XCOM tanks can't end up leaking fuel and sparking dangerously, neither should enemy robots. [[User:Stubbs|Stubbs]]
: I think you can make a case for tanks and robots having "wounds", i.e. damage that gets progressively worse by itself. You can even make a case for them being "stunned" - temporarily non-operational. You can even make a case for it applying to alien robots but not to X-COM tanks, since alien robots all have some degree of organic component (which is why they can be Mind Controlled). But I still think you are right, neither effect should apply to machines, whether alien or human. As for your question, see the tests below:

Cyberdisk Bleeding Test Findings:
* Cyberdisks take Wounds (with Alien Bleeding option enabled)
* Cyberdisk wounds can be healed (though only after unit is stunned)
* Cyberdisks lose health from wounds
* Cyberdisks can die from wounds
* Cyberdisks don't seem to explode when they die from wounds ("has died from wounds" popup)

Cyberdisk Bleeding TestTest Caveats:
* Same caveats as previous tests (above), plus:
* The Cyberdisks were modified from Reapers using xcomutil :rpl
* Some Pistols were changed to Laser Rifles using xcomutil :chg
* (xcomutil was not installed in the game directory however, it was used from another location)
* The stats (Armour 34 all round, Health 120) appeared normal for Superhuman
* However the Cyberdisks seemed to fall too easily to Laser Rifle fire (e.g. 1 hit)
* Also, they seemed not to explode as often. This was because they were often stunned.
* Hard to tell in-game whether a Cyberdisk is dead or stunned. The graphic is the same, you can't use a Mind Probe, nor look on the ground, nor even check by changing sides.
* Actually there is one way to tell: stand over it and use a Medkit. Didn't think of that. [[User:Spike|Spike]] 08:22, 5 September 2009 (EDT)

:Thanks for finding out, Spike. Autopsy text shows you are right about the Sectopod( but not about the Cyberdisc) having biomechanical components, but it's not like there are gallons of blood pumping around the thing to gush out. One thing: did you check both conscious and unconscious death-by-wounds for the Cyberdisc? [[User:Stubbs|Stubbs]]
::No problem Stubbs. I didn't deliberately test this, but I had numerous deaths-by-wounding while unconscious and I think at least a few while conscious. I believe those that died while conscious, exploded. (I think this is the basic rule for Cyberdisks. If they are stunned, they don't explode. This typically happens with stun weapons but can also happen with regular weapons, if you are lucky.) [[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)

* Seb76: maybe robots receiving wounds was an oversight, or maybe you really do want robots to take wounds. In either case, it would be nice to have a separate option for this. My arguments against robot wounds are pretty simple: tanks do not receive them, the bled-out dialogue "X has died from a fatal wound" sounds silly for a robot that was never alive, and finally that a Medkit should not be able to heal a robot.
: It's reasonable that alien mechanisms (Sectopod, Cyberdisk) would not suffer from wounds. Possibly also Zombies should remain immune to wounds? From a note Seb made elsewhere, I think the UNITREF.DAT "can be wounded" flag is the same as the "can be stunned" flag. Wounding is probably prohibited globally for aliens, by an override somewhere in the executable. Seb has probably removed this override, unconditionally. To remove the override more selectively, I suspect Seb would need to put a logic test in the code, to check the alien type. .[[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)
::There was a check for ownership that I simply removed. Next version will have an explicit check for robots/chryssies/zombies not to bleed. [[User:Seb76|Seb76]] 12:29, 6 September 2009 (EDT)

* If you want a sense of "the Sectopod's leg got damaged" or even "the tank's track was broken", perhaps robotic units could be 'wounded' by damaging max TUs.
* If, however, the above won't let weapon usage TU %s recalculate as TUs are lost (i.e. the units lose firing ability as well as walking), then certain values of Energy with the correct Energy usage modifier could emulate loss of speed without losing firing ability. Since Energy is returned at a rate of 1/3 of TUs, these units could have an Energy value of (slightly less than) exactly 1/3rd of their TUs. Their energy usage modifier is then changed to allow this small energy value to usually suffice. Now, when Energy is damaged, the units will be permanently slowed, but their weapons won't be affected. [[User:Stubbs|Stubbs]]

=== Zombie Bleeding ===

Zombies that bleed to death don't seem to turn into Chryssalids. As discussed above, it might be better to disable wounding for Zombies. (Death by wounding for Zombies was already possible, without this fix, if the Zombie was mind controlled, wounded while mind controlled, then released back to Alien control.) [[User:Spike|Spike]] 21:07, 5 September 2009 (EDT)

== Hostile Civilians ==

This fix also seems to prevent:
* [[Exploiting_Mind_Control#Zombie's_Permanent_Control_of_Aliens_via_Stunning|Permanent Control of Aliens via Stunning]] Exploit - as was hoped for.
* [[Exploiting_Mind_Control#Resurrect Zombified Agents|Permanent Control of a Chryssalid/Tentaculat]]

It does not fix:

* Various Mind Control bugs:
** [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]
** [[Known_Bugs#Mind Controlled Aliens Count as MIA if you Abort]]

(Probably because fixing both of these requires special, end-of-mission processing)

Still To Be Fixed:

* [[Exploiting_Mind_Control#Exponential Mind Control|Exponential Mind Control]]

(This requires a check in UNITPOS to ensure that the unit attempting Mind Control is not, itself, already mind controlled.)

[[User:Spike|Spike]] 16:16, 3 September 2009 (EDT)

== Fixed Funky Fire and Zombies ==

Fixed Funky Fire still permanently kills Zombies, when the killing damage comes from (end of turn) fire damage. [[User:Spike|Spike]] 21:02, 5 September 2009 (EDT)

== Research Tree ==

I've found a way of modding the research tree and was wondering if people are interested in an updated version. I've read of stuff like enabling hovertanks from cyberdisc autopsies or flying suits with floater research, but I think there is more that can be done. The limitations from the original game is that having researched a topic cannot unlock more than 4 new topics, and cannot unlock the production of more than 4 new item types. Any ideas? [[User:Seb76|Seb76]] 12:40, 6 September 2009 (EDT)

* Another one I mentioned was: Mind Probe before Psi-Amp, although I'm going to retcon that to "Mind Probe before Psi-Lab" (which then leads to Psi Aimp as per usual). The logic behind this is that the first step of a psi-attack must be scanning for enemy brainwaves to pick them out of the other signals. Before you can teach soldiers to do this, you'd have to have studied the mind probe to see how the non-psychic aliens are managing to find targets. You've got to walk before you can run, after all.
* I'm unsure if the next suggestion is possible, given what you have said. I'd like some kind of necessity to research at least some corpses/aliens - is it possible to require, say, any 6 alien 'live' or 'autopsy' reports finished before Alien Origins unlocks? You might also make it dependent on difficulty (6/7/8/9/10 needed). You could also include alien missions in this count.
* My only other suggestions are: you should have to research Elerium before you can build anything that requires Elerium to build. You should have to research Alien Alloys before you can build anything that uses those (which is true only for some things currently. It doesn't seem to be a prerequisite for building alien weapons). Is it possible for a manufactured item to require two separate research entries to be manufactured?
* Question: is there also a limit of 4 prerequisites for a research item? [[User:Stubbs|Stubbs]]
:There is no limit on prerequisites, it's the code that shows "you can now build/research xxx" that has a 4 entries limitation. [[User:Seb76|Seb76]] 15:05, 6 September 2009 (EDT)

A boring suggestion but how about making sure that for all weapon research, you need to do the pistol before the rifle before the heavy weapon, etc. And similarly with the ammo types. Apart from that, I'll think on it. [[User:Spike|Spike]] 17:42, 6 September 2009 (EDT)

Another boring suggestion: each specific laser weapon should take a little longer to research - force you to use the starting weapons for a little longer. You could also rebalance the Plasma research times so that the rifle took a little longer and the Heavy Plasma took significantly longer. It might then be more viable to research them from weakest to strongest, without forcing your hand as Spike suggested. [[User:Stubbs|Stubbs]]

:Yep that's a good alternative.

You could make the Stun Launcher a little harder by requiring (as well as Alloys and Elerium), perhaps a live Medic to be researched before the Stun Launcher (since it's usually Medics that carry them and presumably understand how to operate them), and an Engineer for a Blaster Launcher. It's not much extra but it helps to make these powerful weapons a little harder to get. If you wanted to make Blaster Launcher quite a lot harder to get you could add something like UFO Navigation (something to do with plotting all those waypoints, alien-stylee), or at least a Mind Probe for similar reason.

But, what are we trying to do here? Make things harder in general? That's one option. Or "rebalance", i.e. make things that are relatively too easy to get, relatively harder to get? Or make things more "logical"? There's lots of ways to play this.

It's a shame there's not a distinction in the game between using, and manufacturing, alien weapons - as is done in XcomUtil. Really, there should be a world of difference between figuring out how to use scavenged alien weapons, and actually being able to manufacture them. But that's not really a research tree topic, '''unless''' - would it be possible to create new topics? Could you separate out the using of an item from the manufacturing of it? (If not, it would be good to have a game variant in which nothing that can be scavenged, is allowed to be manufactured).

UFO Navigation might also be a good prerequisite for Hyperwave Decoder. I'm sort of rambling here, but what are the most powerful technologies, that are kind of easy to get... which ones need to be made harder. (Are there any that need to be made easier?)

Powerful technologies:
* Psionics (Psi Lab == Psi Amp). Adding the Mind Probe, as suggested, would be a good idea. Maybe a psionic Commander capture required for each.
* Blaster Launcher - maybe require an Engineer and a Soldier research, as well as Elerium & Alloys. Mind Probe or UFO Navigation for the "plotting" element? A separate Engineer capture to produce the ammo? What else?
* Stun Launcher - Medic and an Engineer? Maybe a full set of autopsies - but that's too onerous.
* Heavy Plasma - stretching the research time would be good, though this can already be done. Additional pre-reqs - maybe add a live Engineer requirement (maybe for ''each'' Plasma weapon type?). If you keep making these requirements you probably need to add a hint in the UFOPaedia along the lines of "we will need to interrogate alien technical experts to further understand this weapon technology". (OK that's hardly a hint.)
* Laser Cannon (?) - But I'm not sure this Laser Cannon factory thing is a big deal. Arguably building a new intercept base is a better cash cow than building a 50-Engineer Laser Cannon factory.

[[User:Spike|Spike]] 16:34, 8 September 2009 (EDT)

== 64 bit compatibility ==

Any way to make the loader compatible with 64-bit operating systems, like 64-bit XP/Vista/7? [[User:Jwilcox25|Jwilcox25]]

: I'm using it on Windows 7 and it's working fine. Not sure if that's 64 bit though. [[User:Spike|Spike]] 07:26, 9 September 2009 (EDT)

:: If you're not sure, you are probably running the 32-bit version of Windows 7. Starting from XP, Windows comes in both 32-bit and 64-bit flavors. Most 32-bit programs are backwards compatible, but apparently not X-COM from my experience. [[User:Jwilcox25|Jwilcox25]]

: It works fine with Windows 7 64-bit. Didn't have to enable any compatibility options or anything like that. [[User:Rovlad|Rovlad]] 02:29, 23 April 2010 (EDT)

== Music bug ==

When enabled "MIDI freeze" bugfix, after entering first combat the music stops playing completely, for the remaining game session.

Also, when using Extender, for some reason music is playing at really low volume, i have to manually reduce my main sound channel and crank up the volume to hear it. When just starting normal UFO CE volume levels of music and sfx are about equal. I have SB Live & WinXP.

== Fire Speed bug ==

Sometimes, for no apparent reason, fire speed setting jumps to 3, instead of what you had it set on.

: I believe it's a bug in the game itself, not the loader. I remember encountering it in both DOS and CE versions. [[User:Rovlad|Rovlad]] 02:31, 23 April 2010 (EDT)

== Reserve TU for x-Shot ==

Not sure if this has been addressed or fixed, but if you reserve Time Units for any shot type, all you get is Snap Shots for the reaction phase - never aimed or auto. Is there any way you could enable these two unused types for reaction shots? --[[User:Zombie|Zombie]] 22:51, 25 October 2009 (EDT)
:As far as I can tell, the reserve is only meant to be used during the active turn. Reaction shots are hardcoded to snapshots (that's true for the aliens too), it's no bug that your guys don't use reaction autoshots. [[User:Seb76|Seb76]] 12:10, 16 January 2010 (EST)

== TFTD ==

I know you're hoping to perfect the current version before taking on any new projects, but I just want to add my plea to the others requesting a TFTD version. Even some of the basic functionality would be awesome and probably completely portable, such as the stats on the equipments screen, default new base, etc.

== Can't change tasks in D3D ==

Hey, I'm having an issue with D3D. If I alt-tab out, I can't switch back to the X-Com task. I'll switch to it but nothing can happen. I'm on Windows 7 x64 with an ATI Radeon HD 5770. [[User:Rlbond86|Rlbond86]] 20:19, 15 January 2010 (EST)
:I too have hangups sometimes when alt-tabbing out of XCom, sadly I'm no D3D expert :( I'll add more checks to see if resetting the D3D device worked though. If anyone knows of a 100% working way of dealing with "device lost" conditions, now is your chance... [[User:Seb76|Seb76]] 12:06, 16 January 2010 (EST)

== Battlescape Soldier's Stats Crash ==

I'm having this little problem with this and I wanted to know if I'm the only one that's suffering with it: everything works fine, but when in battlescape mode I want to check the stats of a soldier (by clicking his rank icon) the entire game CTD. Does it happen to anyone else? How can I fix it?
:Never saw such problem...
:* Does it still crash when you disable the extender (and what options did you enable)?
:* Do you have the address where the crash happens?
:[[User:Seb76|Seb76]] 15:55, 22 January 2010 (EST)
::It didn't, but now I reinstalled the game and it works wonderful. This is a great job you did here. Is there any chance that you could access to the stats of the soldiers from the assign crew screen? --[[User:Slibluhr|Slibluhr]] 16:56, 22 January 2010 (EST)
::OK, I could reproduce the crash this time, it has nothing to do with the stats screen as I supposed to do. The game crashes RANDOMLY if I have turned on the D3D thingy, any clue? I've also noted that if I turn on the caps mod (to put most of 'em in 150-200 to overcome the distance penalty) the soldiers do NOT improve, even after kicking a large scout's butt with KAtherine Sharpe, she didn't get any FAc point! --[[User:Slibluhr|Slibluhr]] 05:30, 23 January 2010 (EST)
:The caps bug is a known one, and a fix is available. I thought I'd wait for more substancial stuff before releasing a new version though. You can try the latest dev version that has the fix included.
:As for your crash I cannot do much without a crash address... [[User:Seb76|Seb76]] 11:46, 24 January 2010 (EST)
::This is what it said during last crash:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00011689

::--[[User:Slibluhr|Slibluhr]] 15:29, 24 January 2010 (EST)
:Sadly the address is of no use (crash inside Windows code, most likely because of wrong arguments). I've put a new version up with better D3D error handling, does it help with your crashes? Also since I was feeling like it, I updated the "Reorder Soldiers" feature so that when you click the name of the soldier, his stats show up. You must click the rank/name of the ship to assign the soldier. [[User:Seb76|Seb76]] 18:00, 24 January 2010 (EST)
::Thank for the access to the stats of the soldiers via crew screen, it releases them from having their FAcc and PStr in the name.

:: btw, the crash moved to this location now:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00028c0b

::could it be that's my pc's fault? does this happen to anyone else?

::------------------
::System Information
::------------------
::Time of this report: 1/25/2010, 01:25:00
:: Machine name: 0X000001
:: Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.090804-1435)
:: Language: Spanish (Regional Setting: Spanish)
::System Manufacturer: FOXCONN
:: System Model: A6VMX
:: BIOS: BIOS Date: 03/13/09 09:59:28 Ver: 08.00.14
:: Processor: AMD Sempron(tm) Processor LE-1250, MMX, 3DNow, ~2.2GHz
:: Memory: 3072MB RAM
:: Page File: 466MB used, 4490MB available
:: Windows Dir: C:\WINDOWS
:: DirectX Version: DirectX 9.0c (4.09.0000.0904)
::DX Setup Parameters: Not found
:: DxDiag Version: 5.03.2600.5512 32bit Unicode

== Store limit question ==
Nice to see you've implemented the general store change (unfortunately, UFOExtender doesn't work under wine, so I can't test this). I'm curious why 187 is the limit? I thought it would be a power of 2 (possibly minus 1)... Possibly you wanted to write 127? [[User:Cesium|Cesium]] 19:43, 21 February 2010 (EST)
:You can build 35 general stores max in a base and 65535/35 ~= 1872 (the internal representation is ten times what's shown ingame). [[User:Seb76|Seb76]] 00:19, 22 February 2010 (EST)

== Mouse scaller not working on Windows 7 x64 ==

with d3d=1 and Scale Mouse=1 I still have issues with the mouse going way off screen.
--[[User:BladeFireLight|BladeFireLight]] 01:57, 22 February 2010 (EST)
:I have noticed that alt-tabbing out of X-COM at the title menu (or any other point that won't crash it) and then alt-tabbing back into it fixes this problem for me in Win7-64. --[[User:Xusilak|Xusilak]] 13:12, 22 February 2010 (EST)
::Thanks for the heads-up. I uploaded a test version here: http://www.ufopaedia.org/index.php?title=Image:UFOExtender-dev.zip
::Does it fix you problems? [[User:Seb76|Seb76]] 14:36, 22 February 2010 (EST)
:::Yep. Seemingly no issues with the mouse going off the screen using it, although I didn't test for long. I'll try to get more test time in later. --[[User:Xusilak|Xusilak]] 20:46, 24 February 2010 (EST)
::::Actually, it doesnt work for me either, in WinXP. And it was broken since the version of 7th November, the one with windowed mode addition. Also, Alt-Tabbing didnt work too. This fix makes things right, though.
::::Edit : also, this dev version crashes in 100% cases when going to battlescape.
::Strange, I do not have any trouble even when using split binaries. Do you have an address for the crash? [[User:Seb76|Seb76]] 14:03, 1 March 2010 (EST)
:::Okay, i hope this is what you wanted, but it says the adress is 0x0000000000bd22ca. I can load an actual save with tactical mode, but cant go into tactical from geoscape. So i use the version from 1st November still.
:Hum, you say the dev version crashes and that you are stuck with the version from 1st november. Do you mean you have the problem since the version of november the 7th, independently from the dev version? [[User:Seb76|Seb76]] 14:08, 4 March 2010 (EST)
::Actually yes. At first i didnt want to use it, because i use a tablet instead of mouse, and its really noticeable when a window failed to scale properly, since a tablet works in absolute screen coordinates. But just now i checked several new (non-dev) versions for the crash - its there. Crashes every time i try to enter tactical mode from geoscape. Saves from tactical load up fine. Version from Nov.1st gives no problems whatsoever.
:Do you still have the problem if you disable D3D or use windowed mode? Also if you load a tactical game, don't you get a crash when it goes back to geoscape? [[User:Seb76|Seb76]] 03:20, 6 March 2010 (EST)
::When disable D3D - yes. When enable windowed - yes. When going from tactical to geoscape - no.
:OK, I suspect this has to do with the "Save Equipment" feature. Can you try disabling it if you have it on? [[User:Seb76|Seb76]]
::OK, um...i tried all my saves, and with that feature disabled all my saves load up fine, and i can go from geoscape to tactical and back. So i thought everything was alright, and kept playing - the very next tactical mission loads up fine, but as soon as i try to move anyone - it crashes. And that is the same in all my saves, first mission is alright - second one always crashes. The crash adress is 42064f, in case you're gonna ask.
:Alright, can you PM me a savegame before the crash? I doubt it'll help but who knows...[[User:Seb76|Seb76]] 12:43, 6 March 2010 (EST)

== Extender in Steam (+ maybe XComUtil) ==

Hi do you know of any way to use the two apps together with the Steam version? I would really like to be able to combine the 'Reorder Soldiers' feature of Extender and the 'Capturing Aliens for Research' of XcomUtil.

Actually now that Ive put a bit more time into it I can't get UFOLoader.exe to run in steam's dosbox implementation at all. I can just run UFOLoader but it doesn't run in dosbox which makes the game run horribly. If you don't have a steam copy for testing / integration of the basic Extender program please let me know and I would be happy to send you a gift copy.

-Dogfish

P.S. What a great program, you are a credit to gaming.
:As far as I know, the Steam version also ships with the windows CE edition, the default shortcut just happens to point to the dosbox one. Also the latest version of XComUtil is able to detect the loader presence and act accordingly. [[User:Seb76|Seb76]] 15:42, 25 February 2010 (EST)

:: STEAM comes with both EXE. XcomUtil and UFO Extender work together with STEAM. To use Setup UFO Extender in the game folder. Then Download and install the latest build of XcomUtil 9.7. It will auto start XcuSetup in windows, Detect UFO Extender and allow you to configure RunXcom to use it. To use UFO Extender, or UFO:CE you can't launch the game from STEAM. You have to create a short cut for RunXcom. (Right click > send to > Desktop as Shortcut) --[[User:BladeFireLight|BladeFireLight]] 19:13, 25 February 2010 (EST)

Thanks guys I was able to start the game with both mods. I apparently had everything configured correctly but I kept launching it from steam. Is there a way to play in windowed mode (since its not using dosbox)? I tried launching dosbox and running 'RunXCom.bat' file from there but it does not recognize UFOExtender.

Oh boy the game is fast, even on slowest scroll it is difficult play a battle :)

-Dogfish
:What options did you turn on? [[User:Seb76|Seb76]] 14:18, 26 February 2010 (EST)

Show Stats=1
Apply=1 (wreck analysis)
Proximity Grenades Experience=1
Elerium-fueled Craft Bug=1
Save Reserve Mode=1
Rank In Inventory=1
Manual Interception Fire Mode=1
Crafts Always Ready=1
Reorder Soldiers In Crafts=1
No Funkers=1
TFTD Doors=1

Full System Specs:
Win Vista 64
Intel i7 920
6GB RAM
GTX 285 Video
Asus p6t

Everything is fast the geoscape tics are at least 5 times faster than running the non-Extender mode via dosbox.

Would you have any suggestions how to slow it down? I've actually been playing in steam(dosbox) with XComUtil only and then saving/loading between missions so I can reorder the soldiers.

Aha! I found the D3D Windowed option...
HQ4x=0
D3D=1
D3D Windowed=1
Always On Top=0
Clip Cursor=1
Scale Mouse=1
Screen Ratio=0.833333

I can manually resize it to be bigger, excellent!
What is strange is that running it in windowed mode seems to slow it down enough for the scroll speed settings to make it playable :)

I ran into a "Unsupported 32/16/64 bit error message switching from geoscape to battlescape but it happens only 1/3 times maybe?"

I will be playing this and let you know if I run into any more problems.

Thanks a bunch!
-Dogfish

Hi guys, dogfish again I've been getting a couple of glitches.

1. Switching from battlescape back to geoscape in the cmd prompt it displays
'echo----------------------------Leaving' is not recognized as an internal or external command, operable program or batch file.

2. This has happened twice

Get someone who has been shot is at low health and has fatal wounds

Have them pass out due to smoke inhalation

Let them bleed to death and get the "Joe McSoldier has died from a fatal wound" *while unconsious from the smoke*

I will lose points for the mission but the soldier will be recovered at the end of the mission but terribly wounded. (Currently Hans 'Jesus' Vogel is taking 55 days to recover his 41 health.)

:Both of these are XcomUtil issues. 1 has been fixed in Build 413 but I need a saved from just before ending combat to fix 2. --[[User:BladeFireLight|BladeFireLight]] 18:19, 28 February 2010 (EST)

::Sent the savegame to your gmail (whatever was listed on my paypal reciept from your donate button). Just hit end turn (all the aliens are dead) and the bug is triggered. -Dogfish
::: I got it. Was up all night with Bomb Bloke and we worked out what was going on. The fixed works with your save. The next build will fix the zombie bug. Also Thanks for the donation. Every little bit helps. --[[User:BladeFireLight|BladeFireLight]] 16:02, 1 March 2010 (EST)

--
Hi! I'm thefarside. This is my first time ever editing a wiki page so please bear with me. I'm not even sure I'm allowed to do this.

However, I have a problem with the cursor. It moves WAY out of the screen to the right and downwards. I've read something about a "clip cursor" fix but I can't seem to find out where and how to implement it.

Regards,
thefarside
--

== Manually Select Promotions ==

Just an Idea, not sure how easily done it is but I was thinking it would be really cool if (when its time for promotions) it would bring up a soldier screen with the eligible soldiers so that you could pick who gets promoted. Bonus if you could click on the candidates and be taken to their stats screen.

Love,
Dogfish

== Xusilak's Patch Additions ==

Since my patches are being integrated into the main release now, everyone should let me know if any issues are found with them. I'll try to get on fixing them as quickly as possible.

For clarity, the patches in the current build that I developed are:

* AutoSell
* Show Money

Thanks! --[[User:Xusilak|Xusilak]] 14:51, 24 March 2010 (EDT)

I went ahead and set up my own user page: [[User:Xusilak]]. If possible, direct discussion about my patches to my [[User_talk:Xusilak|discussion page]] there. Thanks again! --[[User:Xusilak|Xusilak]] 15:44, 24 March 2010 (EDT)

----

Hi Seb,
I've been working with IDA, your database, and your patcher's code for some time now, learning my way around it, and so on. So far, I've managed to come up with three UI improvement patches, although they still need some polish and testing.

The first one is a battlescape movement confirmation patch; it requires the user to click twice (double-click with no time limit) on the same tile to move, instead of once, to eliminate movement errors. In practice, I have found this very helpful.

The second one shrinks the geoscape clock and adds your current funds above it, letting you see your financial situation at a glance while waiting for time to pass.

The third one enables auto-selling of manufacturing items. Pressing the down arrow when the production quantity is at 0 engages this mode. When in this mode, production of that item never ceases (unless resources become unavailable), and the item is immediately sold upon completion.

Would you like me to make the code for these available once I've finished polishing them up? They currently consist of a few C functions accompanied by some InsertCall()s and Nop()s, as well as some additions to XCOM.h. I haven't added INI options to enable them, so I'd leave that up to you. You may use them as you wish, with no conditions.

Note: I'm still learning x86 assembly, so the patches may not be bug-free. I'm hoping to give them a good testing myself, though.
--[[User:Xusilak|Xusilak]] 16:10, 19 March 2010 (EDT)
:Glad to see you could make something out of this database :-) Do not hesitate to send me your modifications, I'll incorporate them in the codebase so others can enjoy them. I'm sure your autosell feature will make a few happy ones ;-) [[User:Seb76|Seb76]] 19:12, 19 March 2010 (EDT)
:::Yeah those features would all be '''great!''' Thanks Xusilak. [[User:Spike|Spike]] 15:08, 22 March 2010 (EDT)
::OK. I'm going to finish up my last touches on them, then test them for a while; they should be ready within a couple days. --[[User:Xusilak|Xusilak]] 21:59, 19 March 2010 (EDT)

== v1.21, Battlescape crashes ==

I enabled the new mods and they worked ok in Geoscape. Then this Popup box starting the first Battlescape:

Application failure
XCOM crashed at 0x10002571 with error 0xC0000005 trying to access 0x0968DF43

[[Media:UFOExtender1.21.BSCrash.zip]] contains the UFOExtender.ini file.
This was a New Game but not a new install of XCOM, just an overlay of updated UFOExtender.

*Win XP Pro 2002 SP2 32bit PAE
*Pentium-4 3.00GHz 3.5GB RAM

Any ideas? Need more info? [[User:Spike|Spike]] 20:20, 24 March 2010 (EDT)
:Does it happen consistently? I've been plagued by a random geoscape->battlescape transition crash in the collector's edition. It's one of the things I'm looking to fix at some point. The current UFOExtender doesn't appear to crash any more than previous ones do for me. I managed to do four missions in a row just now. --[[User:Xusilak|Xusilak]] 21:00, 24 March 2010 (EDT)

I'm doing some research into this; I started up in debugging mode and spammed missions until I hit a crash. The crash (on this occasion) is an access violation caused by an invalid pointer stored at 0x49B954 (the offset that pSoldierDat points to). This means *pSoldierDat is being changed at some point. It took many, many tries to get this crash to happen; I reloaded something like 20 times hitting the same mission, went ahead and did the mission quickly, proceeded, did another mission, proceeded, then the next mission crashed. Given that I'm in debug mode, it's not impossible this is due to the various hacks enabled by it, so that should be kept in mind. I'm going to continue working on this. --[[User:Xusilak|Xusilak]] 22:26, 24 March 2010 (EDT)
:It appears the "invalid" pointer is actually set by malloc() - 0x0771D380 (for me). I can only assume something along the way disrupted the data on the heap, as the pointer was the same when examined on a battlescape transition that didn't crash. Still researching. Note that for me, the crash itself happened inside GetSolderUUID() in the Save Equipment patch functions when it attempted to use that *pSoldierDat pointer. However, I assume it would still happen if the Save Equipment patch were disabled, just elsewhere. This is something I'll test as well. --[[User:Xusilak|Xusilak]] 23:41, 24 March 2010 (EDT)

::Sorry I'm guilty of reporting a bug I didn't (couldn't) repeat. But as I had no previous save game positions I couldn't repeat anything - the crash happened on the first Battlescape mission which for me is unusual, I would say that for me that transition crashes less than 1 in 100 times, if even that many. I had enabled Save Equipment I think and on instinct I would suspect that mod as being responsible. Those UFOExtender functions would run while setting up the Battlescape presumably. The equipment handling functions and structures ''already'' present in the game are known to be buggy. BladeFireLight and I just found another issue with them last week. Manipulating them is still risky. If you can investigate that would be very helpful.

::In the meantime I will see if I can try to repeat the fault, with and without Save Equipment enabled, and starting from a clean XCOM install. One trick I may use is to set No Score Game Over and then just abort from each mission rather than fighting it, to speed up the testing.

::Thanks for your good work Xusilak, it is appreciated! [[User:Spike|Spike]] 03:25, 25 March 2010 (EDT)

One possibility: On this mission I had only 6 soldiers (2 HWPs) but enough weapons in the Skyranger to equip 14 soldiers. Is there some known issue with needing to allocate '''all''' weapons to soldiers during the equip phase, in order to avoid a crash? If so that might be the cause. I will try to recreate those conditions and see if it provokes a crash. In case it's not clear, Battlescape never appeared to start, no Equip Phase screen ever came up. [[User:Spike|Spike]] 03:31, 25 March 2010 (EDT)
:Assuming the same crash is afflicting us, then the crash is when the very first soldier is accessed, when the Soldier.Dat data is first used for that mission. It's unlikely that volume of equipment is affecting that, and in particular, I hadn't changed my Skyranger's loadout to any degree whatsoever, having only briefly touched researching and manufacturing; it was otherwise a gamestate set entirely by doing one quick regular mission and one quick terror mission. However, I was also in debug mode, which enables certain cheats, like Alien Pets, automatically. This might, itself, have unseen bugs that could corrupt the data structures and cause a similar crash. When I get the time to, I'll be testing again with those cheats disabled, trying to further isolate the conditions involved. --[[User:Xusilak|Xusilak]] 08:34, 25 March 2010 (EDT)

I've repeated this multiple times now, with a clean install of XCOM and a clean install of UFOExtender 1.21. The game crashes everytime, after the "mission screen" that comes up just before the Equip Phase of Battlescape for the first mission. It's regardless of my equipment loadout or number of soldiers/tanks: it happens with totally default equipment and Skyranger load. So I imagine it must be due to some combination of the UFOExtender.ini file options I selected, and maybe code changes in 1.21. My .ini file is the upload at the top of this section. The error is always "error 0xC0000005 trying to access 0x0968DF43", though the crash location (in the code) varies. [[User:Spike|Spike]] 20:31, 25 March 2010 (EDT)
:If you have time, could you try to 1) confirm it's specific to 1.21 2) try to correlate it to ini options? Turn everything but the basics off and see what happens... if that works, turn on Save Equipment and try again, etc. I haven't seen any behavior like that in my local tests, on either of my computers (Win7-64 and XP-32). I'll try it with your ini, though. Maybe I can find something. --[[User:Xusilak|Xusilak]] 20:39, 25 March 2010 (EDT)
::Just tested with your ini, although with D3D and D3D window enabled. Started a mission, didn't crash. I also noticed one thing: you have General Stores capacity set to 1. I don't think that's helping anything, but it's probably not causing the crash, either. Experimenting more. --[[User:Xusilak|Xusilak]] 20:48, 25 March 2010 (EDT)

::: Save Equipment=1 is part (at least) of the problem. If I turn that off, and leave all my other .ini settings as is, I no longer get the Battlescape crash. Seb, did you make some changes there? Maybe after the investigations we were doing with BladeFireLight? [[User:Spike|Spike]] 21:13, 25 March 2010 (EDT)

I have isolated the problem (on my end) to the fact that the SOLDIER.DAT data in memory is deallocated when the transition to the Battlescape starts. When Seb's Save Equipment code attempts to use it, it's getting random unallocated (or unrelated) memory instead of the SOLDIER.DAT data. Interestingly, the dynamic memory used to hold the SOLDIER.DAT data is deallocated on the transition to the Battlescape, and reallocated to a new memory address on the transition out of the Battlescape. I assume this is an artifact of the way the Collector's Edition merged TACTICAL.EXE with GEOSCAPE.EXE, because TACTICAL.EXE had no need of SOLDIER.DAT, and only used UNITREF.DAT and similar. At any rate, this problem can be resolved by not relying on **(0x49B954) (or **pSoldierDat) to contain the correct data. Instead, a workaround to get the needed data should be used. One option would be to patch the way the transition works to prevent the deallocation from happening, and then ensuring on exiting the Battlescape that the old memory block is still used. I may be able to work in that fix myself. If so, it would require no changes to the Save Equipment code.
I'm not sure if this is a general issue or local to me only. I'll try to test on my XP system and see if it suffers from the same problem; if it does, it's a safe bet this is a general issue, and the likely cause of your crashes. --[[User:Xusilak|Xusilak]] 00:06, 26 March 2010 (EDT)

Save Equipment did used to work for me before. Maybe it's because I also selected Reorder Soldiers In Craft. Does that sort and rewrite SOLDIER.DAT? [[User:Spike|Spike]] 03:39, 26 March 2010 (EDT)

I have confirmed this behavior in the original X-COM Collector's Edition UFO Defense.exe copy, running on my XP system. As such, it ''cannot'' be a result of any patches Seb has made (because it still happens even when not using Seb's loader). I'm not sure if it will crash without Seb's patches still, but the way Seb uses the *pSoldierDat pointer in GetSoldierUUID() appears to be unsafe, as *pSoldierDat has already been deallocated at that point. On some systems, it may work, because the nature of memory on the heap is such that different systems give different results when dealing with deallocated memory and bad pointers. Regardless, the crashes can be at least partially (maybe entirely) resolved by using a workaround that avoids the deallocation of *pSoldierDat when the battlescape transition starts. I'm going to see if I can implement the fix I suggested, that prevents the memory from ever being deallocated. That should completely resolve it. At the least, I am going to study the assembly responsible for deallocating it to see if I can confirm the exact issue on the code level. --[[User:Xusilak|Xusilak]] 13:26, 26 March 2010 (EDT)
:It seems that when GotoGeographMode() returns to move into GotoTacticalMode(), it calls FreeEverything() in the process, deallocating all data structures. Then, GotoTacticalMode() never bothers to reinitialize *pSoldierDat, so when the equipment phase comes up, it's still unallocated. Still working on a fix. --[[User:Xusilak|Xusilak]] 14:29, 26 March 2010 (EDT)

::Surely at some point the (unmodified) game needs to at least read the *pSoldierDat structure, in order to populate the [[UNITREF.DAT]] and [[UNITPOS.DAT]] structures for Battlescape? Unless it reads SOLDIER.DAT but doesn't bother storing it, not even temporarily, in *pSoldierDat.[[User:Spike|Spike]] 15:27, 26 March 2010 (EDT)
:::Nice piece of analyse there :-). I'll modify the patch to load the soldier data when needed and clean up afterward. [[User:Seb76|Seb76]] 15:30, 26 March 2010 (EDT)
:::Edit: I uploaded a test version. Can you check if it fixes your crash? [[User:Seb76|Seb76]] 15:47, 26 March 2010 (EDT)
::::Looking good so far; Save Equipment works for me now, and it never has in the past. I'll run through a bunch of missions quickly and see if I get any crashes. Thanks Seb! --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:::No, thank you for figuring out the cause of the crash. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
:::::Just ran through several dozen (very quick, mostly aborted) missions all the way up to June. I never crashed, and Save Equipment always worked correctly. I think we're good to go. Hopefully it works for Spike as well. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)

I've also been narrowing in on another crash, unrelated to the patcher, I believe. It happens rarely upon clicking the air to move somewhere, like stepping out of the Skyranger by clicking the air one tile in front of the soldier, to move onto the ramp. It appears to be the result of a bad calculation on the tile to check in MoveUnitTo(). The calculation is looking at (char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize); // when esi is 2 or greater; this esi factor shouldn't be there, as far as I can tell, because it results in the offset used being much greater than it should be and frequently going out of bounds of the MAP.DAT data stored at *pMap. Continuing my research into this when I get a chance. --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:I noticed that crash also (I think it's the number one crash cause on a genuine XCOM setup) but was never able to reproduce enough to investigate it. I was tempted at one point to patch the GetTileAt function to check its arguments, but finding the cause of the corrupted value would be better. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
::Yes, it's definitely a hard crash to catch, because of how rare it is. I've got a few ideas, though. We'll see if they help. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)
:::Currently, my guess is that this line:
:::<pre>.text:00420534 BE 01 00 00 00 mov esi, 1</pre>
:::should be "mov esi, 0" instead.
:::To sum up the issue:
:::The way the 'click on air to move to a tile below unit' part of MoveUnitTo() works is that it examines each level below the unit until it finds a floor to move to. It does this by looping through the level below you, incrementing esi to loop through the next level below that, and so on. To do this correctly, esi should start at 1. However, the X-COM programmers appear to have made an oversight: they initialized esi to 1, but then incremented esi again before the initial value actually gets used. The net result of this, is that we get zpos += 2 for the very first cycle. This works OK on floors 3 and 4, but for floor 2, it will attempt to access a z level that doesn't exist (one below the ground), causing this line: <pre>(char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize);</pre> to exceed the bounds of the *pMap memory block. Obviously, running off the end of that block will cause unpredictable results, and if it reaches into a block that isn't allocated, it will crash. That's why the actual crash is very rare: it has to overrun into an unallocated memory block.
:::Of course, I could be completely wrong, but it makes sense, and patching 'mov esi, 1' to 'mov esi, 0' doesn't seem to cause any problems. I'm going to be testing with that patch enabled from now on, to see if I crash in that circumstance anymore.
::Looks like you are right. I instrumented the code and there are indeed systematic out of bound accesses when getting out of the craft, though the game does not crash every time. I suspect this is the same crash that happens during base defence when an alien tries to move down from the access lift. Kudos for figuring all this out! I'll provide the fix in the next version. [[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)
:::By the way, Seb, the 1.21 source code doesn't include autosell.cpp; I assume it's a simple oversight. I reconstructed it to get it compiling properly. Just wanted to make sure you knew. --[[User:Xusilak|Xusilak]] 20:37, 26 March 2010 (EDT)
::Oops, forgot to check the unversioned files before checking in...[[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)

== Minor cosmetic enhancements? ==

Had these ideas come to mind while I was at work today, and since your loader is doing some amazing things for the game, I thought I'd ask if the possibility of any of these enhancements exist.

The short of it is: Are you able to overlay any additional bitmap surface on top of the battlescape view, and are you able to play additional sounds?

The main idea for drawing an extra bitmap (semi-transparent) over them map would be to simulate rain/snow for some outdoor maps. Lightning even - though that would require clever use darkening and lightening the overlay. This would have some issues attached to it such as knowing when to display it and when not to, thanks to the various other screens available.

As for playing sounds, which would be simpler, would be to play a looping sound clip to provide environmental sound effects, such as insects chirping and owls hooting at night in woodland maps or town noises at terror sites. Or during the day in a jungle map, some tropical bird calls made at random intervals. TFTD already does the looping environmental sounds, such as teh under water bubbly noises or the wind and sea noises when on land mission. Would it be possible to duplicate this for UFO CE?

Not the most important of enhancements, but I was still wondering if the possibility is there.

-[[User:NKF|NKF]] 01:41, 25 March 2010 (EDT)

== Save/Load shortcuts ==

Seb, would it be possible to enable shortcuts for the Save/Load in geospace & tactical (like F2 or F3) ? ;) except for saving in the final battle (from level 4 if remember) :)

Other things:
- rosvell incidents occured for me too often - 5 in the first month while there was no other alien craft movement detections

- option to disable mission briefing window with the only ok button :) supposedly for advanced users ;)

== Aliens continue using pistols&rifles ==

Hi Seb, sorry to bother you - i have been playing X-COM titles on and off for about 10-15 years now, and one thing always bothered me: Why do the aliens always swith to heavy plasma (or the Sonic cannon in case of TFTD) later on? It encourages the player to swith to heavy plasma too, if only for the free ammunition you almost drown in later on. Would it be possible to have the aliens continue using the plasma pistol&rifle after june/july? It would make using those weapons more feasible, getting ammunition during missions and not having to use elerium to produce it.

Another request (don't know if it is possible) - let the aliens continue using the abductor and the harvester for the respective missions. Later on, all you get are large scouts or even battleships doing those missions - getting some variety in there would make the endgame more interesting. You get to do 50+ battleship missions in a game, but only 4 or 5 with a harester/abductor. Those ships should see a lot more use during the missions they are "designed" for. The "[[MISSIONS.DAT]]" page says something about ufo and mission counters and their associated ufo-types - would it possible to modify those entries via the loader?

Regards, Equinox

== ALIEN MISSION DATA CLARIFICATION ==

According to
[http://ufopaedia.org/index.php?title=Talk:MISSIONS.DAT#Alien_missions_data_discovered_in_geoscape.exe_.5Bfinally_.3B-.29.5D link title]

I found it in TFTD. At offset 505448 (decimal) is starting (mission Probe). Next Interdicition/resource raid/infiltration/colony expansion/surface attack/Floating base attack

I understood what is 3-rd word. If You interesting - I can exlain

Seeing speeds of USO sub we can determine the mission of this USO sub even without transmission resolver - even in january 2040
Every USO sub in every missions (interdiction, colony, probe and other) have unique speeds and we can determine mission of USO on their speed
And we can determine what amount of times a sub touch down on his mission - because every mission has unique rule for touch down USO subs
And we can determine what amount of time USO Sub will touch down on their mission - because every Sub in every mission has unique and ALWAYS equal amoun of time to touch down (p.s. this time we can see in file Loc.dat)
Here - I attached file speeds.zip
[http://www.strategycore.co.uk/forums/Ion-Beam-Accelerator-in-What-file-t8099.html&view=findpost&p=95994#entry95994 link title]

3-rd word - it is reference to unique speed of each sub

4-th word - is time that precede to arrive next uso sub. In other word, in line ufo/c 0/0 if time = for example = 200 - it's time to arrive sub that indexes 1/0.
And where can I get time to arrive EXACTLY sub 0/0 is incomprehensible for me. I assume that this time contain at similarly word of last uso for this mission - but its'not truth because at some missions time in the line of last ufo/c = 2 half-hours and it's means that ufo/c 0/0 can to arrive at new month at 2 half-hours. It's true for Surface attack Mission but not truth for other missions.
I assumed that time in line ufo/c 0/0 - that time to arrive for NOT next ufo - and I assumed that it's time to arrive exactly ufo/c 0/0 itself. But many my tests (more than 100) denies my suppositions.
In example, at line ufo/c Cruiser mission Colony Expansion time in file =2. Cruiser in that mission arriving much more than 2 half-hours after Escort. Instead Fleet supply Cruiser in that mission arriving after 2 half-hours exactly after Cruiser.

'''Question - Where can I find time to arriving for ufo/c 0/0 for each missions except Surface attack mission ?'''

I am sorry for disturbance and will great thank for you for help.
:After the first month the game creates a mission per month, up to the 6th where it generates 2. I guess a mission starts immediatly, there is no timing added for its first ship. [[User:Seb76|Seb76]] 15:18, 30 April 2010 (EDT)

Mission starts not immediately. often time to arrive to survey ship (first sub) about 10-15 days.
1-st day of month at 0-00 we can see it time at Missions.dat but wants to know average time similarly such average time for other subs from alien data mission at executable if possible.

What is exactly 6-th? mission from Probe to Colony Expansion? or from January to June?
:Yep, 6th month. [[User:Seb76|Seb76]] 20:04, 30 April 2010 (EDT)

what happens after 6-th month June?

I so sorry for reminder and bother you, but don't you know it? ((

== Formules about Retaliation/Floating base attack mission ==

Hi

My great respect to you for you formules
I need few help. I am great thank to you in advance

Now I found alien data missions in TFTD (in a similar in EU ) and I ask generously to you to check 3 your formules in TFTD. Is these same or not?

1. After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours
:Xusilak is more knowledgeable than I concerning TFTD. I cannot help you here... [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

Formule 2 and 3 probably contins mistake. formule 'll have to have symbol > instead symbol <. Otherwise retaliation mission activates more often on Beginner diificulty than Superhuman difficulty. Is is strange.

2. A retaliation mission will be scheduled if RAND()*100 < 4*(24-difficultyLevel).
:There is indeed a mistake there. It's been so long I cannot remember if I got it wrong or just messed it up wikifying it ^^ [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

3. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from. The first UFO is scheduled in 100 half-hours (the value is taken from the table I speak of later at the bottom of this page).

And RND() - what values may has? from 0 to 1 or not?
:When I write RAND()*100, it just means a random number between 0 and 100. [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

I will be very thank for given help

== MISSIONS.DAT formula clarification ==

Hi Seb76. I've been having a discussion with Alexchamp and trying to interpret the formula you mentioned on [[Talk:MISSIONS.DAT]] about retaliation missions being scheduled after a shoot down. Namely: if RAND()*100 < 4*24-difficultyLevel

We mainly need clarification on the logical operator. Should it be less-than or greater-than?

As it reads now, it could be interpreted as though retaliation missions are generated more frequently on the easier levels. But if we treat it as >, then this means that retaliation missions are generated about (Beginner) 4%, 8%, 12%, 16% and (Superhuman) 20% (or 28% for TFTD) of the time on their respect difficulty levels.

If you could clarify that for us it would be great, thanks. - [[User:NKF|NKF]]
:Yep, I goofed up. Don't take everything I say as gold ;-) [[User:Seb76|Seb76]] 14:45, 30 April 2010 (EDT)

And I precise too one '''mainly moment'''. Whether there must be the opened bracket after the sign of multiplication? Because if no, then right interpretation formule in Superhuman example such: Rand*100>4*24=96-6=90 and that means that retaliation mission would be sheduled in 10 cases from 100.
IF there must be opened bracket then rand*100>4*(24-6)=4*18=72 wouid be sheduled in 28 cases from 100
What is this versions is right?

Then needs clarification for second formula yours. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from.
What logical operator there? should it be too greater-than or less-than?

You have found later formules about activation retaliation mission (if we shotdown alien craft)
Where exactly in assembler is subprogram that determines it? What address/offset of it?

== COLONY SUPPLY MISSION ==

As we know, When alien base built, Fleet Supply Cruisers with missions Colony Supply can to arrive to this base.

Where can I see (file/offset)
1) average time to arrive colony supply ship for examle/at least in XCOM-EU. As I said later, in responsible offset is time '''to PRECEDE to ARRIVE NEXT UFO SUB''' '''it's not''' time to arrive this sub
2) real time to wait arriving colony supply ship similarly times in file Missions.dat

According to [http://www.strategycore.co.uk/forums/Colony-Supply-ship-time-to-arrivin-t8103.html&view=findpost&p=96011#entry96011 Colony Supply - time to arriving]

If guesses of NKF is right, we need to formule of probability to arrive Colony Supply ship.
Can you to render courtesy with this formule?

Thank you very very great in advance
:I added details in the LOC.DAT talk page. The supply ship is spawned randomly and starts its mission. There is no "time to first supply ship" that I can see. [[User:Seb76|Seb76]] 15:11, 30 April 2010 (EDT)

Thank tou very much for this clarification. I found this offset in TFTD even. Changed, checked - it works.
You are greatly people!

== Roswell mission bug? ==
Hello, Seb76.

I've just had two consecutive games (meaning, I restarted the application and began a new game) where the same strange behavior occurred.

Both games had Roosevelt mission as the first one. It showed the window (type, terrain, UFO size) as usual. Afterward, whenever I clicked on it (to check mission conditions again), it showed a typical "hyperwave transmission decoded" window, stating race/mission type, etc. Needless to say, I had no decoder at this time, since it happened both times in the first game week.

I have a saved game if you want to take a look at it. It's completely reproducible, at least for me. You just click on the white cross and get this window.

Also, I'm using plain CE version with a "complete UFO patch" from StrategyCore. The saved game was not hacked in any way.

Cheers!
[[User:Rovlad|Rovlad]] 10:08, 30 April 2010 (EDT)
:Hum, I gave it some shots but could not reproduce your problem. Anyone experiencing the same problem? [[User:Seb76|Seb76]] 15:36, 30 April 2010 (EDT)

::Here's the [http://rovlad.nm.ru/GAME_1.zip savegame]. Let me know if it works fine for you. [[User:Rovlad|Rovlad]] 21:47, 30 April 2010 (EDT)
:Looks like the CRAFT.DAT entry is not cleared when a new craft is created and the offset 0x64 could be garbage till the craft is detected by a base/another ship. Since I bypass the detection when "crashing" a UFO, it is possible the "HWD detected" flag is set randomly, producing a full report. I'll clear the bit and we'll see if it corrects the issue, just wait for the next release. Thanks for providing the savegame BTW. [[User:Seb76|Seb76]] 14:22, 5 May 2010 (EDT)
::You're more than welcome. Fantastic job on the extender, keep up the good work. [[User:Rovlad|Rovlad]] 19:04, 5 May 2010 (EDT)

== ALIEN RACE SPAWN ==

Your post: In EU, the race is based off a lookup table starting at offset 0x46E53C (containing 300 entries).

Offset-0x46E53C is absent. Is one symbol odd?

Your posr:The table is made up of 10 entries lines.

It means that this bit of array has 10 rows width of 30 bytes. is right?

What is means this 10 entries lines? Can you copy 2-3 lines from exe and explain that means known for you offsets in line?As simiilarly as you done for alien data mission in file Missions.dat
Can you get more particularly answer about values it this array?(naturally if know it)
:0x46E53C is the address in memory. In the file it should be 0x6E53C (UFO Gold edition).
:The begining starts like this:
.data:0046E53C byte_46E53C db 0, 0, 0, 0, 0, 0, 0, 1, 4, 4 ; 0
.data:0046E53C ; DATA XREF: CreateAlienMission+15B�r
.data:0046E546 db 0, 0, 0, 0, 0, 1, 1, 4, 4, 4 ; 0
.data:0046E550 db 0, 0, 0, 0, 0, 0, 4, 4, 4, 4 ; 0
.data:0046E55A db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E564 db 0, 0, 0, 1, 1, 4, 4, 4, 4, 4 ; 0
.data:0046E56E RaceForTerrorMission db 0, 0, 0, 4, 4, 4, 4, 4, 4, 4 ; 0
.data:0046E56E ; DATA XREF: GeoPerformMonthlyActions+15E�r
.data:0046E578 db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E582 db 0, 0, 0, 0, 0, 0, 1, 4, 4, 4 ; 0
:till the end:
.data:0046E67C db 0, 1, 1, 2, 2, 2, 3, 3, 2, 4 ; 0
.data:0046E686 db 0, 0, 1, 1, 1, 2, 2, 3, 3, 4 ; 0
.data:0046E690 db 0, 1, 2, 2, 2, 2, 3, 3, 4, 4 ; 0
:As you can see, at the begining you'll get tons of sectoids (0), a few floaters (4) and even less snakemen (1).
:At the end, you'll get ethereals (2) one time out of two. Also note that for terror missions, the line is taken a bit farther than normal missions, which means that you'll get stronger aliens sooner in terror missions. HTH, [[User:Seb76|Seb76]] 13:36, 5 May 2010 (EDT)

Thank you greatly for your detailed answer ...
I want a few more precise ...
I right understand? I guessed That line 1 - is used for January mission Research? Line 2 - Jan Harvest? Line 3- Jan-Abduction Line 6- January Terror?
What define Line 7?
Line 8 - is February Research?

According to - Line 13 -Feb terror? Line 20 - March terror? Line 27 -April Terror? Line 34- May terror? that sequence and guesses is right?

And question 2) does affect score to choose the value among values in line? How differ choose values in line at the level superhuman and level beginner ?
If you know, naturally, I would be greatly thanks to you for this wonderful magic help.

== Research tree in executable ==

Do you know location (starting offset) of research tree in EU? and how much entries it contains ? and what means values within this array?

Very great thank in advance for this help to you
:The research tree is not stored as a data array but is a hardcoded sequence of "if this is already researched and that is also researched and such item is in the inventory, then enable this research". Modding this would require a complete reengineering, not just patching. Still feasible though. [[User:Seb76|Seb76]] 13:25, 5 May 2010 (EDT)

What is starting offset (ce version) of this hardcoded sequence? and what is latest offset of it? what is length of one sequence? If possible -what is structure of it briefly? (how much bytes to tech requirements, how much bytes to items requrements)

Thank you for this help '''VERY VERY GREAT'''
:As I said, there are no *sequences* but just a cascade of hardcoded ifs:
:[[Image:Research.png]]
:If you want to take a look, the function begins at address 0x446A0. [[User:Seb76|Seb76]] 07:28, 24 May 2010 (EDT)
'''
Seb76, you are GREAT GENIUS!!!! GREATLY RESPECT FOR YOU!!! THANKS FOR YOU VERY VERY MUCH!!!'''
I have found research tree in TFTD too with your help. Now I can do some changes in it.
Maybe do you know, how can I find subprogram that run 1-st day of any month in assembler code of game?
This subprogram determines new mission's month and terror ship route (in TFTD)
There is not in EU terror ship route, I know. But If you know and tell me - what is subprogram in EU that runs 1-st day of any month, I would be able to edit probability of terror ship route in TFTD.
Greatly thanks in advance to you dear Seb76!
:In EU, monthly actions start here:
.text:0043B9B0 GeoPerformMonthlyActions proc near ; CODE XREF: GeoIncrementDayAndDoMonthlyActions:loc_4420C1�j
:HTH, [[User:Seb76|Seb76]] 16:31, 28 May 2010 (EDT)

== Any way to slow down geoscape time? ==

Is there any way to slow down geoscape time progression on fast computers, esp. multiprocessor ones, where it is impossible to significantly slow it down using utilites like MoSlo and Turbo?--[[User:AVE|AVE]] 03:01, 5 May 2010 (EDT)
:Did you try enabling D3D? If you're drivers are configured to wait VSync, it should limit the game speed (well, if you use a CRT@120Hz it'll still be too fast I guess...). Also is it still too fast if you put it windowed? (enabling both D3D and D3D Windowed options) [[User:Seb76|Seb76]] 13:19, 5 May 2010 (EDT)
::Yes, both D3D and D3D Windowed are enabled. This is even more surprising, because it shows the same results on two different computers (Dual Core one and simple P4Celeron) with different video cards (NVidia and ATI). Both have vsync explicitly enabled. LCD@60Hz both. Also I've tried to use different combinations of Video Pitch, D3D, D3DWin and HQ4x settings - no luck. [[User:AVE|AVE]] 04:20, 6 May 2010 (EDT)
:Personally I've never been able to reproduce this "CE game running too fast" thing people keep harping on about. Perhaps I just have a different perception as to what "too fast" means.

:Anyways, I know [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's patched executable] includes a timer hack for the Geoscape, but I found that makes it run far too slow for my taste. Not sure off the top of my head whether it works with Seb's loader, either - you'd probably need to at the very least need to rename Mok's executable to replace the original in order to try it that way. - [[User:Bomb Bloke|Bomb Bloke]] 05:14, 6 May 2010 (EDT)

== Some problem with edit research tree ==

I want to add new 20-30 commands to research tree. I wrote this subprogram. How can I add it to game?
I tried to write "call sub" instead useless 5 bytes in subrogram research tree. I checked in IDA after it, all other commands is preserved.
And I placed my new subprogram after latest byte of executable file. But game is crashed.
I tried to place my new subprogram after all subprograms and before first byte of idata, but game is crashed too.
All indexes in subprogram was exactly.
in second case IDA displayed "sp-analysis failed".

Where and how can I placed my new subprogram that will be addition to current subpogram research tree?
:To add new code, you need to modify the PE header of the exe file accordingly. I'm not quite knowledgeable regarding the procedure (that's one of the reasons why I made a loader instead of patching the file directly) so you're gonna have to find help somewhere else on this one. [[User:Seb76|Seb76]] 16:36, 28 May 2010 (EDT)

== Update to IDA database ==

Hey again Seb76 :)

After a long time I've come back to your extender, dusted off my copy of VC Express, and decided I'd have another go at doing some UFO modding (don't ask how the first attempt went; it's not pretty! :p )

I'm assuming you've probably updated the IDA database since last time I asked. Would be extremely grateful if I could get the latest version.

Thanks for all the hard work, staring at assembly code all day is no joke! --[[User:K9wazere|K9wazere]] 18:07, 6 June 2010 (EDT)

Arf, didn't realise I could send you an email, so this new section on your talk page is a bit redundant now :p Oh well, maybe someone else will want the file too!

== Line of Sight Origin Points ==

Hiya.

A while back you mentioned the co-ords for the [[User talk:Bomb Bloke:Firing Accuracy#Firing Point Origin|firing point origin]]. The zpos is calculated according to the unit's effective height, and the x/ypos co-ords come from look-up tables depending on which way the unit is facing.

I was wondering, are these same two tables used for the purpose of line of ''sight?'' And by any chance could you find the formula for the initial LOS zpos?

Any help would be appreciated, as usual. There are many other obvious questions around this issue (such as where the ''end'' point for these lines is), though the origin would be a good start. - [[User:Bomb Bloke|Bomb Bloke]] 07:44, 24 June 2010 (EDT)

== Training Stat Request ==

Hi there.

In the Equipment screen where the Weight and TUs are displayed during battle, would it be possible to also include the current unit's number of Reaction shots, Hits, Psi attempts and (possibly) Throws? Possibly along the bottom in a horizontal string where there's room?

Talk:Enemy Unknown (1994) Extended

2011-04-05T03:53:41Z

Mannon: /* Craft Always Ready */

= General Discussion =

This is very useful, putting all these things together in one place with clear instructions. This could become the new "standard" version of the game. But I think it's only fair to explain that a lot of the choices you have made for the UFOExtender.ini file are personal choices - you should advise user to review your .ini file (and helpful explanatory comments) and see if they agree.

[[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

In general if we have a mix of features in the standard config, some of which give a minor advantage to XCom (Craft always ready, Elerium fuelled craft bug fix), some of which give a minor advantage to the aliens (Retaliate for Ground Assault), that should work out ok. Features that give a major advantage one way or the other should not be in standard config. [[User:Spike|Spike]] 07:56, 26 August 2009 (EDT)

= UFO Extender Templates =

I think your comments to the .ini file are very helpful. Here are some alternative opinions on some of the options:

*Range Based Accuracy
*[MC] Line of Fire Check

- These are to make the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

*Retaliate Against Ground Assault

- Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

*No Blaster Bomb Drift

- Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

- Maybe you could group the above options together as they all make the game more challenging, i.e. balance the game more in favour of the aliens, and explain that to the player - if you want to make the game more evenly balanced, select these options.

*Tactical Scroll
*Video Pitch
*Music Change Freeze

- You were not experiencing these issues, but others do experience it, so this is an important thing to make clear to users. They should check themselves.

*Elerium-fuelled Craft Bug

- While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

*Funky Fire

- This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

*Crafts Always Ready

- I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

*Keep Base Navigation Modules

- Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

*Base Building Stacking "too complex for benefit"

- Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

*Stun Fest "overpowered"

- I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

*Assign All Personnel

- This is a real time saver

*Hacks

Most of them are deliberate cheats and not meant for normal play so you're right to say they are hugely unbalancing.

However Recover All Clips is a kind of bug fix. Though it does give advantage to XCom it also eliminates the irritating need to manage ammo logistics. With human ammo this is not unbalancing. With scarce alien ammo, it could be, fair enough. No Score Game Over is a way of continuing "hopeless" games. Both of these have precedents in XComUtil, which a lot of players use.

*Initial Base

Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

Lastly, but not least, as Seb76 did so much of the work on UFOExtender, maybe you should give him a credit on the page? And add his UFOExtender page to the See Also?

Cheers, [[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

Spike, thanks. Yes, the choices I made were personal ones informed mostly by my (poor) memories of 15 years ago just to get the ball rolling. This is exactly the discussion I want to have because I think it would be good to come up with a consensus config for a standard version of X-COM for people who just want to get right into the game. I will review your points in detail, rethink the ini config., and make it more clear that seb's UFO Extender is the centerpiece. By the way, this talk page is a hard place to have a discussion - are strategycore forums better? [[User:Xeucom|Xeucom]] 01:57, 20 August 2009 (EDT)

: Hey, great to have you back after 15 years! Sure let's figure out a consensus. Actually I was thinking we might be able to make a few different .ini templates based on some themes, eg:

:* Bug fixes only
:* Convenience features
:* "What the designers intended"
:* Making the game harder
:* Alternate scenarios

:...etc. At the moment I'm trying to recover my account on StrategyCore (I want to post to Zombie's thread on offsets/modding). So when I get my account back I'm happy to talk there. Cheers! [[User:Spike|Spike]] 14:12, 20 August 2009 (EDT)

::Do you remember what your account name is or what email you used to register? If so, I can set you up in a hurry. Just send me an email. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

:: A menu of configs is a good idea. I'd still say we should sweep up a balanced Bug Fixes, Conveneince Features, and Designers Intent into a consensus standard config and establish that as our base line. This is all meant to lure people in/back with a quick and easy setup, get them some play time, then let them explore all the neat options UFO Extender allows. The base line also gives us a standard testing config that we can focus on making bug free (or documenting workarounds). --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

::: Ok that sounds like a plan!

[[User:Spike|Spike]] 05:25, 22 August 2009 (EDT)

: Actually, using a rewritten Initial Base (with a real base) with the stock starting inventory will give you serious cashflow management problems. "Retaliate Against Ground Assault" fixes the cashflow problem, and I'm unclear whether it makes the game easier or harder for X-COM. (I generally have an easier time the first three months on Superhuman than on Beginner, as the extra cashflow from the increased Retalation Acts more than compensates for equally dumb AI with more accurate ranged attacks.) -- [[User:Zaimoni|Zaimoni]] 04:42, 22 August 2009 (CDT)

= Small Scout Map =

Does the Combo Pack include Zombie's Small Scout Map fix? If not, maybe that should be included too. [[User:Spike|Spike]] 14:37, 20 August 2009 (EDT)

:I don't have anything in the kit for the Small Scout because nothing is wrong with it. LOL I do, however, have a Small Scout Mod ([http://www.strategycore.co.uk/files/index.php?dlid=710 found here]) which reintroduces the old Small Scout lefover from the development days. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

::I didn't include the Small Scout patch because it seemed too little gain for the additional step of installing it since people are installing it by manual steps. There is already a very small scout in the game (the one you can grav lift into one square with hole in top) The ideal would be if someone could cook up a little exe that downloaded all the mods and installed them (or we got permission from the authors to bake it into one download) so it was one download and double click. Then it would make sense to add in some more one-trick mods. --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

= Standard Config Discussions =

This section is for discussing what should go in the standard UFO Extender config that is recommended as the downloadable ini file. The concept of the standard config is a config that fixes bugs, introduces convenience features, and retains or improves game balance while keeping the original feel. It is intended for the new or returning player who can put up with a moderate level of difficulty, but is not an elite player (Spike, I will add more sections as I have time to address all the points you raised - these are the ones I had time to research and think about with your feedback).

== Game Version ==

There could be a problem in that the publicly available version of the game is the DOS version released by Steam. The Windows CE version is arguably no longer in the public domain, since Steam now has made its version available. At this time, only one site I can find is still offering downloads of the Windows CE edition. It could be considered the Windows CE edition is no longer "abandonware", and this seems to be the view that the operators of download sites are taking. Therefore, if looking for a reference edition, maybe we should look to modding the Steam, DOS, edition. The problem is that Seb76's loader only works on the Windows CE edition.

I think we should go ahead and define the features of a "standard edition" anyway, but the problem of what version to use will still need to be solved. Basically either the fan community (us!) extends Seb's loader to also apply to the Steam DOS version, or we need to use another tool to patch the DOS version. In theory, XcomUtil could be used to patch the DOS version to introduce all of Seb's additional patches. It is arcane to use but it could be done. The key first step would be to establish a list of patches for the DOS version that are equivalent to Seb's patches to the Windows version.

:Both the Steam and GamersGate (according to forums on the latter) downloads include the Windows version. Specifically, they have a "UFO Defense.exe". I have tested the described mod set with Steam. Steam launches the DosBox DOS version by default through the steam interface, but once you create the shortcut as described, you never use it again. Does that alleviate this concern? [[User:Xeucom|Xeucom]] 09:30 August 23, 2009.

:: You are right! I tested it and, to my surprise, it works. I guess the Steam version must be the Windows CE version, even though it launches it via DosBox. Cool, so there is no problem there - quite the contrary, if all these mods work on the Steam distribution that's excellent. And maybe we can persuade Steam to distribute the "standard extended" version some day. Perhaps not, as we are sort of bypassing their security. Normally when you try to start the executable it should chain back to all the Steam software. In this case, I think we get by that because Seb's loader treats the executable as sort of a data file, loading it rather than directly executing it from the O/S, and also the loader controls the entry points itself (guessing?). Anyway, I suspect Steam don't really care too much about software protection on the old XCom games. [[User:Spike|Spike]] 06:49, 24 August 2009 (EDT)

== Categories ==

Group all fixes into categories:

=== Bug Fixes ===

==== General Bug Fixes ====

All undisputed bugs should be fixed here.

[Bug Fix]
Pay For Dirt=1
Phantom Radar=1
Base Disjoint=1
Radar Stacking=1
Base Facility Dismantle-Construction Crash=1
Collectors Edition Blaster Bomb Bug=1
Proximity Grenades=1
Proximity Grenades Experience=1
Door Jam=1
Personnel Overflow=1
Funky Fire=1
Displayed Base Maintenance Cost=1

[OBDATA.DAT]
Apply=1
;Make grenades indestructible to allow stacking several explosions
Grenade Resistance=255
Proximity Grenade Resistance=255
High Explosive Resistance=255

==== Technical ====

Audio/Video bugfixes or tweaks and other things that some experience, some do not, depending on their platform. Should all be optional and to be set up by the end user. (Possibly video pitch should default to 1, since if it's not enable it can be hard to recover from the screen crash? Which might put users off the "standard extended" package?)

[Bug Fix]
Video Pitch=?
Intro Sounds=?
Music Change Freeze=?
Tactical Scroll=?

[Mod]
HQ4x=?
D3D=?
Scale Mouse=?

[Music]
Apply=1
Source=MP3
;Source=PSX CD
CD Drive=F
MP3 Folder=mp3
Battlescape=*Battlescape*.mp3
Start Menu=*Final Briefing*.mp3
Bad Ending=*Final Briefing*.mp3
Good Ending=*Dogfight*.mp3
Geoscape=*Geoscape*.mp3
Dogfight=*Dogfight*.mp3
Mission Debriefing=*Debriefing*.mp3
UFO Assault=*Briefing1.mp3
Base Defense=*Briefing2.mp3
Base Attack=*Briefing1.mp3
Mars=*Debriefing*.mp3
Terror Mission=*Briefing2.mp3

==== Closed Exploits ====

We ''might'' want to make it optional to close exploits and make that separate from bug fixes. The difference being that bug fixes help the player or are neutral, whereas closing an Exploit by definition makes it relatively harder for the player. Personally I don't like to encourage the use of exploits, but it's an option.

(For now the exploit-closing features have been included in other sections)

:My opinion is that all obvious (in the sense that it is clearly not balanced, not that it is easy to find) exploits should be closed in the standard config. If a player stumbles into an exploit, they can become frustrated because the supension of disbelief and challenge is lost. The game ends up simply looking inconsistent. - [[User:Xeucom|Xeucom]] 19:11 August 25, 2009.

:: I completely agree. You will get some people who routinely rely on certain Exploits, who might not agree. But then they can always change the config file. Probably the most frequently used Exploits are - [[ExploitsA#Free Wages|Free Wages]], [[ExploitsA#Free Manufacturing|Free Manufacturing]], [[Known Bugs#Funky Fire|Funky Fire]], Access Alien Inventory. The [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Robotic Research]] exploits are infrequently used but are massive and should definitely be closed down. [[Exploiting Mind Control#Access the Alien Inventory Screen|Access Alien Inventory]] is arguably not an exploit but merely enables "What The Designers Intended". After all, it seems logical that XCom Psi Troops should be able to access a victim's inventory, just as alien psi attackers can do. It's not in itself unbalancing (or, not any more than Psi itself is). In fact for aliens with only built in attacks it's kind of necessary to make Psi useful on those aliens. It only really becomes unbalancing through the use of [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]. Exponential Mind Control should probably be closed as an Exploit, but I'm not aware of any existing patch that closes it (other than by disabling Access Alien Inventory, which as I've said here is probably not justified). [[Exploiting Mind Control#Zombie's Permanent Control of Aliens via Stunning|Permanent Mind Control]] and the [[Exploiting Mind Control#Resurrect Zombified Agents|Zombie Resurrection]] techniques should also be closed down. [[User:Spike|Spike]] 07:44, 26 August 2009 (EDT)

::[[Tactical Exploits#Elevator Shielding|Elevator Shielding]], which enables risk-free [[Tactical Exploits#Milking Alien Bases|Alien Base Milking]], should also be closed, but again I'm not aware of any fix. [[Grenade Relay]]s, and all similar [[Grenade Relay#Relaying other Equipment|item relays]] - any tactic which allows one item/weapon to be used multiple times per turn by passing it through the hands of multiple soldiers and thereby applying more than 100% TUs to it - are minor and not really important to close down, even though they are a bit silly. [[ExploitsA#Infinite Fuel|Infinite Fuel]] is not so destabilizing as to need closing down as an Exploit, but it probably should be closed just as a bug. [[User:Spike|Spike]] 12:00, 26 August 2009 (EDT)

=== Convenience Features ===

These are logistic or interface enhancements that have a neutral impact on game balance. They should be included by default (unless there is controversy over a particular fix).

[Equipment Screen]
Show Stats=1
Weight=Weight>
Accuracy=Accur>
Reaction=React>
Psi Strength=P.Str>
Psi Skill=P.Skill>
Show Grenade State=1
Primed=primed
; Save Equipment is currently buggy but hopefully will be fixed soon
Save Equipment=0
Auto Flares=1

[Mod]
Save Reserve Mode=1
Rank In Inventory=1
Skip Intro=?
Base Building Stacking=1
Force Language=?
Reorder Soldiers In Crafts=1
De-equip Crafts=1
Assign All Personnel=1
Fast Base Defenses=1

[Battlescape Shortcuts]

[Geoscape Shortcuts]

=== Designer Intent ===

It's sometimes hard to agree designer's intent, but where we agree we should include these.

[Mod]
TFTD Doors=1
Stunned units KIA=1
More Smoke=1
; maybe reduce stun damage from Launchers but otherwise OK:
Stun Fest=1

However if these mods also affect game balance we should think long and hard. Possibly add a subsection:

==== Designer Intent but changes game balance ====

[Bug Fix]
; This makes the game a fair bit easier for XCom, also makes the game less interesting by eliminating any need for regular craft
Elerium-fueled Craft Bug=0

=== Alternate Scenarios ===

Features to permit different ways of playing the game, but not necessarily making it harder.

; Makes recoveries much more fun. Although gives more
; information than you would normally get, it is a very
; minor advantage and worth the compromise to original.
[Wreck Analysis]
Apply=?
Zone Discovered=Intel found out that the %s UFO was raiding %s
Mission Discovered=Inspection showed that the %s UFO was on an %s mission
Both Discovered=Ship investigation revealed that the %s UFO was on an %s mission in %s

; Makes it too easy to find scouts and crashing this often
; does not make sense given alien technology level.
[Roswell]
Apply=?
;Terrain names
Jungle=Jungle
Farm=Farm
Mountain=Mountain
Desert=Desert
Polar=Polar
;Dialog strings
Title=UFO Incident
Info=Crash reported
Location=LOCATION
Type=TYPE
Terrain=TERRAIN

; Needed to complete the game if not allowing any UFO detection
[Mod]
Keep Base Navigation Modules=?

; This makes the game easier but something similar is widely used by experienced players via XcomUtil
; Starting with such a badly designed base is frustrating and modifying the base every time gets boring.
; Starting with a well-designed base could be a good education for starting players.
[Initial Base]
Apply=1
row1=HangarTL HangarTR HangarTL HangarTR HangarTL HangarTR
row2=HangarBL HangarBR HangarBL HangarBR HangarBL HangarBR
row3=AccessLift Empty Empty Empty Empty Empty
row4=GeneralStores LivingQuarters SmallRadar Laboratory Workshop Empty
row5=Empty Empty Empty Empty Empty Empty
row6=Empty Empty Empty Empty Empty Empty

; Another enhancement that is often used via XcomUtil, on the basis that HE Packs are "otherwise useless".
; But many players think HE Packs do have a role. And being able to blow arbitrary holes in UFOs makes it much easier for XCom.
[OBDATA.DAT]
Apply=?
;Make HE packs capable of breaching UFO walls
High Explosive Damage=200

; For playing on even when the situation is hopeless
[Hack]
No Score Game Over=?

; This overpowered weapon makes the game easier but is loads of fun!
[Mod]
Heavy Laser=?

; For people who think a grenade has a fuse that you light with a match ;)
[Mod]
Hot Grenades=0

; Makes the game easier. This is not necessarily a bug, it could reasonably be understood as an intended feature.
[Bug Fix]
Transfered Crafts Refueled=0

; Very convenient for XCom and unbalances the resource side of the game in XCom's favour. Arguably unrealistic.
[Mod]
Crafts Always Ready=0

=== Making The Game Harder ===

Features to increase the level of challenge. Actually this may often overlap with the previous category of Alternate Scenarios. The distinction would be that these features '''always''' make the game harder, whereas the previous category are to help the player when the player '''voluntarily''' plays in an alternative way (which, probably, is a way of playing that makes the game more challenging)

[Mod]
No Funkers=0
Bloodthirst=0
Limited Military=0
Funding Council Income Only=0
Surrender Defence Missions=0
Disable Base Defenses=0
Initial Alien Bases=0
Retaliate Against Ground Assault=0
No Blaster Bomb Drift=0
More Reaction Fire=0
Alien Inventory=0

[Range Based Accuracy]
Apply=0
Minimum Efficiency=50
Snap Penalty Distance=30
Auto Penalty Distance=14
Orange Cursor Threshold=95
Red Cursor Threshold=75

[Line Of Fire Check]
Mind Control=0
Panic=0
Mind Probe=0

[Caps]
Apply=0
Time Units=80
Health=60
Strength=70
Energy=100
Reactions=100
Firing Accuracy=120
Melee Accuracy=120
Throwing Accuracy=120
Psi Skill=100

== Specific Feature Discussions ==

=== Range Based Accuracy ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - If you accept that the role of the standard config as being for the standard player, increasing difficulty for the experienced player would not by itself merit inclusion in the standard config. Things we add to the config to make things more challenging for the elite players might belong in a special 'superhuman plus' config file. Also, the official strategy guide and [[Firing_Accuracy_Testing|information]] on this site suggests that range is already factored into weapon accuracy and fairly balanced. In play, the anecdotal feel is that range does matter.

: Range does matter though only in so far as misses are less likely to accidentally hit at longer ranges. This fix actually reduces the chance of a purposeful hit at longer ranges and increasing the distance penalty for snap fire and even more so auto fire. It could perhaps be better explained! [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: My vote is that this is a Making The Game Harder feature. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

Ranged Based Accuracy doesn't sound like something that directly increase X-Com's difficulty. Doesn't it affect aliens too? If it doesn't, it should. --[[User:SnowJob|SnowJob]] 22:07, 5 July 2010 (EDT)

=== Mind Control Requires Line Of Sight for X-COM Squad ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - See standard config intent and superhuman plus alternative config concept above on difficulty argument. It doesn't seem like physical objects should block mind control in the fictional sense. Also, aliens are able to use it without line of sight (except for seeing the first X-COM soldier). I may be a bit confused here, though: Does the alien squad have to have line of sight on at least one X-COM soldier to be able to use mind control in turns after the aliens first spot an X-COM Soldier? Also, does enabling this make the X-COM soldier who is wielding the psi-amp have to have line of sight on the alien that soldier is going to target?

: Yes the alien squad needs LoS on at least one soldier at some point in the turn. But the same restriction already applies to XCom. I agree this can be put in the superhuman plus category. Not sure of the details of how it works. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

=== Retaliate Against Ground Assault ===

[[User:Spike|Spike]] - Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

[[User:Xeucom|Xeucom]] - I agree with you. Aliens behaving smarter and more logically improves the gameplay experience even if it slightly increases difficulty. I think anything that improves the AI reasoning belongs in the standard config as long as the AI is adhering to fog of war principles. I will enable this in the next standard config ini.

=== Blaster Bomb Drift ===

[[User:Spike|Spike]] - Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

[[User:Xeucom|Xeucom]] - Are you sure that drift only affects aliens? If so, is the blaster bomb overpowered without the drift? As far as I can tell, a direct or close hit from a blaster bomb is guaranteed death for a X-COM soldier, no matter the experience or suit. Would it be better to introduce blaster bomb drift to X-COM firings instead of removing it from the aliens? This seems like one of those random parts of the AI that makes them a little more unpredictable and therefore believable to me. I was reading a story on one of the missions-gone-wrong threads in the forums and an errant blaster bomb firing by the aliens really helped create a funny story.

:Agreed let's confirm that drift only affects aliens. Maybe this could go in Making The Game Harder. Blaster Bombs are terribly lethal so the alien drift is often a lifesaver. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: It's pretty obvious (from StrategyCore old posts, not personally verified) that drift affects XCOM as well; it's why you have to be careful when using a blaster bomb launcher from the Skyranger/Avenger entrance. [[User:Zaimoni|Zaimoni]] 10:21, 25 August 2009 (CDT)

::: OK but in practice this only affects the aliens, since the AI is too stupid to take precautions, whereas players quickly learn to allow some leeway. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Stun Fest ===

[[User:Spike|Spike]] - I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

[[User:Xeucom|Xeucom]] - Do you know that the original game manual has a screenshot with a 'Hit' option for a rifle? Therefore, I agree with you on intent of developers and that there should be a 'pistol whip' stun option for all/most weapons (or empty hand). However, the table at [[User:Seb76|seb's page]] suggests that the weapon values are not less than the stun rod in every case. It seems out of whack (no pun intended) for the missile launcher to do more stun damage than the stun rod, or even more stun damage than a rifle. It would be so bulky it would be harder to beat an alien with that than a pistol or rifle. So my vote is yes for (non-ranged) stun damage for non stun rod weapons, but I think we need to figure out the right balance for stun damage before adding it to the standard config.

:There are definitely some wacky hand to hand damage levels in the executable, normally unused, but I thought that Seb had overridden those values to more sensible levels. I'd better check. :) 04:47, [[User:Spike|Spike]] 04:49, 23 August 2009 (EDT)
::I checked and I would still say "less effective than a Stun Rod in every case". Though the Launchers do get a higher base damage than the Stun Rod, they can only attack once per turn and will use HTH accuracy instead of an automatic hit. Bludgeoning an alien with a weapon is always an act of desperation and less effective than a Stun Rod. But loads of fun and very atmospheric![[User:Spike|Spike]] 13:27, 24 August 2009 (EDT)

:::I see your point when you take into account the Time Units and the accuracy. You convinced me that it belongs in the standard config. [[User:Xeucom|Xeucom]] 18:30, 25 August 2009 (EDT)

=== Elerium Fueled Craft (Bug?) ===

[[User:Spike|Spike]] - While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

[[User:Xeucom|Xeucom]] - It just seems artificial to me that non-elerium craft return home when they are going to have to ditch if they don't, but the elerium craft turn around and head back at an arbitrary fuel level. What would the fictional explanation be? I understand your point about amping up difficulty, but for the standard config, I think consistency is more important. Inconsistency between craft behavior just looks buggy. There are other ways we could increase difficulty that would be much more impactful.

[[User:Spike|Spike]] - Agreed, it disturbs realism and consistency and jars the player experience. That's more important than a slight imbalance. I believe the conventional craft can still stay on station longer than Elerium craft, even with this bug fixed?

=== Craft Always Ready ===

[[User:Spike|Spike]] - I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

[[User:Xeucom|Xeucom]] - I have played with this on and think it is possible you may think that this does more than it does. The only thing that it allows you to do is to dispatch interceptors when they are rearming, refueling, and repairing. It doesn't put them back to 100% loadout, fuel, and integrity. So I think it is still balanced because you are limited to the full refits unless you want to scramble interceptors that only have a short range, or no arms, or are already damaged. I realize that normal rules of procedure would not be to relaunch until total refit is complete, but why not leave it up to the player/commander? In a desperate situation, I think any real-world air force would launch anything in whatever condition it is in and what can be more desperate than fighting aliens? :) Also, X-COM from a fictional perspective is a very odd entity. Some could view it as a professional military alliance of the other powers, but given how little you get and how poorly funded it is (and how you can be shut down by your creditors), it smacks more of a private mercenary corporation whose operational procedures may be largely ad hoc.

[[User:Spike|Spike]] - Agree most of those points. This is only slightly more powerful than just leaving the interceptor in the air on patrol after combat. (It's slightly more powerful because you do get to refuel/rearm while waiting for the next target.) The imbalance I'm talking about is that it makes it possible to maintain one interceptor per base instead of needing two. This has a biggish effect on your cost base early in the game. If there was a balancing "side effect" of launching with low fuel / weapons / repairs, I would be totally happy. As it is, I guess it's not too badly unbalancing.

[[User:Zaimoni|Zaimoni]] - You still need two Interceptors per base to conveniently shoot down Terror Ships before Plasma Cannons, or to conveniently shoot down all non-Battleships in the acts with finales (Infiltration, Base) with Plasma Cannons.

[[User:Mannon|Mannon]] - I've been experimenting with this and I think my opinion has flipped on it. I think craft that aren't fully refueled should be able to take off, but a craft with damage shouldn't. The reason is two-fold. Firstly it makes sense. While you can stop refueling an aircraft and launch it relatively quickly repairing an aircraft would be a whole other story. Except for very light damage you would have to dismantle parts of the aircraft and it simply would not be possible to fly it in such a state. Secondly, it removes all threat from shooting down battleships. Without this mod battleships are always a threat because even your best aircraft can get damaged and put out of service for quite some time. This leaves you having to decide whether it's worth the risk or if you should let it land or use secondary interceptors and cluster them in hopes of minimizing damage. But with this mod it completely alters this dynamic. You no longer have to worry about craft being taken out of service at all. You just launch away. As long as your Avenger's damage isn't too high they can take out a battleship single handedly with dual plama beams and probably have enough time to repair before the next one. In the meantime they can still kill all other UFO's with impunity even if they have 99% damage. I think it changes the game too much to keep it on as is.[[User:Mannon|Mannon]] 23:47, 4 April 2011 (EDT)

=== Base Navigation Modules ===

[[User:Spike|Spike]] - Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

[[User:Xeucom|Xeucom]] - I agree with you and will also include this in the next standard config file. My only discomfort is the explanation of why there are navigation modules at a base, but let's rack that up to spares in hangars.

: Actually in the unmodified game, the base control consoles (destroyed to win the base mission) are Navigation modules. The patch simple captures them intact, instead of destroying them. Equally, we could imagine there are some spares in the base stores. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Modified Initial Base Layout ===

[[User:Spike|Spike]] - Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

[[User:Xeucom|Xeucom]] - This makes sense to me, so I think this should go in the standard config as well. I think the key point you made is avoiding tedium for the player - features that do that without significantly unbalancing should probably go in standard config as matter of course.

=== Base Building Stacking ===

[[User:Spike|Spike]] - Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

[[User:Xeucom|Xeucom]] - My only qualm here is that this seems like a complex feature from a programming perspective that could be risky. Have you played with it a lot and not noticed any increase in crashes or bugs with bases? It doesn't really add anything except being able to lay out the facilities in game sooner - you could still get the same facilities in the same amount of time just waiting for completion messages. The other thing I note with this is that if you turn it off on a game where you have laid out some to-build facilities, bases get funky in with 255 overlayed n the extended modules instead of "Queued". However, for the standard config, I think we should assume that the player will play through the entire game without changing the settings, because otherwise trying to figure out all the possible scenarios would become overwhelming. If you are satisfied that this does not introduced bugginess, I could go for it for the standard config.

[[User:Spike|Spike]] - Well that is a fair point. I have not used the feature enough to swear there are no bugs. Maybe it is safer to leave this as an optional thing that people can enable if they want to.

[[User:Mannon|Mannon]] - I have to disagree on this one too. I don't see how this feature is too complex. It simply puts ques up the construction in areas you can't reach just yet. Construction begins as soon as an adjacent base facility is completed. This greatly simplifies base planning allowing you to lay out as much of your base as you can afford the construction costs on rather than having to make notes on what you intended to build and when. It's a huge improvement and I don't really see any drawbacks to including it.[[User:Mannon|Mannon]] 23:53, 4 April 2011 (EDT)

=== Assign All Personnel ===

[[User:Spike|Spike]] - Highly useful.

[[User:Xeucom|Xeucom]] - I didn't add this to the initial standard config because I don't understand what it does. Can you explain? Also, is it helpful enough to merit the increased risk of negative side effects (crashed, other bugs) when its complexity is considered?

[[User:Spike|Spike]] Basically in various screens this lets you hit the down arrow when the counter is at zero, and the counter goes UP to the highest possible value. This saves you from having to scroll up from 0 to say 100 Scientists, 100 Engineers, etc, whenever starting a new research or manufacturing project. The scrolling speed can be very slow, depending on your machine. This is a very simple mod so I would expect it to be bulletproof from a bug point of view.

[[User:Xeucom|Xeucom]] - Let's call it in for the standard config, then.

=== Save Equipment ===

[[User:Xeucom|Xeucom]] - Spike, I saw that you mentioned in the settings above that you had Save Equpiment turned off because it was buggy. Could you explain? I have used it for some time in my current game and it seems to be working ok. There are some strange things where I am not able to extend the ground portion with the right button and sometimes when I assign a weapon to a soldier it doesn't appear in their hand until I click on one of the slots again. However, I have not verified if this happens with/without UFO Extender or the Save Equipment setting. Since the standard config should aim for bug free, if you think have observed bugs, we should probably leave it out until it is more stable.

: Agreed. There are definitely known bugs with this feature and it is currently described as "Highly Experimental". But once it's working reliably this is a top candidate for inclusion in the standard configuration. [[User:Spike|Spike]] 19:32, 29 August 2009 (EDT)

=== Funky Fire ===

[[User:Spike|Spike]] - This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

[[User:Xeucom|Xeucom]] - The way I understand this it is that the smoke and explosive damage end of turn checks were probably getting applied every time an incendiary shell went off. I think seb76 simply stopped that from happening so that only the entities inside the incendiary shell blast radius took damage and then he increased maximum fire damage from 5 to 10 to compensate for a possible lower fire damage value the original developers put in to offset the bug. From my personal observations, it seems to me that smoke damage is too low and should probably be raised as well because units can spend a lot of time in it without passing out, but that's just an opinion. For the standard config, it sounds like we are in agreement to leave it in because it makes no sense for explosions in other areas of the map to affect other units.

: Yes the illogical behavior is fixed & that's good enough reason to include this fix. My understanding of the fix is that smoke/fire effects only occur at end of turn. This reduced the power of Incendiary weapons a lot, even if not using the Exploit. To partly compensate, Seb has doubled the average damage from fire. There's no exact way to compensate but this is a reasonable approach IMO. [[User:Spike|Spike]] 19:25, 29 August 2009 (EDT)

:: [[User:Xeucom|Xeucom]] - With the fix enabled, if I hit a sectoid with three incendiary shells in one turn, will I do no damage to the sectoid until the turn ends? Or will the sectoid take hit damage (of incendiary type?) on each hit, but no general fire damage from being in a fire square until end of turn?
::: Fire damage will only be applied at the end of the turn. That's why I buffed fire damage up a bit. [[User:Seb76|Seb76]] 13:52, 30 August 2009 (EDT)
:::: In our investigations, we deduced that the so called "incendiary impact damage" is itself an aspect of the bug. And it makes sense that incendiary damage should not take effect as promptly as a bomb,a bullet or a plasma beam. But this does change the play of the game. I don't think it makes much difference apart from people who were exploiting the Funky Fire exploit. But if there was anyone out there who was consistently firing multiple IN rounds at single targets, one at a time, their game play experience will change with this fix. I think it's worth at least a note that this is not just a bug fix but also includes some unavoidable changes in game play. [[User:Spike|Spike]] 04:14, 31 August 2009 (EDT)
::::: This would explain why once when I was facing off against sectoids I had a couple units with incendiaries (night mission, using them to light the place up) and unloaded on a sectoid. After the sixth shell on target, I was like, "Why won't you die!?" Now I understand. However, I think the behavior with Funky Fire makes the most sense because you don't get the random effects from other areas of the map and, really, if you pour a flammable over something and get it coated pretty well, adding more flammable isn't going to really do more damage, so stacking six incendiary shells in an area shouldn't necessarily do more damage to a unit there, just make the fire bigger, which happens naturally anyway because of the deviation in the squares hit. Not quite realistic, but seb76's uptick in fire damage is a fair compromise I think. [[User:Xeucom|Xeucom]] 11:47, 31 August 2009 (EDT)
What are the effects on Zombies? [[User:Magic9mushroom|Magic9mushroom]] 09:55, 1 September 2009 (EDT)

=== Aliens Take Fatal Wounds Damage ===

[[User:Xeucom|Xeucom]] - Saw seb76 made a new release with some new options, so of course have to discuss them for the standard config. :) Starting with this one, this one is a tough call. It's more realistic that aliens could also have fatal wounds. On one hand it makes game easier because injured aliens will die even if they move out of sight and quicker in general if taking damage from fatal wounds. On the other hand, makes game harder because of difficulty capturing live aliens (stunned aliens with fatal wounds likely to die). Can aliens be healed of their fatal wounds with a med kit? If so, introduces entertaining mini-game when trying to capture an alien where you have to stabilize it if injured, perhaps in conjunction with stunning it. A perhaps significant balance problem that arises is X-COM team can have medics with med kits who will heal injured team mates. I suspect this change comes without changes to AI, meaning that aliens will not use med-kits to help each other out. Thoughts?

: I would guess the small number of extra kills from wounds is well-balanced by the scenario you describe, the difficult scenario of trying to stabilise a wounded captive alien, or rush him to the transport before it dies. As this is a new fix we might want to be sure that the alien's death from wounds is handled normally - that correct points are awarded, the game ends properly, etc. Also what happens when a wounded being swaps sides during and after mind control. But (subject to that testing?) I think this one should be included. [[User:Spike|Spike]] 08:50, 1 September 2009 (EDT)

:: The question becomes how do you know you need to stabilise the alien? I can see two ways. First, the mind probe will show you that a standing alien has fatal wounds that you will need to heal once you stun him. Secondly, if medi-kit works on a stunned alien (that's a big if), the display would show you the area hurt (though this may not make sense since I don't think all the aliens are humanoid). I guess this could use some testing to see if the fatal wounds show on mind probe, if you can heal an alien with a med-kit, etc. I like that it opens a new storyline - having to rush the Snakeman Commander to the evac point before he dies, perhaps involving a medic meeting you half way. [[User:Xecuom|Xeucom]] 18:02, 1 September 2009 (EDT)

::: I tested most of the main considerations and they check out OK - see [[User talk:Seb76#Alien Bleeding|here]]. I wasn't able to test the Mind Probe, but you can use the Medkit itself to determine if an aline has any wounds that might need treating. But yes the Mind Probe would be better, since it gives the Health as well, so you can calculate if the alien will die before you can complete the mission. I really expect the Mind Probe will work, since it does normally show the Wound level of aliens - it's just usually always zero. [[User:Spike|Spike]] 20:36, 2 September 2009 (EDT)

=== Unarmed Aliens Pick Up Weapons ===

This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. It would be a very helpful rebalancing of the game that eliminates one of the aliens' weak spots. [[User:Spike|Spike]] 14:44, 3 April 2011 (EDT)

== probability of hit display ==

It would be great if next to the crosshair there would be a percentage indicating the probability of a good hit like in UFO Extraterrestrials.

== May i remake the main page of this article ==

Sorry im new to here so i dont know if i should do it right away or asking someone is polite beforehead or it should be left as is and instead second artice should be added, but:

I have thoughts for current page "Enemy Unknown Extended"
I am willing to write another article, correcting the following:

1) Recently, Xcomutils 6.7 have support for ufoextender. This means, among others, that we no longer need those patches since xcomutils applies them all! It even applies voices and old sounds (more than voices!) but you have to run setup again
2) The supplied INI is old and doenst have every key that new ufoextender uses. This should be avoided imho as the person who dl's it has often litte knowledge to find the hidden options (have to look at the page at this site) or add it (have to copypaste strings from original ini which isnt convinient)
3) For some people (inc me) mp3 solution wont work, for them an explanation how to use PSX Cd would be nice.

Therefore, i'd like to make theese changes:

1) Overview - add that recent 6.7 xcomutils beta build supports ufoextender and so we can use EU+Extender+Xcomutils for a very rich enchanced gameplay
2) Download - remove patches and ini, add xcomutil
3) Verify - accordingly to 2
4) Modify - change to "Patching process" or something as for me, modify isnt that obvious, and then, write here an exact series of steps needed to configue them to work
5) Make shortcut - change to use runxcom.bat

Then i'd like to add "If usage of mp3 causes game to crash" or something with explanation how to use psx cd for music instead
[[User:Istrebitel|Istrebitel]]

:This is a Wiki so everyone can edit anything. But thanks for asking first, that is considered polite, especially before modifying an article page with something that might be seen as a matter of opinion. Could you maybe post your proposed new text here on the Talk page? Also, please sign your posts with 4 tilde characters (~). [[User:Spike|Spike]] 14:39, 3 April 2011 (EDT)

<strike>:I'm a little confused here. You say that XcomUtil 6.7 has UFOextender support, but the lastest version available on the XcomUtil Homepage is XcomUtil 9.60 and I can verify that it very much does not work with UFOextender without some modding to recombine geoscape.exe and tactical.exe back into a single executable since UFOextender crashes if you try to use it to load tactical.exe. Scott's homepage does mention handing over control, but it only gives an email address.[[User:Mannon|Mannon]] 18:21, 3 April 2011 (EDT)
:Another concern is XcomUtil by default makes several changes to the core game, in particular it alters the crafts, making them hold more soldiers. It goes so far as to change the craft's map files (I hate the Avenger, it no longer looks like the UFOpedia entry, but like a fat flying brick.) It even makes the interceptors capable of carrying soldiers. There is no option to turn this off without altering XCUSetup.bat or at least editing XcomUtil.cfg and doing something to fix the Avenger map. I'm not sure how to make those changes easy for someone short of supplying them with an alternate XCUSetup.bat and/or XcomUtil.cfg. Though there are definitely some nice benefits to having XcomUtil installed.[[User:Mannon|Mannon]] 18:29, 3 April 2011 (EDT)</strike>
::Oh NVM. I see that you meant 9.7. I found it and will have to give it a look.[[User:Mannon|Mannon]] 18:43, 3 April 2011 (EDT)

Talk:Enemy Unknown (1994) Extended

2011-04-05T03:53:18Z

Mannon: /* Base Building Stacking */

= General Discussion =

This is very useful, putting all these things together in one place with clear instructions. This could become the new "standard" version of the game. But I think it's only fair to explain that a lot of the choices you have made for the UFOExtender.ini file are personal choices - you should advise user to review your .ini file (and helpful explanatory comments) and see if they agree.

[[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

In general if we have a mix of features in the standard config, some of which give a minor advantage to XCom (Craft always ready, Elerium fuelled craft bug fix), some of which give a minor advantage to the aliens (Retaliate for Ground Assault), that should work out ok. Features that give a major advantage one way or the other should not be in standard config. [[User:Spike|Spike]] 07:56, 26 August 2009 (EDT)

= UFO Extender Templates =

I think your comments to the .ini file are very helpful. Here are some alternative opinions on some of the options:

*Range Based Accuracy
*[MC] Line of Fire Check

- These are to make the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

*Retaliate Against Ground Assault

- Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

*No Blaster Bomb Drift

- Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

- Maybe you could group the above options together as they all make the game more challenging, i.e. balance the game more in favour of the aliens, and explain that to the player - if you want to make the game more evenly balanced, select these options.

*Tactical Scroll
*Video Pitch
*Music Change Freeze

- You were not experiencing these issues, but others do experience it, so this is an important thing to make clear to users. They should check themselves.

*Elerium-fuelled Craft Bug

- While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

*Funky Fire

- This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

*Crafts Always Ready

- I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

*Keep Base Navigation Modules

- Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

*Base Building Stacking "too complex for benefit"

- Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

*Stun Fest "overpowered"

- I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

*Assign All Personnel

- This is a real time saver

*Hacks

Most of them are deliberate cheats and not meant for normal play so you're right to say they are hugely unbalancing.

However Recover All Clips is a kind of bug fix. Though it does give advantage to XCom it also eliminates the irritating need to manage ammo logistics. With human ammo this is not unbalancing. With scarce alien ammo, it could be, fair enough. No Score Game Over is a way of continuing "hopeless" games. Both of these have precedents in XComUtil, which a lot of players use.

*Initial Base

Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

Lastly, but not least, as Seb76 did so much of the work on UFOExtender, maybe you should give him a credit on the page? And add his UFOExtender page to the See Also?

Cheers, [[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

Spike, thanks. Yes, the choices I made were personal ones informed mostly by my (poor) memories of 15 years ago just to get the ball rolling. This is exactly the discussion I want to have because I think it would be good to come up with a consensus config for a standard version of X-COM for people who just want to get right into the game. I will review your points in detail, rethink the ini config., and make it more clear that seb's UFO Extender is the centerpiece. By the way, this talk page is a hard place to have a discussion - are strategycore forums better? [[User:Xeucom|Xeucom]] 01:57, 20 August 2009 (EDT)

: Hey, great to have you back after 15 years! Sure let's figure out a consensus. Actually I was thinking we might be able to make a few different .ini templates based on some themes, eg:

:* Bug fixes only
:* Convenience features
:* "What the designers intended"
:* Making the game harder
:* Alternate scenarios

:...etc. At the moment I'm trying to recover my account on StrategyCore (I want to post to Zombie's thread on offsets/modding). So when I get my account back I'm happy to talk there. Cheers! [[User:Spike|Spike]] 14:12, 20 August 2009 (EDT)

::Do you remember what your account name is or what email you used to register? If so, I can set you up in a hurry. Just send me an email. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

:: A menu of configs is a good idea. I'd still say we should sweep up a balanced Bug Fixes, Conveneince Features, and Designers Intent into a consensus standard config and establish that as our base line. This is all meant to lure people in/back with a quick and easy setup, get them some play time, then let them explore all the neat options UFO Extender allows. The base line also gives us a standard testing config that we can focus on making bug free (or documenting workarounds). --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

::: Ok that sounds like a plan!

[[User:Spike|Spike]] 05:25, 22 August 2009 (EDT)

: Actually, using a rewritten Initial Base (with a real base) with the stock starting inventory will give you serious cashflow management problems. "Retaliate Against Ground Assault" fixes the cashflow problem, and I'm unclear whether it makes the game easier or harder for X-COM. (I generally have an easier time the first three months on Superhuman than on Beginner, as the extra cashflow from the increased Retalation Acts more than compensates for equally dumb AI with more accurate ranged attacks.) -- [[User:Zaimoni|Zaimoni]] 04:42, 22 August 2009 (CDT)

= Small Scout Map =

Does the Combo Pack include Zombie's Small Scout Map fix? If not, maybe that should be included too. [[User:Spike|Spike]] 14:37, 20 August 2009 (EDT)

:I don't have anything in the kit for the Small Scout because nothing is wrong with it. LOL I do, however, have a Small Scout Mod ([http://www.strategycore.co.uk/files/index.php?dlid=710 found here]) which reintroduces the old Small Scout lefover from the development days. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

::I didn't include the Small Scout patch because it seemed too little gain for the additional step of installing it since people are installing it by manual steps. There is already a very small scout in the game (the one you can grav lift into one square with hole in top) The ideal would be if someone could cook up a little exe that downloaded all the mods and installed them (or we got permission from the authors to bake it into one download) so it was one download and double click. Then it would make sense to add in some more one-trick mods. --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

= Standard Config Discussions =

This section is for discussing what should go in the standard UFO Extender config that is recommended as the downloadable ini file. The concept of the standard config is a config that fixes bugs, introduces convenience features, and retains or improves game balance while keeping the original feel. It is intended for the new or returning player who can put up with a moderate level of difficulty, but is not an elite player (Spike, I will add more sections as I have time to address all the points you raised - these are the ones I had time to research and think about with your feedback).

== Game Version ==

There could be a problem in that the publicly available version of the game is the DOS version released by Steam. The Windows CE version is arguably no longer in the public domain, since Steam now has made its version available. At this time, only one site I can find is still offering downloads of the Windows CE edition. It could be considered the Windows CE edition is no longer "abandonware", and this seems to be the view that the operators of download sites are taking. Therefore, if looking for a reference edition, maybe we should look to modding the Steam, DOS, edition. The problem is that Seb76's loader only works on the Windows CE edition.

I think we should go ahead and define the features of a "standard edition" anyway, but the problem of what version to use will still need to be solved. Basically either the fan community (us!) extends Seb's loader to also apply to the Steam DOS version, or we need to use another tool to patch the DOS version. In theory, XcomUtil could be used to patch the DOS version to introduce all of Seb's additional patches. It is arcane to use but it could be done. The key first step would be to establish a list of patches for the DOS version that are equivalent to Seb's patches to the Windows version.

:Both the Steam and GamersGate (according to forums on the latter) downloads include the Windows version. Specifically, they have a "UFO Defense.exe". I have tested the described mod set with Steam. Steam launches the DosBox DOS version by default through the steam interface, but once you create the shortcut as described, you never use it again. Does that alleviate this concern? [[User:Xeucom|Xeucom]] 09:30 August 23, 2009.

:: You are right! I tested it and, to my surprise, it works. I guess the Steam version must be the Windows CE version, even though it launches it via DosBox. Cool, so there is no problem there - quite the contrary, if all these mods work on the Steam distribution that's excellent. And maybe we can persuade Steam to distribute the "standard extended" version some day. Perhaps not, as we are sort of bypassing their security. Normally when you try to start the executable it should chain back to all the Steam software. In this case, I think we get by that because Seb's loader treats the executable as sort of a data file, loading it rather than directly executing it from the O/S, and also the loader controls the entry points itself (guessing?). Anyway, I suspect Steam don't really care too much about software protection on the old XCom games. [[User:Spike|Spike]] 06:49, 24 August 2009 (EDT)

== Categories ==

Group all fixes into categories:

=== Bug Fixes ===

==== General Bug Fixes ====

All undisputed bugs should be fixed here.

[Bug Fix]
Pay For Dirt=1
Phantom Radar=1
Base Disjoint=1
Radar Stacking=1
Base Facility Dismantle-Construction Crash=1
Collectors Edition Blaster Bomb Bug=1
Proximity Grenades=1
Proximity Grenades Experience=1
Door Jam=1
Personnel Overflow=1
Funky Fire=1
Displayed Base Maintenance Cost=1

[OBDATA.DAT]
Apply=1
;Make grenades indestructible to allow stacking several explosions
Grenade Resistance=255
Proximity Grenade Resistance=255
High Explosive Resistance=255

==== Technical ====

Audio/Video bugfixes or tweaks and other things that some experience, some do not, depending on their platform. Should all be optional and to be set up by the end user. (Possibly video pitch should default to 1, since if it's not enable it can be hard to recover from the screen crash? Which might put users off the "standard extended" package?)

[Bug Fix]
Video Pitch=?
Intro Sounds=?
Music Change Freeze=?
Tactical Scroll=?

[Mod]
HQ4x=?
D3D=?
Scale Mouse=?

[Music]
Apply=1
Source=MP3
;Source=PSX CD
CD Drive=F
MP3 Folder=mp3
Battlescape=*Battlescape*.mp3
Start Menu=*Final Briefing*.mp3
Bad Ending=*Final Briefing*.mp3
Good Ending=*Dogfight*.mp3
Geoscape=*Geoscape*.mp3
Dogfight=*Dogfight*.mp3
Mission Debriefing=*Debriefing*.mp3
UFO Assault=*Briefing1.mp3
Base Defense=*Briefing2.mp3
Base Attack=*Briefing1.mp3
Mars=*Debriefing*.mp3
Terror Mission=*Briefing2.mp3

==== Closed Exploits ====

We ''might'' want to make it optional to close exploits and make that separate from bug fixes. The difference being that bug fixes help the player or are neutral, whereas closing an Exploit by definition makes it relatively harder for the player. Personally I don't like to encourage the use of exploits, but it's an option.

(For now the exploit-closing features have been included in other sections)

:My opinion is that all obvious (in the sense that it is clearly not balanced, not that it is easy to find) exploits should be closed in the standard config. If a player stumbles into an exploit, they can become frustrated because the supension of disbelief and challenge is lost. The game ends up simply looking inconsistent. - [[User:Xeucom|Xeucom]] 19:11 August 25, 2009.

:: I completely agree. You will get some people who routinely rely on certain Exploits, who might not agree. But then they can always change the config file. Probably the most frequently used Exploits are - [[ExploitsA#Free Wages|Free Wages]], [[ExploitsA#Free Manufacturing|Free Manufacturing]], [[Known Bugs#Funky Fire|Funky Fire]], Access Alien Inventory. The [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Robotic Research]] exploits are infrequently used but are massive and should definitely be closed down. [[Exploiting Mind Control#Access the Alien Inventory Screen|Access Alien Inventory]] is arguably not an exploit but merely enables "What The Designers Intended". After all, it seems logical that XCom Psi Troops should be able to access a victim's inventory, just as alien psi attackers can do. It's not in itself unbalancing (or, not any more than Psi itself is). In fact for aliens with only built in attacks it's kind of necessary to make Psi useful on those aliens. It only really becomes unbalancing through the use of [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]. Exponential Mind Control should probably be closed as an Exploit, but I'm not aware of any existing patch that closes it (other than by disabling Access Alien Inventory, which as I've said here is probably not justified). [[Exploiting Mind Control#Zombie's Permanent Control of Aliens via Stunning|Permanent Mind Control]] and the [[Exploiting Mind Control#Resurrect Zombified Agents|Zombie Resurrection]] techniques should also be closed down. [[User:Spike|Spike]] 07:44, 26 August 2009 (EDT)

::[[Tactical Exploits#Elevator Shielding|Elevator Shielding]], which enables risk-free [[Tactical Exploits#Milking Alien Bases|Alien Base Milking]], should also be closed, but again I'm not aware of any fix. [[Grenade Relay]]s, and all similar [[Grenade Relay#Relaying other Equipment|item relays]] - any tactic which allows one item/weapon to be used multiple times per turn by passing it through the hands of multiple soldiers and thereby applying more than 100% TUs to it - are minor and not really important to close down, even though they are a bit silly. [[ExploitsA#Infinite Fuel|Infinite Fuel]] is not so destabilizing as to need closing down as an Exploit, but it probably should be closed just as a bug. [[User:Spike|Spike]] 12:00, 26 August 2009 (EDT)

=== Convenience Features ===

These are logistic or interface enhancements that have a neutral impact on game balance. They should be included by default (unless there is controversy over a particular fix).

[Equipment Screen]
Show Stats=1
Weight=Weight>
Accuracy=Accur>
Reaction=React>
Psi Strength=P.Str>
Psi Skill=P.Skill>
Show Grenade State=1
Primed=primed
; Save Equipment is currently buggy but hopefully will be fixed soon
Save Equipment=0
Auto Flares=1

[Mod]
Save Reserve Mode=1
Rank In Inventory=1
Skip Intro=?
Base Building Stacking=1
Force Language=?
Reorder Soldiers In Crafts=1
De-equip Crafts=1
Assign All Personnel=1
Fast Base Defenses=1

[Battlescape Shortcuts]

[Geoscape Shortcuts]

=== Designer Intent ===

It's sometimes hard to agree designer's intent, but where we agree we should include these.

[Mod]
TFTD Doors=1
Stunned units KIA=1
More Smoke=1
; maybe reduce stun damage from Launchers but otherwise OK:
Stun Fest=1

However if these mods also affect game balance we should think long and hard. Possibly add a subsection:

==== Designer Intent but changes game balance ====

[Bug Fix]
; This makes the game a fair bit easier for XCom, also makes the game less interesting by eliminating any need for regular craft
Elerium-fueled Craft Bug=0

=== Alternate Scenarios ===

Features to permit different ways of playing the game, but not necessarily making it harder.

; Makes recoveries much more fun. Although gives more
; information than you would normally get, it is a very
; minor advantage and worth the compromise to original.
[Wreck Analysis]
Apply=?
Zone Discovered=Intel found out that the %s UFO was raiding %s
Mission Discovered=Inspection showed that the %s UFO was on an %s mission
Both Discovered=Ship investigation revealed that the %s UFO was on an %s mission in %s

; Makes it too easy to find scouts and crashing this often
; does not make sense given alien technology level.
[Roswell]
Apply=?
;Terrain names
Jungle=Jungle
Farm=Farm
Mountain=Mountain
Desert=Desert
Polar=Polar
;Dialog strings
Title=UFO Incident
Info=Crash reported
Location=LOCATION
Type=TYPE
Terrain=TERRAIN

; Needed to complete the game if not allowing any UFO detection
[Mod]
Keep Base Navigation Modules=?

; This makes the game easier but something similar is widely used by experienced players via XcomUtil
; Starting with such a badly designed base is frustrating and modifying the base every time gets boring.
; Starting with a well-designed base could be a good education for starting players.
[Initial Base]
Apply=1
row1=HangarTL HangarTR HangarTL HangarTR HangarTL HangarTR
row2=HangarBL HangarBR HangarBL HangarBR HangarBL HangarBR
row3=AccessLift Empty Empty Empty Empty Empty
row4=GeneralStores LivingQuarters SmallRadar Laboratory Workshop Empty
row5=Empty Empty Empty Empty Empty Empty
row6=Empty Empty Empty Empty Empty Empty

; Another enhancement that is often used via XcomUtil, on the basis that HE Packs are "otherwise useless".
; But many players think HE Packs do have a role. And being able to blow arbitrary holes in UFOs makes it much easier for XCom.
[OBDATA.DAT]
Apply=?
;Make HE packs capable of breaching UFO walls
High Explosive Damage=200

; For playing on even when the situation is hopeless
[Hack]
No Score Game Over=?

; This overpowered weapon makes the game easier but is loads of fun!
[Mod]
Heavy Laser=?

; For people who think a grenade has a fuse that you light with a match ;)
[Mod]
Hot Grenades=0

; Makes the game easier. This is not necessarily a bug, it could reasonably be understood as an intended feature.
[Bug Fix]
Transfered Crafts Refueled=0

; Very convenient for XCom and unbalances the resource side of the game in XCom's favour. Arguably unrealistic.
[Mod]
Crafts Always Ready=0

=== Making The Game Harder ===

Features to increase the level of challenge. Actually this may often overlap with the previous category of Alternate Scenarios. The distinction would be that these features '''always''' make the game harder, whereas the previous category are to help the player when the player '''voluntarily''' plays in an alternative way (which, probably, is a way of playing that makes the game more challenging)

[Mod]
No Funkers=0
Bloodthirst=0
Limited Military=0
Funding Council Income Only=0
Surrender Defence Missions=0
Disable Base Defenses=0
Initial Alien Bases=0
Retaliate Against Ground Assault=0
No Blaster Bomb Drift=0
More Reaction Fire=0
Alien Inventory=0

[Range Based Accuracy]
Apply=0
Minimum Efficiency=50
Snap Penalty Distance=30
Auto Penalty Distance=14
Orange Cursor Threshold=95
Red Cursor Threshold=75

[Line Of Fire Check]
Mind Control=0
Panic=0
Mind Probe=0

[Caps]
Apply=0
Time Units=80
Health=60
Strength=70
Energy=100
Reactions=100
Firing Accuracy=120
Melee Accuracy=120
Throwing Accuracy=120
Psi Skill=100

== Specific Feature Discussions ==

=== Range Based Accuracy ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - If you accept that the role of the standard config as being for the standard player, increasing difficulty for the experienced player would not by itself merit inclusion in the standard config. Things we add to the config to make things more challenging for the elite players might belong in a special 'superhuman plus' config file. Also, the official strategy guide and [[Firing_Accuracy_Testing|information]] on this site suggests that range is already factored into weapon accuracy and fairly balanced. In play, the anecdotal feel is that range does matter.

: Range does matter though only in so far as misses are less likely to accidentally hit at longer ranges. This fix actually reduces the chance of a purposeful hit at longer ranges and increasing the distance penalty for snap fire and even more so auto fire. It could perhaps be better explained! [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: My vote is that this is a Making The Game Harder feature. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

Ranged Based Accuracy doesn't sound like something that directly increase X-Com's difficulty. Doesn't it affect aliens too? If it doesn't, it should. --[[User:SnowJob|SnowJob]] 22:07, 5 July 2010 (EDT)

=== Mind Control Requires Line Of Sight for X-COM Squad ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - See standard config intent and superhuman plus alternative config concept above on difficulty argument. It doesn't seem like physical objects should block mind control in the fictional sense. Also, aliens are able to use it without line of sight (except for seeing the first X-COM soldier). I may be a bit confused here, though: Does the alien squad have to have line of sight on at least one X-COM soldier to be able to use mind control in turns after the aliens first spot an X-COM Soldier? Also, does enabling this make the X-COM soldier who is wielding the psi-amp have to have line of sight on the alien that soldier is going to target?

: Yes the alien squad needs LoS on at least one soldier at some point in the turn. But the same restriction already applies to XCom. I agree this can be put in the superhuman plus category. Not sure of the details of how it works. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

=== Retaliate Against Ground Assault ===

[[User:Spike|Spike]] - Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

[[User:Xeucom|Xeucom]] - I agree with you. Aliens behaving smarter and more logically improves the gameplay experience even if it slightly increases difficulty. I think anything that improves the AI reasoning belongs in the standard config as long as the AI is adhering to fog of war principles. I will enable this in the next standard config ini.

=== Blaster Bomb Drift ===

[[User:Spike|Spike]] - Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

[[User:Xeucom|Xeucom]] - Are you sure that drift only affects aliens? If so, is the blaster bomb overpowered without the drift? As far as I can tell, a direct or close hit from a blaster bomb is guaranteed death for a X-COM soldier, no matter the experience or suit. Would it be better to introduce blaster bomb drift to X-COM firings instead of removing it from the aliens? This seems like one of those random parts of the AI that makes them a little more unpredictable and therefore believable to me. I was reading a story on one of the missions-gone-wrong threads in the forums and an errant blaster bomb firing by the aliens really helped create a funny story.

:Agreed let's confirm that drift only affects aliens. Maybe this could go in Making The Game Harder. Blaster Bombs are terribly lethal so the alien drift is often a lifesaver. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: It's pretty obvious (from StrategyCore old posts, not personally verified) that drift affects XCOM as well; it's why you have to be careful when using a blaster bomb launcher from the Skyranger/Avenger entrance. [[User:Zaimoni|Zaimoni]] 10:21, 25 August 2009 (CDT)

::: OK but in practice this only affects the aliens, since the AI is too stupid to take precautions, whereas players quickly learn to allow some leeway. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Stun Fest ===

[[User:Spike|Spike]] - I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

[[User:Xeucom|Xeucom]] - Do you know that the original game manual has a screenshot with a 'Hit' option for a rifle? Therefore, I agree with you on intent of developers and that there should be a 'pistol whip' stun option for all/most weapons (or empty hand). However, the table at [[User:Seb76|seb's page]] suggests that the weapon values are not less than the stun rod in every case. It seems out of whack (no pun intended) for the missile launcher to do more stun damage than the stun rod, or even more stun damage than a rifle. It would be so bulky it would be harder to beat an alien with that than a pistol or rifle. So my vote is yes for (non-ranged) stun damage for non stun rod weapons, but I think we need to figure out the right balance for stun damage before adding it to the standard config.

:There are definitely some wacky hand to hand damage levels in the executable, normally unused, but I thought that Seb had overridden those values to more sensible levels. I'd better check. :) 04:47, [[User:Spike|Spike]] 04:49, 23 August 2009 (EDT)
::I checked and I would still say "less effective than a Stun Rod in every case". Though the Launchers do get a higher base damage than the Stun Rod, they can only attack once per turn and will use HTH accuracy instead of an automatic hit. Bludgeoning an alien with a weapon is always an act of desperation and less effective than a Stun Rod. But loads of fun and very atmospheric![[User:Spike|Spike]] 13:27, 24 August 2009 (EDT)

:::I see your point when you take into account the Time Units and the accuracy. You convinced me that it belongs in the standard config. [[User:Xeucom|Xeucom]] 18:30, 25 August 2009 (EDT)

=== Elerium Fueled Craft (Bug?) ===

[[User:Spike|Spike]] - While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

[[User:Xeucom|Xeucom]] - It just seems artificial to me that non-elerium craft return home when they are going to have to ditch if they don't, but the elerium craft turn around and head back at an arbitrary fuel level. What would the fictional explanation be? I understand your point about amping up difficulty, but for the standard config, I think consistency is more important. Inconsistency between craft behavior just looks buggy. There are other ways we could increase difficulty that would be much more impactful.

[[User:Spike|Spike]] - Agreed, it disturbs realism and consistency and jars the player experience. That's more important than a slight imbalance. I believe the conventional craft can still stay on station longer than Elerium craft, even with this bug fixed?

=== Craft Always Ready ===

[[User:Spike|Spike]] - I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

[[User:Xeucom|Xeucom]] - I have played with this on and think it is possible you may think that this does more than it does. The only thing that it allows you to do is to dispatch interceptors when they are rearming, refueling, and repairing. It doesn't put them back to 100% loadout, fuel, and integrity. So I think it is still balanced because you are limited to the full refits unless you want to scramble interceptors that only have a short range, or no arms, or are already damaged. I realize that normal rules of procedure would not be to relaunch until total refit is complete, but why not leave it up to the player/commander? In a desperate situation, I think any real-world air force would launch anything in whatever condition it is in and what can be more desperate than fighting aliens? :) Also, X-COM from a fictional perspective is a very odd entity. Some could view it as a professional military alliance of the other powers, but given how little you get and how poorly funded it is (and how you can be shut down by your creditors), it smacks more of a private mercenary corporation whose operational procedures may be largely ad hoc.

[[User:Spike|Spike]] - Agree most of those points. This is only slightly more powerful than just leaving the interceptor in the air on patrol after combat. (It's slightly more powerful because you do get to refuel/rearm while waiting for the next target.) The imbalance I'm talking about is that it makes it possible to maintain one interceptor per base instead of needing two. This has a biggish effect on your cost base early in the game. If there was a balancing "side effect" of launching with low fuel / weapons / repairs, I would be totally happy. As it is, I guess it's not too badly unbalancing.

[[User:Zaimoni|Zaimoni]] - You still need two Interceptors per base to conveniently shoot down Terror Ships before Plasma Cannons, or to conveniently shoot down all non-Battleships in the acts with finales (Infiltration, Base) with Plasma Cannons.

::I've been experimenting with this and I think my opinion has flipped on it. I think craft that aren't fully refueled should be able to take off, but a craft with damage shouldn't. The reason is two-fold. Firstly it makes sense. While you can stop refueling an aircraft and launch it relatively quickly repairing an aircraft would be a whole other story. Except for very light damage you would have to dismantle parts of the aircraft and it simply would not be possible to fly it in such a state. Secondly, it removes all threat from shooting down battleships. Without this mod battleships are always a threat because even your best aircraft can get damaged and put out of service for quite some time. This leaves you having to decide whether it's worth the risk or if you should let it land or use secondary interceptors and cluster them in hopes of minimizing damage. But with this mod it completely alters this dynamic. You no longer have to worry about craft being taken out of service at all. You just launch away. As long as your Avenger's damage isn't too high they can take out a battleship single handedly with dual plama beams and probably have enough time to repair before the next one. In the meantime they can still kill all other UFO's with impunity even if they have 99% damage. I think it changes the game too much to keep it on as is.[[User:Mannon|Mannon]] 23:47, 4 April 2011 (EDT)

=== Base Navigation Modules ===

[[User:Spike|Spike]] - Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

[[User:Xeucom|Xeucom]] - I agree with you and will also include this in the next standard config file. My only discomfort is the explanation of why there are navigation modules at a base, but let's rack that up to spares in hangars.

: Actually in the unmodified game, the base control consoles (destroyed to win the base mission) are Navigation modules. The patch simple captures them intact, instead of destroying them. Equally, we could imagine there are some spares in the base stores. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Modified Initial Base Layout ===

[[User:Spike|Spike]] - Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

[[User:Xeucom|Xeucom]] - This makes sense to me, so I think this should go in the standard config as well. I think the key point you made is avoiding tedium for the player - features that do that without significantly unbalancing should probably go in standard config as matter of course.

=== Base Building Stacking ===

[[User:Spike|Spike]] - Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

[[User:Xeucom|Xeucom]] - My only qualm here is that this seems like a complex feature from a programming perspective that could be risky. Have you played with it a lot and not noticed any increase in crashes or bugs with bases? It doesn't really add anything except being able to lay out the facilities in game sooner - you could still get the same facilities in the same amount of time just waiting for completion messages. The other thing I note with this is that if you turn it off on a game where you have laid out some to-build facilities, bases get funky in with 255 overlayed n the extended modules instead of "Queued". However, for the standard config, I think we should assume that the player will play through the entire game without changing the settings, because otherwise trying to figure out all the possible scenarios would become overwhelming. If you are satisfied that this does not introduced bugginess, I could go for it for the standard config.

[[User:Spike|Spike]] - Well that is a fair point. I have not used the feature enough to swear there are no bugs. Maybe it is safer to leave this as an optional thing that people can enable if they want to.

[[User:Mannon|Mannon]] - I have to disagree on this one too. I don't see how this feature is too complex. It simply puts ques up the construction in areas you can't reach just yet. Construction begins as soon as an adjacent base facility is completed. This greatly simplifies base planning allowing you to lay out as much of your base as you can afford the construction costs on rather than having to make notes on what you intended to build and when. It's a huge improvement and I don't really see any drawbacks to including it.[[User:Mannon|Mannon]] 23:53, 4 April 2011 (EDT)

=== Assign All Personnel ===

[[User:Spike|Spike]] - Highly useful.

[[User:Xeucom|Xeucom]] - I didn't add this to the initial standard config because I don't understand what it does. Can you explain? Also, is it helpful enough to merit the increased risk of negative side effects (crashed, other bugs) when its complexity is considered?

[[User:Spike|Spike]] Basically in various screens this lets you hit the down arrow when the counter is at zero, and the counter goes UP to the highest possible value. This saves you from having to scroll up from 0 to say 100 Scientists, 100 Engineers, etc, whenever starting a new research or manufacturing project. The scrolling speed can be very slow, depending on your machine. This is a very simple mod so I would expect it to be bulletproof from a bug point of view.

[[User:Xeucom|Xeucom]] - Let's call it in for the standard config, then.

=== Save Equipment ===

[[User:Xeucom|Xeucom]] - Spike, I saw that you mentioned in the settings above that you had Save Equpiment turned off because it was buggy. Could you explain? I have used it for some time in my current game and it seems to be working ok. There are some strange things where I am not able to extend the ground portion with the right button and sometimes when I assign a weapon to a soldier it doesn't appear in their hand until I click on one of the slots again. However, I have not verified if this happens with/without UFO Extender or the Save Equipment setting. Since the standard config should aim for bug free, if you think have observed bugs, we should probably leave it out until it is more stable.

: Agreed. There are definitely known bugs with this feature and it is currently described as "Highly Experimental". But once it's working reliably this is a top candidate for inclusion in the standard configuration. [[User:Spike|Spike]] 19:32, 29 August 2009 (EDT)

=== Funky Fire ===

[[User:Spike|Spike]] - This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

[[User:Xeucom|Xeucom]] - The way I understand this it is that the smoke and explosive damage end of turn checks were probably getting applied every time an incendiary shell went off. I think seb76 simply stopped that from happening so that only the entities inside the incendiary shell blast radius took damage and then he increased maximum fire damage from 5 to 10 to compensate for a possible lower fire damage value the original developers put in to offset the bug. From my personal observations, it seems to me that smoke damage is too low and should probably be raised as well because units can spend a lot of time in it without passing out, but that's just an opinion. For the standard config, it sounds like we are in agreement to leave it in because it makes no sense for explosions in other areas of the map to affect other units.

: Yes the illogical behavior is fixed & that's good enough reason to include this fix. My understanding of the fix is that smoke/fire effects only occur at end of turn. This reduced the power of Incendiary weapons a lot, even if not using the Exploit. To partly compensate, Seb has doubled the average damage from fire. There's no exact way to compensate but this is a reasonable approach IMO. [[User:Spike|Spike]] 19:25, 29 August 2009 (EDT)

:: [[User:Xeucom|Xeucom]] - With the fix enabled, if I hit a sectoid with three incendiary shells in one turn, will I do no damage to the sectoid until the turn ends? Or will the sectoid take hit damage (of incendiary type?) on each hit, but no general fire damage from being in a fire square until end of turn?
::: Fire damage will only be applied at the end of the turn. That's why I buffed fire damage up a bit. [[User:Seb76|Seb76]] 13:52, 30 August 2009 (EDT)
:::: In our investigations, we deduced that the so called "incendiary impact damage" is itself an aspect of the bug. And it makes sense that incendiary damage should not take effect as promptly as a bomb,a bullet or a plasma beam. But this does change the play of the game. I don't think it makes much difference apart from people who were exploiting the Funky Fire exploit. But if there was anyone out there who was consistently firing multiple IN rounds at single targets, one at a time, their game play experience will change with this fix. I think it's worth at least a note that this is not just a bug fix but also includes some unavoidable changes in game play. [[User:Spike|Spike]] 04:14, 31 August 2009 (EDT)
::::: This would explain why once when I was facing off against sectoids I had a couple units with incendiaries (night mission, using them to light the place up) and unloaded on a sectoid. After the sixth shell on target, I was like, "Why won't you die!?" Now I understand. However, I think the behavior with Funky Fire makes the most sense because you don't get the random effects from other areas of the map and, really, if you pour a flammable over something and get it coated pretty well, adding more flammable isn't going to really do more damage, so stacking six incendiary shells in an area shouldn't necessarily do more damage to a unit there, just make the fire bigger, which happens naturally anyway because of the deviation in the squares hit. Not quite realistic, but seb76's uptick in fire damage is a fair compromise I think. [[User:Xeucom|Xeucom]] 11:47, 31 August 2009 (EDT)
What are the effects on Zombies? [[User:Magic9mushroom|Magic9mushroom]] 09:55, 1 September 2009 (EDT)

=== Aliens Take Fatal Wounds Damage ===

[[User:Xeucom|Xeucom]] - Saw seb76 made a new release with some new options, so of course have to discuss them for the standard config. :) Starting with this one, this one is a tough call. It's more realistic that aliens could also have fatal wounds. On one hand it makes game easier because injured aliens will die even if they move out of sight and quicker in general if taking damage from fatal wounds. On the other hand, makes game harder because of difficulty capturing live aliens (stunned aliens with fatal wounds likely to die). Can aliens be healed of their fatal wounds with a med kit? If so, introduces entertaining mini-game when trying to capture an alien where you have to stabilize it if injured, perhaps in conjunction with stunning it. A perhaps significant balance problem that arises is X-COM team can have medics with med kits who will heal injured team mates. I suspect this change comes without changes to AI, meaning that aliens will not use med-kits to help each other out. Thoughts?

: I would guess the small number of extra kills from wounds is well-balanced by the scenario you describe, the difficult scenario of trying to stabilise a wounded captive alien, or rush him to the transport before it dies. As this is a new fix we might want to be sure that the alien's death from wounds is handled normally - that correct points are awarded, the game ends properly, etc. Also what happens when a wounded being swaps sides during and after mind control. But (subject to that testing?) I think this one should be included. [[User:Spike|Spike]] 08:50, 1 September 2009 (EDT)

:: The question becomes how do you know you need to stabilise the alien? I can see two ways. First, the mind probe will show you that a standing alien has fatal wounds that you will need to heal once you stun him. Secondly, if medi-kit works on a stunned alien (that's a big if), the display would show you the area hurt (though this may not make sense since I don't think all the aliens are humanoid). I guess this could use some testing to see if the fatal wounds show on mind probe, if you can heal an alien with a med-kit, etc. I like that it opens a new storyline - having to rush the Snakeman Commander to the evac point before he dies, perhaps involving a medic meeting you half way. [[User:Xecuom|Xeucom]] 18:02, 1 September 2009 (EDT)

::: I tested most of the main considerations and they check out OK - see [[User talk:Seb76#Alien Bleeding|here]]. I wasn't able to test the Mind Probe, but you can use the Medkit itself to determine if an aline has any wounds that might need treating. But yes the Mind Probe would be better, since it gives the Health as well, so you can calculate if the alien will die before you can complete the mission. I really expect the Mind Probe will work, since it does normally show the Wound level of aliens - it's just usually always zero. [[User:Spike|Spike]] 20:36, 2 September 2009 (EDT)

=== Unarmed Aliens Pick Up Weapons ===

This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. It would be a very helpful rebalancing of the game that eliminates one of the aliens' weak spots. [[User:Spike|Spike]] 14:44, 3 April 2011 (EDT)

== probability of hit display ==

It would be great if next to the crosshair there would be a percentage indicating the probability of a good hit like in UFO Extraterrestrials.

== May i remake the main page of this article ==

Sorry im new to here so i dont know if i should do it right away or asking someone is polite beforehead or it should be left as is and instead second artice should be added, but:

I have thoughts for current page "Enemy Unknown Extended"
I am willing to write another article, correcting the following:

1) Recently, Xcomutils 6.7 have support for ufoextender. This means, among others, that we no longer need those patches since xcomutils applies them all! It even applies voices and old sounds (more than voices!) but you have to run setup again
2) The supplied INI is old and doenst have every key that new ufoextender uses. This should be avoided imho as the person who dl's it has often litte knowledge to find the hidden options (have to look at the page at this site) or add it (have to copypaste strings from original ini which isnt convinient)
3) For some people (inc me) mp3 solution wont work, for them an explanation how to use PSX Cd would be nice.

Therefore, i'd like to make theese changes:

1) Overview - add that recent 6.7 xcomutils beta build supports ufoextender and so we can use EU+Extender+Xcomutils for a very rich enchanced gameplay
2) Download - remove patches and ini, add xcomutil
3) Verify - accordingly to 2
4) Modify - change to "Patching process" or something as for me, modify isnt that obvious, and then, write here an exact series of steps needed to configue them to work
5) Make shortcut - change to use runxcom.bat

Then i'd like to add "If usage of mp3 causes game to crash" or something with explanation how to use psx cd for music instead
[[User:Istrebitel|Istrebitel]]

:This is a Wiki so everyone can edit anything. But thanks for asking first, that is considered polite, especially before modifying an article page with something that might be seen as a matter of opinion. Could you maybe post your proposed new text here on the Talk page? Also, please sign your posts with 4 tilde characters (~). [[User:Spike|Spike]] 14:39, 3 April 2011 (EDT)

<strike>:I'm a little confused here. You say that XcomUtil 6.7 has UFOextender support, but the lastest version available on the XcomUtil Homepage is XcomUtil 9.60 and I can verify that it very much does not work with UFOextender without some modding to recombine geoscape.exe and tactical.exe back into a single executable since UFOextender crashes if you try to use it to load tactical.exe. Scott's homepage does mention handing over control, but it only gives an email address.[[User:Mannon|Mannon]] 18:21, 3 April 2011 (EDT)
:Another concern is XcomUtil by default makes several changes to the core game, in particular it alters the crafts, making them hold more soldiers. It goes so far as to change the craft's map files (I hate the Avenger, it no longer looks like the UFOpedia entry, but like a fat flying brick.) It even makes the interceptors capable of carrying soldiers. There is no option to turn this off without altering XCUSetup.bat or at least editing XcomUtil.cfg and doing something to fix the Avenger map. I'm not sure how to make those changes easy for someone short of supplying them with an alternate XCUSetup.bat and/or XcomUtil.cfg. Though there are definitely some nice benefits to having XcomUtil installed.[[User:Mannon|Mannon]] 18:29, 3 April 2011 (EDT)</strike>
::Oh NVM. I see that you meant 9.7. I found it and will have to give it a look.[[User:Mannon|Mannon]] 18:43, 3 April 2011 (EDT)

Talk:Enemy Unknown (1994) Extended

2011-04-05T03:47:16Z

Mannon: /* Craft Always Ready */

= General Discussion =

This is very useful, putting all these things together in one place with clear instructions. This could become the new "standard" version of the game. But I think it's only fair to explain that a lot of the choices you have made for the UFOExtender.ini file are personal choices - you should advise user to review your .ini file (and helpful explanatory comments) and see if they agree.

[[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

In general if we have a mix of features in the standard config, some of which give a minor advantage to XCom (Craft always ready, Elerium fuelled craft bug fix), some of which give a minor advantage to the aliens (Retaliate for Ground Assault), that should work out ok. Features that give a major advantage one way or the other should not be in standard config. [[User:Spike|Spike]] 07:56, 26 August 2009 (EDT)

= UFO Extender Templates =

I think your comments to the .ini file are very helpful. Here are some alternative opinions on some of the options:

*Range Based Accuracy
*[MC] Line of Fire Check

- These are to make the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

*Retaliate Against Ground Assault

- Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

*No Blaster Bomb Drift

- Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

- Maybe you could group the above options together as they all make the game more challenging, i.e. balance the game more in favour of the aliens, and explain that to the player - if you want to make the game more evenly balanced, select these options.

*Tactical Scroll
*Video Pitch
*Music Change Freeze

- You were not experiencing these issues, but others do experience it, so this is an important thing to make clear to users. They should check themselves.

*Elerium-fuelled Craft Bug

- While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

*Funky Fire

- This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

*Crafts Always Ready

- I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

*Keep Base Navigation Modules

- Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

*Base Building Stacking "too complex for benefit"

- Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

*Stun Fest "overpowered"

- I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

*Assign All Personnel

- This is a real time saver

*Hacks

Most of them are deliberate cheats and not meant for normal play so you're right to say they are hugely unbalancing.

However Recover All Clips is a kind of bug fix. Though it does give advantage to XCom it also eliminates the irritating need to manage ammo logistics. With human ammo this is not unbalancing. With scarce alien ammo, it could be, fair enough. No Score Game Over is a way of continuing "hopeless" games. Both of these have precedents in XComUtil, which a lot of players use.

*Initial Base

Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

Lastly, but not least, as Seb76 did so much of the work on UFOExtender, maybe you should give him a credit on the page? And add his UFOExtender page to the See Also?

Cheers, [[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

Spike, thanks. Yes, the choices I made were personal ones informed mostly by my (poor) memories of 15 years ago just to get the ball rolling. This is exactly the discussion I want to have because I think it would be good to come up with a consensus config for a standard version of X-COM for people who just want to get right into the game. I will review your points in detail, rethink the ini config., and make it more clear that seb's UFO Extender is the centerpiece. By the way, this talk page is a hard place to have a discussion - are strategycore forums better? [[User:Xeucom|Xeucom]] 01:57, 20 August 2009 (EDT)

: Hey, great to have you back after 15 years! Sure let's figure out a consensus. Actually I was thinking we might be able to make a few different .ini templates based on some themes, eg:

:* Bug fixes only
:* Convenience features
:* "What the designers intended"
:* Making the game harder
:* Alternate scenarios

:...etc. At the moment I'm trying to recover my account on StrategyCore (I want to post to Zombie's thread on offsets/modding). So when I get my account back I'm happy to talk there. Cheers! [[User:Spike|Spike]] 14:12, 20 August 2009 (EDT)

::Do you remember what your account name is or what email you used to register? If so, I can set you up in a hurry. Just send me an email. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

:: A menu of configs is a good idea. I'd still say we should sweep up a balanced Bug Fixes, Conveneince Features, and Designers Intent into a consensus standard config and establish that as our base line. This is all meant to lure people in/back with a quick and easy setup, get them some play time, then let them explore all the neat options UFO Extender allows. The base line also gives us a standard testing config that we can focus on making bug free (or documenting workarounds). --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

::: Ok that sounds like a plan!

[[User:Spike|Spike]] 05:25, 22 August 2009 (EDT)

: Actually, using a rewritten Initial Base (with a real base) with the stock starting inventory will give you serious cashflow management problems. "Retaliate Against Ground Assault" fixes the cashflow problem, and I'm unclear whether it makes the game easier or harder for X-COM. (I generally have an easier time the first three months on Superhuman than on Beginner, as the extra cashflow from the increased Retalation Acts more than compensates for equally dumb AI with more accurate ranged attacks.) -- [[User:Zaimoni|Zaimoni]] 04:42, 22 August 2009 (CDT)

= Small Scout Map =

Does the Combo Pack include Zombie's Small Scout Map fix? If not, maybe that should be included too. [[User:Spike|Spike]] 14:37, 20 August 2009 (EDT)

:I don't have anything in the kit for the Small Scout because nothing is wrong with it. LOL I do, however, have a Small Scout Mod ([http://www.strategycore.co.uk/files/index.php?dlid=710 found here]) which reintroduces the old Small Scout lefover from the development days. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

::I didn't include the Small Scout patch because it seemed too little gain for the additional step of installing it since people are installing it by manual steps. There is already a very small scout in the game (the one you can grav lift into one square with hole in top) The ideal would be if someone could cook up a little exe that downloaded all the mods and installed them (or we got permission from the authors to bake it into one download) so it was one download and double click. Then it would make sense to add in some more one-trick mods. --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

= Standard Config Discussions =

This section is for discussing what should go in the standard UFO Extender config that is recommended as the downloadable ini file. The concept of the standard config is a config that fixes bugs, introduces convenience features, and retains or improves game balance while keeping the original feel. It is intended for the new or returning player who can put up with a moderate level of difficulty, but is not an elite player (Spike, I will add more sections as I have time to address all the points you raised - these are the ones I had time to research and think about with your feedback).

== Game Version ==

There could be a problem in that the publicly available version of the game is the DOS version released by Steam. The Windows CE version is arguably no longer in the public domain, since Steam now has made its version available. At this time, only one site I can find is still offering downloads of the Windows CE edition. It could be considered the Windows CE edition is no longer "abandonware", and this seems to be the view that the operators of download sites are taking. Therefore, if looking for a reference edition, maybe we should look to modding the Steam, DOS, edition. The problem is that Seb76's loader only works on the Windows CE edition.

I think we should go ahead and define the features of a "standard edition" anyway, but the problem of what version to use will still need to be solved. Basically either the fan community (us!) extends Seb's loader to also apply to the Steam DOS version, or we need to use another tool to patch the DOS version. In theory, XcomUtil could be used to patch the DOS version to introduce all of Seb's additional patches. It is arcane to use but it could be done. The key first step would be to establish a list of patches for the DOS version that are equivalent to Seb's patches to the Windows version.

:Both the Steam and GamersGate (according to forums on the latter) downloads include the Windows version. Specifically, they have a "UFO Defense.exe". I have tested the described mod set with Steam. Steam launches the DosBox DOS version by default through the steam interface, but once you create the shortcut as described, you never use it again. Does that alleviate this concern? [[User:Xeucom|Xeucom]] 09:30 August 23, 2009.

:: You are right! I tested it and, to my surprise, it works. I guess the Steam version must be the Windows CE version, even though it launches it via DosBox. Cool, so there is no problem there - quite the contrary, if all these mods work on the Steam distribution that's excellent. And maybe we can persuade Steam to distribute the "standard extended" version some day. Perhaps not, as we are sort of bypassing their security. Normally when you try to start the executable it should chain back to all the Steam software. In this case, I think we get by that because Seb's loader treats the executable as sort of a data file, loading it rather than directly executing it from the O/S, and also the loader controls the entry points itself (guessing?). Anyway, I suspect Steam don't really care too much about software protection on the old XCom games. [[User:Spike|Spike]] 06:49, 24 August 2009 (EDT)

== Categories ==

Group all fixes into categories:

=== Bug Fixes ===

==== General Bug Fixes ====

All undisputed bugs should be fixed here.

[Bug Fix]
Pay For Dirt=1
Phantom Radar=1
Base Disjoint=1
Radar Stacking=1
Base Facility Dismantle-Construction Crash=1
Collectors Edition Blaster Bomb Bug=1
Proximity Grenades=1
Proximity Grenades Experience=1
Door Jam=1
Personnel Overflow=1
Funky Fire=1
Displayed Base Maintenance Cost=1

[OBDATA.DAT]
Apply=1
;Make grenades indestructible to allow stacking several explosions
Grenade Resistance=255
Proximity Grenade Resistance=255
High Explosive Resistance=255

==== Technical ====

Audio/Video bugfixes or tweaks and other things that some experience, some do not, depending on their platform. Should all be optional and to be set up by the end user. (Possibly video pitch should default to 1, since if it's not enable it can be hard to recover from the screen crash? Which might put users off the "standard extended" package?)

[Bug Fix]
Video Pitch=?
Intro Sounds=?
Music Change Freeze=?
Tactical Scroll=?

[Mod]
HQ4x=?
D3D=?
Scale Mouse=?

[Music]
Apply=1
Source=MP3
;Source=PSX CD
CD Drive=F
MP3 Folder=mp3
Battlescape=*Battlescape*.mp3
Start Menu=*Final Briefing*.mp3
Bad Ending=*Final Briefing*.mp3
Good Ending=*Dogfight*.mp3
Geoscape=*Geoscape*.mp3
Dogfight=*Dogfight*.mp3
Mission Debriefing=*Debriefing*.mp3
UFO Assault=*Briefing1.mp3
Base Defense=*Briefing2.mp3
Base Attack=*Briefing1.mp3
Mars=*Debriefing*.mp3
Terror Mission=*Briefing2.mp3

==== Closed Exploits ====

We ''might'' want to make it optional to close exploits and make that separate from bug fixes. The difference being that bug fixes help the player or are neutral, whereas closing an Exploit by definition makes it relatively harder for the player. Personally I don't like to encourage the use of exploits, but it's an option.

(For now the exploit-closing features have been included in other sections)

:My opinion is that all obvious (in the sense that it is clearly not balanced, not that it is easy to find) exploits should be closed in the standard config. If a player stumbles into an exploit, they can become frustrated because the supension of disbelief and challenge is lost. The game ends up simply looking inconsistent. - [[User:Xeucom|Xeucom]] 19:11 August 25, 2009.

:: I completely agree. You will get some people who routinely rely on certain Exploits, who might not agree. But then they can always change the config file. Probably the most frequently used Exploits are - [[ExploitsA#Free Wages|Free Wages]], [[ExploitsA#Free Manufacturing|Free Manufacturing]], [[Known Bugs#Funky Fire|Funky Fire]], Access Alien Inventory. The [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Robotic Research]] exploits are infrequently used but are massive and should definitely be closed down. [[Exploiting Mind Control#Access the Alien Inventory Screen|Access Alien Inventory]] is arguably not an exploit but merely enables "What The Designers Intended". After all, it seems logical that XCom Psi Troops should be able to access a victim's inventory, just as alien psi attackers can do. It's not in itself unbalancing (or, not any more than Psi itself is). In fact for aliens with only built in attacks it's kind of necessary to make Psi useful on those aliens. It only really becomes unbalancing through the use of [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]. Exponential Mind Control should probably be closed as an Exploit, but I'm not aware of any existing patch that closes it (other than by disabling Access Alien Inventory, which as I've said here is probably not justified). [[Exploiting Mind Control#Zombie's Permanent Control of Aliens via Stunning|Permanent Mind Control]] and the [[Exploiting Mind Control#Resurrect Zombified Agents|Zombie Resurrection]] techniques should also be closed down. [[User:Spike|Spike]] 07:44, 26 August 2009 (EDT)

::[[Tactical Exploits#Elevator Shielding|Elevator Shielding]], which enables risk-free [[Tactical Exploits#Milking Alien Bases|Alien Base Milking]], should also be closed, but again I'm not aware of any fix. [[Grenade Relay]]s, and all similar [[Grenade Relay#Relaying other Equipment|item relays]] - any tactic which allows one item/weapon to be used multiple times per turn by passing it through the hands of multiple soldiers and thereby applying more than 100% TUs to it - are minor and not really important to close down, even though they are a bit silly. [[ExploitsA#Infinite Fuel|Infinite Fuel]] is not so destabilizing as to need closing down as an Exploit, but it probably should be closed just as a bug. [[User:Spike|Spike]] 12:00, 26 August 2009 (EDT)

=== Convenience Features ===

These are logistic or interface enhancements that have a neutral impact on game balance. They should be included by default (unless there is controversy over a particular fix).

[Equipment Screen]
Show Stats=1
Weight=Weight>
Accuracy=Accur>
Reaction=React>
Psi Strength=P.Str>
Psi Skill=P.Skill>
Show Grenade State=1
Primed=primed
; Save Equipment is currently buggy but hopefully will be fixed soon
Save Equipment=0
Auto Flares=1

[Mod]
Save Reserve Mode=1
Rank In Inventory=1
Skip Intro=?
Base Building Stacking=1
Force Language=?
Reorder Soldiers In Crafts=1
De-equip Crafts=1
Assign All Personnel=1
Fast Base Defenses=1

[Battlescape Shortcuts]

[Geoscape Shortcuts]

=== Designer Intent ===

It's sometimes hard to agree designer's intent, but where we agree we should include these.

[Mod]
TFTD Doors=1
Stunned units KIA=1
More Smoke=1
; maybe reduce stun damage from Launchers but otherwise OK:
Stun Fest=1

However if these mods also affect game balance we should think long and hard. Possibly add a subsection:

==== Designer Intent but changes game balance ====

[Bug Fix]
; This makes the game a fair bit easier for XCom, also makes the game less interesting by eliminating any need for regular craft
Elerium-fueled Craft Bug=0

=== Alternate Scenarios ===

Features to permit different ways of playing the game, but not necessarily making it harder.

; Makes recoveries much more fun. Although gives more
; information than you would normally get, it is a very
; minor advantage and worth the compromise to original.
[Wreck Analysis]
Apply=?
Zone Discovered=Intel found out that the %s UFO was raiding %s
Mission Discovered=Inspection showed that the %s UFO was on an %s mission
Both Discovered=Ship investigation revealed that the %s UFO was on an %s mission in %s

; Makes it too easy to find scouts and crashing this often
; does not make sense given alien technology level.
[Roswell]
Apply=?
;Terrain names
Jungle=Jungle
Farm=Farm
Mountain=Mountain
Desert=Desert
Polar=Polar
;Dialog strings
Title=UFO Incident
Info=Crash reported
Location=LOCATION
Type=TYPE
Terrain=TERRAIN

; Needed to complete the game if not allowing any UFO detection
[Mod]
Keep Base Navigation Modules=?

; This makes the game easier but something similar is widely used by experienced players via XcomUtil
; Starting with such a badly designed base is frustrating and modifying the base every time gets boring.
; Starting with a well-designed base could be a good education for starting players.
[Initial Base]
Apply=1
row1=HangarTL HangarTR HangarTL HangarTR HangarTL HangarTR
row2=HangarBL HangarBR HangarBL HangarBR HangarBL HangarBR
row3=AccessLift Empty Empty Empty Empty Empty
row4=GeneralStores LivingQuarters SmallRadar Laboratory Workshop Empty
row5=Empty Empty Empty Empty Empty Empty
row6=Empty Empty Empty Empty Empty Empty

; Another enhancement that is often used via XcomUtil, on the basis that HE Packs are "otherwise useless".
; But many players think HE Packs do have a role. And being able to blow arbitrary holes in UFOs makes it much easier for XCom.
[OBDATA.DAT]
Apply=?
;Make HE packs capable of breaching UFO walls
High Explosive Damage=200

; For playing on even when the situation is hopeless
[Hack]
No Score Game Over=?

; This overpowered weapon makes the game easier but is loads of fun!
[Mod]
Heavy Laser=?

; For people who think a grenade has a fuse that you light with a match ;)
[Mod]
Hot Grenades=0

; Makes the game easier. This is not necessarily a bug, it could reasonably be understood as an intended feature.
[Bug Fix]
Transfered Crafts Refueled=0

; Very convenient for XCom and unbalances the resource side of the game in XCom's favour. Arguably unrealistic.
[Mod]
Crafts Always Ready=0

=== Making The Game Harder ===

Features to increase the level of challenge. Actually this may often overlap with the previous category of Alternate Scenarios. The distinction would be that these features '''always''' make the game harder, whereas the previous category are to help the player when the player '''voluntarily''' plays in an alternative way (which, probably, is a way of playing that makes the game more challenging)

[Mod]
No Funkers=0
Bloodthirst=0
Limited Military=0
Funding Council Income Only=0
Surrender Defence Missions=0
Disable Base Defenses=0
Initial Alien Bases=0
Retaliate Against Ground Assault=0
No Blaster Bomb Drift=0
More Reaction Fire=0
Alien Inventory=0

[Range Based Accuracy]
Apply=0
Minimum Efficiency=50
Snap Penalty Distance=30
Auto Penalty Distance=14
Orange Cursor Threshold=95
Red Cursor Threshold=75

[Line Of Fire Check]
Mind Control=0
Panic=0
Mind Probe=0

[Caps]
Apply=0
Time Units=80
Health=60
Strength=70
Energy=100
Reactions=100
Firing Accuracy=120
Melee Accuracy=120
Throwing Accuracy=120
Psi Skill=100

== Specific Feature Discussions ==

=== Range Based Accuracy ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - If you accept that the role of the standard config as being for the standard player, increasing difficulty for the experienced player would not by itself merit inclusion in the standard config. Things we add to the config to make things more challenging for the elite players might belong in a special 'superhuman plus' config file. Also, the official strategy guide and [[Firing_Accuracy_Testing|information]] on this site suggests that range is already factored into weapon accuracy and fairly balanced. In play, the anecdotal feel is that range does matter.

: Range does matter though only in so far as misses are less likely to accidentally hit at longer ranges. This fix actually reduces the chance of a purposeful hit at longer ranges and increasing the distance penalty for snap fire and even more so auto fire. It could perhaps be better explained! [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: My vote is that this is a Making The Game Harder feature. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

Ranged Based Accuracy doesn't sound like something that directly increase X-Com's difficulty. Doesn't it affect aliens too? If it doesn't, it should. --[[User:SnowJob|SnowJob]] 22:07, 5 July 2010 (EDT)

=== Mind Control Requires Line Of Sight for X-COM Squad ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - See standard config intent and superhuman plus alternative config concept above on difficulty argument. It doesn't seem like physical objects should block mind control in the fictional sense. Also, aliens are able to use it without line of sight (except for seeing the first X-COM soldier). I may be a bit confused here, though: Does the alien squad have to have line of sight on at least one X-COM soldier to be able to use mind control in turns after the aliens first spot an X-COM Soldier? Also, does enabling this make the X-COM soldier who is wielding the psi-amp have to have line of sight on the alien that soldier is going to target?

: Yes the alien squad needs LoS on at least one soldier at some point in the turn. But the same restriction already applies to XCom. I agree this can be put in the superhuman plus category. Not sure of the details of how it works. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

=== Retaliate Against Ground Assault ===

[[User:Spike|Spike]] - Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

[[User:Xeucom|Xeucom]] - I agree with you. Aliens behaving smarter and more logically improves the gameplay experience even if it slightly increases difficulty. I think anything that improves the AI reasoning belongs in the standard config as long as the AI is adhering to fog of war principles. I will enable this in the next standard config ini.

=== Blaster Bomb Drift ===

[[User:Spike|Spike]] - Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

[[User:Xeucom|Xeucom]] - Are you sure that drift only affects aliens? If so, is the blaster bomb overpowered without the drift? As far as I can tell, a direct or close hit from a blaster bomb is guaranteed death for a X-COM soldier, no matter the experience or suit. Would it be better to introduce blaster bomb drift to X-COM firings instead of removing it from the aliens? This seems like one of those random parts of the AI that makes them a little more unpredictable and therefore believable to me. I was reading a story on one of the missions-gone-wrong threads in the forums and an errant blaster bomb firing by the aliens really helped create a funny story.

:Agreed let's confirm that drift only affects aliens. Maybe this could go in Making The Game Harder. Blaster Bombs are terribly lethal so the alien drift is often a lifesaver. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: It's pretty obvious (from StrategyCore old posts, not personally verified) that drift affects XCOM as well; it's why you have to be careful when using a blaster bomb launcher from the Skyranger/Avenger entrance. [[User:Zaimoni|Zaimoni]] 10:21, 25 August 2009 (CDT)

::: OK but in practice this only affects the aliens, since the AI is too stupid to take precautions, whereas players quickly learn to allow some leeway. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Stun Fest ===

[[User:Spike|Spike]] - I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

[[User:Xeucom|Xeucom]] - Do you know that the original game manual has a screenshot with a 'Hit' option for a rifle? Therefore, I agree with you on intent of developers and that there should be a 'pistol whip' stun option for all/most weapons (or empty hand). However, the table at [[User:Seb76|seb's page]] suggests that the weapon values are not less than the stun rod in every case. It seems out of whack (no pun intended) for the missile launcher to do more stun damage than the stun rod, or even more stun damage than a rifle. It would be so bulky it would be harder to beat an alien with that than a pistol or rifle. So my vote is yes for (non-ranged) stun damage for non stun rod weapons, but I think we need to figure out the right balance for stun damage before adding it to the standard config.

:There are definitely some wacky hand to hand damage levels in the executable, normally unused, but I thought that Seb had overridden those values to more sensible levels. I'd better check. :) 04:47, [[User:Spike|Spike]] 04:49, 23 August 2009 (EDT)
::I checked and I would still say "less effective than a Stun Rod in every case". Though the Launchers do get a higher base damage than the Stun Rod, they can only attack once per turn and will use HTH accuracy instead of an automatic hit. Bludgeoning an alien with a weapon is always an act of desperation and less effective than a Stun Rod. But loads of fun and very atmospheric![[User:Spike|Spike]] 13:27, 24 August 2009 (EDT)

:::I see your point when you take into account the Time Units and the accuracy. You convinced me that it belongs in the standard config. [[User:Xeucom|Xeucom]] 18:30, 25 August 2009 (EDT)

=== Elerium Fueled Craft (Bug?) ===

[[User:Spike|Spike]] - While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

[[User:Xeucom|Xeucom]] - It just seems artificial to me that non-elerium craft return home when they are going to have to ditch if they don't, but the elerium craft turn around and head back at an arbitrary fuel level. What would the fictional explanation be? I understand your point about amping up difficulty, but for the standard config, I think consistency is more important. Inconsistency between craft behavior just looks buggy. There are other ways we could increase difficulty that would be much more impactful.

[[User:Spike|Spike]] - Agreed, it disturbs realism and consistency and jars the player experience. That's more important than a slight imbalance. I believe the conventional craft can still stay on station longer than Elerium craft, even with this bug fixed?

=== Craft Always Ready ===

[[User:Spike|Spike]] - I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

[[User:Xeucom|Xeucom]] - I have played with this on and think it is possible you may think that this does more than it does. The only thing that it allows you to do is to dispatch interceptors when they are rearming, refueling, and repairing. It doesn't put them back to 100% loadout, fuel, and integrity. So I think it is still balanced because you are limited to the full refits unless you want to scramble interceptors that only have a short range, or no arms, or are already damaged. I realize that normal rules of procedure would not be to relaunch until total refit is complete, but why not leave it up to the player/commander? In a desperate situation, I think any real-world air force would launch anything in whatever condition it is in and what can be more desperate than fighting aliens? :) Also, X-COM from a fictional perspective is a very odd entity. Some could view it as a professional military alliance of the other powers, but given how little you get and how poorly funded it is (and how you can be shut down by your creditors), it smacks more of a private mercenary corporation whose operational procedures may be largely ad hoc.

[[User:Spike|Spike]] - Agree most of those points. This is only slightly more powerful than just leaving the interceptor in the air on patrol after combat. (It's slightly more powerful because you do get to refuel/rearm while waiting for the next target.) The imbalance I'm talking about is that it makes it possible to maintain one interceptor per base instead of needing two. This has a biggish effect on your cost base early in the game. If there was a balancing "side effect" of launching with low fuel / weapons / repairs, I would be totally happy. As it is, I guess it's not too badly unbalancing.

[[User:Zaimoni|Zaimoni]] - You still need two Interceptors per base to conveniently shoot down Terror Ships before Plasma Cannons, or to conveniently shoot down all non-Battleships in the acts with finales (Infiltration, Base) with Plasma Cannons.

::I've been experimenting with this and I think my opinion has flipped on it. I think craft that aren't fully refueled should be able to take off, but a craft with damage shouldn't. The reason is two-fold. Firstly it makes sense. While you can stop refueling an aircraft and launch it relatively quickly repairing an aircraft would be a whole other story. Except for very light damage you would have to dismantle parts of the aircraft and it simply would not be possible to fly it in such a state. Secondly, it removes all threat from shooting down battleships. Without this mod battleships are always a threat because even your best aircraft can get damaged and put out of service for quite some time. This leaves you having to decide whether it's worth the risk or if you should let it land or use secondary interceptors and cluster them in hopes of minimizing damage. But with this mod it completely alters this dynamic. You no longer have to worry about craft being taken out of service at all. You just launch away. As long as your Avenger's damage isn't too high they can take out a battleship single handedly with dual plama beams and probably have enough time to repair before the next one. In the meantime they can still kill all other UFO's with impunity even if they have 99% damage. I think it changes the game too much to keep it on as is.[[User:Mannon|Mannon]] 23:47, 4 April 2011 (EDT)

=== Base Navigation Modules ===

[[User:Spike|Spike]] - Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

[[User:Xeucom|Xeucom]] - I agree with you and will also include this in the next standard config file. My only discomfort is the explanation of why there are navigation modules at a base, but let's rack that up to spares in hangars.

: Actually in the unmodified game, the base control consoles (destroyed to win the base mission) are Navigation modules. The patch simple captures them intact, instead of destroying them. Equally, we could imagine there are some spares in the base stores. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Modified Initial Base Layout ===

[[User:Spike|Spike]] - Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

[[User:Xeucom|Xeucom]] - This makes sense to me, so I think this should go in the standard config as well. I think the key point you made is avoiding tedium for the player - features that do that without significantly unbalancing should probably go in standard config as matter of course.

=== Base Building Stacking ===

[[User:Spike|Spike]] - Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

[[User:Xeucom|Xeucom]] - My only qualm here is that this seems like a complex feature from a programming perspective that could be risky. Have you played with it a lot and not noticed any increase in crashes or bugs with bases? It doesn't really add anything except being able to lay out the facilities in game sooner - you could still get the same facilities in the same amount of time just waiting for completion messages. The other thing I note with this is that if you turn it off on a game where you have laid out some to-build facilities, bases get funky in with 255 overlayed n the extended modules instead of "Queued". However, for the standard config, I think we should assume that the player will play through the entire game without changing the settings, because otherwise trying to figure out all the possible scenarios would become overwhelming. If you are satisfied that this does not introduced bugginess, I could go for it for the standard config.

[[User:Spike|Spike]] - Well that is a fair point. I have not used the feature enough to swear there are no bugs. Maybe it is safer to leave this as an optional thing that people can enable if they want to.

=== Assign All Personnel ===

[[User:Spike|Spike]] - Highly useful.

[[User:Xeucom|Xeucom]] - I didn't add this to the initial standard config because I don't understand what it does. Can you explain? Also, is it helpful enough to merit the increased risk of negative side effects (crashed, other bugs) when its complexity is considered?

[[User:Spike|Spike]] Basically in various screens this lets you hit the down arrow when the counter is at zero, and the counter goes UP to the highest possible value. This saves you from having to scroll up from 0 to say 100 Scientists, 100 Engineers, etc, whenever starting a new research or manufacturing project. The scrolling speed can be very slow, depending on your machine. This is a very simple mod so I would expect it to be bulletproof from a bug point of view.

[[User:Xeucom|Xeucom]] - Let's call it in for the standard config, then.

=== Save Equipment ===

[[User:Xeucom|Xeucom]] - Spike, I saw that you mentioned in the settings above that you had Save Equpiment turned off because it was buggy. Could you explain? I have used it for some time in my current game and it seems to be working ok. There are some strange things where I am not able to extend the ground portion with the right button and sometimes when I assign a weapon to a soldier it doesn't appear in their hand until I click on one of the slots again. However, I have not verified if this happens with/without UFO Extender or the Save Equipment setting. Since the standard config should aim for bug free, if you think have observed bugs, we should probably leave it out until it is more stable.

: Agreed. There are definitely known bugs with this feature and it is currently described as "Highly Experimental". But once it's working reliably this is a top candidate for inclusion in the standard configuration. [[User:Spike|Spike]] 19:32, 29 August 2009 (EDT)

=== Funky Fire ===

[[User:Spike|Spike]] - This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

[[User:Xeucom|Xeucom]] - The way I understand this it is that the smoke and explosive damage end of turn checks were probably getting applied every time an incendiary shell went off. I think seb76 simply stopped that from happening so that only the entities inside the incendiary shell blast radius took damage and then he increased maximum fire damage from 5 to 10 to compensate for a possible lower fire damage value the original developers put in to offset the bug. From my personal observations, it seems to me that smoke damage is too low and should probably be raised as well because units can spend a lot of time in it without passing out, but that's just an opinion. For the standard config, it sounds like we are in agreement to leave it in because it makes no sense for explosions in other areas of the map to affect other units.

: Yes the illogical behavior is fixed & that's good enough reason to include this fix. My understanding of the fix is that smoke/fire effects only occur at end of turn. This reduced the power of Incendiary weapons a lot, even if not using the Exploit. To partly compensate, Seb has doubled the average damage from fire. There's no exact way to compensate but this is a reasonable approach IMO. [[User:Spike|Spike]] 19:25, 29 August 2009 (EDT)

:: [[User:Xeucom|Xeucom]] - With the fix enabled, if I hit a sectoid with three incendiary shells in one turn, will I do no damage to the sectoid until the turn ends? Or will the sectoid take hit damage (of incendiary type?) on each hit, but no general fire damage from being in a fire square until end of turn?
::: Fire damage will only be applied at the end of the turn. That's why I buffed fire damage up a bit. [[User:Seb76|Seb76]] 13:52, 30 August 2009 (EDT)
:::: In our investigations, we deduced that the so called "incendiary impact damage" is itself an aspect of the bug. And it makes sense that incendiary damage should not take effect as promptly as a bomb,a bullet or a plasma beam. But this does change the play of the game. I don't think it makes much difference apart from people who were exploiting the Funky Fire exploit. But if there was anyone out there who was consistently firing multiple IN rounds at single targets, one at a time, their game play experience will change with this fix. I think it's worth at least a note that this is not just a bug fix but also includes some unavoidable changes in game play. [[User:Spike|Spike]] 04:14, 31 August 2009 (EDT)
::::: This would explain why once when I was facing off against sectoids I had a couple units with incendiaries (night mission, using them to light the place up) and unloaded on a sectoid. After the sixth shell on target, I was like, "Why won't you die!?" Now I understand. However, I think the behavior with Funky Fire makes the most sense because you don't get the random effects from other areas of the map and, really, if you pour a flammable over something and get it coated pretty well, adding more flammable isn't going to really do more damage, so stacking six incendiary shells in an area shouldn't necessarily do more damage to a unit there, just make the fire bigger, which happens naturally anyway because of the deviation in the squares hit. Not quite realistic, but seb76's uptick in fire damage is a fair compromise I think. [[User:Xeucom|Xeucom]] 11:47, 31 August 2009 (EDT)
What are the effects on Zombies? [[User:Magic9mushroom|Magic9mushroom]] 09:55, 1 September 2009 (EDT)

=== Aliens Take Fatal Wounds Damage ===

[[User:Xeucom|Xeucom]] - Saw seb76 made a new release with some new options, so of course have to discuss them for the standard config. :) Starting with this one, this one is a tough call. It's more realistic that aliens could also have fatal wounds. On one hand it makes game easier because injured aliens will die even if they move out of sight and quicker in general if taking damage from fatal wounds. On the other hand, makes game harder because of difficulty capturing live aliens (stunned aliens with fatal wounds likely to die). Can aliens be healed of their fatal wounds with a med kit? If so, introduces entertaining mini-game when trying to capture an alien where you have to stabilize it if injured, perhaps in conjunction with stunning it. A perhaps significant balance problem that arises is X-COM team can have medics with med kits who will heal injured team mates. I suspect this change comes without changes to AI, meaning that aliens will not use med-kits to help each other out. Thoughts?

: I would guess the small number of extra kills from wounds is well-balanced by the scenario you describe, the difficult scenario of trying to stabilise a wounded captive alien, or rush him to the transport before it dies. As this is a new fix we might want to be sure that the alien's death from wounds is handled normally - that correct points are awarded, the game ends properly, etc. Also what happens when a wounded being swaps sides during and after mind control. But (subject to that testing?) I think this one should be included. [[User:Spike|Spike]] 08:50, 1 September 2009 (EDT)

:: The question becomes how do you know you need to stabilise the alien? I can see two ways. First, the mind probe will show you that a standing alien has fatal wounds that you will need to heal once you stun him. Secondly, if medi-kit works on a stunned alien (that's a big if), the display would show you the area hurt (though this may not make sense since I don't think all the aliens are humanoid). I guess this could use some testing to see if the fatal wounds show on mind probe, if you can heal an alien with a med-kit, etc. I like that it opens a new storyline - having to rush the Snakeman Commander to the evac point before he dies, perhaps involving a medic meeting you half way. [[User:Xecuom|Xeucom]] 18:02, 1 September 2009 (EDT)

::: I tested most of the main considerations and they check out OK - see [[User talk:Seb76#Alien Bleeding|here]]. I wasn't able to test the Mind Probe, but you can use the Medkit itself to determine if an aline has any wounds that might need treating. But yes the Mind Probe would be better, since it gives the Health as well, so you can calculate if the alien will die before you can complete the mission. I really expect the Mind Probe will work, since it does normally show the Wound level of aliens - it's just usually always zero. [[User:Spike|Spike]] 20:36, 2 September 2009 (EDT)

=== Unarmed Aliens Pick Up Weapons ===

This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. It would be a very helpful rebalancing of the game that eliminates one of the aliens' weak spots. [[User:Spike|Spike]] 14:44, 3 April 2011 (EDT)

== probability of hit display ==

It would be great if next to the crosshair there would be a percentage indicating the probability of a good hit like in UFO Extraterrestrials.

== May i remake the main page of this article ==

Sorry im new to here so i dont know if i should do it right away or asking someone is polite beforehead or it should be left as is and instead second artice should be added, but:

I have thoughts for current page "Enemy Unknown Extended"
I am willing to write another article, correcting the following:

1) Recently, Xcomutils 6.7 have support for ufoextender. This means, among others, that we no longer need those patches since xcomutils applies them all! It even applies voices and old sounds (more than voices!) but you have to run setup again
2) The supplied INI is old and doenst have every key that new ufoextender uses. This should be avoided imho as the person who dl's it has often litte knowledge to find the hidden options (have to look at the page at this site) or add it (have to copypaste strings from original ini which isnt convinient)
3) For some people (inc me) mp3 solution wont work, for them an explanation how to use PSX Cd would be nice.

Therefore, i'd like to make theese changes:

1) Overview - add that recent 6.7 xcomutils beta build supports ufoextender and so we can use EU+Extender+Xcomutils for a very rich enchanced gameplay
2) Download - remove patches and ini, add xcomutil
3) Verify - accordingly to 2
4) Modify - change to "Patching process" or something as for me, modify isnt that obvious, and then, write here an exact series of steps needed to configue them to work
5) Make shortcut - change to use runxcom.bat

Then i'd like to add "If usage of mp3 causes game to crash" or something with explanation how to use psx cd for music instead
[[User:Istrebitel|Istrebitel]]

:This is a Wiki so everyone can edit anything. But thanks for asking first, that is considered polite, especially before modifying an article page with something that might be seen as a matter of opinion. Could you maybe post your proposed new text here on the Talk page? Also, please sign your posts with 4 tilde characters (~). [[User:Spike|Spike]] 14:39, 3 April 2011 (EDT)

<strike>:I'm a little confused here. You say that XcomUtil 6.7 has UFOextender support, but the lastest version available on the XcomUtil Homepage is XcomUtil 9.60 and I can verify that it very much does not work with UFOextender without some modding to recombine geoscape.exe and tactical.exe back into a single executable since UFOextender crashes if you try to use it to load tactical.exe. Scott's homepage does mention handing over control, but it only gives an email address.[[User:Mannon|Mannon]] 18:21, 3 April 2011 (EDT)
:Another concern is XcomUtil by default makes several changes to the core game, in particular it alters the crafts, making them hold more soldiers. It goes so far as to change the craft's map files (I hate the Avenger, it no longer looks like the UFOpedia entry, but like a fat flying brick.) It even makes the interceptors capable of carrying soldiers. There is no option to turn this off without altering XCUSetup.bat or at least editing XcomUtil.cfg and doing something to fix the Avenger map. I'm not sure how to make those changes easy for someone short of supplying them with an alternate XCUSetup.bat and/or XcomUtil.cfg. Though there are definitely some nice benefits to having XcomUtil installed.[[User:Mannon|Mannon]] 18:29, 3 April 2011 (EDT)</strike>
::Oh NVM. I see that you meant 9.7. I found it and will have to give it a look.[[User:Mannon|Mannon]] 18:43, 3 April 2011 (EDT)

User:Mannon

2011-04-04T13:47:09Z

Mannon: /* The Clock */

=About Me=

Total Dork... ;p

I'm a detail oriented, methodical, obsessive geek that absolutely LOVES X-Com.

==Introduction==

I originally came to the game because I purchased a magazine with a floppy disk of the TFTD demo. (I still have the disk.) I played the demo with no prior knowledge of X-Com or tactical games at all and was instantly hooked! Of course, having zero exposure to such games initially I found it to be just about the hardest damn game I ever played! lol

I did not have the internet or friends that played the game so I learned the hard way... I played that single mission over and over, obsessively, until I mastered it. (Pretty much until I could do it in my sleep, heh.) I even developed my main tactical strategy that I still use to this day on that demo mission. It's something I think of as The Clock.

Later I found X-Com on the shelf and wanting to start from the beginning I had to have it! I was totally surprised at the strategic metagame and all it's implications. That's when X-Com went from great demo to one of my all time favorite games, and it remains so even now. To date I still prefer X-Com over every other tactical game I've played, though I actually hesitate at playing them because I've yet to beat X-Com. ;p (Did I mention I'm obsessive?)

==You haven't beat it! What kind of a fan are you?==

Yeah yeah... Just because I haven't beat X-Com doesn't mean I haven't played the hell out of it. In a sense I refuse to beat it because I'm not done playing it. heh heh I probably could take an avenger up to Cydonia and manage to beat the game. I'd be weak vs Psi so it might take some doing. But I've faced Ethereals and beat them. (Actually once I've beat the game I may come back to an old save and see if my non-psi using squad can do it, just for fun.)

Okay, here's the longer explanation... First off, I'm sentimental and nostolgic... What does that mean? It means I'm still using most of the same soldiers I've had from the beginning of the game. The very first squad I had. Some of these have been with me from the start, like my ultimate soldier Barbara King who got cheeted out of being commander by an unfortunate savegame mishap. (She was my first commander, but I lost the save and next time around it was Dmitri Maleeve. I had to do some finagling to get her back in the job. heh) So, anyway... I haven't been too keen to start a fresh game.

I also initially made an error that cost me quite a bit. You see I hate the mind probe. It's big, and bulky, and you have to equip it which basically takes one guy off the front lines while he's using it, so it's a huge TU sinc. So when I was capturing aliens for research I was basically just stunning whoever I could get and letting the chips fall where they may. I was also unaware that certain aliens hung out in certain places. Hey, at the time everything was going great anyway and I didn't really need more research projects, but I bet you can guess where this is leading.

Eventually I started to wonder what I'd done wrong, because I still couldn't build a Psi Lab and it didn't seem to matter how many more aliens I researched, either. What I needed, of course, was either a Sectoid Leader, or Commander. So I started looking for the bastard. Let's just say I had quite poor luck finding one, particularly because Sectoid UFO's were becoming quite rare as the Mutons took up the war effort. It was extremely frustrating. I was stuck in that phase of the game a long time, fighting all my battles the old fashioned way.

The upside of that is I learned a lot. I learned that Power Armor, while good is NO replacement for Flying Armor, even if you don't fly. I learned to whip my soldiers into shape so they could all carry Heavy Plasmas. And I learned how to fight cautiously even if it took longer.

Somewhere along the way I also decided to end my age old practice of loading a previous turn if I lost a soldier. I HATE losing soldiers. I don't care what the mission briefing says if I lose even one then the mission was not a victory, it was at best a draw. (Though my opinion on this has been somewhat modified and I now consider rookies as semi-expendable. In other words I still feel bad for their families, but but the squad has about 2 minutes of silence when they get home before cracking open the beers and celebrating their victory, and that's about it.) I eventually decided it was holding me back to always revert like that, on top of being semi-cheating IMO. It's certainly not breaking the game, but it does make a difference.

Let me go into that a sec... If you've never played X-Com without allowing your soldiers to die in combat then you probably will not fully appreciate the difference. I did not. I never allowed it to totally corrupt the way I played. I didn't send soldiers on suicide scouting runs, for example. The problem, however, is on what happens after the soldier that would have died, doesn't. You may not have intended it to be a suicide scouting, but it was, and now you know exactly what not to do. Even if this is infrequent it still colors the game. The other major thing I noticed was that it made me play far more cautiously ON EVERY SINGLE TURN, because the price of a wrong move is just too high. It changed my reaction from "Ooops! Guess I should have used a grenade." to "OH S#$%! F&$# NO! Nooooooooo!" followed by more cursing. ;p That may not sound like a good thing, but it is. It makes you care more about the results. It makes those soldiers lives more precious and the aliens more scum sucking evil pricks! lol I actually hate the aliens now, I can't help it. They have wounded me and I hate them, but I love hating them. Giving the aliens the ability to hurt me instead of just being targets has transformed them into a much better and scarier enemy. It made all the difference.

Anyway... back on topic...

I also tend to be pretty scatterbrained... I got the ADD and I move from project to project, without finishing them between. So it is sometimes years between sessions of me playing X-Com, complicated all the more by the need to reinstall it and make it work on a yet faster computer. heh heh

I also really want to ramp up. I want my coverage to be dominating and my soldiers powerful and fully equipped and trained before I goto Cydonia to finish off those bastards. I'm not done playing X-Com, not at all. Eventually, but not yet. When I'm finally ready to move on I'll take out Cydonia and let Barbara King fire the final shots that end the war. Until then I'm going to build out my bases, hire and equip an army of soldiers and kill all the aliens I see.

When I'm done with that, who knows... Probably start over on Superhuman and/or begin TFTD. Those games will probably progress more easily given my much expanded experience.

==Birdwalking==

"Birdwalking" is a term I learned from my 4th grade teacher and it so aptly describes what I do that it's stuck. Ever watch a bird pecking around? They go here and there and see something interesting over there and stop here and try that, never moving in a strait line from anywhere to anywhere else. Well (obviously) that's how I tend to talk and write... probably due to my ADD. *shrugs* Anyway if I get off topic just bear with me.

=Gaming=

==Strategy & Tactics==

===The Clock===
The clock is just how I think of my clearing tactic. It's a very specific process I actually developed playing the TFTD demo before I had Xcom and then had to refine while playing Xcom.

1. View Perimeter by having soldiers turn to look out windows (if necessary).

2. Find nearest edges of the map. (If your soldiers can't see it then just find where it stops highlighting the tile under your mouse pointer.)

3. Begin exiting craft to establish a reaction fire perimeter. (High TU and Reaction troops do this job and use the craft it-self, it's gears, ramps, and even flying up on top of it for cover.)

4. Widen perimeter until entire craft is encircled and every angle is covered by at least two soldiers ready to reaction fire.

5. If any nearby structures pose a threat use explosives.

6. Begin to widen perimeter to any nearby logical cover that offers a tactical advantage.

7. Widen perimeter to the edge of the map. (When this step is complete you should have a more or less U shaped perimeter with your transport in the arch of the U and the edge of the map along the arms.)

8. Begin widening perimeter with two goals. A. Secure areas to eliminate possible threat vectors. (The fewer threat vectors you have the more you can concentrate reaction fire.) B. Find the UFO.

9. Upon finding the UFO carefully extend perimeter to the near side of it. This may require clearing multiple areas and buildings first.

10. If possible secure UFO exits with reaction fire and/or prox mines. It can also be handy to post some troops with motion detectors near or on top of the UFO.
(Now finally we get to the reason why I think of this as the clock. Your soldiers are now loosely arranged like the hands of a clock with the UFO at the center. And you're going to use them exactly like the hands of a clock as well.)

11. Begin to sweep one or both arms of your formation around the UFO to clear the exterior territory carefully clearing buildings and other dangerous areas as need be.
(I usually have my arms swing around the UFO and try to converge on the side with the exit/s.)

12. When the arms of your formation meet after thoroughly sweeping both sides of the UFO you have now cleared the entire exterior. (Note: The formation at this point is not necessarily centered on the UFO, but rather on its exits and possible entrances.)

13. Setup strong reaction traps for all exits and begin staging for UFO breach, although crashed craft often have holes in the roof you can snipe or toss grenades through.
(The soldiers you want to use for the breach it-self need to be able to get too and through the door with the fewest TU's expended to give them more TU's to retreat or fire as well as to increase the number of soldiers you can get into the room and firing on aliens in the same turn. Keep in mind you're going to want to kill all the aliens you can see on that turn and yet still have soldiers that can kneel with TU's left for reaction fire.)

14. Breach the UFO. If there's a hole in the roof you should at least look for opportunities to kill aliens from the roof with cover if not use it for breaching. If you have to breach through a door be prepared to have the soldier that opens the door retreat if the opposition beyond is too great. Snipers positioned further away, but able to shoot through the open door can often eliminate a few aliens as long as you can get the other soldier out of the way. You do not have to enter the craft right away. Simply open the door and shoot if you can't kill all visible aliens or get your men inside and into cover or at least good reaction fire positions.

That's a bit verbose, but oh well. I perform similar sweeps in bases a lot of the time, though they really are quite different. It's important to keep overlapping fields of reaction fire at all times if possible, and have soldiers leapfrog so that some have nearly all their TU's available for reaction firing.

Also something else you can do. if you have a hovertank then at the beginning of the mission once you've secured the immediate vicinity of your craft point it in the direction of greatest threat and send it up up up to the very top of the battlescape. From here it will have the longest view. Spin it around to get a really good view of your surroundings. You can use soldiers like this as well, but they are vulnerable while flying because their under armor is weaker and they have no cover. You CAN, however, kneel while in midair. Usually I don't have my soldiers fly up into the open, but I do send them atop my transport craft and use it for cover. Snipers go up here as they will stay up here for a long time while you expand the perimeter. Whenever you see an alien you try to kill it with one of these elevated snipers first, to leave the unit on the front line as many TU's as possible for reaction fire.

===Equipment===

I'm picky on equipment... I like to standardize things and I have a tendency to want to turn everybody into a swiss army knife. Before hitting the 80 item limit I used to stock up my soldiers pretty heavily. Every single one got a Heavy Plasma, an extra clip, a med kit, a laser pistol, and some combination of grenades, prox grenades and motion scanners. I've trimmed down since I hit the limit, but I still keep laser pistols on most of my soldiers and usually a med kit for every two soldiers. I also still have 2 to 4 soldiers carry motion scanners, they're just too useful for boarding the UFO's, though often they don't come into play until I've cleared the exterior.

Heavy Plasmas and Laser pistols are my babies. You just can't beat the HP for it's awesome combination of accuracy and stopping power. Laser pistols are my fav backup, though. They're quick and can fire tons of shots. They also don't use ammo, which makes them great for shooting out bushes or holes in barns, ect. Explosives are usually what people think of for clearing obstacles, but I often prefer being able to be more selective, plus not needing ammo means there is no cost and no threat of running out. If I really want to I can sit tight in one spot for several turns and send dozens of laser shots down range. I kinda enjoy doing that, too. ;p

I'm not big on the mind probe. It's big and clunky and a total TU sinc. But I probably should have used it more. I kinda figure it becomes more useful once you get into Psi, which I've not quite done, yet.

==XcomUtil==

A GREAT utility that singlehandedly brought be back to X-Com at one time. I wouldn't even consider playing without it now. However, I also wouldn't consider using the default setup anymore either. Luckily XcomUtil is extremely customizable.

===XcomUtil.cfg===

====Original Craft====

For some reason Scott decided to have XcomUtil modify the standard craft by default. I suppose that might be fine for a lot of people and you could just ignore the newfound abilities of the Interceptor and Firestorm. Personally, I prefer to just keep the craft from the original game. Fortunately it's pretty easy to fix by editing XcomUtil.cfg and running the setup. Mainly I don't like for the interceptor only ships to be capable of carrying soldiers. That changes the game too much for my tastes. Just search for "XCOMShips". The default stats should be listed above in comments.

====StatStrings====

I've found the StatStrings feature to be particularly useful for me, but I was certainly not satisfied with the default strings, so I designed my own. My first system was far too spendy on the number of characters it used so I scrapped it and started over with a totally different idea.

=====Stats=====

The code below opens up the NameStats portion of StatStrings. I separate it here because I chose to split up the individual strings and my class strings. Both my stats and classes fit within NameStats with classes at the end so I include it here to make it clear exactly where in XcomUtil.cfg this belongs.

NameStats
StatStrings

I'm going to describe my system in some detail here, but I'm also leaving my comments in the code in case anyone wants to try these, because it's a good idea to have the comments available in case you forget how it all works.

// New Custom StatString System!!!!

// This system minimizes space usage by using placement and capitolization to designate
// strengths and weaknesses. The basic idea is to sort the stats from least to greatest moving from left
// to right, and provide some important designators letting you know where in the string you pass a certain
// numerical threshold. The letters themselves represent individual stats. Only ? which represents zero
// psi/mc skill and C which designates a coward actually change.

// In the middle of the string I have placed three stats I consider particularly important, (TU's,
// Firing Accuracy, and Strength) as numerical representations. These three digits are placed in the
// middle to serve as a seperator.

// All of the possible designators, in order are as follows... ?CBRTKPEHbrtkp###brtkpBRTKP The letter
// for any particular stat will only appear once in the string, however. I've also made an attempt to sort
// stats within a given capitolization group, though the fidelity is pretty low. In other words if your
// reactions are significantly better than your throwing accuracy but within the same capitolization group
// you should get "tr" in the string instead of "rt". You kinda have to know what order they naturally fall
// into, to make any real use of it, but generally two stats in a row tells you that the second can't be much
// worse than the one before it. I'll add more fidelity, but I'm not going all the way down to individual digits! =O

// For now the fidelity on the sorting is every 5 units.

// Note: The inner letters are lower case to help differetiate them from the numerals, which can
// be hard to tell from upper case letters in some cases. Also keep in mind that most stats for
// most soldiers will NOT have a designator at all. The system purposefully omits middle of the road
// stats to save space. The designators, therefore are only really meant to highlight particularly
// strong or weak stats, other than the three I deemed important enough to ALWAYS designate, which
// actually display their numerical value to the tens.

// Even greater coverage could definately be squeezed in, but the intention is to keep these StatStrings
// very minimalist, while still conveying all the important information. This way you can keep longer names,
// and/or use Class designators in addition to this system. (And, why the hell not!? heh)

// Weaknesses listed first!

? k:0 // Test if they have been Psi trained.

R r:-5 // Reactions
T t:-5 // Throwing Accuracy
K k:1-5 // Psi Skill
P p:-5 // Psi Strength
E e:-5 // Stamina (Energy)
H h:-5 // Health

C b:-10 // Extra warning for COWARDS!
R r:6-10
T t:6-10
K k:6-10
P p:6-10
E e:6-10
H h:6-10

B b:11-15
R r:11-15
T t:11-15
K k:11-15
P p:11-15
E e:11-15
H h:11-15

B b:16-20
R r:16-20
T t:16-20
K k:16-20
P p:16-20
e e:16-20 // Stamina (Energy) only tested for 0 to 20 to find weaklings...
h h:16-20 // Health only tested for 0 to 20 to find wimps...

b b:21-25
r r:21-25
t t:21-25
k k:21-25
p p:21-25

b b:26-30
r r:26-30
t t:26-30
k k:26-30
p p:26-30

b b:31-35
r r:31-35
t t:31-35
k k:31-35
p p:31-35

b b:36-40
r r:36-40
t t:36-40
k k:36-40
p p:36-40

// Display the first digit for TU's, Firing Accuracy, and Strength
# dfs

// Strengths listed after weaknesses...
b b:61-65
r r:61-65
t t:61-65
k k:61-65
p p:61-65

b b:66-70
r r:66-70
t t:66-70
k k:66-70
p p:66-70

b b:71-75
r r:71-75
t t:71-75
k k:71-75
p p:71-75

b b:76-80
r r:76-80
t t:76-80
k k:76-80
p p:76-80

B b:81-85
R r:81-85
T t:81-85
K k:81-85
P p:81-85

B b:86-90
R r:86-90
T t:86-90
K k:86-90
P p:86-90

B b:91-95
R r:91-95
T t:91-95
K k:91-95
P p:91-95

B b:96-
R r:96-
T t:96-
K k:96-
P p:96- /:-

Note: The odd "/:-" is a special case. Entering a slash as a statid is meant to tell XcomUtil that this is the last required namestat. So if the soldier's name is too long after all the rest of the strings get done XcomUtil will backup to this point. What that means here is that if XcomUtil has room for just the stat indicators and not the class then it will cut off the class. Of course, this was initially more useful when my classes were longer than 2 characters. With 2 char classes it might be more useful to reverse this behavior. In order to reverse it, however, I would have to make all of my classes mutually exclusive.

=====Classes=====

Here are my classes. Each class is a 2 character string that consists of a symbol (either "^" or "*") and a letter. The symbol and the capitalization of the letter denote the rank of the soldier in that class.

My classes are not necessarily mutually exclusive. In other words if all of these were evaluated soldiers would wind up qualifying for multiple ranks within classes as well as multiple classes. It was just a lot easier to write that way, taking advantage of the fact that once a statstring longer than 1 character gets added to a name XcomUtil ends the search and no more strings are added. I've arranged my classes so that the highest rank of the best class that the soldier qualifies for will be displayed. Any others will be ignored.

The "^" I hoped would look kinda like a chevron like on military uniforms but instead it looks like an up arrow. I left it in anyway. I'll probably redo these, but I'm putting them here for reference in case it helps anyone.

The comments pretty much explain the rest about my classes so I'll leave it at that.

// Soldier Class

// I have created several classes each with four ranks within the class. A soldier can
// simultaneously qualify for multiple classes, but will only be tagged with the highest
// one in this list that they qualify for. Most soldiers should be regular army, these are
// merely meant as a way of quickly pointing out some specific combinations of stats that
// could be useful to note.
// Note: While there are only four ranks per class some ranks have multiple acceptable criteria.
// This allows one stat to make up for another in some cases.

// Commando (This class is actually a combination of Marksman and Ranger... the all around badass.)
*C f:90- d:80- r:65- b:20- s:30- e:40- h:20-
*c f:80- d:70- r:65- b:20- s:20- e:30- h:20-
^C f:80- d:70- r:50- b:10- s:10- e:20- h:20-
^C f:70- d:70- r:60- b:10- s:10- e:20- h:20-
^C f:60- d:70- r:70- b:10- s:10- e:20- h:20-
^c f:70- d:60- r:40- b:10- s:10- e:10- h:20-
^c f:60- d:60- r:50- b:10- s:10- e:10- h:20-

// Marksman (You friendly neighborhood sniper.)
*M f:90- r:65-
*m f:80- r:65-
^M f:80- r:50-
^M f:70- r:60-
^M f:60- r:70-
^m f:70- r:40-
^m f:60- r:50-

// Ranger (Recon troops... the good at it, non-expendable kind.)
*R d:80- r:65- b:30- s:30- e:40- h:20-
*r d:70- r:65- b:20- s:20- e:30- h:20-
^R d:70- r:60- b:10- s:10- e:20- h:20-
^r d:60- r:50- b:10- s:10- e:10- h:20-

// Artilleryman (Special class, good for carrying heavy weapons and throwing stuff.
// Plus brave enough not to kill the whole squad at the first sign of trouble..)
*A f:50- d:60- b:30- s:70- e:80- h:50- t:30-
*a f:50- d:60- b:20- s:60- e:70- h:40- t:30-
^A f:50- d:60- b:20- s:50- e:60- h:30- t:30-
^a f:50- d:60- b:20- s:40- e:50- h:30- t:20-
^a f:40- d:60- b:20- s:50- e:60- h:30- t:30-

// Scout (Recon troops... the expendable kind... though the top two ranks are more for a heads up on who's nearly ranger material.)
*S d:80-
*s d:70- f:51-
*s d:70- r:51-
^S d:70- f:-50 r:-50
^s d:60- f:-50 r:-50

// Washout (Ditch these guys before they get you killed!)
Wash b:-10 d:-50 f:-50 h:-30
Wash d:-20
Wash f:-20
Wash d:-60 f:-60 h:-20

The code below closes the NameStats portion of StatStrings. I separate it here because I chose to split up the individual strings and my class strings. Both my stats and classes fit within NameStats with classes at the end so I include it here to make it clear exactly where in XcomUtil.cfg this belongs.

/StatStrings
/NameStats

====SortStats====

SortStats
StatStrings

// This sort order is complex but should put important PsiSkill personnell in the rear for protection, along with cowards...
// will put Rookies in the front to get the chance to become Squaddies and then gives me a nice sort of all remaining soldiers.

# +k-d-r+f // Sort in ascending order by PsiSkill, descending order by TU's, and Reactions, then ascending order by Firing Accuracy
R k:40- // Move high PsiSkill to the rear
# -a+R+b-d-r+f // Sort by descending Armor, ascending Rank, Bravery, descending TU's, and Reations, and by ascending Firing Accuracy
F R:-0 // Move all Rookies to the front... (So they can get kills and become Squaddies... as well as being expendable)
# -a+b+d+f-r // Sort by descending Armor, ascending Bravary, TU's, and Firing Accuracy, and descending Reactions
F b:-20 // Move cowards to the front
# -a+d+f-r // Sort by descending Armor, ascending TU's, and Firing Accuracy, and descending Reactions

// # +R // Sort by Inc Rank
// R R:4- // Move two highest Ranks to rear
// # +f-r // Sort by Inc FireAcc, Dec Reactions
// R k:40- // Move high PsiSkill to rear
// R f:70- // Move marksmen to rear
// F R:-0 p:-30 // Move weak-willed rookies to front

/StatStrings
/SortStats

===Custom Batch File===

Talk:XcomUtil

2011-04-03T23:01:36Z

Mannon: /* Read The Fine Manual */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

===Build 442===

*Add Batch file for Java Terrain Editor as an example for thoes that want to use it.
*Fix BFG placement of units in Alien Base Terrain.
*Autocombat: All units with health <= fatal wounds dies before autocombat calculates win threshold.
*Autocombat: Fixed MIA units on WIN.

--[[User:BladeFireLight|BladeFireLight]] 18:16, 26 March 2010 (EDT)

==Beta Discussion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

----

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

----

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). [[User:Spike|Spike]] 17:40, 16 March 2010 (EDT)
:: Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.
::: Thanks! And I thought I'd read the manual. [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)

===Build 442===
Bugs or features?
*BFG random generated a Martian landscape with its signature craters and bunkers for my crashed medium scout mission.
*BFG random generated a forest/farm map for my terror mission in Los Angeles. Nothing wrong with the enemy/civilian units though.
*Randomized small ufo's often seem to have elevators. Could/should it be set so that one level high ufo's would not get an elevator? I saw a 3x3 elevator in a large scout.
--[[User:Ras|Ras]] 04:43, 8 July 2010 (EDT)

*BFG will randomly choose a terrain unless you choose prompt in XcuSetup. This is how it's always been.
*Random floor plans is a complicated thing. It will chose elevator rooms defined in the rms file at random. They do look strange but it's the best Scott and I have come up with so far.
--[[User:BladeFireLight|BladeFireLight]] 21:07, 11 July 2010 (EDT)
:Good enough. --[[User:Ras|Ras]] 03:42, 12 July 2010 (EDT)

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)

*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

* (Build 442) Prompts for "Pistol" not "Dart Gun" mod in TFTD. Also "Psionics" not "M.C.". [[User:Spike|Spike]] 21:53, 1 November 2010 (UTC)

* (Build 442) Steam instructions are confusing - should I run XCUSetup.bat first, then run SteamSetup.bat, then run Steam? Probably not. I think I should run SteamSetup.bat, then Steam, which will run XCUSetup.bat (or then I will directly run XCUSetup.bat). But it's not very clear. Although the instructions are pretty explicit, why doesn't XCUSetup.bat terminate when it detects Steam? That's what confused me I think. I didn't expect to have to hit Ctrl-C at that point. [[User:Spike|Spike]] 21:53, 1 November 2010 (UTC)
**As a nice to have, tell me to hit Ctrl-C to abort XCUSetup (and run SteamSetup.bat) when Steam is detected
**As a nice to have, ''don't'' tell me to abort and run SteamSetup.bat, if I've already run SteamSetup.bat. [[User:Spike|Spike]] 20:18, 3 November 2010 (UTC)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independently to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS environments.
:*Partly Fixed: Requirement has been drastically reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: doesn't appear until after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat gets truncated with selecting any improved weapon.
:*Fixed: This happens because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error during backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now using 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recovery no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocombat if you do this.
:*Fixed: [[Talk:Known Bugs (TFTD)#Multi-part map ammo loss|Multi-part map ammo loss]].
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM doesnt give access by default to the command prompt. If you know how to add that then you should know enough of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unaware that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the difficulty patch and changing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skipped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly during Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)
*EQL only works on turn 1
:: Fixed
*Units not on the craft during Autocombat are MIA
:: This has been fixed. Autocombat now processes one round of fatal wounds first. Any surviving units are then marked as in the craft and MIA score removed. --[[User:BladeFireLight|BladeFireLight]] 18:24, 26 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness - Tested OK (except IN Rkt)
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness

:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. To be Tested. These values are probably too high.
//NB we are not indicating damage here, that is already calculated by the "effective" function. we are just
//factoring in the possibility of hitting multiple targets because of the area effect
//ToDo: needs compensating bonus for aliens (grenades?). should not be cumulative on the same unit.
//Also: add check if weapon is "effective" (at GZ) ?
+25 u:-2 W:-40 W:-41 //U: // Human w/ Blaster/DP Launcher and ammo
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 //U: // Human w/ Stun/Shok Launcher and ammo
+5 u:-2 W:-4 W:-6 //U: // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 //U: // Human w/HE ammo and launcher AC/HjC-HE

-25 u:4-14 W:-40 W:-41 //U: // Alien w/ Blaster/DP Launcher and ammo
-10 u:4-14 W:-42 W:-43 //U: // Alien w/ Stun/Shok Launcher and ammo

::Having tested the HC and AC rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types. To be tested
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-1 T:0- u:6-6 // Flying Alien - Ethereal
-1 T:0- u:8-8 // Flying Alien - Floater
-1 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-1 T:1- u:11-11 // "Flying" Alien - Tentaculat

::On reflection flying is hardly any advantage for aliens, it usually just makes them easier targets with no cover. I guess it helps with avoiding HE splash. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (not +1 per grenade!) //Tested OK

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+3 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod //Tested OK
+3 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above) //Tested OK

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades (this needs to be an OR block, so it's not cumulative for each grenade type)
+2 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)
+2 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+2 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+2 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: One per unit tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect //Tested OK

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

* It would be nice, in a future version of AutoCombat, to have some way of ORing rules together. Using the U: construct as a 'break' only allows you to have one single OR block per unit type (I think). [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* The battle report screen after AutoCombat does not report the number of Alien Artefacts recovered. This gives score I believe. Is it because it's hard to populate whatever data structure the game reads in order to generate the Artefact count? As I understand it, anything you haven't yet researched is an Artefact, and awards some score for recovering it. Anyway, fixing this would be nice-to-have. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* It would be nice to compensate for the [[Known_Bugs#Equip_Phase_Ammo_Load_Error|Equip Phase Ammo Load Bug]] [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

=== Focused Research Help ===

There is a minor and probably unintended consequence of Research Help from Captured Aliens. Normally when you capture a new alien artefact that opens up a new research project, you start the research project - typically with 0 Scientists - and then immediately sell the artefact. The problem with this for Research Help is that you soon have a huge number of projects underway. Then any Research Help tends to get very widely dispersed across all active projects (since it always goes to the project where the biggest reduction can be made, i.e. the projects furthest from completion). The result is that projects are completed only rarely, and progress is made on a broad front but without delivering much. Currently, to avoid this, it is necessary to keep single alien artefacts around in Stores, waiting for the time when the project they open up becomes a priority. In a way, this is interesting and challenging. In another way, it is a headache and take away vital cash.

You might argue that the trick above is a kind of exploit and should not be done. I don't know, maybe. But it is a common practice.

A solution, hopefully fairly easy to implement, is to only consider Research Help for projects which have actually made some progress, e.g. more than 1 scientist day has been applied to them.

In the meantime, maybe put a warning to players in the XCUSETUP script, to keep their research projects to a smaller number when using Research Help from Aliens. [[User:Spike|Spike]] 21:10, 16 March 2010 (EDT)

== Features for 9.8+ - New features ==

=== TFTD Gauss Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

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.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

=== Advanced Laser Cannon ===
The "Advance Laser Weapons" option only nerfs the Laser Cannon (raising cost and reducing profitability but not changing any damage/range values. Previously xcomutil modified them unconditionally). I wonder if that's the best result - should damage and/or range be raised to make the cannon useful or to compensate? Most commanders don't use the cannon as is, but maybe it's prejudice... [[User:Cesium|Cesium]] 21:36, 16 March 2010 (EDT)

: Note this isn't a "rebalancing issue" compared to the other weapons - I'm talking about (maybe) balancing for the increased cost of production and lower profit. [[User:Cesium|Cesium]] 21:41, 16 March 2010 (EDT)
:: I guess the craft weapon rebalancing options listed just above, either the cost-based or the stat-based, would help out here. The intent of "Alternate Laser Weapons" is purely to make the game harder, which it definitely does. Is it necessary to "balance" something that deliberately makes the game harder? I don't think so. But I do think the general principle should be that there are no "pointless" items of equipment. So either way the Laser Cannon deserves a buff. Personally I never thought the previous XCU buff to Laser Cannon made it worth using. What it gave with one hand (range increase, but still lousy range), it took away with the other (firepower). I would actually rather have the standard Laser Cannon than the old XCU "buffed" one. [[User:Spike|Spike]] 22:11, 16 March 2010 (EDT)

=== Rebalanced X-COM craft ===

Is there any thought being put towards perhaps rebalancing the X-COM craft themselves?

The problem, as I see it, is that the Firestorm and the Lightning are fairly comparable to the Interceptor and the Skyranger, but the Avenger makes them all obsolete in every possible way — and once you have the Firestorm/Lightning, the Avenger is just a single research "hop" away, so they're obsolete almost immediately.

And realistically, how is the Avenger really the "ultimate" craft if you '''don't''' need a transport and just want to shoot things down fast? There's no obvious reason X-COM couldn't come up with a smaller, more compact, more streamlined version of the Avenger that goes even faster but can't transport anything. Or, if we assume we've somehow maxed out the alien propulsion technology's speed, you could use the exact same craft, but put more craft weapons in all that cargo space. (Notwithstanding the current hardcoded limit of two weapons per craft.) Either way, it's just not sensible to say that the Avenger is the best available technology for shooting down UFOs, when a ton of internal space is "wasted" on troops and tanks.

A full rebalancing, IMO, would make the Avenger slowest and least armed (maybe unarmed) but with the most capacity, the Firestorm fastest and most heavily armed but with no transport capability, and the Lightning somewhere inbetween. There's also the possibility of changing the names around, maybe even the research order, though some game text updates would certainly be required at that point.

If the primary goal is to avoid making UFO interception any easier, the Firestorm could take the current Avenger role, at 5400 speed and two weapons, while the Lightning would be slower with one weapon and not really be suitable for taking out battleships, but can otherwise take out anything it can outrun (due to plasma beam range). The Avenger would be the slowest and have no weapons, i.e. a pure transport.

Alternatively, to be "backwards compatible" with current Avenger-style tactics (i.e. a whole fleet of dual-role, battleship-killing craft), the Lightning could take the current Avenger role (5400 speed, two weapons). The Firestorm could be even faster, and the Avenger could be slower with just a single weapon, but (again) can kill anything it can (even temporarily) outrun, short of battleships. But of course, this makes interception even easier overall, particularly with easier four-pack battleship intercepts and reduced fuel consumption.

Either approach would keep all three craft useful throughout the game, rather than the monotonous (and IMO unrealistic for reasons above) Avenger-only force you end up with at the end of the game. Just a thought. I'll be trying some of this with my own game. — [[User:Wisq|Wisq]] 20:58, 18 April 2010 (EDT)

=== SWP switch expansion ===

Just chronicling my thoughts here about some possible changes to the SWP switch (related to the [http://www.strategycore.co.uk/forums/Playing-the-bad-guys-with-XcomUtil-t8079.html&gopid=95894#entry95894 Playing the bad guys with XcomUtil] discussion thread over at Strategycore). It would be nice for a more robust SWP option with a few options to control how it behaves. For any reason, from personal play, testing purposes or if you are indeed playing a hot-seat/e-mailed battle (which was what it was intended for originally).

A few ideas off the top of my head:

* Geoscape and Tactical soldier linking - either erase the links so that they don't count for this battle. Maybe a choice to unload the soldiers so that you don't lose the soldiers even if the Skyranger is lost. Or, an option to transfer the links over to the aliens.
* Improved civilian handling during swaps - either exclude them from the swap, or even provide an option to delete them from the map.
* Improve the shroud of war and light map handling. This one's a bit tricky, but there should be more options than its current setting of making the map visible. There's no way to remember previously visited areas for the individual sides unless you also control dual copies of the shroud and light maps. Or just black out everything and light up the immediate areas around the active side's units. Hard call this one.

Not the most important of features to expand on, but worth considering now that a lot more is known about the game since the command was introduced. -[[User:NKF|NKF]] 02:06, 23 April 2010 (EDT)

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

= Read The Fine Manual =

As otherwise you'll be trying to run a modified Interceptor tactical mission without using the required batchfile, resulting in...
<blockquote>===Crewed Interceptor Issues===
By default, the DOS version (and possibly others) of XcomUtil will allow you to outfit interceptors with a crew and equipment. However, if you attempt to perform a tactical mission of any kind with an interceptor, the TACTICAL.EXE portion of the game will go to a black screen. Pressing escape or enter will cause the game to return to GEOSCAPE.EXE with a mission rating of 0, as if you had never attempted the mission at all. The worst part of this, however, is that the agents and equipment that were on board the interceptor will be lost.
This likely occurs for two reasons:
* The tactical portion of the mission fails because no battlescape configurations or terrain exist for the interceptor, since it was never meant to hold crew.
* Upon returning to the geoscape, it is likely that the game "realizes" that interceptors are not supposed to carry crew or equipment, and promptly destroys the passengers and equipment that it is carrying.</blockquote>
::I think that the reason for losing the crew and equipment actually is not due to the game waking up to the fact that interceptors cannot hold them. In fact even with the game modded to allow craft to transport said soldiers and material I would be willing to bet that you will still lose them if the battlescape fails due to there being no map for the ship. The reason is because when the mission is started it places those soldiers and equipment on the terrain, but for the craft which aren't normally capable of it the game doesn't know where to place them. Thus when the mission fails none of your soldiers or equipment were actually in the game map to be retrieved, resulting in their loss. In fact it is possible that even with the craft map and modifications to the exe, you may still lose all soldiers and equipment if you don't have XcomUtil to place them on the map built for that mission.[[User:Mannon|Mannon]] 19:01, 3 April 2011 (EDT)

Talk:XcomUtil

2011-04-03T23:01:18Z

Mannon: /* Read The Fine Manual */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

===Build 442===

*Add Batch file for Java Terrain Editor as an example for thoes that want to use it.
*Fix BFG placement of units in Alien Base Terrain.
*Autocombat: All units with health <= fatal wounds dies before autocombat calculates win threshold.
*Autocombat: Fixed MIA units on WIN.

--[[User:BladeFireLight|BladeFireLight]] 18:16, 26 March 2010 (EDT)

==Beta Discussion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

----

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

----

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). [[User:Spike|Spike]] 17:40, 16 March 2010 (EDT)
:: Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.
::: Thanks! And I thought I'd read the manual. [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)

===Build 442===
Bugs or features?
*BFG random generated a Martian landscape with its signature craters and bunkers for my crashed medium scout mission.
*BFG random generated a forest/farm map for my terror mission in Los Angeles. Nothing wrong with the enemy/civilian units though.
*Randomized small ufo's often seem to have elevators. Could/should it be set so that one level high ufo's would not get an elevator? I saw a 3x3 elevator in a large scout.
--[[User:Ras|Ras]] 04:43, 8 July 2010 (EDT)

*BFG will randomly choose a terrain unless you choose prompt in XcuSetup. This is how it's always been.
*Random floor plans is a complicated thing. It will chose elevator rooms defined in the rms file at random. They do look strange but it's the best Scott and I have come up with so far.
--[[User:BladeFireLight|BladeFireLight]] 21:07, 11 July 2010 (EDT)
:Good enough. --[[User:Ras|Ras]] 03:42, 12 July 2010 (EDT)

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)

*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

* (Build 442) Prompts for "Pistol" not "Dart Gun" mod in TFTD. Also "Psionics" not "M.C.". [[User:Spike|Spike]] 21:53, 1 November 2010 (UTC)

* (Build 442) Steam instructions are confusing - should I run XCUSetup.bat first, then run SteamSetup.bat, then run Steam? Probably not. I think I should run SteamSetup.bat, then Steam, which will run XCUSetup.bat (or then I will directly run XCUSetup.bat). But it's not very clear. Although the instructions are pretty explicit, why doesn't XCUSetup.bat terminate when it detects Steam? That's what confused me I think. I didn't expect to have to hit Ctrl-C at that point. [[User:Spike|Spike]] 21:53, 1 November 2010 (UTC)
**As a nice to have, tell me to hit Ctrl-C to abort XCUSetup (and run SteamSetup.bat) when Steam is detected
**As a nice to have, ''don't'' tell me to abort and run SteamSetup.bat, if I've already run SteamSetup.bat. [[User:Spike|Spike]] 20:18, 3 November 2010 (UTC)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independently to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS environments.
:*Partly Fixed: Requirement has been drastically reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: doesn't appear until after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat gets truncated with selecting any improved weapon.
:*Fixed: This happens because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error during backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now using 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recovery no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocombat if you do this.
:*Fixed: [[Talk:Known Bugs (TFTD)#Multi-part map ammo loss|Multi-part map ammo loss]].
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM doesnt give access by default to the command prompt. If you know how to add that then you should know enough of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unaware that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the difficulty patch and changing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skipped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly during Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)
*EQL only works on turn 1
:: Fixed
*Units not on the craft during Autocombat are MIA
:: This has been fixed. Autocombat now processes one round of fatal wounds first. Any surviving units are then marked as in the craft and MIA score removed. --[[User:BladeFireLight|BladeFireLight]] 18:24, 26 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness - Tested OK (except IN Rkt)
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness

:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. To be Tested. These values are probably too high.
//NB we are not indicating damage here, that is already calculated by the "effective" function. we are just
//factoring in the possibility of hitting multiple targets because of the area effect
//ToDo: needs compensating bonus for aliens (grenades?). should not be cumulative on the same unit.
//Also: add check if weapon is "effective" (at GZ) ?
+25 u:-2 W:-40 W:-41 //U: // Human w/ Blaster/DP Launcher and ammo
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 //U: // Human w/ Stun/Shok Launcher and ammo
+5 u:-2 W:-4 W:-6 //U: // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 //U: // Human w/HE ammo and launcher AC/HjC-HE

-25 u:4-14 W:-40 W:-41 //U: // Alien w/ Blaster/DP Launcher and ammo
-10 u:4-14 W:-42 W:-43 //U: // Alien w/ Stun/Shok Launcher and ammo

::Having tested the HC and AC rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types. To be tested
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-1 T:0- u:6-6 // Flying Alien - Ethereal
-1 T:0- u:8-8 // Flying Alien - Floater
-1 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-1 T:1- u:11-11 // "Flying" Alien - Tentaculat

::On reflection flying is hardly any advantage for aliens, it usually just makes them easier targets with no cover. I guess it helps with avoiding HE splash. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (not +1 per grenade!) //Tested OK

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+3 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod //Tested OK
+3 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above) //Tested OK

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades (this needs to be an OR block, so it's not cumulative for each grenade type)
+2 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)
+2 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+2 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+2 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: One per unit tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect //Tested OK

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

* It would be nice, in a future version of AutoCombat, to have some way of ORing rules together. Using the U: construct as a 'break' only allows you to have one single OR block per unit type (I think). [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* The battle report screen after AutoCombat does not report the number of Alien Artefacts recovered. This gives score I believe. Is it because it's hard to populate whatever data structure the game reads in order to generate the Artefact count? As I understand it, anything you haven't yet researched is an Artefact, and awards some score for recovering it. Anyway, fixing this would be nice-to-have. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* It would be nice to compensate for the [[Known_Bugs#Equip_Phase_Ammo_Load_Error|Equip Phase Ammo Load Bug]] [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

=== Focused Research Help ===

There is a minor and probably unintended consequence of Research Help from Captured Aliens. Normally when you capture a new alien artefact that opens up a new research project, you start the research project - typically with 0 Scientists - and then immediately sell the artefact. The problem with this for Research Help is that you soon have a huge number of projects underway. Then any Research Help tends to get very widely dispersed across all active projects (since it always goes to the project where the biggest reduction can be made, i.e. the projects furthest from completion). The result is that projects are completed only rarely, and progress is made on a broad front but without delivering much. Currently, to avoid this, it is necessary to keep single alien artefacts around in Stores, waiting for the time when the project they open up becomes a priority. In a way, this is interesting and challenging. In another way, it is a headache and take away vital cash.

You might argue that the trick above is a kind of exploit and should not be done. I don't know, maybe. But it is a common practice.

A solution, hopefully fairly easy to implement, is to only consider Research Help for projects which have actually made some progress, e.g. more than 1 scientist day has been applied to them.

In the meantime, maybe put a warning to players in the XCUSETUP script, to keep their research projects to a smaller number when using Research Help from Aliens. [[User:Spike|Spike]] 21:10, 16 March 2010 (EDT)

== Features for 9.8+ - New features ==

=== TFTD Gauss Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

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.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

=== Advanced Laser Cannon ===
The "Advance Laser Weapons" option only nerfs the Laser Cannon (raising cost and reducing profitability but not changing any damage/range values. Previously xcomutil modified them unconditionally). I wonder if that's the best result - should damage and/or range be raised to make the cannon useful or to compensate? Most commanders don't use the cannon as is, but maybe it's prejudice... [[User:Cesium|Cesium]] 21:36, 16 March 2010 (EDT)

: Note this isn't a "rebalancing issue" compared to the other weapons - I'm talking about (maybe) balancing for the increased cost of production and lower profit. [[User:Cesium|Cesium]] 21:41, 16 March 2010 (EDT)
:: I guess the craft weapon rebalancing options listed just above, either the cost-based or the stat-based, would help out here. The intent of "Alternate Laser Weapons" is purely to make the game harder, which it definitely does. Is it necessary to "balance" something that deliberately makes the game harder? I don't think so. But I do think the general principle should be that there are no "pointless" items of equipment. So either way the Laser Cannon deserves a buff. Personally I never thought the previous XCU buff to Laser Cannon made it worth using. What it gave with one hand (range increase, but still lousy range), it took away with the other (firepower). I would actually rather have the standard Laser Cannon than the old XCU "buffed" one. [[User:Spike|Spike]] 22:11, 16 March 2010 (EDT)

=== Rebalanced X-COM craft ===

Is there any thought being put towards perhaps rebalancing the X-COM craft themselves?

The problem, as I see it, is that the Firestorm and the Lightning are fairly comparable to the Interceptor and the Skyranger, but the Avenger makes them all obsolete in every possible way — and once you have the Firestorm/Lightning, the Avenger is just a single research "hop" away, so they're obsolete almost immediately.

And realistically, how is the Avenger really the "ultimate" craft if you '''don't''' need a transport and just want to shoot things down fast? There's no obvious reason X-COM couldn't come up with a smaller, more compact, more streamlined version of the Avenger that goes even faster but can't transport anything. Or, if we assume we've somehow maxed out the alien propulsion technology's speed, you could use the exact same craft, but put more craft weapons in all that cargo space. (Notwithstanding the current hardcoded limit of two weapons per craft.) Either way, it's just not sensible to say that the Avenger is the best available technology for shooting down UFOs, when a ton of internal space is "wasted" on troops and tanks.

A full rebalancing, IMO, would make the Avenger slowest and least armed (maybe unarmed) but with the most capacity, the Firestorm fastest and most heavily armed but with no transport capability, and the Lightning somewhere inbetween. There's also the possibility of changing the names around, maybe even the research order, though some game text updates would certainly be required at that point.

If the primary goal is to avoid making UFO interception any easier, the Firestorm could take the current Avenger role, at 5400 speed and two weapons, while the Lightning would be slower with one weapon and not really be suitable for taking out battleships, but can otherwise take out anything it can outrun (due to plasma beam range). The Avenger would be the slowest and have no weapons, i.e. a pure transport.

Alternatively, to be "backwards compatible" with current Avenger-style tactics (i.e. a whole fleet of dual-role, battleship-killing craft), the Lightning could take the current Avenger role (5400 speed, two weapons). The Firestorm could be even faster, and the Avenger could be slower with just a single weapon, but (again) can kill anything it can (even temporarily) outrun, short of battleships. But of course, this makes interception even easier overall, particularly with easier four-pack battleship intercepts and reduced fuel consumption.

Either approach would keep all three craft useful throughout the game, rather than the monotonous (and IMO unrealistic for reasons above) Avenger-only force you end up with at the end of the game. Just a thought. I'll be trying some of this with my own game. — [[User:Wisq|Wisq]] 20:58, 18 April 2010 (EDT)

=== SWP switch expansion ===

Just chronicling my thoughts here about some possible changes to the SWP switch (related to the [http://www.strategycore.co.uk/forums/Playing-the-bad-guys-with-XcomUtil-t8079.html&gopid=95894#entry95894 Playing the bad guys with XcomUtil] discussion thread over at Strategycore). It would be nice for a more robust SWP option with a few options to control how it behaves. For any reason, from personal play, testing purposes or if you are indeed playing a hot-seat/e-mailed battle (which was what it was intended for originally).

A few ideas off the top of my head:

* Geoscape and Tactical soldier linking - either erase the links so that they don't count for this battle. Maybe a choice to unload the soldiers so that you don't lose the soldiers even if the Skyranger is lost. Or, an option to transfer the links over to the aliens.
* Improved civilian handling during swaps - either exclude them from the swap, or even provide an option to delete them from the map.
* Improve the shroud of war and light map handling. This one's a bit tricky, but there should be more options than its current setting of making the map visible. There's no way to remember previously visited areas for the individual sides unless you also control dual copies of the shroud and light maps. Or just black out everything and light up the immediate areas around the active side's units. Hard call this one.

Not the most important of features to expand on, but worth considering now that a lot more is known about the game since the command was introduced. -[[User:NKF|NKF]] 02:06, 23 April 2010 (EDT)

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

= Read The Fine Manual =

As otherwise you'll be trying to run a modified Interceptor tactical mission without using the required batchfile, resulting in...
<blockquote>===Crewed Interceptor Issues===
By default, the DOS version (and possibly others) of XcomUtil will allow you to outfit interceptors with a crew and equipment. However, if you attempt to perform a tactical mission of any kind with an interceptor, the TACTICAL.EXE portion of the game will go to a black screen. Pressing escape or enter will cause the game to return to GEOSCAPE.EXE with a mission rating of 0, as if you had never attempted the mission at all. The worst part of this, however, is that the agents and equipment that were on board the interceptor will be lost.
This likely occurs for two reasons:
* The tactical portion of the mission fails because no battlescape configurations or terrain exist for the interceptor, since it was never meant to hold crew.
* Upon returning to the geoscape, it is likely that the game "realizes" that interceptors are not supposed to carry crew or equipment, and promptly destroys the passengers and equipment that it is carrying.</blockquote>
:I think that the reason for losing the crew and equipment actually is not due to the game waking up to the fact that interceptors cannot hold them. In fact even with the game modded to allow craft to transport said soldiers and material I would be willing to bet that you will still lose them if the battlescape fails due to there being no map for the ship. The reason is because when the mission is started it places those soldiers and equipment on the terrain, but for the craft which aren't normally capable of it the game doesn't know where to place them. Thus when the mission fails none of your soldiers or equipment were actually in the game map to be retrieved, resulting in their loss. In fact it is possible that even with the craft map and modifications to the exe, you may still lose all soldiers and equipment if you don't have XcomUtil to place them on the map built for that mission.[[User:Mannon|Mannon]] 19:01, 3 April 2011 (EDT)

Talk:Enemy Unknown (1994) Extended

2011-04-03T22:43:49Z

Mannon: /* May i remake the main page of this article */

= General Discussion =

This is very useful, putting all these things together in one place with clear instructions. This could become the new "standard" version of the game. But I think it's only fair to explain that a lot of the choices you have made for the UFOExtender.ini file are personal choices - you should advise user to review your .ini file (and helpful explanatory comments) and see if they agree.

[[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

In general if we have a mix of features in the standard config, some of which give a minor advantage to XCom (Craft always ready, Elerium fuelled craft bug fix), some of which give a minor advantage to the aliens (Retaliate for Ground Assault), that should work out ok. Features that give a major advantage one way or the other should not be in standard config. [[User:Spike|Spike]] 07:56, 26 August 2009 (EDT)

= UFO Extender Templates =

I think your comments to the .ini file are very helpful. Here are some alternative opinions on some of the options:

*Range Based Accuracy
*[MC] Line of Fire Check

- These are to make the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

*Retaliate Against Ground Assault

- Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

*No Blaster Bomb Drift

- Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

- Maybe you could group the above options together as they all make the game more challenging, i.e. balance the game more in favour of the aliens, and explain that to the player - if you want to make the game more evenly balanced, select these options.

*Tactical Scroll
*Video Pitch
*Music Change Freeze

- You were not experiencing these issues, but others do experience it, so this is an important thing to make clear to users. They should check themselves.

*Elerium-fuelled Craft Bug

- While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

*Funky Fire

- This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

*Crafts Always Ready

- I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

*Keep Base Navigation Modules

- Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

*Base Building Stacking "too complex for benefit"

- Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

*Stun Fest "overpowered"

- I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

*Assign All Personnel

- This is a real time saver

*Hacks

Most of them are deliberate cheats and not meant for normal play so you're right to say they are hugely unbalancing.

However Recover All Clips is a kind of bug fix. Though it does give advantage to XCom it also eliminates the irritating need to manage ammo logistics. With human ammo this is not unbalancing. With scarce alien ammo, it could be, fair enough. No Score Game Over is a way of continuing "hopeless" games. Both of these have precedents in XComUtil, which a lot of players use.

*Initial Base

Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

Lastly, but not least, as Seb76 did so much of the work on UFOExtender, maybe you should give him a credit on the page? And add his UFOExtender page to the See Also?

Cheers, [[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

Spike, thanks. Yes, the choices I made were personal ones informed mostly by my (poor) memories of 15 years ago just to get the ball rolling. This is exactly the discussion I want to have because I think it would be good to come up with a consensus config for a standard version of X-COM for people who just want to get right into the game. I will review your points in detail, rethink the ini config., and make it more clear that seb's UFO Extender is the centerpiece. By the way, this talk page is a hard place to have a discussion - are strategycore forums better? [[User:Xeucom|Xeucom]] 01:57, 20 August 2009 (EDT)

: Hey, great to have you back after 15 years! Sure let's figure out a consensus. Actually I was thinking we might be able to make a few different .ini templates based on some themes, eg:

:* Bug fixes only
:* Convenience features
:* "What the designers intended"
:* Making the game harder
:* Alternate scenarios

:...etc. At the moment I'm trying to recover my account on StrategyCore (I want to post to Zombie's thread on offsets/modding). So when I get my account back I'm happy to talk there. Cheers! [[User:Spike|Spike]] 14:12, 20 August 2009 (EDT)

::Do you remember what your account name is or what email you used to register? If so, I can set you up in a hurry. Just send me an email. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

:: A menu of configs is a good idea. I'd still say we should sweep up a balanced Bug Fixes, Conveneince Features, and Designers Intent into a consensus standard config and establish that as our base line. This is all meant to lure people in/back with a quick and easy setup, get them some play time, then let them explore all the neat options UFO Extender allows. The base line also gives us a standard testing config that we can focus on making bug free (or documenting workarounds). --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

::: Ok that sounds like a plan!

[[User:Spike|Spike]] 05:25, 22 August 2009 (EDT)

: Actually, using a rewritten Initial Base (with a real base) with the stock starting inventory will give you serious cashflow management problems. "Retaliate Against Ground Assault" fixes the cashflow problem, and I'm unclear whether it makes the game easier or harder for X-COM. (I generally have an easier time the first three months on Superhuman than on Beginner, as the extra cashflow from the increased Retalation Acts more than compensates for equally dumb AI with more accurate ranged attacks.) -- [[User:Zaimoni|Zaimoni]] 04:42, 22 August 2009 (CDT)

= Small Scout Map =

Does the Combo Pack include Zombie's Small Scout Map fix? If not, maybe that should be included too. [[User:Spike|Spike]] 14:37, 20 August 2009 (EDT)

:I don't have anything in the kit for the Small Scout because nothing is wrong with it. LOL I do, however, have a Small Scout Mod ([http://www.strategycore.co.uk/files/index.php?dlid=710 found here]) which reintroduces the old Small Scout lefover from the development days. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

::I didn't include the Small Scout patch because it seemed too little gain for the additional step of installing it since people are installing it by manual steps. There is already a very small scout in the game (the one you can grav lift into one square with hole in top) The ideal would be if someone could cook up a little exe that downloaded all the mods and installed them (or we got permission from the authors to bake it into one download) so it was one download and double click. Then it would make sense to add in some more one-trick mods. --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

= Standard Config Discussions =

This section is for discussing what should go in the standard UFO Extender config that is recommended as the downloadable ini file. The concept of the standard config is a config that fixes bugs, introduces convenience features, and retains or improves game balance while keeping the original feel. It is intended for the new or returning player who can put up with a moderate level of difficulty, but is not an elite player (Spike, I will add more sections as I have time to address all the points you raised - these are the ones I had time to research and think about with your feedback).

== Game Version ==

There could be a problem in that the publicly available version of the game is the DOS version released by Steam. The Windows CE version is arguably no longer in the public domain, since Steam now has made its version available. At this time, only one site I can find is still offering downloads of the Windows CE edition. It could be considered the Windows CE edition is no longer "abandonware", and this seems to be the view that the operators of download sites are taking. Therefore, if looking for a reference edition, maybe we should look to modding the Steam, DOS, edition. The problem is that Seb76's loader only works on the Windows CE edition.

I think we should go ahead and define the features of a "standard edition" anyway, but the problem of what version to use will still need to be solved. Basically either the fan community (us!) extends Seb's loader to also apply to the Steam DOS version, or we need to use another tool to patch the DOS version. In theory, XcomUtil could be used to patch the DOS version to introduce all of Seb's additional patches. It is arcane to use but it could be done. The key first step would be to establish a list of patches for the DOS version that are equivalent to Seb's patches to the Windows version.

:Both the Steam and GamersGate (according to forums on the latter) downloads include the Windows version. Specifically, they have a "UFO Defense.exe". I have tested the described mod set with Steam. Steam launches the DosBox DOS version by default through the steam interface, but once you create the shortcut as described, you never use it again. Does that alleviate this concern? [[User:Xeucom|Xeucom]] 09:30 August 23, 2009.

:: You are right! I tested it and, to my surprise, it works. I guess the Steam version must be the Windows CE version, even though it launches it via DosBox. Cool, so there is no problem there - quite the contrary, if all these mods work on the Steam distribution that's excellent. And maybe we can persuade Steam to distribute the "standard extended" version some day. Perhaps not, as we are sort of bypassing their security. Normally when you try to start the executable it should chain back to all the Steam software. In this case, I think we get by that because Seb's loader treats the executable as sort of a data file, loading it rather than directly executing it from the O/S, and also the loader controls the entry points itself (guessing?). Anyway, I suspect Steam don't really care too much about software protection on the old XCom games. [[User:Spike|Spike]] 06:49, 24 August 2009 (EDT)

== Categories ==

Group all fixes into categories:

=== Bug Fixes ===

==== General Bug Fixes ====

All undisputed bugs should be fixed here.

[Bug Fix]
Pay For Dirt=1
Phantom Radar=1
Base Disjoint=1
Radar Stacking=1
Base Facility Dismantle-Construction Crash=1
Collectors Edition Blaster Bomb Bug=1
Proximity Grenades=1
Proximity Grenades Experience=1
Door Jam=1
Personnel Overflow=1
Funky Fire=1
Displayed Base Maintenance Cost=1

[OBDATA.DAT]
Apply=1
;Make grenades indestructible to allow stacking several explosions
Grenade Resistance=255
Proximity Grenade Resistance=255
High Explosive Resistance=255

==== Technical ====

Audio/Video bugfixes or tweaks and other things that some experience, some do not, depending on their platform. Should all be optional and to be set up by the end user. (Possibly video pitch should default to 1, since if it's not enable it can be hard to recover from the screen crash? Which might put users off the "standard extended" package?)

[Bug Fix]
Video Pitch=?
Intro Sounds=?
Music Change Freeze=?
Tactical Scroll=?

[Mod]
HQ4x=?
D3D=?
Scale Mouse=?

[Music]
Apply=1
Source=MP3
;Source=PSX CD
CD Drive=F
MP3 Folder=mp3
Battlescape=*Battlescape*.mp3
Start Menu=*Final Briefing*.mp3
Bad Ending=*Final Briefing*.mp3
Good Ending=*Dogfight*.mp3
Geoscape=*Geoscape*.mp3
Dogfight=*Dogfight*.mp3
Mission Debriefing=*Debriefing*.mp3
UFO Assault=*Briefing1.mp3
Base Defense=*Briefing2.mp3
Base Attack=*Briefing1.mp3
Mars=*Debriefing*.mp3
Terror Mission=*Briefing2.mp3

==== Closed Exploits ====

We ''might'' want to make it optional to close exploits and make that separate from bug fixes. The difference being that bug fixes help the player or are neutral, whereas closing an Exploit by definition makes it relatively harder for the player. Personally I don't like to encourage the use of exploits, but it's an option.

(For now the exploit-closing features have been included in other sections)

:My opinion is that all obvious (in the sense that it is clearly not balanced, not that it is easy to find) exploits should be closed in the standard config. If a player stumbles into an exploit, they can become frustrated because the supension of disbelief and challenge is lost. The game ends up simply looking inconsistent. - [[User:Xeucom|Xeucom]] 19:11 August 25, 2009.

:: I completely agree. You will get some people who routinely rely on certain Exploits, who might not agree. But then they can always change the config file. Probably the most frequently used Exploits are - [[ExploitsA#Free Wages|Free Wages]], [[ExploitsA#Free Manufacturing|Free Manufacturing]], [[Known Bugs#Funky Fire|Funky Fire]], Access Alien Inventory. The [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Robotic Research]] exploits are infrequently used but are massive and should definitely be closed down. [[Exploiting Mind Control#Access the Alien Inventory Screen|Access Alien Inventory]] is arguably not an exploit but merely enables "What The Designers Intended". After all, it seems logical that XCom Psi Troops should be able to access a victim's inventory, just as alien psi attackers can do. It's not in itself unbalancing (or, not any more than Psi itself is). In fact for aliens with only built in attacks it's kind of necessary to make Psi useful on those aliens. It only really becomes unbalancing through the use of [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]. Exponential Mind Control should probably be closed as an Exploit, but I'm not aware of any existing patch that closes it (other than by disabling Access Alien Inventory, which as I've said here is probably not justified). [[Exploiting Mind Control#Zombie's Permanent Control of Aliens via Stunning|Permanent Mind Control]] and the [[Exploiting Mind Control#Resurrect Zombified Agents|Zombie Resurrection]] techniques should also be closed down. [[User:Spike|Spike]] 07:44, 26 August 2009 (EDT)

::[[Tactical Exploits#Elevator Shielding|Elevator Shielding]], which enables risk-free [[Tactical Exploits#Milking Alien Bases|Alien Base Milking]], should also be closed, but again I'm not aware of any fix. [[Grenade Relay]]s, and all similar [[Grenade Relay#Relaying other Equipment|item relays]] - any tactic which allows one item/weapon to be used multiple times per turn by passing it through the hands of multiple soldiers and thereby applying more than 100% TUs to it - are minor and not really important to close down, even though they are a bit silly. [[ExploitsA#Infinite Fuel|Infinite Fuel]] is not so destabilizing as to need closing down as an Exploit, but it probably should be closed just as a bug. [[User:Spike|Spike]] 12:00, 26 August 2009 (EDT)

=== Convenience Features ===

These are logistic or interface enhancements that have a neutral impact on game balance. They should be included by default (unless there is controversy over a particular fix).

[Equipment Screen]
Show Stats=1
Weight=Weight>
Accuracy=Accur>
Reaction=React>
Psi Strength=P.Str>
Psi Skill=P.Skill>
Show Grenade State=1
Primed=primed
; Save Equipment is currently buggy but hopefully will be fixed soon
Save Equipment=0
Auto Flares=1

[Mod]
Save Reserve Mode=1
Rank In Inventory=1
Skip Intro=?
Base Building Stacking=1
Force Language=?
Reorder Soldiers In Crafts=1
De-equip Crafts=1
Assign All Personnel=1
Fast Base Defenses=1

[Battlescape Shortcuts]

[Geoscape Shortcuts]

=== Designer Intent ===

It's sometimes hard to agree designer's intent, but where we agree we should include these.

[Mod]
TFTD Doors=1
Stunned units KIA=1
More Smoke=1
; maybe reduce stun damage from Launchers but otherwise OK:
Stun Fest=1

However if these mods also affect game balance we should think long and hard. Possibly add a subsection:

==== Designer Intent but changes game balance ====

[Bug Fix]
; This makes the game a fair bit easier for XCom, also makes the game less interesting by eliminating any need for regular craft
Elerium-fueled Craft Bug=0

=== Alternate Scenarios ===

Features to permit different ways of playing the game, but not necessarily making it harder.

; Makes recoveries much more fun. Although gives more
; information than you would normally get, it is a very
; minor advantage and worth the compromise to original.
[Wreck Analysis]
Apply=?
Zone Discovered=Intel found out that the %s UFO was raiding %s
Mission Discovered=Inspection showed that the %s UFO was on an %s mission
Both Discovered=Ship investigation revealed that the %s UFO was on an %s mission in %s

; Makes it too easy to find scouts and crashing this often
; does not make sense given alien technology level.
[Roswell]
Apply=?
;Terrain names
Jungle=Jungle
Farm=Farm
Mountain=Mountain
Desert=Desert
Polar=Polar
;Dialog strings
Title=UFO Incident
Info=Crash reported
Location=LOCATION
Type=TYPE
Terrain=TERRAIN

; Needed to complete the game if not allowing any UFO detection
[Mod]
Keep Base Navigation Modules=?

; This makes the game easier but something similar is widely used by experienced players via XcomUtil
; Starting with such a badly designed base is frustrating and modifying the base every time gets boring.
; Starting with a well-designed base could be a good education for starting players.
[Initial Base]
Apply=1
row1=HangarTL HangarTR HangarTL HangarTR HangarTL HangarTR
row2=HangarBL HangarBR HangarBL HangarBR HangarBL HangarBR
row3=AccessLift Empty Empty Empty Empty Empty
row4=GeneralStores LivingQuarters SmallRadar Laboratory Workshop Empty
row5=Empty Empty Empty Empty Empty Empty
row6=Empty Empty Empty Empty Empty Empty

; Another enhancement that is often used via XcomUtil, on the basis that HE Packs are "otherwise useless".
; But many players think HE Packs do have a role. And being able to blow arbitrary holes in UFOs makes it much easier for XCom.
[OBDATA.DAT]
Apply=?
;Make HE packs capable of breaching UFO walls
High Explosive Damage=200

; For playing on even when the situation is hopeless
[Hack]
No Score Game Over=?

; This overpowered weapon makes the game easier but is loads of fun!
[Mod]
Heavy Laser=?

; For people who think a grenade has a fuse that you light with a match ;)
[Mod]
Hot Grenades=0

; Makes the game easier. This is not necessarily a bug, it could reasonably be understood as an intended feature.
[Bug Fix]
Transfered Crafts Refueled=0

; Very convenient for XCom and unbalances the resource side of the game in XCom's favour. Arguably unrealistic.
[Mod]
Crafts Always Ready=0

=== Making The Game Harder ===

Features to increase the level of challenge. Actually this may often overlap with the previous category of Alternate Scenarios. The distinction would be that these features '''always''' make the game harder, whereas the previous category are to help the player when the player '''voluntarily''' plays in an alternative way (which, probably, is a way of playing that makes the game more challenging)

[Mod]
No Funkers=0
Bloodthirst=0
Limited Military=0
Funding Council Income Only=0
Surrender Defence Missions=0
Disable Base Defenses=0
Initial Alien Bases=0
Retaliate Against Ground Assault=0
No Blaster Bomb Drift=0
More Reaction Fire=0
Alien Inventory=0

[Range Based Accuracy]
Apply=0
Minimum Efficiency=50
Snap Penalty Distance=30
Auto Penalty Distance=14
Orange Cursor Threshold=95
Red Cursor Threshold=75

[Line Of Fire Check]
Mind Control=0
Panic=0
Mind Probe=0

[Caps]
Apply=0
Time Units=80
Health=60
Strength=70
Energy=100
Reactions=100
Firing Accuracy=120
Melee Accuracy=120
Throwing Accuracy=120
Psi Skill=100

== Specific Feature Discussions ==

=== Range Based Accuracy ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - If you accept that the role of the standard config as being for the standard player, increasing difficulty for the experienced player would not by itself merit inclusion in the standard config. Things we add to the config to make things more challenging for the elite players might belong in a special 'superhuman plus' config file. Also, the official strategy guide and [[Firing_Accuracy_Testing|information]] on this site suggests that range is already factored into weapon accuracy and fairly balanced. In play, the anecdotal feel is that range does matter.

: Range does matter though only in so far as misses are less likely to accidentally hit at longer ranges. This fix actually reduces the chance of a purposeful hit at longer ranges and increasing the distance penalty for snap fire and even more so auto fire. It could perhaps be better explained! [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: My vote is that this is a Making The Game Harder feature. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

Ranged Based Accuracy doesn't sound like something that directly increase X-Com's difficulty. Doesn't it affect aliens too? If it doesn't, it should. --[[User:SnowJob|SnowJob]] 22:07, 5 July 2010 (EDT)

=== Mind Control Requires Line Of Sight for X-COM Squad ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - See standard config intent and superhuman plus alternative config concept above on difficulty argument. It doesn't seem like physical objects should block mind control in the fictional sense. Also, aliens are able to use it without line of sight (except for seeing the first X-COM soldier). I may be a bit confused here, though: Does the alien squad have to have line of sight on at least one X-COM soldier to be able to use mind control in turns after the aliens first spot an X-COM Soldier? Also, does enabling this make the X-COM soldier who is wielding the psi-amp have to have line of sight on the alien that soldier is going to target?

: Yes the alien squad needs LoS on at least one soldier at some point in the turn. But the same restriction already applies to XCom. I agree this can be put in the superhuman plus category. Not sure of the details of how it works. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

=== Retaliate Against Ground Assault ===

[[User:Spike|Spike]] - Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

[[User:Xeucom|Xeucom]] - I agree with you. Aliens behaving smarter and more logically improves the gameplay experience even if it slightly increases difficulty. I think anything that improves the AI reasoning belongs in the standard config as long as the AI is adhering to fog of war principles. I will enable this in the next standard config ini.

=== Blaster Bomb Drift ===

[[User:Spike|Spike]] - Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

[[User:Xeucom|Xeucom]] - Are you sure that drift only affects aliens? If so, is the blaster bomb overpowered without the drift? As far as I can tell, a direct or close hit from a blaster bomb is guaranteed death for a X-COM soldier, no matter the experience or suit. Would it be better to introduce blaster bomb drift to X-COM firings instead of removing it from the aliens? This seems like one of those random parts of the AI that makes them a little more unpredictable and therefore believable to me. I was reading a story on one of the missions-gone-wrong threads in the forums and an errant blaster bomb firing by the aliens really helped create a funny story.

:Agreed let's confirm that drift only affects aliens. Maybe this could go in Making The Game Harder. Blaster Bombs are terribly lethal so the alien drift is often a lifesaver. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: It's pretty obvious (from StrategyCore old posts, not personally verified) that drift affects XCOM as well; it's why you have to be careful when using a blaster bomb launcher from the Skyranger/Avenger entrance. [[User:Zaimoni|Zaimoni]] 10:21, 25 August 2009 (CDT)

::: OK but in practice this only affects the aliens, since the AI is too stupid to take precautions, whereas players quickly learn to allow some leeway. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Stun Fest ===

[[User:Spike|Spike]] - I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

[[User:Xeucom|Xeucom]] - Do you know that the original game manual has a screenshot with a 'Hit' option for a rifle? Therefore, I agree with you on intent of developers and that there should be a 'pistol whip' stun option for all/most weapons (or empty hand). However, the table at [[User:Seb76|seb's page]] suggests that the weapon values are not less than the stun rod in every case. It seems out of whack (no pun intended) for the missile launcher to do more stun damage than the stun rod, or even more stun damage than a rifle. It would be so bulky it would be harder to beat an alien with that than a pistol or rifle. So my vote is yes for (non-ranged) stun damage for non stun rod weapons, but I think we need to figure out the right balance for stun damage before adding it to the standard config.

:There are definitely some wacky hand to hand damage levels in the executable, normally unused, but I thought that Seb had overridden those values to more sensible levels. I'd better check. :) 04:47, [[User:Spike|Spike]] 04:49, 23 August 2009 (EDT)
::I checked and I would still say "less effective than a Stun Rod in every case". Though the Launchers do get a higher base damage than the Stun Rod, they can only attack once per turn and will use HTH accuracy instead of an automatic hit. Bludgeoning an alien with a weapon is always an act of desperation and less effective than a Stun Rod. But loads of fun and very atmospheric![[User:Spike|Spike]] 13:27, 24 August 2009 (EDT)

:::I see your point when you take into account the Time Units and the accuracy. You convinced me that it belongs in the standard config. [[User:Xeucom|Xeucom]] 18:30, 25 August 2009 (EDT)

=== Elerium Fueled Craft (Bug?) ===

[[User:Spike|Spike]] - While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

[[User:Xeucom|Xeucom]] - It just seems artificial to me that non-elerium craft return home when they are going to have to ditch if they don't, but the elerium craft turn around and head back at an arbitrary fuel level. What would the fictional explanation be? I understand your point about amping up difficulty, but for the standard config, I think consistency is more important. Inconsistency between craft behavior just looks buggy. There are other ways we could increase difficulty that would be much more impactful.

[[User:Spike|Spike]] - Agreed, it disturbs realism and consistency and jars the player experience. That's more important than a slight imbalance. I believe the conventional craft can still stay on station longer than Elerium craft, even with this bug fixed?

=== Craft Always Ready ===

[[User:Spike|Spike]] - I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

[[User:Xeucom|Xeucom]] - I have played with this on and think it is possible you may think that this does more than it does. The only thing that it allows you to do is to dispatch interceptors when they are rearming, refueling, and repairing. It doesn't put them back to 100% loadout, fuel, and integrity. So I think it is still balanced because you are limited to the full refits unless you want to scramble interceptors that only have a short range, or no arms, or are already damaged. I realize that normal rules of procedure would not be to relaunch until total refit is complete, but why not leave it up to the player/commander? In a desperate situation, I think any real-world air force would launch anything in whatever condition it is in and what can be more desperate than fighting aliens? :) Also, X-COM from a fictional perspective is a very odd entity. Some could view it as a professional military alliance of the other powers, but given how little you get and how poorly funded it is (and how you can be shut down by your creditors), it smacks more of a private mercenary corporation whose operational procedures may be largely ad hoc.

[[User:Spike|Spike]] - Agree most of those points. This is only slightly more powerful than just leaving the interceptor in the air on patrol after combat. (It's slightly more powerful because you do get to refuel/rearm while waiting for the next target.) The imbalance I'm talking about is that it makes it possible to maintain one interceptor per base instead of needing two. This has a biggish effect on your cost base early in the game. If there was a balancing "side effect" of launching with low fuel / weapons / repairs, I would be totally happy. As it is, I guess it's not too badly unbalancing.

[[User:Zaimoni|Zaimoni]] - You still need two Interceptors per base to conveniently shoot down Terror Ships before Plasma Cannons, or to conveniently shoot down all non-Battleships in the acts with finales (Infiltration, Base) with Plasma Cannons.

=== Base Navigation Modules ===

[[User:Spike|Spike]] - Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

[[User:Xeucom|Xeucom]] - I agree with you and will also include this in the next standard config file. My only discomfort is the explanation of why there are navigation modules at a base, but let's rack that up to spares in hangars.

: Actually in the unmodified game, the base control consoles (destroyed to win the base mission) are Navigation modules. The patch simple captures them intact, instead of destroying them. Equally, we could imagine there are some spares in the base stores. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Modified Initial Base Layout ===

[[User:Spike|Spike]] - Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

[[User:Xeucom|Xeucom]] - This makes sense to me, so I think this should go in the standard config as well. I think the key point you made is avoiding tedium for the player - features that do that without significantly unbalancing should probably go in standard config as matter of course.

=== Base Building Stacking ===

[[User:Spike|Spike]] - Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

[[User:Xeucom|Xeucom]] - My only qualm here is that this seems like a complex feature from a programming perspective that could be risky. Have you played with it a lot and not noticed any increase in crashes or bugs with bases? It doesn't really add anything except being able to lay out the facilities in game sooner - you could still get the same facilities in the same amount of time just waiting for completion messages. The other thing I note with this is that if you turn it off on a game where you have laid out some to-build facilities, bases get funky in with 255 overlayed n the extended modules instead of "Queued". However, for the standard config, I think we should assume that the player will play through the entire game without changing the settings, because otherwise trying to figure out all the possible scenarios would become overwhelming. If you are satisfied that this does not introduced bugginess, I could go for it for the standard config.

[[User:Spike|Spike]] - Well that is a fair point. I have not used the feature enough to swear there are no bugs. Maybe it is safer to leave this as an optional thing that people can enable if they want to.

=== Assign All Personnel ===

[[User:Spike|Spike]] - Highly useful.

[[User:Xeucom|Xeucom]] - I didn't add this to the initial standard config because I don't understand what it does. Can you explain? Also, is it helpful enough to merit the increased risk of negative side effects (crashed, other bugs) when its complexity is considered?

[[User:Spike|Spike]] Basically in various screens this lets you hit the down arrow when the counter is at zero, and the counter goes UP to the highest possible value. This saves you from having to scroll up from 0 to say 100 Scientists, 100 Engineers, etc, whenever starting a new research or manufacturing project. The scrolling speed can be very slow, depending on your machine. This is a very simple mod so I would expect it to be bulletproof from a bug point of view.

[[User:Xeucom|Xeucom]] - Let's call it in for the standard config, then.

=== Save Equipment ===

[[User:Xeucom|Xeucom]] - Spike, I saw that you mentioned in the settings above that you had Save Equpiment turned off because it was buggy. Could you explain? I have used it for some time in my current game and it seems to be working ok. There are some strange things where I am not able to extend the ground portion with the right button and sometimes when I assign a weapon to a soldier it doesn't appear in their hand until I click on one of the slots again. However, I have not verified if this happens with/without UFO Extender or the Save Equipment setting. Since the standard config should aim for bug free, if you think have observed bugs, we should probably leave it out until it is more stable.

: Agreed. There are definitely known bugs with this feature and it is currently described as "Highly Experimental". But once it's working reliably this is a top candidate for inclusion in the standard configuration. [[User:Spike|Spike]] 19:32, 29 August 2009 (EDT)

=== Funky Fire ===

[[User:Spike|Spike]] - This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

[[User:Xeucom|Xeucom]] - The way I understand this it is that the smoke and explosive damage end of turn checks were probably getting applied every time an incendiary shell went off. I think seb76 simply stopped that from happening so that only the entities inside the incendiary shell blast radius took damage and then he increased maximum fire damage from 5 to 10 to compensate for a possible lower fire damage value the original developers put in to offset the bug. From my personal observations, it seems to me that smoke damage is too low and should probably be raised as well because units can spend a lot of time in it without passing out, but that's just an opinion. For the standard config, it sounds like we are in agreement to leave it in because it makes no sense for explosions in other areas of the map to affect other units.

: Yes the illogical behavior is fixed & that's good enough reason to include this fix. My understanding of the fix is that smoke/fire effects only occur at end of turn. This reduced the power of Incendiary weapons a lot, even if not using the Exploit. To partly compensate, Seb has doubled the average damage from fire. There's no exact way to compensate but this is a reasonable approach IMO. [[User:Spike|Spike]] 19:25, 29 August 2009 (EDT)

:: [[User:Xeucom|Xeucom]] - With the fix enabled, if I hit a sectoid with three incendiary shells in one turn, will I do no damage to the sectoid until the turn ends? Or will the sectoid take hit damage (of incendiary type?) on each hit, but no general fire damage from being in a fire square until end of turn?
::: Fire damage will only be applied at the end of the turn. That's why I buffed fire damage up a bit. [[User:Seb76|Seb76]] 13:52, 30 August 2009 (EDT)
:::: In our investigations, we deduced that the so called "incendiary impact damage" is itself an aspect of the bug. And it makes sense that incendiary damage should not take effect as promptly as a bomb,a bullet or a plasma beam. But this does change the play of the game. I don't think it makes much difference apart from people who were exploiting the Funky Fire exploit. But if there was anyone out there who was consistently firing multiple IN rounds at single targets, one at a time, their game play experience will change with this fix. I think it's worth at least a note that this is not just a bug fix but also includes some unavoidable changes in game play. [[User:Spike|Spike]] 04:14, 31 August 2009 (EDT)
::::: This would explain why once when I was facing off against sectoids I had a couple units with incendiaries (night mission, using them to light the place up) and unloaded on a sectoid. After the sixth shell on target, I was like, "Why won't you die!?" Now I understand. However, I think the behavior with Funky Fire makes the most sense because you don't get the random effects from other areas of the map and, really, if you pour a flammable over something and get it coated pretty well, adding more flammable isn't going to really do more damage, so stacking six incendiary shells in an area shouldn't necessarily do more damage to a unit there, just make the fire bigger, which happens naturally anyway because of the deviation in the squares hit. Not quite realistic, but seb76's uptick in fire damage is a fair compromise I think. [[User:Xeucom|Xeucom]] 11:47, 31 August 2009 (EDT)
What are the effects on Zombies? [[User:Magic9mushroom|Magic9mushroom]] 09:55, 1 September 2009 (EDT)

=== Aliens Take Fatal Wounds Damage ===

[[User:Xeucom|Xeucom]] - Saw seb76 made a new release with some new options, so of course have to discuss them for the standard config. :) Starting with this one, this one is a tough call. It's more realistic that aliens could also have fatal wounds. On one hand it makes game easier because injured aliens will die even if they move out of sight and quicker in general if taking damage from fatal wounds. On the other hand, makes game harder because of difficulty capturing live aliens (stunned aliens with fatal wounds likely to die). Can aliens be healed of their fatal wounds with a med kit? If so, introduces entertaining mini-game when trying to capture an alien where you have to stabilize it if injured, perhaps in conjunction with stunning it. A perhaps significant balance problem that arises is X-COM team can have medics with med kits who will heal injured team mates. I suspect this change comes without changes to AI, meaning that aliens will not use med-kits to help each other out. Thoughts?

: I would guess the small number of extra kills from wounds is well-balanced by the scenario you describe, the difficult scenario of trying to stabilise a wounded captive alien, or rush him to the transport before it dies. As this is a new fix we might want to be sure that the alien's death from wounds is handled normally - that correct points are awarded, the game ends properly, etc. Also what happens when a wounded being swaps sides during and after mind control. But (subject to that testing?) I think this one should be included. [[User:Spike|Spike]] 08:50, 1 September 2009 (EDT)

:: The question becomes how do you know you need to stabilise the alien? I can see two ways. First, the mind probe will show you that a standing alien has fatal wounds that you will need to heal once you stun him. Secondly, if medi-kit works on a stunned alien (that's a big if), the display would show you the area hurt (though this may not make sense since I don't think all the aliens are humanoid). I guess this could use some testing to see if the fatal wounds show on mind probe, if you can heal an alien with a med-kit, etc. I like that it opens a new storyline - having to rush the Snakeman Commander to the evac point before he dies, perhaps involving a medic meeting you half way. [[User:Xecuom|Xeucom]] 18:02, 1 September 2009 (EDT)

::: I tested most of the main considerations and they check out OK - see [[User talk:Seb76#Alien Bleeding|here]]. I wasn't able to test the Mind Probe, but you can use the Medkit itself to determine if an aline has any wounds that might need treating. But yes the Mind Probe would be better, since it gives the Health as well, so you can calculate if the alien will die before you can complete the mission. I really expect the Mind Probe will work, since it does normally show the Wound level of aliens - it's just usually always zero. [[User:Spike|Spike]] 20:36, 2 September 2009 (EDT)

=== Unarmed Aliens Pick Up Weapons ===

This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. It would be a very helpful rebalancing of the game that eliminates one of the aliens' weak spots. [[User:Spike|Spike]] 14:44, 3 April 2011 (EDT)

== probability of hit display ==

It would be great if next to the crosshair there would be a percentage indicating the probability of a good hit like in UFO Extraterrestrials.

== May i remake the main page of this article ==

Sorry im new to here so i dont know if i should do it right away or asking someone is polite beforehead or it should be left as is and instead second artice should be added, but:

I have thoughts for current page "Enemy Unknown Extended"
I am willing to write another article, correcting the following:

1) Recently, Xcomutils 6.7 have support for ufoextender. This means, among others, that we no longer need those patches since xcomutils applies them all! It even applies voices and old sounds (more than voices!) but you have to run setup again
2) The supplied INI is old and doenst have every key that new ufoextender uses. This should be avoided imho as the person who dl's it has often litte knowledge to find the hidden options (have to look at the page at this site) or add it (have to copypaste strings from original ini which isnt convinient)
3) For some people (inc me) mp3 solution wont work, for them an explanation how to use PSX Cd would be nice.

Therefore, i'd like to make theese changes:

1) Overview - add that recent 6.7 xcomutils beta build supports ufoextender and so we can use EU+Extender+Xcomutils for a very rich enchanced gameplay
2) Download - remove patches and ini, add xcomutil
3) Verify - accordingly to 2
4) Modify - change to "Patching process" or something as for me, modify isnt that obvious, and then, write here an exact series of steps needed to configue them to work
5) Make shortcut - change to use runxcom.bat

Then i'd like to add "If usage of mp3 causes game to crash" or something with explanation how to use psx cd for music instead
[[User:Istrebitel|Istrebitel]]

:This is a Wiki so everyone can edit anything. But thanks for asking first, that is considered polite, especially before modifying an article page with something that might be seen as a matter of opinion. Could you maybe post your proposed new text here on the Talk page? Also, please sign your posts with 4 tilde characters (~). [[User:Spike|Spike]] 14:39, 3 April 2011 (EDT)

<strike>:I'm a little confused here. You say that XcomUtil 6.7 has UFOextender support, but the lastest version available on the XcomUtil Homepage is XcomUtil 9.60 and I can verify that it very much does not work with UFOextender without some modding to recombine geoscape.exe and tactical.exe back into a single executable since UFOextender crashes if you try to use it to load tactical.exe. Scott's homepage does mention handing over control, but it only gives an email address.[[User:Mannon|Mannon]] 18:21, 3 April 2011 (EDT)
:Another concern is XcomUtil by default makes several changes to the core game, in particular it alters the crafts, making them hold more soldiers. It goes so far as to change the craft's map files (I hate the Avenger, it no longer looks like the UFOpedia entry, but like a fat flying brick.) It even makes the interceptors capable of carrying soldiers. There is no option to turn this off without altering XCUSetup.bat or at least editing XcomUtil.cfg and doing something to fix the Avenger map. I'm not sure how to make those changes easy for someone short of supplying them with an alternate XCUSetup.bat and/or XcomUtil.cfg. Though there are definitely some nice benefits to having XcomUtil installed.[[User:Mannon|Mannon]] 18:29, 3 April 2011 (EDT)</strike>
::Oh NVM. I see that you meant 9.7. I found it and will have to give it a look.[[User:Mannon|Mannon]] 18:43, 3 April 2011 (EDT)

Talk:Enemy Unknown (1994) Extended

2011-04-03T22:29:10Z

Mannon: /* May i remake the main page of this article */

= General Discussion =

This is very useful, putting all these things together in one place with clear instructions. This could become the new "standard" version of the game. But I think it's only fair to explain that a lot of the choices you have made for the UFOExtender.ini file are personal choices - you should advise user to review your .ini file (and helpful explanatory comments) and see if they agree.

[[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

In general if we have a mix of features in the standard config, some of which give a minor advantage to XCom (Craft always ready, Elerium fuelled craft bug fix), some of which give a minor advantage to the aliens (Retaliate for Ground Assault), that should work out ok. Features that give a major advantage one way or the other should not be in standard config. [[User:Spike|Spike]] 07:56, 26 August 2009 (EDT)

= UFO Extender Templates =

I think your comments to the .ini file are very helpful. Here are some alternative opinions on some of the options:

*Range Based Accuracy
*[MC] Line of Fire Check

- These are to make the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

*Retaliate Against Ground Assault

- Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

*No Blaster Bomb Drift

- Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

- Maybe you could group the above options together as they all make the game more challenging, i.e. balance the game more in favour of the aliens, and explain that to the player - if you want to make the game more evenly balanced, select these options.

*Tactical Scroll
*Video Pitch
*Music Change Freeze

- You were not experiencing these issues, but others do experience it, so this is an important thing to make clear to users. They should check themselves.

*Elerium-fuelled Craft Bug

- While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

*Funky Fire

- This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

*Crafts Always Ready

- I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

*Keep Base Navigation Modules

- Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

*Base Building Stacking "too complex for benefit"

- Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

*Stun Fest "overpowered"

- I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

*Assign All Personnel

- This is a real time saver

*Hacks

Most of them are deliberate cheats and not meant for normal play so you're right to say they are hugely unbalancing.

However Recover All Clips is a kind of bug fix. Though it does give advantage to XCom it also eliminates the irritating need to manage ammo logistics. With human ammo this is not unbalancing. With scarce alien ammo, it could be, fair enough. No Score Game Over is a way of continuing "hopeless" games. Both of these have precedents in XComUtil, which a lot of players use.

*Initial Base

Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

Lastly, but not least, as Seb76 did so much of the work on UFOExtender, maybe you should give him a credit on the page? And add his UFOExtender page to the See Also?

Cheers, [[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

Spike, thanks. Yes, the choices I made were personal ones informed mostly by my (poor) memories of 15 years ago just to get the ball rolling. This is exactly the discussion I want to have because I think it would be good to come up with a consensus config for a standard version of X-COM for people who just want to get right into the game. I will review your points in detail, rethink the ini config., and make it more clear that seb's UFO Extender is the centerpiece. By the way, this talk page is a hard place to have a discussion - are strategycore forums better? [[User:Xeucom|Xeucom]] 01:57, 20 August 2009 (EDT)

: Hey, great to have you back after 15 years! Sure let's figure out a consensus. Actually I was thinking we might be able to make a few different .ini templates based on some themes, eg:

:* Bug fixes only
:* Convenience features
:* "What the designers intended"
:* Making the game harder
:* Alternate scenarios

:...etc. At the moment I'm trying to recover my account on StrategyCore (I want to post to Zombie's thread on offsets/modding). So when I get my account back I'm happy to talk there. Cheers! [[User:Spike|Spike]] 14:12, 20 August 2009 (EDT)

::Do you remember what your account name is or what email you used to register? If so, I can set you up in a hurry. Just send me an email. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

:: A menu of configs is a good idea. I'd still say we should sweep up a balanced Bug Fixes, Conveneince Features, and Designers Intent into a consensus standard config and establish that as our base line. This is all meant to lure people in/back with a quick and easy setup, get them some play time, then let them explore all the neat options UFO Extender allows. The base line also gives us a standard testing config that we can focus on making bug free (or documenting workarounds). --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

::: Ok that sounds like a plan!

[[User:Spike|Spike]] 05:25, 22 August 2009 (EDT)

: Actually, using a rewritten Initial Base (with a real base) with the stock starting inventory will give you serious cashflow management problems. "Retaliate Against Ground Assault" fixes the cashflow problem, and I'm unclear whether it makes the game easier or harder for X-COM. (I generally have an easier time the first three months on Superhuman than on Beginner, as the extra cashflow from the increased Retalation Acts more than compensates for equally dumb AI with more accurate ranged attacks.) -- [[User:Zaimoni|Zaimoni]] 04:42, 22 August 2009 (CDT)

= Small Scout Map =

Does the Combo Pack include Zombie's Small Scout Map fix? If not, maybe that should be included too. [[User:Spike|Spike]] 14:37, 20 August 2009 (EDT)

:I don't have anything in the kit for the Small Scout because nothing is wrong with it. LOL I do, however, have a Small Scout Mod ([http://www.strategycore.co.uk/files/index.php?dlid=710 found here]) which reintroduces the old Small Scout lefover from the development days. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

::I didn't include the Small Scout patch because it seemed too little gain for the additional step of installing it since people are installing it by manual steps. There is already a very small scout in the game (the one you can grav lift into one square with hole in top) The ideal would be if someone could cook up a little exe that downloaded all the mods and installed them (or we got permission from the authors to bake it into one download) so it was one download and double click. Then it would make sense to add in some more one-trick mods. --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

= Standard Config Discussions =

This section is for discussing what should go in the standard UFO Extender config that is recommended as the downloadable ini file. The concept of the standard config is a config that fixes bugs, introduces convenience features, and retains or improves game balance while keeping the original feel. It is intended for the new or returning player who can put up with a moderate level of difficulty, but is not an elite player (Spike, I will add more sections as I have time to address all the points you raised - these are the ones I had time to research and think about with your feedback).

== Game Version ==

There could be a problem in that the publicly available version of the game is the DOS version released by Steam. The Windows CE version is arguably no longer in the public domain, since Steam now has made its version available. At this time, only one site I can find is still offering downloads of the Windows CE edition. It could be considered the Windows CE edition is no longer "abandonware", and this seems to be the view that the operators of download sites are taking. Therefore, if looking for a reference edition, maybe we should look to modding the Steam, DOS, edition. The problem is that Seb76's loader only works on the Windows CE edition.

I think we should go ahead and define the features of a "standard edition" anyway, but the problem of what version to use will still need to be solved. Basically either the fan community (us!) extends Seb's loader to also apply to the Steam DOS version, or we need to use another tool to patch the DOS version. In theory, XcomUtil could be used to patch the DOS version to introduce all of Seb's additional patches. It is arcane to use but it could be done. The key first step would be to establish a list of patches for the DOS version that are equivalent to Seb's patches to the Windows version.

:Both the Steam and GamersGate (according to forums on the latter) downloads include the Windows version. Specifically, they have a "UFO Defense.exe". I have tested the described mod set with Steam. Steam launches the DosBox DOS version by default through the steam interface, but once you create the shortcut as described, you never use it again. Does that alleviate this concern? [[User:Xeucom|Xeucom]] 09:30 August 23, 2009.

:: You are right! I tested it and, to my surprise, it works. I guess the Steam version must be the Windows CE version, even though it launches it via DosBox. Cool, so there is no problem there - quite the contrary, if all these mods work on the Steam distribution that's excellent. And maybe we can persuade Steam to distribute the "standard extended" version some day. Perhaps not, as we are sort of bypassing their security. Normally when you try to start the executable it should chain back to all the Steam software. In this case, I think we get by that because Seb's loader treats the executable as sort of a data file, loading it rather than directly executing it from the O/S, and also the loader controls the entry points itself (guessing?). Anyway, I suspect Steam don't really care too much about software protection on the old XCom games. [[User:Spike|Spike]] 06:49, 24 August 2009 (EDT)

== Categories ==

Group all fixes into categories:

=== Bug Fixes ===

==== General Bug Fixes ====

All undisputed bugs should be fixed here.

[Bug Fix]
Pay For Dirt=1
Phantom Radar=1
Base Disjoint=1
Radar Stacking=1
Base Facility Dismantle-Construction Crash=1
Collectors Edition Blaster Bomb Bug=1
Proximity Grenades=1
Proximity Grenades Experience=1
Door Jam=1
Personnel Overflow=1
Funky Fire=1
Displayed Base Maintenance Cost=1

[OBDATA.DAT]
Apply=1
;Make grenades indestructible to allow stacking several explosions
Grenade Resistance=255
Proximity Grenade Resistance=255
High Explosive Resistance=255

==== Technical ====

Audio/Video bugfixes or tweaks and other things that some experience, some do not, depending on their platform. Should all be optional and to be set up by the end user. (Possibly video pitch should default to 1, since if it's not enable it can be hard to recover from the screen crash? Which might put users off the "standard extended" package?)

[Bug Fix]
Video Pitch=?
Intro Sounds=?
Music Change Freeze=?
Tactical Scroll=?

[Mod]
HQ4x=?
D3D=?
Scale Mouse=?

[Music]
Apply=1
Source=MP3
;Source=PSX CD
CD Drive=F
MP3 Folder=mp3
Battlescape=*Battlescape*.mp3
Start Menu=*Final Briefing*.mp3
Bad Ending=*Final Briefing*.mp3
Good Ending=*Dogfight*.mp3
Geoscape=*Geoscape*.mp3
Dogfight=*Dogfight*.mp3
Mission Debriefing=*Debriefing*.mp3
UFO Assault=*Briefing1.mp3
Base Defense=*Briefing2.mp3
Base Attack=*Briefing1.mp3
Mars=*Debriefing*.mp3
Terror Mission=*Briefing2.mp3

==== Closed Exploits ====

We ''might'' want to make it optional to close exploits and make that separate from bug fixes. The difference being that bug fixes help the player or are neutral, whereas closing an Exploit by definition makes it relatively harder for the player. Personally I don't like to encourage the use of exploits, but it's an option.

(For now the exploit-closing features have been included in other sections)

:My opinion is that all obvious (in the sense that it is clearly not balanced, not that it is easy to find) exploits should be closed in the standard config. If a player stumbles into an exploit, they can become frustrated because the supension of disbelief and challenge is lost. The game ends up simply looking inconsistent. - [[User:Xeucom|Xeucom]] 19:11 August 25, 2009.

:: I completely agree. You will get some people who routinely rely on certain Exploits, who might not agree. But then they can always change the config file. Probably the most frequently used Exploits are - [[ExploitsA#Free Wages|Free Wages]], [[ExploitsA#Free Manufacturing|Free Manufacturing]], [[Known Bugs#Funky Fire|Funky Fire]], Access Alien Inventory. The [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Robotic Research]] exploits are infrequently used but are massive and should definitely be closed down. [[Exploiting Mind Control#Access the Alien Inventory Screen|Access Alien Inventory]] is arguably not an exploit but merely enables "What The Designers Intended". After all, it seems logical that XCom Psi Troops should be able to access a victim's inventory, just as alien psi attackers can do. It's not in itself unbalancing (or, not any more than Psi itself is). In fact for aliens with only built in attacks it's kind of necessary to make Psi useful on those aliens. It only really becomes unbalancing through the use of [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]. Exponential Mind Control should probably be closed as an Exploit, but I'm not aware of any existing patch that closes it (other than by disabling Access Alien Inventory, which as I've said here is probably not justified). [[Exploiting Mind Control#Zombie's Permanent Control of Aliens via Stunning|Permanent Mind Control]] and the [[Exploiting Mind Control#Resurrect Zombified Agents|Zombie Resurrection]] techniques should also be closed down. [[User:Spike|Spike]] 07:44, 26 August 2009 (EDT)

::[[Tactical Exploits#Elevator Shielding|Elevator Shielding]], which enables risk-free [[Tactical Exploits#Milking Alien Bases|Alien Base Milking]], should also be closed, but again I'm not aware of any fix. [[Grenade Relay]]s, and all similar [[Grenade Relay#Relaying other Equipment|item relays]] - any tactic which allows one item/weapon to be used multiple times per turn by passing it through the hands of multiple soldiers and thereby applying more than 100% TUs to it - are minor and not really important to close down, even though they are a bit silly. [[ExploitsA#Infinite Fuel|Infinite Fuel]] is not so destabilizing as to need closing down as an Exploit, but it probably should be closed just as a bug. [[User:Spike|Spike]] 12:00, 26 August 2009 (EDT)

=== Convenience Features ===

These are logistic or interface enhancements that have a neutral impact on game balance. They should be included by default (unless there is controversy over a particular fix).

[Equipment Screen]
Show Stats=1
Weight=Weight>
Accuracy=Accur>
Reaction=React>
Psi Strength=P.Str>
Psi Skill=P.Skill>
Show Grenade State=1
Primed=primed
; Save Equipment is currently buggy but hopefully will be fixed soon
Save Equipment=0
Auto Flares=1

[Mod]
Save Reserve Mode=1
Rank In Inventory=1
Skip Intro=?
Base Building Stacking=1
Force Language=?
Reorder Soldiers In Crafts=1
De-equip Crafts=1
Assign All Personnel=1
Fast Base Defenses=1

[Battlescape Shortcuts]

[Geoscape Shortcuts]

=== Designer Intent ===

It's sometimes hard to agree designer's intent, but where we agree we should include these.

[Mod]
TFTD Doors=1
Stunned units KIA=1
More Smoke=1
; maybe reduce stun damage from Launchers but otherwise OK:
Stun Fest=1

However if these mods also affect game balance we should think long and hard. Possibly add a subsection:

==== Designer Intent but changes game balance ====

[Bug Fix]
; This makes the game a fair bit easier for XCom, also makes the game less interesting by eliminating any need for regular craft
Elerium-fueled Craft Bug=0

=== Alternate Scenarios ===

Features to permit different ways of playing the game, but not necessarily making it harder.

; Makes recoveries much more fun. Although gives more
; information than you would normally get, it is a very
; minor advantage and worth the compromise to original.
[Wreck Analysis]
Apply=?
Zone Discovered=Intel found out that the %s UFO was raiding %s
Mission Discovered=Inspection showed that the %s UFO was on an %s mission
Both Discovered=Ship investigation revealed that the %s UFO was on an %s mission in %s

; Makes it too easy to find scouts and crashing this often
; does not make sense given alien technology level.
[Roswell]
Apply=?
;Terrain names
Jungle=Jungle
Farm=Farm
Mountain=Mountain
Desert=Desert
Polar=Polar
;Dialog strings
Title=UFO Incident
Info=Crash reported
Location=LOCATION
Type=TYPE
Terrain=TERRAIN

; Needed to complete the game if not allowing any UFO detection
[Mod]
Keep Base Navigation Modules=?

; This makes the game easier but something similar is widely used by experienced players via XcomUtil
; Starting with such a badly designed base is frustrating and modifying the base every time gets boring.
; Starting with a well-designed base could be a good education for starting players.
[Initial Base]
Apply=1
row1=HangarTL HangarTR HangarTL HangarTR HangarTL HangarTR
row2=HangarBL HangarBR HangarBL HangarBR HangarBL HangarBR
row3=AccessLift Empty Empty Empty Empty Empty
row4=GeneralStores LivingQuarters SmallRadar Laboratory Workshop Empty
row5=Empty Empty Empty Empty Empty Empty
row6=Empty Empty Empty Empty Empty Empty

; Another enhancement that is often used via XcomUtil, on the basis that HE Packs are "otherwise useless".
; But many players think HE Packs do have a role. And being able to blow arbitrary holes in UFOs makes it much easier for XCom.
[OBDATA.DAT]
Apply=?
;Make HE packs capable of breaching UFO walls
High Explosive Damage=200

; For playing on even when the situation is hopeless
[Hack]
No Score Game Over=?

; This overpowered weapon makes the game easier but is loads of fun!
[Mod]
Heavy Laser=?

; For people who think a grenade has a fuse that you light with a match ;)
[Mod]
Hot Grenades=0

; Makes the game easier. This is not necessarily a bug, it could reasonably be understood as an intended feature.
[Bug Fix]
Transfered Crafts Refueled=0

; Very convenient for XCom and unbalances the resource side of the game in XCom's favour. Arguably unrealistic.
[Mod]
Crafts Always Ready=0

=== Making The Game Harder ===

Features to increase the level of challenge. Actually this may often overlap with the previous category of Alternate Scenarios. The distinction would be that these features '''always''' make the game harder, whereas the previous category are to help the player when the player '''voluntarily''' plays in an alternative way (which, probably, is a way of playing that makes the game more challenging)

[Mod]
No Funkers=0
Bloodthirst=0
Limited Military=0
Funding Council Income Only=0
Surrender Defence Missions=0
Disable Base Defenses=0
Initial Alien Bases=0
Retaliate Against Ground Assault=0
No Blaster Bomb Drift=0
More Reaction Fire=0
Alien Inventory=0

[Range Based Accuracy]
Apply=0
Minimum Efficiency=50
Snap Penalty Distance=30
Auto Penalty Distance=14
Orange Cursor Threshold=95
Red Cursor Threshold=75

[Line Of Fire Check]
Mind Control=0
Panic=0
Mind Probe=0

[Caps]
Apply=0
Time Units=80
Health=60
Strength=70
Energy=100
Reactions=100
Firing Accuracy=120
Melee Accuracy=120
Throwing Accuracy=120
Psi Skill=100

== Specific Feature Discussions ==

=== Range Based Accuracy ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - If you accept that the role of the standard config as being for the standard player, increasing difficulty for the experienced player would not by itself merit inclusion in the standard config. Things we add to the config to make things more challenging for the elite players might belong in a special 'superhuman plus' config file. Also, the official strategy guide and [[Firing_Accuracy_Testing|information]] on this site suggests that range is already factored into weapon accuracy and fairly balanced. In play, the anecdotal feel is that range does matter.

: Range does matter though only in so far as misses are less likely to accidentally hit at longer ranges. This fix actually reduces the chance of a purposeful hit at longer ranges and increasing the distance penalty for snap fire and even more so auto fire. It could perhaps be better explained! [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: My vote is that this is a Making The Game Harder feature. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

Ranged Based Accuracy doesn't sound like something that directly increase X-Com's difficulty. Doesn't it affect aliens too? If it doesn't, it should. --[[User:SnowJob|SnowJob]] 22:07, 5 July 2010 (EDT)

=== Mind Control Requires Line Of Sight for X-COM Squad ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - See standard config intent and superhuman plus alternative config concept above on difficulty argument. It doesn't seem like physical objects should block mind control in the fictional sense. Also, aliens are able to use it without line of sight (except for seeing the first X-COM soldier). I may be a bit confused here, though: Does the alien squad have to have line of sight on at least one X-COM soldier to be able to use mind control in turns after the aliens first spot an X-COM Soldier? Also, does enabling this make the X-COM soldier who is wielding the psi-amp have to have line of sight on the alien that soldier is going to target?

: Yes the alien squad needs LoS on at least one soldier at some point in the turn. But the same restriction already applies to XCom. I agree this can be put in the superhuman plus category. Not sure of the details of how it works. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

=== Retaliate Against Ground Assault ===

[[User:Spike|Spike]] - Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

[[User:Xeucom|Xeucom]] - I agree with you. Aliens behaving smarter and more logically improves the gameplay experience even if it slightly increases difficulty. I think anything that improves the AI reasoning belongs in the standard config as long as the AI is adhering to fog of war principles. I will enable this in the next standard config ini.

=== Blaster Bomb Drift ===

[[User:Spike|Spike]] - Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

[[User:Xeucom|Xeucom]] - Are you sure that drift only affects aliens? If so, is the blaster bomb overpowered without the drift? As far as I can tell, a direct or close hit from a blaster bomb is guaranteed death for a X-COM soldier, no matter the experience or suit. Would it be better to introduce blaster bomb drift to X-COM firings instead of removing it from the aliens? This seems like one of those random parts of the AI that makes them a little more unpredictable and therefore believable to me. I was reading a story on one of the missions-gone-wrong threads in the forums and an errant blaster bomb firing by the aliens really helped create a funny story.

:Agreed let's confirm that drift only affects aliens. Maybe this could go in Making The Game Harder. Blaster Bombs are terribly lethal so the alien drift is often a lifesaver. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: It's pretty obvious (from StrategyCore old posts, not personally verified) that drift affects XCOM as well; it's why you have to be careful when using a blaster bomb launcher from the Skyranger/Avenger entrance. [[User:Zaimoni|Zaimoni]] 10:21, 25 August 2009 (CDT)

::: OK but in practice this only affects the aliens, since the AI is too stupid to take precautions, whereas players quickly learn to allow some leeway. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Stun Fest ===

[[User:Spike|Spike]] - I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

[[User:Xeucom|Xeucom]] - Do you know that the original game manual has a screenshot with a 'Hit' option for a rifle? Therefore, I agree with you on intent of developers and that there should be a 'pistol whip' stun option for all/most weapons (or empty hand). However, the table at [[User:Seb76|seb's page]] suggests that the weapon values are not less than the stun rod in every case. It seems out of whack (no pun intended) for the missile launcher to do more stun damage than the stun rod, or even more stun damage than a rifle. It would be so bulky it would be harder to beat an alien with that than a pistol or rifle. So my vote is yes for (non-ranged) stun damage for non stun rod weapons, but I think we need to figure out the right balance for stun damage before adding it to the standard config.

:There are definitely some wacky hand to hand damage levels in the executable, normally unused, but I thought that Seb had overridden those values to more sensible levels. I'd better check. :) 04:47, [[User:Spike|Spike]] 04:49, 23 August 2009 (EDT)
::I checked and I would still say "less effective than a Stun Rod in every case". Though the Launchers do get a higher base damage than the Stun Rod, they can only attack once per turn and will use HTH accuracy instead of an automatic hit. Bludgeoning an alien with a weapon is always an act of desperation and less effective than a Stun Rod. But loads of fun and very atmospheric![[User:Spike|Spike]] 13:27, 24 August 2009 (EDT)

:::I see your point when you take into account the Time Units and the accuracy. You convinced me that it belongs in the standard config. [[User:Xeucom|Xeucom]] 18:30, 25 August 2009 (EDT)

=== Elerium Fueled Craft (Bug?) ===

[[User:Spike|Spike]] - While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

[[User:Xeucom|Xeucom]] - It just seems artificial to me that non-elerium craft return home when they are going to have to ditch if they don't, but the elerium craft turn around and head back at an arbitrary fuel level. What would the fictional explanation be? I understand your point about amping up difficulty, but for the standard config, I think consistency is more important. Inconsistency between craft behavior just looks buggy. There are other ways we could increase difficulty that would be much more impactful.

[[User:Spike|Spike]] - Agreed, it disturbs realism and consistency and jars the player experience. That's more important than a slight imbalance. I believe the conventional craft can still stay on station longer than Elerium craft, even with this bug fixed?

=== Craft Always Ready ===

[[User:Spike|Spike]] - I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

[[User:Xeucom|Xeucom]] - I have played with this on and think it is possible you may think that this does more than it does. The only thing that it allows you to do is to dispatch interceptors when they are rearming, refueling, and repairing. It doesn't put them back to 100% loadout, fuel, and integrity. So I think it is still balanced because you are limited to the full refits unless you want to scramble interceptors that only have a short range, or no arms, or are already damaged. I realize that normal rules of procedure would not be to relaunch until total refit is complete, but why not leave it up to the player/commander? In a desperate situation, I think any real-world air force would launch anything in whatever condition it is in and what can be more desperate than fighting aliens? :) Also, X-COM from a fictional perspective is a very odd entity. Some could view it as a professional military alliance of the other powers, but given how little you get and how poorly funded it is (and how you can be shut down by your creditors), it smacks more of a private mercenary corporation whose operational procedures may be largely ad hoc.

[[User:Spike|Spike]] - Agree most of those points. This is only slightly more powerful than just leaving the interceptor in the air on patrol after combat. (It's slightly more powerful because you do get to refuel/rearm while waiting for the next target.) The imbalance I'm talking about is that it makes it possible to maintain one interceptor per base instead of needing two. This has a biggish effect on your cost base early in the game. If there was a balancing "side effect" of launching with low fuel / weapons / repairs, I would be totally happy. As it is, I guess it's not too badly unbalancing.

[[User:Zaimoni|Zaimoni]] - You still need two Interceptors per base to conveniently shoot down Terror Ships before Plasma Cannons, or to conveniently shoot down all non-Battleships in the acts with finales (Infiltration, Base) with Plasma Cannons.

=== Base Navigation Modules ===

[[User:Spike|Spike]] - Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

[[User:Xeucom|Xeucom]] - I agree with you and will also include this in the next standard config file. My only discomfort is the explanation of why there are navigation modules at a base, but let's rack that up to spares in hangars.

: Actually in the unmodified game, the base control consoles (destroyed to win the base mission) are Navigation modules. The patch simple captures them intact, instead of destroying them. Equally, we could imagine there are some spares in the base stores. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Modified Initial Base Layout ===

[[User:Spike|Spike]] - Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

[[User:Xeucom|Xeucom]] - This makes sense to me, so I think this should go in the standard config as well. I think the key point you made is avoiding tedium for the player - features that do that without significantly unbalancing should probably go in standard config as matter of course.

=== Base Building Stacking ===

[[User:Spike|Spike]] - Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

[[User:Xeucom|Xeucom]] - My only qualm here is that this seems like a complex feature from a programming perspective that could be risky. Have you played with it a lot and not noticed any increase in crashes or bugs with bases? It doesn't really add anything except being able to lay out the facilities in game sooner - you could still get the same facilities in the same amount of time just waiting for completion messages. The other thing I note with this is that if you turn it off on a game where you have laid out some to-build facilities, bases get funky in with 255 overlayed n the extended modules instead of "Queued". However, for the standard config, I think we should assume that the player will play through the entire game without changing the settings, because otherwise trying to figure out all the possible scenarios would become overwhelming. If you are satisfied that this does not introduced bugginess, I could go for it for the standard config.

[[User:Spike|Spike]] - Well that is a fair point. I have not used the feature enough to swear there are no bugs. Maybe it is safer to leave this as an optional thing that people can enable if they want to.

=== Assign All Personnel ===

[[User:Spike|Spike]] - Highly useful.

[[User:Xeucom|Xeucom]] - I didn't add this to the initial standard config because I don't understand what it does. Can you explain? Also, is it helpful enough to merit the increased risk of negative side effects (crashed, other bugs) when its complexity is considered?

[[User:Spike|Spike]] Basically in various screens this lets you hit the down arrow when the counter is at zero, and the counter goes UP to the highest possible value. This saves you from having to scroll up from 0 to say 100 Scientists, 100 Engineers, etc, whenever starting a new research or manufacturing project. The scrolling speed can be very slow, depending on your machine. This is a very simple mod so I would expect it to be bulletproof from a bug point of view.

[[User:Xeucom|Xeucom]] - Let's call it in for the standard config, then.

=== Save Equipment ===

[[User:Xeucom|Xeucom]] - Spike, I saw that you mentioned in the settings above that you had Save Equpiment turned off because it was buggy. Could you explain? I have used it for some time in my current game and it seems to be working ok. There are some strange things where I am not able to extend the ground portion with the right button and sometimes when I assign a weapon to a soldier it doesn't appear in their hand until I click on one of the slots again. However, I have not verified if this happens with/without UFO Extender or the Save Equipment setting. Since the standard config should aim for bug free, if you think have observed bugs, we should probably leave it out until it is more stable.

: Agreed. There are definitely known bugs with this feature and it is currently described as "Highly Experimental". But once it's working reliably this is a top candidate for inclusion in the standard configuration. [[User:Spike|Spike]] 19:32, 29 August 2009 (EDT)

=== Funky Fire ===

[[User:Spike|Spike]] - This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

[[User:Xeucom|Xeucom]] - The way I understand this it is that the smoke and explosive damage end of turn checks were probably getting applied every time an incendiary shell went off. I think seb76 simply stopped that from happening so that only the entities inside the incendiary shell blast radius took damage and then he increased maximum fire damage from 5 to 10 to compensate for a possible lower fire damage value the original developers put in to offset the bug. From my personal observations, it seems to me that smoke damage is too low and should probably be raised as well because units can spend a lot of time in it without passing out, but that's just an opinion. For the standard config, it sounds like we are in agreement to leave it in because it makes no sense for explosions in other areas of the map to affect other units.

: Yes the illogical behavior is fixed & that's good enough reason to include this fix. My understanding of the fix is that smoke/fire effects only occur at end of turn. This reduced the power of Incendiary weapons a lot, even if not using the Exploit. To partly compensate, Seb has doubled the average damage from fire. There's no exact way to compensate but this is a reasonable approach IMO. [[User:Spike|Spike]] 19:25, 29 August 2009 (EDT)

:: [[User:Xeucom|Xeucom]] - With the fix enabled, if I hit a sectoid with three incendiary shells in one turn, will I do no damage to the sectoid until the turn ends? Or will the sectoid take hit damage (of incendiary type?) on each hit, but no general fire damage from being in a fire square until end of turn?
::: Fire damage will only be applied at the end of the turn. That's why I buffed fire damage up a bit. [[User:Seb76|Seb76]] 13:52, 30 August 2009 (EDT)
:::: In our investigations, we deduced that the so called "incendiary impact damage" is itself an aspect of the bug. And it makes sense that incendiary damage should not take effect as promptly as a bomb,a bullet or a plasma beam. But this does change the play of the game. I don't think it makes much difference apart from people who were exploiting the Funky Fire exploit. But if there was anyone out there who was consistently firing multiple IN rounds at single targets, one at a time, their game play experience will change with this fix. I think it's worth at least a note that this is not just a bug fix but also includes some unavoidable changes in game play. [[User:Spike|Spike]] 04:14, 31 August 2009 (EDT)
::::: This would explain why once when I was facing off against sectoids I had a couple units with incendiaries (night mission, using them to light the place up) and unloaded on a sectoid. After the sixth shell on target, I was like, "Why won't you die!?" Now I understand. However, I think the behavior with Funky Fire makes the most sense because you don't get the random effects from other areas of the map and, really, if you pour a flammable over something and get it coated pretty well, adding more flammable isn't going to really do more damage, so stacking six incendiary shells in an area shouldn't necessarily do more damage to a unit there, just make the fire bigger, which happens naturally anyway because of the deviation in the squares hit. Not quite realistic, but seb76's uptick in fire damage is a fair compromise I think. [[User:Xeucom|Xeucom]] 11:47, 31 August 2009 (EDT)
What are the effects on Zombies? [[User:Magic9mushroom|Magic9mushroom]] 09:55, 1 September 2009 (EDT)

=== Aliens Take Fatal Wounds Damage ===

[[User:Xeucom|Xeucom]] - Saw seb76 made a new release with some new options, so of course have to discuss them for the standard config. :) Starting with this one, this one is a tough call. It's more realistic that aliens could also have fatal wounds. On one hand it makes game easier because injured aliens will die even if they move out of sight and quicker in general if taking damage from fatal wounds. On the other hand, makes game harder because of difficulty capturing live aliens (stunned aliens with fatal wounds likely to die). Can aliens be healed of their fatal wounds with a med kit? If so, introduces entertaining mini-game when trying to capture an alien where you have to stabilize it if injured, perhaps in conjunction with stunning it. A perhaps significant balance problem that arises is X-COM team can have medics with med kits who will heal injured team mates. I suspect this change comes without changes to AI, meaning that aliens will not use med-kits to help each other out. Thoughts?

: I would guess the small number of extra kills from wounds is well-balanced by the scenario you describe, the difficult scenario of trying to stabilise a wounded captive alien, or rush him to the transport before it dies. As this is a new fix we might want to be sure that the alien's death from wounds is handled normally - that correct points are awarded, the game ends properly, etc. Also what happens when a wounded being swaps sides during and after mind control. But (subject to that testing?) I think this one should be included. [[User:Spike|Spike]] 08:50, 1 September 2009 (EDT)

:: The question becomes how do you know you need to stabilise the alien? I can see two ways. First, the mind probe will show you that a standing alien has fatal wounds that you will need to heal once you stun him. Secondly, if medi-kit works on a stunned alien (that's a big if), the display would show you the area hurt (though this may not make sense since I don't think all the aliens are humanoid). I guess this could use some testing to see if the fatal wounds show on mind probe, if you can heal an alien with a med-kit, etc. I like that it opens a new storyline - having to rush the Snakeman Commander to the evac point before he dies, perhaps involving a medic meeting you half way. [[User:Xecuom|Xeucom]] 18:02, 1 September 2009 (EDT)

::: I tested most of the main considerations and they check out OK - see [[User talk:Seb76#Alien Bleeding|here]]. I wasn't able to test the Mind Probe, but you can use the Medkit itself to determine if an aline has any wounds that might need treating. But yes the Mind Probe would be better, since it gives the Health as well, so you can calculate if the alien will die before you can complete the mission. I really expect the Mind Probe will work, since it does normally show the Wound level of aliens - it's just usually always zero. [[User:Spike|Spike]] 20:36, 2 September 2009 (EDT)

=== Unarmed Aliens Pick Up Weapons ===

This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. It would be a very helpful rebalancing of the game that eliminates one of the aliens' weak spots. [[User:Spike|Spike]] 14:44, 3 April 2011 (EDT)

== probability of hit display ==

It would be great if next to the crosshair there would be a percentage indicating the probability of a good hit like in UFO Extraterrestrials.

== May i remake the main page of this article ==

Sorry im new to here so i dont know if i should do it right away or asking someone is polite beforehead or it should be left as is and instead second artice should be added, but:

I have thoughts for current page "Enemy Unknown Extended"
I am willing to write another article, correcting the following:

1) Recently, Xcomutils 6.7 have support for ufoextender. This means, among others, that we no longer need those patches since xcomutils applies them all! It even applies voices and old sounds (more than voices!) but you have to run setup again
2) The supplied INI is old and doenst have every key that new ufoextender uses. This should be avoided imho as the person who dl's it has often litte knowledge to find the hidden options (have to look at the page at this site) or add it (have to copypaste strings from original ini which isnt convinient)
3) For some people (inc me) mp3 solution wont work, for them an explanation how to use PSX Cd would be nice.

Therefore, i'd like to make theese changes:

1) Overview - add that recent 6.7 xcomutils beta build supports ufoextender and so we can use EU+Extender+Xcomutils for a very rich enchanced gameplay
2) Download - remove patches and ini, add xcomutil
3) Verify - accordingly to 2
4) Modify - change to "Patching process" or something as for me, modify isnt that obvious, and then, write here an exact series of steps needed to configue them to work
5) Make shortcut - change to use runxcom.bat

Then i'd like to add "If usage of mp3 causes game to crash" or something with explanation how to use psx cd for music instead
[[User:Istrebitel|Istrebitel]]

:This is a Wiki so everyone can edit anything. But thanks for asking first, that is considered polite, especially before modifying an article page with something that might be seen as a matter of opinion. Could you maybe post your proposed new text here on the Talk page? Also, please sign your posts with 4 tilde characters (~). [[User:Spike|Spike]] 14:39, 3 April 2011 (EDT)

:I'm a little confused here. You say that XcomUtil 6.7 has UFOextender support, but the lastest version available on the XcomUtil Homepage is XcomUtil 9.60 and I can verify that it very much does not work with UFOextender without some modding to recombine geoscape.exe and tactical.exe back into a single executable since UFOextender crashes if you try to use it to load tactical.exe. Scott's homepage does mention handing over control, but it only gives an email address.[[User:Mannon|Mannon]] 18:21, 3 April 2011 (EDT)

:Another concern is XcomUtil by default makes several changes to the core game, in particular it alters the crafts, making them hold more soldiers. It goes so far as to change the craft's map files (I hate the Avenger, it no longer looks like the UFOpedia entry, but like a fat flying brick.) It even makes the interceptors capable of carrying soldiers. There is no option to turn this off without altering XCUSetup.bat or at least editing XcomUtil.cfg and doing something to fix the Avenger map. I'm not sure how to make those changes easy for someone short of supplying them with an alternate XCUSetup.bat and/or XcomUtil.cfg. Though there are definitely some nice benefits to having XcomUtil installed.[[User:Mannon|Mannon]] 18:29, 3 April 2011 (EDT)

Talk:Enemy Unknown (1994) Extended

2011-04-03T22:21:46Z

Mannon: /* May i remake the main page of this article */

= General Discussion =

This is very useful, putting all these things together in one place with clear instructions. This could become the new "standard" version of the game. But I think it's only fair to explain that a lot of the choices you have made for the UFOExtender.ini file are personal choices - you should advise user to review your .ini file (and helpful explanatory comments) and see if they agree.

[[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

In general if we have a mix of features in the standard config, some of which give a minor advantage to XCom (Craft always ready, Elerium fuelled craft bug fix), some of which give a minor advantage to the aliens (Retaliate for Ground Assault), that should work out ok. Features that give a major advantage one way or the other should not be in standard config. [[User:Spike|Spike]] 07:56, 26 August 2009 (EDT)

= UFO Extender Templates =

I think your comments to the .ini file are very helpful. Here are some alternative opinions on some of the options:

*Range Based Accuracy
*[MC] Line of Fire Check

- These are to make the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

*Retaliate Against Ground Assault

- Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

*No Blaster Bomb Drift

- Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

- Maybe you could group the above options together as they all make the game more challenging, i.e. balance the game more in favour of the aliens, and explain that to the player - if you want to make the game more evenly balanced, select these options.

*Tactical Scroll
*Video Pitch
*Music Change Freeze

- You were not experiencing these issues, but others do experience it, so this is an important thing to make clear to users. They should check themselves.

*Elerium-fuelled Craft Bug

- While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

*Funky Fire

- This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

*Crafts Always Ready

- I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

*Keep Base Navigation Modules

- Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

*Base Building Stacking "too complex for benefit"

- Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

*Stun Fest "overpowered"

- I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

*Assign All Personnel

- This is a real time saver

*Hacks

Most of them are deliberate cheats and not meant for normal play so you're right to say they are hugely unbalancing.

However Recover All Clips is a kind of bug fix. Though it does give advantage to XCom it also eliminates the irritating need to manage ammo logistics. With human ammo this is not unbalancing. With scarce alien ammo, it could be, fair enough. No Score Game Over is a way of continuing "hopeless" games. Both of these have precedents in XComUtil, which a lot of players use.

*Initial Base

Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

Lastly, but not least, as Seb76 did so much of the work on UFOExtender, maybe you should give him a credit on the page? And add his UFOExtender page to the See Also?

Cheers, [[User:Spike|Spike]] 05:11, 17 August 2009 (EDT)

Spike, thanks. Yes, the choices I made were personal ones informed mostly by my (poor) memories of 15 years ago just to get the ball rolling. This is exactly the discussion I want to have because I think it would be good to come up with a consensus config for a standard version of X-COM for people who just want to get right into the game. I will review your points in detail, rethink the ini config., and make it more clear that seb's UFO Extender is the centerpiece. By the way, this talk page is a hard place to have a discussion - are strategycore forums better? [[User:Xeucom|Xeucom]] 01:57, 20 August 2009 (EDT)

: Hey, great to have you back after 15 years! Sure let's figure out a consensus. Actually I was thinking we might be able to make a few different .ini templates based on some themes, eg:

:* Bug fixes only
:* Convenience features
:* "What the designers intended"
:* Making the game harder
:* Alternate scenarios

:...etc. At the moment I'm trying to recover my account on StrategyCore (I want to post to Zombie's thread on offsets/modding). So when I get my account back I'm happy to talk there. Cheers! [[User:Spike|Spike]] 14:12, 20 August 2009 (EDT)

::Do you remember what your account name is or what email you used to register? If so, I can set you up in a hurry. Just send me an email. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

:: A menu of configs is a good idea. I'd still say we should sweep up a balanced Bug Fixes, Conveneince Features, and Designers Intent into a consensus standard config and establish that as our base line. This is all meant to lure people in/back with a quick and easy setup, get them some play time, then let them explore all the neat options UFO Extender allows. The base line also gives us a standard testing config that we can focus on making bug free (or documenting workarounds). --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

::: Ok that sounds like a plan!

[[User:Spike|Spike]] 05:25, 22 August 2009 (EDT)

: Actually, using a rewritten Initial Base (with a real base) with the stock starting inventory will give you serious cashflow management problems. "Retaliate Against Ground Assault" fixes the cashflow problem, and I'm unclear whether it makes the game easier or harder for X-COM. (I generally have an easier time the first three months on Superhuman than on Beginner, as the extra cashflow from the increased Retalation Acts more than compensates for equally dumb AI with more accurate ranged attacks.) -- [[User:Zaimoni|Zaimoni]] 04:42, 22 August 2009 (CDT)

= Small Scout Map =

Does the Combo Pack include Zombie's Small Scout Map fix? If not, maybe that should be included too. [[User:Spike|Spike]] 14:37, 20 August 2009 (EDT)

:I don't have anything in the kit for the Small Scout because nothing is wrong with it. LOL I do, however, have a Small Scout Mod ([http://www.strategycore.co.uk/files/index.php?dlid=710 found here]) which reintroduces the old Small Scout lefover from the development days. --[[User:Zombie|Zombie]] 20:10, 20 August 2009 (EDT)

::I didn't include the Small Scout patch because it seemed too little gain for the additional step of installing it since people are installing it by manual steps. There is already a very small scout in the game (the one you can grav lift into one square with hole in top) The ideal would be if someone could cook up a little exe that downloaded all the mods and installed them (or we got permission from the authors to bake it into one download) so it was one download and double click. Then it would make sense to add in some more one-trick mods. --[[User:Xeucom|Xeucom]] 01:30, 22 August 2009 (EDT)

= Standard Config Discussions =

This section is for discussing what should go in the standard UFO Extender config that is recommended as the downloadable ini file. The concept of the standard config is a config that fixes bugs, introduces convenience features, and retains or improves game balance while keeping the original feel. It is intended for the new or returning player who can put up with a moderate level of difficulty, but is not an elite player (Spike, I will add more sections as I have time to address all the points you raised - these are the ones I had time to research and think about with your feedback).

== Game Version ==

There could be a problem in that the publicly available version of the game is the DOS version released by Steam. The Windows CE version is arguably no longer in the public domain, since Steam now has made its version available. At this time, only one site I can find is still offering downloads of the Windows CE edition. It could be considered the Windows CE edition is no longer "abandonware", and this seems to be the view that the operators of download sites are taking. Therefore, if looking for a reference edition, maybe we should look to modding the Steam, DOS, edition. The problem is that Seb76's loader only works on the Windows CE edition.

I think we should go ahead and define the features of a "standard edition" anyway, but the problem of what version to use will still need to be solved. Basically either the fan community (us!) extends Seb's loader to also apply to the Steam DOS version, or we need to use another tool to patch the DOS version. In theory, XcomUtil could be used to patch the DOS version to introduce all of Seb's additional patches. It is arcane to use but it could be done. The key first step would be to establish a list of patches for the DOS version that are equivalent to Seb's patches to the Windows version.

:Both the Steam and GamersGate (according to forums on the latter) downloads include the Windows version. Specifically, they have a "UFO Defense.exe". I have tested the described mod set with Steam. Steam launches the DosBox DOS version by default through the steam interface, but once you create the shortcut as described, you never use it again. Does that alleviate this concern? [[User:Xeucom|Xeucom]] 09:30 August 23, 2009.

:: You are right! I tested it and, to my surprise, it works. I guess the Steam version must be the Windows CE version, even though it launches it via DosBox. Cool, so there is no problem there - quite the contrary, if all these mods work on the Steam distribution that's excellent. And maybe we can persuade Steam to distribute the "standard extended" version some day. Perhaps not, as we are sort of bypassing their security. Normally when you try to start the executable it should chain back to all the Steam software. In this case, I think we get by that because Seb's loader treats the executable as sort of a data file, loading it rather than directly executing it from the O/S, and also the loader controls the entry points itself (guessing?). Anyway, I suspect Steam don't really care too much about software protection on the old XCom games. [[User:Spike|Spike]] 06:49, 24 August 2009 (EDT)

== Categories ==

Group all fixes into categories:

=== Bug Fixes ===

==== General Bug Fixes ====

All undisputed bugs should be fixed here.

[Bug Fix]
Pay For Dirt=1
Phantom Radar=1
Base Disjoint=1
Radar Stacking=1
Base Facility Dismantle-Construction Crash=1
Collectors Edition Blaster Bomb Bug=1
Proximity Grenades=1
Proximity Grenades Experience=1
Door Jam=1
Personnel Overflow=1
Funky Fire=1
Displayed Base Maintenance Cost=1

[OBDATA.DAT]
Apply=1
;Make grenades indestructible to allow stacking several explosions
Grenade Resistance=255
Proximity Grenade Resistance=255
High Explosive Resistance=255

==== Technical ====

Audio/Video bugfixes or tweaks and other things that some experience, some do not, depending on their platform. Should all be optional and to be set up by the end user. (Possibly video pitch should default to 1, since if it's not enable it can be hard to recover from the screen crash? Which might put users off the "standard extended" package?)

[Bug Fix]
Video Pitch=?
Intro Sounds=?
Music Change Freeze=?
Tactical Scroll=?

[Mod]
HQ4x=?
D3D=?
Scale Mouse=?

[Music]
Apply=1
Source=MP3
;Source=PSX CD
CD Drive=F
MP3 Folder=mp3
Battlescape=*Battlescape*.mp3
Start Menu=*Final Briefing*.mp3
Bad Ending=*Final Briefing*.mp3
Good Ending=*Dogfight*.mp3
Geoscape=*Geoscape*.mp3
Dogfight=*Dogfight*.mp3
Mission Debriefing=*Debriefing*.mp3
UFO Assault=*Briefing1.mp3
Base Defense=*Briefing2.mp3
Base Attack=*Briefing1.mp3
Mars=*Debriefing*.mp3
Terror Mission=*Briefing2.mp3

==== Closed Exploits ====

We ''might'' want to make it optional to close exploits and make that separate from bug fixes. The difference being that bug fixes help the player or are neutral, whereas closing an Exploit by definition makes it relatively harder for the player. Personally I don't like to encourage the use of exploits, but it's an option.

(For now the exploit-closing features have been included in other sections)

:My opinion is that all obvious (in the sense that it is clearly not balanced, not that it is easy to find) exploits should be closed in the standard config. If a player stumbles into an exploit, they can become frustrated because the supension of disbelief and challenge is lost. The game ends up simply looking inconsistent. - [[User:Xeucom|Xeucom]] 19:11 August 25, 2009.

:: I completely agree. You will get some people who routinely rely on certain Exploits, who might not agree. But then they can always change the config file. Probably the most frequently used Exploits are - [[ExploitsA#Free Wages|Free Wages]], [[ExploitsA#Free Manufacturing|Free Manufacturing]], [[Known Bugs#Funky Fire|Funky Fire]], Access Alien Inventory. The [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Robotic Research]] exploits are infrequently used but are massive and should definitely be closed down. [[Exploiting Mind Control#Access the Alien Inventory Screen|Access Alien Inventory]] is arguably not an exploit but merely enables "What The Designers Intended". After all, it seems logical that XCom Psi Troops should be able to access a victim's inventory, just as alien psi attackers can do. It's not in itself unbalancing (or, not any more than Psi itself is). In fact for aliens with only built in attacks it's kind of necessary to make Psi useful on those aliens. It only really becomes unbalancing through the use of [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]. Exponential Mind Control should probably be closed as an Exploit, but I'm not aware of any existing patch that closes it (other than by disabling Access Alien Inventory, which as I've said here is probably not justified). [[Exploiting Mind Control#Zombie's Permanent Control of Aliens via Stunning|Permanent Mind Control]] and the [[Exploiting Mind Control#Resurrect Zombified Agents|Zombie Resurrection]] techniques should also be closed down. [[User:Spike|Spike]] 07:44, 26 August 2009 (EDT)

::[[Tactical Exploits#Elevator Shielding|Elevator Shielding]], which enables risk-free [[Tactical Exploits#Milking Alien Bases|Alien Base Milking]], should also be closed, but again I'm not aware of any fix. [[Grenade Relay]]s, and all similar [[Grenade Relay#Relaying other Equipment|item relays]] - any tactic which allows one item/weapon to be used multiple times per turn by passing it through the hands of multiple soldiers and thereby applying more than 100% TUs to it - are minor and not really important to close down, even though they are a bit silly. [[ExploitsA#Infinite Fuel|Infinite Fuel]] is not so destabilizing as to need closing down as an Exploit, but it probably should be closed just as a bug. [[User:Spike|Spike]] 12:00, 26 August 2009 (EDT)

=== Convenience Features ===

These are logistic or interface enhancements that have a neutral impact on game balance. They should be included by default (unless there is controversy over a particular fix).

[Equipment Screen]
Show Stats=1
Weight=Weight>
Accuracy=Accur>
Reaction=React>
Psi Strength=P.Str>
Psi Skill=P.Skill>
Show Grenade State=1
Primed=primed
; Save Equipment is currently buggy but hopefully will be fixed soon
Save Equipment=0
Auto Flares=1

[Mod]
Save Reserve Mode=1
Rank In Inventory=1
Skip Intro=?
Base Building Stacking=1
Force Language=?
Reorder Soldiers In Crafts=1
De-equip Crafts=1
Assign All Personnel=1
Fast Base Defenses=1

[Battlescape Shortcuts]

[Geoscape Shortcuts]

=== Designer Intent ===

It's sometimes hard to agree designer's intent, but where we agree we should include these.

[Mod]
TFTD Doors=1
Stunned units KIA=1
More Smoke=1
; maybe reduce stun damage from Launchers but otherwise OK:
Stun Fest=1

However if these mods also affect game balance we should think long and hard. Possibly add a subsection:

==== Designer Intent but changes game balance ====

[Bug Fix]
; This makes the game a fair bit easier for XCom, also makes the game less interesting by eliminating any need for regular craft
Elerium-fueled Craft Bug=0

=== Alternate Scenarios ===

Features to permit different ways of playing the game, but not necessarily making it harder.

; Makes recoveries much more fun. Although gives more
; information than you would normally get, it is a very
; minor advantage and worth the compromise to original.
[Wreck Analysis]
Apply=?
Zone Discovered=Intel found out that the %s UFO was raiding %s
Mission Discovered=Inspection showed that the %s UFO was on an %s mission
Both Discovered=Ship investigation revealed that the %s UFO was on an %s mission in %s

; Makes it too easy to find scouts and crashing this often
; does not make sense given alien technology level.
[Roswell]
Apply=?
;Terrain names
Jungle=Jungle
Farm=Farm
Mountain=Mountain
Desert=Desert
Polar=Polar
;Dialog strings
Title=UFO Incident
Info=Crash reported
Location=LOCATION
Type=TYPE
Terrain=TERRAIN

; Needed to complete the game if not allowing any UFO detection
[Mod]
Keep Base Navigation Modules=?

; This makes the game easier but something similar is widely used by experienced players via XcomUtil
; Starting with such a badly designed base is frustrating and modifying the base every time gets boring.
; Starting with a well-designed base could be a good education for starting players.
[Initial Base]
Apply=1
row1=HangarTL HangarTR HangarTL HangarTR HangarTL HangarTR
row2=HangarBL HangarBR HangarBL HangarBR HangarBL HangarBR
row3=AccessLift Empty Empty Empty Empty Empty
row4=GeneralStores LivingQuarters SmallRadar Laboratory Workshop Empty
row5=Empty Empty Empty Empty Empty Empty
row6=Empty Empty Empty Empty Empty Empty

; Another enhancement that is often used via XcomUtil, on the basis that HE Packs are "otherwise useless".
; But many players think HE Packs do have a role. And being able to blow arbitrary holes in UFOs makes it much easier for XCom.
[OBDATA.DAT]
Apply=?
;Make HE packs capable of breaching UFO walls
High Explosive Damage=200

; For playing on even when the situation is hopeless
[Hack]
No Score Game Over=?

; This overpowered weapon makes the game easier but is loads of fun!
[Mod]
Heavy Laser=?

; For people who think a grenade has a fuse that you light with a match ;)
[Mod]
Hot Grenades=0

; Makes the game easier. This is not necessarily a bug, it could reasonably be understood as an intended feature.
[Bug Fix]
Transfered Crafts Refueled=0

; Very convenient for XCom and unbalances the resource side of the game in XCom's favour. Arguably unrealistic.
[Mod]
Crafts Always Ready=0

=== Making The Game Harder ===

Features to increase the level of challenge. Actually this may often overlap with the previous category of Alternate Scenarios. The distinction would be that these features '''always''' make the game harder, whereas the previous category are to help the player when the player '''voluntarily''' plays in an alternative way (which, probably, is a way of playing that makes the game more challenging)

[Mod]
No Funkers=0
Bloodthirst=0
Limited Military=0
Funding Council Income Only=0
Surrender Defence Missions=0
Disable Base Defenses=0
Initial Alien Bases=0
Retaliate Against Ground Assault=0
No Blaster Bomb Drift=0
More Reaction Fire=0
Alien Inventory=0

[Range Based Accuracy]
Apply=0
Minimum Efficiency=50
Snap Penalty Distance=30
Auto Penalty Distance=14
Orange Cursor Threshold=95
Red Cursor Threshold=75

[Line Of Fire Check]
Mind Control=0
Panic=0
Mind Probe=0

[Caps]
Apply=0
Time Units=80
Health=60
Strength=70
Energy=100
Reactions=100
Firing Accuracy=120
Melee Accuracy=120
Throwing Accuracy=120
Psi Skill=100

== Specific Feature Discussions ==

=== Range Based Accuracy ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - If you accept that the role of the standard config as being for the standard player, increasing difficulty for the experienced player would not by itself merit inclusion in the standard config. Things we add to the config to make things more challenging for the elite players might belong in a special 'superhuman plus' config file. Also, the official strategy guide and [[Firing_Accuracy_Testing|information]] on this site suggests that range is already factored into weapon accuracy and fairly balanced. In play, the anecdotal feel is that range does matter.

: Range does matter though only in so far as misses are less likely to accidentally hit at longer ranges. This fix actually reduces the chance of a purposeful hit at longer ranges and increasing the distance penalty for snap fire and even more so auto fire. It could perhaps be better explained! [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: My vote is that this is a Making The Game Harder feature. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

Ranged Based Accuracy doesn't sound like something that directly increase X-Com's difficulty. Doesn't it affect aliens too? If it doesn't, it should. --[[User:SnowJob|SnowJob]] 22:07, 5 July 2010 (EDT)

=== Mind Control Requires Line Of Sight for X-COM Squad ===

[[User:Spike|Spike]] - This makes the game harder, which can be a good thing as experienced players consider the game too easy for XCom.

[[User:Xeucom|Xeucom]] - See standard config intent and superhuman plus alternative config concept above on difficulty argument. It doesn't seem like physical objects should block mind control in the fictional sense. Also, aliens are able to use it without line of sight (except for seeing the first X-COM soldier). I may be a bit confused here, though: Does the alien squad have to have line of sight on at least one X-COM soldier to be able to use mind control in turns after the aliens first spot an X-COM Soldier? Also, does enabling this make the X-COM soldier who is wielding the psi-amp have to have line of sight on the alien that soldier is going to target?

: Yes the alien squad needs LoS on at least one soldier at some point in the turn. But the same restriction already applies to XCom. I agree this can be put in the superhuman plus category. Not sure of the details of how it works. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

=== Retaliate Against Ground Assault ===

[[User:Spike|Spike]] - Yes it does change the game dynamic but not by much. It makes the game harder for X-Com which is a good thing, makes the aliens behave smarter and more logically.

[[User:Xeucom|Xeucom]] - I agree with you. Aliens behaving smarter and more logically improves the gameplay experience even if it slightly increases difficulty. I think anything that improves the AI reasoning belongs in the standard config as long as the AI is adhering to fog of war principles. I will enable this in the next standard config ini.

=== Blaster Bomb Drift ===

[[User:Spike|Spike]] - Drift actually only affects aliens so again it's an option that rebalances the game in favour of the aliens and makes it more challenging.

[[User:Xeucom|Xeucom]] - Are you sure that drift only affects aliens? If so, is the blaster bomb overpowered without the drift? As far as I can tell, a direct or close hit from a blaster bomb is guaranteed death for a X-COM soldier, no matter the experience or suit. Would it be better to introduce blaster bomb drift to X-COM firings instead of removing it from the aliens? This seems like one of those random parts of the AI that makes them a little more unpredictable and therefore believable to me. I was reading a story on one of the missions-gone-wrong threads in the forums and an errant blaster bomb firing by the aliens really helped create a funny story.

:Agreed let's confirm that drift only affects aliens. Maybe this could go in Making The Game Harder. Blaster Bombs are terribly lethal so the alien drift is often a lifesaver. [[User:Spike|Spike]] 04:47, 23 August 2009 (EDT)

:: It's pretty obvious (from StrategyCore old posts, not personally verified) that drift affects XCOM as well; it's why you have to be careful when using a blaster bomb launcher from the Skyranger/Avenger entrance. [[User:Zaimoni|Zaimoni]] 10:21, 25 August 2009 (CDT)

::: OK but in practice this only affects the aliens, since the AI is too stupid to take precautions, whereas players quickly learn to allow some leeway. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Stun Fest ===

[[User:Spike|Spike]] - I don't agree it's overpowered. Beating up aliens is hard work. The melee weapon values are all moderate - less effective than a Stun Rod in every case, so how can that unbalancing? To me, this just adds to the game "flavour", adds realism, and is clearly part of the designers' original intent.

[[User:Xeucom|Xeucom]] - Do you know that the original game manual has a screenshot with a 'Hit' option for a rifle? Therefore, I agree with you on intent of developers and that there should be a 'pistol whip' stun option for all/most weapons (or empty hand). However, the table at [[User:Seb76|seb's page]] suggests that the weapon values are not less than the stun rod in every case. It seems out of whack (no pun intended) for the missile launcher to do more stun damage than the stun rod, or even more stun damage than a rifle. It would be so bulky it would be harder to beat an alien with that than a pistol or rifle. So my vote is yes for (non-ranged) stun damage for non stun rod weapons, but I think we need to figure out the right balance for stun damage before adding it to the standard config.

:There are definitely some wacky hand to hand damage levels in the executable, normally unused, but I thought that Seb had overridden those values to more sensible levels. I'd better check. :) 04:47, [[User:Spike|Spike]] 04:49, 23 August 2009 (EDT)
::I checked and I would still say "less effective than a Stun Rod in every case". Though the Launchers do get a higher base damage than the Stun Rod, they can only attack once per turn and will use HTH accuracy instead of an automatic hit. Bludgeoning an alien with a weapon is always an act of desperation and less effective than a Stun Rod. But loads of fun and very atmospheric![[User:Spike|Spike]] 13:27, 24 August 2009 (EDT)

:::I see your point when you take into account the Time Units and the accuracy. You convinced me that it belongs in the standard config. [[User:Xeucom|Xeucom]] 18:30, 25 August 2009 (EDT)

=== Elerium Fueled Craft (Bug?) ===

[[User:Spike|Spike]] - While it may well be unintended, this removes a significant limitation on X-Com and therefore unbalances the game in X-Com's favour.

[[User:Xeucom|Xeucom]] - It just seems artificial to me that non-elerium craft return home when they are going to have to ditch if they don't, but the elerium craft turn around and head back at an arbitrary fuel level. What would the fictional explanation be? I understand your point about amping up difficulty, but for the standard config, I think consistency is more important. Inconsistency between craft behavior just looks buggy. There are other ways we could increase difficulty that would be much more impactful.

[[User:Spike|Spike]] - Agreed, it disturbs realism and consistency and jars the player experience. That's more important than a slight imbalance. I believe the conventional craft can still stay on station longer than Elerium craft, even with this bug fixed?

=== Craft Always Ready ===

[[User:Spike|Spike]] - I disagree, though this seems realistic, it gives advantages to XCom. In particular it removes the imperative to maintain multiple craft, which is a major resource drain early in the game and in fact throughout the game. You can also argue that the un-modded game is very realistic as this is how real-world air forces operate. It is totally against procedure to re-launch aircraft without a full logistics refit. Anyway, the point is, this is a significant advantage to XCom. Maybe this option should be "balanced" by creating a risk that the aircraft just falls out of the sky - with a warning before launch "this aircraft has not been properly maintained".

[[User:Xeucom|Xeucom]] - I have played with this on and think it is possible you may think that this does more than it does. The only thing that it allows you to do is to dispatch interceptors when they are rearming, refueling, and repairing. It doesn't put them back to 100% loadout, fuel, and integrity. So I think it is still balanced because you are limited to the full refits unless you want to scramble interceptors that only have a short range, or no arms, or are already damaged. I realize that normal rules of procedure would not be to relaunch until total refit is complete, but why not leave it up to the player/commander? In a desperate situation, I think any real-world air force would launch anything in whatever condition it is in and what can be more desperate than fighting aliens? :) Also, X-COM from a fictional perspective is a very odd entity. Some could view it as a professional military alliance of the other powers, but given how little you get and how poorly funded it is (and how you can be shut down by your creditors), it smacks more of a private mercenary corporation whose operational procedures may be largely ad hoc.

[[User:Spike|Spike]] - Agree most of those points. This is only slightly more powerful than just leaving the interceptor in the air on patrol after combat. (It's slightly more powerful because you do get to refuel/rearm while waiting for the next target.) The imbalance I'm talking about is that it makes it possible to maintain one interceptor per base instead of needing two. This has a biggish effect on your cost base early in the game. If there was a balancing "side effect" of launching with low fuel / weapons / repairs, I would be totally happy. As it is, I guess it's not too badly unbalancing.

[[User:Zaimoni|Zaimoni]] - You still need two Interceptors per base to conveniently shoot down Terror Ships before Plasma Cannons, or to conveniently shoot down all non-Battleships in the acts with finales (Infiltration, Base) with Plasma Cannons.

=== Base Navigation Modules ===

[[User:Spike|Spike]] - Potentially unbalancing? I really don't think so. Succeeding in an Alien Base assault is much, much harder than a UFO Recovery mission or Ground Assault mission that is normally used to recover Navigation Modules. This option was included by Seb at my request to facilitate a "No Interception" scenario where shooting down UFOs is impossible. It's not unbalancing, it just gives alternative ways to play the game.

[[User:Xeucom|Xeucom]] - I agree with you and will also include this in the next standard config file. My only discomfort is the explanation of why there are navigation modules at a base, but let's rack that up to spares in hangars.

: Actually in the unmodified game, the base control consoles (destroyed to win the base mission) are Navigation modules. The patch simple captures them intact, instead of destroying them. Equally, we could imagine there are some spares in the base stores. [[User:Spike|Spike]] 07:34, 26 August 2009 (EDT)

=== Modified Initial Base Layout ===

[[User:Spike|Spike]] - Again there is precedent for this in XComUtil which either gives an improved layout base (like this one) or by default a base with Large Radar and Alien Containment already completed - a big step forward. I don't think the sensible base layout is too unbalancing and it saves the tedious task of reorganising the starter base. It also gives new players a better hint about how they should design a base layout.

[[User:Xeucom|Xeucom]] - This makes sense to me, so I think this should go in the standard config as well. I think the key point you made is avoiding tedium for the player - features that do that without significantly unbalancing should probably go in standard config as matter of course.

=== Base Building Stacking ===

[[User:Spike|Spike]] - Very much a personal opinion! Enabling it does no harm, as no one is obliged to use the feature if they find it too complex. For others, it is useful for simplifying construction management, especially when managing lots of bases. You make your growth plan once, "stack" the builds, and then you can forget about it until those facilities are complete.

[[User:Xeucom|Xeucom]] - My only qualm here is that this seems like a complex feature from a programming perspective that could be risky. Have you played with it a lot and not noticed any increase in crashes or bugs with bases? It doesn't really add anything except being able to lay out the facilities in game sooner - you could still get the same facilities in the same amount of time just waiting for completion messages. The other thing I note with this is that if you turn it off on a game where you have laid out some to-build facilities, bases get funky in with 255 overlayed n the extended modules instead of "Queued". However, for the standard config, I think we should assume that the player will play through the entire game without changing the settings, because otherwise trying to figure out all the possible scenarios would become overwhelming. If you are satisfied that this does not introduced bugginess, I could go for it for the standard config.

[[User:Spike|Spike]] - Well that is a fair point. I have not used the feature enough to swear there are no bugs. Maybe it is safer to leave this as an optional thing that people can enable if they want to.

=== Assign All Personnel ===

[[User:Spike|Spike]] - Highly useful.

[[User:Xeucom|Xeucom]] - I didn't add this to the initial standard config because I don't understand what it does. Can you explain? Also, is it helpful enough to merit the increased risk of negative side effects (crashed, other bugs) when its complexity is considered?

[[User:Spike|Spike]] Basically in various screens this lets you hit the down arrow when the counter is at zero, and the counter goes UP to the highest possible value. This saves you from having to scroll up from 0 to say 100 Scientists, 100 Engineers, etc, whenever starting a new research or manufacturing project. The scrolling speed can be very slow, depending on your machine. This is a very simple mod so I would expect it to be bulletproof from a bug point of view.

[[User:Xeucom|Xeucom]] - Let's call it in for the standard config, then.

=== Save Equipment ===

[[User:Xeucom|Xeucom]] - Spike, I saw that you mentioned in the settings above that you had Save Equpiment turned off because it was buggy. Could you explain? I have used it for some time in my current game and it seems to be working ok. There are some strange things where I am not able to extend the ground portion with the right button and sometimes when I assign a weapon to a soldier it doesn't appear in their hand until I click on one of the slots again. However, I have not verified if this happens with/without UFO Extender or the Save Equipment setting. Since the standard config should aim for bug free, if you think have observed bugs, we should probably leave it out until it is more stable.

: Agreed. There are definitely known bugs with this feature and it is currently described as "Highly Experimental". But once it's working reliably this is a top candidate for inclusion in the standard configuration. [[User:Spike|Spike]] 19:32, 29 August 2009 (EDT)

=== Funky Fire ===

[[User:Spike|Spike]] - This is definitely a bug/exploit, but the bug fix also includes some changes to the way incendiary weapons work. I think Seb's approach is correct, as he makes fire behave logically but still do roughly the same damage as non-exploit non-fixed usage. But it might be worth flagging up to the player as this is a difficult judgement call.

[[User:Xeucom|Xeucom]] - The way I understand this it is that the smoke and explosive damage end of turn checks were probably getting applied every time an incendiary shell went off. I think seb76 simply stopped that from happening so that only the entities inside the incendiary shell blast radius took damage and then he increased maximum fire damage from 5 to 10 to compensate for a possible lower fire damage value the original developers put in to offset the bug. From my personal observations, it seems to me that smoke damage is too low and should probably be raised as well because units can spend a lot of time in it without passing out, but that's just an opinion. For the standard config, it sounds like we are in agreement to leave it in because it makes no sense for explosions in other areas of the map to affect other units.

: Yes the illogical behavior is fixed & that's good enough reason to include this fix. My understanding of the fix is that smoke/fire effects only occur at end of turn. This reduced the power of Incendiary weapons a lot, even if not using the Exploit. To partly compensate, Seb has doubled the average damage from fire. There's no exact way to compensate but this is a reasonable approach IMO. [[User:Spike|Spike]] 19:25, 29 August 2009 (EDT)

:: [[User:Xeucom|Xeucom]] - With the fix enabled, if I hit a sectoid with three incendiary shells in one turn, will I do no damage to the sectoid until the turn ends? Or will the sectoid take hit damage (of incendiary type?) on each hit, but no general fire damage from being in a fire square until end of turn?
::: Fire damage will only be applied at the end of the turn. That's why I buffed fire damage up a bit. [[User:Seb76|Seb76]] 13:52, 30 August 2009 (EDT)
:::: In our investigations, we deduced that the so called "incendiary impact damage" is itself an aspect of the bug. And it makes sense that incendiary damage should not take effect as promptly as a bomb,a bullet or a plasma beam. But this does change the play of the game. I don't think it makes much difference apart from people who were exploiting the Funky Fire exploit. But if there was anyone out there who was consistently firing multiple IN rounds at single targets, one at a time, their game play experience will change with this fix. I think it's worth at least a note that this is not just a bug fix but also includes some unavoidable changes in game play. [[User:Spike|Spike]] 04:14, 31 August 2009 (EDT)
::::: This would explain why once when I was facing off against sectoids I had a couple units with incendiaries (night mission, using them to light the place up) and unloaded on a sectoid. After the sixth shell on target, I was like, "Why won't you die!?" Now I understand. However, I think the behavior with Funky Fire makes the most sense because you don't get the random effects from other areas of the map and, really, if you pour a flammable over something and get it coated pretty well, adding more flammable isn't going to really do more damage, so stacking six incendiary shells in an area shouldn't necessarily do more damage to a unit there, just make the fire bigger, which happens naturally anyway because of the deviation in the squares hit. Not quite realistic, but seb76's uptick in fire damage is a fair compromise I think. [[User:Xeucom|Xeucom]] 11:47, 31 August 2009 (EDT)
What are the effects on Zombies? [[User:Magic9mushroom|Magic9mushroom]] 09:55, 1 September 2009 (EDT)

=== Aliens Take Fatal Wounds Damage ===

[[User:Xeucom|Xeucom]] - Saw seb76 made a new release with some new options, so of course have to discuss them for the standard config. :) Starting with this one, this one is a tough call. It's more realistic that aliens could also have fatal wounds. On one hand it makes game easier because injured aliens will die even if they move out of sight and quicker in general if taking damage from fatal wounds. On the other hand, makes game harder because of difficulty capturing live aliens (stunned aliens with fatal wounds likely to die). Can aliens be healed of their fatal wounds with a med kit? If so, introduces entertaining mini-game when trying to capture an alien where you have to stabilize it if injured, perhaps in conjunction with stunning it. A perhaps significant balance problem that arises is X-COM team can have medics with med kits who will heal injured team mates. I suspect this change comes without changes to AI, meaning that aliens will not use med-kits to help each other out. Thoughts?

: I would guess the small number of extra kills from wounds is well-balanced by the scenario you describe, the difficult scenario of trying to stabilise a wounded captive alien, or rush him to the transport before it dies. As this is a new fix we might want to be sure that the alien's death from wounds is handled normally - that correct points are awarded, the game ends properly, etc. Also what happens when a wounded being swaps sides during and after mind control. But (subject to that testing?) I think this one should be included. [[User:Spike|Spike]] 08:50, 1 September 2009 (EDT)

:: The question becomes how do you know you need to stabilise the alien? I can see two ways. First, the mind probe will show you that a standing alien has fatal wounds that you will need to heal once you stun him. Secondly, if medi-kit works on a stunned alien (that's a big if), the display would show you the area hurt (though this may not make sense since I don't think all the aliens are humanoid). I guess this could use some testing to see if the fatal wounds show on mind probe, if you can heal an alien with a med-kit, etc. I like that it opens a new storyline - having to rush the Snakeman Commander to the evac point before he dies, perhaps involving a medic meeting you half way. [[User:Xecuom|Xeucom]] 18:02, 1 September 2009 (EDT)

::: I tested most of the main considerations and they check out OK - see [[User talk:Seb76#Alien Bleeding|here]]. I wasn't able to test the Mind Probe, but you can use the Medkit itself to determine if an aline has any wounds that might need treating. But yes the Mind Probe would be better, since it gives the Health as well, so you can calculate if the alien will die before you can complete the mission. I really expect the Mind Probe will work, since it does normally show the Wound level of aliens - it's just usually always zero. [[User:Spike|Spike]] 20:36, 2 September 2009 (EDT)

=== Unarmed Aliens Pick Up Weapons ===

This now seems to be possible due to research by Volutar. See [[Talk:OBDATA.DAT#Field_0x2D]]. It would be a very helpful rebalancing of the game that eliminates one of the aliens' weak spots. [[User:Spike|Spike]] 14:44, 3 April 2011 (EDT)

== probability of hit display ==

It would be great if next to the crosshair there would be a percentage indicating the probability of a good hit like in UFO Extraterrestrials.

== May i remake the main page of this article ==

Sorry im new to here so i dont know if i should do it right away or asking someone is polite beforehead or it should be left as is and instead second artice should be added, but:

I have thoughts for current page "Enemy Unknown Extended"
I am willing to write another article, correcting the following:

1) Recently, Xcomutils 6.7 have support for ufoextender. This means, among others, that we no longer need those patches since xcomutils applies them all! It even applies voices and old sounds (more than voices!) but you have to run setup again
2) The supplied INI is old and doenst have every key that new ufoextender uses. This should be avoided imho as the person who dl's it has often litte knowledge to find the hidden options (have to look at the page at this site) or add it (have to copypaste strings from original ini which isnt convinient)
3) For some people (inc me) mp3 solution wont work, for them an explanation how to use PSX Cd would be nice.

Therefore, i'd like to make theese changes:

1) Overview - add that recent 6.7 xcomutils beta build supports ufoextender and so we can use EU+Extender+Xcomutils for a very rich enchanced gameplay
2) Download - remove patches and ini, add xcomutil
3) Verify - accordingly to 2
4) Modify - change to "Patching process" or something as for me, modify isnt that obvious, and then, write here an exact series of steps needed to configue them to work
5) Make shortcut - change to use runxcom.bat

Then i'd like to add "If usage of mp3 causes game to crash" or something with explanation how to use psx cd for music instead
[[User:Istrebitel|Istrebitel]]

:This is a Wiki so everyone can edit anything. But thanks for asking first, that is considered polite, especially before modifying an article page with something that might be seen as a matter of opinion. Could you maybe post your proposed new text here on the Talk page? Also, please sign your posts with 4 tilde characters (~). [[User:Spike|Spike]] 14:39, 3 April 2011 (EDT)

:I'm a little confused here. You say that XcomUtil 6.7 has UFOextender support, but the lastest version available on the XcomUtil Homepage is XcomUtil 9.60 and I can verify that it very much does not work with UFOextender without some modding to recombine geoscape.exe and tactical.exe back into a single executable since UFOextender crashes if you try to use it to load tactical.exe. Scott's homepage does mention handing over control, but it only gives an email address.[[User:Mannon|Mannon]] 18:21, 3 April 2011 (EDT)

Talk:Accuracy formula

2011-04-01T11:10:56Z

Mannon:

From experience I think the chance of hitting an alien tends to be best if in an exact straight line (orthagonal or diagonal), and on the same level as it. This probably is explained by the misses that hit anyway, because you can miss slightly short and kneecap them, or long and hit them in the face, but I think this is less likely if you are at an oblique or acute angle (because there are less squares that are behind him you can scatter to, but still hit him - especially as you get further and further away so the aliens width becomes less of a factor). Equally with height, the further up you are, the less squares the fire can scatter to but still intersect with the alien.

Does this match up with other peoples experiences?

--[[User:Sfnhltb|Sfnhltb]] 12:59, 27 February 2007 (PST)

-----

Hmm, I'm not sure what I'd say. In theory the "silhouette" wouldn't change much, if the angle were not a multiple of 45 degrees (that's what you mean, right?). I'm willing to bet that the engine is more influenced by things that might truncate values here and there, than anything else. And/or the interaction with exactly how they "draw" the "3D" target that the shot's trying to intersect. I'm sure it's crude but effective... but crude in what ways? shrug. - [[User:MikeTheRed|MikeTheRed]] 15:50, 28 February 2007 (PST)

----

Does the accuracy displayed in-game for the auto-fire apply to each individual shot or to all three shots?

: It applies to each individual shot. -[[User:NKF|NKF]] 22:39, 1 December 2008 (CST)

:: Indeed. Note that the displayed "chance to hit" isn't really your ''chance to hit''... It's more a measurement of the ranges of angles you can fire along. - [[User:Bomb Bloke|Bomb Bloke]] 00:37, 2 December 2008 (CST)

::: In Laser Squad Nemesis, that is explicit - units have a stat called "inaccuracy", defined as "The average deviation from true for a weapon shot, in degrees." Has anyone made tests in X-Com, what is the relation of distance to target and displayed and actual chance to hit? - Quantifier 05:14, 2 December 2008 (CST)

::::[[User_talk:Bomb_Bloke#Firing_Accuracy|Yes, this has been done.]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:49, 2 December 2008 (CST)

: As in "spread" of your shots, BB? Where bigger spread means, less accurate? -[[User:MikeTheRed|MikeTheRed]] 04:15, 2 December 2008 (CST)

----

What, exactly, happens when you miss? Does the game shift your aim by pivoting around the fire point or actually pick a random location in 3D that's close'ish to the target? It seems to me like it's the latter due to your ability to miss and shoot the ground right at your feet when shooting at nearby aliens. This doesn't seem to happen for farther away targets. Would this then suggest that aiming behind your target could potentially result in more hits on target due to more "misses" hitting? I haven't tried this tactic in practice.

Talk:Accuracy formula

2011-04-01T11:10:28Z

Mannon:

From experience I think the chance of hitting an alien tends to be best if in an exact straight line (orthagonal or diagonal), and on the same level as it. This probably is explained by the misses that hit anyway, because you can miss slightly short and kneecap them, or long and hit them in the face, but I think this is less likely if you are at an oblique or acute angle (because there are less squares that are behind him you can scatter to, but still hit him - especially as you get further and further away so the aliens width becomes less of a factor). Equally with height, the further up you are, the less squares the fire can scatter to but still intersect with the alien.

Does this match up with other peoples experiences?

--[[User:Sfnhltb|Sfnhltb]] 12:59, 27 February 2007 (PST)

-----

Hmm, I'm not sure what I'd say. In theory the "silhouette" wouldn't change much, if the angle were not a multiple of 45 degrees (that's what you mean, right?). I'm willing to bet that the engine is more influenced by things that might truncate values here and there, than anything else. And/or the interaction with exactly how they "draw" the "3D" target that the shot's trying to intersect. I'm sure it's crude but effective... but crude in what ways? shrug. - [[User:MikeTheRed|MikeTheRed]] 15:50, 28 February 2007 (PST)

----

Does the accuracy displayed in-game for the auto-fire apply to each individual shot or to all three shots?

: It applies to each individual shot. -[[User:NKF|NKF]] 22:39, 1 December 2008 (CST)

:: Indeed. Note that the displayed "chance to hit" isn't really your ''chance to hit''... It's more a measurement of the ranges of angles you can fire along. - [[User:Bomb Bloke|Bomb Bloke]] 00:37, 2 December 2008 (CST)

::: In Laser Squad Nemesis, that is explicit - units have a stat called "inaccuracy", defined as "The average deviation from true for a weapon shot, in degrees." Has anyone made tests in X-Com, what is the relation of distance to target and displayed and actual chance to hit? - Quantifier 05:14, 2 December 2008 (CST)

::::[[User_talk:Bomb_Bloke#Firing_Accuracy|Yes, this has been done.]] [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:49, 2 December 2008 (CST)

: As in "spread" of your shots, BB? Where bigger spread means, less accurate? -[[User:MikeTheRed|MikeTheRed]] 04:15, 2 December 2008 (CST)

What, exactly, happens when you miss? Does the game shift your aim by pivoting around the fire point or actually pick a random location in 3D that's close'ish to the target? It seems to me like it's the latter due to your ability to miss and shoot the ground right at your feet when shooting at nearby aliens. This doesn't seem to happen for farther away targets. Would this then suggest that aiming behind your target could potentially result in more hits on target due to more "misses" hitting? I haven't tried this tactic in practice.

The Mysteries of X-COM

2011-03-30T17:12:13Z

Mannon: /* Why did the aliens use limited force during the First Alien War? */

Discussion page for some less clear aspects of the series

==General issues==

==='''How fast can alien craft travel in space?'''===

Some alien missions (repeated attacks on X-COM bases, for instance) come daily. This seems to imply that alien craft are able to travel the distance from Mars to Earth in a matter of hours.

: Or maybe, as you suggest in your novels, they have a staging area near Earth, such as the dark side of the Moon. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)

::Really fast. Consider that they don't need to push aside atmosphere, as well as the fact that momentum is conserved in space, so they can achieve very high speeds with gravity slingshots. (Mars DOES have 2 moons, recall.) Also note that they may be operating a bit closer to home(the far side of the moon, perhaps?) it's simply that the command staff are at Cydonia. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Good article in last month's Scientific American pointing out we only rely on gravity slingshots because we still use chemical rockets with pathetic delta-V. Once 2nd and 3rd generation plasma engines come on line (1st gen are in flight now) the gravity slingshot will become an irrelevance. No doubt UFO drives are at least as good as our (future) 3rd gen plasma drives, probably way better since they warp space.

(Reminds me of the old Guild Navigator joke - I just warped space from Ix, and boy is my mind tired. Oh well, you had to be there)

[[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Also keep in mind that both Phobos and Deimos are tiny. They are basically captured asteroids. Neither would be useful in gravity assist. But yeah, the UFO's shouldn't need any assist anyway.[[User:Mannon|Mannon]] 11:35, 30 March 2011 (EDT)

==='''What happens to the crashed UFO craft and its crew?'''===

Downed alien craft disappear after a few days have passed. No explanation is given to this whatsoever, so what really happens to them?

Possible answers:
* The UFO and its occupants are recovered by other humans.
* The Aliens manage to repair the craft and fly back to space. (unlikely, in the event that the power plant blew up and they have no Elerium)
* The Aliens self-destruct the craft and kill themselves in the process, ensuring their remains will not be recovered by humans.
* The UFO Powerplant eventually suffers a meltdown and explodes, eliminating any vestiges of alien presence.
* The Aliens blow up the UFO and disappear into the countryside.
* Most likely answer, IMHO: The local government/ funding nations give X-COM a limited time window to launch any operation, similiar to what you see in covert ops movies: "Complete the mission within 36 hours, or we initiate Carpet Bombing of the area". This is very likely considering that each nation actually has jurisdiction, and X-com is operating each military op with permission and cooperation by local authorities. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
*Similiarly, I assume that nations which have signed a pact with the aliens launch a rescue operation and assist their alien friends. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
: In the UFO TV show, it's stated that alien craft and bodies degrade quickly in Earth's atmosphere, disappearing completely in hours or a few days. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)
:: If that was the case, then one of the gases present in the atmosphere would be very toxic to the aliens. They would be restricted on their activities outside their craft, not to mention they would have to terraform the planet to be able to live here. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

:: As Zombie said, doesn't Alien Containment support this idea? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::Those are excellent suggestions. One of the X-COM books detailed that aliens throw up a force field around crashed UFOs to give them time to repair the craft. This would also explain the limited size of the Battlescape (the area of the force field...the field was thrown up before the crash, thus why the craft wasn't always centered in it) as well as why the Battlescape is devoid of human life(the aliens took care of that up front.) Similarly, large scale bombing works as well, as does the local government going in to clean it up themselves. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
:::If there's a force field around the craft what is it supposed to repel? The atmosphere? Because humans have no problem entering the field and operating inside it. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::::Of course they do! Have you ever noticed how dumb your units can be? That's because the aliens can't live with too much nitrogen, so they turn some of it in their force field to oxygen, and excessive amounts of oxygen make you act weird. After a while, their power source runs out and the nitrogen returns, dissolving them into E-115. (What did you think it was made of?) AT least, that's what seemes logical to me, ad is a combination of many postulates here. 21:36, 18 March 2010 (EDT)
:::::That would require that the aliens' biochemistry and the alien alloys used in the power sources reacted with nitrogen, which is a mostly inert gas on normal temperature and pressure and a . It's kinda of weird that the aliens didn't bothered with fixing that vulnerability with their craft and bodies during millions of years (what happens if the force field malfunctions while capturing cattle? ooops!) but ok. The increase in the amount of oxygen would probably also turn any kind of fire into large explosions throughtout the force field. [[User:Hobbes|Hobbes]] 21:24, 19 March 2010 (EDT)
::The force field was intended to keep humans out so the aliens were undisturbed. The first major hurdle X-COM had was figuring out a way to bypass those fields so they COULD get troops and aircraft inside. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===How do the aliens carry their equipment?===
Like human soldiers, aliens can carry weapons and equipment in locations like legs, belt, shoulders and backpack, regardless of the fact that some of their races even lack those anatomical features.

:Potentially a sticky gel-like area on the limb. Though really, since we were never intended to access alien inventories and the AI does all inventory management internally, this may simply be something that was never considered. Speaking from a slightly different standard, most aliens do not carry excessive amounts of gear; often their equipment would be able to fit in both hands. Also recall that Floaters and Ethereals have capes and robes(which may have inside pockets, or the Floaters could store them in the anti-grav/life support unit or inside surgically created body cavities during the installation, while Ethereals could support their excess gear with telekinesis), Mutons have armor(which may have external straps or adhesive areas), and Snakemen have an armor plate(which could have straps, adhesive, inside pockets, or even a backpack.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:We already know the answer to this one - they cheat! ;) [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

===Are X-COM transport craft piloted?===

:Almost certainly, since a remotely-piloted craft could be returned to base when the mission was aborted or failed. It's entirely possible that all X-COM soldiers are qualified pilots of the appropriate craft, since it would make no sense for X-COM to waste space on the plane for a noncombatant, or to have a single-point of failure on the mission like that. (The aliens could screw over the entire op by killing the pilot). It also explains why the craft is lost when the mission fails or is aborted with no one inside(lacking a pilot, the aliens are able to easily destroy it.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:: On the other hand, even a tank/hovertank is capable of getting the craft back to base. Perhaps there is an autopilot function. X-com craft are also infamous for choosing strange and bizarre intercept paths, based on latitude lines... almost as if they followed some a few simple lines of code from 1993 programming (bit of 4th wall breakage there...) -[[User:Jasonred|Jasonred]]

:Of course, given the tanks seem to be remotely piloted from an X-COM base, its possible that the tank being in the craft allows the Tank pilot to reroute into the control systems for the dropship and take it over. Limiting this to having the tank inside is a rather good idea. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

:I recall that the various cutscenes in the PSX version had a pilot, most notably in the "Mission Failure" scene, where it shows the pilot being killed. --[[User:Mabmoro|Mabmoro]] 16:06, 13 March 2009 (EDT)

===What sort of physical process is used to increase human stats over time?===

The increases in some stats are easy explained by experience gained on missions (firing abiility, reactions, etc.). However, in the cases of physical stats (TUs, stamina, strength) the increase must be augmented by an artificial process, since it isn't easily explainable that humans can significantly increase body mass/speed/endurance just by physical activity/exercise.

:Lifting weights will increase strength. Running and cardio exercise will increase endurance, and performing the same task multiple times will allow you to perform it faster. I see no reason natural increase doesn't work. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)
::I assume that it is possible to a human to use those methods to double its physical condition, but that being the case why are X-COM recruits so... undeveloped? Maybe this is a more intriguing aspect. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

What I don't get is that when someone gets blasted that they gain a lot of extra health. For crying out loud, the aliens are throwing around plasma and ridicoulously HUGE explosions. Shouldn't they be suffering from third-degree burns? I would expect them to at least have a major sore spot where they got hit. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] September 24

:There's been arguments over whether the soldiers in X-COM are the Green Berets or equivalents of their various militaries, just average soldiers that volunteered for the job, or if the Council of Funding Nations is corrupt and is using this as an excuse to foist off their most useless soldiers onto the X-COM project. If the latter, it would easily explain their rather poor early stats. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

::Maybe the stat increases relate to the troops getting more comfortable performing all operations - lifting, running, combat actions - when the aliens no longer scare the cr*p out of them so much. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:: I know what you mean... if this were Jagged Alliance, it'd be like trying to hire Mike and getting Gumpy instead... ouch! ... IMHO, it looks as if the COFN is being funny about this. Clearly, the troops assigned to X-com have had extensive weapons training... each and every one of them can use just about any standard weapon, including Rocket Launchers, incindieries, auto Cannons, etc. However, NONE of them have any combat experience, coming to you as fresh rookies. And their stats look as if they were selected based on a pot luck basis rather than screening among the elite troops... [[User:Jasonred]]

:Health isn't gained from getting shot. But as for the "ludicrously low stats" issue, maybe they're being selected on some other basis, or there's a real shortage of volunteers. [[User:Magic9mushroom|Magic9mushroom]] 04:56, 25 September 2009 (EDT)

:: I think that the X-COM's soldiers have big responsibilities, can't have children. They are sworn in and only then go to the field - if someone can't be trusted to keep a secret, he's getting sacked, given a shitty job (ever wondered who maintained the General Stores?) or worse. - n, 16:47, 16 August 2010 (GMT+2)

In Hotpoint's [http://www.tthfanfic.org/Story-16092/Hotpoint+XSGCOM+Goa+uld+Defence.htm| XSGCOM: Goa'uld Defense], his explanation is that after a few missions of watching their fellow newbies die, the survivors give in and volunteer for an experimental regimen of performance-enhancing drugs. IRL, steroids and such don't result in instant strength enhancement, they just encourage accelerated development of muscles. [[User:Kalaong|Kalaong]] 03:16, 28 March 2011 (EDT)

==Enemy Unknown/UFO Defence issues==
==='''Why isn't Earth overrun by Snakeman/Chryssalids?'''===

According to the UFOPaedia, Snakemen's "Reproduction is asexual, with each snakeman carrying up to fifty eggs inside its body at any one time" adding the ominious conclusion: "Left to its own devices this species would be a severe threat to life on earth."
Moreover, this species is usually accompanied by the Chryssalids, which have a capacity to reproduce themselves very quickly using humans. So, any survivors of crash sites or terror attacks could start reproducing themselves hidden, resulting in large areas being overrun by those aliens later on.

Possible answers:
* Both races have a self-destruct mechanism incorporated into their psysiology to prevent this.
* The entire area is purged by large scale bombing. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)

::One thing suggested in fan data was that Snakemen have air tablets in their stomach...which may be different from earth's atmosphere, which would limit their lifespan in earth's atmosphere, also making egg-laying pointless, since the offspring wouldn't be able to breathe or survive. It has also been suggested that Chryssalids have a very rapid metabolism. Though Chryssalids are likely just as, if not more useful, as a threat or a bargaining tool. When attempting to get a nation to capitulate to their demands, the aliens could threaten to employ Chryssalids en masse, or offer to remove a mass infestation in exchange for the government's cooperation. Or even further, it's possible that Chryssalids are under Ethereal control and maintaining the control link at that distance is taxing, thus eliminating mass use of the creatures. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Two words: [[Alien Containment]]. That answers everything except for the UFOPaedia articles for the aliens themselves which contradict it. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)
: For captured aliens, yes. But what survivors of uninvestigated crash sites? [[User:Hobbes|Hobbes]]

::Zombie is commenting that based on the need for an Alien Containment unit, the aliens cannot survive in earth's atmosphere for extended periods, needing special atmospheric blends and/or nutrient pools which earth is unable to provide naturally, thus limiting their operations outside of the craft. (If the aliens won the war, it's likely this would be one of the first things that they would 'correct'.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===What is the propose of the 'disco balls' found inside some UFOs?===

:Given that they explode, they could be storage reservoirs for coolant for the computers or other systems. They could also be circuit breakers or electrical junction boxes, or even a component of the UFO's particle beam they use to fry X-COM Interception craft. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Here again, two words: [[Alien Entertainment]]. Even though the spheres are not set to Alien Entertainment in the MCD files, they are almost certainly related to the process somehow. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)

:Maybe they are for having discos? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Presumably [[Alien Entertainment]] is psionic in some way, maybe they're Psi-Emitters or something? -[[User:magic9mushroom|magic9mushroom]]

===Who buys those alien bodies/equipment from X-COM?===

:Equipment likely goes to the funding nations or the international black market. No rebel group is going to ask too many questions about being offered guns that can [[Heavy Plasma|slice through the hull of an MBT]] or [[Alien Grenade|grenades that can level a building]] or [[Blaster Launcher|man-portable guided missiles]]; it'd just be cash-and-carry. Similarly, scientists would likely be interested in looking at much of this stuff for their own research. This would also explain the lack of market forces; the funding nations could have a set price for each item, or if X-COM is selling them under the table to rebels and rogue scientists, they can set the price and refuse to budge. The money on corpses could also be an "Alien Bounty" paid by the Funding Nations, as a reward for each alien that X-COM can prove they killed. Or it could be bought by other groups...rumor has it that some fast food restaurants have processes that can make ANY meat, no matter the source, look and taste the same, and a Muton would make a LOT of McBurgers. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
From the USO (Kasey Chang): XARQUID SUSHI.

===How did the aliens got to Mars?===

There are no indications that UFOs are capable of faster than light speed. So how did they get to Mars in the first place?

:The UFOs are mission craft, used for the legwork. The fighters; we never see the carriers. Given the aliens have been proven to be interstellar, they either Clone-A-Crew as needed when coming the long way to keep the UFOs crewed, or its far more likely that the aliens did have or still do have larger "Carrier" ships, which are capable of FTL travel, that were/are further out in the Solar System that store and dispatch UFOs to mission locations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: One word: TFTD. The entire city of T'leth was put into cryogenic suspended animation? Or look at X-com Interceptor. X-com and the aliens show the ability to enter hyperspace or whatever it is.
::: T'Leth is another mystery of its own. More to that later on :) [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::... there are no indications that the UFOs are INcapable of FTL... I don't think you would want to perform FTL travel within Earth's planetary atmosphere!
::: There are no indications that they are capable as well. And X-COM scientists don't seem to detect any FTL capabilities in UFOs during their research. And after the war the Elerium stocks dwindled, and it would make sense to perform some sort of interstellar missions to detect and harvest Elerium, however none are mentioned. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
:::: Unless you count the events of X-com Interceptor? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 21:15, 26 February 2009 (CST)
::::: I am refering to the events between Enemy Unknown and TFTD. There is clearly a big distinction between the alien craft on EU and those of Interceptor. [[User:Hobbes|Hobbes]] 09:38, 27 February 2009 (CST)
::::: Enemy Unknown is set in 1999, TFTD in 2040, Interceptor in 2067... looks entirely plausible that they DID begin research into space exploration immediately after the events of Enemy Unknown. These things take time you know. Remember that the universe is a huge place, and Earth had rather limited Elerium Reserves by the end of EU. It takes... what, 30 Elerium just to fly an Avenger halfway across Earth? They could hardly afford to fly around randomly in space HOPING to come across elerium, they had to figure out detections methods, then scan the galaxy sector by sector, possibly partially using non-Elerium based propulsion at times... I can't remember if it's canon or fanfic, but I remember reading that all Elerium on Earth was reserved for space exploration.
As for FTL, Earth does get it for sure sometime between 1999 and 2067. And I'm pretty certain the technology is Elerium based. It's not a huge logic jump to assume that the aliens have access to FTL Elerium based tech.
Though I'm a bit puzzled why all T'leth technology is based on Zrbrite, when the aliens uniformly use Elerium, all the way from Earth to Cydonia to the far reaches of space. -[[User:Jasonred|Jasonred]]

:It takes 12 Elerium to fuel an Avenger, though how much 1 Elerium is is an ongoing debate. As for Elerium, it was reserved for propulsion research when the funding nations divvied up X-COM's resources, and then they blew it all without learning anything more than the original X-COM scientists. And yes, Earth clearly gets FTL after TFTD but before Interceptor. The reason Elerium is not used in TFTD is because Elerium becomes inert and useless upon contact with seawater. Similarly, seawater aggressively corrodes Alien Alloys and eventually completely dissolves them. Zrbite functions similar to Elerium, being gold mixed with alien bio-material. Unfortunately, Zrbite only works when supported by a massive energy grid created by T'leth and becomes inert upon its destruction. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

OK... take the UNIT of elerium out of the equation... let's say that Earth had 5000 units of elerium, so 6 units get's an Avenger halfway around the world, and 12 units is sufficient to reach Mars. Hardly enough fuel reserves for intergalactic travel then.
2065 On October the 27th, the probe 'Tombstone 1' returns reports to Earth. It's data show that the globular star cluster where it rests, one hundred light-years from Earth, contains many life-supporting planets. Many of the planet's within the probe's scanning range also apparently possess great mineral wealth, including trace veins of elerium-115.
Hmm... So, mankind discovers FTL technology on their own in those 65 years? ah... come to think of it, if they've got non-Elerium based space travel and FTL, and more powerful weapons too, what's the big deal about Elerium in the Frontier? Does mankind even need it anymore?
As for T'leth, it is meant to be over 65 million years old, and CRASHLANDED on Earth due to a solar flare. Was the Ultimate Alien a prophet, thus chose to base T'leth on aqua plastics and Zrbite when T'lth was first constructed? Or did T'leth crash land, followed by frenzied activity where the entire city was replaced part by part, the alien alloys swapped for Aqua Plastics?
...
Actually, come to think of it, it's obviously a massive plothole due to limited timeframe, no point in discussing too deeply. Sigh... [[User:Jasonred|Jasonred]] 13:50, 27 February 2009 (CST)

:It's implied that despite the loss of ability to use the alien technology from the First and Second alien wars, simply being able to see and examine their designs catapulted earth's technology forward at least a few decades...which really is entirely reasonable. Much of the technology can be replicated on earth, and the principles and designs can be reapplied.

:As for the deal with Elerium, its needed to power stronger weapons and is also wonderful for power generation; its efficiency in power generation is what allows Mega Primus to even exist.

:And was there anywhere that specifically said that T'Leth was made of Aqua Plastics? I don't recall. Yes, the rest of their subs are made of aqua plastics, but I'm wondering if something the size of a medium city might perhaps be made of something a bit more durable. PS: Thanks for signing your post! :D [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:17, 27 February 2009 (CST)

It's not a plothole at all. There is no Elerium on Earth, whereas the aliens can manufacture Zrbite on Earth, since there's gold here. Therefore it's obvious why they used Zrbite. Also, there's the fact that it was an Aquatoid colony mission, intended to produce an "aquatic paradise", so using Aqua Plastics instead of Alien Alloys is perfectly justified. [[User:magic9mushroom]]

:I think that the use of Aqua Plastics instead of Alien Alloys is perfectly justified by the fact that T'leth crashed million of years ago while the aliens that came to take a shot or two at earth were two million years ahead technologically. So Aqua plastics was some plastic that was used by aliens before they've got the Alloys. You might argue - it's Aqua Plastics, so Aqua =/= Space. Well, Aliens weren't calling them aqua, and there wasn't anything saying that Aqua Plastics is not suitable for Space Travel. --[[User:Domenique|Domenique]] 11:10, 19 May 2010 (EDT)

... I think Alien Alloys alone would catapult earth's technology forward a decade, and there's no reason humanity can't use those anymore, just not in water. According to timeline, some space pirates manage to make the decommisioned Avengers run on non-Elerium fuel... a large technological step.
By the time of Interceptor, Elerium weapons aren't that powerful. Good point about power generation though.
I would assume that T'leth SHOULD have been constructed out of Alien Alloys, since it was originially an interplanetary vessel? Generally, everything in EU was made of Alien Alloys, everything in TFTD was made out of Aqua plastics. Both of which seemed plenty durable.

::Have you noticed that the UFOs fly however their mission parameters tell them to? The UFOs pretty much IGNORE interceptions by X-com craft... if their mission tells them to make 3 passes, speed up, slow down, speed up... they will follow that pattern exactly, whether X-com craft are firing on them or not.

::Question: How long does it take the Avenger to reach Mars from Earth? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)
:::No longer than a week, in my opinion. Probably less than 2 days. Since canonically, the design of the Avenger had the Cydonia mission in mind, it would be capable of very high interplanetary speeds. (You could choose to burn 40% of the Elerium in one blast to get to high speed. Or you could burn even more and refuel while it's landed...or it could be a mission with no guaranteed escape for the crew. The lives of the many over those of the few and all that, especially since the war hinges on the mission.) In addition, you can fit a full complement of soldiers on board with no real excess room for supplies, and the longer it takes to get to Mars, the greater the chance the aliens will spot it coming for them and mount a serious defense. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:20, 26 February 2009 (CST)
:::If you'd burn that much fuel to accelerate the craft then you'd have to use as much again to decelerate it and attain a planetary orbit, otherwise you'll simply overshoot the planet and head towards outer space. This is also another aspect to take into account when thinking about the speed of UFOs. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

::: UFO drives are non-Newtonian so those sort of rocket equations don't necessarily apply. I think filling up a car with gas is a closer analogy. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::: Well, they could put a mini mind shield on the Avenger, shoot down a UFO roughly their size, and then fly to Cydonia when the UFO they shot down was supposed to return based on the instructions found by the hyper-wave decoder. Basically taking the place of the UFO. Shouldn't be too hard since the UFO's are pretty common by the time you research Cydonia or Bust. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] 14 February 2010 (MST)

::That would leave 20% of the fuel to take off the Avenger and land it. Not really that unreasonable. While they're landed, they could potentially refuel the Avenger, or the mission might have been planned as a 1-way trip from the get-go. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===What happened to Mars and the alien civilization there?===

According to the Brain, Mars was blooming with life had a alien civilization millions of years ago. However, Mars nowadays is a barren world and the alien civilization seems reduced to the area on Cydonia.

:That may well have been before Mars lost the majority of its atmosphere due to its weak magnetic field. As the atmosphere dissipated, the aliens left or died off. It's also possible that the aliens, shown in the game over to have little respect for planets other than as sites for slaves and resources, they strip-mined the planet dry(and the rust from the machines created the red coloring), and then seeded Earth so that the slave workforce would grow for future extraction of Earth's resources. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

===Where are the human-alien hybrids referred to on the UFOPaedia?===

:For the ones on earth, probably in hiding or in laboratories for research. For the ones the aliens have, potentially improving the Sectoid gene pool or being used as food or menial tasks. Cloning is alot easier than making genetic hybrids and there's nothing that says their first-generation experiments would be suitable for combat. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: They are babies at the time of X-com, and few in number. Their aren't even that many of them by the time of X-com Apocalypse. [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)

:Not to mention the ones in X-COM: Apocalypse are less-than-fit for battle before extensive training. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===Why did the aliens only activate T'Leth after they were defeated?===

On TFTD T'Leth is shown as an entity/city of major power that is capable of conducting a war on its own. But the aliens leave it dormant although they could have used it to speed the process of taking control of Earth.

:Perhaps the Enemy Unknown aliens are legitimately scared of the TFTD aliens and are unsure how long they could trust them. Evil is not monolithic; the TFTD aliens may be more interested in themselves than the alien empire, so they were kept as an ace-in-the-hole. This is the same reason (canonically) that SKYNET did not originally send the T-1000 to assassinate Sarah Connor; SKYNET was scared of what the T-1000 could do and had only a bare minimum of control over it, so it only used it as an option when it had nothing left to lose. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

T'Leth is in fact so powerful that all it has to do is surface, in order for X-com to be considered to have lost the war.
In fact, looking at the timelines, it takes 40 years for T'leth to wake up from it's slumber... that's one good reason not to use it. By the time it activated, the war would already be over. [[User:Jasonred]]

Because the whole purpose of the Enemy Unknown aliens was to rescue the TFTD aliens from T'leth, and there was no way of seeing whether the T'leth-based invasion in TFTD would even work - from their perspective it's possible that getting T'leth to bootstrap itself could have caused a catastrophe (they don't know whether or how badly it's damaged). Presumably the aliens planned to mount a proper rescue operation after locking down Earth and readying it for the aquatic paradise that was the entire point of the T'leth expedition in the first place. [[User:magic9mushroom]]

T'Leth was a coleny ship sent by the Sectoid/Aquatoid's millions of years earlier. This is why the Aquatoids use electronics to augment there control over other creatures, while there progeny are genetically modified to gain the same control. In TFTD it's implied that the T'Leth had been partialy active for a long time. Thawing out aliens in small groups but never going in full production. UFO aliens may have not intended to start the full awakening cycle until they had a chance to prepare the planet.
OR, given the Ultimate Alien was aquatoid in origin by his looks and there was no other races from the first game involved. And the fact that Sectoid/Aqutoid's are not the top of the food chain with the Ethereal and Brain being more powerful it's possible the brain had decided that the Ultimate Alien was a threat to it's power. It was not until it's death that they tried send the signal. --[[User:BladeFireLight|BladeFireLight]] 17:19, 22 March 2010 (EDT)

===Why did the aliens use limited force during the First Alien War?===

Imagine Independence Day or War of the Worlds: UFO above the major Earth cities destroying the national leadership and any resistance. Or simply announce to Earth that they are now a part of their empire and resistence is futile. Instead, they go 1 mission each day, allowing humans to capture their craft, research their technology, discover their intentions and mount a successful defense. Don't the aliens watch sci-fi movies to see how it should be done?

:Perhaps they don't have the standing forces to do so, and are in the process of building up the forces needed to do so. Perhaps they don't want to wipe out the entire power structure too fast; they want to leave some pieces in place for when they rebuild. Perhaps they're too condescending to think that humanity ever really has a chance; they've probably conquered thousands of other planets without anyone ever successfully resisting them. Perhaps they consider the X-COM project to be a rearguard action that, while a valiant effort and a credible threat, is ultimately doomed to failure because they simply cannot win in the end, which is why they undermine it. Indeed, the reason you need to launch the Cydonia mission in order to win is because X-COM simply cannot stop the aliens in a ground war; the aliens have an effectively infinite supply line and standing forces(though nothing says they're all waiting to swamp the earth), and the only way to win is to kill the command staff(which the aliens believe X-COM will not be able to do, lacking both knowledge of where the Brain is and any practical means to get there.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)
::The most plausible explanation seems to be the one employed in the Worldwar series, by Harry Turtledove, but that does not seem to mesh with what the Brain says about having been on Mars for a while, since then they could watch the Earthlings perpetually. Of course, what it says is probably a bunch of lies. Thinking about what it says for too long also raises the question of why the aliens attacked when they did, of course... [[User:Vizzydix1|Vizzydix1]] 21:52, 18 March 2010 (EDT)

The aliens are completely lacking in weapons of mass destruction. When you get right down to it, their aircraft are very fast, manuevarable and durable, but they have rotten firepower. Even the battleship is unable to bring down an Interceptor in 1 shot.
The terror missions and X-com Base Defences prove that the Aliens are unable to simply launch orbital bombardments... in fact, they appear to have no Air to Land weapons whatsoever...
When you get right down to it, the aliens are pretty stupid. Also, their scientists seem inferior to Earth's. Seems to me that they only had the advantage of Elerium deposits and thus elerium based research.
X-COM was unable to win in an all-out war with the aliens, but remember that X-com is a small little covert group with several dozen soldiers and a handful of aircraft. Can you imagine the result if the aliens had caused a joint war effort by the UN? You would have Lockheed factories converted to Avenger production, several platoons of soldiers outfitted with Flying Suits, Lasers, Heavy Plasma, thousands upon thousands of Laser Tanks...
I would say that keeping the fight to covert action on both sides was actually beneficial to the aliens, really. [[User:Jasonred]]
* Nope, the aliens could just invoke John's Law and blow up the planet with a kamikaze battleship at .9c. Even failing that, the alien battlefleet could come in numbers sufficent to blot out the sun.--[[User:(name here)|(name here)]] 14:39, 8 November 2009 (EST)
** Lest we forget, X-Com is essentially the Spartans to the aliens' Persian Empire. So they'd just fight in the shade (which would be a blessing in desert missions). --[[User:Guido Talbot|Guido Talbot]] 13:58, 16 July 2010 (EDT)

Aliens first began with smal scouting missions, so maybe all we expirience in X-Com is initial attacks by aliens, maybe the whole base was begining scouting and waiting for the invasion fleet? Aliens problably could be in sense dumber than humans, humans are adaptable and thinking, our technology advances fast, and we are fast and smart enough to stop the invasion before it begins. Aliens problably were not used to it so they thought "oh well, another invasion...". --[[User:Domenique|Domenique]] 11:10, 19 May 2010 (EDT)

Mankind, as a whole, is incredibly cunning and full of guile. We are also incredibly aggressive. A trait that the most of the Aliens can barely concieve. Though we are weaker physically, mentally, etc, we are overly developed when it comes to strategem and war. The aliens are, in essence, have come to an inverse of Flatland. Though they are advanced, it is they who are 2D to our 3D approach to fighting. They return to earth, and through extensive research and testing, determine that inferior are strategically to humans. So...they use their advances to what they percieve as the most full advantage, and call for reinforcements over the initial months of the First Alien War. For eons, only the Sectoid make arrivals to earth. When the Brain finally realizes the situation, that mankind has woke up and is dealing with them most directly, it begins to get desperate, it sends reinforcements, but only incrementally. (Its always focused on peak efficiency). The concept of overwhelming force is illogical and some how, disdainful, to it. It prefers nuance, interogation, politics, and assessment. The Brain determine that its more effective to eliminate allies of XCOM than to face it directly. The concept of obliterating anything from orbit is reprehensible. Everything must be examined, especially the dead creatures you leave behind. Over time, it would learn man's tactics and assimilate. In fact, each race called in is an example of the Brain adapting. The Floaters bring forth an extra dimension to combat. The snakemen aggressiveness and accuracy. Mutons a culmination of superior warrior breeding, raw physical power, and determination not unlike the so called human soul. Finally, the Ethereals enter, with capacity to bring overwhelming force. In time, as they do on Mars base, they might begin joint force attacks with Mutons backed by Ethereals, supported by a mix of terror weapons. Fortunately, the First Alien War is ended before they fully develop such cunning. Hence the desperate act of T'Leth. The Brain has learned the power of anger fueled by vengeance and desperation.
--[[User:BlackLibrary|BlackLibrary]] 11:10, 29 May 2011 (EDT)

:I've always viewed it as primarily a lack of resources. Even if you get a UFO every single day and shoot them all down so that there's no possible chance of any of them being the same UFO that's still only several hundred to perhaps a thousand or few UFO's over the course of several years. And most of those are quite small and not too difficult to take out with regular old interceptors and human armaments. If used all at once it might be enough to achieve air superiority, particularly if the Battleships do all the heavy lifting. But it also might not. It certainly would NOT provide enough soldiers to mount a worldwide ground offensive. The crews on those ships aren't all that big. There's also no reason to assume that all those craft, weapons, soldiers, and more importantly... elerium are all available at the same time. It's quite likely that the aliens are cloning new soldiers, building new weapons and UFO's, and possibly receiving supplies (particularly of elerium) from deep space. Elerium is needed to manufacture a lot of their stuff as well, and we already know it's a limited resource in our solar system. Consider on top of that how much get's used up as fuel every time a UFO visits Earth. If they sent all their UFO's they would use up their reserves of Elerium all at once for a 1 day attack that ultimately would fail. Instead of conquering the Earth wholesale they are trying to influence governments into signing secret pacts with them so that they can control the population of the Earth rather than wipe us out. They do this by using terrorism to intimidate the public and inserting clones to infiltrate governments while holding secret negotiations. A steady stream of UFO missions keeps up the pressure until governments break. Lucky for us they never expected us to bring the fight to the command center on mars. Just imagine if they had built base defenses like we can for our bases. heh Lord would it be aggravating building up a crew of top notch soldiers, constructing an Avenger from scratch, scrapping together all the gear, sending it to Mars, and then watching it get blown to bits before it even lands... O,o Also consider that their UFO's have operated with relative impunity for a very long time. Presumably XCom is the first organization to shoot down a UFO? As for Earth ramping up for a full scale war, it'd be unlikely that we could really produce enough alien technology in any reasonable timescale to actually outfit whole nations armies, especially with limited Elerium. Perhaps the tech that doesn't require Elerium, but then again shifting an entire army from one weapon system to another is not as simple as merely producing all the weapons. It's an extremely long, arcane, and baffling process. Getting just the branches of the US military to switch to laser weapons would probably take at least a decade. I think that limited resources and the intent to control and dominate rather than eliminate the population of the Earth explain it. For that matter they would see the human population it-self as a resource. Hence the use of small scale terrorism rather than attempting to use any weapons of mass destruction. A bunch of aliens walking around shooting people is still pretty damn scary stuff.[[User:Mannon|Mannon]] 13:12, 30 March 2011 (EDT)

==TFTD issues==
===What was the relationship between the aliens from the 1st and 2nd wars?===

Quoting from the UFOPaedia regarding Alien Origins: 'Deep in the oceans there lie ancient
sites used by the Aliens to contact their stellar cousins.' This also has some implications regarding the issue of why T'Leth was only activated when the Sectoids were defeated.

*Gill Men are coopted Terran creatures, Aquatoids are a differently-modified Sectoid breed, Lobstermen are machine soldiers that are manufactured, Tasoths are clone soldiers that are grown.

Aquatoids are the ancestors of the Sectoids. The colony ship was sent out slowing than light hundreds of millions of years ago. Sectoids are a more genetically advanced race. The rest of UFO aliens were picked up after that point. The Brain and Ethereals probably conquered the Sectoids and don't regard them highly. While the Aquatoids that were thawed over the years created, conquered (Gill Man) or manufactured the rest of the allies over time. I picture the Tasoth as probably something they brought with them and have been working on. Since most of the Aquatoids come from suspended animation they have not tinkered with genes much. Instead modifying and using electronics (MC Chip) to control. --[[User:BladeFireLight|BladeFireLight]] 17:28, 22 March 2010 (EDT)

===What kind of materials were 'synomium' and 'adamantium'?===

The first one is mentioned on the name of the alien communication devices and the second one appears at the end when T'Leth is destroyed: 'he twisting hugeness of T'leth begins to rupture.
Flames and smoke spew from its gleaming spires and adamantium halls.'

:Synomium is probably a special material used in the comm. devices, like Stargate's naquadah (universal stuff), naquadria (unstable power source), trinium (hull material) and neutronium (superdense metal). Adamantium is a legendary material in ancient literature that is said to be indestructible, similarly to mithril.--[[User:Amitakartok|amitakartok]] 10:55, 3 November 2009 (EST)

===How deep were X-COM bases located on the seas?===

*Floating bases would be easier to build, repair and supply. However they would have to be tethered to the ocean bed or possess some sort of propulsion to prevent them from drifing with the ocean currents. But it would also allow for easy redeployment of the base.
*Submersible bases could allow for better sonar detection. Same problems regarding ocean currents would apply. In case of hull breaches entire modules would be quickly flooded and any crew present would be crushed by water pressure or drown. Base could be built and then submerged (requires depth control)
*Seabed bases would be the hardest to build and supply. Several other factors could limit their deployment, such as unstable areas (underwater volcanoes, prone to seaquakes, rock avalanches, etc.) and depths.
*Given that the Alien Retaliation missions in TFTD are called "Floating Base Attack", I'd say floating. Also remember that your starting sonar can't see Very Deep, which rules out seabed bases. [[User:magic9mushroom]]
** Floating doesn't always happen on the surface. The surface has to deal with large waves ad bobbing up and down, submerged only has the currents it could be stabilized easier. --[[User:BladeFireLight|BladeFireLight]] 11:57, 14 January 2010 (EST)
* I was recently researching how far you have to be down to not be effected by surface conditions. You have to be submerged 1/2 of a waves lenght (measured crest to crest) Best I can find is that the average wave is 150 yards accross. To not be effected by the waves you have to be 75 Yards below. This is way below the depth needed to not be effected by the bends when surfaceing. I figure they are probably right at the limit of what can be safe for quick surfacing and well anchored to avoid getting [http://www.youtube.com/watch?v=LwKXfc_a4Ag tossed in a storm]. --[[User:BladeFireLight|BladeFireLight]] 17:37, 22 March 2010 (EDT)
**Something else to consider - these 'floating bases' could be large modular submarines/submersibles. If memory serves, submarines basically maintain sea-level pressure regardless of the depth, so that could explain why they'd be able to be 75+ feet below sea level and not suffer the bends when surfacing.
::(Or, y'know, we could just say "a wizard did it".) --[[User:Guido Talbot|Guido Talbot]] 14:13, 16 July 2010 (EDT)
[[Category: Fiction]]

The Mysteries of X-COM

2011-03-30T15:35:44Z

Mannon: /* How fast can alien craft travel in space? */

Discussion page for some less clear aspects of the series

==General issues==

==='''How fast can alien craft travel in space?'''===

Some alien missions (repeated attacks on X-COM bases, for instance) come daily. This seems to imply that alien craft are able to travel the distance from Mars to Earth in a matter of hours.

: Or maybe, as you suggest in your novels, they have a staging area near Earth, such as the dark side of the Moon. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)

::Really fast. Consider that they don't need to push aside atmosphere, as well as the fact that momentum is conserved in space, so they can achieve very high speeds with gravity slingshots. (Mars DOES have 2 moons, recall.) Also note that they may be operating a bit closer to home(the far side of the moon, perhaps?) it's simply that the command staff are at Cydonia. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Good article in last month's Scientific American pointing out we only rely on gravity slingshots because we still use chemical rockets with pathetic delta-V. Once 2nd and 3rd generation plasma engines come on line (1st gen are in flight now) the gravity slingshot will become an irrelevance. No doubt UFO drives are at least as good as our (future) 3rd gen plasma drives, probably way better since they warp space.

(Reminds me of the old Guild Navigator joke - I just warped space from Ix, and boy is my mind tired. Oh well, you had to be there)

[[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Also keep in mind that both Phobos and Deimos are tiny. They are basically captured asteroids. Neither would be useful in gravity assist. But yeah, the UFO's shouldn't need any assist anyway.[[User:Mannon|Mannon]] 11:35, 30 March 2011 (EDT)

==='''What happens to the crashed UFO craft and its crew?'''===

Downed alien craft disappear after a few days have passed. No explanation is given to this whatsoever, so what really happens to them?

Possible answers:
* The UFO and its occupants are recovered by other humans.
* The Aliens manage to repair the craft and fly back to space. (unlikely, in the event that the power plant blew up and they have no Elerium)
* The Aliens self-destruct the craft and kill themselves in the process, ensuring their remains will not be recovered by humans.
* The UFO Powerplant eventually suffers a meltdown and explodes, eliminating any vestiges of alien presence.
* The Aliens blow up the UFO and disappear into the countryside.
* Most likely answer, IMHO: The local government/ funding nations give X-COM a limited time window to launch any operation, similiar to what you see in covert ops movies: "Complete the mission within 36 hours, or we initiate Carpet Bombing of the area". This is very likely considering that each nation actually has jurisdiction, and X-com is operating each military op with permission and cooperation by local authorities. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
*Similiarly, I assume that nations which have signed a pact with the aliens launch a rescue operation and assist their alien friends. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
: In the UFO TV show, it's stated that alien craft and bodies degrade quickly in Earth's atmosphere, disappearing completely in hours or a few days. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)
:: If that was the case, then one of the gases present in the atmosphere would be very toxic to the aliens. They would be restricted on their activities outside their craft, not to mention they would have to terraform the planet to be able to live here. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

:: As Zombie said, doesn't Alien Containment support this idea? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::Those are excellent suggestions. One of the X-COM books detailed that aliens throw up a force field around crashed UFOs to give them time to repair the craft. This would also explain the limited size of the Battlescape (the area of the force field...the field was thrown up before the crash, thus why the craft wasn't always centered in it) as well as why the Battlescape is devoid of human life(the aliens took care of that up front.) Similarly, large scale bombing works as well, as does the local government going in to clean it up themselves. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
:::If there's a force field around the craft what is it supposed to repel? The atmosphere? Because humans have no problem entering the field and operating inside it. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::::Of course they do! Have you ever noticed how dumb your units can be? That's because the aliens can't live with too much nitrogen, so they turn some of it in their force field to oxygen, and excessive amounts of oxygen make you act weird. After a while, their power source runs out and the nitrogen returns, dissolving them into E-115. (What did you think it was made of?) AT least, that's what seemes logical to me, ad is a combination of many postulates here. 21:36, 18 March 2010 (EDT)
:::::That would require that the aliens' biochemistry and the alien alloys used in the power sources reacted with nitrogen, which is a mostly inert gas on normal temperature and pressure and a . It's kinda of weird that the aliens didn't bothered with fixing that vulnerability with their craft and bodies during millions of years (what happens if the force field malfunctions while capturing cattle? ooops!) but ok. The increase in the amount of oxygen would probably also turn any kind of fire into large explosions throughtout the force field. [[User:Hobbes|Hobbes]] 21:24, 19 March 2010 (EDT)
::The force field was intended to keep humans out so the aliens were undisturbed. The first major hurdle X-COM had was figuring out a way to bypass those fields so they COULD get troops and aircraft inside. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===How do the aliens carry their equipment?===
Like human soldiers, aliens can carry weapons and equipment in locations like legs, belt, shoulders and backpack, regardless of the fact that some of their races even lack those anatomical features.

:Potentially a sticky gel-like area on the limb. Though really, since we were never intended to access alien inventories and the AI does all inventory management internally, this may simply be something that was never considered. Speaking from a slightly different standard, most aliens do not carry excessive amounts of gear; often their equipment would be able to fit in both hands. Also recall that Floaters and Ethereals have capes and robes(which may have inside pockets, or the Floaters could store them in the anti-grav/life support unit or inside surgically created body cavities during the installation, while Ethereals could support their excess gear with telekinesis), Mutons have armor(which may have external straps or adhesive areas), and Snakemen have an armor plate(which could have straps, adhesive, inside pockets, or even a backpack.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:We already know the answer to this one - they cheat! ;) [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

===Are X-COM transport craft piloted?===

:Almost certainly, since a remotely-piloted craft could be returned to base when the mission was aborted or failed. It's entirely possible that all X-COM soldiers are qualified pilots of the appropriate craft, since it would make no sense for X-COM to waste space on the plane for a noncombatant, or to have a single-point of failure on the mission like that. (The aliens could screw over the entire op by killing the pilot). It also explains why the craft is lost when the mission fails or is aborted with no one inside(lacking a pilot, the aliens are able to easily destroy it.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:: On the other hand, even a tank/hovertank is capable of getting the craft back to base. Perhaps there is an autopilot function. X-com craft are also infamous for choosing strange and bizarre intercept paths, based on latitude lines... almost as if they followed some a few simple lines of code from 1993 programming (bit of 4th wall breakage there...) -[[User:Jasonred|Jasonred]]

:Of course, given the tanks seem to be remotely piloted from an X-COM base, its possible that the tank being in the craft allows the Tank pilot to reroute into the control systems for the dropship and take it over. Limiting this to having the tank inside is a rather good idea. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

:I recall that the various cutscenes in the PSX version had a pilot, most notably in the "Mission Failure" scene, where it shows the pilot being killed. --[[User:Mabmoro|Mabmoro]] 16:06, 13 March 2009 (EDT)

===What sort of physical process is used to increase human stats over time?===

The increases in some stats are easy explained by experience gained on missions (firing abiility, reactions, etc.). However, in the cases of physical stats (TUs, stamina, strength) the increase must be augmented by an artificial process, since it isn't easily explainable that humans can significantly increase body mass/speed/endurance just by physical activity/exercise.

:Lifting weights will increase strength. Running and cardio exercise will increase endurance, and performing the same task multiple times will allow you to perform it faster. I see no reason natural increase doesn't work. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)
::I assume that it is possible to a human to use those methods to double its physical condition, but that being the case why are X-COM recruits so... undeveloped? Maybe this is a more intriguing aspect. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

What I don't get is that when someone gets blasted that they gain a lot of extra health. For crying out loud, the aliens are throwing around plasma and ridicoulously HUGE explosions. Shouldn't they be suffering from third-degree burns? I would expect them to at least have a major sore spot where they got hit. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] September 24

:There's been arguments over whether the soldiers in X-COM are the Green Berets or equivalents of their various militaries, just average soldiers that volunteered for the job, or if the Council of Funding Nations is corrupt and is using this as an excuse to foist off their most useless soldiers onto the X-COM project. If the latter, it would easily explain their rather poor early stats. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

::Maybe the stat increases relate to the troops getting more comfortable performing all operations - lifting, running, combat actions - when the aliens no longer scare the cr*p out of them so much. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:: I know what you mean... if this were Jagged Alliance, it'd be like trying to hire Mike and getting Gumpy instead... ouch! ... IMHO, it looks as if the COFN is being funny about this. Clearly, the troops assigned to X-com have had extensive weapons training... each and every one of them can use just about any standard weapon, including Rocket Launchers, incindieries, auto Cannons, etc. However, NONE of them have any combat experience, coming to you as fresh rookies. And their stats look as if they were selected based on a pot luck basis rather than screening among the elite troops... [[User:Jasonred]]

:Health isn't gained from getting shot. But as for the "ludicrously low stats" issue, maybe they're being selected on some other basis, or there's a real shortage of volunteers. [[User:Magic9mushroom|Magic9mushroom]] 04:56, 25 September 2009 (EDT)

:: I think that the X-COM's soldiers have big responsibilities, can't have children. They are sworn in and only then go to the field - if someone can't be trusted to keep a secret, he's getting sacked, given a shitty job (ever wondered who maintained the General Stores?) or worse. - n, 16:47, 16 August 2010 (GMT+2)

In Hotpoint's [http://www.tthfanfic.org/Story-16092/Hotpoint+XSGCOM+Goa+uld+Defence.htm| XSGCOM: Goa'uld Defense], his explanation is that after a few missions of watching their fellow newbies die, the survivors give in and volunteer for an experimental regimen of performance-enhancing drugs. IRL, steroids and such don't result in instant strength enhancement, they just encourage accelerated development of muscles. [[User:Kalaong|Kalaong]] 03:16, 28 March 2011 (EDT)

==Enemy Unknown/UFO Defence issues==
==='''Why isn't Earth overrun by Snakeman/Chryssalids?'''===

According to the UFOPaedia, Snakemen's "Reproduction is asexual, with each snakeman carrying up to fifty eggs inside its body at any one time" adding the ominious conclusion: "Left to its own devices this species would be a severe threat to life on earth."
Moreover, this species is usually accompanied by the Chryssalids, which have a capacity to reproduce themselves very quickly using humans. So, any survivors of crash sites or terror attacks could start reproducing themselves hidden, resulting in large areas being overrun by those aliens later on.

Possible answers:
* Both races have a self-destruct mechanism incorporated into their psysiology to prevent this.
* The entire area is purged by large scale bombing. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)

::One thing suggested in fan data was that Snakemen have air tablets in their stomach...which may be different from earth's atmosphere, which would limit their lifespan in earth's atmosphere, also making egg-laying pointless, since the offspring wouldn't be able to breathe or survive. It has also been suggested that Chryssalids have a very rapid metabolism. Though Chryssalids are likely just as, if not more useful, as a threat or a bargaining tool. When attempting to get a nation to capitulate to their demands, the aliens could threaten to employ Chryssalids en masse, or offer to remove a mass infestation in exchange for the government's cooperation. Or even further, it's possible that Chryssalids are under Ethereal control and maintaining the control link at that distance is taxing, thus eliminating mass use of the creatures. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Two words: [[Alien Containment]]. That answers everything except for the UFOPaedia articles for the aliens themselves which contradict it. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)
: For captured aliens, yes. But what survivors of uninvestigated crash sites? [[User:Hobbes|Hobbes]]

::Zombie is commenting that based on the need for an Alien Containment unit, the aliens cannot survive in earth's atmosphere for extended periods, needing special atmospheric blends and/or nutrient pools which earth is unable to provide naturally, thus limiting their operations outside of the craft. (If the aliens won the war, it's likely this would be one of the first things that they would 'correct'.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===What is the propose of the 'disco balls' found inside some UFOs?===

:Given that they explode, they could be storage reservoirs for coolant for the computers or other systems. They could also be circuit breakers or electrical junction boxes, or even a component of the UFO's particle beam they use to fry X-COM Interception craft. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Here again, two words: [[Alien Entertainment]]. Even though the spheres are not set to Alien Entertainment in the MCD files, they are almost certainly related to the process somehow. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)

:Maybe they are for having discos? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Presumably [[Alien Entertainment]] is psionic in some way, maybe they're Psi-Emitters or something? -[[User:magic9mushroom|magic9mushroom]]

===Who buys those alien bodies/equipment from X-COM?===

:Equipment likely goes to the funding nations or the international black market. No rebel group is going to ask too many questions about being offered guns that can [[Heavy Plasma|slice through the hull of an MBT]] or [[Alien Grenade|grenades that can level a building]] or [[Blaster Launcher|man-portable guided missiles]]; it'd just be cash-and-carry. Similarly, scientists would likely be interested in looking at much of this stuff for their own research. This would also explain the lack of market forces; the funding nations could have a set price for each item, or if X-COM is selling them under the table to rebels and rogue scientists, they can set the price and refuse to budge. The money on corpses could also be an "Alien Bounty" paid by the Funding Nations, as a reward for each alien that X-COM can prove they killed. Or it could be bought by other groups...rumor has it that some fast food restaurants have processes that can make ANY meat, no matter the source, look and taste the same, and a Muton would make a LOT of McBurgers. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
From the USO (Kasey Chang): XARQUID SUSHI.

===How did the aliens got to Mars?===

There are no indications that UFOs are capable of faster than light speed. So how did they get to Mars in the first place?

:The UFOs are mission craft, used for the legwork. The fighters; we never see the carriers. Given the aliens have been proven to be interstellar, they either Clone-A-Crew as needed when coming the long way to keep the UFOs crewed, or its far more likely that the aliens did have or still do have larger "Carrier" ships, which are capable of FTL travel, that were/are further out in the Solar System that store and dispatch UFOs to mission locations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: One word: TFTD. The entire city of T'leth was put into cryogenic suspended animation? Or look at X-com Interceptor. X-com and the aliens show the ability to enter hyperspace or whatever it is.
::: T'Leth is another mystery of its own. More to that later on :) [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::... there are no indications that the UFOs are INcapable of FTL... I don't think you would want to perform FTL travel within Earth's planetary atmosphere!
::: There are no indications that they are capable as well. And X-COM scientists don't seem to detect any FTL capabilities in UFOs during their research. And after the war the Elerium stocks dwindled, and it would make sense to perform some sort of interstellar missions to detect and harvest Elerium, however none are mentioned. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
:::: Unless you count the events of X-com Interceptor? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 21:15, 26 February 2009 (CST)
::::: I am refering to the events between Enemy Unknown and TFTD. There is clearly a big distinction between the alien craft on EU and those of Interceptor. [[User:Hobbes|Hobbes]] 09:38, 27 February 2009 (CST)
::::: Enemy Unknown is set in 1999, TFTD in 2040, Interceptor in 2067... looks entirely plausible that they DID begin research into space exploration immediately after the events of Enemy Unknown. These things take time you know. Remember that the universe is a huge place, and Earth had rather limited Elerium Reserves by the end of EU. It takes... what, 30 Elerium just to fly an Avenger halfway across Earth? They could hardly afford to fly around randomly in space HOPING to come across elerium, they had to figure out detections methods, then scan the galaxy sector by sector, possibly partially using non-Elerium based propulsion at times... I can't remember if it's canon or fanfic, but I remember reading that all Elerium on Earth was reserved for space exploration.
As for FTL, Earth does get it for sure sometime between 1999 and 2067. And I'm pretty certain the technology is Elerium based. It's not a huge logic jump to assume that the aliens have access to FTL Elerium based tech.
Though I'm a bit puzzled why all T'leth technology is based on Zrbrite, when the aliens uniformly use Elerium, all the way from Earth to Cydonia to the far reaches of space. -[[User:Jasonred|Jasonred]]

:It takes 12 Elerium to fuel an Avenger, though how much 1 Elerium is is an ongoing debate. As for Elerium, it was reserved for propulsion research when the funding nations divvied up X-COM's resources, and then they blew it all without learning anything more than the original X-COM scientists. And yes, Earth clearly gets FTL after TFTD but before Interceptor. The reason Elerium is not used in TFTD is because Elerium becomes inert and useless upon contact with seawater. Similarly, seawater aggressively corrodes Alien Alloys and eventually completely dissolves them. Zrbite functions similar to Elerium, being gold mixed with alien bio-material. Unfortunately, Zrbite only works when supported by a massive energy grid created by T'leth and becomes inert upon its destruction. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

OK... take the UNIT of elerium out of the equation... let's say that Earth had 5000 units of elerium, so 6 units get's an Avenger halfway around the world, and 12 units is sufficient to reach Mars. Hardly enough fuel reserves for intergalactic travel then.
2065 On October the 27th, the probe 'Tombstone 1' returns reports to Earth. It's data show that the globular star cluster where it rests, one hundred light-years from Earth, contains many life-supporting planets. Many of the planet's within the probe's scanning range also apparently possess great mineral wealth, including trace veins of elerium-115.
Hmm... So, mankind discovers FTL technology on their own in those 65 years? ah... come to think of it, if they've got non-Elerium based space travel and FTL, and more powerful weapons too, what's the big deal about Elerium in the Frontier? Does mankind even need it anymore?
As for T'leth, it is meant to be over 65 million years old, and CRASHLANDED on Earth due to a solar flare. Was the Ultimate Alien a prophet, thus chose to base T'leth on aqua plastics and Zrbite when T'lth was first constructed? Or did T'leth crash land, followed by frenzied activity where the entire city was replaced part by part, the alien alloys swapped for Aqua Plastics?
...
Actually, come to think of it, it's obviously a massive plothole due to limited timeframe, no point in discussing too deeply. Sigh... [[User:Jasonred|Jasonred]] 13:50, 27 February 2009 (CST)

:It's implied that despite the loss of ability to use the alien technology from the First and Second alien wars, simply being able to see and examine their designs catapulted earth's technology forward at least a few decades...which really is entirely reasonable. Much of the technology can be replicated on earth, and the principles and designs can be reapplied.

:As for the deal with Elerium, its needed to power stronger weapons and is also wonderful for power generation; its efficiency in power generation is what allows Mega Primus to even exist.

:And was there anywhere that specifically said that T'Leth was made of Aqua Plastics? I don't recall. Yes, the rest of their subs are made of aqua plastics, but I'm wondering if something the size of a medium city might perhaps be made of something a bit more durable. PS: Thanks for signing your post! :D [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:17, 27 February 2009 (CST)

It's not a plothole at all. There is no Elerium on Earth, whereas the aliens can manufacture Zrbite on Earth, since there's gold here. Therefore it's obvious why they used Zrbite. Also, there's the fact that it was an Aquatoid colony mission, intended to produce an "aquatic paradise", so using Aqua Plastics instead of Alien Alloys is perfectly justified. [[User:magic9mushroom]]

:I think that the use of Aqua Plastics instead of Alien Alloys is perfectly justified by the fact that T'leth crashed million of years ago while the aliens that came to take a shot or two at earth were two million years ahead technologically. So Aqua plastics was some plastic that was used by aliens before they've got the Alloys. You might argue - it's Aqua Plastics, so Aqua =/= Space. Well, Aliens weren't calling them aqua, and there wasn't anything saying that Aqua Plastics is not suitable for Space Travel. --[[User:Domenique|Domenique]] 11:10, 19 May 2010 (EDT)

... I think Alien Alloys alone would catapult earth's technology forward a decade, and there's no reason humanity can't use those anymore, just not in water. According to timeline, some space pirates manage to make the decommisioned Avengers run on non-Elerium fuel... a large technological step.
By the time of Interceptor, Elerium weapons aren't that powerful. Good point about power generation though.
I would assume that T'leth SHOULD have been constructed out of Alien Alloys, since it was originially an interplanetary vessel? Generally, everything in EU was made of Alien Alloys, everything in TFTD was made out of Aqua plastics. Both of which seemed plenty durable.

::Have you noticed that the UFOs fly however their mission parameters tell them to? The UFOs pretty much IGNORE interceptions by X-com craft... if their mission tells them to make 3 passes, speed up, slow down, speed up... they will follow that pattern exactly, whether X-com craft are firing on them or not.

::Question: How long does it take the Avenger to reach Mars from Earth? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)
:::No longer than a week, in my opinion. Probably less than 2 days. Since canonically, the design of the Avenger had the Cydonia mission in mind, it would be capable of very high interplanetary speeds. (You could choose to burn 40% of the Elerium in one blast to get to high speed. Or you could burn even more and refuel while it's landed...or it could be a mission with no guaranteed escape for the crew. The lives of the many over those of the few and all that, especially since the war hinges on the mission.) In addition, you can fit a full complement of soldiers on board with no real excess room for supplies, and the longer it takes to get to Mars, the greater the chance the aliens will spot it coming for them and mount a serious defense. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:20, 26 February 2009 (CST)
:::If you'd burn that much fuel to accelerate the craft then you'd have to use as much again to decelerate it and attain a planetary orbit, otherwise you'll simply overshoot the planet and head towards outer space. This is also another aspect to take into account when thinking about the speed of UFOs. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

::: UFO drives are non-Newtonian so those sort of rocket equations don't necessarily apply. I think filling up a car with gas is a closer analogy. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::: Well, they could put a mini mind shield on the Avenger, shoot down a UFO roughly their size, and then fly to Cydonia when the UFO they shot down was supposed to return based on the instructions found by the hyper-wave decoder. Basically taking the place of the UFO. Shouldn't be too hard since the UFO's are pretty common by the time you research Cydonia or Bust. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] 14 February 2010 (MST)

::That would leave 20% of the fuel to take off the Avenger and land it. Not really that unreasonable. While they're landed, they could potentially refuel the Avenger, or the mission might have been planned as a 1-way trip from the get-go. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===What happened to Mars and the alien civilization there?===

According to the Brain, Mars was blooming with life had a alien civilization millions of years ago. However, Mars nowadays is a barren world and the alien civilization seems reduced to the area on Cydonia.

:That may well have been before Mars lost the majority of its atmosphere due to its weak magnetic field. As the atmosphere dissipated, the aliens left or died off. It's also possible that the aliens, shown in the game over to have little respect for planets other than as sites for slaves and resources, they strip-mined the planet dry(and the rust from the machines created the red coloring), and then seeded Earth so that the slave workforce would grow for future extraction of Earth's resources. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

===Where are the human-alien hybrids referred to on the UFOPaedia?===

:For the ones on earth, probably in hiding or in laboratories for research. For the ones the aliens have, potentially improving the Sectoid gene pool or being used as food or menial tasks. Cloning is alot easier than making genetic hybrids and there's nothing that says their first-generation experiments would be suitable for combat. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: They are babies at the time of X-com, and few in number. Their aren't even that many of them by the time of X-com Apocalypse. [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)

:Not to mention the ones in X-COM: Apocalypse are less-than-fit for battle before extensive training. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===Why did the aliens only activate T'Leth after they were defeated?===

On TFTD T'Leth is shown as an entity/city of major power that is capable of conducting a war on its own. But the aliens leave it dormant although they could have used it to speed the process of taking control of Earth.

:Perhaps the Enemy Unknown aliens are legitimately scared of the TFTD aliens and are unsure how long they could trust them. Evil is not monolithic; the TFTD aliens may be more interested in themselves than the alien empire, so they were kept as an ace-in-the-hole. This is the same reason (canonically) that SKYNET did not originally send the T-1000 to assassinate Sarah Connor; SKYNET was scared of what the T-1000 could do and had only a bare minimum of control over it, so it only used it as an option when it had nothing left to lose. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

T'Leth is in fact so powerful that all it has to do is surface, in order for X-com to be considered to have lost the war.
In fact, looking at the timelines, it takes 40 years for T'leth to wake up from it's slumber... that's one good reason not to use it. By the time it activated, the war would already be over. [[User:Jasonred]]

Because the whole purpose of the Enemy Unknown aliens was to rescue the TFTD aliens from T'leth, and there was no way of seeing whether the T'leth-based invasion in TFTD would even work - from their perspective it's possible that getting T'leth to bootstrap itself could have caused a catastrophe (they don't know whether or how badly it's damaged). Presumably the aliens planned to mount a proper rescue operation after locking down Earth and readying it for the aquatic paradise that was the entire point of the T'leth expedition in the first place. [[User:magic9mushroom]]

T'Leth was a coleny ship sent by the Sectoid/Aquatoid's millions of years earlier. This is why the Aquatoids use electronics to augment there control over other creatures, while there progeny are genetically modified to gain the same control. In TFTD it's implied that the T'Leth had been partialy active for a long time. Thawing out aliens in small groups but never going in full production. UFO aliens may have not intended to start the full awakening cycle until they had a chance to prepare the planet.
OR, given the Ultimate Alien was aquatoid in origin by his looks and there was no other races from the first game involved. And the fact that Sectoid/Aqutoid's are not the top of the food chain with the Ethereal and Brain being more powerful it's possible the brain had decided that the Ultimate Alien was a threat to it's power. It was not until it's death that they tried send the signal. --[[User:BladeFireLight|BladeFireLight]] 17:19, 22 March 2010 (EDT)

===Why did the aliens use limited force during the First Alien War?===

Imagine Independence Day or War of the Worlds: UFO above the major Earth cities destroying the national leadership and any resistance. Or simply announce to Earth that they are now a part of their empire and resistence is futile. Instead, they go 1 mission each day, allowing humans to capture their craft, research their technology, discover their intentions and mount a successful defense. Don't the aliens watch sci-fi movies to see how it should be done?

:Perhaps they don't have the standing forces to do so, and are in the process of building up the forces needed to do so. Perhaps they don't want to wipe out the entire power structure too fast; they want to leave some pieces in place for when they rebuild. Perhaps they're too condescending to think that humanity ever really has a chance; they've probably conquered thousands of other planets without anyone ever successfully resisting them. Perhaps they consider the X-COM project to be a rearguard action that, while a valiant effort and a credible threat, is ultimately doomed to failure because they simply cannot win in the end, which is why they undermine it. Indeed, the reason you need to launch the Cydonia mission in order to win is because X-COM simply cannot stop the aliens in a ground war; the aliens have an effectively infinite supply line and standing forces(though nothing says they're all waiting to swamp the earth), and the only way to win is to kill the command staff(which the aliens believe X-COM will not be able to do, lacking both knowledge of where the Brain is and any practical means to get there.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)
::The most plausible explanation seems to be the one employed in the Worldwar series, by Harry Turtledove, but that does not seem to mesh with what the Brain says about having been on Mars for a while, since then they could watch the Earthlings perpetually. Of course, what it says is probably a bunch of lies. Thinking about what it says for too long also raises the question of why the aliens attacked when they did, of course... [[User:Vizzydix1|Vizzydix1]] 21:52, 18 March 2010 (EDT)

The aliens are completely lacking in weapons of mass destruction. When you get right down to it, their aircraft are very fast, manuevarable and durable, but they have rotten firepower. Even the battleship is unable to bring down an Interceptor in 1 shot.
The terror missions and X-com Base Defences prove that the Aliens are unable to simply launch orbital bombardments... in fact, they appear to have no Air to Land weapons whatsoever...
When you get right down to it, the aliens are pretty stupid. Also, their scientists seem inferior to Earth's. Seems to me that they only had the advantage of Elerium deposits and thus elerium based research.
X-COM was unable to win in an all-out war with the aliens, but remember that X-com is a small little covert group with several dozen soldiers and a handful of aircraft. Can you imagine the result if the aliens had caused a joint war effort by the UN? You would have Lockheed factories converted to Avenger production, several platoons of soldiers outfitted with Flying Suits, Lasers, Heavy Plasma, thousands upon thousands of Laser Tanks...
I would say that keeping the fight to covert action on both sides was actually beneficial to the aliens, really. [[User:Jasonred]]
* Nope, the aliens could just invoke John's Law and blow up the planet with a kamikaze battleship at .9c. Even failing that, the alien battlefleet could come in numbers sufficent to blot out the sun.--[[User:(name here)|(name here)]] 14:39, 8 November 2009 (EST)
** Lest we forget, X-Com is essentially the Spartans to the aliens' Persian Empire. So they'd just fight in the shade (which would be a blessing in desert missions). --[[User:Guido Talbot|Guido Talbot]] 13:58, 16 July 2010 (EDT)

Aliens first began with smal scouting missions, so maybe all we expirience in X-Com is initial attacks by aliens, maybe the whole base was begining scouting and waiting for the invasion fleet? Aliens problably could be in sense dumber than humans, humans are adaptable and thinking, our technology advances fast, and we are fast and smart enough to stop the invasion before it begins. Aliens problably were not used to it so they thought "oh well, another invasion...". --[[User:Domenique|Domenique]] 11:10, 19 May 2010 (EDT)

Mankind, as a whole, is incredibly cunning and full of guile. We are also incredibly aggressive. A trait that the most of the Aliens can barely concieve. Though we are weaker physically, mentally, etc, we are overly developed when it comes to strategem and war. The aliens are, in essence, have come to an inverse of Flatland. Though they are advanced, it is they who are 2D to our 3D approach to fighting. They return to earth, and through extensive research and testing, determine that inferior are strategically to humans. So...they use their advances to what they percieve as the most full advantage, and call for reinforcements over the initial months of the First Alien War. For eons, only the Sectoid make arrivals to earth. When the Brain finally realizes the situation, that mankind has woke up and is dealing with them most directly, it begins to get desperate, it sends reinforcements, but only incrementally. (Its always focused on peak efficiency). The concept of overwhelming force is illogical and some how, disdainful, to it. It prefers nuance, interogation, politics, and assessment. The Brain determine that its more effective to eliminate allies of XCOM than to face it directly. The concept of obliterating anything from orbit is reprehensible. Everything must be examined, especially the dead creatures you leave behind. Over time, it would learn man's tactics and assimilate. In fact, each race called in is an example of the Brain adapting. The Floaters bring forth an extra dimension to combat. The snakemen aggressiveness and accuracy. Mutons a culmination of superior warrior breeding, raw physical power, and determination not unlike the so called human soul. Finally, the Ethereals enter, with capacity to bring overwhelming force. In time, as they do on Mars base, they might begin joint force attacks with Mutons backed by Ethereals, supported by a mix of terror weapons. Fortunately, the First Alien War is ended before they fully develop such cunning. Hence the desperate act of T'Leth. The Brain has learned the power of anger fueled by vengeance and desperation.
--[[User:BlackLibrary|BlackLibrary]] 11:10, 29 May 2011 (EDT)

==TFTD issues==
===What was the relationship between the aliens from the 1st and 2nd wars?===

Quoting from the UFOPaedia regarding Alien Origins: 'Deep in the oceans there lie ancient
sites used by the Aliens to contact their stellar cousins.' This also has some implications regarding the issue of why T'Leth was only activated when the Sectoids were defeated.

*Gill Men are coopted Terran creatures, Aquatoids are a differently-modified Sectoid breed, Lobstermen are machine soldiers that are manufactured, Tasoths are clone soldiers that are grown.

Aquatoids are the ancestors of the Sectoids. The colony ship was sent out slowing than light hundreds of millions of years ago. Sectoids are a more genetically advanced race. The rest of UFO aliens were picked up after that point. The Brain and Ethereals probably conquered the Sectoids and don't regard them highly. While the Aquatoids that were thawed over the years created, conquered (Gill Man) or manufactured the rest of the allies over time. I picture the Tasoth as probably something they brought with them and have been working on. Since most of the Aquatoids come from suspended animation they have not tinkered with genes much. Instead modifying and using electronics (MC Chip) to control. --[[User:BladeFireLight|BladeFireLight]] 17:28, 22 March 2010 (EDT)

===What kind of materials were 'synomium' and 'adamantium'?===

The first one is mentioned on the name of the alien communication devices and the second one appears at the end when T'Leth is destroyed: 'he twisting hugeness of T'leth begins to rupture.
Flames and smoke spew from its gleaming spires and adamantium halls.'

:Synomium is probably a special material used in the comm. devices, like Stargate's naquadah (universal stuff), naquadria (unstable power source), trinium (hull material) and neutronium (superdense metal). Adamantium is a legendary material in ancient literature that is said to be indestructible, similarly to mithril.--[[User:Amitakartok|amitakartok]] 10:55, 3 November 2009 (EST)

===How deep were X-COM bases located on the seas?===

*Floating bases would be easier to build, repair and supply. However they would have to be tethered to the ocean bed or possess some sort of propulsion to prevent them from drifing with the ocean currents. But it would also allow for easy redeployment of the base.
*Submersible bases could allow for better sonar detection. Same problems regarding ocean currents would apply. In case of hull breaches entire modules would be quickly flooded and any crew present would be crushed by water pressure or drown. Base could be built and then submerged (requires depth control)
*Seabed bases would be the hardest to build and supply. Several other factors could limit their deployment, such as unstable areas (underwater volcanoes, prone to seaquakes, rock avalanches, etc.) and depths.
*Given that the Alien Retaliation missions in TFTD are called "Floating Base Attack", I'd say floating. Also remember that your starting sonar can't see Very Deep, which rules out seabed bases. [[User:magic9mushroom]]
** Floating doesn't always happen on the surface. The surface has to deal with large waves ad bobbing up and down, submerged only has the currents it could be stabilized easier. --[[User:BladeFireLight|BladeFireLight]] 11:57, 14 January 2010 (EST)
* I was recently researching how far you have to be down to not be effected by surface conditions. You have to be submerged 1/2 of a waves lenght (measured crest to crest) Best I can find is that the average wave is 150 yards accross. To not be effected by the waves you have to be 75 Yards below. This is way below the depth needed to not be effected by the bends when surfaceing. I figure they are probably right at the limit of what can be safe for quick surfacing and well anchored to avoid getting [http://www.youtube.com/watch?v=LwKXfc_a4Ag tossed in a storm]. --[[User:BladeFireLight|BladeFireLight]] 17:37, 22 March 2010 (EDT)
**Something else to consider - these 'floating bases' could be large modular submarines/submersibles. If memory serves, submarines basically maintain sea-level pressure regardless of the depth, so that could explain why they'd be able to be 75+ feet below sea level and not suffer the bends when surfacing.
::(Or, y'know, we could just say "a wizard did it".) --[[User:Guido Talbot|Guido Talbot]] 14:13, 16 July 2010 (EDT)
[[Category: Fiction]]

User talk:Seb76

2011-03-30T14:56:17Z

Mannon: /* UFOloader and Xcomutil */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

My problem is the following: if I try to run the loader normally, a console window pops up for a few seconds then I get an "illegal instruction" error from NTVDM (and the window disappears, yet it's button remains on the taskbar until I kill the process). If I try to run it with DosBox however, I get "illegal command: UFOLOADER.EXE". Point is, I can't run this at all.--[[User:Amitakartok|amitakartok]] 11:27, 13 October 2009 (EDT)
:Looks like you're trying to use the DOS version here. Only the CE (windows) version is supported. [[User:Seb76|Seb76]] 13:48, 13 October 2009 (EDT)

Hi, is it in any way possilbe to run the Extender in Win98? I just set up an old machine with it and wanted to give it a try but as you said above, it won't work with Win9x. But is there a way to manually mod the game? I am asking becaus on my WinXP Machine the game often crahes in battlescape and that really sucks =(--[[User:Skaw847|Skaw847]] 19:28, 21 May 2010 (EDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)
:::I for one am a huge fan of XcomUtil, though I'm now also a huge fan of UFO Extender! I'm really hoping I can get the two to play nice. I was up until now playing a dos version, myself. Mainly because the version I bought years and years ago was the DOS version on CD and it still worked via dosbox, which also has several filters similar to your HQ4x. (Some run a little faster and I think they can run in a window while I can't get HQ4x to run windowed at all. I don't mind that so much, though the game runs noticeably slower when I run HQ4x and I prefer to run windowed these days so I can more easily multitask. Still I LOVE UFO Extender so I switched to the Windows version just for this.) Some of XcomUtil's features only work in the DOS version with split exe's because it goes back into the batch file and allows XcomUtil to play with things when switching from Geoscape to Battlescape and vice versa. But, it's not that big a deal for me. UFO Loader's feature list is more than robust enough to give that up. As for the sounds the Windows CE versions changed a lot of the sound effects. If you're used to this version then it's Np, but if you played the DOS version and got used to it then it's VERY off putting. Luckily it's easy to patch it back to the DOS sound effects. The "Enemy Unknown Extended" page here lays out an install that includes UFO Extender, the original DOS sounds, ect... It's a good place to start. Anyway, great tool. Now let's see if I can get these to play nice.[[User:Mannon|Mannon]] 04:40, 27 March 2011 (EDT) (I keep forgetting to sign things... too used to forums instead of discussion pages.)
::::Facinatingly XcomUtil actually DOES split the CE's executable into geoscape.exe and tactical.exe! It uses it's own sdump utility to do this during the setup batch file. I misread the above. XcomUtil splits them to preserve it's fuctionality so that it can use the batch file to knit them together like in the original DOS version and insert it's own exe into the mix. This does not make the windows exe run in DOS of course, but it does allow XcomUtil to keep it's functionality. I have to assume it really screws up UFO Extender, though... ;-( [[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)

Decided to look into this as there are a few XcomUtil features I like that aren't reproduced in UFO Extender. XCU does indeed split the exe. It also modifies both of the split exe's. It still loads both via fodder's loader when running them from the batch file. The command lines for that are "start /w xcloader geoscape.exe "0"" and start /w xcloader tactical.exe "1". Replacing xcloader with UFO Loader appears to work for tactical. The command line even appears to point UFO loader to the tactical exe since going into combat causes a problem. If I change the first xcloader call to "start /w xcloader" then the renamed UFO Loader finds the unsplit exe. Going into combat no longer fails like this, but it also prevents XcomUtil from running between phases. This does not prevent the running of XCU completely, but it will cause problems with some features, especially in the placement of soldiers in the new craft maps that XCU adds. Then again, by using the UFO Loader to use the original unsplit exe I believe that you are also bypassing all of XCU's modifications to the exe's as it probably does all those modifications to the geoscape and tactical exe's it created when splitting the exe. It may be possible to recombine those exe's or to find command line parameters that allow UFO Loader to load tactical.exe on it's own. The latter would probably be the best solution since it should allow XCU to function between phases.[[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)
:Splitting of the exe is accomplished by first simply copying it with both of the destination filenames. Then sdump is run on each one using settings from XcomUtil.cfg to essentially transform each one into the geoscape only and battlescape only versions. The settings are available in the cfg, but not documented so I don't really understand them. Though... it is actually starting to make some sense as I compare the cfg to the sdump documentation in XcomUtil.txt. Seems like it would be possible to reverse the patch, though it might require first extracting the correct data from the unsplit version. Note: The split up geoscape.exe and tactical.exe are exactly the same size as the original ufo defense.exe, thus data was not removed by sdump, merely changed. I think the only change needed were to cause geoscape.exe to exit at the right time instead of going immediately to the battlescape, and for tactical.exe to go directly to battlescape loading the mission data like the old DOS version.[[User:Mannon|Mannon]] 22:01, 29 March 2011 (EDT)
::I believe that I have managed to get XcomUtil and UFO Extenter at least working together with a kludge. My method involves using modified versions of XcuSetup.bat and RunXcomW.bat and the creation of a new exe, (to avoid overwriting the original and keep it as a backup). RunXcomW.bat is changed to point to UFOLoader.exe instead of xcloader.exe and points UFOLoader at the new exe UFOmerge.exe. The second call of xcloader which normally initiates the battlescape has been simply disabled as it will never occur under my setup. The changes to XcuSetup.bat are also pretty simple. I allow it to copy the UFO exe into geoscape and tactical because XcomUtil.exe will only modify these exe's. But I disable the patching done to each via sdump which turns them into independent phases of the game. Then in every instance where XcuSetup calls XcomUtil to make a change to the exe's I insert a line after it that uses sdump to merge those exe's back into UFOmerge.exe. Viola! Theoretically this should allow XcomUtil to modify the UFO exe while still allowing UFO Extender to make it's own changes. However... Not all XcomUtil functions will work and some of them will flat out break because it cannot be called when switching phases of the game. So, for example, if you use the larger craft XCU includes then you could be in trouble since XCU cannot be run to place your soldiers properly. I suggest you stick to the normal number of soldiers each craft can carry. If I knew a way to make UFOLoader.exe compatible with tactical.exe then it should be possible to have full functionality. It actually works perfectly fine with geoscape.exe. Seb76, if you're around anymore I can provide you with exactly which bytes are altered in tactical.exe for both UFO and TFTD as they are in XcomUtil.cfg. After looking at the sdump documentation it's actually pretty straitforward. It basically uses hex numbers as commands specifying goto this address, write the next X bytes, skip the next X bytes, ect... I'll make my modified XcomUtil files available on my page if anybody asks for them. Now... to figure out how to disable the XcomUtil base disjoint bug fix. lol I think I'd prefer the UFO Extender fix, and I like having the option to leave the bug in place and use it for tactical options.[[User:Mannon|Mannon]] 05:07, 30 March 2011 (EDT)
:::Kept getting sidetracked, but I finished that part and added it to XcuSetup.bat. All it took was adding the one line, "if exist maps\xbase_01.xcu xcopy maps\xbase_*.xcu maps\xbase_*.map /y" right after XcomUtil does it's map:cfg write. This only leaves the disjoint bug in xcom bases. I could revert the alien bases too, but I figure why bother doing that.[[User:Mannon|Mannon]] 10:56, 30 March 2011 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Could we get TUs (in current/max format) at the inventory screen while on a mission? It would greatly help with swapping weapons among soldiers.

* Could we get little numbers [like on the screenshot of accuracy mod] showing how much TUs an action on the inventory screen would take? Some players (me, of course, included) can't really remember all that reloading from backpack or from a leg slot TUs. Also...

* a "drop all" button, maybe?

* Soldiers' positioning in Skyranger is very good... but with the Avenger it is not so pretty. The ones at the top are not the ones closest to the trap door. Chooseable patterns, maybe?

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.
: '''Save Equipment''' is under development, still some bugs

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
** Eliminate "infinite fuel" exploit for conventional aircraft.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

* Enable native alien melee attacks within Alien Pets. The Floaters are pleading. (At the moment, Alien Pets+Big Brother means a crashed Superhuman Floater Large Scout costs 6-8 X-COM agents; corresponding crashed Sectoid Superhuman Large Scout is only worth 3-5 X-COM agents. Floater Large Terror Ship on just Big Brother : only one agent, and that was due to the top-of-stair pinning bug providing enough TU to do something.) -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Do something to help out the psi aliens as well within Alien Pets, as above. -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Would it be possible to change the master volume level in the game, or at least have a no sound option? [[User:Epiceuropean|Epiceuropean]] 00:26, 12 January 2010 (EST)

=== A few more ===

Do any of these take your fancy:

* Draw the Radar detection radii onto the map as a circle(s) around the base (also for moving aircraft?)

* Show All UFOs (Ultrawave Detector - like Show All Locations, but doesn't show Alien Bases, you still have to hunt for those).

* Sensible Ammo Recovery = add up all remaining rounds of ammunition at the end of a mission (in the ship, if Aborting), and recover a number of (full) clips equal to that number divided by the clip capacity (rounded down maybe).
: There's a reason I didn't turn Clip Recovery on, and it's that I guessed that it didn't work exactly as it's suggested here. If it did work like this, I would use it. [[User:Stubbs|Stubbs]]

* Implement tactical time limits for UFO Assaults/Recoveries. After a random period (within a pre-defined upper and lower time limit), the aliens leave. Pop up warnings appear at the end of each turn, saying the UFO engines are powering up. When the aliens leave, all aliens/items/equipment inside the UFO is gone - no loot, no score. Any soldiers still inside the UFO are considered MIA. The soldiers are ''captured'' in fact - score penalty worse than MIA? There must be one conscious alien inside the UFO for it to leave or attempt to leave. Maybe any live aliens outside are 'beamed' or 'tractored' inside the UFO, complete with their equipment? (E.g. the mission ends and you don't get score for them or their equipment either - just for the corpses and dropped loot).

* No Milk Please: After XCom withdraws from an Alien Base, randomise the base's location and make it hidden again. Just like what happens to the aliens after they fail to assault an X-Com base. Though you would probably still need to locate it within the same country or region so finding it again wouldn't take long I guess. Would it mess things up to move the base to a random part of the world?

* [[User:Spike#Tank mods|Tank Armour and Equipment Mods]]

But I should probably code this up myself, looking at your source code it doesn't look '''too''' hard. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

[[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

* Burning Zombies

It's more or less impossible to prevent Zombies from hatching into Chryssalids by killing the Zombies with fire, since fire does such a small amount of damage, and the requirement is that the actual killing point of damage is done by an incendiary. Apart from hitting them with an incendiary and running away, then waiting about ten turns for them to die (probably repeating the attack once or twice), this is only ever going to happen by blind luck.

It would be much more viable if the rule was (also?) that a Zombie which is '''on fire''' at the time of death would not hatch into a Chryssalid. This is not exactly easy either, but it is at least possible. It requires hitting the Zombie repeatedly with incendiary weapons until it catches on fire, then killing it right away with regular weapons (before the fire goes out).

A much easier version of this approach would be to say that if the Zombie is killed while it is '''in fire''', it does not hatch. But that is probably too easy.

A way to do this by hacking game files, without code changes, would be to increase the Zombie susceptibility to fire, to 200%. This would make incendiary weapons a viable way of killing them, as well as increasing the likelihood that the killing shot was an incendiary shot.

An alternative approach would be for the Zombie to have a chance of not turning into a Chryssalid, proportional to the percentage of health damage that had been caused by incendiaries. But that's probably too hard to track, it would require an extra/unused field in UNITREF.DAT.

[[User:Spike|Spike]] 13:12, 7 September 2009 (EDT)

* Fear of Fire

Apparently there is no morale effect from [[Incendiary#Damage|Incendiary damage]]. If anything, for humans, and maybe be for other humanoid aliens, fire should probably have a greater morale effect than ordinary damage, not none. A basic fix would treat fire damage the same as normal damage when reducing morale. A more complicated fix could add a weighting to this morale effect: multiply by the creatures susceptibility to fire (or reduce by its resistance to fire). Any creature or soldier that is immune to fire should not have its morale affected. Actually the affects of fire vary quite a lot (different aliens, different human armour types). Maybe this is why the designers didn't get around to implementing morale effects for fire, as it's a bit complicated.

[[User:Spike|Spike]] 13:40, 7 September 2009 (EDT)

=== Multi Stage Missions ===

Between each stage of a multi-stage mission:

* Send all artefacts (non-usable items), corpses and recoverables back to base
* If possible, remember the score for these items, and apply it to the score at the end of the mission
* Alternatively, pop up a score window between the mission stages, and apply the score then?
* Gather all loose usable equipment into the "equipment pile" for the next stage
* Or possibly re-run the Equip Screen between mission stages, again gathering all loose usable items into the equipment pile first.
* Keep an 80 item limit on what you can take into the next stage
* Prune down to the 80 item limit using some sensible rules, not sure what exactly.

This is of limited use in X-Com EU but would be much more use for TFTD, one day. EU has only one multi stage mission, and it ends the game, so only some of these points above will be relevant.

[[User:Spike|Spike]] 20:54, 2 September 2009 (EDT)

=== Even More ===

Tremendous work, you've pretty much made the game worth playing again. Best work since Xcomutil. As with everone else, I have a few requests. [[User:KingMob4313|KingMob4313]] 23:59, 12 August 2009 (EDT)

: Ability to change damage modifier. Right now the damage runs from 0-200% of damage values on the weapon. I'd love to see a way to change it to 50-150%, 75-125% or the like.

: A modifier to increase or decrease the explosion radius modifier. Right now the radius is either keyed to the explosive or to the explosive damage. I'll investigate it further. But it would be nice to have a very small radius, but high powered explosive for use as a breaching charge.
:: There is a "crimping" function on some of the explosions already so it might be possible to exploit that. Check the [[Explosions]] page. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

: A modification of the range based accuracy. One handed weapons have a shorter range, to the point that even their aimed shots have an effective range, two handed weapons have a further range (and no aimed shot effective range) and really heavy two handed weapons have an even further range.

: Ability to enable the Burst fire (5 shots over 3 picked spots) and/or the full auto mod that is on the heavy laser on other weapons (set by a flag).

: A modification so that on the alien's side first turn, they do not have their full time units in reserve for reaction fire. Nothing like getting shot 3 times from the same sectiod after missing ONE shot on them.

:: You could always wait a turn before you open the door. :) [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

::: Good point, I should be doing that anyways.

=== More Exploits to Close ===

* [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]

Probably the worst single exploit in the game. What is needed is to disable any mind control actions for a Psi Amp, if the unit holding the Psi Amp is currently mind controlled.

Also a general mind control bug/exploit fix for:

* [[Exploiting Mind Control#Exponential Mind Control|Civilian Traitors]]
* [[Exploiting Mind Control#Exponential Mind Control|Resurrect Zombified Agents]]
* [[Exploiting Mind Control#Exponential Mind Control|Zombie's Permanent Control of Aliens via Stunning]]
: Above 3 bugs are fixed by '''Hostile Civilians''' fix.

* Probably many other missing/MIA-type bugs

These probably all arise from the daft decision to save a single byte (or even bit), by not recording separately the current vs default "side" a unit is on. The game only tracks the "current side". Consequently when mind control ends, the game often makes dumb decisions as to what side to "restore" the unit to. We could use an unused byte to track the default "side", but that would require overloading a presumed "unused" field and that could be risky. But actually we can always deduce the "default side" from the unit type: XCom for soldiers and tanks, Neutral for Civilians, Alien for everything else. So what is needed is just an end-of-turn check to restore everything to its correct side, based on its unit type. Actually it's slightly complicated by alternating turns. You need to update all (originally) Alien units at the end of the Alien turn, all originally XCom units at the end of the XCom turn. You might also need a special end-of-game update, to avoid the MIA-type bugs. [[User:Spike|Spike]] 12:22, 26 August 2009 (EDT)

: AlienSWP.py implements turnswapping via mind control, like XCOMUtil. Handling the alternating turns, as you described, is necessary to make mind control work properly (a mind-controlled alien remains with X-COM during the alien turn, and so on).

: I would assume that the original programming team had a coding policy forbidding both bitfields, and emulating them with bitwise shifts. That's really the only way I can explain most of the idiosyncrasies of the file format. [[User:Zaimoni|Zaimoni]] 12:07, 26 August 2009 (CDT)

=== Soldier Colouration ===

Not the most "practical" request in terms of changes to gameplay, but still something I feel would be pretty cool if incorporated. Basically, the option to have the battlescape engine display soldiers according to their race/hair colour, as according to their inventory screens, [http://www.strategycore.co.uk/forums/post-a1669-.html like this].

The stored tactical [[PALETTES.DAT|palette]] is made up of 16 groups of 16 colours (256 total), in this order (though the last 16 colours are replaced with a grey-scale shade list at run-time, similar to the other fifteen groups - refer to the page on palette data for more info on that):

[[image:5_BattleScapePal.Png|center|frame]]

Solders are drawn using colours from three of these groups: One for their clothing (x50-x5F for overalls/power armor, xE0-xEF for personal armor), one for their skin (x60-x6F), and one for their hair (x90-x9F). Flying suits use a few extra colours, but they don't matter for the sake of this explanation (they don't show hair/skin anyways).

With my [http://www.strategycore.co.uk/files/index.php?dlid=686 battlescape editor] I incorporated a feature where you could have the program redraw units on the fly (as per the screen shot), changing just the hair/skin colour. For example, to check to see if a colour index was supposed to represent hair, it simply checks if "(''value'' & xF0) == x90", and if so, it'd add or subtract a certain figure to achieve the desired colour.

Well, there's a bit more to it then that (males in personal armor have a different hair colour already), but I'm sure the basic concept is obvious to you by this point. If you're interested, you can see a sample function in a file included in my toolkit - "bb_tact\UnitDrawer.java", line 384. It's not exactly well documented, but if you check the hair/skin arrays it refers to, it should be fairly obvious what it does. While the program is running, the "characteristics" variable is set to "true" by tapping C on your keyboard. Of course, I've no idea how the actual game deals with drawing soldiers, but I assume it decompresses every [[Image_Formats#PCK|PCK]] image every time it wants to draw it, same as my code does.

- [[User:Bomb Bloke|Bomb Bloke]] 09:46, 4 May 2010 (EDT)

=== See Also ===

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

== Completed Items - Thanks Seb! ==

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

* More video options. In particular, an option to put padding at the top and the bottom of the screen to preserve the aspect ratio on a 4:3 monitor. Maybe it's just me, but stretching the original height of the game to fit a 4:3 screen makes the Battlescape look weird. (Actually, if you update the source code link, I could try to do it myself. The current source doesn't seem to include your more recent changes. --[[User:Mikawo|Mikawo]] 20:30, 12 August 2009 (EDT))
** Thanks for uploading the new source code. I managed to add the letterboxing that I wanted. If you wanted to make it an official feature I could upload the updated files. And I don't think I said this before, but thanks for the great loader! --[[User:Mikawo|Mikawo]] 18:40, 14 August 2009 (EDT)
:Go ahead and upload/PM me the file (d3d.cpp I presume?), I'll gladly incorporate your modification. [[User:Seb76|Seb76]] 19:14, 14 August 2009 (EDT)

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

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

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

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

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

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

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."
:The above works perfectly. [[User:KingMob4313|KingMob4313]] 00:05, 13 August 2009 (EDT)

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.
:Fixed via Keyboard Shortcuts - and configurable too.
-- Sorry, I am having trouble finding this addition. Is it in the newest version? I can't see where to configure it if so.

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....
Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)
:I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that 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?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human 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?

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).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
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!
:I think this is a known issue with LOS, not sure though
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).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

There are major issues with your current weight calculations. I'm not exactly sure how it was occurring, but repeatedly messing around unloading and loading weapons, switching clips from the ground them putting them back in... at least one of these functions causes 'phantom weight' to be added to the soldier (e.g. strip them bare and they are still carrying a load). This was happening by 3 units of weight at a time; the weight of a clip. It's so bad that I managed to get 18 phantom weight units on a soldier before getting bored. Occasionally, 3 units of phantom weight would be removed again! It's hard to tell if this was in the original game, due to the lack of weight display in the inventory screen.

Edit: I've worked out what's happening. Add a loaded weapon to a soldier, unload it, and remove the ammo and gun: this ''removes'' 3 phantom weight units. But, add an unloaded weapon to a solider and load it... this ''adds'' 3 phantom weight units. [[User:Stubbs|Stubbs]]
:This is a genuine bug because they forgot to unassign the clip of a weapon when you drop it. Also the default weapon's clip is not initially assigned to the wearer so if you unload and reload the clip, your soldier weights more. [[User:Seb76|Seb76]] 13:27, 3 February 2010 (EST)
:: So is this impossible for you to override and fix? It's really irritating... I've edited lots of item weights, but I guess I'd have to make ammo light and guns heavy to minimize the effects of this bug. [[User:Stubbs|Stubbs]]
:::I second that, it would be great if this could be fixed. [[User:Rovlad|Rovlad]] 17:45, 13 May 2010 (EDT)

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

:: Alien reaction fire works fine for me within Alien Pets. -- [[User:Zaimoni|Zaimoni]] 12:41, August 12 2009 (CDT)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)
:Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)

The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. <3
:Uploaded a new version, you need to add a "HQ4x=1" line under the "Mod" section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)

Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)

Now the question is, how do you use DXWnd with the loader?
[[User:KingMob4313|KingMob4313]] 11:02, 12 August 2009 (EDT)

==Works but won't multitask==

Target system: prefab HP Vista with global data execution prevention. Problem is the same native, with D3D, and/or with HQ4X. (The two do combine nicely, visually, but a bit laggy for my tastes).

ALT-TAB terminates all further screen display on restore; the sea of blackness continues until Task Manager is used to kill the application, at which point D3D admits that it has "lost the device". (This is after the improved error reporting patch. Before, 0xc0000005 as Data Execution Prevention takes over.)

-- [[User:Zaimoni|Zaimoni]] 12:27, 12 August 2009 (CDT)

: Solved on Win7 for the most recent version: Program Properties dialog has an "unblock" button. Unblocking allows the program to survive being alt-tabbed away from. -- [[User:Zaimoni|Zaimoni]] 22:03, 24 June 2010 (CDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)
:That's great ;-) By dev I was refering to the "dev" version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)

Hi Seb, I've been playing the UFO series since the beginning but just joined this wiki. I've tried just about every mod there is for these games, and I must say, yours is one of the best as far as creating a "more complete" and stimulating game experience. My question is in regards to your "Heavy Laser" mod. I liked what you did by creating new "abilities" for the weapon with the Full auto and Burst fire mode, but every time I play I can't help but think that it just doesn't belong to the Heavy Laser as a weapon. I always envisioned the Heavy Laser as more of a long range "Sniper" support weapon, and I like the mod that the X-ComUtil added that gave the Heavy Laser a new life by increasing the accuracy and damage of the weapon making it one of the best Sniper weapons available (even if it is heavy to lug around) as well as finaly giving my troops a greatly needed new weapon for disposing of those pesky sectopods (on any difficulty). I do, however, think that the new fire modes (full auto and burst fire) would be a perfect addition to the Auto-Cannon. The in game image alone has always brought to mind a "mini-gun" type weapon that should be capable of very rapid fire, but at the expense of accuracy due to the encumbering nature of the beastly AC. I never liked how the AC seemed like a generic Heavy Cannon with less damage and only the added auto shot function. Also, I always wondered why that weapon even had an "Aim" function. Who's going to sit there trying to carefully aim a Gatling Gun? Nobody... that's who, you use a weapon like that for mass devistation and shock value, PERIOD! This is why I think that your mod to the Heavy Laser should be reconsidered for the Auto-Cannon. I think, at the very least, it will give people a reason to use the AC in the mid to late portion of the game, and being that it still has weak stats compaired to other weapons, it's not going to be overpowered or infringe on the use of specialty weapons (I think the Heavy Laser with full auto and burst fire is a little un-balanced due to its considerably higher power). If you don't agree that's fine, but since I'm not very knowledgeable about game programing, I was wondering if you could at least give me a hint on how to create similar weapon functions for other weapons, cause I'd like to at least try it out for myself. Thanks for any help you can give me and keep up the good work, you're mod is awesome.

== REng UFO with IDA ==

Hi Seb =)

I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.

So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).

Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.

I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.

My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).

Any advice is deeply appreciated mate =)

XCom forever!
--[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)
:Hi k9,
:Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.
:For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...
:Good luck with your project,
:[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)

:::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...

void InsertCall(int dst, void *func)
{
DWORD oldProtect;
DWORD *pOffset=(DWORD *)(((char *)dst)+1);

VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&oldProtect);
*(char *)dst=(char)0xE8;
*pOffset=(int)func-(int)dst-5;
VirtualProtect((void *)dst,5,oldProtect,&oldProtect);
}

::: This calculation here is interesting:

*pOffset=(int)func-(int)dst-5;

:::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).
:The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).
:The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)

:::Can you suggest some good reading material to better understand this? Cheers!
:::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)
:You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the "UFO Defense" process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)

== D3D ==

If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has.

I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)
:You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)

Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)

OK I ran the dxdiag utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)
:Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.
:Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)
Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)

D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J'ordos]] 19:09, 8 August 2009 (EDT)
:edit: forgot to mention, I have directx 9.0c installed and dxdiag reports no problems. I have a Geforce2 MX *blushes*
:Do you know if this card supports non power of two textures? [[User:Seb76|Seb76]] 05:10, 9 August 2009 (EDT)
::no idea, but since your new version works fine with the D3D option on I assume it doesn't :) [[User:J'ordos|J'ordos]] 11:38, 9 August 2009 (EDT)
:That's great. Spike, does it fix your problems too? [[User:Seb76|Seb76]] 16:04, 9 August 2009 (EDT)
::Sorry for the late reply - yes that fixes my problems too, D3D is working fine now. Thanks, [[User:Spike|Spike]] 15:55, 26 August 2009 (EDT)

== Save equipment ==

Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:

*1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of "invisible" equipment!
*Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips.
*The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.
*Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment.

Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked?

Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)
:Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.
:The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?
:As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.
:I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)
::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a "before" and "after". [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)
:In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)
::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns & ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)
:OK, I'll have a look at this, thanks for the effort.
:Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the "i/b" one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)
::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)
::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)
::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)
:I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)
:: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)
:Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)
::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)

Hmm more problems with Save Equipment. Ammo of all types seems to disappear. Eg I have 6 pistols and 6 pistol clips on the craft, but the Equip screen just gives me 6 empty pistols. Other weapons are short of ammo too. Is the Save feature perhaps "remembering" empty weapons (or loaded weapons) and somehow eliminating the clips. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)
:This looks like an issue with ''UnloadClips''(). I noticed that the clip object's ''loaded_into'' is set to 0xff, but the ''not_loaded'' remains as 0. The game may see this as the clip still being loaded in an object, so the clip effectively disappears. --[[User:Mikawo|Mikawo]] 11:05, 19 August 2009 (EDT)
::This is possible. The wiki is wrong on these 2 fields BTW: it is in fact just one field (loaded_into signed extended to 16bit). I'll have a look at that. [[User:Seb76|Seb76]] 14:33, 19 August 2009 (EDT)

I think Mikawo is right. UnloadClips() should look something like this:

void UnloadClips()
{
obpos_dat *pObPos=pObpos_dat;

for(unsigned char i=0;i<170;i++)
{
if(pObPos->itemType != 0xff && pObPos->not_loaded == 0 && IsXComItem(i))
{
pObPos->loaded_into=0xff;
<big>'''pObPos->not_loaded=0xff;'''</big>
}
pObPos++;
}
}

Quite a few other functions in '''equipment.cpp''' use this check '''pObPos->not_loaded == 0xff''' so it is important to set this flag just for UFOExtender, regardless of whether the game needs it set (which it probably does). Eg items unloaded by UnloadClips will thereafter fail to be found by GetFreeItem, during execution of LoadSoldierEquipment. That probably explains the problems observed.
[[User:Spike|Spike]] 15:24, 26 August 2009 (EDT)

:I did some rework based on that. Do you have other problems? [[User:Seb76|Seb76]] 16:08, 30 August 2009 (EDT)

::Thanks Seb. This seems to be working mostly ok now. Some remaining smaller issues I have seen:

::* The weight calculation is so accurate, it is more accurate than the unmodified game. So the "weight free ammo" (the first clip loaded into a weapon, before the user takes any action in the Equip screen) is no longer weight free. Not sure if you want to "fix" this or not? It is debatable. Really, you have fixed a bug. But the normal game behaviour has changed. Maybe make the "weight free ammo" optional?
::* There is a weird glitch. If I unload a weapon, put it and the clip on the ground seperately, that works fine. But if I pick up the clip '''directly from the ground''' and load it straight into the weapon, then drop the weapon, the weight of the clip is still shown on the soldier. And actually the same thing happens with a clip that is first moved into the soldier's equipment. So in fact the problem is that a clip loaded into a weapon, doesn't get removed from the soldier weight when the weapon is dropped onto the ground. It happens even if the clip is pre-loaded by your routine.
::* Still outstanding - you can't use the right arrow to move onto a second screen of equipment. So you can't have more than one screenload of equipment on the ground. Or maybe you can, if you start the Equip screen with more than one screenload on the ground - I didn't check that.

::[[User:Spike|Spike]] 13:10, 1 September 2009 (EDT)

== Glitch with Alien Pets and Big Brother? ==

Hi Seb. I was trying to do some initial research on the idea of [[User:Spike#Tank mods|Tank mods]] but it looked like these 2 useful features of your Loader, Alien Pets and Big Brother, have both stopped working. Can you test this, on the latest version? I'm using a very recent version (last 2 weeks) but not the absolute latest as I have internet download problems.

Also, have you seen this new Wiki article: [[Enemy Unknown Extended]]. It is a package including your loader plus a few other odds and ends.

cheers,
[[User:Spike|Spike]] 11:16, 17 August 2009 (EDT)
:My mistake, I commented out that part of code a while ago and only recently noticed that. It was corrected one or two versions ago.
:The article is a good idea, it should allow less techies an easy start. [[User:Seb76|Seb76]] 13:51, 17 August 2009 (EDT)
:: OK cool yes the Hacks are back in place, thanks. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)

== Alien Bleeding ==

Test results:

* 1-unit and 4-unit aliens can be healed by anyone (alien or human) holding a Medkit
* 4-unit aliens can be healed by standing in any of their 4 squares
* 4-unit aliens can only be healed while they are stunned. Pointing to their "control" square does not seem to work.
* 1-unit aliens can be healed either while conscious or while stunned
* Wounds on aliens can be correctly seen with Medkits
* The Medkit display shows a human silhouette regardless of the alien type, of course
* Healing aliens with Medkits, stops them from dying of wounds (not 100% tested but seems to be true)
* Aliens (large and small) seem to lose the correct amount of Health per turn from Wounds
* Aliens with wounds that are not treated, eventually die (not 100% tested but seems to be true)
* A Mind Probe can see if an alien has Wounds.

Anomalies:

* I had a lot more reports of Reapers dying than I would expect. I would not have expected any to die, and I had 3 reports of death by wounds. Even heavily wounded Reapers take a long time to die. In my test I was only shooting them with Pistols. Maybe there is a problem with the reporting? Maybe the death of the same Reaper was reported more than once? More testing needed on this.
:I wonder if Reapers are receiving wounds on all 4 sections when hit by explosives (I don't know which weapon you were using). They really shouldn't, although I'm unsure how you'd get around this. If possible, put a cap on the maximum number of wounds something can ever have (perhaps 6). You could argue their multiple hearts really empty their blood out quickly, but I don't think fatal wounds should ever become more dangerous than burning alive.

:: Well, why not: hit four times by one explosive, check for incurring fatal wounds four times. -- [[User:Zaimoni|Zaimoni]], 13:49 Sept. 6 2009 CDT

* Question: should the death of an alien by wounds be reported, or should it die silently? Did I only see these messages because I was using Alien Pets, and so they were on "my" side?
:Regarding death reports, I enabled the dialog for aliens/civilians (it usually only shows up for xcom operatives) to help in testing. The final version will not show them. [[User:Seb76|Seb76]] 14:10, 3 September 2009 (EDT)

Caveats:
* I used the Alien Pets, Big Brother, and Alien Inventory hacks to do this test. I also hacked a save game to give me Pistols, Medkits, PsiAmps and Mind Probes. [[User:Spike|Spike]] 16:03, 3 September 2009 (EDT)

To Do:
* Test if aliens (small, large and mechanical) suffer from [[Fatal Wounds#Other effects of Fatal Wounds|other effects of wounds]], e.g. penalties to Energy, Accuracy, Time Units
* Do Cyberdisks, which have no legs or arms and probably no head, only ever receive Torso wounds?

=== Mechanical Bleeding ===

* Question: Do Cyberdiscs and Sectopods receive Fatal Wounds? I'm wondering whether an unconscious Cyberdisc is safe to be around. Even if they didn't explode, Fatal Wounds would be stupid for a robot. If XCOM tanks can't end up leaking fuel and sparking dangerously, neither should enemy robots. [[User:Stubbs|Stubbs]]
: I think you can make a case for tanks and robots having "wounds", i.e. damage that gets progressively worse by itself. You can even make a case for them being "stunned" - temporarily non-operational. You can even make a case for it applying to alien robots but not to X-COM tanks, since alien robots all have some degree of organic component (which is why they can be Mind Controlled). But I still think you are right, neither effect should apply to machines, whether alien or human. As for your question, see the tests below:

Cyberdisk Bleeding Test Findings:
* Cyberdisks take Wounds (with Alien Bleeding option enabled)
* Cyberdisk wounds can be healed (though only after unit is stunned)
* Cyberdisks lose health from wounds
* Cyberdisks can die from wounds
* Cyberdisks don't seem to explode when they die from wounds ("has died from wounds" popup)

Cyberdisk Bleeding TestTest Caveats:
* Same caveats as previous tests (above), plus:
* The Cyberdisks were modified from Reapers using xcomutil :rpl
* Some Pistols were changed to Laser Rifles using xcomutil :chg
* (xcomutil was not installed in the game directory however, it was used from another location)
* The stats (Armour 34 all round, Health 120) appeared normal for Superhuman
* However the Cyberdisks seemed to fall too easily to Laser Rifle fire (e.g. 1 hit)
* Also, they seemed not to explode as often. This was because they were often stunned.
* Hard to tell in-game whether a Cyberdisk is dead or stunned. The graphic is the same, you can't use a Mind Probe, nor look on the ground, nor even check by changing sides.
* Actually there is one way to tell: stand over it and use a Medkit. Didn't think of that. [[User:Spike|Spike]] 08:22, 5 September 2009 (EDT)

:Thanks for finding out, Spike. Autopsy text shows you are right about the Sectopod( but not about the Cyberdisc) having biomechanical components, but it's not like there are gallons of blood pumping around the thing to gush out. One thing: did you check both conscious and unconscious death-by-wounds for the Cyberdisc? [[User:Stubbs|Stubbs]]
::No problem Stubbs. I didn't deliberately test this, but I had numerous deaths-by-wounding while unconscious and I think at least a few while conscious. I believe those that died while conscious, exploded. (I think this is the basic rule for Cyberdisks. If they are stunned, they don't explode. This typically happens with stun weapons but can also happen with regular weapons, if you are lucky.) [[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)

* Seb76: maybe robots receiving wounds was an oversight, or maybe you really do want robots to take wounds. In either case, it would be nice to have a separate option for this. My arguments against robot wounds are pretty simple: tanks do not receive them, the bled-out dialogue "X has died from a fatal wound" sounds silly for a robot that was never alive, and finally that a Medkit should not be able to heal a robot.
: It's reasonable that alien mechanisms (Sectopod, Cyberdisk) would not suffer from wounds. Possibly also Zombies should remain immune to wounds? From a note Seb made elsewhere, I think the UNITREF.DAT "can be wounded" flag is the same as the "can be stunned" flag. Wounding is probably prohibited globally for aliens, by an override somewhere in the executable. Seb has probably removed this override, unconditionally. To remove the override more selectively, I suspect Seb would need to put a logic test in the code, to check the alien type. .[[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)
::There was a check for ownership that I simply removed. Next version will have an explicit check for robots/chryssies/zombies not to bleed. [[User:Seb76|Seb76]] 12:29, 6 September 2009 (EDT)

* If you want a sense of "the Sectopod's leg got damaged" or even "the tank's track was broken", perhaps robotic units could be 'wounded' by damaging max TUs.
* If, however, the above won't let weapon usage TU %s recalculate as TUs are lost (i.e. the units lose firing ability as well as walking), then certain values of Energy with the correct Energy usage modifier could emulate loss of speed without losing firing ability. Since Energy is returned at a rate of 1/3 of TUs, these units could have an Energy value of (slightly less than) exactly 1/3rd of their TUs. Their energy usage modifier is then changed to allow this small energy value to usually suffice. Now, when Energy is damaged, the units will be permanently slowed, but their weapons won't be affected. [[User:Stubbs|Stubbs]]

=== Zombie Bleeding ===

Zombies that bleed to death don't seem to turn into Chryssalids. As discussed above, it might be better to disable wounding for Zombies. (Death by wounding for Zombies was already possible, without this fix, if the Zombie was mind controlled, wounded while mind controlled, then released back to Alien control.) [[User:Spike|Spike]] 21:07, 5 September 2009 (EDT)

== Hostile Civilians ==

This fix also seems to prevent:
* [[Exploiting_Mind_Control#Zombie's_Permanent_Control_of_Aliens_via_Stunning|Permanent Control of Aliens via Stunning]] Exploit - as was hoped for.
* [[Exploiting_Mind_Control#Resurrect Zombified Agents|Permanent Control of a Chryssalid/Tentaculat]]

It does not fix:

* Various Mind Control bugs:
** [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]
** [[Known_Bugs#Mind Controlled Aliens Count as MIA if you Abort]]

(Probably because fixing both of these requires special, end-of-mission processing)

Still To Be Fixed:

* [[Exploiting_Mind_Control#Exponential Mind Control|Exponential Mind Control]]

(This requires a check in UNITPOS to ensure that the unit attempting Mind Control is not, itself, already mind controlled.)

[[User:Spike|Spike]] 16:16, 3 September 2009 (EDT)

== Fixed Funky Fire and Zombies ==

Fixed Funky Fire still permanently kills Zombies, when the killing damage comes from (end of turn) fire damage. [[User:Spike|Spike]] 21:02, 5 September 2009 (EDT)

== Research Tree ==

I've found a way of modding the research tree and was wondering if people are interested in an updated version. I've read of stuff like enabling hovertanks from cyberdisc autopsies or flying suits with floater research, but I think there is more that can be done. The limitations from the original game is that having researched a topic cannot unlock more than 4 new topics, and cannot unlock the production of more than 4 new item types. Any ideas? [[User:Seb76|Seb76]] 12:40, 6 September 2009 (EDT)

* Another one I mentioned was: Mind Probe before Psi-Amp, although I'm going to retcon that to "Mind Probe before Psi-Lab" (which then leads to Psi Aimp as per usual). The logic behind this is that the first step of a psi-attack must be scanning for enemy brainwaves to pick them out of the other signals. Before you can teach soldiers to do this, you'd have to have studied the mind probe to see how the non-psychic aliens are managing to find targets. You've got to walk before you can run, after all.
* I'm unsure if the next suggestion is possible, given what you have said. I'd like some kind of necessity to research at least some corpses/aliens - is it possible to require, say, any 6 alien 'live' or 'autopsy' reports finished before Alien Origins unlocks? You might also make it dependent on difficulty (6/7/8/9/10 needed). You could also include alien missions in this count.
* My only other suggestions are: you should have to research Elerium before you can build anything that requires Elerium to build. You should have to research Alien Alloys before you can build anything that uses those (which is true only for some things currently. It doesn't seem to be a prerequisite for building alien weapons). Is it possible for a manufactured item to require two separate research entries to be manufactured?
* Question: is there also a limit of 4 prerequisites for a research item? [[User:Stubbs|Stubbs]]
:There is no limit on prerequisites, it's the code that shows "you can now build/research xxx" that has a 4 entries limitation. [[User:Seb76|Seb76]] 15:05, 6 September 2009 (EDT)

A boring suggestion but how about making sure that for all weapon research, you need to do the pistol before the rifle before the heavy weapon, etc. And similarly with the ammo types. Apart from that, I'll think on it. [[User:Spike|Spike]] 17:42, 6 September 2009 (EDT)

Another boring suggestion: each specific laser weapon should take a little longer to research - force you to use the starting weapons for a little longer. You could also rebalance the Plasma research times so that the rifle took a little longer and the Heavy Plasma took significantly longer. It might then be more viable to research them from weakest to strongest, without forcing your hand as Spike suggested. [[User:Stubbs|Stubbs]]

:Yep that's a good alternative.

You could make the Stun Launcher a little harder by requiring (as well as Alloys and Elerium), perhaps a live Medic to be researched before the Stun Launcher (since it's usually Medics that carry them and presumably understand how to operate them), and an Engineer for a Blaster Launcher. It's not much extra but it helps to make these powerful weapons a little harder to get. If you wanted to make Blaster Launcher quite a lot harder to get you could add something like UFO Navigation (something to do with plotting all those waypoints, alien-stylee), or at least a Mind Probe for similar reason.

But, what are we trying to do here? Make things harder in general? That's one option. Or "rebalance", i.e. make things that are relatively too easy to get, relatively harder to get? Or make things more "logical"? There's lots of ways to play this.

It's a shame there's not a distinction in the game between using, and manufacturing, alien weapons - as is done in XcomUtil. Really, there should be a world of difference between figuring out how to use scavenged alien weapons, and actually being able to manufacture them. But that's not really a research tree topic, '''unless''' - would it be possible to create new topics? Could you separate out the using of an item from the manufacturing of it? (If not, it would be good to have a game variant in which nothing that can be scavenged, is allowed to be manufactured).

UFO Navigation might also be a good prerequisite for Hyperwave Decoder. I'm sort of rambling here, but what are the most powerful technologies, that are kind of easy to get... which ones need to be made harder. (Are there any that need to be made easier?)

Powerful technologies:
* Psionics (Psi Lab == Psi Amp). Adding the Mind Probe, as suggested, would be a good idea. Maybe a psionic Commander capture required for each.
* Blaster Launcher - maybe require an Engineer and a Soldier research, as well as Elerium & Alloys. Mind Probe or UFO Navigation for the "plotting" element? A separate Engineer capture to produce the ammo? What else?
* Stun Launcher - Medic and an Engineer? Maybe a full set of autopsies - but that's too onerous.
* Heavy Plasma - stretching the research time would be good, though this can already be done. Additional pre-reqs - maybe add a live Engineer requirement (maybe for ''each'' Plasma weapon type?). If you keep making these requirements you probably need to add a hint in the UFOPaedia along the lines of "we will need to interrogate alien technical experts to further understand this weapon technology". (OK that's hardly a hint.)
* Laser Cannon (?) - But I'm not sure this Laser Cannon factory thing is a big deal. Arguably building a new intercept base is a better cash cow than building a 50-Engineer Laser Cannon factory.

[[User:Spike|Spike]] 16:34, 8 September 2009 (EDT)

== 64 bit compatibility ==

Any way to make the loader compatible with 64-bit operating systems, like 64-bit XP/Vista/7? [[User:Jwilcox25|Jwilcox25]]

: I'm using it on Windows 7 and it's working fine. Not sure if that's 64 bit though. [[User:Spike|Spike]] 07:26, 9 September 2009 (EDT)

:: If you're not sure, you are probably running the 32-bit version of Windows 7. Starting from XP, Windows comes in both 32-bit and 64-bit flavors. Most 32-bit programs are backwards compatible, but apparently not X-COM from my experience. [[User:Jwilcox25|Jwilcox25]]

: It works fine with Windows 7 64-bit. Didn't have to enable any compatibility options or anything like that. [[User:Rovlad|Rovlad]] 02:29, 23 April 2010 (EDT)

== Music bug ==

When enabled "MIDI freeze" bugfix, after entering first combat the music stops playing completely, for the remaining game session.

Also, when using Extender, for some reason music is playing at really low volume, i have to manually reduce my main sound channel and crank up the volume to hear it. When just starting normal UFO CE volume levels of music and sfx are about equal. I have SB Live & WinXP.

== Fire Speed bug ==

Sometimes, for no apparent reason, fire speed setting jumps to 3, instead of what you had it set on.

: I believe it's a bug in the game itself, not the loader. I remember encountering it in both DOS and CE versions. [[User:Rovlad|Rovlad]] 02:31, 23 April 2010 (EDT)

== Reserve TU for x-Shot ==

Not sure if this has been addressed or fixed, but if you reserve Time Units for any shot type, all you get is Snap Shots for the reaction phase - never aimed or auto. Is there any way you could enable these two unused types for reaction shots? --[[User:Zombie|Zombie]] 22:51, 25 October 2009 (EDT)
:As far as I can tell, the reserve is only meant to be used during the active turn. Reaction shots are hardcoded to snapshots (that's true for the aliens too), it's no bug that your guys don't use reaction autoshots. [[User:Seb76|Seb76]] 12:10, 16 January 2010 (EST)

== TFTD ==

I know you're hoping to perfect the current version before taking on any new projects, but I just want to add my plea to the others requesting a TFTD version. Even some of the basic functionality would be awesome and probably completely portable, such as the stats on the equipments screen, default new base, etc.

== Can't change tasks in D3D ==

Hey, I'm having an issue with D3D. If I alt-tab out, I can't switch back to the X-Com task. I'll switch to it but nothing can happen. I'm on Windows 7 x64 with an ATI Radeon HD 5770. [[User:Rlbond86|Rlbond86]] 20:19, 15 January 2010 (EST)
:I too have hangups sometimes when alt-tabbing out of XCom, sadly I'm no D3D expert :( I'll add more checks to see if resetting the D3D device worked though. If anyone knows of a 100% working way of dealing with "device lost" conditions, now is your chance... [[User:Seb76|Seb76]] 12:06, 16 January 2010 (EST)

== Battlescape Soldier's Stats Crash ==

I'm having this little problem with this and I wanted to know if I'm the only one that's suffering with it: everything works fine, but when in battlescape mode I want to check the stats of a soldier (by clicking his rank icon) the entire game CTD. Does it happen to anyone else? How can I fix it?
:Never saw such problem...
:* Does it still crash when you disable the extender (and what options did you enable)?
:* Do you have the address where the crash happens?
:[[User:Seb76|Seb76]] 15:55, 22 January 2010 (EST)
::It didn't, but now I reinstalled the game and it works wonderful. This is a great job you did here. Is there any chance that you could access to the stats of the soldiers from the assign crew screen? --[[User:Slibluhr|Slibluhr]] 16:56, 22 January 2010 (EST)
::OK, I could reproduce the crash this time, it has nothing to do with the stats screen as I supposed to do. The game crashes RANDOMLY if I have turned on the D3D thingy, any clue? I've also noted that if I turn on the caps mod (to put most of 'em in 150-200 to overcome the distance penalty) the soldiers do NOT improve, even after kicking a large scout's butt with KAtherine Sharpe, she didn't get any FAc point! --[[User:Slibluhr|Slibluhr]] 05:30, 23 January 2010 (EST)
:The caps bug is a known one, and a fix is available. I thought I'd wait for more substancial stuff before releasing a new version though. You can try the latest dev version that has the fix included.
:As for your crash I cannot do much without a crash address... [[User:Seb76|Seb76]] 11:46, 24 January 2010 (EST)
::This is what it said during last crash:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00011689

::--[[User:Slibluhr|Slibluhr]] 15:29, 24 January 2010 (EST)
:Sadly the address is of no use (crash inside Windows code, most likely because of wrong arguments). I've put a new version up with better D3D error handling, does it help with your crashes? Also since I was feeling like it, I updated the "Reorder Soldiers" feature so that when you click the name of the soldier, his stats show up. You must click the rank/name of the ship to assign the soldier. [[User:Seb76|Seb76]] 18:00, 24 January 2010 (EST)
::Thank for the access to the stats of the soldiers via crew screen, it releases them from having their FAcc and PStr in the name.

:: btw, the crash moved to this location now:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00028c0b

::could it be that's my pc's fault? does this happen to anyone else?

::------------------
::System Information
::------------------
::Time of this report: 1/25/2010, 01:25:00
:: Machine name: 0X000001
:: Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.090804-1435)
:: Language: Spanish (Regional Setting: Spanish)
::System Manufacturer: FOXCONN
:: System Model: A6VMX
:: BIOS: BIOS Date: 03/13/09 09:59:28 Ver: 08.00.14
:: Processor: AMD Sempron(tm) Processor LE-1250, MMX, 3DNow, ~2.2GHz
:: Memory: 3072MB RAM
:: Page File: 466MB used, 4490MB available
:: Windows Dir: C:\WINDOWS
:: DirectX Version: DirectX 9.0c (4.09.0000.0904)
::DX Setup Parameters: Not found
:: DxDiag Version: 5.03.2600.5512 32bit Unicode

== Store limit question ==
Nice to see you've implemented the general store change (unfortunately, UFOExtender doesn't work under wine, so I can't test this). I'm curious why 187 is the limit? I thought it would be a power of 2 (possibly minus 1)... Possibly you wanted to write 127? [[User:Cesium|Cesium]] 19:43, 21 February 2010 (EST)
:You can build 35 general stores max in a base and 65535/35 ~= 1872 (the internal representation is ten times what's shown ingame). [[User:Seb76|Seb76]] 00:19, 22 February 2010 (EST)

== Mouse scaller not working on Windows 7 x64 ==

with d3d=1 and Scale Mouse=1 I still have issues with the mouse going way off screen.
--[[User:BladeFireLight|BladeFireLight]] 01:57, 22 February 2010 (EST)
:I have noticed that alt-tabbing out of X-COM at the title menu (or any other point that won't crash it) and then alt-tabbing back into it fixes this problem for me in Win7-64. --[[User:Xusilak|Xusilak]] 13:12, 22 February 2010 (EST)
::Thanks for the heads-up. I uploaded a test version here: http://www.ufopaedia.org/index.php?title=Image:UFOExtender-dev.zip
::Does it fix you problems? [[User:Seb76|Seb76]] 14:36, 22 February 2010 (EST)
:::Yep. Seemingly no issues with the mouse going off the screen using it, although I didn't test for long. I'll try to get more test time in later. --[[User:Xusilak|Xusilak]] 20:46, 24 February 2010 (EST)
::::Actually, it doesnt work for me either, in WinXP. And it was broken since the version of 7th November, the one with windowed mode addition. Also, Alt-Tabbing didnt work too. This fix makes things right, though.
::::Edit : also, this dev version crashes in 100% cases when going to battlescape.
::Strange, I do not have any trouble even when using split binaries. Do you have an address for the crash? [[User:Seb76|Seb76]] 14:03, 1 March 2010 (EST)
:::Okay, i hope this is what you wanted, but it says the adress is 0x0000000000bd22ca. I can load an actual save with tactical mode, but cant go into tactical from geoscape. So i use the version from 1st November still.
:Hum, you say the dev version crashes and that you are stuck with the version from 1st november. Do you mean you have the problem since the version of november the 7th, independently from the dev version? [[User:Seb76|Seb76]] 14:08, 4 March 2010 (EST)
::Actually yes. At first i didnt want to use it, because i use a tablet instead of mouse, and its really noticeable when a window failed to scale properly, since a tablet works in absolute screen coordinates. But just now i checked several new (non-dev) versions for the crash - its there. Crashes every time i try to enter tactical mode from geoscape. Saves from tactical load up fine. Version from Nov.1st gives no problems whatsoever.
:Do you still have the problem if you disable D3D or use windowed mode? Also if you load a tactical game, don't you get a crash when it goes back to geoscape? [[User:Seb76|Seb76]] 03:20, 6 March 2010 (EST)
::When disable D3D - yes. When enable windowed - yes. When going from tactical to geoscape - no.
:OK, I suspect this has to do with the "Save Equipment" feature. Can you try disabling it if you have it on? [[User:Seb76|Seb76]]
::OK, um...i tried all my saves, and with that feature disabled all my saves load up fine, and i can go from geoscape to tactical and back. So i thought everything was alright, and kept playing - the very next tactical mission loads up fine, but as soon as i try to move anyone - it crashes. And that is the same in all my saves, first mission is alright - second one always crashes. The crash adress is 42064f, in case you're gonna ask.
:Alright, can you PM me a savegame before the crash? I doubt it'll help but who knows...[[User:Seb76|Seb76]] 12:43, 6 March 2010 (EST)

== Extender in Steam (+ maybe XComUtil) ==

Hi do you know of any way to use the two apps together with the Steam version? I would really like to be able to combine the 'Reorder Soldiers' feature of Extender and the 'Capturing Aliens for Research' of XcomUtil.

Actually now that Ive put a bit more time into it I can't get UFOLoader.exe to run in steam's dosbox implementation at all. I can just run UFOLoader but it doesn't run in dosbox which makes the game run horribly. If you don't have a steam copy for testing / integration of the basic Extender program please let me know and I would be happy to send you a gift copy.

-Dogfish

P.S. What a great program, you are a credit to gaming.
:As far as I know, the Steam version also ships with the windows CE edition, the default shortcut just happens to point to the dosbox one. Also the latest version of XComUtil is able to detect the loader presence and act accordingly. [[User:Seb76|Seb76]] 15:42, 25 February 2010 (EST)

:: STEAM comes with both EXE. XcomUtil and UFO Extender work together with STEAM. To use Setup UFO Extender in the game folder. Then Download and install the latest build of XcomUtil 9.7. It will auto start XcuSetup in windows, Detect UFO Extender and allow you to configure RunXcom to use it. To use UFO Extender, or UFO:CE you can't launch the game from STEAM. You have to create a short cut for RunXcom. (Right click > send to > Desktop as Shortcut) --[[User:BladeFireLight|BladeFireLight]] 19:13, 25 February 2010 (EST)

Thanks guys I was able to start the game with both mods. I apparently had everything configured correctly but I kept launching it from steam. Is there a way to play in windowed mode (since its not using dosbox)? I tried launching dosbox and running 'RunXCom.bat' file from there but it does not recognize UFOExtender.

Oh boy the game is fast, even on slowest scroll it is difficult play a battle :)

-Dogfish
:What options did you turn on? [[User:Seb76|Seb76]] 14:18, 26 February 2010 (EST)

Show Stats=1
Apply=1 (wreck analysis)
Proximity Grenades Experience=1
Elerium-fueled Craft Bug=1
Save Reserve Mode=1
Rank In Inventory=1
Manual Interception Fire Mode=1
Crafts Always Ready=1
Reorder Soldiers In Crafts=1
No Funkers=1
TFTD Doors=1

Full System Specs:
Win Vista 64
Intel i7 920
6GB RAM
GTX 285 Video
Asus p6t

Everything is fast the geoscape tics are at least 5 times faster than running the non-Extender mode via dosbox.

Would you have any suggestions how to slow it down? I've actually been playing in steam(dosbox) with XComUtil only and then saving/loading between missions so I can reorder the soldiers.

Aha! I found the D3D Windowed option...
HQ4x=0
D3D=1
D3D Windowed=1
Always On Top=0
Clip Cursor=1
Scale Mouse=1
Screen Ratio=0.833333

I can manually resize it to be bigger, excellent!
What is strange is that running it in windowed mode seems to slow it down enough for the scroll speed settings to make it playable :)

I ran into a "Unsupported 32/16/64 bit error message switching from geoscape to battlescape but it happens only 1/3 times maybe?"

I will be playing this and let you know if I run into any more problems.

Thanks a bunch!
-Dogfish

Hi guys, dogfish again I've been getting a couple of glitches.

1. Switching from battlescape back to geoscape in the cmd prompt it displays
'echo----------------------------Leaving' is not recognized as an internal or external command, operable program or batch file.

2. This has happened twice

Get someone who has been shot is at low health and has fatal wounds

Have them pass out due to smoke inhalation

Let them bleed to death and get the "Joe McSoldier has died from a fatal wound" *while unconsious from the smoke*

I will lose points for the mission but the soldier will be recovered at the end of the mission but terribly wounded. (Currently Hans 'Jesus' Vogel is taking 55 days to recover his 41 health.)

:Both of these are XcomUtil issues. 1 has been fixed in Build 413 but I need a saved from just before ending combat to fix 2. --[[User:BladeFireLight|BladeFireLight]] 18:19, 28 February 2010 (EST)

::Sent the savegame to your gmail (whatever was listed on my paypal reciept from your donate button). Just hit end turn (all the aliens are dead) and the bug is triggered. -Dogfish
::: I got it. Was up all night with Bomb Bloke and we worked out what was going on. The fixed works with your save. The next build will fix the zombie bug. Also Thanks for the donation. Every little bit helps. --[[User:BladeFireLight|BladeFireLight]] 16:02, 1 March 2010 (EST)

--
Hi! I'm thefarside. This is my first time ever editing a wiki page so please bear with me. I'm not even sure I'm allowed to do this.

However, I have a problem with the cursor. It moves WAY out of the screen to the right and downwards. I've read something about a "clip cursor" fix but I can't seem to find out where and how to implement it.

Regards,
thefarside
--

== Manually Select Promotions ==

Just an Idea, not sure how easily done it is but I was thinking it would be really cool if (when its time for promotions) it would bring up a soldier screen with the eligible soldiers so that you could pick who gets promoted. Bonus if you could click on the candidates and be taken to their stats screen.

Love,
Dogfish

== Xusilak's Patch Additions ==

Since my patches are being integrated into the main release now, everyone should let me know if any issues are found with them. I'll try to get on fixing them as quickly as possible.

For clarity, the patches in the current build that I developed are:

* AutoSell
* Show Money

Thanks! --[[User:Xusilak|Xusilak]] 14:51, 24 March 2010 (EDT)

I went ahead and set up my own user page: [[User:Xusilak]]. If possible, direct discussion about my patches to my [[User_talk:Xusilak|discussion page]] there. Thanks again! --[[User:Xusilak|Xusilak]] 15:44, 24 March 2010 (EDT)

----

Hi Seb,
I've been working with IDA, your database, and your patcher's code for some time now, learning my way around it, and so on. So far, I've managed to come up with three UI improvement patches, although they still need some polish and testing.

The first one is a battlescape movement confirmation patch; it requires the user to click twice (double-click with no time limit) on the same tile to move, instead of once, to eliminate movement errors. In practice, I have found this very helpful.

The second one shrinks the geoscape clock and adds your current funds above it, letting you see your financial situation at a glance while waiting for time to pass.

The third one enables auto-selling of manufacturing items. Pressing the down arrow when the production quantity is at 0 engages this mode. When in this mode, production of that item never ceases (unless resources become unavailable), and the item is immediately sold upon completion.

Would you like me to make the code for these available once I've finished polishing them up? They currently consist of a few C functions accompanied by some InsertCall()s and Nop()s, as well as some additions to XCOM.h. I haven't added INI options to enable them, so I'd leave that up to you. You may use them as you wish, with no conditions.

Note: I'm still learning x86 assembly, so the patches may not be bug-free. I'm hoping to give them a good testing myself, though.
--[[User:Xusilak|Xusilak]] 16:10, 19 March 2010 (EDT)
:Glad to see you could make something out of this database :-) Do not hesitate to send me your modifications, I'll incorporate them in the codebase so others can enjoy them. I'm sure your autosell feature will make a few happy ones ;-) [[User:Seb76|Seb76]] 19:12, 19 March 2010 (EDT)
:::Yeah those features would all be '''great!''' Thanks Xusilak. [[User:Spike|Spike]] 15:08, 22 March 2010 (EDT)
::OK. I'm going to finish up my last touches on them, then test them for a while; they should be ready within a couple days. --[[User:Xusilak|Xusilak]] 21:59, 19 March 2010 (EDT)

== v1.21, Battlescape crashes ==

I enabled the new mods and they worked ok in Geoscape. Then this Popup box starting the first Battlescape:

Application failure
XCOM crashed at 0x10002571 with error 0xC0000005 trying to access 0x0968DF43

[[Media:UFOExtender1.21.BSCrash.zip]] contains the UFOExtender.ini file.
This was a New Game but not a new install of XCOM, just an overlay of updated UFOExtender.

*Win XP Pro 2002 SP2 32bit PAE
*Pentium-4 3.00GHz 3.5GB RAM

Any ideas? Need more info? [[User:Spike|Spike]] 20:20, 24 March 2010 (EDT)
:Does it happen consistently? I've been plagued by a random geoscape->battlescape transition crash in the collector's edition. It's one of the things I'm looking to fix at some point. The current UFOExtender doesn't appear to crash any more than previous ones do for me. I managed to do four missions in a row just now. --[[User:Xusilak|Xusilak]] 21:00, 24 March 2010 (EDT)

I'm doing some research into this; I started up in debugging mode and spammed missions until I hit a crash. The crash (on this occasion) is an access violation caused by an invalid pointer stored at 0x49B954 (the offset that pSoldierDat points to). This means *pSoldierDat is being changed at some point. It took many, many tries to get this crash to happen; I reloaded something like 20 times hitting the same mission, went ahead and did the mission quickly, proceeded, did another mission, proceeded, then the next mission crashed. Given that I'm in debug mode, it's not impossible this is due to the various hacks enabled by it, so that should be kept in mind. I'm going to continue working on this. --[[User:Xusilak|Xusilak]] 22:26, 24 March 2010 (EDT)
:It appears the "invalid" pointer is actually set by malloc() - 0x0771D380 (for me). I can only assume something along the way disrupted the data on the heap, as the pointer was the same when examined on a battlescape transition that didn't crash. Still researching. Note that for me, the crash itself happened inside GetSolderUUID() in the Save Equipment patch functions when it attempted to use that *pSoldierDat pointer. However, I assume it would still happen if the Save Equipment patch were disabled, just elsewhere. This is something I'll test as well. --[[User:Xusilak|Xusilak]] 23:41, 24 March 2010 (EDT)

::Sorry I'm guilty of reporting a bug I didn't (couldn't) repeat. But as I had no previous save game positions I couldn't repeat anything - the crash happened on the first Battlescape mission which for me is unusual, I would say that for me that transition crashes less than 1 in 100 times, if even that many. I had enabled Save Equipment I think and on instinct I would suspect that mod as being responsible. Those UFOExtender functions would run while setting up the Battlescape presumably. The equipment handling functions and structures ''already'' present in the game are known to be buggy. BladeFireLight and I just found another issue with them last week. Manipulating them is still risky. If you can investigate that would be very helpful.

::In the meantime I will see if I can try to repeat the fault, with and without Save Equipment enabled, and starting from a clean XCOM install. One trick I may use is to set No Score Game Over and then just abort from each mission rather than fighting it, to speed up the testing.

::Thanks for your good work Xusilak, it is appreciated! [[User:Spike|Spike]] 03:25, 25 March 2010 (EDT)

One possibility: On this mission I had only 6 soldiers (2 HWPs) but enough weapons in the Skyranger to equip 14 soldiers. Is there some known issue with needing to allocate '''all''' weapons to soldiers during the equip phase, in order to avoid a crash? If so that might be the cause. I will try to recreate those conditions and see if it provokes a crash. In case it's not clear, Battlescape never appeared to start, no Equip Phase screen ever came up. [[User:Spike|Spike]] 03:31, 25 March 2010 (EDT)
:Assuming the same crash is afflicting us, then the crash is when the very first soldier is accessed, when the Soldier.Dat data is first used for that mission. It's unlikely that volume of equipment is affecting that, and in particular, I hadn't changed my Skyranger's loadout to any degree whatsoever, having only briefly touched researching and manufacturing; it was otherwise a gamestate set entirely by doing one quick regular mission and one quick terror mission. However, I was also in debug mode, which enables certain cheats, like Alien Pets, automatically. This might, itself, have unseen bugs that could corrupt the data structures and cause a similar crash. When I get the time to, I'll be testing again with those cheats disabled, trying to further isolate the conditions involved. --[[User:Xusilak|Xusilak]] 08:34, 25 March 2010 (EDT)

I've repeated this multiple times now, with a clean install of XCOM and a clean install of UFOExtender 1.21. The game crashes everytime, after the "mission screen" that comes up just before the Equip Phase of Battlescape for the first mission. It's regardless of my equipment loadout or number of soldiers/tanks: it happens with totally default equipment and Skyranger load. So I imagine it must be due to some combination of the UFOExtender.ini file options I selected, and maybe code changes in 1.21. My .ini file is the upload at the top of this section. The error is always "error 0xC0000005 trying to access 0x0968DF43", though the crash location (in the code) varies. [[User:Spike|Spike]] 20:31, 25 March 2010 (EDT)
:If you have time, could you try to 1) confirm it's specific to 1.21 2) try to correlate it to ini options? Turn everything but the basics off and see what happens... if that works, turn on Save Equipment and try again, etc. I haven't seen any behavior like that in my local tests, on either of my computers (Win7-64 and XP-32). I'll try it with your ini, though. Maybe I can find something. --[[User:Xusilak|Xusilak]] 20:39, 25 March 2010 (EDT)
::Just tested with your ini, although with D3D and D3D window enabled. Started a mission, didn't crash. I also noticed one thing: you have General Stores capacity set to 1. I don't think that's helping anything, but it's probably not causing the crash, either. Experimenting more. --[[User:Xusilak|Xusilak]] 20:48, 25 March 2010 (EDT)

::: Save Equipment=1 is part (at least) of the problem. If I turn that off, and leave all my other .ini settings as is, I no longer get the Battlescape crash. Seb, did you make some changes there? Maybe after the investigations we were doing with BladeFireLight? [[User:Spike|Spike]] 21:13, 25 March 2010 (EDT)

I have isolated the problem (on my end) to the fact that the SOLDIER.DAT data in memory is deallocated when the transition to the Battlescape starts. When Seb's Save Equipment code attempts to use it, it's getting random unallocated (or unrelated) memory instead of the SOLDIER.DAT data. Interestingly, the dynamic memory used to hold the SOLDIER.DAT data is deallocated on the transition to the Battlescape, and reallocated to a new memory address on the transition out of the Battlescape. I assume this is an artifact of the way the Collector's Edition merged TACTICAL.EXE with GEOSCAPE.EXE, because TACTICAL.EXE had no need of SOLDIER.DAT, and only used UNITREF.DAT and similar. At any rate, this problem can be resolved by not relying on **(0x49B954) (or **pSoldierDat) to contain the correct data. Instead, a workaround to get the needed data should be used. One option would be to patch the way the transition works to prevent the deallocation from happening, and then ensuring on exiting the Battlescape that the old memory block is still used. I may be able to work in that fix myself. If so, it would require no changes to the Save Equipment code.
I'm not sure if this is a general issue or local to me only. I'll try to test on my XP system and see if it suffers from the same problem; if it does, it's a safe bet this is a general issue, and the likely cause of your crashes. --[[User:Xusilak|Xusilak]] 00:06, 26 March 2010 (EDT)

Save Equipment did used to work for me before. Maybe it's because I also selected Reorder Soldiers In Craft. Does that sort and rewrite SOLDIER.DAT? [[User:Spike|Spike]] 03:39, 26 March 2010 (EDT)

I have confirmed this behavior in the original X-COM Collector's Edition UFO Defense.exe copy, running on my XP system. As such, it ''cannot'' be a result of any patches Seb has made (because it still happens even when not using Seb's loader). I'm not sure if it will crash without Seb's patches still, but the way Seb uses the *pSoldierDat pointer in GetSoldierUUID() appears to be unsafe, as *pSoldierDat has already been deallocated at that point. On some systems, it may work, because the nature of memory on the heap is such that different systems give different results when dealing with deallocated memory and bad pointers. Regardless, the crashes can be at least partially (maybe entirely) resolved by using a workaround that avoids the deallocation of *pSoldierDat when the battlescape transition starts. I'm going to see if I can implement the fix I suggested, that prevents the memory from ever being deallocated. That should completely resolve it. At the least, I am going to study the assembly responsible for deallocating it to see if I can confirm the exact issue on the code level. --[[User:Xusilak|Xusilak]] 13:26, 26 March 2010 (EDT)
:It seems that when GotoGeographMode() returns to move into GotoTacticalMode(), it calls FreeEverything() in the process, deallocating all data structures. Then, GotoTacticalMode() never bothers to reinitialize *pSoldierDat, so when the equipment phase comes up, it's still unallocated. Still working on a fix. --[[User:Xusilak|Xusilak]] 14:29, 26 March 2010 (EDT)

::Surely at some point the (unmodified) game needs to at least read the *pSoldierDat structure, in order to populate the [[UNITREF.DAT]] and [[UNITPOS.DAT]] structures for Battlescape? Unless it reads SOLDIER.DAT but doesn't bother storing it, not even temporarily, in *pSoldierDat.[[User:Spike|Spike]] 15:27, 26 March 2010 (EDT)
:::Nice piece of analyse there :-). I'll modify the patch to load the soldier data when needed and clean up afterward. [[User:Seb76|Seb76]] 15:30, 26 March 2010 (EDT)
:::Edit: I uploaded a test version. Can you check if it fixes your crash? [[User:Seb76|Seb76]] 15:47, 26 March 2010 (EDT)
::::Looking good so far; Save Equipment works for me now, and it never has in the past. I'll run through a bunch of missions quickly and see if I get any crashes. Thanks Seb! --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:::No, thank you for figuring out the cause of the crash. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
:::::Just ran through several dozen (very quick, mostly aborted) missions all the way up to June. I never crashed, and Save Equipment always worked correctly. I think we're good to go. Hopefully it works for Spike as well. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)

I've also been narrowing in on another crash, unrelated to the patcher, I believe. It happens rarely upon clicking the air to move somewhere, like stepping out of the Skyranger by clicking the air one tile in front of the soldier, to move onto the ramp. It appears to be the result of a bad calculation on the tile to check in MoveUnitTo(). The calculation is looking at (char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize); // when esi is 2 or greater; this esi factor shouldn't be there, as far as I can tell, because it results in the offset used being much greater than it should be and frequently going out of bounds of the MAP.DAT data stored at *pMap. Continuing my research into this when I get a chance. --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:I noticed that crash also (I think it's the number one crash cause on a genuine XCOM setup) but was never able to reproduce enough to investigate it. I was tempted at one point to patch the GetTileAt function to check its arguments, but finding the cause of the corrupted value would be better. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
::Yes, it's definitely a hard crash to catch, because of how rare it is. I've got a few ideas, though. We'll see if they help. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)
:::Currently, my guess is that this line:
:::<pre>.text:00420534 BE 01 00 00 00 mov esi, 1</pre>
:::should be "mov esi, 0" instead.
:::To sum up the issue:
:::The way the 'click on air to move to a tile below unit' part of MoveUnitTo() works is that it examines each level below the unit until it finds a floor to move to. It does this by looping through the level below you, incrementing esi to loop through the next level below that, and so on. To do this correctly, esi should start at 1. However, the X-COM programmers appear to have made an oversight: they initialized esi to 1, but then incremented esi again before the initial value actually gets used. The net result of this, is that we get zpos += 2 for the very first cycle. This works OK on floors 3 and 4, but for floor 2, it will attempt to access a z level that doesn't exist (one below the ground), causing this line: <pre>(char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize);</pre> to exceed the bounds of the *pMap memory block. Obviously, running off the end of that block will cause unpredictable results, and if it reaches into a block that isn't allocated, it will crash. That's why the actual crash is very rare: it has to overrun into an unallocated memory block.
:::Of course, I could be completely wrong, but it makes sense, and patching 'mov esi, 1' to 'mov esi, 0' doesn't seem to cause any problems. I'm going to be testing with that patch enabled from now on, to see if I crash in that circumstance anymore.
::Looks like you are right. I instrumented the code and there are indeed systematic out of bound accesses when getting out of the craft, though the game does not crash every time. I suspect this is the same crash that happens during base defence when an alien tries to move down from the access lift. Kudos for figuring all this out! I'll provide the fix in the next version. [[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)
:::By the way, Seb, the 1.21 source code doesn't include autosell.cpp; I assume it's a simple oversight. I reconstructed it to get it compiling properly. Just wanted to make sure you knew. --[[User:Xusilak|Xusilak]] 20:37, 26 March 2010 (EDT)
::Oops, forgot to check the unversioned files before checking in...[[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)

== Minor cosmetic enhancements? ==

Had these ideas come to mind while I was at work today, and since your loader is doing some amazing things for the game, I thought I'd ask if the possibility of any of these enhancements exist.

The short of it is: Are you able to overlay any additional bitmap surface on top of the battlescape view, and are you able to play additional sounds?

The main idea for drawing an extra bitmap (semi-transparent) over them map would be to simulate rain/snow for some outdoor maps. Lightning even - though that would require clever use darkening and lightening the overlay. This would have some issues attached to it such as knowing when to display it and when not to, thanks to the various other screens available.

As for playing sounds, which would be simpler, would be to play a looping sound clip to provide environmental sound effects, such as insects chirping and owls hooting at night in woodland maps or town noises at terror sites. Or during the day in a jungle map, some tropical bird calls made at random intervals. TFTD already does the looping environmental sounds, such as teh under water bubbly noises or the wind and sea noises when on land mission. Would it be possible to duplicate this for UFO CE?

Not the most important of enhancements, but I was still wondering if the possibility is there.

-[[User:NKF|NKF]] 01:41, 25 March 2010 (EDT)

== Save/Load shortcuts ==

Seb, would it be possible to enable shortcuts for the Save/Load in geospace & tactical (like F2 or F3) ? ;) except for saving in the final battle (from level 4 if remember) :)

Other things:
- rosvell incidents occured for me too often - 5 in the first month while there was no other alien craft movement detections

- option to disable mission briefing window with the only ok button :) supposedly for advanced users ;)

== Aliens continue using pistols&rifles ==

Hi Seb, sorry to bother you - i have been playing X-COM titles on and off for about 10-15 years now, and one thing always bothered me: Why do the aliens always swith to heavy plasma (or the Sonic cannon in case of TFTD) later on? It encourages the player to swith to heavy plasma too, if only for the free ammunition you almost drown in later on. Would it be possible to have the aliens continue using the plasma pistol&rifle after june/july? It would make using those weapons more feasible, getting ammunition during missions and not having to use elerium to produce it.

Another request (don't know if it is possible) - let the aliens continue using the abductor and the harvester for the respective missions. Later on, all you get are large scouts or even battleships doing those missions - getting some variety in there would make the endgame more interesting. You get to do 50+ battleship missions in a game, but only 4 or 5 with a harester/abductor. Those ships should see a lot more use during the missions they are "designed" for. The "[[MISSIONS.DAT]]" page says something about ufo and mission counters and their associated ufo-types - would it possible to modify those entries via the loader?

Regards, Equinox

== ALIEN MISSION DATA CLARIFICATION ==

According to
[http://ufopaedia.org/index.php?title=Talk:MISSIONS.DAT#Alien_missions_data_discovered_in_geoscape.exe_.5Bfinally_.3B-.29.5D link title]

I found it in TFTD. At offset 505448 (decimal) is starting (mission Probe). Next Interdicition/resource raid/infiltration/colony expansion/surface attack/Floating base attack

I understood what is 3-rd word. If You interesting - I can exlain

Seeing speeds of USO sub we can determine the mission of this USO sub even without transmission resolver - even in january 2040
Every USO sub in every missions (interdiction, colony, probe and other) have unique speeds and we can determine mission of USO on their speed
And we can determine what amount of times a sub touch down on his mission - because every mission has unique rule for touch down USO subs
And we can determine what amount of time USO Sub will touch down on their mission - because every Sub in every mission has unique and ALWAYS equal amoun of time to touch down (p.s. this time we can see in file Loc.dat)
Here - I attached file speeds.zip
[http://www.strategycore.co.uk/forums/Ion-Beam-Accelerator-in-What-file-t8099.html&view=findpost&p=95994#entry95994 link title]

3-rd word - it is reference to unique speed of each sub

4-th word - is time that precede to arrive next uso sub. In other word, in line ufo/c 0/0 if time = for example = 200 - it's time to arrive sub that indexes 1/0.
And where can I get time to arrive EXACTLY sub 0/0 is incomprehensible for me. I assume that this time contain at similarly word of last uso for this mission - but its'not truth because at some missions time in the line of last ufo/c = 2 half-hours and it's means that ufo/c 0/0 can to arrive at new month at 2 half-hours. It's true for Surface attack Mission but not truth for other missions.
I assumed that time in line ufo/c 0/0 - that time to arrive for NOT next ufo - and I assumed that it's time to arrive exactly ufo/c 0/0 itself. But many my tests (more than 100) denies my suppositions.
In example, at line ufo/c Cruiser mission Colony Expansion time in file =2. Cruiser in that mission arriving much more than 2 half-hours after Escort. Instead Fleet supply Cruiser in that mission arriving after 2 half-hours exactly after Cruiser.

'''Question - Where can I find time to arriving for ufo/c 0/0 for each missions except Surface attack mission ?'''

I am sorry for disturbance and will great thank for you for help.
:After the first month the game creates a mission per month, up to the 6th where it generates 2. I guess a mission starts immediatly, there is no timing added for its first ship. [[User:Seb76|Seb76]] 15:18, 30 April 2010 (EDT)

Mission starts not immediately. often time to arrive to survey ship (first sub) about 10-15 days.
1-st day of month at 0-00 we can see it time at Missions.dat but wants to know average time similarly such average time for other subs from alien data mission at executable if possible.

What is exactly 6-th? mission from Probe to Colony Expansion? or from January to June?
:Yep, 6th month. [[User:Seb76|Seb76]] 20:04, 30 April 2010 (EDT)

what happens after 6-th month June?

I so sorry for reminder and bother you, but don't you know it? ((

== Formules about Retaliation/Floating base attack mission ==

Hi

My great respect to you for you formules
I need few help. I am great thank to you in advance

Now I found alien data missions in TFTD (in a similar in EU ) and I ask generously to you to check 3 your formules in TFTD. Is these same or not?

1. After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours
:Xusilak is more knowledgeable than I concerning TFTD. I cannot help you here... [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

Formule 2 and 3 probably contins mistake. formule 'll have to have symbol > instead symbol <. Otherwise retaliation mission activates more often on Beginner diificulty than Superhuman difficulty. Is is strange.

2. A retaliation mission will be scheduled if RAND()*100 < 4*(24-difficultyLevel).
:There is indeed a mistake there. It's been so long I cannot remember if I got it wrong or just messed it up wikifying it ^^ [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

3. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from. The first UFO is scheduled in 100 half-hours (the value is taken from the table I speak of later at the bottom of this page).

And RND() - what values may has? from 0 to 1 or not?
:When I write RAND()*100, it just means a random number between 0 and 100. [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

I will be very thank for given help

== MISSIONS.DAT formula clarification ==

Hi Seb76. I've been having a discussion with Alexchamp and trying to interpret the formula you mentioned on [[Talk:MISSIONS.DAT]] about retaliation missions being scheduled after a shoot down. Namely: if RAND()*100 < 4*24-difficultyLevel

We mainly need clarification on the logical operator. Should it be less-than or greater-than?

As it reads now, it could be interpreted as though retaliation missions are generated more frequently on the easier levels. But if we treat it as >, then this means that retaliation missions are generated about (Beginner) 4%, 8%, 12%, 16% and (Superhuman) 20% (or 28% for TFTD) of the time on their respect difficulty levels.

If you could clarify that for us it would be great, thanks. - [[User:NKF|NKF]]
:Yep, I goofed up. Don't take everything I say as gold ;-) [[User:Seb76|Seb76]] 14:45, 30 April 2010 (EDT)

And I precise too one '''mainly moment'''. Whether there must be the opened bracket after the sign of multiplication? Because if no, then right interpretation formule in Superhuman example such: Rand*100>4*24=96-6=90 and that means that retaliation mission would be sheduled in 10 cases from 100.
IF there must be opened bracket then rand*100>4*(24-6)=4*18=72 wouid be sheduled in 28 cases from 100
What is this versions is right?

Then needs clarification for second formula yours. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from.
What logical operator there? should it be too greater-than or less-than?

You have found later formules about activation retaliation mission (if we shotdown alien craft)
Where exactly in assembler is subprogram that determines it? What address/offset of it?

== COLONY SUPPLY MISSION ==

As we know, When alien base built, Fleet Supply Cruisers with missions Colony Supply can to arrive to this base.

Where can I see (file/offset)
1) average time to arrive colony supply ship for examle/at least in XCOM-EU. As I said later, in responsible offset is time '''to PRECEDE to ARRIVE NEXT UFO SUB''' '''it's not''' time to arrive this sub
2) real time to wait arriving colony supply ship similarly times in file Missions.dat

According to [http://www.strategycore.co.uk/forums/Colony-Supply-ship-time-to-arrivin-t8103.html&view=findpost&p=96011#entry96011 Colony Supply - time to arriving]

If guesses of NKF is right, we need to formule of probability to arrive Colony Supply ship.
Can you to render courtesy with this formule?

Thank you very very great in advance
:I added details in the LOC.DAT talk page. The supply ship is spawned randomly and starts its mission. There is no "time to first supply ship" that I can see. [[User:Seb76|Seb76]] 15:11, 30 April 2010 (EDT)

Thank tou very much for this clarification. I found this offset in TFTD even. Changed, checked - it works.
You are greatly people!

== Roswell mission bug? ==
Hello, Seb76.

I've just had two consecutive games (meaning, I restarted the application and began a new game) where the same strange behavior occurred.

Both games had Roosevelt mission as the first one. It showed the window (type, terrain, UFO size) as usual. Afterward, whenever I clicked on it (to check mission conditions again), it showed a typical "hyperwave transmission decoded" window, stating race/mission type, etc. Needless to say, I had no decoder at this time, since it happened both times in the first game week.

I have a saved game if you want to take a look at it. It's completely reproducible, at least for me. You just click on the white cross and get this window.

Also, I'm using plain CE version with a "complete UFO patch" from StrategyCore. The saved game was not hacked in any way.

Cheers!
[[User:Rovlad|Rovlad]] 10:08, 30 April 2010 (EDT)
:Hum, I gave it some shots but could not reproduce your problem. Anyone experiencing the same problem? [[User:Seb76|Seb76]] 15:36, 30 April 2010 (EDT)

::Here's the [http://rovlad.nm.ru/GAME_1.zip savegame]. Let me know if it works fine for you. [[User:Rovlad|Rovlad]] 21:47, 30 April 2010 (EDT)
:Looks like the CRAFT.DAT entry is not cleared when a new craft is created and the offset 0x64 could be garbage till the craft is detected by a base/another ship. Since I bypass the detection when "crashing" a UFO, it is possible the "HWD detected" flag is set randomly, producing a full report. I'll clear the bit and we'll see if it corrects the issue, just wait for the next release. Thanks for providing the savegame BTW. [[User:Seb76|Seb76]] 14:22, 5 May 2010 (EDT)
::You're more than welcome. Fantastic job on the extender, keep up the good work. [[User:Rovlad|Rovlad]] 19:04, 5 May 2010 (EDT)

== ALIEN RACE SPAWN ==

Your post: In EU, the race is based off a lookup table starting at offset 0x46E53C (containing 300 entries).

Offset-0x46E53C is absent. Is one symbol odd?

Your posr:The table is made up of 10 entries lines.

It means that this bit of array has 10 rows width of 30 bytes. is right?

What is means this 10 entries lines? Can you copy 2-3 lines from exe and explain that means known for you offsets in line?As simiilarly as you done for alien data mission in file Missions.dat
Can you get more particularly answer about values it this array?(naturally if know it)
:0x46E53C is the address in memory. In the file it should be 0x6E53C (UFO Gold edition).
:The begining starts like this:
.data:0046E53C byte_46E53C db 0, 0, 0, 0, 0, 0, 0, 1, 4, 4 ; 0
.data:0046E53C ; DATA XREF: CreateAlienMission+15B�r
.data:0046E546 db 0, 0, 0, 0, 0, 1, 1, 4, 4, 4 ; 0
.data:0046E550 db 0, 0, 0, 0, 0, 0, 4, 4, 4, 4 ; 0
.data:0046E55A db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E564 db 0, 0, 0, 1, 1, 4, 4, 4, 4, 4 ; 0
.data:0046E56E RaceForTerrorMission db 0, 0, 0, 4, 4, 4, 4, 4, 4, 4 ; 0
.data:0046E56E ; DATA XREF: GeoPerformMonthlyActions+15E�r
.data:0046E578 db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E582 db 0, 0, 0, 0, 0, 0, 1, 4, 4, 4 ; 0
:till the end:
.data:0046E67C db 0, 1, 1, 2, 2, 2, 3, 3, 2, 4 ; 0
.data:0046E686 db 0, 0, 1, 1, 1, 2, 2, 3, 3, 4 ; 0
.data:0046E690 db 0, 1, 2, 2, 2, 2, 3, 3, 4, 4 ; 0
:As you can see, at the begining you'll get tons of sectoids (0), a few floaters (4) and even less snakemen (1).
:At the end, you'll get ethereals (2) one time out of two. Also note that for terror missions, the line is taken a bit farther than normal missions, which means that you'll get stronger aliens sooner in terror missions. HTH, [[User:Seb76|Seb76]] 13:36, 5 May 2010 (EDT)

Thank you greatly for your detailed answer ...
I want a few more precise ...
I right understand? I guessed That line 1 - is used for January mission Research? Line 2 - Jan Harvest? Line 3- Jan-Abduction Line 6- January Terror?
What define Line 7?
Line 8 - is February Research?

According to - Line 13 -Feb terror? Line 20 - March terror? Line 27 -April Terror? Line 34- May terror? that sequence and guesses is right?

And question 2) does affect score to choose the value among values in line? How differ choose values in line at the level superhuman and level beginner ?
If you know, naturally, I would be greatly thanks to you for this wonderful magic help.

== Research tree in executable ==

Do you know location (starting offset) of research tree in EU? and how much entries it contains ? and what means values within this array?

Very great thank in advance for this help to you
:The research tree is not stored as a data array but is a hardcoded sequence of "if this is already researched and that is also researched and such item is in the inventory, then enable this research". Modding this would require a complete reengineering, not just patching. Still feasible though. [[User:Seb76|Seb76]] 13:25, 5 May 2010 (EDT)

What is starting offset (ce version) of this hardcoded sequence? and what is latest offset of it? what is length of one sequence? If possible -what is structure of it briefly? (how much bytes to tech requirements, how much bytes to items requrements)

Thank you for this help '''VERY VERY GREAT'''
:As I said, there are no *sequences* but just a cascade of hardcoded ifs:
:[[Image:Research.png]]
:If you want to take a look, the function begins at address 0x446A0. [[User:Seb76|Seb76]] 07:28, 24 May 2010 (EDT)
'''
Seb76, you are GREAT GENIUS!!!! GREATLY RESPECT FOR YOU!!! THANKS FOR YOU VERY VERY MUCH!!!'''
I have found research tree in TFTD too with your help. Now I can do some changes in it.
Maybe do you know, how can I find subprogram that run 1-st day of any month in assembler code of game?
This subprogram determines new mission's month and terror ship route (in TFTD)
There is not in EU terror ship route, I know. But If you know and tell me - what is subprogram in EU that runs 1-st day of any month, I would be able to edit probability of terror ship route in TFTD.
Greatly thanks in advance to you dear Seb76!
:In EU, monthly actions start here:
.text:0043B9B0 GeoPerformMonthlyActions proc near ; CODE XREF: GeoIncrementDayAndDoMonthlyActions:loc_4420C1�j
:HTH, [[User:Seb76|Seb76]] 16:31, 28 May 2010 (EDT)

== Any way to slow down geoscape time? ==

Is there any way to slow down geoscape time progression on fast computers, esp. multiprocessor ones, where it is impossible to significantly slow it down using utilites like MoSlo and Turbo?--[[User:AVE|AVE]] 03:01, 5 May 2010 (EDT)
:Did you try enabling D3D? If you're drivers are configured to wait VSync, it should limit the game speed (well, if you use a CRT@120Hz it'll still be too fast I guess...). Also is it still too fast if you put it windowed? (enabling both D3D and D3D Windowed options) [[User:Seb76|Seb76]] 13:19, 5 May 2010 (EDT)
::Yes, both D3D and D3D Windowed are enabled. This is even more surprising, because it shows the same results on two different computers (Dual Core one and simple P4Celeron) with different video cards (NVidia and ATI). Both have vsync explicitly enabled. LCD@60Hz both. Also I've tried to use different combinations of Video Pitch, D3D, D3DWin and HQ4x settings - no luck. [[User:AVE|AVE]] 04:20, 6 May 2010 (EDT)
:Personally I've never been able to reproduce this "CE game running too fast" thing people keep harping on about. Perhaps I just have a different perception as to what "too fast" means.

:Anyways, I know [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's patched executable] includes a timer hack for the Geoscape, but I found that makes it run far too slow for my taste. Not sure off the top of my head whether it works with Seb's loader, either - you'd probably need to at the very least need to rename Mok's executable to replace the original in order to try it that way. - [[User:Bomb Bloke|Bomb Bloke]] 05:14, 6 May 2010 (EDT)

== Some problem with edit research tree ==

I want to add new 20-30 commands to research tree. I wrote this subprogram. How can I add it to game?
I tried to write "call sub" instead useless 5 bytes in subrogram research tree. I checked in IDA after it, all other commands is preserved.
And I placed my new subprogram after latest byte of executable file. But game is crashed.
I tried to place my new subprogram after all subprograms and before first byte of idata, but game is crashed too.
All indexes in subprogram was exactly.
in second case IDA displayed "sp-analysis failed".

Where and how can I placed my new subprogram that will be addition to current subpogram research tree?
:To add new code, you need to modify the PE header of the exe file accordingly. I'm not quite knowledgeable regarding the procedure (that's one of the reasons why I made a loader instead of patching the file directly) so you're gonna have to find help somewhere else on this one. [[User:Seb76|Seb76]] 16:36, 28 May 2010 (EDT)

== Update to IDA database ==

Hey again Seb76 :)

After a long time I've come back to your extender, dusted off my copy of VC Express, and decided I'd have another go at doing some UFO modding (don't ask how the first attempt went; it's not pretty! :p )

I'm assuming you've probably updated the IDA database since last time I asked. Would be extremely grateful if I could get the latest version.

Thanks for all the hard work, staring at assembly code all day is no joke! --[[User:K9wazere|K9wazere]] 18:07, 6 June 2010 (EDT)

Arf, didn't realise I could send you an email, so this new section on your talk page is a bit redundant now :p Oh well, maybe someone else will want the file too!

== Line of Sight Origin Points ==

Hiya.

A while back you mentioned the co-ords for the [[User talk:Bomb Bloke:Firing Accuracy#Firing Point Origin|firing point origin]]. The zpos is calculated according to the unit's effective height, and the x/ypos co-ords come from look-up tables depending on which way the unit is facing.

I was wondering, are these same two tables used for the purpose of line of ''sight?'' And by any chance could you find the formula for the initial LOS zpos?

Any help would be appreciated, as usual. There are many other obvious questions around this issue (such as where the ''end'' point for these lines is), though the origin would be a good start. - [[User:Bomb Bloke|Bomb Bloke]] 07:44, 24 June 2010 (EDT)

== Training Stat Request ==

Hi there.

In the Equipment screen where the Weight and TUs are displayed during battle, would it be possible to also include the current unit's number of Reaction shots, Hits, Psi attempts and (possibly) Throws? Possibly along the bottom in a horizontal string where there's room?

User talk:Seb76

2011-03-30T09:07:40Z

Mannon: /* UFOloader and Xcomutil */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

My problem is the following: if I try to run the loader normally, a console window pops up for a few seconds then I get an "illegal instruction" error from NTVDM (and the window disappears, yet it's button remains on the taskbar until I kill the process). If I try to run it with DosBox however, I get "illegal command: UFOLOADER.EXE". Point is, I can't run this at all.--[[User:Amitakartok|amitakartok]] 11:27, 13 October 2009 (EDT)
:Looks like you're trying to use the DOS version here. Only the CE (windows) version is supported. [[User:Seb76|Seb76]] 13:48, 13 October 2009 (EDT)

Hi, is it in any way possilbe to run the Extender in Win98? I just set up an old machine with it and wanted to give it a try but as you said above, it won't work with Win9x. But is there a way to manually mod the game? I am asking becaus on my WinXP Machine the game often crahes in battlescape and that really sucks =(--[[User:Skaw847|Skaw847]] 19:28, 21 May 2010 (EDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)
:::I for one am a huge fan of XcomUtil, though I'm now also a huge fan of UFO Extender! I'm really hoping I can get the two to play nice. I was up until now playing a dos version, myself. Mainly because the version I bought years and years ago was the DOS version on CD and it still worked via dosbox, which also has several filters similar to your HQ4x. (Some run a little faster and I think they can run in a window while I can't get HQ4x to run windowed at all. I don't mind that so much, though the game runs noticeably slower when I run HQ4x and I prefer to run windowed these days so I can more easily multitask. Still I LOVE UFO Extender so I switched to the Windows version just for this.) Some of XcomUtil's features only work in the DOS version with split exe's because it goes back into the batch file and allows XcomUtil to play with things when switching from Geoscape to Battlescape and vice versa. But, it's not that big a deal for me. UFO Loader's feature list is more than robust enough to give that up. As for the sounds the Windows CE versions changed a lot of the sound effects. If you're used to this version then it's Np, but if you played the DOS version and got used to it then it's VERY off putting. Luckily it's easy to patch it back to the DOS sound effects. The "Enemy Unknown Extended" page here lays out an install that includes UFO Extender, the original DOS sounds, ect... It's a good place to start. Anyway, great tool. Now let's see if I can get these to play nice.[[User:Mannon|Mannon]] 04:40, 27 March 2011 (EDT) (I keep forgetting to sign things... too used to forums instead of discussion pages.)
::::Facinatingly XcomUtil actually DOES split the CE's executable into geoscape.exe and tactical.exe! It uses it's own sdump utility to do this during the setup batch file. I misread the above. XcomUtil splits them to preserve it's fuctionality so that it can use the batch file to knit them together like in the original DOS version and insert it's own exe into the mix. This does not make the windows exe run in DOS of course, but it does allow XcomUtil to keep it's functionality. I have to assume it really screws up UFO Extender, though... ;-( [[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)

Decided to look into this as there are a few XcomUtil features I like that aren't reproduced in UFO Extender. XCU does indeed split the exe. It also modifies both of the split exe's. It still loads both via fodder's loader when running them from the batch file. The command lines for that are "start /w xcloader geoscape.exe "0"" and start /w xcloader tactical.exe "1". Replacing xcloader with UFO Loader appears to work for tactical. The command line even appears to point UFO loader to the tactical exe since going into combat causes a problem. If I change the first xcloader call to "start /w xcloader" then the renamed UFO Loader finds the unsplit exe. Going into combat no longer fails like this, but it also prevents XcomUtil from running between phases. This does not prevent the running of XCU completely, but it will cause problems with some features, especially in the placement of soldiers in the new craft maps that XCU adds. Then again, by using the UFO Loader to use the original unsplit exe I believe that you are also bypassing all of XCU's modifications to the exe's as it probably does all those modifications to the geoscape and tactical exe's it created when splitting the exe. It may be possible to recombine those exe's or to find command line parameters that allow UFO Loader to load tactical.exe on it's own. The latter would probably be the best solution since it should allow XCU to function between phases.[[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)
:Splitting of the exe is accomplished by first simply copying it with both of the destination filenames. Then sdump is run on each one using settings from XcomUtil.cfg to essentially transform each one into the geoscape only and battlescape only versions. The settings are available in the cfg, but not documented so I don't really understand them. Though... it is actually starting to make some sense as I compare the cfg to the sdump documentation in XcomUtil.txt. Seems like it would be possible to reverse the patch, though it might require first extracting the correct data from the unsplit version. Note: The split up geoscape.exe and tactical.exe are exactly the same size as the original ufo defense.exe, thus data was not removed by sdump, merely changed. I think the only change needed were to cause geoscape.exe to exit at the right time instead of going immediately to the battlescape, and for tactical.exe to go directly to battlescape loading the mission data like the old DOS version.[[User:Mannon|Mannon]] 22:01, 29 March 2011 (EDT)
::I believe that I have managed to get XcomUtil and UFO Extenter at least working together with a kludge. My method involves using modified versions of XcuSetup.bat and RunXcomW.bat and the creation of a new exe, (to avoid overwriting the original and keep it as a backup). RunXcomW.bat is changed to point to UFOLoader.exe instead of xcloader.exe and points UFOLoader at the new exe UFOmerge.exe. The second call of xcloader which normally initiates the battlescape has been simply disabled as it will never occur under my setup. The changes to XcuSetup.bat are also pretty simple. I allow it to copy the UFO exe into geoscape and tactical because XcomUtil.exe will only modify these exe's. But I disable the patching done to each via sdump which turns them into independent phases of the game. Then in every instance where XcuSetup calls XcomUtil to make a change to the exe's I insert a line after it that uses sdump to merge those exe's back into UFOmerge.exe. Viola! Theoretically this should allow XcomUtil to modify the UFO exe while still allowing UFO Extender to make it's own changes. However... Not all XcomUtil functions will work and some of them will flat out break because it cannot be called when switching phases of the game. So, for example, if you use the larger craft XCU includes then you could be in trouble since XCU cannot be run to place your soldiers properly. I suggest you stick to the normal number of soldiers each craft can carry. If I knew a way to make UFOLoader.exe compatible with tactical.exe then it should be possible to have full functionality. It actually works perfectly fine with geoscape.exe. Seb76, if you're around anymore I can provide you with exactly which bytes are altered in tactical.exe for both UFO and TFTD as they are in XcomUtil.cfg. After looking at the sdump documentation it's actually pretty straitforward. It basically uses hex numbers as commands specifying goto this address, write the next X bytes, skip the next X bytes, ect... I'll make my modified XcomUtil files available on my page if anybody asks for them. Now... to figure out how to disable the XcomUtil base disjoint bug fix. lol I think I'd prefer the UFO Extender fix, and I like having the option to leave the bug in place and use it for tactical options.[[User:Mannon|Mannon]] 05:07, 30 March 2011 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Could we get TUs (in current/max format) at the inventory screen while on a mission? It would greatly help with swapping weapons among soldiers.

* Could we get little numbers [like on the screenshot of accuracy mod] showing how much TUs an action on the inventory screen would take? Some players (me, of course, included) can't really remember all that reloading from backpack or from a leg slot TUs. Also...

* a "drop all" button, maybe?

* Soldiers' positioning in Skyranger is very good... but with the Avenger it is not so pretty. The ones at the top are not the ones closest to the trap door. Chooseable patterns, maybe?

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.
: '''Save Equipment''' is under development, still some bugs

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
** Eliminate "infinite fuel" exploit for conventional aircraft.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

* Enable native alien melee attacks within Alien Pets. The Floaters are pleading. (At the moment, Alien Pets+Big Brother means a crashed Superhuman Floater Large Scout costs 6-8 X-COM agents; corresponding crashed Sectoid Superhuman Large Scout is only worth 3-5 X-COM agents. Floater Large Terror Ship on just Big Brother : only one agent, and that was due to the top-of-stair pinning bug providing enough TU to do something.) -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Do something to help out the psi aliens as well within Alien Pets, as above. -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Would it be possible to change the master volume level in the game, or at least have a no sound option? [[User:Epiceuropean|Epiceuropean]] 00:26, 12 January 2010 (EST)

=== A few more ===

Do any of these take your fancy:

* Draw the Radar detection radii onto the map as a circle(s) around the base (also for moving aircraft?)

* Show All UFOs (Ultrawave Detector - like Show All Locations, but doesn't show Alien Bases, you still have to hunt for those).

* Sensible Ammo Recovery = add up all remaining rounds of ammunition at the end of a mission (in the ship, if Aborting), and recover a number of (full) clips equal to that number divided by the clip capacity (rounded down maybe).
: There's a reason I didn't turn Clip Recovery on, and it's that I guessed that it didn't work exactly as it's suggested here. If it did work like this, I would use it. [[User:Stubbs|Stubbs]]

* Implement tactical time limits for UFO Assaults/Recoveries. After a random period (within a pre-defined upper and lower time limit), the aliens leave. Pop up warnings appear at the end of each turn, saying the UFO engines are powering up. When the aliens leave, all aliens/items/equipment inside the UFO is gone - no loot, no score. Any soldiers still inside the UFO are considered MIA. The soldiers are ''captured'' in fact - score penalty worse than MIA? There must be one conscious alien inside the UFO for it to leave or attempt to leave. Maybe any live aliens outside are 'beamed' or 'tractored' inside the UFO, complete with their equipment? (E.g. the mission ends and you don't get score for them or their equipment either - just for the corpses and dropped loot).

* No Milk Please: After XCom withdraws from an Alien Base, randomise the base's location and make it hidden again. Just like what happens to the aliens after they fail to assault an X-Com base. Though you would probably still need to locate it within the same country or region so finding it again wouldn't take long I guess. Would it mess things up to move the base to a random part of the world?

* [[User:Spike#Tank mods|Tank Armour and Equipment Mods]]

But I should probably code this up myself, looking at your source code it doesn't look '''too''' hard. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

[[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

* Burning Zombies

It's more or less impossible to prevent Zombies from hatching into Chryssalids by killing the Zombies with fire, since fire does such a small amount of damage, and the requirement is that the actual killing point of damage is done by an incendiary. Apart from hitting them with an incendiary and running away, then waiting about ten turns for them to die (probably repeating the attack once or twice), this is only ever going to happen by blind luck.

It would be much more viable if the rule was (also?) that a Zombie which is '''on fire''' at the time of death would not hatch into a Chryssalid. This is not exactly easy either, but it is at least possible. It requires hitting the Zombie repeatedly with incendiary weapons until it catches on fire, then killing it right away with regular weapons (before the fire goes out).

A much easier version of this approach would be to say that if the Zombie is killed while it is '''in fire''', it does not hatch. But that is probably too easy.

A way to do this by hacking game files, without code changes, would be to increase the Zombie susceptibility to fire, to 200%. This would make incendiary weapons a viable way of killing them, as well as increasing the likelihood that the killing shot was an incendiary shot.

An alternative approach would be for the Zombie to have a chance of not turning into a Chryssalid, proportional to the percentage of health damage that had been caused by incendiaries. But that's probably too hard to track, it would require an extra/unused field in UNITREF.DAT.

[[User:Spike|Spike]] 13:12, 7 September 2009 (EDT)

* Fear of Fire

Apparently there is no morale effect from [[Incendiary#Damage|Incendiary damage]]. If anything, for humans, and maybe be for other humanoid aliens, fire should probably have a greater morale effect than ordinary damage, not none. A basic fix would treat fire damage the same as normal damage when reducing morale. A more complicated fix could add a weighting to this morale effect: multiply by the creatures susceptibility to fire (or reduce by its resistance to fire). Any creature or soldier that is immune to fire should not have its morale affected. Actually the affects of fire vary quite a lot (different aliens, different human armour types). Maybe this is why the designers didn't get around to implementing morale effects for fire, as it's a bit complicated.

[[User:Spike|Spike]] 13:40, 7 September 2009 (EDT)

=== Multi Stage Missions ===

Between each stage of a multi-stage mission:

* Send all artefacts (non-usable items), corpses and recoverables back to base
* If possible, remember the score for these items, and apply it to the score at the end of the mission
* Alternatively, pop up a score window between the mission stages, and apply the score then?
* Gather all loose usable equipment into the "equipment pile" for the next stage
* Or possibly re-run the Equip Screen between mission stages, again gathering all loose usable items into the equipment pile first.
* Keep an 80 item limit on what you can take into the next stage
* Prune down to the 80 item limit using some sensible rules, not sure what exactly.

This is of limited use in X-Com EU but would be much more use for TFTD, one day. EU has only one multi stage mission, and it ends the game, so only some of these points above will be relevant.

[[User:Spike|Spike]] 20:54, 2 September 2009 (EDT)

=== Even More ===

Tremendous work, you've pretty much made the game worth playing again. Best work since Xcomutil. As with everone else, I have a few requests. [[User:KingMob4313|KingMob4313]] 23:59, 12 August 2009 (EDT)

: Ability to change damage modifier. Right now the damage runs from 0-200% of damage values on the weapon. I'd love to see a way to change it to 50-150%, 75-125% or the like.

: A modifier to increase or decrease the explosion radius modifier. Right now the radius is either keyed to the explosive or to the explosive damage. I'll investigate it further. But it would be nice to have a very small radius, but high powered explosive for use as a breaching charge.
:: There is a "crimping" function on some of the explosions already so it might be possible to exploit that. Check the [[Explosions]] page. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

: A modification of the range based accuracy. One handed weapons have a shorter range, to the point that even their aimed shots have an effective range, two handed weapons have a further range (and no aimed shot effective range) and really heavy two handed weapons have an even further range.

: Ability to enable the Burst fire (5 shots over 3 picked spots) and/or the full auto mod that is on the heavy laser on other weapons (set by a flag).

: A modification so that on the alien's side first turn, they do not have their full time units in reserve for reaction fire. Nothing like getting shot 3 times from the same sectiod after missing ONE shot on them.

:: You could always wait a turn before you open the door. :) [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

::: Good point, I should be doing that anyways.

=== More Exploits to Close ===

* [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]

Probably the worst single exploit in the game. What is needed is to disable any mind control actions for a Psi Amp, if the unit holding the Psi Amp is currently mind controlled.

Also a general mind control bug/exploit fix for:

* [[Exploiting Mind Control#Exponential Mind Control|Civilian Traitors]]
* [[Exploiting Mind Control#Exponential Mind Control|Resurrect Zombified Agents]]
* [[Exploiting Mind Control#Exponential Mind Control|Zombie's Permanent Control of Aliens via Stunning]]
: Above 3 bugs are fixed by '''Hostile Civilians''' fix.

* Probably many other missing/MIA-type bugs

These probably all arise from the daft decision to save a single byte (or even bit), by not recording separately the current vs default "side" a unit is on. The game only tracks the "current side". Consequently when mind control ends, the game often makes dumb decisions as to what side to "restore" the unit to. We could use an unused byte to track the default "side", but that would require overloading a presumed "unused" field and that could be risky. But actually we can always deduce the "default side" from the unit type: XCom for soldiers and tanks, Neutral for Civilians, Alien for everything else. So what is needed is just an end-of-turn check to restore everything to its correct side, based on its unit type. Actually it's slightly complicated by alternating turns. You need to update all (originally) Alien units at the end of the Alien turn, all originally XCom units at the end of the XCom turn. You might also need a special end-of-game update, to avoid the MIA-type bugs. [[User:Spike|Spike]] 12:22, 26 August 2009 (EDT)

: AlienSWP.py implements turnswapping via mind control, like XCOMUtil. Handling the alternating turns, as you described, is necessary to make mind control work properly (a mind-controlled alien remains with X-COM during the alien turn, and so on).

: I would assume that the original programming team had a coding policy forbidding both bitfields, and emulating them with bitwise shifts. That's really the only way I can explain most of the idiosyncrasies of the file format. [[User:Zaimoni|Zaimoni]] 12:07, 26 August 2009 (CDT)

=== Soldier Colouration ===

Not the most "practical" request in terms of changes to gameplay, but still something I feel would be pretty cool if incorporated. Basically, the option to have the battlescape engine display soldiers according to their race/hair colour, as according to their inventory screens, [http://www.strategycore.co.uk/forums/post-a1669-.html like this].

The stored tactical [[PALETTES.DAT|palette]] is made up of 16 groups of 16 colours (256 total), in this order (though the last 16 colours are replaced with a grey-scale shade list at run-time, similar to the other fifteen groups - refer to the page on palette data for more info on that):

[[image:5_BattleScapePal.Png|center|frame]]

Solders are drawn using colours from three of these groups: One for their clothing (x50-x5F for overalls/power armor, xE0-xEF for personal armor), one for their skin (x60-x6F), and one for their hair (x90-x9F). Flying suits use a few extra colours, but they don't matter for the sake of this explanation (they don't show hair/skin anyways).

With my [http://www.strategycore.co.uk/files/index.php?dlid=686 battlescape editor] I incorporated a feature where you could have the program redraw units on the fly (as per the screen shot), changing just the hair/skin colour. For example, to check to see if a colour index was supposed to represent hair, it simply checks if "(''value'' & xF0) == x90", and if so, it'd add or subtract a certain figure to achieve the desired colour.

Well, there's a bit more to it then that (males in personal armor have a different hair colour already), but I'm sure the basic concept is obvious to you by this point. If you're interested, you can see a sample function in a file included in my toolkit - "bb_tact\UnitDrawer.java", line 384. It's not exactly well documented, but if you check the hair/skin arrays it refers to, it should be fairly obvious what it does. While the program is running, the "characteristics" variable is set to "true" by tapping C on your keyboard. Of course, I've no idea how the actual game deals with drawing soldiers, but I assume it decompresses every [[Image_Formats#PCK|PCK]] image every time it wants to draw it, same as my code does.

- [[User:Bomb Bloke|Bomb Bloke]] 09:46, 4 May 2010 (EDT)

=== See Also ===

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

== Completed Items - Thanks Seb! ==

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

* More video options. In particular, an option to put padding at the top and the bottom of the screen to preserve the aspect ratio on a 4:3 monitor. Maybe it's just me, but stretching the original height of the game to fit a 4:3 screen makes the Battlescape look weird. (Actually, if you update the source code link, I could try to do it myself. The current source doesn't seem to include your more recent changes. --[[User:Mikawo|Mikawo]] 20:30, 12 August 2009 (EDT))
** Thanks for uploading the new source code. I managed to add the letterboxing that I wanted. If you wanted to make it an official feature I could upload the updated files. And I don't think I said this before, but thanks for the great loader! --[[User:Mikawo|Mikawo]] 18:40, 14 August 2009 (EDT)
:Go ahead and upload/PM me the file (d3d.cpp I presume?), I'll gladly incorporate your modification. [[User:Seb76|Seb76]] 19:14, 14 August 2009 (EDT)

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

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

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

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

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

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

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."
:The above works perfectly. [[User:KingMob4313|KingMob4313]] 00:05, 13 August 2009 (EDT)

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.
:Fixed via Keyboard Shortcuts - and configurable too.
-- Sorry, I am having trouble finding this addition. Is it in the newest version? I can't see where to configure it if so.

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....
Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)
:I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that 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?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human 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?

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).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
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!
:I think this is a known issue with LOS, not sure though
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).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

There are major issues with your current weight calculations. I'm not exactly sure how it was occurring, but repeatedly messing around unloading and loading weapons, switching clips from the ground them putting them back in... at least one of these functions causes 'phantom weight' to be added to the soldier (e.g. strip them bare and they are still carrying a load). This was happening by 3 units of weight at a time; the weight of a clip. It's so bad that I managed to get 18 phantom weight units on a soldier before getting bored. Occasionally, 3 units of phantom weight would be removed again! It's hard to tell if this was in the original game, due to the lack of weight display in the inventory screen.

Edit: I've worked out what's happening. Add a loaded weapon to a soldier, unload it, and remove the ammo and gun: this ''removes'' 3 phantom weight units. But, add an unloaded weapon to a solider and load it... this ''adds'' 3 phantom weight units. [[User:Stubbs|Stubbs]]
:This is a genuine bug because they forgot to unassign the clip of a weapon when you drop it. Also the default weapon's clip is not initially assigned to the wearer so if you unload and reload the clip, your soldier weights more. [[User:Seb76|Seb76]] 13:27, 3 February 2010 (EST)
:: So is this impossible for you to override and fix? It's really irritating... I've edited lots of item weights, but I guess I'd have to make ammo light and guns heavy to minimize the effects of this bug. [[User:Stubbs|Stubbs]]
:::I second that, it would be great if this could be fixed. [[User:Rovlad|Rovlad]] 17:45, 13 May 2010 (EDT)

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

:: Alien reaction fire works fine for me within Alien Pets. -- [[User:Zaimoni|Zaimoni]] 12:41, August 12 2009 (CDT)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)
:Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)

The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. <3
:Uploaded a new version, you need to add a "HQ4x=1" line under the "Mod" section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)

Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)

Now the question is, how do you use DXWnd with the loader?
[[User:KingMob4313|KingMob4313]] 11:02, 12 August 2009 (EDT)

==Works but won't multitask==

Target system: prefab HP Vista with global data execution prevention. Problem is the same native, with D3D, and/or with HQ4X. (The two do combine nicely, visually, but a bit laggy for my tastes).

ALT-TAB terminates all further screen display on restore; the sea of blackness continues until Task Manager is used to kill the application, at which point D3D admits that it has "lost the device". (This is after the improved error reporting patch. Before, 0xc0000005 as Data Execution Prevention takes over.)

-- [[User:Zaimoni|Zaimoni]] 12:27, 12 August 2009 (CDT)

: Solved on Win7 for the most recent version: Program Properties dialog has an "unblock" button. Unblocking allows the program to survive being alt-tabbed away from. -- [[User:Zaimoni|Zaimoni]] 22:03, 24 June 2010 (CDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)
:That's great ;-) By dev I was refering to the "dev" version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)

Hi Seb, I've been playing the UFO series since the beginning but just joined this wiki. I've tried just about every mod there is for these games, and I must say, yours is one of the best as far as creating a "more complete" and stimulating game experience. My question is in regards to your "Heavy Laser" mod. I liked what you did by creating new "abilities" for the weapon with the Full auto and Burst fire mode, but every time I play I can't help but think that it just doesn't belong to the Heavy Laser as a weapon. I always envisioned the Heavy Laser as more of a long range "Sniper" support weapon, and I like the mod that the X-ComUtil added that gave the Heavy Laser a new life by increasing the accuracy and damage of the weapon making it one of the best Sniper weapons available (even if it is heavy to lug around) as well as finaly giving my troops a greatly needed new weapon for disposing of those pesky sectopods (on any difficulty). I do, however, think that the new fire modes (full auto and burst fire) would be a perfect addition to the Auto-Cannon. The in game image alone has always brought to mind a "mini-gun" type weapon that should be capable of very rapid fire, but at the expense of accuracy due to the encumbering nature of the beastly AC. I never liked how the AC seemed like a generic Heavy Cannon with less damage and only the added auto shot function. Also, I always wondered why that weapon even had an "Aim" function. Who's going to sit there trying to carefully aim a Gatling Gun? Nobody... that's who, you use a weapon like that for mass devistation and shock value, PERIOD! This is why I think that your mod to the Heavy Laser should be reconsidered for the Auto-Cannon. I think, at the very least, it will give people a reason to use the AC in the mid to late portion of the game, and being that it still has weak stats compaired to other weapons, it's not going to be overpowered or infringe on the use of specialty weapons (I think the Heavy Laser with full auto and burst fire is a little un-balanced due to its considerably higher power). If you don't agree that's fine, but since I'm not very knowledgeable about game programing, I was wondering if you could at least give me a hint on how to create similar weapon functions for other weapons, cause I'd like to at least try it out for myself. Thanks for any help you can give me and keep up the good work, you're mod is awesome.

== REng UFO with IDA ==

Hi Seb =)

I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.

So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).

Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.

I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.

My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).

Any advice is deeply appreciated mate =)

XCom forever!
--[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)
:Hi k9,
:Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.
:For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...
:Good luck with your project,
:[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)

:::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...

void InsertCall(int dst, void *func)
{
DWORD oldProtect;
DWORD *pOffset=(DWORD *)(((char *)dst)+1);

VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&oldProtect);
*(char *)dst=(char)0xE8;
*pOffset=(int)func-(int)dst-5;
VirtualProtect((void *)dst,5,oldProtect,&oldProtect);
}

::: This calculation here is interesting:

*pOffset=(int)func-(int)dst-5;

:::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).
:The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).
:The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)

:::Can you suggest some good reading material to better understand this? Cheers!
:::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)
:You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the "UFO Defense" process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)

== D3D ==

If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has.

I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)
:You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)

Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)

OK I ran the dxdiag utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)
:Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.
:Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)
Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)

D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J'ordos]] 19:09, 8 August 2009 (EDT)
:edit: forgot to mention, I have directx 9.0c installed and dxdiag reports no problems. I have a Geforce2 MX *blushes*
:Do you know if this card supports non power of two textures? [[User:Seb76|Seb76]] 05:10, 9 August 2009 (EDT)
::no idea, but since your new version works fine with the D3D option on I assume it doesn't :) [[User:J'ordos|J'ordos]] 11:38, 9 August 2009 (EDT)
:That's great. Spike, does it fix your problems too? [[User:Seb76|Seb76]] 16:04, 9 August 2009 (EDT)
::Sorry for the late reply - yes that fixes my problems too, D3D is working fine now. Thanks, [[User:Spike|Spike]] 15:55, 26 August 2009 (EDT)

== Save equipment ==

Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:

*1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of "invisible" equipment!
*Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips.
*The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.
*Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment.

Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked?

Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)
:Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.
:The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?
:As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.
:I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)
::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a "before" and "after". [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)
:In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)
::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns & ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)
:OK, I'll have a look at this, thanks for the effort.
:Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the "i/b" one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)
::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)
::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)
::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)
:I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)
:: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)
:Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)
::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)

Hmm more problems with Save Equipment. Ammo of all types seems to disappear. Eg I have 6 pistols and 6 pistol clips on the craft, but the Equip screen just gives me 6 empty pistols. Other weapons are short of ammo too. Is the Save feature perhaps "remembering" empty weapons (or loaded weapons) and somehow eliminating the clips. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)
:This looks like an issue with ''UnloadClips''(). I noticed that the clip object's ''loaded_into'' is set to 0xff, but the ''not_loaded'' remains as 0. The game may see this as the clip still being loaded in an object, so the clip effectively disappears. --[[User:Mikawo|Mikawo]] 11:05, 19 August 2009 (EDT)
::This is possible. The wiki is wrong on these 2 fields BTW: it is in fact just one field (loaded_into signed extended to 16bit). I'll have a look at that. [[User:Seb76|Seb76]] 14:33, 19 August 2009 (EDT)

I think Mikawo is right. UnloadClips() should look something like this:

void UnloadClips()
{
obpos_dat *pObPos=pObpos_dat;

for(unsigned char i=0;i<170;i++)
{
if(pObPos->itemType != 0xff && pObPos->not_loaded == 0 && IsXComItem(i))
{
pObPos->loaded_into=0xff;
<big>'''pObPos->not_loaded=0xff;'''</big>
}
pObPos++;
}
}

Quite a few other functions in '''equipment.cpp''' use this check '''pObPos->not_loaded == 0xff''' so it is important to set this flag just for UFOExtender, regardless of whether the game needs it set (which it probably does). Eg items unloaded by UnloadClips will thereafter fail to be found by GetFreeItem, during execution of LoadSoldierEquipment. That probably explains the problems observed.
[[User:Spike|Spike]] 15:24, 26 August 2009 (EDT)

:I did some rework based on that. Do you have other problems? [[User:Seb76|Seb76]] 16:08, 30 August 2009 (EDT)

::Thanks Seb. This seems to be working mostly ok now. Some remaining smaller issues I have seen:

::* The weight calculation is so accurate, it is more accurate than the unmodified game. So the "weight free ammo" (the first clip loaded into a weapon, before the user takes any action in the Equip screen) is no longer weight free. Not sure if you want to "fix" this or not? It is debatable. Really, you have fixed a bug. But the normal game behaviour has changed. Maybe make the "weight free ammo" optional?
::* There is a weird glitch. If I unload a weapon, put it and the clip on the ground seperately, that works fine. But if I pick up the clip '''directly from the ground''' and load it straight into the weapon, then drop the weapon, the weight of the clip is still shown on the soldier. And actually the same thing happens with a clip that is first moved into the soldier's equipment. So in fact the problem is that a clip loaded into a weapon, doesn't get removed from the soldier weight when the weapon is dropped onto the ground. It happens even if the clip is pre-loaded by your routine.
::* Still outstanding - you can't use the right arrow to move onto a second screen of equipment. So you can't have more than one screenload of equipment on the ground. Or maybe you can, if you start the Equip screen with more than one screenload on the ground - I didn't check that.

::[[User:Spike|Spike]] 13:10, 1 September 2009 (EDT)

== Glitch with Alien Pets and Big Brother? ==

Hi Seb. I was trying to do some initial research on the idea of [[User:Spike#Tank mods|Tank mods]] but it looked like these 2 useful features of your Loader, Alien Pets and Big Brother, have both stopped working. Can you test this, on the latest version? I'm using a very recent version (last 2 weeks) but not the absolute latest as I have internet download problems.

Also, have you seen this new Wiki article: [[Enemy Unknown Extended]]. It is a package including your loader plus a few other odds and ends.

cheers,
[[User:Spike|Spike]] 11:16, 17 August 2009 (EDT)
:My mistake, I commented out that part of code a while ago and only recently noticed that. It was corrected one or two versions ago.
:The article is a good idea, it should allow less techies an easy start. [[User:Seb76|Seb76]] 13:51, 17 August 2009 (EDT)
:: OK cool yes the Hacks are back in place, thanks. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)

== Alien Bleeding ==

Test results:

* 1-unit and 4-unit aliens can be healed by anyone (alien or human) holding a Medkit
* 4-unit aliens can be healed by standing in any of their 4 squares
* 4-unit aliens can only be healed while they are stunned. Pointing to their "control" square does not seem to work.
* 1-unit aliens can be healed either while conscious or while stunned
* Wounds on aliens can be correctly seen with Medkits
* The Medkit display shows a human silhouette regardless of the alien type, of course
* Healing aliens with Medkits, stops them from dying of wounds (not 100% tested but seems to be true)
* Aliens (large and small) seem to lose the correct amount of Health per turn from Wounds
* Aliens with wounds that are not treated, eventually die (not 100% tested but seems to be true)
* A Mind Probe can see if an alien has Wounds.

Anomalies:

* I had a lot more reports of Reapers dying than I would expect. I would not have expected any to die, and I had 3 reports of death by wounds. Even heavily wounded Reapers take a long time to die. In my test I was only shooting them with Pistols. Maybe there is a problem with the reporting? Maybe the death of the same Reaper was reported more than once? More testing needed on this.
:I wonder if Reapers are receiving wounds on all 4 sections when hit by explosives (I don't know which weapon you were using). They really shouldn't, although I'm unsure how you'd get around this. If possible, put a cap on the maximum number of wounds something can ever have (perhaps 6). You could argue their multiple hearts really empty their blood out quickly, but I don't think fatal wounds should ever become more dangerous than burning alive.

:: Well, why not: hit four times by one explosive, check for incurring fatal wounds four times. -- [[User:Zaimoni|Zaimoni]], 13:49 Sept. 6 2009 CDT

* Question: should the death of an alien by wounds be reported, or should it die silently? Did I only see these messages because I was using Alien Pets, and so they were on "my" side?
:Regarding death reports, I enabled the dialog for aliens/civilians (it usually only shows up for xcom operatives) to help in testing. The final version will not show them. [[User:Seb76|Seb76]] 14:10, 3 September 2009 (EDT)

Caveats:
* I used the Alien Pets, Big Brother, and Alien Inventory hacks to do this test. I also hacked a save game to give me Pistols, Medkits, PsiAmps and Mind Probes. [[User:Spike|Spike]] 16:03, 3 September 2009 (EDT)

To Do:
* Test if aliens (small, large and mechanical) suffer from [[Fatal Wounds#Other effects of Fatal Wounds|other effects of wounds]], e.g. penalties to Energy, Accuracy, Time Units
* Do Cyberdisks, which have no legs or arms and probably no head, only ever receive Torso wounds?

=== Mechanical Bleeding ===

* Question: Do Cyberdiscs and Sectopods receive Fatal Wounds? I'm wondering whether an unconscious Cyberdisc is safe to be around. Even if they didn't explode, Fatal Wounds would be stupid for a robot. If XCOM tanks can't end up leaking fuel and sparking dangerously, neither should enemy robots. [[User:Stubbs|Stubbs]]
: I think you can make a case for tanks and robots having "wounds", i.e. damage that gets progressively worse by itself. You can even make a case for them being "stunned" - temporarily non-operational. You can even make a case for it applying to alien robots but not to X-COM tanks, since alien robots all have some degree of organic component (which is why they can be Mind Controlled). But I still think you are right, neither effect should apply to machines, whether alien or human. As for your question, see the tests below:

Cyberdisk Bleeding Test Findings:
* Cyberdisks take Wounds (with Alien Bleeding option enabled)
* Cyberdisk wounds can be healed (though only after unit is stunned)
* Cyberdisks lose health from wounds
* Cyberdisks can die from wounds
* Cyberdisks don't seem to explode when they die from wounds ("has died from wounds" popup)

Cyberdisk Bleeding TestTest Caveats:
* Same caveats as previous tests (above), plus:
* The Cyberdisks were modified from Reapers using xcomutil :rpl
* Some Pistols were changed to Laser Rifles using xcomutil :chg
* (xcomutil was not installed in the game directory however, it was used from another location)
* The stats (Armour 34 all round, Health 120) appeared normal for Superhuman
* However the Cyberdisks seemed to fall too easily to Laser Rifle fire (e.g. 1 hit)
* Also, they seemed not to explode as often. This was because they were often stunned.
* Hard to tell in-game whether a Cyberdisk is dead or stunned. The graphic is the same, you can't use a Mind Probe, nor look on the ground, nor even check by changing sides.
* Actually there is one way to tell: stand over it and use a Medkit. Didn't think of that. [[User:Spike|Spike]] 08:22, 5 September 2009 (EDT)

:Thanks for finding out, Spike. Autopsy text shows you are right about the Sectopod( but not about the Cyberdisc) having biomechanical components, but it's not like there are gallons of blood pumping around the thing to gush out. One thing: did you check both conscious and unconscious death-by-wounds for the Cyberdisc? [[User:Stubbs|Stubbs]]
::No problem Stubbs. I didn't deliberately test this, but I had numerous deaths-by-wounding while unconscious and I think at least a few while conscious. I believe those that died while conscious, exploded. (I think this is the basic rule for Cyberdisks. If they are stunned, they don't explode. This typically happens with stun weapons but can also happen with regular weapons, if you are lucky.) [[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)

* Seb76: maybe robots receiving wounds was an oversight, or maybe you really do want robots to take wounds. In either case, it would be nice to have a separate option for this. My arguments against robot wounds are pretty simple: tanks do not receive them, the bled-out dialogue "X has died from a fatal wound" sounds silly for a robot that was never alive, and finally that a Medkit should not be able to heal a robot.
: It's reasonable that alien mechanisms (Sectopod, Cyberdisk) would not suffer from wounds. Possibly also Zombies should remain immune to wounds? From a note Seb made elsewhere, I think the UNITREF.DAT "can be wounded" flag is the same as the "can be stunned" flag. Wounding is probably prohibited globally for aliens, by an override somewhere in the executable. Seb has probably removed this override, unconditionally. To remove the override more selectively, I suspect Seb would need to put a logic test in the code, to check the alien type. .[[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)
::There was a check for ownership that I simply removed. Next version will have an explicit check for robots/chryssies/zombies not to bleed. [[User:Seb76|Seb76]] 12:29, 6 September 2009 (EDT)

* If you want a sense of "the Sectopod's leg got damaged" or even "the tank's track was broken", perhaps robotic units could be 'wounded' by damaging max TUs.
* If, however, the above won't let weapon usage TU %s recalculate as TUs are lost (i.e. the units lose firing ability as well as walking), then certain values of Energy with the correct Energy usage modifier could emulate loss of speed without losing firing ability. Since Energy is returned at a rate of 1/3 of TUs, these units could have an Energy value of (slightly less than) exactly 1/3rd of their TUs. Their energy usage modifier is then changed to allow this small energy value to usually suffice. Now, when Energy is damaged, the units will be permanently slowed, but their weapons won't be affected. [[User:Stubbs|Stubbs]]

=== Zombie Bleeding ===

Zombies that bleed to death don't seem to turn into Chryssalids. As discussed above, it might be better to disable wounding for Zombies. (Death by wounding for Zombies was already possible, without this fix, if the Zombie was mind controlled, wounded while mind controlled, then released back to Alien control.) [[User:Spike|Spike]] 21:07, 5 September 2009 (EDT)

== Hostile Civilians ==

This fix also seems to prevent:
* [[Exploiting_Mind_Control#Zombie's_Permanent_Control_of_Aliens_via_Stunning|Permanent Control of Aliens via Stunning]] Exploit - as was hoped for.
* [[Exploiting_Mind_Control#Resurrect Zombified Agents|Permanent Control of a Chryssalid/Tentaculat]]

It does not fix:

* Various Mind Control bugs:
** [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]
** [[Known_Bugs#Mind Controlled Aliens Count as MIA if you Abort]]

(Probably because fixing both of these requires special, end-of-mission processing)

Still To Be Fixed:

* [[Exploiting_Mind_Control#Exponential Mind Control|Exponential Mind Control]]

(This requires a check in UNITPOS to ensure that the unit attempting Mind Control is not, itself, already mind controlled.)

[[User:Spike|Spike]] 16:16, 3 September 2009 (EDT)

== Fixed Funky Fire and Zombies ==

Fixed Funky Fire still permanently kills Zombies, when the killing damage comes from (end of turn) fire damage. [[User:Spike|Spike]] 21:02, 5 September 2009 (EDT)

== Research Tree ==

I've found a way of modding the research tree and was wondering if people are interested in an updated version. I've read of stuff like enabling hovertanks from cyberdisc autopsies or flying suits with floater research, but I think there is more that can be done. The limitations from the original game is that having researched a topic cannot unlock more than 4 new topics, and cannot unlock the production of more than 4 new item types. Any ideas? [[User:Seb76|Seb76]] 12:40, 6 September 2009 (EDT)

* Another one I mentioned was: Mind Probe before Psi-Amp, although I'm going to retcon that to "Mind Probe before Psi-Lab" (which then leads to Psi Aimp as per usual). The logic behind this is that the first step of a psi-attack must be scanning for enemy brainwaves to pick them out of the other signals. Before you can teach soldiers to do this, you'd have to have studied the mind probe to see how the non-psychic aliens are managing to find targets. You've got to walk before you can run, after all.
* I'm unsure if the next suggestion is possible, given what you have said. I'd like some kind of necessity to research at least some corpses/aliens - is it possible to require, say, any 6 alien 'live' or 'autopsy' reports finished before Alien Origins unlocks? You might also make it dependent on difficulty (6/7/8/9/10 needed). You could also include alien missions in this count.
* My only other suggestions are: you should have to research Elerium before you can build anything that requires Elerium to build. You should have to research Alien Alloys before you can build anything that uses those (which is true only for some things currently. It doesn't seem to be a prerequisite for building alien weapons). Is it possible for a manufactured item to require two separate research entries to be manufactured?
* Question: is there also a limit of 4 prerequisites for a research item? [[User:Stubbs|Stubbs]]
:There is no limit on prerequisites, it's the code that shows "you can now build/research xxx" that has a 4 entries limitation. [[User:Seb76|Seb76]] 15:05, 6 September 2009 (EDT)

A boring suggestion but how about making sure that for all weapon research, you need to do the pistol before the rifle before the heavy weapon, etc. And similarly with the ammo types. Apart from that, I'll think on it. [[User:Spike|Spike]] 17:42, 6 September 2009 (EDT)

Another boring suggestion: each specific laser weapon should take a little longer to research - force you to use the starting weapons for a little longer. You could also rebalance the Plasma research times so that the rifle took a little longer and the Heavy Plasma took significantly longer. It might then be more viable to research them from weakest to strongest, without forcing your hand as Spike suggested. [[User:Stubbs|Stubbs]]

:Yep that's a good alternative.

You could make the Stun Launcher a little harder by requiring (as well as Alloys and Elerium), perhaps a live Medic to be researched before the Stun Launcher (since it's usually Medics that carry them and presumably understand how to operate them), and an Engineer for a Blaster Launcher. It's not much extra but it helps to make these powerful weapons a little harder to get. If you wanted to make Blaster Launcher quite a lot harder to get you could add something like UFO Navigation (something to do with plotting all those waypoints, alien-stylee), or at least a Mind Probe for similar reason.

But, what are we trying to do here? Make things harder in general? That's one option. Or "rebalance", i.e. make things that are relatively too easy to get, relatively harder to get? Or make things more "logical"? There's lots of ways to play this.

It's a shame there's not a distinction in the game between using, and manufacturing, alien weapons - as is done in XcomUtil. Really, there should be a world of difference between figuring out how to use scavenged alien weapons, and actually being able to manufacture them. But that's not really a research tree topic, '''unless''' - would it be possible to create new topics? Could you separate out the using of an item from the manufacturing of it? (If not, it would be good to have a game variant in which nothing that can be scavenged, is allowed to be manufactured).

UFO Navigation might also be a good prerequisite for Hyperwave Decoder. I'm sort of rambling here, but what are the most powerful technologies, that are kind of easy to get... which ones need to be made harder. (Are there any that need to be made easier?)

Powerful technologies:
* Psionics (Psi Lab == Psi Amp). Adding the Mind Probe, as suggested, would be a good idea. Maybe a psionic Commander capture required for each.
* Blaster Launcher - maybe require an Engineer and a Soldier research, as well as Elerium & Alloys. Mind Probe or UFO Navigation for the "plotting" element? A separate Engineer capture to produce the ammo? What else?
* Stun Launcher - Medic and an Engineer? Maybe a full set of autopsies - but that's too onerous.
* Heavy Plasma - stretching the research time would be good, though this can already be done. Additional pre-reqs - maybe add a live Engineer requirement (maybe for ''each'' Plasma weapon type?). If you keep making these requirements you probably need to add a hint in the UFOPaedia along the lines of "we will need to interrogate alien technical experts to further understand this weapon technology". (OK that's hardly a hint.)
* Laser Cannon (?) - But I'm not sure this Laser Cannon factory thing is a big deal. Arguably building a new intercept base is a better cash cow than building a 50-Engineer Laser Cannon factory.

[[User:Spike|Spike]] 16:34, 8 September 2009 (EDT)

== 64 bit compatibility ==

Any way to make the loader compatible with 64-bit operating systems, like 64-bit XP/Vista/7? [[User:Jwilcox25|Jwilcox25]]

: I'm using it on Windows 7 and it's working fine. Not sure if that's 64 bit though. [[User:Spike|Spike]] 07:26, 9 September 2009 (EDT)

:: If you're not sure, you are probably running the 32-bit version of Windows 7. Starting from XP, Windows comes in both 32-bit and 64-bit flavors. Most 32-bit programs are backwards compatible, but apparently not X-COM from my experience. [[User:Jwilcox25|Jwilcox25]]

: It works fine with Windows 7 64-bit. Didn't have to enable any compatibility options or anything like that. [[User:Rovlad|Rovlad]] 02:29, 23 April 2010 (EDT)

== Music bug ==

When enabled "MIDI freeze" bugfix, after entering first combat the music stops playing completely, for the remaining game session.

Also, when using Extender, for some reason music is playing at really low volume, i have to manually reduce my main sound channel and crank up the volume to hear it. When just starting normal UFO CE volume levels of music and sfx are about equal. I have SB Live & WinXP.

== Fire Speed bug ==

Sometimes, for no apparent reason, fire speed setting jumps to 3, instead of what you had it set on.

: I believe it's a bug in the game itself, not the loader. I remember encountering it in both DOS and CE versions. [[User:Rovlad|Rovlad]] 02:31, 23 April 2010 (EDT)

== Reserve TU for x-Shot ==

Not sure if this has been addressed or fixed, but if you reserve Time Units for any shot type, all you get is Snap Shots for the reaction phase - never aimed or auto. Is there any way you could enable these two unused types for reaction shots? --[[User:Zombie|Zombie]] 22:51, 25 October 2009 (EDT)
:As far as I can tell, the reserve is only meant to be used during the active turn. Reaction shots are hardcoded to snapshots (that's true for the aliens too), it's no bug that your guys don't use reaction autoshots. [[User:Seb76|Seb76]] 12:10, 16 January 2010 (EST)

== TFTD ==

I know you're hoping to perfect the current version before taking on any new projects, but I just want to add my plea to the others requesting a TFTD version. Even some of the basic functionality would be awesome and probably completely portable, such as the stats on the equipments screen, default new base, etc.

== Can't change tasks in D3D ==

Hey, I'm having an issue with D3D. If I alt-tab out, I can't switch back to the X-Com task. I'll switch to it but nothing can happen. I'm on Windows 7 x64 with an ATI Radeon HD 5770. [[User:Rlbond86|Rlbond86]] 20:19, 15 January 2010 (EST)
:I too have hangups sometimes when alt-tabbing out of XCom, sadly I'm no D3D expert :( I'll add more checks to see if resetting the D3D device worked though. If anyone knows of a 100% working way of dealing with "device lost" conditions, now is your chance... [[User:Seb76|Seb76]] 12:06, 16 January 2010 (EST)

== Battlescape Soldier's Stats Crash ==

I'm having this little problem with this and I wanted to know if I'm the only one that's suffering with it: everything works fine, but when in battlescape mode I want to check the stats of a soldier (by clicking his rank icon) the entire game CTD. Does it happen to anyone else? How can I fix it?
:Never saw such problem...
:* Does it still crash when you disable the extender (and what options did you enable)?
:* Do you have the address where the crash happens?
:[[User:Seb76|Seb76]] 15:55, 22 January 2010 (EST)
::It didn't, but now I reinstalled the game and it works wonderful. This is a great job you did here. Is there any chance that you could access to the stats of the soldiers from the assign crew screen? --[[User:Slibluhr|Slibluhr]] 16:56, 22 January 2010 (EST)
::OK, I could reproduce the crash this time, it has nothing to do with the stats screen as I supposed to do. The game crashes RANDOMLY if I have turned on the D3D thingy, any clue? I've also noted that if I turn on the caps mod (to put most of 'em in 150-200 to overcome the distance penalty) the soldiers do NOT improve, even after kicking a large scout's butt with KAtherine Sharpe, she didn't get any FAc point! --[[User:Slibluhr|Slibluhr]] 05:30, 23 January 2010 (EST)
:The caps bug is a known one, and a fix is available. I thought I'd wait for more substancial stuff before releasing a new version though. You can try the latest dev version that has the fix included.
:As for your crash I cannot do much without a crash address... [[User:Seb76|Seb76]] 11:46, 24 January 2010 (EST)
::This is what it said during last crash:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00011689

::--[[User:Slibluhr|Slibluhr]] 15:29, 24 January 2010 (EST)
:Sadly the address is of no use (crash inside Windows code, most likely because of wrong arguments). I've put a new version up with better D3D error handling, does it help with your crashes? Also since I was feeling like it, I updated the "Reorder Soldiers" feature so that when you click the name of the soldier, his stats show up. You must click the rank/name of the ship to assign the soldier. [[User:Seb76|Seb76]] 18:00, 24 January 2010 (EST)
::Thank for the access to the stats of the soldiers via crew screen, it releases them from having their FAcc and PStr in the name.

:: btw, the crash moved to this location now:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00028c0b

::could it be that's my pc's fault? does this happen to anyone else?

::------------------
::System Information
::------------------
::Time of this report: 1/25/2010, 01:25:00
:: Machine name: 0X000001
:: Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.090804-1435)
:: Language: Spanish (Regional Setting: Spanish)
::System Manufacturer: FOXCONN
:: System Model: A6VMX
:: BIOS: BIOS Date: 03/13/09 09:59:28 Ver: 08.00.14
:: Processor: AMD Sempron(tm) Processor LE-1250, MMX, 3DNow, ~2.2GHz
:: Memory: 3072MB RAM
:: Page File: 466MB used, 4490MB available
:: Windows Dir: C:\WINDOWS
:: DirectX Version: DirectX 9.0c (4.09.0000.0904)
::DX Setup Parameters: Not found
:: DxDiag Version: 5.03.2600.5512 32bit Unicode

== Store limit question ==
Nice to see you've implemented the general store change (unfortunately, UFOExtender doesn't work under wine, so I can't test this). I'm curious why 187 is the limit? I thought it would be a power of 2 (possibly minus 1)... Possibly you wanted to write 127? [[User:Cesium|Cesium]] 19:43, 21 February 2010 (EST)
:You can build 35 general stores max in a base and 65535/35 ~= 1872 (the internal representation is ten times what's shown ingame). [[User:Seb76|Seb76]] 00:19, 22 February 2010 (EST)

== Mouse scaller not working on Windows 7 x64 ==

with d3d=1 and Scale Mouse=1 I still have issues with the mouse going way off screen.
--[[User:BladeFireLight|BladeFireLight]] 01:57, 22 February 2010 (EST)
:I have noticed that alt-tabbing out of X-COM at the title menu (or any other point that won't crash it) and then alt-tabbing back into it fixes this problem for me in Win7-64. --[[User:Xusilak|Xusilak]] 13:12, 22 February 2010 (EST)
::Thanks for the heads-up. I uploaded a test version here: http://www.ufopaedia.org/index.php?title=Image:UFOExtender-dev.zip
::Does it fix you problems? [[User:Seb76|Seb76]] 14:36, 22 February 2010 (EST)
:::Yep. Seemingly no issues with the mouse going off the screen using it, although I didn't test for long. I'll try to get more test time in later. --[[User:Xusilak|Xusilak]] 20:46, 24 February 2010 (EST)
::::Actually, it doesnt work for me either, in WinXP. And it was broken since the version of 7th November, the one with windowed mode addition. Also, Alt-Tabbing didnt work too. This fix makes things right, though.
::::Edit : also, this dev version crashes in 100% cases when going to battlescape.
::Strange, I do not have any trouble even when using split binaries. Do you have an address for the crash? [[User:Seb76|Seb76]] 14:03, 1 March 2010 (EST)
:::Okay, i hope this is what you wanted, but it says the adress is 0x0000000000bd22ca. I can load an actual save with tactical mode, but cant go into tactical from geoscape. So i use the version from 1st November still.
:Hum, you say the dev version crashes and that you are stuck with the version from 1st november. Do you mean you have the problem since the version of november the 7th, independently from the dev version? [[User:Seb76|Seb76]] 14:08, 4 March 2010 (EST)
::Actually yes. At first i didnt want to use it, because i use a tablet instead of mouse, and its really noticeable when a window failed to scale properly, since a tablet works in absolute screen coordinates. But just now i checked several new (non-dev) versions for the crash - its there. Crashes every time i try to enter tactical mode from geoscape. Saves from tactical load up fine. Version from Nov.1st gives no problems whatsoever.
:Do you still have the problem if you disable D3D or use windowed mode? Also if you load a tactical game, don't you get a crash when it goes back to geoscape? [[User:Seb76|Seb76]] 03:20, 6 March 2010 (EST)
::When disable D3D - yes. When enable windowed - yes. When going from tactical to geoscape - no.
:OK, I suspect this has to do with the "Save Equipment" feature. Can you try disabling it if you have it on? [[User:Seb76|Seb76]]
::OK, um...i tried all my saves, and with that feature disabled all my saves load up fine, and i can go from geoscape to tactical and back. So i thought everything was alright, and kept playing - the very next tactical mission loads up fine, but as soon as i try to move anyone - it crashes. And that is the same in all my saves, first mission is alright - second one always crashes. The crash adress is 42064f, in case you're gonna ask.
:Alright, can you PM me a savegame before the crash? I doubt it'll help but who knows...[[User:Seb76|Seb76]] 12:43, 6 March 2010 (EST)

== Extender in Steam (+ maybe XComUtil) ==

Hi do you know of any way to use the two apps together with the Steam version? I would really like to be able to combine the 'Reorder Soldiers' feature of Extender and the 'Capturing Aliens for Research' of XcomUtil.

Actually now that Ive put a bit more time into it I can't get UFOLoader.exe to run in steam's dosbox implementation at all. I can just run UFOLoader but it doesn't run in dosbox which makes the game run horribly. If you don't have a steam copy for testing / integration of the basic Extender program please let me know and I would be happy to send you a gift copy.

-Dogfish

P.S. What a great program, you are a credit to gaming.
:As far as I know, the Steam version also ships with the windows CE edition, the default shortcut just happens to point to the dosbox one. Also the latest version of XComUtil is able to detect the loader presence and act accordingly. [[User:Seb76|Seb76]] 15:42, 25 February 2010 (EST)

:: STEAM comes with both EXE. XcomUtil and UFO Extender work together with STEAM. To use Setup UFO Extender in the game folder. Then Download and install the latest build of XcomUtil 9.7. It will auto start XcuSetup in windows, Detect UFO Extender and allow you to configure RunXcom to use it. To use UFO Extender, or UFO:CE you can't launch the game from STEAM. You have to create a short cut for RunXcom. (Right click > send to > Desktop as Shortcut) --[[User:BladeFireLight|BladeFireLight]] 19:13, 25 February 2010 (EST)

Thanks guys I was able to start the game with both mods. I apparently had everything configured correctly but I kept launching it from steam. Is there a way to play in windowed mode (since its not using dosbox)? I tried launching dosbox and running 'RunXCom.bat' file from there but it does not recognize UFOExtender.

Oh boy the game is fast, even on slowest scroll it is difficult play a battle :)

-Dogfish
:What options did you turn on? [[User:Seb76|Seb76]] 14:18, 26 February 2010 (EST)

Show Stats=1
Apply=1 (wreck analysis)
Proximity Grenades Experience=1
Elerium-fueled Craft Bug=1
Save Reserve Mode=1
Rank In Inventory=1
Manual Interception Fire Mode=1
Crafts Always Ready=1
Reorder Soldiers In Crafts=1
No Funkers=1
TFTD Doors=1

Full System Specs:
Win Vista 64
Intel i7 920
6GB RAM
GTX 285 Video
Asus p6t

Everything is fast the geoscape tics are at least 5 times faster than running the non-Extender mode via dosbox.

Would you have any suggestions how to slow it down? I've actually been playing in steam(dosbox) with XComUtil only and then saving/loading between missions so I can reorder the soldiers.

Aha! I found the D3D Windowed option...
HQ4x=0
D3D=1
D3D Windowed=1
Always On Top=0
Clip Cursor=1
Scale Mouse=1
Screen Ratio=0.833333

I can manually resize it to be bigger, excellent!
What is strange is that running it in windowed mode seems to slow it down enough for the scroll speed settings to make it playable :)

I ran into a "Unsupported 32/16/64 bit error message switching from geoscape to battlescape but it happens only 1/3 times maybe?"

I will be playing this and let you know if I run into any more problems.

Thanks a bunch!
-Dogfish

Hi guys, dogfish again I've been getting a couple of glitches.

1. Switching from battlescape back to geoscape in the cmd prompt it displays
'echo----------------------------Leaving' is not recognized as an internal or external command, operable program or batch file.

2. This has happened twice

Get someone who has been shot is at low health and has fatal wounds

Have them pass out due to smoke inhalation

Let them bleed to death and get the "Joe McSoldier has died from a fatal wound" *while unconsious from the smoke*

I will lose points for the mission but the soldier will be recovered at the end of the mission but terribly wounded. (Currently Hans 'Jesus' Vogel is taking 55 days to recover his 41 health.)

:Both of these are XcomUtil issues. 1 has been fixed in Build 413 but I need a saved from just before ending combat to fix 2. --[[User:BladeFireLight|BladeFireLight]] 18:19, 28 February 2010 (EST)

::Sent the savegame to your gmail (whatever was listed on my paypal reciept from your donate button). Just hit end turn (all the aliens are dead) and the bug is triggered. -Dogfish
::: I got it. Was up all night with Bomb Bloke and we worked out what was going on. The fixed works with your save. The next build will fix the zombie bug. Also Thanks for the donation. Every little bit helps. --[[User:BladeFireLight|BladeFireLight]] 16:02, 1 March 2010 (EST)

--
Hi! I'm thefarside. This is my first time ever editing a wiki page so please bear with me. I'm not even sure I'm allowed to do this.

However, I have a problem with the cursor. It moves WAY out of the screen to the right and downwards. I've read something about a "clip cursor" fix but I can't seem to find out where and how to implement it.

Regards,
thefarside
--

== Manually Select Promotions ==

Just an Idea, not sure how easily done it is but I was thinking it would be really cool if (when its time for promotions) it would bring up a soldier screen with the eligible soldiers so that you could pick who gets promoted. Bonus if you could click on the candidates and be taken to their stats screen.

Love,
Dogfish

== Xusilak's Patch Additions ==

Since my patches are being integrated into the main release now, everyone should let me know if any issues are found with them. I'll try to get on fixing them as quickly as possible.

For clarity, the patches in the current build that I developed are:

* AutoSell
* Show Money

Thanks! --[[User:Xusilak|Xusilak]] 14:51, 24 March 2010 (EDT)

I went ahead and set up my own user page: [[User:Xusilak]]. If possible, direct discussion about my patches to my [[User_talk:Xusilak|discussion page]] there. Thanks again! --[[User:Xusilak|Xusilak]] 15:44, 24 March 2010 (EDT)

----

Hi Seb,
I've been working with IDA, your database, and your patcher's code for some time now, learning my way around it, and so on. So far, I've managed to come up with three UI improvement patches, although they still need some polish and testing.

The first one is a battlescape movement confirmation patch; it requires the user to click twice (double-click with no time limit) on the same tile to move, instead of once, to eliminate movement errors. In practice, I have found this very helpful.

The second one shrinks the geoscape clock and adds your current funds above it, letting you see your financial situation at a glance while waiting for time to pass.

The third one enables auto-selling of manufacturing items. Pressing the down arrow when the production quantity is at 0 engages this mode. When in this mode, production of that item never ceases (unless resources become unavailable), and the item is immediately sold upon completion.

Would you like me to make the code for these available once I've finished polishing them up? They currently consist of a few C functions accompanied by some InsertCall()s and Nop()s, as well as some additions to XCOM.h. I haven't added INI options to enable them, so I'd leave that up to you. You may use them as you wish, with no conditions.

Note: I'm still learning x86 assembly, so the patches may not be bug-free. I'm hoping to give them a good testing myself, though.
--[[User:Xusilak|Xusilak]] 16:10, 19 March 2010 (EDT)
:Glad to see you could make something out of this database :-) Do not hesitate to send me your modifications, I'll incorporate them in the codebase so others can enjoy them. I'm sure your autosell feature will make a few happy ones ;-) [[User:Seb76|Seb76]] 19:12, 19 March 2010 (EDT)
:::Yeah those features would all be '''great!''' Thanks Xusilak. [[User:Spike|Spike]] 15:08, 22 March 2010 (EDT)
::OK. I'm going to finish up my last touches on them, then test them for a while; they should be ready within a couple days. --[[User:Xusilak|Xusilak]] 21:59, 19 March 2010 (EDT)

== v1.21, Battlescape crashes ==

I enabled the new mods and they worked ok in Geoscape. Then this Popup box starting the first Battlescape:

Application failure
XCOM crashed at 0x10002571 with error 0xC0000005 trying to access 0x0968DF43

[[Media:UFOExtender1.21.BSCrash.zip]] contains the UFOExtender.ini file.
This was a New Game but not a new install of XCOM, just an overlay of updated UFOExtender.

*Win XP Pro 2002 SP2 32bit PAE
*Pentium-4 3.00GHz 3.5GB RAM

Any ideas? Need more info? [[User:Spike|Spike]] 20:20, 24 March 2010 (EDT)
:Does it happen consistently? I've been plagued by a random geoscape->battlescape transition crash in the collector's edition. It's one of the things I'm looking to fix at some point. The current UFOExtender doesn't appear to crash any more than previous ones do for me. I managed to do four missions in a row just now. --[[User:Xusilak|Xusilak]] 21:00, 24 March 2010 (EDT)

I'm doing some research into this; I started up in debugging mode and spammed missions until I hit a crash. The crash (on this occasion) is an access violation caused by an invalid pointer stored at 0x49B954 (the offset that pSoldierDat points to). This means *pSoldierDat is being changed at some point. It took many, many tries to get this crash to happen; I reloaded something like 20 times hitting the same mission, went ahead and did the mission quickly, proceeded, did another mission, proceeded, then the next mission crashed. Given that I'm in debug mode, it's not impossible this is due to the various hacks enabled by it, so that should be kept in mind. I'm going to continue working on this. --[[User:Xusilak|Xusilak]] 22:26, 24 March 2010 (EDT)
:It appears the "invalid" pointer is actually set by malloc() - 0x0771D380 (for me). I can only assume something along the way disrupted the data on the heap, as the pointer was the same when examined on a battlescape transition that didn't crash. Still researching. Note that for me, the crash itself happened inside GetSolderUUID() in the Save Equipment patch functions when it attempted to use that *pSoldierDat pointer. However, I assume it would still happen if the Save Equipment patch were disabled, just elsewhere. This is something I'll test as well. --[[User:Xusilak|Xusilak]] 23:41, 24 March 2010 (EDT)

::Sorry I'm guilty of reporting a bug I didn't (couldn't) repeat. But as I had no previous save game positions I couldn't repeat anything - the crash happened on the first Battlescape mission which for me is unusual, I would say that for me that transition crashes less than 1 in 100 times, if even that many. I had enabled Save Equipment I think and on instinct I would suspect that mod as being responsible. Those UFOExtender functions would run while setting up the Battlescape presumably. The equipment handling functions and structures ''already'' present in the game are known to be buggy. BladeFireLight and I just found another issue with them last week. Manipulating them is still risky. If you can investigate that would be very helpful.

::In the meantime I will see if I can try to repeat the fault, with and without Save Equipment enabled, and starting from a clean XCOM install. One trick I may use is to set No Score Game Over and then just abort from each mission rather than fighting it, to speed up the testing.

::Thanks for your good work Xusilak, it is appreciated! [[User:Spike|Spike]] 03:25, 25 March 2010 (EDT)

One possibility: On this mission I had only 6 soldiers (2 HWPs) but enough weapons in the Skyranger to equip 14 soldiers. Is there some known issue with needing to allocate '''all''' weapons to soldiers during the equip phase, in order to avoid a crash? If so that might be the cause. I will try to recreate those conditions and see if it provokes a crash. In case it's not clear, Battlescape never appeared to start, no Equip Phase screen ever came up. [[User:Spike|Spike]] 03:31, 25 March 2010 (EDT)
:Assuming the same crash is afflicting us, then the crash is when the very first soldier is accessed, when the Soldier.Dat data is first used for that mission. It's unlikely that volume of equipment is affecting that, and in particular, I hadn't changed my Skyranger's loadout to any degree whatsoever, having only briefly touched researching and manufacturing; it was otherwise a gamestate set entirely by doing one quick regular mission and one quick terror mission. However, I was also in debug mode, which enables certain cheats, like Alien Pets, automatically. This might, itself, have unseen bugs that could corrupt the data structures and cause a similar crash. When I get the time to, I'll be testing again with those cheats disabled, trying to further isolate the conditions involved. --[[User:Xusilak|Xusilak]] 08:34, 25 March 2010 (EDT)

I've repeated this multiple times now, with a clean install of XCOM and a clean install of UFOExtender 1.21. The game crashes everytime, after the "mission screen" that comes up just before the Equip Phase of Battlescape for the first mission. It's regardless of my equipment loadout or number of soldiers/tanks: it happens with totally default equipment and Skyranger load. So I imagine it must be due to some combination of the UFOExtender.ini file options I selected, and maybe code changes in 1.21. My .ini file is the upload at the top of this section. The error is always "error 0xC0000005 trying to access 0x0968DF43", though the crash location (in the code) varies. [[User:Spike|Spike]] 20:31, 25 March 2010 (EDT)
:If you have time, could you try to 1) confirm it's specific to 1.21 2) try to correlate it to ini options? Turn everything but the basics off and see what happens... if that works, turn on Save Equipment and try again, etc. I haven't seen any behavior like that in my local tests, on either of my computers (Win7-64 and XP-32). I'll try it with your ini, though. Maybe I can find something. --[[User:Xusilak|Xusilak]] 20:39, 25 March 2010 (EDT)
::Just tested with your ini, although with D3D and D3D window enabled. Started a mission, didn't crash. I also noticed one thing: you have General Stores capacity set to 1. I don't think that's helping anything, but it's probably not causing the crash, either. Experimenting more. --[[User:Xusilak|Xusilak]] 20:48, 25 March 2010 (EDT)

::: Save Equipment=1 is part (at least) of the problem. If I turn that off, and leave all my other .ini settings as is, I no longer get the Battlescape crash. Seb, did you make some changes there? Maybe after the investigations we were doing with BladeFireLight? [[User:Spike|Spike]] 21:13, 25 March 2010 (EDT)

I have isolated the problem (on my end) to the fact that the SOLDIER.DAT data in memory is deallocated when the transition to the Battlescape starts. When Seb's Save Equipment code attempts to use it, it's getting random unallocated (or unrelated) memory instead of the SOLDIER.DAT data. Interestingly, the dynamic memory used to hold the SOLDIER.DAT data is deallocated on the transition to the Battlescape, and reallocated to a new memory address on the transition out of the Battlescape. I assume this is an artifact of the way the Collector's Edition merged TACTICAL.EXE with GEOSCAPE.EXE, because TACTICAL.EXE had no need of SOLDIER.DAT, and only used UNITREF.DAT and similar. At any rate, this problem can be resolved by not relying on **(0x49B954) (or **pSoldierDat) to contain the correct data. Instead, a workaround to get the needed data should be used. One option would be to patch the way the transition works to prevent the deallocation from happening, and then ensuring on exiting the Battlescape that the old memory block is still used. I may be able to work in that fix myself. If so, it would require no changes to the Save Equipment code.
I'm not sure if this is a general issue or local to me only. I'll try to test on my XP system and see if it suffers from the same problem; if it does, it's a safe bet this is a general issue, and the likely cause of your crashes. --[[User:Xusilak|Xusilak]] 00:06, 26 March 2010 (EDT)

Save Equipment did used to work for me before. Maybe it's because I also selected Reorder Soldiers In Craft. Does that sort and rewrite SOLDIER.DAT? [[User:Spike|Spike]] 03:39, 26 March 2010 (EDT)

I have confirmed this behavior in the original X-COM Collector's Edition UFO Defense.exe copy, running on my XP system. As such, it ''cannot'' be a result of any patches Seb has made (because it still happens even when not using Seb's loader). I'm not sure if it will crash without Seb's patches still, but the way Seb uses the *pSoldierDat pointer in GetSoldierUUID() appears to be unsafe, as *pSoldierDat has already been deallocated at that point. On some systems, it may work, because the nature of memory on the heap is such that different systems give different results when dealing with deallocated memory and bad pointers. Regardless, the crashes can be at least partially (maybe entirely) resolved by using a workaround that avoids the deallocation of *pSoldierDat when the battlescape transition starts. I'm going to see if I can implement the fix I suggested, that prevents the memory from ever being deallocated. That should completely resolve it. At the least, I am going to study the assembly responsible for deallocating it to see if I can confirm the exact issue on the code level. --[[User:Xusilak|Xusilak]] 13:26, 26 March 2010 (EDT)
:It seems that when GotoGeographMode() returns to move into GotoTacticalMode(), it calls FreeEverything() in the process, deallocating all data structures. Then, GotoTacticalMode() never bothers to reinitialize *pSoldierDat, so when the equipment phase comes up, it's still unallocated. Still working on a fix. --[[User:Xusilak|Xusilak]] 14:29, 26 March 2010 (EDT)

::Surely at some point the (unmodified) game needs to at least read the *pSoldierDat structure, in order to populate the [[UNITREF.DAT]] and [[UNITPOS.DAT]] structures for Battlescape? Unless it reads SOLDIER.DAT but doesn't bother storing it, not even temporarily, in *pSoldierDat.[[User:Spike|Spike]] 15:27, 26 March 2010 (EDT)
:::Nice piece of analyse there :-). I'll modify the patch to load the soldier data when needed and clean up afterward. [[User:Seb76|Seb76]] 15:30, 26 March 2010 (EDT)
:::Edit: I uploaded a test version. Can you check if it fixes your crash? [[User:Seb76|Seb76]] 15:47, 26 March 2010 (EDT)
::::Looking good so far; Save Equipment works for me now, and it never has in the past. I'll run through a bunch of missions quickly and see if I get any crashes. Thanks Seb! --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:::No, thank you for figuring out the cause of the crash. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
:::::Just ran through several dozen (very quick, mostly aborted) missions all the way up to June. I never crashed, and Save Equipment always worked correctly. I think we're good to go. Hopefully it works for Spike as well. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)

I've also been narrowing in on another crash, unrelated to the patcher, I believe. It happens rarely upon clicking the air to move somewhere, like stepping out of the Skyranger by clicking the air one tile in front of the soldier, to move onto the ramp. It appears to be the result of a bad calculation on the tile to check in MoveUnitTo(). The calculation is looking at (char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize); // when esi is 2 or greater; this esi factor shouldn't be there, as far as I can tell, because it results in the offset used being much greater than it should be and frequently going out of bounds of the MAP.DAT data stored at *pMap. Continuing my research into this when I get a chance. --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:I noticed that crash also (I think it's the number one crash cause on a genuine XCOM setup) but was never able to reproduce enough to investigate it. I was tempted at one point to patch the GetTileAt function to check its arguments, but finding the cause of the corrupted value would be better. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
::Yes, it's definitely a hard crash to catch, because of how rare it is. I've got a few ideas, though. We'll see if they help. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)
:::Currently, my guess is that this line:
:::<pre>.text:00420534 BE 01 00 00 00 mov esi, 1</pre>
:::should be "mov esi, 0" instead.
:::To sum up the issue:
:::The way the 'click on air to move to a tile below unit' part of MoveUnitTo() works is that it examines each level below the unit until it finds a floor to move to. It does this by looping through the level below you, incrementing esi to loop through the next level below that, and so on. To do this correctly, esi should start at 1. However, the X-COM programmers appear to have made an oversight: they initialized esi to 1, but then incremented esi again before the initial value actually gets used. The net result of this, is that we get zpos += 2 for the very first cycle. This works OK on floors 3 and 4, but for floor 2, it will attempt to access a z level that doesn't exist (one below the ground), causing this line: <pre>(char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize);</pre> to exceed the bounds of the *pMap memory block. Obviously, running off the end of that block will cause unpredictable results, and if it reaches into a block that isn't allocated, it will crash. That's why the actual crash is very rare: it has to overrun into an unallocated memory block.
:::Of course, I could be completely wrong, but it makes sense, and patching 'mov esi, 1' to 'mov esi, 0' doesn't seem to cause any problems. I'm going to be testing with that patch enabled from now on, to see if I crash in that circumstance anymore.
::Looks like you are right. I instrumented the code and there are indeed systematic out of bound accesses when getting out of the craft, though the game does not crash every time. I suspect this is the same crash that happens during base defence when an alien tries to move down from the access lift. Kudos for figuring all this out! I'll provide the fix in the next version. [[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)
:::By the way, Seb, the 1.21 source code doesn't include autosell.cpp; I assume it's a simple oversight. I reconstructed it to get it compiling properly. Just wanted to make sure you knew. --[[User:Xusilak|Xusilak]] 20:37, 26 March 2010 (EDT)
::Oops, forgot to check the unversioned files before checking in...[[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)

== Minor cosmetic enhancements? ==

Had these ideas come to mind while I was at work today, and since your loader is doing some amazing things for the game, I thought I'd ask if the possibility of any of these enhancements exist.

The short of it is: Are you able to overlay any additional bitmap surface on top of the battlescape view, and are you able to play additional sounds?

The main idea for drawing an extra bitmap (semi-transparent) over them map would be to simulate rain/snow for some outdoor maps. Lightning even - though that would require clever use darkening and lightening the overlay. This would have some issues attached to it such as knowing when to display it and when not to, thanks to the various other screens available.

As for playing sounds, which would be simpler, would be to play a looping sound clip to provide environmental sound effects, such as insects chirping and owls hooting at night in woodland maps or town noises at terror sites. Or during the day in a jungle map, some tropical bird calls made at random intervals. TFTD already does the looping environmental sounds, such as teh under water bubbly noises or the wind and sea noises when on land mission. Would it be possible to duplicate this for UFO CE?

Not the most important of enhancements, but I was still wondering if the possibility is there.

-[[User:NKF|NKF]] 01:41, 25 March 2010 (EDT)

== Save/Load shortcuts ==

Seb, would it be possible to enable shortcuts for the Save/Load in geospace & tactical (like F2 or F3) ? ;) except for saving in the final battle (from level 4 if remember) :)

Other things:
- rosvell incidents occured for me too often - 5 in the first month while there was no other alien craft movement detections

- option to disable mission briefing window with the only ok button :) supposedly for advanced users ;)

== Aliens continue using pistols&rifles ==

Hi Seb, sorry to bother you - i have been playing X-COM titles on and off for about 10-15 years now, and one thing always bothered me: Why do the aliens always swith to heavy plasma (or the Sonic cannon in case of TFTD) later on? It encourages the player to swith to heavy plasma too, if only for the free ammunition you almost drown in later on. Would it be possible to have the aliens continue using the plasma pistol&rifle after june/july? It would make using those weapons more feasible, getting ammunition during missions and not having to use elerium to produce it.

Another request (don't know if it is possible) - let the aliens continue using the abductor and the harvester for the respective missions. Later on, all you get are large scouts or even battleships doing those missions - getting some variety in there would make the endgame more interesting. You get to do 50+ battleship missions in a game, but only 4 or 5 with a harester/abductor. Those ships should see a lot more use during the missions they are "designed" for. The "[[MISSIONS.DAT]]" page says something about ufo and mission counters and their associated ufo-types - would it possible to modify those entries via the loader?

Regards, Equinox

== ALIEN MISSION DATA CLARIFICATION ==

According to
[http://ufopaedia.org/index.php?title=Talk:MISSIONS.DAT#Alien_missions_data_discovered_in_geoscape.exe_.5Bfinally_.3B-.29.5D link title]

I found it in TFTD. At offset 505448 (decimal) is starting (mission Probe). Next Interdicition/resource raid/infiltration/colony expansion/surface attack/Floating base attack

I understood what is 3-rd word. If You interesting - I can exlain

Seeing speeds of USO sub we can determine the mission of this USO sub even without transmission resolver - even in january 2040
Every USO sub in every missions (interdiction, colony, probe and other) have unique speeds and we can determine mission of USO on their speed
And we can determine what amount of times a sub touch down on his mission - because every mission has unique rule for touch down USO subs
And we can determine what amount of time USO Sub will touch down on their mission - because every Sub in every mission has unique and ALWAYS equal amoun of time to touch down (p.s. this time we can see in file Loc.dat)
Here - I attached file speeds.zip
[http://www.strategycore.co.uk/forums/Ion-Beam-Accelerator-in-What-file-t8099.html&view=findpost&p=95994#entry95994 link title]

3-rd word - it is reference to unique speed of each sub

4-th word - is time that precede to arrive next uso sub. In other word, in line ufo/c 0/0 if time = for example = 200 - it's time to arrive sub that indexes 1/0.
And where can I get time to arrive EXACTLY sub 0/0 is incomprehensible for me. I assume that this time contain at similarly word of last uso for this mission - but its'not truth because at some missions time in the line of last ufo/c = 2 half-hours and it's means that ufo/c 0/0 can to arrive at new month at 2 half-hours. It's true for Surface attack Mission but not truth for other missions.
I assumed that time in line ufo/c 0/0 - that time to arrive for NOT next ufo - and I assumed that it's time to arrive exactly ufo/c 0/0 itself. But many my tests (more than 100) denies my suppositions.
In example, at line ufo/c Cruiser mission Colony Expansion time in file =2. Cruiser in that mission arriving much more than 2 half-hours after Escort. Instead Fleet supply Cruiser in that mission arriving after 2 half-hours exactly after Cruiser.

'''Question - Where can I find time to arriving for ufo/c 0/0 for each missions except Surface attack mission ?'''

I am sorry for disturbance and will great thank for you for help.
:After the first month the game creates a mission per month, up to the 6th where it generates 2. I guess a mission starts immediatly, there is no timing added for its first ship. [[User:Seb76|Seb76]] 15:18, 30 April 2010 (EDT)

Mission starts not immediately. often time to arrive to survey ship (first sub) about 10-15 days.
1-st day of month at 0-00 we can see it time at Missions.dat but wants to know average time similarly such average time for other subs from alien data mission at executable if possible.

What is exactly 6-th? mission from Probe to Colony Expansion? or from January to June?
:Yep, 6th month. [[User:Seb76|Seb76]] 20:04, 30 April 2010 (EDT)

what happens after 6-th month June?

I so sorry for reminder and bother you, but don't you know it? ((

== Formules about Retaliation/Floating base attack mission ==

Hi

My great respect to you for you formules
I need few help. I am great thank to you in advance

Now I found alien data missions in TFTD (in a similar in EU ) and I ask generously to you to check 3 your formules in TFTD. Is these same or not?

1. After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours
:Xusilak is more knowledgeable than I concerning TFTD. I cannot help you here... [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

Formule 2 and 3 probably contins mistake. formule 'll have to have symbol > instead symbol <. Otherwise retaliation mission activates more often on Beginner diificulty than Superhuman difficulty. Is is strange.

2. A retaliation mission will be scheduled if RAND()*100 < 4*(24-difficultyLevel).
:There is indeed a mistake there. It's been so long I cannot remember if I got it wrong or just messed it up wikifying it ^^ [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

3. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from. The first UFO is scheduled in 100 half-hours (the value is taken from the table I speak of later at the bottom of this page).

And RND() - what values may has? from 0 to 1 or not?
:When I write RAND()*100, it just means a random number between 0 and 100. [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

I will be very thank for given help

== MISSIONS.DAT formula clarification ==

Hi Seb76. I've been having a discussion with Alexchamp and trying to interpret the formula you mentioned on [[Talk:MISSIONS.DAT]] about retaliation missions being scheduled after a shoot down. Namely: if RAND()*100 < 4*24-difficultyLevel

We mainly need clarification on the logical operator. Should it be less-than or greater-than?

As it reads now, it could be interpreted as though retaliation missions are generated more frequently on the easier levels. But if we treat it as >, then this means that retaliation missions are generated about (Beginner) 4%, 8%, 12%, 16% and (Superhuman) 20% (or 28% for TFTD) of the time on their respect difficulty levels.

If you could clarify that for us it would be great, thanks. - [[User:NKF|NKF]]
:Yep, I goofed up. Don't take everything I say as gold ;-) [[User:Seb76|Seb76]] 14:45, 30 April 2010 (EDT)

And I precise too one '''mainly moment'''. Whether there must be the opened bracket after the sign of multiplication? Because if no, then right interpretation formule in Superhuman example such: Rand*100>4*24=96-6=90 and that means that retaliation mission would be sheduled in 10 cases from 100.
IF there must be opened bracket then rand*100>4*(24-6)=4*18=72 wouid be sheduled in 28 cases from 100
What is this versions is right?

Then needs clarification for second formula yours. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from.
What logical operator there? should it be too greater-than or less-than?

You have found later formules about activation retaliation mission (if we shotdown alien craft)
Where exactly in assembler is subprogram that determines it? What address/offset of it?

== COLONY SUPPLY MISSION ==

As we know, When alien base built, Fleet Supply Cruisers with missions Colony Supply can to arrive to this base.

Where can I see (file/offset)
1) average time to arrive colony supply ship for examle/at least in XCOM-EU. As I said later, in responsible offset is time '''to PRECEDE to ARRIVE NEXT UFO SUB''' '''it's not''' time to arrive this sub
2) real time to wait arriving colony supply ship similarly times in file Missions.dat

According to [http://www.strategycore.co.uk/forums/Colony-Supply-ship-time-to-arrivin-t8103.html&view=findpost&p=96011#entry96011 Colony Supply - time to arriving]

If guesses of NKF is right, we need to formule of probability to arrive Colony Supply ship.
Can you to render courtesy with this formule?

Thank you very very great in advance
:I added details in the LOC.DAT talk page. The supply ship is spawned randomly and starts its mission. There is no "time to first supply ship" that I can see. [[User:Seb76|Seb76]] 15:11, 30 April 2010 (EDT)

Thank tou very much for this clarification. I found this offset in TFTD even. Changed, checked - it works.
You are greatly people!

== Roswell mission bug? ==
Hello, Seb76.

I've just had two consecutive games (meaning, I restarted the application and began a new game) where the same strange behavior occurred.

Both games had Roosevelt mission as the first one. It showed the window (type, terrain, UFO size) as usual. Afterward, whenever I clicked on it (to check mission conditions again), it showed a typical "hyperwave transmission decoded" window, stating race/mission type, etc. Needless to say, I had no decoder at this time, since it happened both times in the first game week.

I have a saved game if you want to take a look at it. It's completely reproducible, at least for me. You just click on the white cross and get this window.

Also, I'm using plain CE version with a "complete UFO patch" from StrategyCore. The saved game was not hacked in any way.

Cheers!
[[User:Rovlad|Rovlad]] 10:08, 30 April 2010 (EDT)
:Hum, I gave it some shots but could not reproduce your problem. Anyone experiencing the same problem? [[User:Seb76|Seb76]] 15:36, 30 April 2010 (EDT)

::Here's the [http://rovlad.nm.ru/GAME_1.zip savegame]. Let me know if it works fine for you. [[User:Rovlad|Rovlad]] 21:47, 30 April 2010 (EDT)
:Looks like the CRAFT.DAT entry is not cleared when a new craft is created and the offset 0x64 could be garbage till the craft is detected by a base/another ship. Since I bypass the detection when "crashing" a UFO, it is possible the "HWD detected" flag is set randomly, producing a full report. I'll clear the bit and we'll see if it corrects the issue, just wait for the next release. Thanks for providing the savegame BTW. [[User:Seb76|Seb76]] 14:22, 5 May 2010 (EDT)
::You're more than welcome. Fantastic job on the extender, keep up the good work. [[User:Rovlad|Rovlad]] 19:04, 5 May 2010 (EDT)

== ALIEN RACE SPAWN ==

Your post: In EU, the race is based off a lookup table starting at offset 0x46E53C (containing 300 entries).

Offset-0x46E53C is absent. Is one symbol odd?

Your posr:The table is made up of 10 entries lines.

It means that this bit of array has 10 rows width of 30 bytes. is right?

What is means this 10 entries lines? Can you copy 2-3 lines from exe and explain that means known for you offsets in line?As simiilarly as you done for alien data mission in file Missions.dat
Can you get more particularly answer about values it this array?(naturally if know it)
:0x46E53C is the address in memory. In the file it should be 0x6E53C (UFO Gold edition).
:The begining starts like this:
.data:0046E53C byte_46E53C db 0, 0, 0, 0, 0, 0, 0, 1, 4, 4 ; 0
.data:0046E53C ; DATA XREF: CreateAlienMission+15B�r
.data:0046E546 db 0, 0, 0, 0, 0, 1, 1, 4, 4, 4 ; 0
.data:0046E550 db 0, 0, 0, 0, 0, 0, 4, 4, 4, 4 ; 0
.data:0046E55A db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E564 db 0, 0, 0, 1, 1, 4, 4, 4, 4, 4 ; 0
.data:0046E56E RaceForTerrorMission db 0, 0, 0, 4, 4, 4, 4, 4, 4, 4 ; 0
.data:0046E56E ; DATA XREF: GeoPerformMonthlyActions+15E�r
.data:0046E578 db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E582 db 0, 0, 0, 0, 0, 0, 1, 4, 4, 4 ; 0
:till the end:
.data:0046E67C db 0, 1, 1, 2, 2, 2, 3, 3, 2, 4 ; 0
.data:0046E686 db 0, 0, 1, 1, 1, 2, 2, 3, 3, 4 ; 0
.data:0046E690 db 0, 1, 2, 2, 2, 2, 3, 3, 4, 4 ; 0
:As you can see, at the begining you'll get tons of sectoids (0), a few floaters (4) and even less snakemen (1).
:At the end, you'll get ethereals (2) one time out of two. Also note that for terror missions, the line is taken a bit farther than normal missions, which means that you'll get stronger aliens sooner in terror missions. HTH, [[User:Seb76|Seb76]] 13:36, 5 May 2010 (EDT)

Thank you greatly for your detailed answer ...
I want a few more precise ...
I right understand? I guessed That line 1 - is used for January mission Research? Line 2 - Jan Harvest? Line 3- Jan-Abduction Line 6- January Terror?
What define Line 7?
Line 8 - is February Research?

According to - Line 13 -Feb terror? Line 20 - March terror? Line 27 -April Terror? Line 34- May terror? that sequence and guesses is right?

And question 2) does affect score to choose the value among values in line? How differ choose values in line at the level superhuman and level beginner ?
If you know, naturally, I would be greatly thanks to you for this wonderful magic help.

== Research tree in executable ==

Do you know location (starting offset) of research tree in EU? and how much entries it contains ? and what means values within this array?

Very great thank in advance for this help to you
:The research tree is not stored as a data array but is a hardcoded sequence of "if this is already researched and that is also researched and such item is in the inventory, then enable this research". Modding this would require a complete reengineering, not just patching. Still feasible though. [[User:Seb76|Seb76]] 13:25, 5 May 2010 (EDT)

What is starting offset (ce version) of this hardcoded sequence? and what is latest offset of it? what is length of one sequence? If possible -what is structure of it briefly? (how much bytes to tech requirements, how much bytes to items requrements)

Thank you for this help '''VERY VERY GREAT'''
:As I said, there are no *sequences* but just a cascade of hardcoded ifs:
:[[Image:Research.png]]
:If you want to take a look, the function begins at address 0x446A0. [[User:Seb76|Seb76]] 07:28, 24 May 2010 (EDT)
'''
Seb76, you are GREAT GENIUS!!!! GREATLY RESPECT FOR YOU!!! THANKS FOR YOU VERY VERY MUCH!!!'''
I have found research tree in TFTD too with your help. Now I can do some changes in it.
Maybe do you know, how can I find subprogram that run 1-st day of any month in assembler code of game?
This subprogram determines new mission's month and terror ship route (in TFTD)
There is not in EU terror ship route, I know. But If you know and tell me - what is subprogram in EU that runs 1-st day of any month, I would be able to edit probability of terror ship route in TFTD.
Greatly thanks in advance to you dear Seb76!
:In EU, monthly actions start here:
.text:0043B9B0 GeoPerformMonthlyActions proc near ; CODE XREF: GeoIncrementDayAndDoMonthlyActions:loc_4420C1�j
:HTH, [[User:Seb76|Seb76]] 16:31, 28 May 2010 (EDT)

== Any way to slow down geoscape time? ==

Is there any way to slow down geoscape time progression on fast computers, esp. multiprocessor ones, where it is impossible to significantly slow it down using utilites like MoSlo and Turbo?--[[User:AVE|AVE]] 03:01, 5 May 2010 (EDT)
:Did you try enabling D3D? If you're drivers are configured to wait VSync, it should limit the game speed (well, if you use a CRT@120Hz it'll still be too fast I guess...). Also is it still too fast if you put it windowed? (enabling both D3D and D3D Windowed options) [[User:Seb76|Seb76]] 13:19, 5 May 2010 (EDT)
::Yes, both D3D and D3D Windowed are enabled. This is even more surprising, because it shows the same results on two different computers (Dual Core one and simple P4Celeron) with different video cards (NVidia and ATI). Both have vsync explicitly enabled. LCD@60Hz both. Also I've tried to use different combinations of Video Pitch, D3D, D3DWin and HQ4x settings - no luck. [[User:AVE|AVE]] 04:20, 6 May 2010 (EDT)
:Personally I've never been able to reproduce this "CE game running too fast" thing people keep harping on about. Perhaps I just have a different perception as to what "too fast" means.

:Anyways, I know [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's patched executable] includes a timer hack for the Geoscape, but I found that makes it run far too slow for my taste. Not sure off the top of my head whether it works with Seb's loader, either - you'd probably need to at the very least need to rename Mok's executable to replace the original in order to try it that way. - [[User:Bomb Bloke|Bomb Bloke]] 05:14, 6 May 2010 (EDT)

== Some problem with edit research tree ==

I want to add new 20-30 commands to research tree. I wrote this subprogram. How can I add it to game?
I tried to write "call sub" instead useless 5 bytes in subrogram research tree. I checked in IDA after it, all other commands is preserved.
And I placed my new subprogram after latest byte of executable file. But game is crashed.
I tried to place my new subprogram after all subprograms and before first byte of idata, but game is crashed too.
All indexes in subprogram was exactly.
in second case IDA displayed "sp-analysis failed".

Where and how can I placed my new subprogram that will be addition to current subpogram research tree?
:To add new code, you need to modify the PE header of the exe file accordingly. I'm not quite knowledgeable regarding the procedure (that's one of the reasons why I made a loader instead of patching the file directly) so you're gonna have to find help somewhere else on this one. [[User:Seb76|Seb76]] 16:36, 28 May 2010 (EDT)

== Update to IDA database ==

Hey again Seb76 :)

After a long time I've come back to your extender, dusted off my copy of VC Express, and decided I'd have another go at doing some UFO modding (don't ask how the first attempt went; it's not pretty! :p )

I'm assuming you've probably updated the IDA database since last time I asked. Would be extremely grateful if I could get the latest version.

Thanks for all the hard work, staring at assembly code all day is no joke! --[[User:K9wazere|K9wazere]] 18:07, 6 June 2010 (EDT)

Arf, didn't realise I could send you an email, so this new section on your talk page is a bit redundant now :p Oh well, maybe someone else will want the file too!

== Line of Sight Origin Points ==

Hiya.

A while back you mentioned the co-ords for the [[User talk:Bomb Bloke:Firing Accuracy#Firing Point Origin|firing point origin]]. The zpos is calculated according to the unit's effective height, and the x/ypos co-ords come from look-up tables depending on which way the unit is facing.

I was wondering, are these same two tables used for the purpose of line of ''sight?'' And by any chance could you find the formula for the initial LOS zpos?

Any help would be appreciated, as usual. There are many other obvious questions around this issue (such as where the ''end'' point for these lines is), though the origin would be a good start. - [[User:Bomb Bloke|Bomb Bloke]] 07:44, 24 June 2010 (EDT)

== Training Stat Request ==

Hi there.

In the Equipment screen where the Weight and TUs are displayed during battle, would it be possible to also include the current unit's number of Reaction shots, Hits, Psi attempts and (possibly) Throws? Possibly along the bottom in a horizontal string where there's room?

User talk:Seb76

2011-03-30T02:01:47Z

Mannon: /* UFOloader and Xcomutil */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

My problem is the following: if I try to run the loader normally, a console window pops up for a few seconds then I get an "illegal instruction" error from NTVDM (and the window disappears, yet it's button remains on the taskbar until I kill the process). If I try to run it with DosBox however, I get "illegal command: UFOLOADER.EXE". Point is, I can't run this at all.--[[User:Amitakartok|amitakartok]] 11:27, 13 October 2009 (EDT)
:Looks like you're trying to use the DOS version here. Only the CE (windows) version is supported. [[User:Seb76|Seb76]] 13:48, 13 October 2009 (EDT)

Hi, is it in any way possilbe to run the Extender in Win98? I just set up an old machine with it and wanted to give it a try but as you said above, it won't work with Win9x. But is there a way to manually mod the game? I am asking becaus on my WinXP Machine the game often crahes in battlescape and that really sucks =(--[[User:Skaw847|Skaw847]] 19:28, 21 May 2010 (EDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)
:::I for one am a huge fan of XcomUtil, though I'm now also a huge fan of UFO Extender! I'm really hoping I can get the two to play nice. I was up until now playing a dos version, myself. Mainly because the version I bought years and years ago was the DOS version on CD and it still worked via dosbox, which also has several filters similar to your HQ4x. (Some run a little faster and I think they can run in a window while I can't get HQ4x to run windowed at all. I don't mind that so much, though the game runs noticeably slower when I run HQ4x and I prefer to run windowed these days so I can more easily multitask. Still I LOVE UFO Extender so I switched to the Windows version just for this.) Some of XcomUtil's features only work in the DOS version with split exe's because it goes back into the batch file and allows XcomUtil to play with things when switching from Geoscape to Battlescape and vice versa. But, it's not that big a deal for me. UFO Loader's feature list is more than robust enough to give that up. As for the sounds the Windows CE versions changed a lot of the sound effects. If you're used to this version then it's Np, but if you played the DOS version and got used to it then it's VERY off putting. Luckily it's easy to patch it back to the DOS sound effects. The "Enemy Unknown Extended" page here lays out an install that includes UFO Extender, the original DOS sounds, ect... It's a good place to start. Anyway, great tool. Now let's see if I can get these to play nice.[[User:Mannon|Mannon]] 04:40, 27 March 2011 (EDT) (I keep forgetting to sign things... too used to forums instead of discussion pages.)
::::Facinatingly XcomUtil actually DOES split the CE's executable into geoscape.exe and tactical.exe! It uses it's own sdump utility to do this during the setup batch file. I misread the above. XcomUtil splits them to preserve it's fuctionality so that it can use the batch file to knit them together like in the original DOS version and insert it's own exe into the mix. This does not make the windows exe run in DOS of course, but it does allow XcomUtil to keep it's functionality. I have to assume it really screws up UFO Extender, though... ;-( [[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)

Decided to look into this as there are a few XcomUtil features I like that aren't reproduced in UFO Extender. XCU does indeed split the exe. It also modifies both of the split exe's. It still loads both via fodder's loader when running them from the batch file. The command lines for that are "start /w xcloader geoscape.exe "0"" and start /w xcloader tactical.exe "1". Replacing xcloader with UFO Loader appears to work for tactical. The command line even appears to point UFO loader to the tactical exe since going into combat causes a problem. If I change the first xcloader call to "start /w xcloader" then the renamed UFO Loader finds the unsplit exe. Going into combat no longer fails like this, but it also prevents XcomUtil from running between phases. This does not prevent the running of XCU completely, but it will cause problems with some features, especially in the placement of soldiers in the new craft maps that XCU adds. Then again, by using the UFO Loader to use the original unsplit exe I believe that you are also bypassing all of XCU's modifications to the exe's as it probably does all those modifications to the geoscape and tactical exe's it created when splitting the exe. It may be possible to recombine those exe's or to find command line parameters that allow UFO Loader to load tactical.exe on it's own. The latter would probably be the best solution since it should allow XCU to function between phases.[[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)
:Splitting of the exe is accomplished by first simply copying it with both of the destination filenames. Then sdump is run on each one using settings from XcomUtil.cfg to essentially transform each one into the geoscape only and battlescape only versions. The settings are available in the cfg, but not documented so I don't really understand them. Though... it is actually starting to make some sense as I compare the cfg to the sdump documentation in XcomUtil.txt. Seems like it would be possible to reverse the patch, though it might require first extracting the correct data from the unsplit version. Note: The split up geoscape.exe and tactical.exe are exactly the same size as the original ufo defense.exe, thus data was not removed by sdump, merely changed. I think the only change needed were to cause geoscape.exe to exit at the right time instead of going immediately to the battlescape, and for tactical.exe to go directly to battlescape loading the mission data like the old DOS version.[[User:Mannon|Mannon]] 22:01, 29 March 2011 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Could we get TUs (in current/max format) at the inventory screen while on a mission? It would greatly help with swapping weapons among soldiers.

* Could we get little numbers [like on the screenshot of accuracy mod] showing how much TUs an action on the inventory screen would take? Some players (me, of course, included) can't really remember all that reloading from backpack or from a leg slot TUs. Also...

* a "drop all" button, maybe?

* Soldiers' positioning in Skyranger is very good... but with the Avenger it is not so pretty. The ones at the top are not the ones closest to the trap door. Chooseable patterns, maybe?

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.
: '''Save Equipment''' is under development, still some bugs

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
** Eliminate "infinite fuel" exploit for conventional aircraft.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

* Enable native alien melee attacks within Alien Pets. The Floaters are pleading. (At the moment, Alien Pets+Big Brother means a crashed Superhuman Floater Large Scout costs 6-8 X-COM agents; corresponding crashed Sectoid Superhuman Large Scout is only worth 3-5 X-COM agents. Floater Large Terror Ship on just Big Brother : only one agent, and that was due to the top-of-stair pinning bug providing enough TU to do something.) -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Do something to help out the psi aliens as well within Alien Pets, as above. -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Would it be possible to change the master volume level in the game, or at least have a no sound option? [[User:Epiceuropean|Epiceuropean]] 00:26, 12 January 2010 (EST)

=== A few more ===

Do any of these take your fancy:

* Draw the Radar detection radii onto the map as a circle(s) around the base (also for moving aircraft?)

* Show All UFOs (Ultrawave Detector - like Show All Locations, but doesn't show Alien Bases, you still have to hunt for those).

* Sensible Ammo Recovery = add up all remaining rounds of ammunition at the end of a mission (in the ship, if Aborting), and recover a number of (full) clips equal to that number divided by the clip capacity (rounded down maybe).
: There's a reason I didn't turn Clip Recovery on, and it's that I guessed that it didn't work exactly as it's suggested here. If it did work like this, I would use it. [[User:Stubbs|Stubbs]]

* Implement tactical time limits for UFO Assaults/Recoveries. After a random period (within a pre-defined upper and lower time limit), the aliens leave. Pop up warnings appear at the end of each turn, saying the UFO engines are powering up. When the aliens leave, all aliens/items/equipment inside the UFO is gone - no loot, no score. Any soldiers still inside the UFO are considered MIA. The soldiers are ''captured'' in fact - score penalty worse than MIA? There must be one conscious alien inside the UFO for it to leave or attempt to leave. Maybe any live aliens outside are 'beamed' or 'tractored' inside the UFO, complete with their equipment? (E.g. the mission ends and you don't get score for them or their equipment either - just for the corpses and dropped loot).

* No Milk Please: After XCom withdraws from an Alien Base, randomise the base's location and make it hidden again. Just like what happens to the aliens after they fail to assault an X-Com base. Though you would probably still need to locate it within the same country or region so finding it again wouldn't take long I guess. Would it mess things up to move the base to a random part of the world?

* [[User:Spike#Tank mods|Tank Armour and Equipment Mods]]

But I should probably code this up myself, looking at your source code it doesn't look '''too''' hard. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

[[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

* Burning Zombies

It's more or less impossible to prevent Zombies from hatching into Chryssalids by killing the Zombies with fire, since fire does such a small amount of damage, and the requirement is that the actual killing point of damage is done by an incendiary. Apart from hitting them with an incendiary and running away, then waiting about ten turns for them to die (probably repeating the attack once or twice), this is only ever going to happen by blind luck.

It would be much more viable if the rule was (also?) that a Zombie which is '''on fire''' at the time of death would not hatch into a Chryssalid. This is not exactly easy either, but it is at least possible. It requires hitting the Zombie repeatedly with incendiary weapons until it catches on fire, then killing it right away with regular weapons (before the fire goes out).

A much easier version of this approach would be to say that if the Zombie is killed while it is '''in fire''', it does not hatch. But that is probably too easy.

A way to do this by hacking game files, without code changes, would be to increase the Zombie susceptibility to fire, to 200%. This would make incendiary weapons a viable way of killing them, as well as increasing the likelihood that the killing shot was an incendiary shot.

An alternative approach would be for the Zombie to have a chance of not turning into a Chryssalid, proportional to the percentage of health damage that had been caused by incendiaries. But that's probably too hard to track, it would require an extra/unused field in UNITREF.DAT.

[[User:Spike|Spike]] 13:12, 7 September 2009 (EDT)

* Fear of Fire

Apparently there is no morale effect from [[Incendiary#Damage|Incendiary damage]]. If anything, for humans, and maybe be for other humanoid aliens, fire should probably have a greater morale effect than ordinary damage, not none. A basic fix would treat fire damage the same as normal damage when reducing morale. A more complicated fix could add a weighting to this morale effect: multiply by the creatures susceptibility to fire (or reduce by its resistance to fire). Any creature or soldier that is immune to fire should not have its morale affected. Actually the affects of fire vary quite a lot (different aliens, different human armour types). Maybe this is why the designers didn't get around to implementing morale effects for fire, as it's a bit complicated.

[[User:Spike|Spike]] 13:40, 7 September 2009 (EDT)

=== Multi Stage Missions ===

Between each stage of a multi-stage mission:

* Send all artefacts (non-usable items), corpses and recoverables back to base
* If possible, remember the score for these items, and apply it to the score at the end of the mission
* Alternatively, pop up a score window between the mission stages, and apply the score then?
* Gather all loose usable equipment into the "equipment pile" for the next stage
* Or possibly re-run the Equip Screen between mission stages, again gathering all loose usable items into the equipment pile first.
* Keep an 80 item limit on what you can take into the next stage
* Prune down to the 80 item limit using some sensible rules, not sure what exactly.

This is of limited use in X-Com EU but would be much more use for TFTD, one day. EU has only one multi stage mission, and it ends the game, so only some of these points above will be relevant.

[[User:Spike|Spike]] 20:54, 2 September 2009 (EDT)

=== Even More ===

Tremendous work, you've pretty much made the game worth playing again. Best work since Xcomutil. As with everone else, I have a few requests. [[User:KingMob4313|KingMob4313]] 23:59, 12 August 2009 (EDT)

: Ability to change damage modifier. Right now the damage runs from 0-200% of damage values on the weapon. I'd love to see a way to change it to 50-150%, 75-125% or the like.

: A modifier to increase or decrease the explosion radius modifier. Right now the radius is either keyed to the explosive or to the explosive damage. I'll investigate it further. But it would be nice to have a very small radius, but high powered explosive for use as a breaching charge.
:: There is a "crimping" function on some of the explosions already so it might be possible to exploit that. Check the [[Explosions]] page. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

: A modification of the range based accuracy. One handed weapons have a shorter range, to the point that even their aimed shots have an effective range, two handed weapons have a further range (and no aimed shot effective range) and really heavy two handed weapons have an even further range.

: Ability to enable the Burst fire (5 shots over 3 picked spots) and/or the full auto mod that is on the heavy laser on other weapons (set by a flag).

: A modification so that on the alien's side first turn, they do not have their full time units in reserve for reaction fire. Nothing like getting shot 3 times from the same sectiod after missing ONE shot on them.

:: You could always wait a turn before you open the door. :) [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

::: Good point, I should be doing that anyways.

=== More Exploits to Close ===

* [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]

Probably the worst single exploit in the game. What is needed is to disable any mind control actions for a Psi Amp, if the unit holding the Psi Amp is currently mind controlled.

Also a general mind control bug/exploit fix for:

* [[Exploiting Mind Control#Exponential Mind Control|Civilian Traitors]]
* [[Exploiting Mind Control#Exponential Mind Control|Resurrect Zombified Agents]]
* [[Exploiting Mind Control#Exponential Mind Control|Zombie's Permanent Control of Aliens via Stunning]]
: Above 3 bugs are fixed by '''Hostile Civilians''' fix.

* Probably many other missing/MIA-type bugs

These probably all arise from the daft decision to save a single byte (or even bit), by not recording separately the current vs default "side" a unit is on. The game only tracks the "current side". Consequently when mind control ends, the game often makes dumb decisions as to what side to "restore" the unit to. We could use an unused byte to track the default "side", but that would require overloading a presumed "unused" field and that could be risky. But actually we can always deduce the "default side" from the unit type: XCom for soldiers and tanks, Neutral for Civilians, Alien for everything else. So what is needed is just an end-of-turn check to restore everything to its correct side, based on its unit type. Actually it's slightly complicated by alternating turns. You need to update all (originally) Alien units at the end of the Alien turn, all originally XCom units at the end of the XCom turn. You might also need a special end-of-game update, to avoid the MIA-type bugs. [[User:Spike|Spike]] 12:22, 26 August 2009 (EDT)

: AlienSWP.py implements turnswapping via mind control, like XCOMUtil. Handling the alternating turns, as you described, is necessary to make mind control work properly (a mind-controlled alien remains with X-COM during the alien turn, and so on).

: I would assume that the original programming team had a coding policy forbidding both bitfields, and emulating them with bitwise shifts. That's really the only way I can explain most of the idiosyncrasies of the file format. [[User:Zaimoni|Zaimoni]] 12:07, 26 August 2009 (CDT)

=== Soldier Colouration ===

Not the most "practical" request in terms of changes to gameplay, but still something I feel would be pretty cool if incorporated. Basically, the option to have the battlescape engine display soldiers according to their race/hair colour, as according to their inventory screens, [http://www.strategycore.co.uk/forums/post-a1669-.html like this].

The stored tactical [[PALETTES.DAT|palette]] is made up of 16 groups of 16 colours (256 total), in this order (though the last 16 colours are replaced with a grey-scale shade list at run-time, similar to the other fifteen groups - refer to the page on palette data for more info on that):

[[image:5_BattleScapePal.Png|center|frame]]

Solders are drawn using colours from three of these groups: One for their clothing (x50-x5F for overalls/power armor, xE0-xEF for personal armor), one for their skin (x60-x6F), and one for their hair (x90-x9F). Flying suits use a few extra colours, but they don't matter for the sake of this explanation (they don't show hair/skin anyways).

With my [http://www.strategycore.co.uk/files/index.php?dlid=686 battlescape editor] I incorporated a feature where you could have the program redraw units on the fly (as per the screen shot), changing just the hair/skin colour. For example, to check to see if a colour index was supposed to represent hair, it simply checks if "(''value'' & xF0) == x90", and if so, it'd add or subtract a certain figure to achieve the desired colour.

Well, there's a bit more to it then that (males in personal armor have a different hair colour already), but I'm sure the basic concept is obvious to you by this point. If you're interested, you can see a sample function in a file included in my toolkit - "bb_tact\UnitDrawer.java", line 384. It's not exactly well documented, but if you check the hair/skin arrays it refers to, it should be fairly obvious what it does. While the program is running, the "characteristics" variable is set to "true" by tapping C on your keyboard. Of course, I've no idea how the actual game deals with drawing soldiers, but I assume it decompresses every [[Image_Formats#PCK|PCK]] image every time it wants to draw it, same as my code does.

- [[User:Bomb Bloke|Bomb Bloke]] 09:46, 4 May 2010 (EDT)

=== See Also ===

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

== Completed Items - Thanks Seb! ==

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

* More video options. In particular, an option to put padding at the top and the bottom of the screen to preserve the aspect ratio on a 4:3 monitor. Maybe it's just me, but stretching the original height of the game to fit a 4:3 screen makes the Battlescape look weird. (Actually, if you update the source code link, I could try to do it myself. The current source doesn't seem to include your more recent changes. --[[User:Mikawo|Mikawo]] 20:30, 12 August 2009 (EDT))
** Thanks for uploading the new source code. I managed to add the letterboxing that I wanted. If you wanted to make it an official feature I could upload the updated files. And I don't think I said this before, but thanks for the great loader! --[[User:Mikawo|Mikawo]] 18:40, 14 August 2009 (EDT)
:Go ahead and upload/PM me the file (d3d.cpp I presume?), I'll gladly incorporate your modification. [[User:Seb76|Seb76]] 19:14, 14 August 2009 (EDT)

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

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

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

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

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

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

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."
:The above works perfectly. [[User:KingMob4313|KingMob4313]] 00:05, 13 August 2009 (EDT)

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.
:Fixed via Keyboard Shortcuts - and configurable too.
-- Sorry, I am having trouble finding this addition. Is it in the newest version? I can't see where to configure it if so.

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....
Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)
:I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that 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?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human 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?

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).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
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!
:I think this is a known issue with LOS, not sure though
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).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

There are major issues with your current weight calculations. I'm not exactly sure how it was occurring, but repeatedly messing around unloading and loading weapons, switching clips from the ground them putting them back in... at least one of these functions causes 'phantom weight' to be added to the soldier (e.g. strip them bare and they are still carrying a load). This was happening by 3 units of weight at a time; the weight of a clip. It's so bad that I managed to get 18 phantom weight units on a soldier before getting bored. Occasionally, 3 units of phantom weight would be removed again! It's hard to tell if this was in the original game, due to the lack of weight display in the inventory screen.

Edit: I've worked out what's happening. Add a loaded weapon to a soldier, unload it, and remove the ammo and gun: this ''removes'' 3 phantom weight units. But, add an unloaded weapon to a solider and load it... this ''adds'' 3 phantom weight units. [[User:Stubbs|Stubbs]]
:This is a genuine bug because they forgot to unassign the clip of a weapon when you drop it. Also the default weapon's clip is not initially assigned to the wearer so if you unload and reload the clip, your soldier weights more. [[User:Seb76|Seb76]] 13:27, 3 February 2010 (EST)
:: So is this impossible for you to override and fix? It's really irritating... I've edited lots of item weights, but I guess I'd have to make ammo light and guns heavy to minimize the effects of this bug. [[User:Stubbs|Stubbs]]
:::I second that, it would be great if this could be fixed. [[User:Rovlad|Rovlad]] 17:45, 13 May 2010 (EDT)

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

:: Alien reaction fire works fine for me within Alien Pets. -- [[User:Zaimoni|Zaimoni]] 12:41, August 12 2009 (CDT)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)
:Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)

The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. <3
:Uploaded a new version, you need to add a "HQ4x=1" line under the "Mod" section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)

Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)

Now the question is, how do you use DXWnd with the loader?
[[User:KingMob4313|KingMob4313]] 11:02, 12 August 2009 (EDT)

==Works but won't multitask==

Target system: prefab HP Vista with global data execution prevention. Problem is the same native, with D3D, and/or with HQ4X. (The two do combine nicely, visually, but a bit laggy for my tastes).

ALT-TAB terminates all further screen display on restore; the sea of blackness continues until Task Manager is used to kill the application, at which point D3D admits that it has "lost the device". (This is after the improved error reporting patch. Before, 0xc0000005 as Data Execution Prevention takes over.)

-- [[User:Zaimoni|Zaimoni]] 12:27, 12 August 2009 (CDT)

: Solved on Win7 for the most recent version: Program Properties dialog has an "unblock" button. Unblocking allows the program to survive being alt-tabbed away from. -- [[User:Zaimoni|Zaimoni]] 22:03, 24 June 2010 (CDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)
:That's great ;-) By dev I was refering to the "dev" version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)

Hi Seb, I've been playing the UFO series since the beginning but just joined this wiki. I've tried just about every mod there is for these games, and I must say, yours is one of the best as far as creating a "more complete" and stimulating game experience. My question is in regards to your "Heavy Laser" mod. I liked what you did by creating new "abilities" for the weapon with the Full auto and Burst fire mode, but every time I play I can't help but think that it just doesn't belong to the Heavy Laser as a weapon. I always envisioned the Heavy Laser as more of a long range "Sniper" support weapon, and I like the mod that the X-ComUtil added that gave the Heavy Laser a new life by increasing the accuracy and damage of the weapon making it one of the best Sniper weapons available (even if it is heavy to lug around) as well as finaly giving my troops a greatly needed new weapon for disposing of those pesky sectopods (on any difficulty). I do, however, think that the new fire modes (full auto and burst fire) would be a perfect addition to the Auto-Cannon. The in game image alone has always brought to mind a "mini-gun" type weapon that should be capable of very rapid fire, but at the expense of accuracy due to the encumbering nature of the beastly AC. I never liked how the AC seemed like a generic Heavy Cannon with less damage and only the added auto shot function. Also, I always wondered why that weapon even had an "Aim" function. Who's going to sit there trying to carefully aim a Gatling Gun? Nobody... that's who, you use a weapon like that for mass devistation and shock value, PERIOD! This is why I think that your mod to the Heavy Laser should be reconsidered for the Auto-Cannon. I think, at the very least, it will give people a reason to use the AC in the mid to late portion of the game, and being that it still has weak stats compaired to other weapons, it's not going to be overpowered or infringe on the use of specialty weapons (I think the Heavy Laser with full auto and burst fire is a little un-balanced due to its considerably higher power). If you don't agree that's fine, but since I'm not very knowledgeable about game programing, I was wondering if you could at least give me a hint on how to create similar weapon functions for other weapons, cause I'd like to at least try it out for myself. Thanks for any help you can give me and keep up the good work, you're mod is awesome.

== REng UFO with IDA ==

Hi Seb =)

I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.

So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).

Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.

I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.

My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).

Any advice is deeply appreciated mate =)

XCom forever!
--[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)
:Hi k9,
:Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.
:For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...
:Good luck with your project,
:[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)

:::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...

void InsertCall(int dst, void *func)
{
DWORD oldProtect;
DWORD *pOffset=(DWORD *)(((char *)dst)+1);

VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&oldProtect);
*(char *)dst=(char)0xE8;
*pOffset=(int)func-(int)dst-5;
VirtualProtect((void *)dst,5,oldProtect,&oldProtect);
}

::: This calculation here is interesting:

*pOffset=(int)func-(int)dst-5;

:::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).
:The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).
:The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)

:::Can you suggest some good reading material to better understand this? Cheers!
:::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)
:You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the "UFO Defense" process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)

== D3D ==

If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has.

I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)
:You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)

Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)

OK I ran the dxdiag utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)
:Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.
:Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)
Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)

D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J'ordos]] 19:09, 8 August 2009 (EDT)
:edit: forgot to mention, I have directx 9.0c installed and dxdiag reports no problems. I have a Geforce2 MX *blushes*
:Do you know if this card supports non power of two textures? [[User:Seb76|Seb76]] 05:10, 9 August 2009 (EDT)
::no idea, but since your new version works fine with the D3D option on I assume it doesn't :) [[User:J'ordos|J'ordos]] 11:38, 9 August 2009 (EDT)
:That's great. Spike, does it fix your problems too? [[User:Seb76|Seb76]] 16:04, 9 August 2009 (EDT)
::Sorry for the late reply - yes that fixes my problems too, D3D is working fine now. Thanks, [[User:Spike|Spike]] 15:55, 26 August 2009 (EDT)

== Save equipment ==

Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:

*1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of "invisible" equipment!
*Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips.
*The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.
*Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment.

Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked?

Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)
:Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.
:The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?
:As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.
:I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)
::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a "before" and "after". [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)
:In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)
::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns & ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)
:OK, I'll have a look at this, thanks for the effort.
:Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the "i/b" one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)
::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)
::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)
::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)
:I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)
:: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)
:Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)
::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)

Hmm more problems with Save Equipment. Ammo of all types seems to disappear. Eg I have 6 pistols and 6 pistol clips on the craft, but the Equip screen just gives me 6 empty pistols. Other weapons are short of ammo too. Is the Save feature perhaps "remembering" empty weapons (or loaded weapons) and somehow eliminating the clips. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)
:This looks like an issue with ''UnloadClips''(). I noticed that the clip object's ''loaded_into'' is set to 0xff, but the ''not_loaded'' remains as 0. The game may see this as the clip still being loaded in an object, so the clip effectively disappears. --[[User:Mikawo|Mikawo]] 11:05, 19 August 2009 (EDT)
::This is possible. The wiki is wrong on these 2 fields BTW: it is in fact just one field (loaded_into signed extended to 16bit). I'll have a look at that. [[User:Seb76|Seb76]] 14:33, 19 August 2009 (EDT)

I think Mikawo is right. UnloadClips() should look something like this:

void UnloadClips()
{
obpos_dat *pObPos=pObpos_dat;

for(unsigned char i=0;i<170;i++)
{
if(pObPos->itemType != 0xff && pObPos->not_loaded == 0 && IsXComItem(i))
{
pObPos->loaded_into=0xff;
<big>'''pObPos->not_loaded=0xff;'''</big>
}
pObPos++;
}
}

Quite a few other functions in '''equipment.cpp''' use this check '''pObPos->not_loaded == 0xff''' so it is important to set this flag just for UFOExtender, regardless of whether the game needs it set (which it probably does). Eg items unloaded by UnloadClips will thereafter fail to be found by GetFreeItem, during execution of LoadSoldierEquipment. That probably explains the problems observed.
[[User:Spike|Spike]] 15:24, 26 August 2009 (EDT)

:I did some rework based on that. Do you have other problems? [[User:Seb76|Seb76]] 16:08, 30 August 2009 (EDT)

::Thanks Seb. This seems to be working mostly ok now. Some remaining smaller issues I have seen:

::* The weight calculation is so accurate, it is more accurate than the unmodified game. So the "weight free ammo" (the first clip loaded into a weapon, before the user takes any action in the Equip screen) is no longer weight free. Not sure if you want to "fix" this or not? It is debatable. Really, you have fixed a bug. But the normal game behaviour has changed. Maybe make the "weight free ammo" optional?
::* There is a weird glitch. If I unload a weapon, put it and the clip on the ground seperately, that works fine. But if I pick up the clip '''directly from the ground''' and load it straight into the weapon, then drop the weapon, the weight of the clip is still shown on the soldier. And actually the same thing happens with a clip that is first moved into the soldier's equipment. So in fact the problem is that a clip loaded into a weapon, doesn't get removed from the soldier weight when the weapon is dropped onto the ground. It happens even if the clip is pre-loaded by your routine.
::* Still outstanding - you can't use the right arrow to move onto a second screen of equipment. So you can't have more than one screenload of equipment on the ground. Or maybe you can, if you start the Equip screen with more than one screenload on the ground - I didn't check that.

::[[User:Spike|Spike]] 13:10, 1 September 2009 (EDT)

== Glitch with Alien Pets and Big Brother? ==

Hi Seb. I was trying to do some initial research on the idea of [[User:Spike#Tank mods|Tank mods]] but it looked like these 2 useful features of your Loader, Alien Pets and Big Brother, have both stopped working. Can you test this, on the latest version? I'm using a very recent version (last 2 weeks) but not the absolute latest as I have internet download problems.

Also, have you seen this new Wiki article: [[Enemy Unknown Extended]]. It is a package including your loader plus a few other odds and ends.

cheers,
[[User:Spike|Spike]] 11:16, 17 August 2009 (EDT)
:My mistake, I commented out that part of code a while ago and only recently noticed that. It was corrected one or two versions ago.
:The article is a good idea, it should allow less techies an easy start. [[User:Seb76|Seb76]] 13:51, 17 August 2009 (EDT)
:: OK cool yes the Hacks are back in place, thanks. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)

== Alien Bleeding ==

Test results:

* 1-unit and 4-unit aliens can be healed by anyone (alien or human) holding a Medkit
* 4-unit aliens can be healed by standing in any of their 4 squares
* 4-unit aliens can only be healed while they are stunned. Pointing to their "control" square does not seem to work.
* 1-unit aliens can be healed either while conscious or while stunned
* Wounds on aliens can be correctly seen with Medkits
* The Medkit display shows a human silhouette regardless of the alien type, of course
* Healing aliens with Medkits, stops them from dying of wounds (not 100% tested but seems to be true)
* Aliens (large and small) seem to lose the correct amount of Health per turn from Wounds
* Aliens with wounds that are not treated, eventually die (not 100% tested but seems to be true)
* A Mind Probe can see if an alien has Wounds.

Anomalies:

* I had a lot more reports of Reapers dying than I would expect. I would not have expected any to die, and I had 3 reports of death by wounds. Even heavily wounded Reapers take a long time to die. In my test I was only shooting them with Pistols. Maybe there is a problem with the reporting? Maybe the death of the same Reaper was reported more than once? More testing needed on this.
:I wonder if Reapers are receiving wounds on all 4 sections when hit by explosives (I don't know which weapon you were using). They really shouldn't, although I'm unsure how you'd get around this. If possible, put a cap on the maximum number of wounds something can ever have (perhaps 6). You could argue their multiple hearts really empty their blood out quickly, but I don't think fatal wounds should ever become more dangerous than burning alive.

:: Well, why not: hit four times by one explosive, check for incurring fatal wounds four times. -- [[User:Zaimoni|Zaimoni]], 13:49 Sept. 6 2009 CDT

* Question: should the death of an alien by wounds be reported, or should it die silently? Did I only see these messages because I was using Alien Pets, and so they were on "my" side?
:Regarding death reports, I enabled the dialog for aliens/civilians (it usually only shows up for xcom operatives) to help in testing. The final version will not show them. [[User:Seb76|Seb76]] 14:10, 3 September 2009 (EDT)

Caveats:
* I used the Alien Pets, Big Brother, and Alien Inventory hacks to do this test. I also hacked a save game to give me Pistols, Medkits, PsiAmps and Mind Probes. [[User:Spike|Spike]] 16:03, 3 September 2009 (EDT)

To Do:
* Test if aliens (small, large and mechanical) suffer from [[Fatal Wounds#Other effects of Fatal Wounds|other effects of wounds]], e.g. penalties to Energy, Accuracy, Time Units
* Do Cyberdisks, which have no legs or arms and probably no head, only ever receive Torso wounds?

=== Mechanical Bleeding ===

* Question: Do Cyberdiscs and Sectopods receive Fatal Wounds? I'm wondering whether an unconscious Cyberdisc is safe to be around. Even if they didn't explode, Fatal Wounds would be stupid for a robot. If XCOM tanks can't end up leaking fuel and sparking dangerously, neither should enemy robots. [[User:Stubbs|Stubbs]]
: I think you can make a case for tanks and robots having "wounds", i.e. damage that gets progressively worse by itself. You can even make a case for them being "stunned" - temporarily non-operational. You can even make a case for it applying to alien robots but not to X-COM tanks, since alien robots all have some degree of organic component (which is why they can be Mind Controlled). But I still think you are right, neither effect should apply to machines, whether alien or human. As for your question, see the tests below:

Cyberdisk Bleeding Test Findings:
* Cyberdisks take Wounds (with Alien Bleeding option enabled)
* Cyberdisk wounds can be healed (though only after unit is stunned)
* Cyberdisks lose health from wounds
* Cyberdisks can die from wounds
* Cyberdisks don't seem to explode when they die from wounds ("has died from wounds" popup)

Cyberdisk Bleeding TestTest Caveats:
* Same caveats as previous tests (above), plus:
* The Cyberdisks were modified from Reapers using xcomutil :rpl
* Some Pistols were changed to Laser Rifles using xcomutil :chg
* (xcomutil was not installed in the game directory however, it was used from another location)
* The stats (Armour 34 all round, Health 120) appeared normal for Superhuman
* However the Cyberdisks seemed to fall too easily to Laser Rifle fire (e.g. 1 hit)
* Also, they seemed not to explode as often. This was because they were often stunned.
* Hard to tell in-game whether a Cyberdisk is dead or stunned. The graphic is the same, you can't use a Mind Probe, nor look on the ground, nor even check by changing sides.
* Actually there is one way to tell: stand over it and use a Medkit. Didn't think of that. [[User:Spike|Spike]] 08:22, 5 September 2009 (EDT)

:Thanks for finding out, Spike. Autopsy text shows you are right about the Sectopod( but not about the Cyberdisc) having biomechanical components, but it's not like there are gallons of blood pumping around the thing to gush out. One thing: did you check both conscious and unconscious death-by-wounds for the Cyberdisc? [[User:Stubbs|Stubbs]]
::No problem Stubbs. I didn't deliberately test this, but I had numerous deaths-by-wounding while unconscious and I think at least a few while conscious. I believe those that died while conscious, exploded. (I think this is the basic rule for Cyberdisks. If they are stunned, they don't explode. This typically happens with stun weapons but can also happen with regular weapons, if you are lucky.) [[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)

* Seb76: maybe robots receiving wounds was an oversight, or maybe you really do want robots to take wounds. In either case, it would be nice to have a separate option for this. My arguments against robot wounds are pretty simple: tanks do not receive them, the bled-out dialogue "X has died from a fatal wound" sounds silly for a robot that was never alive, and finally that a Medkit should not be able to heal a robot.
: It's reasonable that alien mechanisms (Sectopod, Cyberdisk) would not suffer from wounds. Possibly also Zombies should remain immune to wounds? From a note Seb made elsewhere, I think the UNITREF.DAT "can be wounded" flag is the same as the "can be stunned" flag. Wounding is probably prohibited globally for aliens, by an override somewhere in the executable. Seb has probably removed this override, unconditionally. To remove the override more selectively, I suspect Seb would need to put a logic test in the code, to check the alien type. .[[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)
::There was a check for ownership that I simply removed. Next version will have an explicit check for robots/chryssies/zombies not to bleed. [[User:Seb76|Seb76]] 12:29, 6 September 2009 (EDT)

* If you want a sense of "the Sectopod's leg got damaged" or even "the tank's track was broken", perhaps robotic units could be 'wounded' by damaging max TUs.
* If, however, the above won't let weapon usage TU %s recalculate as TUs are lost (i.e. the units lose firing ability as well as walking), then certain values of Energy with the correct Energy usage modifier could emulate loss of speed without losing firing ability. Since Energy is returned at a rate of 1/3 of TUs, these units could have an Energy value of (slightly less than) exactly 1/3rd of their TUs. Their energy usage modifier is then changed to allow this small energy value to usually suffice. Now, when Energy is damaged, the units will be permanently slowed, but their weapons won't be affected. [[User:Stubbs|Stubbs]]

=== Zombie Bleeding ===

Zombies that bleed to death don't seem to turn into Chryssalids. As discussed above, it might be better to disable wounding for Zombies. (Death by wounding for Zombies was already possible, without this fix, if the Zombie was mind controlled, wounded while mind controlled, then released back to Alien control.) [[User:Spike|Spike]] 21:07, 5 September 2009 (EDT)

== Hostile Civilians ==

This fix also seems to prevent:
* [[Exploiting_Mind_Control#Zombie's_Permanent_Control_of_Aliens_via_Stunning|Permanent Control of Aliens via Stunning]] Exploit - as was hoped for.
* [[Exploiting_Mind_Control#Resurrect Zombified Agents|Permanent Control of a Chryssalid/Tentaculat]]

It does not fix:

* Various Mind Control bugs:
** [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]
** [[Known_Bugs#Mind Controlled Aliens Count as MIA if you Abort]]

(Probably because fixing both of these requires special, end-of-mission processing)

Still To Be Fixed:

* [[Exploiting_Mind_Control#Exponential Mind Control|Exponential Mind Control]]

(This requires a check in UNITPOS to ensure that the unit attempting Mind Control is not, itself, already mind controlled.)

[[User:Spike|Spike]] 16:16, 3 September 2009 (EDT)

== Fixed Funky Fire and Zombies ==

Fixed Funky Fire still permanently kills Zombies, when the killing damage comes from (end of turn) fire damage. [[User:Spike|Spike]] 21:02, 5 September 2009 (EDT)

== Research Tree ==

I've found a way of modding the research tree and was wondering if people are interested in an updated version. I've read of stuff like enabling hovertanks from cyberdisc autopsies or flying suits with floater research, but I think there is more that can be done. The limitations from the original game is that having researched a topic cannot unlock more than 4 new topics, and cannot unlock the production of more than 4 new item types. Any ideas? [[User:Seb76|Seb76]] 12:40, 6 September 2009 (EDT)

* Another one I mentioned was: Mind Probe before Psi-Amp, although I'm going to retcon that to "Mind Probe before Psi-Lab" (which then leads to Psi Aimp as per usual). The logic behind this is that the first step of a psi-attack must be scanning for enemy brainwaves to pick them out of the other signals. Before you can teach soldiers to do this, you'd have to have studied the mind probe to see how the non-psychic aliens are managing to find targets. You've got to walk before you can run, after all.
* I'm unsure if the next suggestion is possible, given what you have said. I'd like some kind of necessity to research at least some corpses/aliens - is it possible to require, say, any 6 alien 'live' or 'autopsy' reports finished before Alien Origins unlocks? You might also make it dependent on difficulty (6/7/8/9/10 needed). You could also include alien missions in this count.
* My only other suggestions are: you should have to research Elerium before you can build anything that requires Elerium to build. You should have to research Alien Alloys before you can build anything that uses those (which is true only for some things currently. It doesn't seem to be a prerequisite for building alien weapons). Is it possible for a manufactured item to require two separate research entries to be manufactured?
* Question: is there also a limit of 4 prerequisites for a research item? [[User:Stubbs|Stubbs]]
:There is no limit on prerequisites, it's the code that shows "you can now build/research xxx" that has a 4 entries limitation. [[User:Seb76|Seb76]] 15:05, 6 September 2009 (EDT)

A boring suggestion but how about making sure that for all weapon research, you need to do the pistol before the rifle before the heavy weapon, etc. And similarly with the ammo types. Apart from that, I'll think on it. [[User:Spike|Spike]] 17:42, 6 September 2009 (EDT)

Another boring suggestion: each specific laser weapon should take a little longer to research - force you to use the starting weapons for a little longer. You could also rebalance the Plasma research times so that the rifle took a little longer and the Heavy Plasma took significantly longer. It might then be more viable to research them from weakest to strongest, without forcing your hand as Spike suggested. [[User:Stubbs|Stubbs]]

:Yep that's a good alternative.

You could make the Stun Launcher a little harder by requiring (as well as Alloys and Elerium), perhaps a live Medic to be researched before the Stun Launcher (since it's usually Medics that carry them and presumably understand how to operate them), and an Engineer for a Blaster Launcher. It's not much extra but it helps to make these powerful weapons a little harder to get. If you wanted to make Blaster Launcher quite a lot harder to get you could add something like UFO Navigation (something to do with plotting all those waypoints, alien-stylee), or at least a Mind Probe for similar reason.

But, what are we trying to do here? Make things harder in general? That's one option. Or "rebalance", i.e. make things that are relatively too easy to get, relatively harder to get? Or make things more "logical"? There's lots of ways to play this.

It's a shame there's not a distinction in the game between using, and manufacturing, alien weapons - as is done in XcomUtil. Really, there should be a world of difference between figuring out how to use scavenged alien weapons, and actually being able to manufacture them. But that's not really a research tree topic, '''unless''' - would it be possible to create new topics? Could you separate out the using of an item from the manufacturing of it? (If not, it would be good to have a game variant in which nothing that can be scavenged, is allowed to be manufactured).

UFO Navigation might also be a good prerequisite for Hyperwave Decoder. I'm sort of rambling here, but what are the most powerful technologies, that are kind of easy to get... which ones need to be made harder. (Are there any that need to be made easier?)

Powerful technologies:
* Psionics (Psi Lab == Psi Amp). Adding the Mind Probe, as suggested, would be a good idea. Maybe a psionic Commander capture required for each.
* Blaster Launcher - maybe require an Engineer and a Soldier research, as well as Elerium & Alloys. Mind Probe or UFO Navigation for the "plotting" element? A separate Engineer capture to produce the ammo? What else?
* Stun Launcher - Medic and an Engineer? Maybe a full set of autopsies - but that's too onerous.
* Heavy Plasma - stretching the research time would be good, though this can already be done. Additional pre-reqs - maybe add a live Engineer requirement (maybe for ''each'' Plasma weapon type?). If you keep making these requirements you probably need to add a hint in the UFOPaedia along the lines of "we will need to interrogate alien technical experts to further understand this weapon technology". (OK that's hardly a hint.)
* Laser Cannon (?) - But I'm not sure this Laser Cannon factory thing is a big deal. Arguably building a new intercept base is a better cash cow than building a 50-Engineer Laser Cannon factory.

[[User:Spike|Spike]] 16:34, 8 September 2009 (EDT)

== 64 bit compatibility ==

Any way to make the loader compatible with 64-bit operating systems, like 64-bit XP/Vista/7? [[User:Jwilcox25|Jwilcox25]]

: I'm using it on Windows 7 and it's working fine. Not sure if that's 64 bit though. [[User:Spike|Spike]] 07:26, 9 September 2009 (EDT)

:: If you're not sure, you are probably running the 32-bit version of Windows 7. Starting from XP, Windows comes in both 32-bit and 64-bit flavors. Most 32-bit programs are backwards compatible, but apparently not X-COM from my experience. [[User:Jwilcox25|Jwilcox25]]

: It works fine with Windows 7 64-bit. Didn't have to enable any compatibility options or anything like that. [[User:Rovlad|Rovlad]] 02:29, 23 April 2010 (EDT)

== Music bug ==

When enabled "MIDI freeze" bugfix, after entering first combat the music stops playing completely, for the remaining game session.

Also, when using Extender, for some reason music is playing at really low volume, i have to manually reduce my main sound channel and crank up the volume to hear it. When just starting normal UFO CE volume levels of music and sfx are about equal. I have SB Live & WinXP.

== Fire Speed bug ==

Sometimes, for no apparent reason, fire speed setting jumps to 3, instead of what you had it set on.

: I believe it's a bug in the game itself, not the loader. I remember encountering it in both DOS and CE versions. [[User:Rovlad|Rovlad]] 02:31, 23 April 2010 (EDT)

== Reserve TU for x-Shot ==

Not sure if this has been addressed or fixed, but if you reserve Time Units for any shot type, all you get is Snap Shots for the reaction phase - never aimed or auto. Is there any way you could enable these two unused types for reaction shots? --[[User:Zombie|Zombie]] 22:51, 25 October 2009 (EDT)
:As far as I can tell, the reserve is only meant to be used during the active turn. Reaction shots are hardcoded to snapshots (that's true for the aliens too), it's no bug that your guys don't use reaction autoshots. [[User:Seb76|Seb76]] 12:10, 16 January 2010 (EST)

== TFTD ==

I know you're hoping to perfect the current version before taking on any new projects, but I just want to add my plea to the others requesting a TFTD version. Even some of the basic functionality would be awesome and probably completely portable, such as the stats on the equipments screen, default new base, etc.

== Can't change tasks in D3D ==

Hey, I'm having an issue with D3D. If I alt-tab out, I can't switch back to the X-Com task. I'll switch to it but nothing can happen. I'm on Windows 7 x64 with an ATI Radeon HD 5770. [[User:Rlbond86|Rlbond86]] 20:19, 15 January 2010 (EST)
:I too have hangups sometimes when alt-tabbing out of XCom, sadly I'm no D3D expert :( I'll add more checks to see if resetting the D3D device worked though. If anyone knows of a 100% working way of dealing with "device lost" conditions, now is your chance... [[User:Seb76|Seb76]] 12:06, 16 January 2010 (EST)

== Battlescape Soldier's Stats Crash ==

I'm having this little problem with this and I wanted to know if I'm the only one that's suffering with it: everything works fine, but when in battlescape mode I want to check the stats of a soldier (by clicking his rank icon) the entire game CTD. Does it happen to anyone else? How can I fix it?
:Never saw such problem...
:* Does it still crash when you disable the extender (and what options did you enable)?
:* Do you have the address where the crash happens?
:[[User:Seb76|Seb76]] 15:55, 22 January 2010 (EST)
::It didn't, but now I reinstalled the game and it works wonderful. This is a great job you did here. Is there any chance that you could access to the stats of the soldiers from the assign crew screen? --[[User:Slibluhr|Slibluhr]] 16:56, 22 January 2010 (EST)
::OK, I could reproduce the crash this time, it has nothing to do with the stats screen as I supposed to do. The game crashes RANDOMLY if I have turned on the D3D thingy, any clue? I've also noted that if I turn on the caps mod (to put most of 'em in 150-200 to overcome the distance penalty) the soldiers do NOT improve, even after kicking a large scout's butt with KAtherine Sharpe, she didn't get any FAc point! --[[User:Slibluhr|Slibluhr]] 05:30, 23 January 2010 (EST)
:The caps bug is a known one, and a fix is available. I thought I'd wait for more substancial stuff before releasing a new version though. You can try the latest dev version that has the fix included.
:As for your crash I cannot do much without a crash address... [[User:Seb76|Seb76]] 11:46, 24 January 2010 (EST)
::This is what it said during last crash:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00011689

::--[[User:Slibluhr|Slibluhr]] 15:29, 24 January 2010 (EST)
:Sadly the address is of no use (crash inside Windows code, most likely because of wrong arguments). I've put a new version up with better D3D error handling, does it help with your crashes? Also since I was feeling like it, I updated the "Reorder Soldiers" feature so that when you click the name of the soldier, his stats show up. You must click the rank/name of the ship to assign the soldier. [[User:Seb76|Seb76]] 18:00, 24 January 2010 (EST)
::Thank for the access to the stats of the soldiers via crew screen, it releases them from having their FAcc and PStr in the name.

:: btw, the crash moved to this location now:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00028c0b

::could it be that's my pc's fault? does this happen to anyone else?

::------------------
::System Information
::------------------
::Time of this report: 1/25/2010, 01:25:00
:: Machine name: 0X000001
:: Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.090804-1435)
:: Language: Spanish (Regional Setting: Spanish)
::System Manufacturer: FOXCONN
:: System Model: A6VMX
:: BIOS: BIOS Date: 03/13/09 09:59:28 Ver: 08.00.14
:: Processor: AMD Sempron(tm) Processor LE-1250, MMX, 3DNow, ~2.2GHz
:: Memory: 3072MB RAM
:: Page File: 466MB used, 4490MB available
:: Windows Dir: C:\WINDOWS
:: DirectX Version: DirectX 9.0c (4.09.0000.0904)
::DX Setup Parameters: Not found
:: DxDiag Version: 5.03.2600.5512 32bit Unicode

== Store limit question ==
Nice to see you've implemented the general store change (unfortunately, UFOExtender doesn't work under wine, so I can't test this). I'm curious why 187 is the limit? I thought it would be a power of 2 (possibly minus 1)... Possibly you wanted to write 127? [[User:Cesium|Cesium]] 19:43, 21 February 2010 (EST)
:You can build 35 general stores max in a base and 65535/35 ~= 1872 (the internal representation is ten times what's shown ingame). [[User:Seb76|Seb76]] 00:19, 22 February 2010 (EST)

== Mouse scaller not working on Windows 7 x64 ==

with d3d=1 and Scale Mouse=1 I still have issues with the mouse going way off screen.
--[[User:BladeFireLight|BladeFireLight]] 01:57, 22 February 2010 (EST)
:I have noticed that alt-tabbing out of X-COM at the title menu (or any other point that won't crash it) and then alt-tabbing back into it fixes this problem for me in Win7-64. --[[User:Xusilak|Xusilak]] 13:12, 22 February 2010 (EST)
::Thanks for the heads-up. I uploaded a test version here: http://www.ufopaedia.org/index.php?title=Image:UFOExtender-dev.zip
::Does it fix you problems? [[User:Seb76|Seb76]] 14:36, 22 February 2010 (EST)
:::Yep. Seemingly no issues with the mouse going off the screen using it, although I didn't test for long. I'll try to get more test time in later. --[[User:Xusilak|Xusilak]] 20:46, 24 February 2010 (EST)
::::Actually, it doesnt work for me either, in WinXP. And it was broken since the version of 7th November, the one with windowed mode addition. Also, Alt-Tabbing didnt work too. This fix makes things right, though.
::::Edit : also, this dev version crashes in 100% cases when going to battlescape.
::Strange, I do not have any trouble even when using split binaries. Do you have an address for the crash? [[User:Seb76|Seb76]] 14:03, 1 March 2010 (EST)
:::Okay, i hope this is what you wanted, but it says the adress is 0x0000000000bd22ca. I can load an actual save with tactical mode, but cant go into tactical from geoscape. So i use the version from 1st November still.
:Hum, you say the dev version crashes and that you are stuck with the version from 1st november. Do you mean you have the problem since the version of november the 7th, independently from the dev version? [[User:Seb76|Seb76]] 14:08, 4 March 2010 (EST)
::Actually yes. At first i didnt want to use it, because i use a tablet instead of mouse, and its really noticeable when a window failed to scale properly, since a tablet works in absolute screen coordinates. But just now i checked several new (non-dev) versions for the crash - its there. Crashes every time i try to enter tactical mode from geoscape. Saves from tactical load up fine. Version from Nov.1st gives no problems whatsoever.
:Do you still have the problem if you disable D3D or use windowed mode? Also if you load a tactical game, don't you get a crash when it goes back to geoscape? [[User:Seb76|Seb76]] 03:20, 6 March 2010 (EST)
::When disable D3D - yes. When enable windowed - yes. When going from tactical to geoscape - no.
:OK, I suspect this has to do with the "Save Equipment" feature. Can you try disabling it if you have it on? [[User:Seb76|Seb76]]
::OK, um...i tried all my saves, and with that feature disabled all my saves load up fine, and i can go from geoscape to tactical and back. So i thought everything was alright, and kept playing - the very next tactical mission loads up fine, but as soon as i try to move anyone - it crashes. And that is the same in all my saves, first mission is alright - second one always crashes. The crash adress is 42064f, in case you're gonna ask.
:Alright, can you PM me a savegame before the crash? I doubt it'll help but who knows...[[User:Seb76|Seb76]] 12:43, 6 March 2010 (EST)

== Extender in Steam (+ maybe XComUtil) ==

Hi do you know of any way to use the two apps together with the Steam version? I would really like to be able to combine the 'Reorder Soldiers' feature of Extender and the 'Capturing Aliens for Research' of XcomUtil.

Actually now that Ive put a bit more time into it I can't get UFOLoader.exe to run in steam's dosbox implementation at all. I can just run UFOLoader but it doesn't run in dosbox which makes the game run horribly. If you don't have a steam copy for testing / integration of the basic Extender program please let me know and I would be happy to send you a gift copy.

-Dogfish

P.S. What a great program, you are a credit to gaming.
:As far as I know, the Steam version also ships with the windows CE edition, the default shortcut just happens to point to the dosbox one. Also the latest version of XComUtil is able to detect the loader presence and act accordingly. [[User:Seb76|Seb76]] 15:42, 25 February 2010 (EST)

:: STEAM comes with both EXE. XcomUtil and UFO Extender work together with STEAM. To use Setup UFO Extender in the game folder. Then Download and install the latest build of XcomUtil 9.7. It will auto start XcuSetup in windows, Detect UFO Extender and allow you to configure RunXcom to use it. To use UFO Extender, or UFO:CE you can't launch the game from STEAM. You have to create a short cut for RunXcom. (Right click > send to > Desktop as Shortcut) --[[User:BladeFireLight|BladeFireLight]] 19:13, 25 February 2010 (EST)

Thanks guys I was able to start the game with both mods. I apparently had everything configured correctly but I kept launching it from steam. Is there a way to play in windowed mode (since its not using dosbox)? I tried launching dosbox and running 'RunXCom.bat' file from there but it does not recognize UFOExtender.

Oh boy the game is fast, even on slowest scroll it is difficult play a battle :)

-Dogfish
:What options did you turn on? [[User:Seb76|Seb76]] 14:18, 26 February 2010 (EST)

Show Stats=1
Apply=1 (wreck analysis)
Proximity Grenades Experience=1
Elerium-fueled Craft Bug=1
Save Reserve Mode=1
Rank In Inventory=1
Manual Interception Fire Mode=1
Crafts Always Ready=1
Reorder Soldiers In Crafts=1
No Funkers=1
TFTD Doors=1

Full System Specs:
Win Vista 64
Intel i7 920
6GB RAM
GTX 285 Video
Asus p6t

Everything is fast the geoscape tics are at least 5 times faster than running the non-Extender mode via dosbox.

Would you have any suggestions how to slow it down? I've actually been playing in steam(dosbox) with XComUtil only and then saving/loading between missions so I can reorder the soldiers.

Aha! I found the D3D Windowed option...
HQ4x=0
D3D=1
D3D Windowed=1
Always On Top=0
Clip Cursor=1
Scale Mouse=1
Screen Ratio=0.833333

I can manually resize it to be bigger, excellent!
What is strange is that running it in windowed mode seems to slow it down enough for the scroll speed settings to make it playable :)

I ran into a "Unsupported 32/16/64 bit error message switching from geoscape to battlescape but it happens only 1/3 times maybe?"

I will be playing this and let you know if I run into any more problems.

Thanks a bunch!
-Dogfish

Hi guys, dogfish again I've been getting a couple of glitches.

1. Switching from battlescape back to geoscape in the cmd prompt it displays
'echo----------------------------Leaving' is not recognized as an internal or external command, operable program or batch file.

2. This has happened twice

Get someone who has been shot is at low health and has fatal wounds

Have them pass out due to smoke inhalation

Let them bleed to death and get the "Joe McSoldier has died from a fatal wound" *while unconsious from the smoke*

I will lose points for the mission but the soldier will be recovered at the end of the mission but terribly wounded. (Currently Hans 'Jesus' Vogel is taking 55 days to recover his 41 health.)

:Both of these are XcomUtil issues. 1 has been fixed in Build 413 but I need a saved from just before ending combat to fix 2. --[[User:BladeFireLight|BladeFireLight]] 18:19, 28 February 2010 (EST)

::Sent the savegame to your gmail (whatever was listed on my paypal reciept from your donate button). Just hit end turn (all the aliens are dead) and the bug is triggered. -Dogfish
::: I got it. Was up all night with Bomb Bloke and we worked out what was going on. The fixed works with your save. The next build will fix the zombie bug. Also Thanks for the donation. Every little bit helps. --[[User:BladeFireLight|BladeFireLight]] 16:02, 1 March 2010 (EST)

--
Hi! I'm thefarside. This is my first time ever editing a wiki page so please bear with me. I'm not even sure I'm allowed to do this.

However, I have a problem with the cursor. It moves WAY out of the screen to the right and downwards. I've read something about a "clip cursor" fix but I can't seem to find out where and how to implement it.

Regards,
thefarside
--

== Manually Select Promotions ==

Just an Idea, not sure how easily done it is but I was thinking it would be really cool if (when its time for promotions) it would bring up a soldier screen with the eligible soldiers so that you could pick who gets promoted. Bonus if you could click on the candidates and be taken to their stats screen.

Love,
Dogfish

== Xusilak's Patch Additions ==

Since my patches are being integrated into the main release now, everyone should let me know if any issues are found with them. I'll try to get on fixing them as quickly as possible.

For clarity, the patches in the current build that I developed are:

* AutoSell
* Show Money

Thanks! --[[User:Xusilak|Xusilak]] 14:51, 24 March 2010 (EDT)

I went ahead and set up my own user page: [[User:Xusilak]]. If possible, direct discussion about my patches to my [[User_talk:Xusilak|discussion page]] there. Thanks again! --[[User:Xusilak|Xusilak]] 15:44, 24 March 2010 (EDT)

----

Hi Seb,
I've been working with IDA, your database, and your patcher's code for some time now, learning my way around it, and so on. So far, I've managed to come up with three UI improvement patches, although they still need some polish and testing.

The first one is a battlescape movement confirmation patch; it requires the user to click twice (double-click with no time limit) on the same tile to move, instead of once, to eliminate movement errors. In practice, I have found this very helpful.

The second one shrinks the geoscape clock and adds your current funds above it, letting you see your financial situation at a glance while waiting for time to pass.

The third one enables auto-selling of manufacturing items. Pressing the down arrow when the production quantity is at 0 engages this mode. When in this mode, production of that item never ceases (unless resources become unavailable), and the item is immediately sold upon completion.

Would you like me to make the code for these available once I've finished polishing them up? They currently consist of a few C functions accompanied by some InsertCall()s and Nop()s, as well as some additions to XCOM.h. I haven't added INI options to enable them, so I'd leave that up to you. You may use them as you wish, with no conditions.

Note: I'm still learning x86 assembly, so the patches may not be bug-free. I'm hoping to give them a good testing myself, though.
--[[User:Xusilak|Xusilak]] 16:10, 19 March 2010 (EDT)
:Glad to see you could make something out of this database :-) Do not hesitate to send me your modifications, I'll incorporate them in the codebase so others can enjoy them. I'm sure your autosell feature will make a few happy ones ;-) [[User:Seb76|Seb76]] 19:12, 19 March 2010 (EDT)
:::Yeah those features would all be '''great!''' Thanks Xusilak. [[User:Spike|Spike]] 15:08, 22 March 2010 (EDT)
::OK. I'm going to finish up my last touches on them, then test them for a while; they should be ready within a couple days. --[[User:Xusilak|Xusilak]] 21:59, 19 March 2010 (EDT)

== v1.21, Battlescape crashes ==

I enabled the new mods and they worked ok in Geoscape. Then this Popup box starting the first Battlescape:

Application failure
XCOM crashed at 0x10002571 with error 0xC0000005 trying to access 0x0968DF43

[[Media:UFOExtender1.21.BSCrash.zip]] contains the UFOExtender.ini file.
This was a New Game but not a new install of XCOM, just an overlay of updated UFOExtender.

*Win XP Pro 2002 SP2 32bit PAE
*Pentium-4 3.00GHz 3.5GB RAM

Any ideas? Need more info? [[User:Spike|Spike]] 20:20, 24 March 2010 (EDT)
:Does it happen consistently? I've been plagued by a random geoscape->battlescape transition crash in the collector's edition. It's one of the things I'm looking to fix at some point. The current UFOExtender doesn't appear to crash any more than previous ones do for me. I managed to do four missions in a row just now. --[[User:Xusilak|Xusilak]] 21:00, 24 March 2010 (EDT)

I'm doing some research into this; I started up in debugging mode and spammed missions until I hit a crash. The crash (on this occasion) is an access violation caused by an invalid pointer stored at 0x49B954 (the offset that pSoldierDat points to). This means *pSoldierDat is being changed at some point. It took many, many tries to get this crash to happen; I reloaded something like 20 times hitting the same mission, went ahead and did the mission quickly, proceeded, did another mission, proceeded, then the next mission crashed. Given that I'm in debug mode, it's not impossible this is due to the various hacks enabled by it, so that should be kept in mind. I'm going to continue working on this. --[[User:Xusilak|Xusilak]] 22:26, 24 March 2010 (EDT)
:It appears the "invalid" pointer is actually set by malloc() - 0x0771D380 (for me). I can only assume something along the way disrupted the data on the heap, as the pointer was the same when examined on a battlescape transition that didn't crash. Still researching. Note that for me, the crash itself happened inside GetSolderUUID() in the Save Equipment patch functions when it attempted to use that *pSoldierDat pointer. However, I assume it would still happen if the Save Equipment patch were disabled, just elsewhere. This is something I'll test as well. --[[User:Xusilak|Xusilak]] 23:41, 24 March 2010 (EDT)

::Sorry I'm guilty of reporting a bug I didn't (couldn't) repeat. But as I had no previous save game positions I couldn't repeat anything - the crash happened on the first Battlescape mission which for me is unusual, I would say that for me that transition crashes less than 1 in 100 times, if even that many. I had enabled Save Equipment I think and on instinct I would suspect that mod as being responsible. Those UFOExtender functions would run while setting up the Battlescape presumably. The equipment handling functions and structures ''already'' present in the game are known to be buggy. BladeFireLight and I just found another issue with them last week. Manipulating them is still risky. If you can investigate that would be very helpful.

::In the meantime I will see if I can try to repeat the fault, with and without Save Equipment enabled, and starting from a clean XCOM install. One trick I may use is to set No Score Game Over and then just abort from each mission rather than fighting it, to speed up the testing.

::Thanks for your good work Xusilak, it is appreciated! [[User:Spike|Spike]] 03:25, 25 March 2010 (EDT)

One possibility: On this mission I had only 6 soldiers (2 HWPs) but enough weapons in the Skyranger to equip 14 soldiers. Is there some known issue with needing to allocate '''all''' weapons to soldiers during the equip phase, in order to avoid a crash? If so that might be the cause. I will try to recreate those conditions and see if it provokes a crash. In case it's not clear, Battlescape never appeared to start, no Equip Phase screen ever came up. [[User:Spike|Spike]] 03:31, 25 March 2010 (EDT)
:Assuming the same crash is afflicting us, then the crash is when the very first soldier is accessed, when the Soldier.Dat data is first used for that mission. It's unlikely that volume of equipment is affecting that, and in particular, I hadn't changed my Skyranger's loadout to any degree whatsoever, having only briefly touched researching and manufacturing; it was otherwise a gamestate set entirely by doing one quick regular mission and one quick terror mission. However, I was also in debug mode, which enables certain cheats, like Alien Pets, automatically. This might, itself, have unseen bugs that could corrupt the data structures and cause a similar crash. When I get the time to, I'll be testing again with those cheats disabled, trying to further isolate the conditions involved. --[[User:Xusilak|Xusilak]] 08:34, 25 March 2010 (EDT)

I've repeated this multiple times now, with a clean install of XCOM and a clean install of UFOExtender 1.21. The game crashes everytime, after the "mission screen" that comes up just before the Equip Phase of Battlescape for the first mission. It's regardless of my equipment loadout or number of soldiers/tanks: it happens with totally default equipment and Skyranger load. So I imagine it must be due to some combination of the UFOExtender.ini file options I selected, and maybe code changes in 1.21. My .ini file is the upload at the top of this section. The error is always "error 0xC0000005 trying to access 0x0968DF43", though the crash location (in the code) varies. [[User:Spike|Spike]] 20:31, 25 March 2010 (EDT)
:If you have time, could you try to 1) confirm it's specific to 1.21 2) try to correlate it to ini options? Turn everything but the basics off and see what happens... if that works, turn on Save Equipment and try again, etc. I haven't seen any behavior like that in my local tests, on either of my computers (Win7-64 and XP-32). I'll try it with your ini, though. Maybe I can find something. --[[User:Xusilak|Xusilak]] 20:39, 25 March 2010 (EDT)
::Just tested with your ini, although with D3D and D3D window enabled. Started a mission, didn't crash. I also noticed one thing: you have General Stores capacity set to 1. I don't think that's helping anything, but it's probably not causing the crash, either. Experimenting more. --[[User:Xusilak|Xusilak]] 20:48, 25 March 2010 (EDT)

::: Save Equipment=1 is part (at least) of the problem. If I turn that off, and leave all my other .ini settings as is, I no longer get the Battlescape crash. Seb, did you make some changes there? Maybe after the investigations we were doing with BladeFireLight? [[User:Spike|Spike]] 21:13, 25 March 2010 (EDT)

I have isolated the problem (on my end) to the fact that the SOLDIER.DAT data in memory is deallocated when the transition to the Battlescape starts. When Seb's Save Equipment code attempts to use it, it's getting random unallocated (or unrelated) memory instead of the SOLDIER.DAT data. Interestingly, the dynamic memory used to hold the SOLDIER.DAT data is deallocated on the transition to the Battlescape, and reallocated to a new memory address on the transition out of the Battlescape. I assume this is an artifact of the way the Collector's Edition merged TACTICAL.EXE with GEOSCAPE.EXE, because TACTICAL.EXE had no need of SOLDIER.DAT, and only used UNITREF.DAT and similar. At any rate, this problem can be resolved by not relying on **(0x49B954) (or **pSoldierDat) to contain the correct data. Instead, a workaround to get the needed data should be used. One option would be to patch the way the transition works to prevent the deallocation from happening, and then ensuring on exiting the Battlescape that the old memory block is still used. I may be able to work in that fix myself. If so, it would require no changes to the Save Equipment code.
I'm not sure if this is a general issue or local to me only. I'll try to test on my XP system and see if it suffers from the same problem; if it does, it's a safe bet this is a general issue, and the likely cause of your crashes. --[[User:Xusilak|Xusilak]] 00:06, 26 March 2010 (EDT)

Save Equipment did used to work for me before. Maybe it's because I also selected Reorder Soldiers In Craft. Does that sort and rewrite SOLDIER.DAT? [[User:Spike|Spike]] 03:39, 26 March 2010 (EDT)

I have confirmed this behavior in the original X-COM Collector's Edition UFO Defense.exe copy, running on my XP system. As such, it ''cannot'' be a result of any patches Seb has made (because it still happens even when not using Seb's loader). I'm not sure if it will crash without Seb's patches still, but the way Seb uses the *pSoldierDat pointer in GetSoldierUUID() appears to be unsafe, as *pSoldierDat has already been deallocated at that point. On some systems, it may work, because the nature of memory on the heap is such that different systems give different results when dealing with deallocated memory and bad pointers. Regardless, the crashes can be at least partially (maybe entirely) resolved by using a workaround that avoids the deallocation of *pSoldierDat when the battlescape transition starts. I'm going to see if I can implement the fix I suggested, that prevents the memory from ever being deallocated. That should completely resolve it. At the least, I am going to study the assembly responsible for deallocating it to see if I can confirm the exact issue on the code level. --[[User:Xusilak|Xusilak]] 13:26, 26 March 2010 (EDT)
:It seems that when GotoGeographMode() returns to move into GotoTacticalMode(), it calls FreeEverything() in the process, deallocating all data structures. Then, GotoTacticalMode() never bothers to reinitialize *pSoldierDat, so when the equipment phase comes up, it's still unallocated. Still working on a fix. --[[User:Xusilak|Xusilak]] 14:29, 26 March 2010 (EDT)

::Surely at some point the (unmodified) game needs to at least read the *pSoldierDat structure, in order to populate the [[UNITREF.DAT]] and [[UNITPOS.DAT]] structures for Battlescape? Unless it reads SOLDIER.DAT but doesn't bother storing it, not even temporarily, in *pSoldierDat.[[User:Spike|Spike]] 15:27, 26 March 2010 (EDT)
:::Nice piece of analyse there :-). I'll modify the patch to load the soldier data when needed and clean up afterward. [[User:Seb76|Seb76]] 15:30, 26 March 2010 (EDT)
:::Edit: I uploaded a test version. Can you check if it fixes your crash? [[User:Seb76|Seb76]] 15:47, 26 March 2010 (EDT)
::::Looking good so far; Save Equipment works for me now, and it never has in the past. I'll run through a bunch of missions quickly and see if I get any crashes. Thanks Seb! --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:::No, thank you for figuring out the cause of the crash. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
:::::Just ran through several dozen (very quick, mostly aborted) missions all the way up to June. I never crashed, and Save Equipment always worked correctly. I think we're good to go. Hopefully it works for Spike as well. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)

I've also been narrowing in on another crash, unrelated to the patcher, I believe. It happens rarely upon clicking the air to move somewhere, like stepping out of the Skyranger by clicking the air one tile in front of the soldier, to move onto the ramp. It appears to be the result of a bad calculation on the tile to check in MoveUnitTo(). The calculation is looking at (char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize); // when esi is 2 or greater; this esi factor shouldn't be there, as far as I can tell, because it results in the offset used being much greater than it should be and frequently going out of bounds of the MAP.DAT data stored at *pMap. Continuing my research into this when I get a chance. --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:I noticed that crash also (I think it's the number one crash cause on a genuine XCOM setup) but was never able to reproduce enough to investigate it. I was tempted at one point to patch the GetTileAt function to check its arguments, but finding the cause of the corrupted value would be better. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
::Yes, it's definitely a hard crash to catch, because of how rare it is. I've got a few ideas, though. We'll see if they help. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)
:::Currently, my guess is that this line:
:::<pre>.text:00420534 BE 01 00 00 00 mov esi, 1</pre>
:::should be "mov esi, 0" instead.
:::To sum up the issue:
:::The way the 'click on air to move to a tile below unit' part of MoveUnitTo() works is that it examines each level below the unit until it finds a floor to move to. It does this by looping through the level below you, incrementing esi to loop through the next level below that, and so on. To do this correctly, esi should start at 1. However, the X-COM programmers appear to have made an oversight: they initialized esi to 1, but then incremented esi again before the initial value actually gets used. The net result of this, is that we get zpos += 2 for the very first cycle. This works OK on floors 3 and 4, but for floor 2, it will attempt to access a z level that doesn't exist (one below the ground), causing this line: <pre>(char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize);</pre> to exceed the bounds of the *pMap memory block. Obviously, running off the end of that block will cause unpredictable results, and if it reaches into a block that isn't allocated, it will crash. That's why the actual crash is very rare: it has to overrun into an unallocated memory block.
:::Of course, I could be completely wrong, but it makes sense, and patching 'mov esi, 1' to 'mov esi, 0' doesn't seem to cause any problems. I'm going to be testing with that patch enabled from now on, to see if I crash in that circumstance anymore.
::Looks like you are right. I instrumented the code and there are indeed systematic out of bound accesses when getting out of the craft, though the game does not crash every time. I suspect this is the same crash that happens during base defence when an alien tries to move down from the access lift. Kudos for figuring all this out! I'll provide the fix in the next version. [[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)
:::By the way, Seb, the 1.21 source code doesn't include autosell.cpp; I assume it's a simple oversight. I reconstructed it to get it compiling properly. Just wanted to make sure you knew. --[[User:Xusilak|Xusilak]] 20:37, 26 March 2010 (EDT)
::Oops, forgot to check the unversioned files before checking in...[[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)

== Minor cosmetic enhancements? ==

Had these ideas come to mind while I was at work today, and since your loader is doing some amazing things for the game, I thought I'd ask if the possibility of any of these enhancements exist.

The short of it is: Are you able to overlay any additional bitmap surface on top of the battlescape view, and are you able to play additional sounds?

The main idea for drawing an extra bitmap (semi-transparent) over them map would be to simulate rain/snow for some outdoor maps. Lightning even - though that would require clever use darkening and lightening the overlay. This would have some issues attached to it such as knowing when to display it and when not to, thanks to the various other screens available.

As for playing sounds, which would be simpler, would be to play a looping sound clip to provide environmental sound effects, such as insects chirping and owls hooting at night in woodland maps or town noises at terror sites. Or during the day in a jungle map, some tropical bird calls made at random intervals. TFTD already does the looping environmental sounds, such as teh under water bubbly noises or the wind and sea noises when on land mission. Would it be possible to duplicate this for UFO CE?

Not the most important of enhancements, but I was still wondering if the possibility is there.

-[[User:NKF|NKF]] 01:41, 25 March 2010 (EDT)

== Save/Load shortcuts ==

Seb, would it be possible to enable shortcuts for the Save/Load in geospace & tactical (like F2 or F3) ? ;) except for saving in the final battle (from level 4 if remember) :)

Other things:
- rosvell incidents occured for me too often - 5 in the first month while there was no other alien craft movement detections

- option to disable mission briefing window with the only ok button :) supposedly for advanced users ;)

== Aliens continue using pistols&rifles ==

Hi Seb, sorry to bother you - i have been playing X-COM titles on and off for about 10-15 years now, and one thing always bothered me: Why do the aliens always swith to heavy plasma (or the Sonic cannon in case of TFTD) later on? It encourages the player to swith to heavy plasma too, if only for the free ammunition you almost drown in later on. Would it be possible to have the aliens continue using the plasma pistol&rifle after june/july? It would make using those weapons more feasible, getting ammunition during missions and not having to use elerium to produce it.

Another request (don't know if it is possible) - let the aliens continue using the abductor and the harvester for the respective missions. Later on, all you get are large scouts or even battleships doing those missions - getting some variety in there would make the endgame more interesting. You get to do 50+ battleship missions in a game, but only 4 or 5 with a harester/abductor. Those ships should see a lot more use during the missions they are "designed" for. The "[[MISSIONS.DAT]]" page says something about ufo and mission counters and their associated ufo-types - would it possible to modify those entries via the loader?

Regards, Equinox

== ALIEN MISSION DATA CLARIFICATION ==

According to
[http://ufopaedia.org/index.php?title=Talk:MISSIONS.DAT#Alien_missions_data_discovered_in_geoscape.exe_.5Bfinally_.3B-.29.5D link title]

I found it in TFTD. At offset 505448 (decimal) is starting (mission Probe). Next Interdicition/resource raid/infiltration/colony expansion/surface attack/Floating base attack

I understood what is 3-rd word. If You interesting - I can exlain

Seeing speeds of USO sub we can determine the mission of this USO sub even without transmission resolver - even in january 2040
Every USO sub in every missions (interdiction, colony, probe and other) have unique speeds and we can determine mission of USO on their speed
And we can determine what amount of times a sub touch down on his mission - because every mission has unique rule for touch down USO subs
And we can determine what amount of time USO Sub will touch down on their mission - because every Sub in every mission has unique and ALWAYS equal amoun of time to touch down (p.s. this time we can see in file Loc.dat)
Here - I attached file speeds.zip
[http://www.strategycore.co.uk/forums/Ion-Beam-Accelerator-in-What-file-t8099.html&view=findpost&p=95994#entry95994 link title]

3-rd word - it is reference to unique speed of each sub

4-th word - is time that precede to arrive next uso sub. In other word, in line ufo/c 0/0 if time = for example = 200 - it's time to arrive sub that indexes 1/0.
And where can I get time to arrive EXACTLY sub 0/0 is incomprehensible for me. I assume that this time contain at similarly word of last uso for this mission - but its'not truth because at some missions time in the line of last ufo/c = 2 half-hours and it's means that ufo/c 0/0 can to arrive at new month at 2 half-hours. It's true for Surface attack Mission but not truth for other missions.
I assumed that time in line ufo/c 0/0 - that time to arrive for NOT next ufo - and I assumed that it's time to arrive exactly ufo/c 0/0 itself. But many my tests (more than 100) denies my suppositions.
In example, at line ufo/c Cruiser mission Colony Expansion time in file =2. Cruiser in that mission arriving much more than 2 half-hours after Escort. Instead Fleet supply Cruiser in that mission arriving after 2 half-hours exactly after Cruiser.

'''Question - Where can I find time to arriving for ufo/c 0/0 for each missions except Surface attack mission ?'''

I am sorry for disturbance and will great thank for you for help.
:After the first month the game creates a mission per month, up to the 6th where it generates 2. I guess a mission starts immediatly, there is no timing added for its first ship. [[User:Seb76|Seb76]] 15:18, 30 April 2010 (EDT)

Mission starts not immediately. often time to arrive to survey ship (first sub) about 10-15 days.
1-st day of month at 0-00 we can see it time at Missions.dat but wants to know average time similarly such average time for other subs from alien data mission at executable if possible.

What is exactly 6-th? mission from Probe to Colony Expansion? or from January to June?
:Yep, 6th month. [[User:Seb76|Seb76]] 20:04, 30 April 2010 (EDT)

what happens after 6-th month June?

I so sorry for reminder and bother you, but don't you know it? ((

== Formules about Retaliation/Floating base attack mission ==

Hi

My great respect to you for you formules
I need few help. I am great thank to you in advance

Now I found alien data missions in TFTD (in a similar in EU ) and I ask generously to you to check 3 your formules in TFTD. Is these same or not?

1. After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours
:Xusilak is more knowledgeable than I concerning TFTD. I cannot help you here... [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

Formule 2 and 3 probably contins mistake. formule 'll have to have symbol > instead symbol <. Otherwise retaliation mission activates more often on Beginner diificulty than Superhuman difficulty. Is is strange.

2. A retaliation mission will be scheduled if RAND()*100 < 4*(24-difficultyLevel).
:There is indeed a mistake there. It's been so long I cannot remember if I got it wrong or just messed it up wikifying it ^^ [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

3. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from. The first UFO is scheduled in 100 half-hours (the value is taken from the table I speak of later at the bottom of this page).

And RND() - what values may has? from 0 to 1 or not?
:When I write RAND()*100, it just means a random number between 0 and 100. [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

I will be very thank for given help

== MISSIONS.DAT formula clarification ==

Hi Seb76. I've been having a discussion with Alexchamp and trying to interpret the formula you mentioned on [[Talk:MISSIONS.DAT]] about retaliation missions being scheduled after a shoot down. Namely: if RAND()*100 < 4*24-difficultyLevel

We mainly need clarification on the logical operator. Should it be less-than or greater-than?

As it reads now, it could be interpreted as though retaliation missions are generated more frequently on the easier levels. But if we treat it as >, then this means that retaliation missions are generated about (Beginner) 4%, 8%, 12%, 16% and (Superhuman) 20% (or 28% for TFTD) of the time on their respect difficulty levels.

If you could clarify that for us it would be great, thanks. - [[User:NKF|NKF]]
:Yep, I goofed up. Don't take everything I say as gold ;-) [[User:Seb76|Seb76]] 14:45, 30 April 2010 (EDT)

And I precise too one '''mainly moment'''. Whether there must be the opened bracket after the sign of multiplication? Because if no, then right interpretation formule in Superhuman example such: Rand*100>4*24=96-6=90 and that means that retaliation mission would be sheduled in 10 cases from 100.
IF there must be opened bracket then rand*100>4*(24-6)=4*18=72 wouid be sheduled in 28 cases from 100
What is this versions is right?

Then needs clarification for second formula yours. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from.
What logical operator there? should it be too greater-than or less-than?

You have found later formules about activation retaliation mission (if we shotdown alien craft)
Where exactly in assembler is subprogram that determines it? What address/offset of it?

== COLONY SUPPLY MISSION ==

As we know, When alien base built, Fleet Supply Cruisers with missions Colony Supply can to arrive to this base.

Where can I see (file/offset)
1) average time to arrive colony supply ship for examle/at least in XCOM-EU. As I said later, in responsible offset is time '''to PRECEDE to ARRIVE NEXT UFO SUB''' '''it's not''' time to arrive this sub
2) real time to wait arriving colony supply ship similarly times in file Missions.dat

According to [http://www.strategycore.co.uk/forums/Colony-Supply-ship-time-to-arrivin-t8103.html&view=findpost&p=96011#entry96011 Colony Supply - time to arriving]

If guesses of NKF is right, we need to formule of probability to arrive Colony Supply ship.
Can you to render courtesy with this formule?

Thank you very very great in advance
:I added details in the LOC.DAT talk page. The supply ship is spawned randomly and starts its mission. There is no "time to first supply ship" that I can see. [[User:Seb76|Seb76]] 15:11, 30 April 2010 (EDT)

Thank tou very much for this clarification. I found this offset in TFTD even. Changed, checked - it works.
You are greatly people!

== Roswell mission bug? ==
Hello, Seb76.

I've just had two consecutive games (meaning, I restarted the application and began a new game) where the same strange behavior occurred.

Both games had Roosevelt mission as the first one. It showed the window (type, terrain, UFO size) as usual. Afterward, whenever I clicked on it (to check mission conditions again), it showed a typical "hyperwave transmission decoded" window, stating race/mission type, etc. Needless to say, I had no decoder at this time, since it happened both times in the first game week.

I have a saved game if you want to take a look at it. It's completely reproducible, at least for me. You just click on the white cross and get this window.

Also, I'm using plain CE version with a "complete UFO patch" from StrategyCore. The saved game was not hacked in any way.

Cheers!
[[User:Rovlad|Rovlad]] 10:08, 30 April 2010 (EDT)
:Hum, I gave it some shots but could not reproduce your problem. Anyone experiencing the same problem? [[User:Seb76|Seb76]] 15:36, 30 April 2010 (EDT)

::Here's the [http://rovlad.nm.ru/GAME_1.zip savegame]. Let me know if it works fine for you. [[User:Rovlad|Rovlad]] 21:47, 30 April 2010 (EDT)
:Looks like the CRAFT.DAT entry is not cleared when a new craft is created and the offset 0x64 could be garbage till the craft is detected by a base/another ship. Since I bypass the detection when "crashing" a UFO, it is possible the "HWD detected" flag is set randomly, producing a full report. I'll clear the bit and we'll see if it corrects the issue, just wait for the next release. Thanks for providing the savegame BTW. [[User:Seb76|Seb76]] 14:22, 5 May 2010 (EDT)
::You're more than welcome. Fantastic job on the extender, keep up the good work. [[User:Rovlad|Rovlad]] 19:04, 5 May 2010 (EDT)

== ALIEN RACE SPAWN ==

Your post: In EU, the race is based off a lookup table starting at offset 0x46E53C (containing 300 entries).

Offset-0x46E53C is absent. Is one symbol odd?

Your posr:The table is made up of 10 entries lines.

It means that this bit of array has 10 rows width of 30 bytes. is right?

What is means this 10 entries lines? Can you copy 2-3 lines from exe and explain that means known for you offsets in line?As simiilarly as you done for alien data mission in file Missions.dat
Can you get more particularly answer about values it this array?(naturally if know it)
:0x46E53C is the address in memory. In the file it should be 0x6E53C (UFO Gold edition).
:The begining starts like this:
.data:0046E53C byte_46E53C db 0, 0, 0, 0, 0, 0, 0, 1, 4, 4 ; 0
.data:0046E53C ; DATA XREF: CreateAlienMission+15B�r
.data:0046E546 db 0, 0, 0, 0, 0, 1, 1, 4, 4, 4 ; 0
.data:0046E550 db 0, 0, 0, 0, 0, 0, 4, 4, 4, 4 ; 0
.data:0046E55A db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E564 db 0, 0, 0, 1, 1, 4, 4, 4, 4, 4 ; 0
.data:0046E56E RaceForTerrorMission db 0, 0, 0, 4, 4, 4, 4, 4, 4, 4 ; 0
.data:0046E56E ; DATA XREF: GeoPerformMonthlyActions+15E�r
.data:0046E578 db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E582 db 0, 0, 0, 0, 0, 0, 1, 4, 4, 4 ; 0
:till the end:
.data:0046E67C db 0, 1, 1, 2, 2, 2, 3, 3, 2, 4 ; 0
.data:0046E686 db 0, 0, 1, 1, 1, 2, 2, 3, 3, 4 ; 0
.data:0046E690 db 0, 1, 2, 2, 2, 2, 3, 3, 4, 4 ; 0
:As you can see, at the begining you'll get tons of sectoids (0), a few floaters (4) and even less snakemen (1).
:At the end, you'll get ethereals (2) one time out of two. Also note that for terror missions, the line is taken a bit farther than normal missions, which means that you'll get stronger aliens sooner in terror missions. HTH, [[User:Seb76|Seb76]] 13:36, 5 May 2010 (EDT)

Thank you greatly for your detailed answer ...
I want a few more precise ...
I right understand? I guessed That line 1 - is used for January mission Research? Line 2 - Jan Harvest? Line 3- Jan-Abduction Line 6- January Terror?
What define Line 7?
Line 8 - is February Research?

According to - Line 13 -Feb terror? Line 20 - March terror? Line 27 -April Terror? Line 34- May terror? that sequence and guesses is right?

And question 2) does affect score to choose the value among values in line? How differ choose values in line at the level superhuman and level beginner ?
If you know, naturally, I would be greatly thanks to you for this wonderful magic help.

== Research tree in executable ==

Do you know location (starting offset) of research tree in EU? and how much entries it contains ? and what means values within this array?

Very great thank in advance for this help to you
:The research tree is not stored as a data array but is a hardcoded sequence of "if this is already researched and that is also researched and such item is in the inventory, then enable this research". Modding this would require a complete reengineering, not just patching. Still feasible though. [[User:Seb76|Seb76]] 13:25, 5 May 2010 (EDT)

What is starting offset (ce version) of this hardcoded sequence? and what is latest offset of it? what is length of one sequence? If possible -what is structure of it briefly? (how much bytes to tech requirements, how much bytes to items requrements)

Thank you for this help '''VERY VERY GREAT'''
:As I said, there are no *sequences* but just a cascade of hardcoded ifs:
:[[Image:Research.png]]
:If you want to take a look, the function begins at address 0x446A0. [[User:Seb76|Seb76]] 07:28, 24 May 2010 (EDT)
'''
Seb76, you are GREAT GENIUS!!!! GREATLY RESPECT FOR YOU!!! THANKS FOR YOU VERY VERY MUCH!!!'''
I have found research tree in TFTD too with your help. Now I can do some changes in it.
Maybe do you know, how can I find subprogram that run 1-st day of any month in assembler code of game?
This subprogram determines new mission's month and terror ship route (in TFTD)
There is not in EU terror ship route, I know. But If you know and tell me - what is subprogram in EU that runs 1-st day of any month, I would be able to edit probability of terror ship route in TFTD.
Greatly thanks in advance to you dear Seb76!
:In EU, monthly actions start here:
.text:0043B9B0 GeoPerformMonthlyActions proc near ; CODE XREF: GeoIncrementDayAndDoMonthlyActions:loc_4420C1�j
:HTH, [[User:Seb76|Seb76]] 16:31, 28 May 2010 (EDT)

== Any way to slow down geoscape time? ==

Is there any way to slow down geoscape time progression on fast computers, esp. multiprocessor ones, where it is impossible to significantly slow it down using utilites like MoSlo and Turbo?--[[User:AVE|AVE]] 03:01, 5 May 2010 (EDT)
:Did you try enabling D3D? If you're drivers are configured to wait VSync, it should limit the game speed (well, if you use a CRT@120Hz it'll still be too fast I guess...). Also is it still too fast if you put it windowed? (enabling both D3D and D3D Windowed options) [[User:Seb76|Seb76]] 13:19, 5 May 2010 (EDT)
::Yes, both D3D and D3D Windowed are enabled. This is even more surprising, because it shows the same results on two different computers (Dual Core one and simple P4Celeron) with different video cards (NVidia and ATI). Both have vsync explicitly enabled. LCD@60Hz both. Also I've tried to use different combinations of Video Pitch, D3D, D3DWin and HQ4x settings - no luck. [[User:AVE|AVE]] 04:20, 6 May 2010 (EDT)
:Personally I've never been able to reproduce this "CE game running too fast" thing people keep harping on about. Perhaps I just have a different perception as to what "too fast" means.

:Anyways, I know [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's patched executable] includes a timer hack for the Geoscape, but I found that makes it run far too slow for my taste. Not sure off the top of my head whether it works with Seb's loader, either - you'd probably need to at the very least need to rename Mok's executable to replace the original in order to try it that way. - [[User:Bomb Bloke|Bomb Bloke]] 05:14, 6 May 2010 (EDT)

== Some problem with edit research tree ==

I want to add new 20-30 commands to research tree. I wrote this subprogram. How can I add it to game?
I tried to write "call sub" instead useless 5 bytes in subrogram research tree. I checked in IDA after it, all other commands is preserved.
And I placed my new subprogram after latest byte of executable file. But game is crashed.
I tried to place my new subprogram after all subprograms and before first byte of idata, but game is crashed too.
All indexes in subprogram was exactly.
in second case IDA displayed "sp-analysis failed".

Where and how can I placed my new subprogram that will be addition to current subpogram research tree?
:To add new code, you need to modify the PE header of the exe file accordingly. I'm not quite knowledgeable regarding the procedure (that's one of the reasons why I made a loader instead of patching the file directly) so you're gonna have to find help somewhere else on this one. [[User:Seb76|Seb76]] 16:36, 28 May 2010 (EDT)

== Update to IDA database ==

Hey again Seb76 :)

After a long time I've come back to your extender, dusted off my copy of VC Express, and decided I'd have another go at doing some UFO modding (don't ask how the first attempt went; it's not pretty! :p )

I'm assuming you've probably updated the IDA database since last time I asked. Would be extremely grateful if I could get the latest version.

Thanks for all the hard work, staring at assembly code all day is no joke! --[[User:K9wazere|K9wazere]] 18:07, 6 June 2010 (EDT)

Arf, didn't realise I could send you an email, so this new section on your talk page is a bit redundant now :p Oh well, maybe someone else will want the file too!

== Line of Sight Origin Points ==

Hiya.

A while back you mentioned the co-ords for the [[User talk:Bomb Bloke:Firing Accuracy#Firing Point Origin|firing point origin]]. The zpos is calculated according to the unit's effective height, and the x/ypos co-ords come from look-up tables depending on which way the unit is facing.

I was wondering, are these same two tables used for the purpose of line of ''sight?'' And by any chance could you find the formula for the initial LOS zpos?

Any help would be appreciated, as usual. There are many other obvious questions around this issue (such as where the ''end'' point for these lines is), though the origin would be a good start. - [[User:Bomb Bloke|Bomb Bloke]] 07:44, 24 June 2010 (EDT)

== Training Stat Request ==

Hi there.

In the Equipment screen where the Weight and TUs are displayed during battle, would it be possible to also include the current unit's number of Reaction shots, Hits, Psi attempts and (possibly) Throws? Possibly along the bottom in a horizontal string where there's room?

User talk:Seb76

2011-03-30T01:31:53Z

Mannon: /* UFOloader and Xcomutil */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

My problem is the following: if I try to run the loader normally, a console window pops up for a few seconds then I get an "illegal instruction" error from NTVDM (and the window disappears, yet it's button remains on the taskbar until I kill the process). If I try to run it with DosBox however, I get "illegal command: UFOLOADER.EXE". Point is, I can't run this at all.--[[User:Amitakartok|amitakartok]] 11:27, 13 October 2009 (EDT)
:Looks like you're trying to use the DOS version here. Only the CE (windows) version is supported. [[User:Seb76|Seb76]] 13:48, 13 October 2009 (EDT)

Hi, is it in any way possilbe to run the Extender in Win98? I just set up an old machine with it and wanted to give it a try but as you said above, it won't work with Win9x. But is there a way to manually mod the game? I am asking becaus on my WinXP Machine the game often crahes in battlescape and that really sucks =(--[[User:Skaw847|Skaw847]] 19:28, 21 May 2010 (EDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)
:::I for one am a huge fan of XcomUtil, though I'm now also a huge fan of UFO Extender! I'm really hoping I can get the two to play nice. I was up until now playing a dos version, myself. Mainly because the version I bought years and years ago was the DOS version on CD and it still worked via dosbox, which also has several filters similar to your HQ4x. (Some run a little faster and I think they can run in a window while I can't get HQ4x to run windowed at all. I don't mind that so much, though the game runs noticeably slower when I run HQ4x and I prefer to run windowed these days so I can more easily multitask. Still I LOVE UFO Extender so I switched to the Windows version just for this.) Some of XcomUtil's features only work in the DOS version with split exe's because it goes back into the batch file and allows XcomUtil to play with things when switching from Geoscape to Battlescape and vice versa. But, it's not that big a deal for me. UFO Loader's feature list is more than robust enough to give that up. As for the sounds the Windows CE versions changed a lot of the sound effects. If you're used to this version then it's Np, but if you played the DOS version and got used to it then it's VERY off putting. Luckily it's easy to patch it back to the DOS sound effects. The "Enemy Unknown Extended" page here lays out an install that includes UFO Extender, the original DOS sounds, ect... It's a good place to start. Anyway, great tool. Now let's see if I can get these to play nice.[[User:Mannon|Mannon]] 04:40, 27 March 2011 (EDT) (I keep forgetting to sign things... too used to forums instead of discussion pages.)
::::Facinatingly XcomUtil actually DOES split the CE's executable into geoscape.exe and tactical.exe! It uses it's own sdump utility to do this during the setup batch file. I misread the above. XcomUtil splits them to preserve it's fuctionality so that it can use the batch file to knit them together like in the original DOS version and insert it's own exe into the mix. This does not make the windows exe run in DOS of course, but it does allow XcomUtil to keep it's functionality. I have to assume it really screws up UFO Extender, though... ;-( [[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)

Decided to look into this as there are a few XcomUtil features I like that aren't reproduced in UFO Extender. XCU does indeed split the exe. It also modifies both of the split exe's. It still loads both via fodder's loader when running them from the batch file. The command lines for that are "start /w xcloader geoscape.exe "0"" and start /w xcloader tactical.exe "1". Replacing xcloader with UFO Loader appears to work for tactical. The command line even appears to point UFO loader to the tactical exe since going into combat causes a problem. If I change the first xcloader call to "start /w xcloader" then the renamed UFO Loader finds the unsplit exe. Going into combat no longer fails like this, but it also prevents XcomUtil from running between phases. This does not prevent the running of XCU completely, but it will cause problems with some features, especially in the placement of soldiers in the new craft maps that XCU adds. Then again, by using the UFO Loader to use the original unsplit exe I believe that you are also bypassing all of XCU's modifications to the exe's as it probably does all those modifications to the geoscape and tactical exe's it created when splitting the exe. It may be possible to recombine those exe's or to find command line parameters that allow UFO Loader to load tactical.exe on it's own. The latter would probably be the best solution since it should allow XCU to function between phases.[[User:Mannon|Mannon]] 21:31, 29 March 2011 (EDT)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Could we get TUs (in current/max format) at the inventory screen while on a mission? It would greatly help with swapping weapons among soldiers.

* Could we get little numbers [like on the screenshot of accuracy mod] showing how much TUs an action on the inventory screen would take? Some players (me, of course, included) can't really remember all that reloading from backpack or from a leg slot TUs. Also...

* a "drop all" button, maybe?

* Soldiers' positioning in Skyranger is very good... but with the Avenger it is not so pretty. The ones at the top are not the ones closest to the trap door. Chooseable patterns, maybe?

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.
: '''Save Equipment''' is under development, still some bugs

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
** Eliminate "infinite fuel" exploit for conventional aircraft.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

* Enable native alien melee attacks within Alien Pets. The Floaters are pleading. (At the moment, Alien Pets+Big Brother means a crashed Superhuman Floater Large Scout costs 6-8 X-COM agents; corresponding crashed Sectoid Superhuman Large Scout is only worth 3-5 X-COM agents. Floater Large Terror Ship on just Big Brother : only one agent, and that was due to the top-of-stair pinning bug providing enough TU to do something.) -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Do something to help out the psi aliens as well within Alien Pets, as above. -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Would it be possible to change the master volume level in the game, or at least have a no sound option? [[User:Epiceuropean|Epiceuropean]] 00:26, 12 January 2010 (EST)

=== A few more ===

Do any of these take your fancy:

* Draw the Radar detection radii onto the map as a circle(s) around the base (also for moving aircraft?)

* Show All UFOs (Ultrawave Detector - like Show All Locations, but doesn't show Alien Bases, you still have to hunt for those).

* Sensible Ammo Recovery = add up all remaining rounds of ammunition at the end of a mission (in the ship, if Aborting), and recover a number of (full) clips equal to that number divided by the clip capacity (rounded down maybe).
: There's a reason I didn't turn Clip Recovery on, and it's that I guessed that it didn't work exactly as it's suggested here. If it did work like this, I would use it. [[User:Stubbs|Stubbs]]

* Implement tactical time limits for UFO Assaults/Recoveries. After a random period (within a pre-defined upper and lower time limit), the aliens leave. Pop up warnings appear at the end of each turn, saying the UFO engines are powering up. When the aliens leave, all aliens/items/equipment inside the UFO is gone - no loot, no score. Any soldiers still inside the UFO are considered MIA. The soldiers are ''captured'' in fact - score penalty worse than MIA? There must be one conscious alien inside the UFO for it to leave or attempt to leave. Maybe any live aliens outside are 'beamed' or 'tractored' inside the UFO, complete with their equipment? (E.g. the mission ends and you don't get score for them or their equipment either - just for the corpses and dropped loot).

* No Milk Please: After XCom withdraws from an Alien Base, randomise the base's location and make it hidden again. Just like what happens to the aliens after they fail to assault an X-Com base. Though you would probably still need to locate it within the same country or region so finding it again wouldn't take long I guess. Would it mess things up to move the base to a random part of the world?

* [[User:Spike#Tank mods|Tank Armour and Equipment Mods]]

But I should probably code this up myself, looking at your source code it doesn't look '''too''' hard. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

[[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

* Burning Zombies

It's more or less impossible to prevent Zombies from hatching into Chryssalids by killing the Zombies with fire, since fire does such a small amount of damage, and the requirement is that the actual killing point of damage is done by an incendiary. Apart from hitting them with an incendiary and running away, then waiting about ten turns for them to die (probably repeating the attack once or twice), this is only ever going to happen by blind luck.

It would be much more viable if the rule was (also?) that a Zombie which is '''on fire''' at the time of death would not hatch into a Chryssalid. This is not exactly easy either, but it is at least possible. It requires hitting the Zombie repeatedly with incendiary weapons until it catches on fire, then killing it right away with regular weapons (before the fire goes out).

A much easier version of this approach would be to say that if the Zombie is killed while it is '''in fire''', it does not hatch. But that is probably too easy.

A way to do this by hacking game files, without code changes, would be to increase the Zombie susceptibility to fire, to 200%. This would make incendiary weapons a viable way of killing them, as well as increasing the likelihood that the killing shot was an incendiary shot.

An alternative approach would be for the Zombie to have a chance of not turning into a Chryssalid, proportional to the percentage of health damage that had been caused by incendiaries. But that's probably too hard to track, it would require an extra/unused field in UNITREF.DAT.

[[User:Spike|Spike]] 13:12, 7 September 2009 (EDT)

* Fear of Fire

Apparently there is no morale effect from [[Incendiary#Damage|Incendiary damage]]. If anything, for humans, and maybe be for other humanoid aliens, fire should probably have a greater morale effect than ordinary damage, not none. A basic fix would treat fire damage the same as normal damage when reducing morale. A more complicated fix could add a weighting to this morale effect: multiply by the creatures susceptibility to fire (or reduce by its resistance to fire). Any creature or soldier that is immune to fire should not have its morale affected. Actually the affects of fire vary quite a lot (different aliens, different human armour types). Maybe this is why the designers didn't get around to implementing morale effects for fire, as it's a bit complicated.

[[User:Spike|Spike]] 13:40, 7 September 2009 (EDT)

=== Multi Stage Missions ===

Between each stage of a multi-stage mission:

* Send all artefacts (non-usable items), corpses and recoverables back to base
* If possible, remember the score for these items, and apply it to the score at the end of the mission
* Alternatively, pop up a score window between the mission stages, and apply the score then?
* Gather all loose usable equipment into the "equipment pile" for the next stage
* Or possibly re-run the Equip Screen between mission stages, again gathering all loose usable items into the equipment pile first.
* Keep an 80 item limit on what you can take into the next stage
* Prune down to the 80 item limit using some sensible rules, not sure what exactly.

This is of limited use in X-Com EU but would be much more use for TFTD, one day. EU has only one multi stage mission, and it ends the game, so only some of these points above will be relevant.

[[User:Spike|Spike]] 20:54, 2 September 2009 (EDT)

=== Even More ===

Tremendous work, you've pretty much made the game worth playing again. Best work since Xcomutil. As with everone else, I have a few requests. [[User:KingMob4313|KingMob4313]] 23:59, 12 August 2009 (EDT)

: Ability to change damage modifier. Right now the damage runs from 0-200% of damage values on the weapon. I'd love to see a way to change it to 50-150%, 75-125% or the like.

: A modifier to increase or decrease the explosion radius modifier. Right now the radius is either keyed to the explosive or to the explosive damage. I'll investigate it further. But it would be nice to have a very small radius, but high powered explosive for use as a breaching charge.
:: There is a "crimping" function on some of the explosions already so it might be possible to exploit that. Check the [[Explosions]] page. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

: A modification of the range based accuracy. One handed weapons have a shorter range, to the point that even their aimed shots have an effective range, two handed weapons have a further range (and no aimed shot effective range) and really heavy two handed weapons have an even further range.

: Ability to enable the Burst fire (5 shots over 3 picked spots) and/or the full auto mod that is on the heavy laser on other weapons (set by a flag).

: A modification so that on the alien's side first turn, they do not have their full time units in reserve for reaction fire. Nothing like getting shot 3 times from the same sectiod after missing ONE shot on them.

:: You could always wait a turn before you open the door. :) [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

::: Good point, I should be doing that anyways.

=== More Exploits to Close ===

* [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]

Probably the worst single exploit in the game. What is needed is to disable any mind control actions for a Psi Amp, if the unit holding the Psi Amp is currently mind controlled.

Also a general mind control bug/exploit fix for:

* [[Exploiting Mind Control#Exponential Mind Control|Civilian Traitors]]
* [[Exploiting Mind Control#Exponential Mind Control|Resurrect Zombified Agents]]
* [[Exploiting Mind Control#Exponential Mind Control|Zombie's Permanent Control of Aliens via Stunning]]
: Above 3 bugs are fixed by '''Hostile Civilians''' fix.

* Probably many other missing/MIA-type bugs

These probably all arise from the daft decision to save a single byte (or even bit), by not recording separately the current vs default "side" a unit is on. The game only tracks the "current side". Consequently when mind control ends, the game often makes dumb decisions as to what side to "restore" the unit to. We could use an unused byte to track the default "side", but that would require overloading a presumed "unused" field and that could be risky. But actually we can always deduce the "default side" from the unit type: XCom for soldiers and tanks, Neutral for Civilians, Alien for everything else. So what is needed is just an end-of-turn check to restore everything to its correct side, based on its unit type. Actually it's slightly complicated by alternating turns. You need to update all (originally) Alien units at the end of the Alien turn, all originally XCom units at the end of the XCom turn. You might also need a special end-of-game update, to avoid the MIA-type bugs. [[User:Spike|Spike]] 12:22, 26 August 2009 (EDT)

: AlienSWP.py implements turnswapping via mind control, like XCOMUtil. Handling the alternating turns, as you described, is necessary to make mind control work properly (a mind-controlled alien remains with X-COM during the alien turn, and so on).

: I would assume that the original programming team had a coding policy forbidding both bitfields, and emulating them with bitwise shifts. That's really the only way I can explain most of the idiosyncrasies of the file format. [[User:Zaimoni|Zaimoni]] 12:07, 26 August 2009 (CDT)

=== Soldier Colouration ===

Not the most "practical" request in terms of changes to gameplay, but still something I feel would be pretty cool if incorporated. Basically, the option to have the battlescape engine display soldiers according to their race/hair colour, as according to their inventory screens, [http://www.strategycore.co.uk/forums/post-a1669-.html like this].

The stored tactical [[PALETTES.DAT|palette]] is made up of 16 groups of 16 colours (256 total), in this order (though the last 16 colours are replaced with a grey-scale shade list at run-time, similar to the other fifteen groups - refer to the page on palette data for more info on that):

[[image:5_BattleScapePal.Png|center|frame]]

Solders are drawn using colours from three of these groups: One for their clothing (x50-x5F for overalls/power armor, xE0-xEF for personal armor), one for their skin (x60-x6F), and one for their hair (x90-x9F). Flying suits use a few extra colours, but they don't matter for the sake of this explanation (they don't show hair/skin anyways).

With my [http://www.strategycore.co.uk/files/index.php?dlid=686 battlescape editor] I incorporated a feature where you could have the program redraw units on the fly (as per the screen shot), changing just the hair/skin colour. For example, to check to see if a colour index was supposed to represent hair, it simply checks if "(''value'' & xF0) == x90", and if so, it'd add or subtract a certain figure to achieve the desired colour.

Well, there's a bit more to it then that (males in personal armor have a different hair colour already), but I'm sure the basic concept is obvious to you by this point. If you're interested, you can see a sample function in a file included in my toolkit - "bb_tact\UnitDrawer.java", line 384. It's not exactly well documented, but if you check the hair/skin arrays it refers to, it should be fairly obvious what it does. While the program is running, the "characteristics" variable is set to "true" by tapping C on your keyboard. Of course, I've no idea how the actual game deals with drawing soldiers, but I assume it decompresses every [[Image_Formats#PCK|PCK]] image every time it wants to draw it, same as my code does.

- [[User:Bomb Bloke|Bomb Bloke]] 09:46, 4 May 2010 (EDT)

=== See Also ===

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

== Completed Items - Thanks Seb! ==

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

* More video options. In particular, an option to put padding at the top and the bottom of the screen to preserve the aspect ratio on a 4:3 monitor. Maybe it's just me, but stretching the original height of the game to fit a 4:3 screen makes the Battlescape look weird. (Actually, if you update the source code link, I could try to do it myself. The current source doesn't seem to include your more recent changes. --[[User:Mikawo|Mikawo]] 20:30, 12 August 2009 (EDT))
** Thanks for uploading the new source code. I managed to add the letterboxing that I wanted. If you wanted to make it an official feature I could upload the updated files. And I don't think I said this before, but thanks for the great loader! --[[User:Mikawo|Mikawo]] 18:40, 14 August 2009 (EDT)
:Go ahead and upload/PM me the file (d3d.cpp I presume?), I'll gladly incorporate your modification. [[User:Seb76|Seb76]] 19:14, 14 August 2009 (EDT)

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

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

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

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

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

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

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."
:The above works perfectly. [[User:KingMob4313|KingMob4313]] 00:05, 13 August 2009 (EDT)

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.
:Fixed via Keyboard Shortcuts - and configurable too.
-- Sorry, I am having trouble finding this addition. Is it in the newest version? I can't see where to configure it if so.

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....
Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)
:I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that 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?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human 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?

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).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
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!
:I think this is a known issue with LOS, not sure though
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).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

There are major issues with your current weight calculations. I'm not exactly sure how it was occurring, but repeatedly messing around unloading and loading weapons, switching clips from the ground them putting them back in... at least one of these functions causes 'phantom weight' to be added to the soldier (e.g. strip them bare and they are still carrying a load). This was happening by 3 units of weight at a time; the weight of a clip. It's so bad that I managed to get 18 phantom weight units on a soldier before getting bored. Occasionally, 3 units of phantom weight would be removed again! It's hard to tell if this was in the original game, due to the lack of weight display in the inventory screen.

Edit: I've worked out what's happening. Add a loaded weapon to a soldier, unload it, and remove the ammo and gun: this ''removes'' 3 phantom weight units. But, add an unloaded weapon to a solider and load it... this ''adds'' 3 phantom weight units. [[User:Stubbs|Stubbs]]
:This is a genuine bug because they forgot to unassign the clip of a weapon when you drop it. Also the default weapon's clip is not initially assigned to the wearer so if you unload and reload the clip, your soldier weights more. [[User:Seb76|Seb76]] 13:27, 3 February 2010 (EST)
:: So is this impossible for you to override and fix? It's really irritating... I've edited lots of item weights, but I guess I'd have to make ammo light and guns heavy to minimize the effects of this bug. [[User:Stubbs|Stubbs]]
:::I second that, it would be great if this could be fixed. [[User:Rovlad|Rovlad]] 17:45, 13 May 2010 (EDT)

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

:: Alien reaction fire works fine for me within Alien Pets. -- [[User:Zaimoni|Zaimoni]] 12:41, August 12 2009 (CDT)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)
:Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)

The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. <3
:Uploaded a new version, you need to add a "HQ4x=1" line under the "Mod" section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)

Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)

Now the question is, how do you use DXWnd with the loader?
[[User:KingMob4313|KingMob4313]] 11:02, 12 August 2009 (EDT)

==Works but won't multitask==

Target system: prefab HP Vista with global data execution prevention. Problem is the same native, with D3D, and/or with HQ4X. (The two do combine nicely, visually, but a bit laggy for my tastes).

ALT-TAB terminates all further screen display on restore; the sea of blackness continues until Task Manager is used to kill the application, at which point D3D admits that it has "lost the device". (This is after the improved error reporting patch. Before, 0xc0000005 as Data Execution Prevention takes over.)

-- [[User:Zaimoni|Zaimoni]] 12:27, 12 August 2009 (CDT)

: Solved on Win7 for the most recent version: Program Properties dialog has an "unblock" button. Unblocking allows the program to survive being alt-tabbed away from. -- [[User:Zaimoni|Zaimoni]] 22:03, 24 June 2010 (CDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)
:That's great ;-) By dev I was refering to the "dev" version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)

Hi Seb, I've been playing the UFO series since the beginning but just joined this wiki. I've tried just about every mod there is for these games, and I must say, yours is one of the best as far as creating a "more complete" and stimulating game experience. My question is in regards to your "Heavy Laser" mod. I liked what you did by creating new "abilities" for the weapon with the Full auto and Burst fire mode, but every time I play I can't help but think that it just doesn't belong to the Heavy Laser as a weapon. I always envisioned the Heavy Laser as more of a long range "Sniper" support weapon, and I like the mod that the X-ComUtil added that gave the Heavy Laser a new life by increasing the accuracy and damage of the weapon making it one of the best Sniper weapons available (even if it is heavy to lug around) as well as finaly giving my troops a greatly needed new weapon for disposing of those pesky sectopods (on any difficulty). I do, however, think that the new fire modes (full auto and burst fire) would be a perfect addition to the Auto-Cannon. The in game image alone has always brought to mind a "mini-gun" type weapon that should be capable of very rapid fire, but at the expense of accuracy due to the encumbering nature of the beastly AC. I never liked how the AC seemed like a generic Heavy Cannon with less damage and only the added auto shot function. Also, I always wondered why that weapon even had an "Aim" function. Who's going to sit there trying to carefully aim a Gatling Gun? Nobody... that's who, you use a weapon like that for mass devistation and shock value, PERIOD! This is why I think that your mod to the Heavy Laser should be reconsidered for the Auto-Cannon. I think, at the very least, it will give people a reason to use the AC in the mid to late portion of the game, and being that it still has weak stats compaired to other weapons, it's not going to be overpowered or infringe on the use of specialty weapons (I think the Heavy Laser with full auto and burst fire is a little un-balanced due to its considerably higher power). If you don't agree that's fine, but since I'm not very knowledgeable about game programing, I was wondering if you could at least give me a hint on how to create similar weapon functions for other weapons, cause I'd like to at least try it out for myself. Thanks for any help you can give me and keep up the good work, you're mod is awesome.

== REng UFO with IDA ==

Hi Seb =)

I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.

So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).

Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.

I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.

My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).

Any advice is deeply appreciated mate =)

XCom forever!
--[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)
:Hi k9,
:Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.
:For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...
:Good luck with your project,
:[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)

:::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...

void InsertCall(int dst, void *func)
{
DWORD oldProtect;
DWORD *pOffset=(DWORD *)(((char *)dst)+1);

VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&oldProtect);
*(char *)dst=(char)0xE8;
*pOffset=(int)func-(int)dst-5;
VirtualProtect((void *)dst,5,oldProtect,&oldProtect);
}

::: This calculation here is interesting:

*pOffset=(int)func-(int)dst-5;

:::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).
:The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).
:The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)

:::Can you suggest some good reading material to better understand this? Cheers!
:::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)
:You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the "UFO Defense" process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)

== D3D ==

If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has.

I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)
:You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)

Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)

OK I ran the dxdiag utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)
:Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.
:Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)
Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)

D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J'ordos]] 19:09, 8 August 2009 (EDT)
:edit: forgot to mention, I have directx 9.0c installed and dxdiag reports no problems. I have a Geforce2 MX *blushes*
:Do you know if this card supports non power of two textures? [[User:Seb76|Seb76]] 05:10, 9 August 2009 (EDT)
::no idea, but since your new version works fine with the D3D option on I assume it doesn't :) [[User:J'ordos|J'ordos]] 11:38, 9 August 2009 (EDT)
:That's great. Spike, does it fix your problems too? [[User:Seb76|Seb76]] 16:04, 9 August 2009 (EDT)
::Sorry for the late reply - yes that fixes my problems too, D3D is working fine now. Thanks, [[User:Spike|Spike]] 15:55, 26 August 2009 (EDT)

== Save equipment ==

Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:

*1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of "invisible" equipment!
*Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips.
*The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.
*Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment.

Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked?

Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)
:Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.
:The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?
:As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.
:I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)
::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a "before" and "after". [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)
:In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)
::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns & ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)
:OK, I'll have a look at this, thanks for the effort.
:Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the "i/b" one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)
::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)
::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)
::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)
:I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)
:: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)
:Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)
::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)

Hmm more problems with Save Equipment. Ammo of all types seems to disappear. Eg I have 6 pistols and 6 pistol clips on the craft, but the Equip screen just gives me 6 empty pistols. Other weapons are short of ammo too. Is the Save feature perhaps "remembering" empty weapons (or loaded weapons) and somehow eliminating the clips. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)
:This looks like an issue with ''UnloadClips''(). I noticed that the clip object's ''loaded_into'' is set to 0xff, but the ''not_loaded'' remains as 0. The game may see this as the clip still being loaded in an object, so the clip effectively disappears. --[[User:Mikawo|Mikawo]] 11:05, 19 August 2009 (EDT)
::This is possible. The wiki is wrong on these 2 fields BTW: it is in fact just one field (loaded_into signed extended to 16bit). I'll have a look at that. [[User:Seb76|Seb76]] 14:33, 19 August 2009 (EDT)

I think Mikawo is right. UnloadClips() should look something like this:

void UnloadClips()
{
obpos_dat *pObPos=pObpos_dat;

for(unsigned char i=0;i<170;i++)
{
if(pObPos->itemType != 0xff && pObPos->not_loaded == 0 && IsXComItem(i))
{
pObPos->loaded_into=0xff;
<big>'''pObPos->not_loaded=0xff;'''</big>
}
pObPos++;
}
}

Quite a few other functions in '''equipment.cpp''' use this check '''pObPos->not_loaded == 0xff''' so it is important to set this flag just for UFOExtender, regardless of whether the game needs it set (which it probably does). Eg items unloaded by UnloadClips will thereafter fail to be found by GetFreeItem, during execution of LoadSoldierEquipment. That probably explains the problems observed.
[[User:Spike|Spike]] 15:24, 26 August 2009 (EDT)

:I did some rework based on that. Do you have other problems? [[User:Seb76|Seb76]] 16:08, 30 August 2009 (EDT)

::Thanks Seb. This seems to be working mostly ok now. Some remaining smaller issues I have seen:

::* The weight calculation is so accurate, it is more accurate than the unmodified game. So the "weight free ammo" (the first clip loaded into a weapon, before the user takes any action in the Equip screen) is no longer weight free. Not sure if you want to "fix" this or not? It is debatable. Really, you have fixed a bug. But the normal game behaviour has changed. Maybe make the "weight free ammo" optional?
::* There is a weird glitch. If I unload a weapon, put it and the clip on the ground seperately, that works fine. But if I pick up the clip '''directly from the ground''' and load it straight into the weapon, then drop the weapon, the weight of the clip is still shown on the soldier. And actually the same thing happens with a clip that is first moved into the soldier's equipment. So in fact the problem is that a clip loaded into a weapon, doesn't get removed from the soldier weight when the weapon is dropped onto the ground. It happens even if the clip is pre-loaded by your routine.
::* Still outstanding - you can't use the right arrow to move onto a second screen of equipment. So you can't have more than one screenload of equipment on the ground. Or maybe you can, if you start the Equip screen with more than one screenload on the ground - I didn't check that.

::[[User:Spike|Spike]] 13:10, 1 September 2009 (EDT)

== Glitch with Alien Pets and Big Brother? ==

Hi Seb. I was trying to do some initial research on the idea of [[User:Spike#Tank mods|Tank mods]] but it looked like these 2 useful features of your Loader, Alien Pets and Big Brother, have both stopped working. Can you test this, on the latest version? I'm using a very recent version (last 2 weeks) but not the absolute latest as I have internet download problems.

Also, have you seen this new Wiki article: [[Enemy Unknown Extended]]. It is a package including your loader plus a few other odds and ends.

cheers,
[[User:Spike|Spike]] 11:16, 17 August 2009 (EDT)
:My mistake, I commented out that part of code a while ago and only recently noticed that. It was corrected one or two versions ago.
:The article is a good idea, it should allow less techies an easy start. [[User:Seb76|Seb76]] 13:51, 17 August 2009 (EDT)
:: OK cool yes the Hacks are back in place, thanks. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)

== Alien Bleeding ==

Test results:

* 1-unit and 4-unit aliens can be healed by anyone (alien or human) holding a Medkit
* 4-unit aliens can be healed by standing in any of their 4 squares
* 4-unit aliens can only be healed while they are stunned. Pointing to their "control" square does not seem to work.
* 1-unit aliens can be healed either while conscious or while stunned
* Wounds on aliens can be correctly seen with Medkits
* The Medkit display shows a human silhouette regardless of the alien type, of course
* Healing aliens with Medkits, stops them from dying of wounds (not 100% tested but seems to be true)
* Aliens (large and small) seem to lose the correct amount of Health per turn from Wounds
* Aliens with wounds that are not treated, eventually die (not 100% tested but seems to be true)
* A Mind Probe can see if an alien has Wounds.

Anomalies:

* I had a lot more reports of Reapers dying than I would expect. I would not have expected any to die, and I had 3 reports of death by wounds. Even heavily wounded Reapers take a long time to die. In my test I was only shooting them with Pistols. Maybe there is a problem with the reporting? Maybe the death of the same Reaper was reported more than once? More testing needed on this.
:I wonder if Reapers are receiving wounds on all 4 sections when hit by explosives (I don't know which weapon you were using). They really shouldn't, although I'm unsure how you'd get around this. If possible, put a cap on the maximum number of wounds something can ever have (perhaps 6). You could argue their multiple hearts really empty their blood out quickly, but I don't think fatal wounds should ever become more dangerous than burning alive.

:: Well, why not: hit four times by one explosive, check for incurring fatal wounds four times. -- [[User:Zaimoni|Zaimoni]], 13:49 Sept. 6 2009 CDT

* Question: should the death of an alien by wounds be reported, or should it die silently? Did I only see these messages because I was using Alien Pets, and so they were on "my" side?
:Regarding death reports, I enabled the dialog for aliens/civilians (it usually only shows up for xcom operatives) to help in testing. The final version will not show them. [[User:Seb76|Seb76]] 14:10, 3 September 2009 (EDT)

Caveats:
* I used the Alien Pets, Big Brother, and Alien Inventory hacks to do this test. I also hacked a save game to give me Pistols, Medkits, PsiAmps and Mind Probes. [[User:Spike|Spike]] 16:03, 3 September 2009 (EDT)

To Do:
* Test if aliens (small, large and mechanical) suffer from [[Fatal Wounds#Other effects of Fatal Wounds|other effects of wounds]], e.g. penalties to Energy, Accuracy, Time Units
* Do Cyberdisks, which have no legs or arms and probably no head, only ever receive Torso wounds?

=== Mechanical Bleeding ===

* Question: Do Cyberdiscs and Sectopods receive Fatal Wounds? I'm wondering whether an unconscious Cyberdisc is safe to be around. Even if they didn't explode, Fatal Wounds would be stupid for a robot. If XCOM tanks can't end up leaking fuel and sparking dangerously, neither should enemy robots. [[User:Stubbs|Stubbs]]
: I think you can make a case for tanks and robots having "wounds", i.e. damage that gets progressively worse by itself. You can even make a case for them being "stunned" - temporarily non-operational. You can even make a case for it applying to alien robots but not to X-COM tanks, since alien robots all have some degree of organic component (which is why they can be Mind Controlled). But I still think you are right, neither effect should apply to machines, whether alien or human. As for your question, see the tests below:

Cyberdisk Bleeding Test Findings:
* Cyberdisks take Wounds (with Alien Bleeding option enabled)
* Cyberdisk wounds can be healed (though only after unit is stunned)
* Cyberdisks lose health from wounds
* Cyberdisks can die from wounds
* Cyberdisks don't seem to explode when they die from wounds ("has died from wounds" popup)

Cyberdisk Bleeding TestTest Caveats:
* Same caveats as previous tests (above), plus:
* The Cyberdisks were modified from Reapers using xcomutil :rpl
* Some Pistols were changed to Laser Rifles using xcomutil :chg
* (xcomutil was not installed in the game directory however, it was used from another location)
* The stats (Armour 34 all round, Health 120) appeared normal for Superhuman
* However the Cyberdisks seemed to fall too easily to Laser Rifle fire (e.g. 1 hit)
* Also, they seemed not to explode as often. This was because they were often stunned.
* Hard to tell in-game whether a Cyberdisk is dead or stunned. The graphic is the same, you can't use a Mind Probe, nor look on the ground, nor even check by changing sides.
* Actually there is one way to tell: stand over it and use a Medkit. Didn't think of that. [[User:Spike|Spike]] 08:22, 5 September 2009 (EDT)

:Thanks for finding out, Spike. Autopsy text shows you are right about the Sectopod( but not about the Cyberdisc) having biomechanical components, but it's not like there are gallons of blood pumping around the thing to gush out. One thing: did you check both conscious and unconscious death-by-wounds for the Cyberdisc? [[User:Stubbs|Stubbs]]
::No problem Stubbs. I didn't deliberately test this, but I had numerous deaths-by-wounding while unconscious and I think at least a few while conscious. I believe those that died while conscious, exploded. (I think this is the basic rule for Cyberdisks. If they are stunned, they don't explode. This typically happens with stun weapons but can also happen with regular weapons, if you are lucky.) [[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)

* Seb76: maybe robots receiving wounds was an oversight, or maybe you really do want robots to take wounds. In either case, it would be nice to have a separate option for this. My arguments against robot wounds are pretty simple: tanks do not receive them, the bled-out dialogue "X has died from a fatal wound" sounds silly for a robot that was never alive, and finally that a Medkit should not be able to heal a robot.
: It's reasonable that alien mechanisms (Sectopod, Cyberdisk) would not suffer from wounds. Possibly also Zombies should remain immune to wounds? From a note Seb made elsewhere, I think the UNITREF.DAT "can be wounded" flag is the same as the "can be stunned" flag. Wounding is probably prohibited globally for aliens, by an override somewhere in the executable. Seb has probably removed this override, unconditionally. To remove the override more selectively, I suspect Seb would need to put a logic test in the code, to check the alien type. .[[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)
::There was a check for ownership that I simply removed. Next version will have an explicit check for robots/chryssies/zombies not to bleed. [[User:Seb76|Seb76]] 12:29, 6 September 2009 (EDT)

* If you want a sense of "the Sectopod's leg got damaged" or even "the tank's track was broken", perhaps robotic units could be 'wounded' by damaging max TUs.
* If, however, the above won't let weapon usage TU %s recalculate as TUs are lost (i.e. the units lose firing ability as well as walking), then certain values of Energy with the correct Energy usage modifier could emulate loss of speed without losing firing ability. Since Energy is returned at a rate of 1/3 of TUs, these units could have an Energy value of (slightly less than) exactly 1/3rd of their TUs. Their energy usage modifier is then changed to allow this small energy value to usually suffice. Now, when Energy is damaged, the units will be permanently slowed, but their weapons won't be affected. [[User:Stubbs|Stubbs]]

=== Zombie Bleeding ===

Zombies that bleed to death don't seem to turn into Chryssalids. As discussed above, it might be better to disable wounding for Zombies. (Death by wounding for Zombies was already possible, without this fix, if the Zombie was mind controlled, wounded while mind controlled, then released back to Alien control.) [[User:Spike|Spike]] 21:07, 5 September 2009 (EDT)

== Hostile Civilians ==

This fix also seems to prevent:
* [[Exploiting_Mind_Control#Zombie's_Permanent_Control_of_Aliens_via_Stunning|Permanent Control of Aliens via Stunning]] Exploit - as was hoped for.
* [[Exploiting_Mind_Control#Resurrect Zombified Agents|Permanent Control of a Chryssalid/Tentaculat]]

It does not fix:

* Various Mind Control bugs:
** [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]
** [[Known_Bugs#Mind Controlled Aliens Count as MIA if you Abort]]

(Probably because fixing both of these requires special, end-of-mission processing)

Still To Be Fixed:

* [[Exploiting_Mind_Control#Exponential Mind Control|Exponential Mind Control]]

(This requires a check in UNITPOS to ensure that the unit attempting Mind Control is not, itself, already mind controlled.)

[[User:Spike|Spike]] 16:16, 3 September 2009 (EDT)

== Fixed Funky Fire and Zombies ==

Fixed Funky Fire still permanently kills Zombies, when the killing damage comes from (end of turn) fire damage. [[User:Spike|Spike]] 21:02, 5 September 2009 (EDT)

== Research Tree ==

I've found a way of modding the research tree and was wondering if people are interested in an updated version. I've read of stuff like enabling hovertanks from cyberdisc autopsies or flying suits with floater research, but I think there is more that can be done. The limitations from the original game is that having researched a topic cannot unlock more than 4 new topics, and cannot unlock the production of more than 4 new item types. Any ideas? [[User:Seb76|Seb76]] 12:40, 6 September 2009 (EDT)

* Another one I mentioned was: Mind Probe before Psi-Amp, although I'm going to retcon that to "Mind Probe before Psi-Lab" (which then leads to Psi Aimp as per usual). The logic behind this is that the first step of a psi-attack must be scanning for enemy brainwaves to pick them out of the other signals. Before you can teach soldiers to do this, you'd have to have studied the mind probe to see how the non-psychic aliens are managing to find targets. You've got to walk before you can run, after all.
* I'm unsure if the next suggestion is possible, given what you have said. I'd like some kind of necessity to research at least some corpses/aliens - is it possible to require, say, any 6 alien 'live' or 'autopsy' reports finished before Alien Origins unlocks? You might also make it dependent on difficulty (6/7/8/9/10 needed). You could also include alien missions in this count.
* My only other suggestions are: you should have to research Elerium before you can build anything that requires Elerium to build. You should have to research Alien Alloys before you can build anything that uses those (which is true only for some things currently. It doesn't seem to be a prerequisite for building alien weapons). Is it possible for a manufactured item to require two separate research entries to be manufactured?
* Question: is there also a limit of 4 prerequisites for a research item? [[User:Stubbs|Stubbs]]
:There is no limit on prerequisites, it's the code that shows "you can now build/research xxx" that has a 4 entries limitation. [[User:Seb76|Seb76]] 15:05, 6 September 2009 (EDT)

A boring suggestion but how about making sure that for all weapon research, you need to do the pistol before the rifle before the heavy weapon, etc. And similarly with the ammo types. Apart from that, I'll think on it. [[User:Spike|Spike]] 17:42, 6 September 2009 (EDT)

Another boring suggestion: each specific laser weapon should take a little longer to research - force you to use the starting weapons for a little longer. You could also rebalance the Plasma research times so that the rifle took a little longer and the Heavy Plasma took significantly longer. It might then be more viable to research them from weakest to strongest, without forcing your hand as Spike suggested. [[User:Stubbs|Stubbs]]

:Yep that's a good alternative.

You could make the Stun Launcher a little harder by requiring (as well as Alloys and Elerium), perhaps a live Medic to be researched before the Stun Launcher (since it's usually Medics that carry them and presumably understand how to operate them), and an Engineer for a Blaster Launcher. It's not much extra but it helps to make these powerful weapons a little harder to get. If you wanted to make Blaster Launcher quite a lot harder to get you could add something like UFO Navigation (something to do with plotting all those waypoints, alien-stylee), or at least a Mind Probe for similar reason.

But, what are we trying to do here? Make things harder in general? That's one option. Or "rebalance", i.e. make things that are relatively too easy to get, relatively harder to get? Or make things more "logical"? There's lots of ways to play this.

It's a shame there's not a distinction in the game between using, and manufacturing, alien weapons - as is done in XcomUtil. Really, there should be a world of difference between figuring out how to use scavenged alien weapons, and actually being able to manufacture them. But that's not really a research tree topic, '''unless''' - would it be possible to create new topics? Could you separate out the using of an item from the manufacturing of it? (If not, it would be good to have a game variant in which nothing that can be scavenged, is allowed to be manufactured).

UFO Navigation might also be a good prerequisite for Hyperwave Decoder. I'm sort of rambling here, but what are the most powerful technologies, that are kind of easy to get... which ones need to be made harder. (Are there any that need to be made easier?)

Powerful technologies:
* Psionics (Psi Lab == Psi Amp). Adding the Mind Probe, as suggested, would be a good idea. Maybe a psionic Commander capture required for each.
* Blaster Launcher - maybe require an Engineer and a Soldier research, as well as Elerium & Alloys. Mind Probe or UFO Navigation for the "plotting" element? A separate Engineer capture to produce the ammo? What else?
* Stun Launcher - Medic and an Engineer? Maybe a full set of autopsies - but that's too onerous.
* Heavy Plasma - stretching the research time would be good, though this can already be done. Additional pre-reqs - maybe add a live Engineer requirement (maybe for ''each'' Plasma weapon type?). If you keep making these requirements you probably need to add a hint in the UFOPaedia along the lines of "we will need to interrogate alien technical experts to further understand this weapon technology". (OK that's hardly a hint.)
* Laser Cannon (?) - But I'm not sure this Laser Cannon factory thing is a big deal. Arguably building a new intercept base is a better cash cow than building a 50-Engineer Laser Cannon factory.

[[User:Spike|Spike]] 16:34, 8 September 2009 (EDT)

== 64 bit compatibility ==

Any way to make the loader compatible with 64-bit operating systems, like 64-bit XP/Vista/7? [[User:Jwilcox25|Jwilcox25]]

: I'm using it on Windows 7 and it's working fine. Not sure if that's 64 bit though. [[User:Spike|Spike]] 07:26, 9 September 2009 (EDT)

:: If you're not sure, you are probably running the 32-bit version of Windows 7. Starting from XP, Windows comes in both 32-bit and 64-bit flavors. Most 32-bit programs are backwards compatible, but apparently not X-COM from my experience. [[User:Jwilcox25|Jwilcox25]]

: It works fine with Windows 7 64-bit. Didn't have to enable any compatibility options or anything like that. [[User:Rovlad|Rovlad]] 02:29, 23 April 2010 (EDT)

== Music bug ==

When enabled "MIDI freeze" bugfix, after entering first combat the music stops playing completely, for the remaining game session.

Also, when using Extender, for some reason music is playing at really low volume, i have to manually reduce my main sound channel and crank up the volume to hear it. When just starting normal UFO CE volume levels of music and sfx are about equal. I have SB Live & WinXP.

== Fire Speed bug ==

Sometimes, for no apparent reason, fire speed setting jumps to 3, instead of what you had it set on.

: I believe it's a bug in the game itself, not the loader. I remember encountering it in both DOS and CE versions. [[User:Rovlad|Rovlad]] 02:31, 23 April 2010 (EDT)

== Reserve TU for x-Shot ==

Not sure if this has been addressed or fixed, but if you reserve Time Units for any shot type, all you get is Snap Shots for the reaction phase - never aimed or auto. Is there any way you could enable these two unused types for reaction shots? --[[User:Zombie|Zombie]] 22:51, 25 October 2009 (EDT)
:As far as I can tell, the reserve is only meant to be used during the active turn. Reaction shots are hardcoded to snapshots (that's true for the aliens too), it's no bug that your guys don't use reaction autoshots. [[User:Seb76|Seb76]] 12:10, 16 January 2010 (EST)

== TFTD ==

I know you're hoping to perfect the current version before taking on any new projects, but I just want to add my plea to the others requesting a TFTD version. Even some of the basic functionality would be awesome and probably completely portable, such as the stats on the equipments screen, default new base, etc.

== Can't change tasks in D3D ==

Hey, I'm having an issue with D3D. If I alt-tab out, I can't switch back to the X-Com task. I'll switch to it but nothing can happen. I'm on Windows 7 x64 with an ATI Radeon HD 5770. [[User:Rlbond86|Rlbond86]] 20:19, 15 January 2010 (EST)
:I too have hangups sometimes when alt-tabbing out of XCom, sadly I'm no D3D expert :( I'll add more checks to see if resetting the D3D device worked though. If anyone knows of a 100% working way of dealing with "device lost" conditions, now is your chance... [[User:Seb76|Seb76]] 12:06, 16 January 2010 (EST)

== Battlescape Soldier's Stats Crash ==

I'm having this little problem with this and I wanted to know if I'm the only one that's suffering with it: everything works fine, but when in battlescape mode I want to check the stats of a soldier (by clicking his rank icon) the entire game CTD. Does it happen to anyone else? How can I fix it?
:Never saw such problem...
:* Does it still crash when you disable the extender (and what options did you enable)?
:* Do you have the address where the crash happens?
:[[User:Seb76|Seb76]] 15:55, 22 January 2010 (EST)
::It didn't, but now I reinstalled the game and it works wonderful. This is a great job you did here. Is there any chance that you could access to the stats of the soldiers from the assign crew screen? --[[User:Slibluhr|Slibluhr]] 16:56, 22 January 2010 (EST)
::OK, I could reproduce the crash this time, it has nothing to do with the stats screen as I supposed to do. The game crashes RANDOMLY if I have turned on the D3D thingy, any clue? I've also noted that if I turn on the caps mod (to put most of 'em in 150-200 to overcome the distance penalty) the soldiers do NOT improve, even after kicking a large scout's butt with KAtherine Sharpe, she didn't get any FAc point! --[[User:Slibluhr|Slibluhr]] 05:30, 23 January 2010 (EST)
:The caps bug is a known one, and a fix is available. I thought I'd wait for more substancial stuff before releasing a new version though. You can try the latest dev version that has the fix included.
:As for your crash I cannot do much without a crash address... [[User:Seb76|Seb76]] 11:46, 24 January 2010 (EST)
::This is what it said during last crash:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00011689

::--[[User:Slibluhr|Slibluhr]] 15:29, 24 January 2010 (EST)
:Sadly the address is of no use (crash inside Windows code, most likely because of wrong arguments). I've put a new version up with better D3D error handling, does it help with your crashes? Also since I was feeling like it, I updated the "Reorder Soldiers" feature so that when you click the name of the soldier, his stats show up. You must click the rank/name of the ship to assign the soldier. [[User:Seb76|Seb76]] 18:00, 24 January 2010 (EST)
::Thank for the access to the stats of the soldiers via crew screen, it releases them from having their FAcc and PStr in the name.

:: btw, the crash moved to this location now:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00028c0b

::could it be that's my pc's fault? does this happen to anyone else?

::------------------
::System Information
::------------------
::Time of this report: 1/25/2010, 01:25:00
:: Machine name: 0X000001
:: Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.090804-1435)
:: Language: Spanish (Regional Setting: Spanish)
::System Manufacturer: FOXCONN
:: System Model: A6VMX
:: BIOS: BIOS Date: 03/13/09 09:59:28 Ver: 08.00.14
:: Processor: AMD Sempron(tm) Processor LE-1250, MMX, 3DNow, ~2.2GHz
:: Memory: 3072MB RAM
:: Page File: 466MB used, 4490MB available
:: Windows Dir: C:\WINDOWS
:: DirectX Version: DirectX 9.0c (4.09.0000.0904)
::DX Setup Parameters: Not found
:: DxDiag Version: 5.03.2600.5512 32bit Unicode

== Store limit question ==
Nice to see you've implemented the general store change (unfortunately, UFOExtender doesn't work under wine, so I can't test this). I'm curious why 187 is the limit? I thought it would be a power of 2 (possibly minus 1)... Possibly you wanted to write 127? [[User:Cesium|Cesium]] 19:43, 21 February 2010 (EST)
:You can build 35 general stores max in a base and 65535/35 ~= 1872 (the internal representation is ten times what's shown ingame). [[User:Seb76|Seb76]] 00:19, 22 February 2010 (EST)

== Mouse scaller not working on Windows 7 x64 ==

with d3d=1 and Scale Mouse=1 I still have issues with the mouse going way off screen.
--[[User:BladeFireLight|BladeFireLight]] 01:57, 22 February 2010 (EST)
:I have noticed that alt-tabbing out of X-COM at the title menu (or any other point that won't crash it) and then alt-tabbing back into it fixes this problem for me in Win7-64. --[[User:Xusilak|Xusilak]] 13:12, 22 February 2010 (EST)
::Thanks for the heads-up. I uploaded a test version here: http://www.ufopaedia.org/index.php?title=Image:UFOExtender-dev.zip
::Does it fix you problems? [[User:Seb76|Seb76]] 14:36, 22 February 2010 (EST)
:::Yep. Seemingly no issues with the mouse going off the screen using it, although I didn't test for long. I'll try to get more test time in later. --[[User:Xusilak|Xusilak]] 20:46, 24 February 2010 (EST)
::::Actually, it doesnt work for me either, in WinXP. And it was broken since the version of 7th November, the one with windowed mode addition. Also, Alt-Tabbing didnt work too. This fix makes things right, though.
::::Edit : also, this dev version crashes in 100% cases when going to battlescape.
::Strange, I do not have any trouble even when using split binaries. Do you have an address for the crash? [[User:Seb76|Seb76]] 14:03, 1 March 2010 (EST)
:::Okay, i hope this is what you wanted, but it says the adress is 0x0000000000bd22ca. I can load an actual save with tactical mode, but cant go into tactical from geoscape. So i use the version from 1st November still.
:Hum, you say the dev version crashes and that you are stuck with the version from 1st november. Do you mean you have the problem since the version of november the 7th, independently from the dev version? [[User:Seb76|Seb76]] 14:08, 4 March 2010 (EST)
::Actually yes. At first i didnt want to use it, because i use a tablet instead of mouse, and its really noticeable when a window failed to scale properly, since a tablet works in absolute screen coordinates. But just now i checked several new (non-dev) versions for the crash - its there. Crashes every time i try to enter tactical mode from geoscape. Saves from tactical load up fine. Version from Nov.1st gives no problems whatsoever.
:Do you still have the problem if you disable D3D or use windowed mode? Also if you load a tactical game, don't you get a crash when it goes back to geoscape? [[User:Seb76|Seb76]] 03:20, 6 March 2010 (EST)
::When disable D3D - yes. When enable windowed - yes. When going from tactical to geoscape - no.
:OK, I suspect this has to do with the "Save Equipment" feature. Can you try disabling it if you have it on? [[User:Seb76|Seb76]]
::OK, um...i tried all my saves, and with that feature disabled all my saves load up fine, and i can go from geoscape to tactical and back. So i thought everything was alright, and kept playing - the very next tactical mission loads up fine, but as soon as i try to move anyone - it crashes. And that is the same in all my saves, first mission is alright - second one always crashes. The crash adress is 42064f, in case you're gonna ask.
:Alright, can you PM me a savegame before the crash? I doubt it'll help but who knows...[[User:Seb76|Seb76]] 12:43, 6 March 2010 (EST)

== Extender in Steam (+ maybe XComUtil) ==

Hi do you know of any way to use the two apps together with the Steam version? I would really like to be able to combine the 'Reorder Soldiers' feature of Extender and the 'Capturing Aliens for Research' of XcomUtil.

Actually now that Ive put a bit more time into it I can't get UFOLoader.exe to run in steam's dosbox implementation at all. I can just run UFOLoader but it doesn't run in dosbox which makes the game run horribly. If you don't have a steam copy for testing / integration of the basic Extender program please let me know and I would be happy to send you a gift copy.

-Dogfish

P.S. What a great program, you are a credit to gaming.
:As far as I know, the Steam version also ships with the windows CE edition, the default shortcut just happens to point to the dosbox one. Also the latest version of XComUtil is able to detect the loader presence and act accordingly. [[User:Seb76|Seb76]] 15:42, 25 February 2010 (EST)

:: STEAM comes with both EXE. XcomUtil and UFO Extender work together with STEAM. To use Setup UFO Extender in the game folder. Then Download and install the latest build of XcomUtil 9.7. It will auto start XcuSetup in windows, Detect UFO Extender and allow you to configure RunXcom to use it. To use UFO Extender, or UFO:CE you can't launch the game from STEAM. You have to create a short cut for RunXcom. (Right click > send to > Desktop as Shortcut) --[[User:BladeFireLight|BladeFireLight]] 19:13, 25 February 2010 (EST)

Thanks guys I was able to start the game with both mods. I apparently had everything configured correctly but I kept launching it from steam. Is there a way to play in windowed mode (since its not using dosbox)? I tried launching dosbox and running 'RunXCom.bat' file from there but it does not recognize UFOExtender.

Oh boy the game is fast, even on slowest scroll it is difficult play a battle :)

-Dogfish
:What options did you turn on? [[User:Seb76|Seb76]] 14:18, 26 February 2010 (EST)

Show Stats=1
Apply=1 (wreck analysis)
Proximity Grenades Experience=1
Elerium-fueled Craft Bug=1
Save Reserve Mode=1
Rank In Inventory=1
Manual Interception Fire Mode=1
Crafts Always Ready=1
Reorder Soldiers In Crafts=1
No Funkers=1
TFTD Doors=1

Full System Specs:
Win Vista 64
Intel i7 920
6GB RAM
GTX 285 Video
Asus p6t

Everything is fast the geoscape tics are at least 5 times faster than running the non-Extender mode via dosbox.

Would you have any suggestions how to slow it down? I've actually been playing in steam(dosbox) with XComUtil only and then saving/loading between missions so I can reorder the soldiers.

Aha! I found the D3D Windowed option...
HQ4x=0
D3D=1
D3D Windowed=1
Always On Top=0
Clip Cursor=1
Scale Mouse=1
Screen Ratio=0.833333

I can manually resize it to be bigger, excellent!
What is strange is that running it in windowed mode seems to slow it down enough for the scroll speed settings to make it playable :)

I ran into a "Unsupported 32/16/64 bit error message switching from geoscape to battlescape but it happens only 1/3 times maybe?"

I will be playing this and let you know if I run into any more problems.

Thanks a bunch!
-Dogfish

Hi guys, dogfish again I've been getting a couple of glitches.

1. Switching from battlescape back to geoscape in the cmd prompt it displays
'echo----------------------------Leaving' is not recognized as an internal or external command, operable program or batch file.

2. This has happened twice

Get someone who has been shot is at low health and has fatal wounds

Have them pass out due to smoke inhalation

Let them bleed to death and get the "Joe McSoldier has died from a fatal wound" *while unconsious from the smoke*

I will lose points for the mission but the soldier will be recovered at the end of the mission but terribly wounded. (Currently Hans 'Jesus' Vogel is taking 55 days to recover his 41 health.)

:Both of these are XcomUtil issues. 1 has been fixed in Build 413 but I need a saved from just before ending combat to fix 2. --[[User:BladeFireLight|BladeFireLight]] 18:19, 28 February 2010 (EST)

::Sent the savegame to your gmail (whatever was listed on my paypal reciept from your donate button). Just hit end turn (all the aliens are dead) and the bug is triggered. -Dogfish
::: I got it. Was up all night with Bomb Bloke and we worked out what was going on. The fixed works with your save. The next build will fix the zombie bug. Also Thanks for the donation. Every little bit helps. --[[User:BladeFireLight|BladeFireLight]] 16:02, 1 March 2010 (EST)

--
Hi! I'm thefarside. This is my first time ever editing a wiki page so please bear with me. I'm not even sure I'm allowed to do this.

However, I have a problem with the cursor. It moves WAY out of the screen to the right and downwards. I've read something about a "clip cursor" fix but I can't seem to find out where and how to implement it.

Regards,
thefarside
--

== Manually Select Promotions ==

Just an Idea, not sure how easily done it is but I was thinking it would be really cool if (when its time for promotions) it would bring up a soldier screen with the eligible soldiers so that you could pick who gets promoted. Bonus if you could click on the candidates and be taken to their stats screen.

Love,
Dogfish

== Xusilak's Patch Additions ==

Since my patches are being integrated into the main release now, everyone should let me know if any issues are found with them. I'll try to get on fixing them as quickly as possible.

For clarity, the patches in the current build that I developed are:

* AutoSell
* Show Money

Thanks! --[[User:Xusilak|Xusilak]] 14:51, 24 March 2010 (EDT)

I went ahead and set up my own user page: [[User:Xusilak]]. If possible, direct discussion about my patches to my [[User_talk:Xusilak|discussion page]] there. Thanks again! --[[User:Xusilak|Xusilak]] 15:44, 24 March 2010 (EDT)

----

Hi Seb,
I've been working with IDA, your database, and your patcher's code for some time now, learning my way around it, and so on. So far, I've managed to come up with three UI improvement patches, although they still need some polish and testing.

The first one is a battlescape movement confirmation patch; it requires the user to click twice (double-click with no time limit) on the same tile to move, instead of once, to eliminate movement errors. In practice, I have found this very helpful.

The second one shrinks the geoscape clock and adds your current funds above it, letting you see your financial situation at a glance while waiting for time to pass.

The third one enables auto-selling of manufacturing items. Pressing the down arrow when the production quantity is at 0 engages this mode. When in this mode, production of that item never ceases (unless resources become unavailable), and the item is immediately sold upon completion.

Would you like me to make the code for these available once I've finished polishing them up? They currently consist of a few C functions accompanied by some InsertCall()s and Nop()s, as well as some additions to XCOM.h. I haven't added INI options to enable them, so I'd leave that up to you. You may use them as you wish, with no conditions.

Note: I'm still learning x86 assembly, so the patches may not be bug-free. I'm hoping to give them a good testing myself, though.
--[[User:Xusilak|Xusilak]] 16:10, 19 March 2010 (EDT)
:Glad to see you could make something out of this database :-) Do not hesitate to send me your modifications, I'll incorporate them in the codebase so others can enjoy them. I'm sure your autosell feature will make a few happy ones ;-) [[User:Seb76|Seb76]] 19:12, 19 March 2010 (EDT)
:::Yeah those features would all be '''great!''' Thanks Xusilak. [[User:Spike|Spike]] 15:08, 22 March 2010 (EDT)
::OK. I'm going to finish up my last touches on them, then test them for a while; they should be ready within a couple days. --[[User:Xusilak|Xusilak]] 21:59, 19 March 2010 (EDT)

== v1.21, Battlescape crashes ==

I enabled the new mods and they worked ok in Geoscape. Then this Popup box starting the first Battlescape:

Application failure
XCOM crashed at 0x10002571 with error 0xC0000005 trying to access 0x0968DF43

[[Media:UFOExtender1.21.BSCrash.zip]] contains the UFOExtender.ini file.
This was a New Game but not a new install of XCOM, just an overlay of updated UFOExtender.

*Win XP Pro 2002 SP2 32bit PAE
*Pentium-4 3.00GHz 3.5GB RAM

Any ideas? Need more info? [[User:Spike|Spike]] 20:20, 24 March 2010 (EDT)
:Does it happen consistently? I've been plagued by a random geoscape->battlescape transition crash in the collector's edition. It's one of the things I'm looking to fix at some point. The current UFOExtender doesn't appear to crash any more than previous ones do for me. I managed to do four missions in a row just now. --[[User:Xusilak|Xusilak]] 21:00, 24 March 2010 (EDT)

I'm doing some research into this; I started up in debugging mode and spammed missions until I hit a crash. The crash (on this occasion) is an access violation caused by an invalid pointer stored at 0x49B954 (the offset that pSoldierDat points to). This means *pSoldierDat is being changed at some point. It took many, many tries to get this crash to happen; I reloaded something like 20 times hitting the same mission, went ahead and did the mission quickly, proceeded, did another mission, proceeded, then the next mission crashed. Given that I'm in debug mode, it's not impossible this is due to the various hacks enabled by it, so that should be kept in mind. I'm going to continue working on this. --[[User:Xusilak|Xusilak]] 22:26, 24 March 2010 (EDT)
:It appears the "invalid" pointer is actually set by malloc() - 0x0771D380 (for me). I can only assume something along the way disrupted the data on the heap, as the pointer was the same when examined on a battlescape transition that didn't crash. Still researching. Note that for me, the crash itself happened inside GetSolderUUID() in the Save Equipment patch functions when it attempted to use that *pSoldierDat pointer. However, I assume it would still happen if the Save Equipment patch were disabled, just elsewhere. This is something I'll test as well. --[[User:Xusilak|Xusilak]] 23:41, 24 March 2010 (EDT)

::Sorry I'm guilty of reporting a bug I didn't (couldn't) repeat. But as I had no previous save game positions I couldn't repeat anything - the crash happened on the first Battlescape mission which for me is unusual, I would say that for me that transition crashes less than 1 in 100 times, if even that many. I had enabled Save Equipment I think and on instinct I would suspect that mod as being responsible. Those UFOExtender functions would run while setting up the Battlescape presumably. The equipment handling functions and structures ''already'' present in the game are known to be buggy. BladeFireLight and I just found another issue with them last week. Manipulating them is still risky. If you can investigate that would be very helpful.

::In the meantime I will see if I can try to repeat the fault, with and without Save Equipment enabled, and starting from a clean XCOM install. One trick I may use is to set No Score Game Over and then just abort from each mission rather than fighting it, to speed up the testing.

::Thanks for your good work Xusilak, it is appreciated! [[User:Spike|Spike]] 03:25, 25 March 2010 (EDT)

One possibility: On this mission I had only 6 soldiers (2 HWPs) but enough weapons in the Skyranger to equip 14 soldiers. Is there some known issue with needing to allocate '''all''' weapons to soldiers during the equip phase, in order to avoid a crash? If so that might be the cause. I will try to recreate those conditions and see if it provokes a crash. In case it's not clear, Battlescape never appeared to start, no Equip Phase screen ever came up. [[User:Spike|Spike]] 03:31, 25 March 2010 (EDT)
:Assuming the same crash is afflicting us, then the crash is when the very first soldier is accessed, when the Soldier.Dat data is first used for that mission. It's unlikely that volume of equipment is affecting that, and in particular, I hadn't changed my Skyranger's loadout to any degree whatsoever, having only briefly touched researching and manufacturing; it was otherwise a gamestate set entirely by doing one quick regular mission and one quick terror mission. However, I was also in debug mode, which enables certain cheats, like Alien Pets, automatically. This might, itself, have unseen bugs that could corrupt the data structures and cause a similar crash. When I get the time to, I'll be testing again with those cheats disabled, trying to further isolate the conditions involved. --[[User:Xusilak|Xusilak]] 08:34, 25 March 2010 (EDT)

I've repeated this multiple times now, with a clean install of XCOM and a clean install of UFOExtender 1.21. The game crashes everytime, after the "mission screen" that comes up just before the Equip Phase of Battlescape for the first mission. It's regardless of my equipment loadout or number of soldiers/tanks: it happens with totally default equipment and Skyranger load. So I imagine it must be due to some combination of the UFOExtender.ini file options I selected, and maybe code changes in 1.21. My .ini file is the upload at the top of this section. The error is always "error 0xC0000005 trying to access 0x0968DF43", though the crash location (in the code) varies. [[User:Spike|Spike]] 20:31, 25 March 2010 (EDT)
:If you have time, could you try to 1) confirm it's specific to 1.21 2) try to correlate it to ini options? Turn everything but the basics off and see what happens... if that works, turn on Save Equipment and try again, etc. I haven't seen any behavior like that in my local tests, on either of my computers (Win7-64 and XP-32). I'll try it with your ini, though. Maybe I can find something. --[[User:Xusilak|Xusilak]] 20:39, 25 March 2010 (EDT)
::Just tested with your ini, although with D3D and D3D window enabled. Started a mission, didn't crash. I also noticed one thing: you have General Stores capacity set to 1. I don't think that's helping anything, but it's probably not causing the crash, either. Experimenting more. --[[User:Xusilak|Xusilak]] 20:48, 25 March 2010 (EDT)

::: Save Equipment=1 is part (at least) of the problem. If I turn that off, and leave all my other .ini settings as is, I no longer get the Battlescape crash. Seb, did you make some changes there? Maybe after the investigations we were doing with BladeFireLight? [[User:Spike|Spike]] 21:13, 25 March 2010 (EDT)

I have isolated the problem (on my end) to the fact that the SOLDIER.DAT data in memory is deallocated when the transition to the Battlescape starts. When Seb's Save Equipment code attempts to use it, it's getting random unallocated (or unrelated) memory instead of the SOLDIER.DAT data. Interestingly, the dynamic memory used to hold the SOLDIER.DAT data is deallocated on the transition to the Battlescape, and reallocated to a new memory address on the transition out of the Battlescape. I assume this is an artifact of the way the Collector's Edition merged TACTICAL.EXE with GEOSCAPE.EXE, because TACTICAL.EXE had no need of SOLDIER.DAT, and only used UNITREF.DAT and similar. At any rate, this problem can be resolved by not relying on **(0x49B954) (or **pSoldierDat) to contain the correct data. Instead, a workaround to get the needed data should be used. One option would be to patch the way the transition works to prevent the deallocation from happening, and then ensuring on exiting the Battlescape that the old memory block is still used. I may be able to work in that fix myself. If so, it would require no changes to the Save Equipment code.
I'm not sure if this is a general issue or local to me only. I'll try to test on my XP system and see if it suffers from the same problem; if it does, it's a safe bet this is a general issue, and the likely cause of your crashes. --[[User:Xusilak|Xusilak]] 00:06, 26 March 2010 (EDT)

Save Equipment did used to work for me before. Maybe it's because I also selected Reorder Soldiers In Craft. Does that sort and rewrite SOLDIER.DAT? [[User:Spike|Spike]] 03:39, 26 March 2010 (EDT)

I have confirmed this behavior in the original X-COM Collector's Edition UFO Defense.exe copy, running on my XP system. As such, it ''cannot'' be a result of any patches Seb has made (because it still happens even when not using Seb's loader). I'm not sure if it will crash without Seb's patches still, but the way Seb uses the *pSoldierDat pointer in GetSoldierUUID() appears to be unsafe, as *pSoldierDat has already been deallocated at that point. On some systems, it may work, because the nature of memory on the heap is such that different systems give different results when dealing with deallocated memory and bad pointers. Regardless, the crashes can be at least partially (maybe entirely) resolved by using a workaround that avoids the deallocation of *pSoldierDat when the battlescape transition starts. I'm going to see if I can implement the fix I suggested, that prevents the memory from ever being deallocated. That should completely resolve it. At the least, I am going to study the assembly responsible for deallocating it to see if I can confirm the exact issue on the code level. --[[User:Xusilak|Xusilak]] 13:26, 26 March 2010 (EDT)
:It seems that when GotoGeographMode() returns to move into GotoTacticalMode(), it calls FreeEverything() in the process, deallocating all data structures. Then, GotoTacticalMode() never bothers to reinitialize *pSoldierDat, so when the equipment phase comes up, it's still unallocated. Still working on a fix. --[[User:Xusilak|Xusilak]] 14:29, 26 March 2010 (EDT)

::Surely at some point the (unmodified) game needs to at least read the *pSoldierDat structure, in order to populate the [[UNITREF.DAT]] and [[UNITPOS.DAT]] structures for Battlescape? Unless it reads SOLDIER.DAT but doesn't bother storing it, not even temporarily, in *pSoldierDat.[[User:Spike|Spike]] 15:27, 26 March 2010 (EDT)
:::Nice piece of analyse there :-). I'll modify the patch to load the soldier data when needed and clean up afterward. [[User:Seb76|Seb76]] 15:30, 26 March 2010 (EDT)
:::Edit: I uploaded a test version. Can you check if it fixes your crash? [[User:Seb76|Seb76]] 15:47, 26 March 2010 (EDT)
::::Looking good so far; Save Equipment works for me now, and it never has in the past. I'll run through a bunch of missions quickly and see if I get any crashes. Thanks Seb! --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:::No, thank you for figuring out the cause of the crash. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
:::::Just ran through several dozen (very quick, mostly aborted) missions all the way up to June. I never crashed, and Save Equipment always worked correctly. I think we're good to go. Hopefully it works for Spike as well. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)

I've also been narrowing in on another crash, unrelated to the patcher, I believe. It happens rarely upon clicking the air to move somewhere, like stepping out of the Skyranger by clicking the air one tile in front of the soldier, to move onto the ramp. It appears to be the result of a bad calculation on the tile to check in MoveUnitTo(). The calculation is looking at (char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize); // when esi is 2 or greater; this esi factor shouldn't be there, as far as I can tell, because it results in the offset used being much greater than it should be and frequently going out of bounds of the MAP.DAT data stored at *pMap. Continuing my research into this when I get a chance. --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:I noticed that crash also (I think it's the number one crash cause on a genuine XCOM setup) but was never able to reproduce enough to investigate it. I was tempted at one point to patch the GetTileAt function to check its arguments, but finding the cause of the corrupted value would be better. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
::Yes, it's definitely a hard crash to catch, because of how rare it is. I've got a few ideas, though. We'll see if they help. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)
:::Currently, my guess is that this line:
:::<pre>.text:00420534 BE 01 00 00 00 mov esi, 1</pre>
:::should be "mov esi, 0" instead.
:::To sum up the issue:
:::The way the 'click on air to move to a tile below unit' part of MoveUnitTo() works is that it examines each level below the unit until it finds a floor to move to. It does this by looping through the level below you, incrementing esi to loop through the next level below that, and so on. To do this correctly, esi should start at 1. However, the X-COM programmers appear to have made an oversight: they initialized esi to 1, but then incremented esi again before the initial value actually gets used. The net result of this, is that we get zpos += 2 for the very first cycle. This works OK on floors 3 and 4, but for floor 2, it will attempt to access a z level that doesn't exist (one below the ground), causing this line: <pre>(char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize);</pre> to exceed the bounds of the *pMap memory block. Obviously, running off the end of that block will cause unpredictable results, and if it reaches into a block that isn't allocated, it will crash. That's why the actual crash is very rare: it has to overrun into an unallocated memory block.
:::Of course, I could be completely wrong, but it makes sense, and patching 'mov esi, 1' to 'mov esi, 0' doesn't seem to cause any problems. I'm going to be testing with that patch enabled from now on, to see if I crash in that circumstance anymore.
::Looks like you are right. I instrumented the code and there are indeed systematic out of bound accesses when getting out of the craft, though the game does not crash every time. I suspect this is the same crash that happens during base defence when an alien tries to move down from the access lift. Kudos for figuring all this out! I'll provide the fix in the next version. [[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)
:::By the way, Seb, the 1.21 source code doesn't include autosell.cpp; I assume it's a simple oversight. I reconstructed it to get it compiling properly. Just wanted to make sure you knew. --[[User:Xusilak|Xusilak]] 20:37, 26 March 2010 (EDT)
::Oops, forgot to check the unversioned files before checking in...[[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)

== Minor cosmetic enhancements? ==

Had these ideas come to mind while I was at work today, and since your loader is doing some amazing things for the game, I thought I'd ask if the possibility of any of these enhancements exist.

The short of it is: Are you able to overlay any additional bitmap surface on top of the battlescape view, and are you able to play additional sounds?

The main idea for drawing an extra bitmap (semi-transparent) over them map would be to simulate rain/snow for some outdoor maps. Lightning even - though that would require clever use darkening and lightening the overlay. This would have some issues attached to it such as knowing when to display it and when not to, thanks to the various other screens available.

As for playing sounds, which would be simpler, would be to play a looping sound clip to provide environmental sound effects, such as insects chirping and owls hooting at night in woodland maps or town noises at terror sites. Or during the day in a jungle map, some tropical bird calls made at random intervals. TFTD already does the looping environmental sounds, such as teh under water bubbly noises or the wind and sea noises when on land mission. Would it be possible to duplicate this for UFO CE?

Not the most important of enhancements, but I was still wondering if the possibility is there.

-[[User:NKF|NKF]] 01:41, 25 March 2010 (EDT)

== Save/Load shortcuts ==

Seb, would it be possible to enable shortcuts for the Save/Load in geospace & tactical (like F2 or F3) ? ;) except for saving in the final battle (from level 4 if remember) :)

Other things:
- rosvell incidents occured for me too often - 5 in the first month while there was no other alien craft movement detections

- option to disable mission briefing window with the only ok button :) supposedly for advanced users ;)

== Aliens continue using pistols&rifles ==

Hi Seb, sorry to bother you - i have been playing X-COM titles on and off for about 10-15 years now, and one thing always bothered me: Why do the aliens always swith to heavy plasma (or the Sonic cannon in case of TFTD) later on? It encourages the player to swith to heavy plasma too, if only for the free ammunition you almost drown in later on. Would it be possible to have the aliens continue using the plasma pistol&rifle after june/july? It would make using those weapons more feasible, getting ammunition during missions and not having to use elerium to produce it.

Another request (don't know if it is possible) - let the aliens continue using the abductor and the harvester for the respective missions. Later on, all you get are large scouts or even battleships doing those missions - getting some variety in there would make the endgame more interesting. You get to do 50+ battleship missions in a game, but only 4 or 5 with a harester/abductor. Those ships should see a lot more use during the missions they are "designed" for. The "[[MISSIONS.DAT]]" page says something about ufo and mission counters and their associated ufo-types - would it possible to modify those entries via the loader?

Regards, Equinox

== ALIEN MISSION DATA CLARIFICATION ==

According to
[http://ufopaedia.org/index.php?title=Talk:MISSIONS.DAT#Alien_missions_data_discovered_in_geoscape.exe_.5Bfinally_.3B-.29.5D link title]

I found it in TFTD. At offset 505448 (decimal) is starting (mission Probe). Next Interdicition/resource raid/infiltration/colony expansion/surface attack/Floating base attack

I understood what is 3-rd word. If You interesting - I can exlain

Seeing speeds of USO sub we can determine the mission of this USO sub even without transmission resolver - even in january 2040
Every USO sub in every missions (interdiction, colony, probe and other) have unique speeds and we can determine mission of USO on their speed
And we can determine what amount of times a sub touch down on his mission - because every mission has unique rule for touch down USO subs
And we can determine what amount of time USO Sub will touch down on their mission - because every Sub in every mission has unique and ALWAYS equal amoun of time to touch down (p.s. this time we can see in file Loc.dat)
Here - I attached file speeds.zip
[http://www.strategycore.co.uk/forums/Ion-Beam-Accelerator-in-What-file-t8099.html&view=findpost&p=95994#entry95994 link title]

3-rd word - it is reference to unique speed of each sub

4-th word - is time that precede to arrive next uso sub. In other word, in line ufo/c 0/0 if time = for example = 200 - it's time to arrive sub that indexes 1/0.
And where can I get time to arrive EXACTLY sub 0/0 is incomprehensible for me. I assume that this time contain at similarly word of last uso for this mission - but its'not truth because at some missions time in the line of last ufo/c = 2 half-hours and it's means that ufo/c 0/0 can to arrive at new month at 2 half-hours. It's true for Surface attack Mission but not truth for other missions.
I assumed that time in line ufo/c 0/0 - that time to arrive for NOT next ufo - and I assumed that it's time to arrive exactly ufo/c 0/0 itself. But many my tests (more than 100) denies my suppositions.
In example, at line ufo/c Cruiser mission Colony Expansion time in file =2. Cruiser in that mission arriving much more than 2 half-hours after Escort. Instead Fleet supply Cruiser in that mission arriving after 2 half-hours exactly after Cruiser.

'''Question - Where can I find time to arriving for ufo/c 0/0 for each missions except Surface attack mission ?'''

I am sorry for disturbance and will great thank for you for help.
:After the first month the game creates a mission per month, up to the 6th where it generates 2. I guess a mission starts immediatly, there is no timing added for its first ship. [[User:Seb76|Seb76]] 15:18, 30 April 2010 (EDT)

Mission starts not immediately. often time to arrive to survey ship (first sub) about 10-15 days.
1-st day of month at 0-00 we can see it time at Missions.dat but wants to know average time similarly such average time for other subs from alien data mission at executable if possible.

What is exactly 6-th? mission from Probe to Colony Expansion? or from January to June?
:Yep, 6th month. [[User:Seb76|Seb76]] 20:04, 30 April 2010 (EDT)

what happens after 6-th month June?

I so sorry for reminder and bother you, but don't you know it? ((

== Formules about Retaliation/Floating base attack mission ==

Hi

My great respect to you for you formules
I need few help. I am great thank to you in advance

Now I found alien data missions in TFTD (in a similar in EU ) and I ask generously to you to check 3 your formules in TFTD. Is these same or not?

1. After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours
:Xusilak is more knowledgeable than I concerning TFTD. I cannot help you here... [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

Formule 2 and 3 probably contins mistake. formule 'll have to have symbol > instead symbol <. Otherwise retaliation mission activates more often on Beginner diificulty than Superhuman difficulty. Is is strange.

2. A retaliation mission will be scheduled if RAND()*100 < 4*(24-difficultyLevel).
:There is indeed a mistake there. It's been so long I cannot remember if I got it wrong or just messed it up wikifying it ^^ [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

3. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from. The first UFO is scheduled in 100 half-hours (the value is taken from the table I speak of later at the bottom of this page).

And RND() - what values may has? from 0 to 1 or not?
:When I write RAND()*100, it just means a random number between 0 and 100. [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

I will be very thank for given help

== MISSIONS.DAT formula clarification ==

Hi Seb76. I've been having a discussion with Alexchamp and trying to interpret the formula you mentioned on [[Talk:MISSIONS.DAT]] about retaliation missions being scheduled after a shoot down. Namely: if RAND()*100 < 4*24-difficultyLevel

We mainly need clarification on the logical operator. Should it be less-than or greater-than?

As it reads now, it could be interpreted as though retaliation missions are generated more frequently on the easier levels. But if we treat it as >, then this means that retaliation missions are generated about (Beginner) 4%, 8%, 12%, 16% and (Superhuman) 20% (or 28% for TFTD) of the time on their respect difficulty levels.

If you could clarify that for us it would be great, thanks. - [[User:NKF|NKF]]
:Yep, I goofed up. Don't take everything I say as gold ;-) [[User:Seb76|Seb76]] 14:45, 30 April 2010 (EDT)

And I precise too one '''mainly moment'''. Whether there must be the opened bracket after the sign of multiplication? Because if no, then right interpretation formule in Superhuman example such: Rand*100>4*24=96-6=90 and that means that retaliation mission would be sheduled in 10 cases from 100.
IF there must be opened bracket then rand*100>4*(24-6)=4*18=72 wouid be sheduled in 28 cases from 100
What is this versions is right?

Then needs clarification for second formula yours. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from.
What logical operator there? should it be too greater-than or less-than?

You have found later formules about activation retaliation mission (if we shotdown alien craft)
Where exactly in assembler is subprogram that determines it? What address/offset of it?

== COLONY SUPPLY MISSION ==

As we know, When alien base built, Fleet Supply Cruisers with missions Colony Supply can to arrive to this base.

Where can I see (file/offset)
1) average time to arrive colony supply ship for examle/at least in XCOM-EU. As I said later, in responsible offset is time '''to PRECEDE to ARRIVE NEXT UFO SUB''' '''it's not''' time to arrive this sub
2) real time to wait arriving colony supply ship similarly times in file Missions.dat

According to [http://www.strategycore.co.uk/forums/Colony-Supply-ship-time-to-arrivin-t8103.html&view=findpost&p=96011#entry96011 Colony Supply - time to arriving]

If guesses of NKF is right, we need to formule of probability to arrive Colony Supply ship.
Can you to render courtesy with this formule?

Thank you very very great in advance
:I added details in the LOC.DAT talk page. The supply ship is spawned randomly and starts its mission. There is no "time to first supply ship" that I can see. [[User:Seb76|Seb76]] 15:11, 30 April 2010 (EDT)

Thank tou very much for this clarification. I found this offset in TFTD even. Changed, checked - it works.
You are greatly people!

== Roswell mission bug? ==
Hello, Seb76.

I've just had two consecutive games (meaning, I restarted the application and began a new game) where the same strange behavior occurred.

Both games had Roosevelt mission as the first one. It showed the window (type, terrain, UFO size) as usual. Afterward, whenever I clicked on it (to check mission conditions again), it showed a typical "hyperwave transmission decoded" window, stating race/mission type, etc. Needless to say, I had no decoder at this time, since it happened both times in the first game week.

I have a saved game if you want to take a look at it. It's completely reproducible, at least for me. You just click on the white cross and get this window.

Also, I'm using plain CE version with a "complete UFO patch" from StrategyCore. The saved game was not hacked in any way.

Cheers!
[[User:Rovlad|Rovlad]] 10:08, 30 April 2010 (EDT)
:Hum, I gave it some shots but could not reproduce your problem. Anyone experiencing the same problem? [[User:Seb76|Seb76]] 15:36, 30 April 2010 (EDT)

::Here's the [http://rovlad.nm.ru/GAME_1.zip savegame]. Let me know if it works fine for you. [[User:Rovlad|Rovlad]] 21:47, 30 April 2010 (EDT)
:Looks like the CRAFT.DAT entry is not cleared when a new craft is created and the offset 0x64 could be garbage till the craft is detected by a base/another ship. Since I bypass the detection when "crashing" a UFO, it is possible the "HWD detected" flag is set randomly, producing a full report. I'll clear the bit and we'll see if it corrects the issue, just wait for the next release. Thanks for providing the savegame BTW. [[User:Seb76|Seb76]] 14:22, 5 May 2010 (EDT)
::You're more than welcome. Fantastic job on the extender, keep up the good work. [[User:Rovlad|Rovlad]] 19:04, 5 May 2010 (EDT)

== ALIEN RACE SPAWN ==

Your post: In EU, the race is based off a lookup table starting at offset 0x46E53C (containing 300 entries).

Offset-0x46E53C is absent. Is one symbol odd?

Your posr:The table is made up of 10 entries lines.

It means that this bit of array has 10 rows width of 30 bytes. is right?

What is means this 10 entries lines? Can you copy 2-3 lines from exe and explain that means known for you offsets in line?As simiilarly as you done for alien data mission in file Missions.dat
Can you get more particularly answer about values it this array?(naturally if know it)
:0x46E53C is the address in memory. In the file it should be 0x6E53C (UFO Gold edition).
:The begining starts like this:
.data:0046E53C byte_46E53C db 0, 0, 0, 0, 0, 0, 0, 1, 4, 4 ; 0
.data:0046E53C ; DATA XREF: CreateAlienMission+15B�r
.data:0046E546 db 0, 0, 0, 0, 0, 1, 1, 4, 4, 4 ; 0
.data:0046E550 db 0, 0, 0, 0, 0, 0, 4, 4, 4, 4 ; 0
.data:0046E55A db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E564 db 0, 0, 0, 1, 1, 4, 4, 4, 4, 4 ; 0
.data:0046E56E RaceForTerrorMission db 0, 0, 0, 4, 4, 4, 4, 4, 4, 4 ; 0
.data:0046E56E ; DATA XREF: GeoPerformMonthlyActions+15E�r
.data:0046E578 db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E582 db 0, 0, 0, 0, 0, 0, 1, 4, 4, 4 ; 0
:till the end:
.data:0046E67C db 0, 1, 1, 2, 2, 2, 3, 3, 2, 4 ; 0
.data:0046E686 db 0, 0, 1, 1, 1, 2, 2, 3, 3, 4 ; 0
.data:0046E690 db 0, 1, 2, 2, 2, 2, 3, 3, 4, 4 ; 0
:As you can see, at the begining you'll get tons of sectoids (0), a few floaters (4) and even less snakemen (1).
:At the end, you'll get ethereals (2) one time out of two. Also note that for terror missions, the line is taken a bit farther than normal missions, which means that you'll get stronger aliens sooner in terror missions. HTH, [[User:Seb76|Seb76]] 13:36, 5 May 2010 (EDT)

Thank you greatly for your detailed answer ...
I want a few more precise ...
I right understand? I guessed That line 1 - is used for January mission Research? Line 2 - Jan Harvest? Line 3- Jan-Abduction Line 6- January Terror?
What define Line 7?
Line 8 - is February Research?

According to - Line 13 -Feb terror? Line 20 - March terror? Line 27 -April Terror? Line 34- May terror? that sequence and guesses is right?

And question 2) does affect score to choose the value among values in line? How differ choose values in line at the level superhuman and level beginner ?
If you know, naturally, I would be greatly thanks to you for this wonderful magic help.

== Research tree in executable ==

Do you know location (starting offset) of research tree in EU? and how much entries it contains ? and what means values within this array?

Very great thank in advance for this help to you
:The research tree is not stored as a data array but is a hardcoded sequence of "if this is already researched and that is also researched and such item is in the inventory, then enable this research". Modding this would require a complete reengineering, not just patching. Still feasible though. [[User:Seb76|Seb76]] 13:25, 5 May 2010 (EDT)

What is starting offset (ce version) of this hardcoded sequence? and what is latest offset of it? what is length of one sequence? If possible -what is structure of it briefly? (how much bytes to tech requirements, how much bytes to items requrements)

Thank you for this help '''VERY VERY GREAT'''
:As I said, there are no *sequences* but just a cascade of hardcoded ifs:
:[[Image:Research.png]]
:If you want to take a look, the function begins at address 0x446A0. [[User:Seb76|Seb76]] 07:28, 24 May 2010 (EDT)
'''
Seb76, you are GREAT GENIUS!!!! GREATLY RESPECT FOR YOU!!! THANKS FOR YOU VERY VERY MUCH!!!'''
I have found research tree in TFTD too with your help. Now I can do some changes in it.
Maybe do you know, how can I find subprogram that run 1-st day of any month in assembler code of game?
This subprogram determines new mission's month and terror ship route (in TFTD)
There is not in EU terror ship route, I know. But If you know and tell me - what is subprogram in EU that runs 1-st day of any month, I would be able to edit probability of terror ship route in TFTD.
Greatly thanks in advance to you dear Seb76!
:In EU, monthly actions start here:
.text:0043B9B0 GeoPerformMonthlyActions proc near ; CODE XREF: GeoIncrementDayAndDoMonthlyActions:loc_4420C1�j
:HTH, [[User:Seb76|Seb76]] 16:31, 28 May 2010 (EDT)

== Any way to slow down geoscape time? ==

Is there any way to slow down geoscape time progression on fast computers, esp. multiprocessor ones, where it is impossible to significantly slow it down using utilites like MoSlo and Turbo?--[[User:AVE|AVE]] 03:01, 5 May 2010 (EDT)
:Did you try enabling D3D? If you're drivers are configured to wait VSync, it should limit the game speed (well, if you use a CRT@120Hz it'll still be too fast I guess...). Also is it still too fast if you put it windowed? (enabling both D3D and D3D Windowed options) [[User:Seb76|Seb76]] 13:19, 5 May 2010 (EDT)
::Yes, both D3D and D3D Windowed are enabled. This is even more surprising, because it shows the same results on two different computers (Dual Core one and simple P4Celeron) with different video cards (NVidia and ATI). Both have vsync explicitly enabled. LCD@60Hz both. Also I've tried to use different combinations of Video Pitch, D3D, D3DWin and HQ4x settings - no luck. [[User:AVE|AVE]] 04:20, 6 May 2010 (EDT)
:Personally I've never been able to reproduce this "CE game running too fast" thing people keep harping on about. Perhaps I just have a different perception as to what "too fast" means.

:Anyways, I know [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's patched executable] includes a timer hack for the Geoscape, but I found that makes it run far too slow for my taste. Not sure off the top of my head whether it works with Seb's loader, either - you'd probably need to at the very least need to rename Mok's executable to replace the original in order to try it that way. - [[User:Bomb Bloke|Bomb Bloke]] 05:14, 6 May 2010 (EDT)

== Some problem with edit research tree ==

I want to add new 20-30 commands to research tree. I wrote this subprogram. How can I add it to game?
I tried to write "call sub" instead useless 5 bytes in subrogram research tree. I checked in IDA after it, all other commands is preserved.
And I placed my new subprogram after latest byte of executable file. But game is crashed.
I tried to place my new subprogram after all subprograms and before first byte of idata, but game is crashed too.
All indexes in subprogram was exactly.
in second case IDA displayed "sp-analysis failed".

Where and how can I placed my new subprogram that will be addition to current subpogram research tree?
:To add new code, you need to modify the PE header of the exe file accordingly. I'm not quite knowledgeable regarding the procedure (that's one of the reasons why I made a loader instead of patching the file directly) so you're gonna have to find help somewhere else on this one. [[User:Seb76|Seb76]] 16:36, 28 May 2010 (EDT)

== Update to IDA database ==

Hey again Seb76 :)

After a long time I've come back to your extender, dusted off my copy of VC Express, and decided I'd have another go at doing some UFO modding (don't ask how the first attempt went; it's not pretty! :p )

I'm assuming you've probably updated the IDA database since last time I asked. Would be extremely grateful if I could get the latest version.

Thanks for all the hard work, staring at assembly code all day is no joke! --[[User:K9wazere|K9wazere]] 18:07, 6 June 2010 (EDT)

Arf, didn't realise I could send you an email, so this new section on your talk page is a bit redundant now :p Oh well, maybe someone else will want the file too!

== Line of Sight Origin Points ==

Hiya.

A while back you mentioned the co-ords for the [[User talk:Bomb Bloke:Firing Accuracy#Firing Point Origin|firing point origin]]. The zpos is calculated according to the unit's effective height, and the x/ypos co-ords come from look-up tables depending on which way the unit is facing.

I was wondering, are these same two tables used for the purpose of line of ''sight?'' And by any chance could you find the formula for the initial LOS zpos?

Any help would be appreciated, as usual. There are many other obvious questions around this issue (such as where the ''end'' point for these lines is), though the origin would be a good start. - [[User:Bomb Bloke|Bomb Bloke]] 07:44, 24 June 2010 (EDT)

== Training Stat Request ==

Hi there.

In the Equipment screen where the Weight and TUs are displayed during battle, would it be possible to also include the current unit's number of Reaction shots, Hits, Psi attempts and (possibly) Throws? Possibly along the bottom in a horizontal string where there's room?

User talk:Seb76

2011-03-28T00:15:32Z

Mannon: /* UFOloader and Xcomutil */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

My problem is the following: if I try to run the loader normally, a console window pops up for a few seconds then I get an "illegal instruction" error from NTVDM (and the window disappears, yet it's button remains on the taskbar until I kill the process). If I try to run it with DosBox however, I get "illegal command: UFOLOADER.EXE". Point is, I can't run this at all.--[[User:Amitakartok|amitakartok]] 11:27, 13 October 2009 (EDT)
:Looks like you're trying to use the DOS version here. Only the CE (windows) version is supported. [[User:Seb76|Seb76]] 13:48, 13 October 2009 (EDT)

Hi, is it in any way possilbe to run the Extender in Win98? I just set up an old machine with it and wanted to give it a try but as you said above, it won't work with Win9x. But is there a way to manually mod the game? I am asking becaus on my WinXP Machine the game often crahes in battlescape and that really sucks =(--[[User:Skaw847|Skaw847]] 19:28, 21 May 2010 (EDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)
:::I for one am a huge fan of XcomUtil, though I'm now also a huge fan of UFO Extender! I'm really hoping I can get the two to play nice. I was up until now playing a dos version, myself. Mainly because the version I bought years and years ago was the DOS version on CD and it still worked via dosbox, which also has several filters similar to your HQ4x. (Some run a little faster and I think they can run in a window while I can't get HQ4x to run windowed at all. I don't mind that so much, though the game runs noticeably slower when I run HQ4x and I prefer to run windowed these days so I can more easily multitask. Still I LOVE UFO Extender so I switched to the Windows version just for this.) Some of XcomUtil's features only work in the DOS version with split exe's because it goes back into the batch file and allows XcomUtil to play with things when switching from Geoscape to Battlescape and vice versa. But, it's not that big a deal for me. UFO Loader's feature list is more than robust enough to give that up. As for the sounds the Windows CE versions changed a lot of the sound effects. If you're used to this version then it's Np, but if you played the DOS version and got used to it then it's VERY off putting. Luckily it's easy to patch it back to the DOS sound effects. The "Enemy Unknown Extended" page here lays out an install that includes UFO Extender, the original DOS sounds, ect... It's a good place to start. Anyway, great tool. Now let's see if I can get these to play nice.[[User:Mannon|Mannon]] 04:40, 27 March 2011 (EDT) (I keep forgetting to sign things... too used to forums instead of discussion pages.)
::::Facinatingly XcomUtil actually DOES split the CE's executable into geoscape.exe and tactical.exe! It uses it's own sdump utility to do this during the setup batch file. I misread the above. XcomUtil splits them to preserve it's fuctionality so that it can use the batch file to knit them together like in the original DOS version and insert it's own exe into the mix. This does not make the windows exe run in DOS of course, but it does allow XcomUtil to keep it's functionality. I have to assume it really screws up UFO Extender, though... ;-(

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Could we get TUs (in current/max format) at the inventory screen while on a mission? It would greatly help with swapping weapons among soldiers.

* Could we get little numbers [like on the screenshot of accuracy mod] showing how much TUs an action on the inventory screen would take? Some players (me, of course, included) can't really remember all that reloading from backpack or from a leg slot TUs. Also...

* a "drop all" button, maybe?

* Soldiers' positioning in Skyranger is very good... but with the Avenger it is not so pretty. The ones at the top are not the ones closest to the trap door. Chooseable patterns, maybe?

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.
: '''Save Equipment''' is under development, still some bugs

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
** Eliminate "infinite fuel" exploit for conventional aircraft.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

* Enable native alien melee attacks within Alien Pets. The Floaters are pleading. (At the moment, Alien Pets+Big Brother means a crashed Superhuman Floater Large Scout costs 6-8 X-COM agents; corresponding crashed Sectoid Superhuman Large Scout is only worth 3-5 X-COM agents. Floater Large Terror Ship on just Big Brother : only one agent, and that was due to the top-of-stair pinning bug providing enough TU to do something.) -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Do something to help out the psi aliens as well within Alien Pets, as above. -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Would it be possible to change the master volume level in the game, or at least have a no sound option? [[User:Epiceuropean|Epiceuropean]] 00:26, 12 January 2010 (EST)

=== A few more ===

Do any of these take your fancy:

* Draw the Radar detection radii onto the map as a circle(s) around the base (also for moving aircraft?)

* Show All UFOs (Ultrawave Detector - like Show All Locations, but doesn't show Alien Bases, you still have to hunt for those).

* Sensible Ammo Recovery = add up all remaining rounds of ammunition at the end of a mission (in the ship, if Aborting), and recover a number of (full) clips equal to that number divided by the clip capacity (rounded down maybe).
: There's a reason I didn't turn Clip Recovery on, and it's that I guessed that it didn't work exactly as it's suggested here. If it did work like this, I would use it. [[User:Stubbs|Stubbs]]

* Implement tactical time limits for UFO Assaults/Recoveries. After a random period (within a pre-defined upper and lower time limit), the aliens leave. Pop up warnings appear at the end of each turn, saying the UFO engines are powering up. When the aliens leave, all aliens/items/equipment inside the UFO is gone - no loot, no score. Any soldiers still inside the UFO are considered MIA. The soldiers are ''captured'' in fact - score penalty worse than MIA? There must be one conscious alien inside the UFO for it to leave or attempt to leave. Maybe any live aliens outside are 'beamed' or 'tractored' inside the UFO, complete with their equipment? (E.g. the mission ends and you don't get score for them or their equipment either - just for the corpses and dropped loot).

* No Milk Please: After XCom withdraws from an Alien Base, randomise the base's location and make it hidden again. Just like what happens to the aliens after they fail to assault an X-Com base. Though you would probably still need to locate it within the same country or region so finding it again wouldn't take long I guess. Would it mess things up to move the base to a random part of the world?

* [[User:Spike#Tank mods|Tank Armour and Equipment Mods]]

But I should probably code this up myself, looking at your source code it doesn't look '''too''' hard. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

[[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

* Burning Zombies

It's more or less impossible to prevent Zombies from hatching into Chryssalids by killing the Zombies with fire, since fire does such a small amount of damage, and the requirement is that the actual killing point of damage is done by an incendiary. Apart from hitting them with an incendiary and running away, then waiting about ten turns for them to die (probably repeating the attack once or twice), this is only ever going to happen by blind luck.

It would be much more viable if the rule was (also?) that a Zombie which is '''on fire''' at the time of death would not hatch into a Chryssalid. This is not exactly easy either, but it is at least possible. It requires hitting the Zombie repeatedly with incendiary weapons until it catches on fire, then killing it right away with regular weapons (before the fire goes out).

A much easier version of this approach would be to say that if the Zombie is killed while it is '''in fire''', it does not hatch. But that is probably too easy.

A way to do this by hacking game files, without code changes, would be to increase the Zombie susceptibility to fire, to 200%. This would make incendiary weapons a viable way of killing them, as well as increasing the likelihood that the killing shot was an incendiary shot.

An alternative approach would be for the Zombie to have a chance of not turning into a Chryssalid, proportional to the percentage of health damage that had been caused by incendiaries. But that's probably too hard to track, it would require an extra/unused field in UNITREF.DAT.

[[User:Spike|Spike]] 13:12, 7 September 2009 (EDT)

* Fear of Fire

Apparently there is no morale effect from [[Incendiary#Damage|Incendiary damage]]. If anything, for humans, and maybe be for other humanoid aliens, fire should probably have a greater morale effect than ordinary damage, not none. A basic fix would treat fire damage the same as normal damage when reducing morale. A more complicated fix could add a weighting to this morale effect: multiply by the creatures susceptibility to fire (or reduce by its resistance to fire). Any creature or soldier that is immune to fire should not have its morale affected. Actually the affects of fire vary quite a lot (different aliens, different human armour types). Maybe this is why the designers didn't get around to implementing morale effects for fire, as it's a bit complicated.

[[User:Spike|Spike]] 13:40, 7 September 2009 (EDT)

=== Multi Stage Missions ===

Between each stage of a multi-stage mission:

* Send all artefacts (non-usable items), corpses and recoverables back to base
* If possible, remember the score for these items, and apply it to the score at the end of the mission
* Alternatively, pop up a score window between the mission stages, and apply the score then?
* Gather all loose usable equipment into the "equipment pile" for the next stage
* Or possibly re-run the Equip Screen between mission stages, again gathering all loose usable items into the equipment pile first.
* Keep an 80 item limit on what you can take into the next stage
* Prune down to the 80 item limit using some sensible rules, not sure what exactly.

This is of limited use in X-Com EU but would be much more use for TFTD, one day. EU has only one multi stage mission, and it ends the game, so only some of these points above will be relevant.

[[User:Spike|Spike]] 20:54, 2 September 2009 (EDT)

=== Even More ===

Tremendous work, you've pretty much made the game worth playing again. Best work since Xcomutil. As with everone else, I have a few requests. [[User:KingMob4313|KingMob4313]] 23:59, 12 August 2009 (EDT)

: Ability to change damage modifier. Right now the damage runs from 0-200% of damage values on the weapon. I'd love to see a way to change it to 50-150%, 75-125% or the like.

: A modifier to increase or decrease the explosion radius modifier. Right now the radius is either keyed to the explosive or to the explosive damage. I'll investigate it further. But it would be nice to have a very small radius, but high powered explosive for use as a breaching charge.
:: There is a "crimping" function on some of the explosions already so it might be possible to exploit that. Check the [[Explosions]] page. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

: A modification of the range based accuracy. One handed weapons have a shorter range, to the point that even their aimed shots have an effective range, two handed weapons have a further range (and no aimed shot effective range) and really heavy two handed weapons have an even further range.

: Ability to enable the Burst fire (5 shots over 3 picked spots) and/or the full auto mod that is on the heavy laser on other weapons (set by a flag).

: A modification so that on the alien's side first turn, they do not have their full time units in reserve for reaction fire. Nothing like getting shot 3 times from the same sectiod after missing ONE shot on them.

:: You could always wait a turn before you open the door. :) [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

::: Good point, I should be doing that anyways.

=== More Exploits to Close ===

* [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]

Probably the worst single exploit in the game. What is needed is to disable any mind control actions for a Psi Amp, if the unit holding the Psi Amp is currently mind controlled.

Also a general mind control bug/exploit fix for:

* [[Exploiting Mind Control#Exponential Mind Control|Civilian Traitors]]
* [[Exploiting Mind Control#Exponential Mind Control|Resurrect Zombified Agents]]
* [[Exploiting Mind Control#Exponential Mind Control|Zombie's Permanent Control of Aliens via Stunning]]
: Above 3 bugs are fixed by '''Hostile Civilians''' fix.

* Probably many other missing/MIA-type bugs

These probably all arise from the daft decision to save a single byte (or even bit), by not recording separately the current vs default "side" a unit is on. The game only tracks the "current side". Consequently when mind control ends, the game often makes dumb decisions as to what side to "restore" the unit to. We could use an unused byte to track the default "side", but that would require overloading a presumed "unused" field and that could be risky. But actually we can always deduce the "default side" from the unit type: XCom for soldiers and tanks, Neutral for Civilians, Alien for everything else. So what is needed is just an end-of-turn check to restore everything to its correct side, based on its unit type. Actually it's slightly complicated by alternating turns. You need to update all (originally) Alien units at the end of the Alien turn, all originally XCom units at the end of the XCom turn. You might also need a special end-of-game update, to avoid the MIA-type bugs. [[User:Spike|Spike]] 12:22, 26 August 2009 (EDT)

: AlienSWP.py implements turnswapping via mind control, like XCOMUtil. Handling the alternating turns, as you described, is necessary to make mind control work properly (a mind-controlled alien remains with X-COM during the alien turn, and so on).

: I would assume that the original programming team had a coding policy forbidding both bitfields, and emulating them with bitwise shifts. That's really the only way I can explain most of the idiosyncrasies of the file format. [[User:Zaimoni|Zaimoni]] 12:07, 26 August 2009 (CDT)

=== Soldier Colouration ===

Not the most "practical" request in terms of changes to gameplay, but still something I feel would be pretty cool if incorporated. Basically, the option to have the battlescape engine display soldiers according to their race/hair colour, as according to their inventory screens, [http://www.strategycore.co.uk/forums/post-a1669-.html like this].

The stored tactical [[PALETTES.DAT|palette]] is made up of 16 groups of 16 colours (256 total), in this order (though the last 16 colours are replaced with a grey-scale shade list at run-time, similar to the other fifteen groups - refer to the page on palette data for more info on that):

[[image:5_BattleScapePal.Png|center|frame]]

Solders are drawn using colours from three of these groups: One for their clothing (x50-x5F for overalls/power armor, xE0-xEF for personal armor), one for their skin (x60-x6F), and one for their hair (x90-x9F). Flying suits use a few extra colours, but they don't matter for the sake of this explanation (they don't show hair/skin anyways).

With my [http://www.strategycore.co.uk/files/index.php?dlid=686 battlescape editor] I incorporated a feature where you could have the program redraw units on the fly (as per the screen shot), changing just the hair/skin colour. For example, to check to see if a colour index was supposed to represent hair, it simply checks if "(''value'' & xF0) == x90", and if so, it'd add or subtract a certain figure to achieve the desired colour.

Well, there's a bit more to it then that (males in personal armor have a different hair colour already), but I'm sure the basic concept is obvious to you by this point. If you're interested, you can see a sample function in a file included in my toolkit - "bb_tact\UnitDrawer.java", line 384. It's not exactly well documented, but if you check the hair/skin arrays it refers to, it should be fairly obvious what it does. While the program is running, the "characteristics" variable is set to "true" by tapping C on your keyboard. Of course, I've no idea how the actual game deals with drawing soldiers, but I assume it decompresses every [[Image_Formats#PCK|PCK]] image every time it wants to draw it, same as my code does.

- [[User:Bomb Bloke|Bomb Bloke]] 09:46, 4 May 2010 (EDT)

=== See Also ===

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

== Completed Items - Thanks Seb! ==

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

* More video options. In particular, an option to put padding at the top and the bottom of the screen to preserve the aspect ratio on a 4:3 monitor. Maybe it's just me, but stretching the original height of the game to fit a 4:3 screen makes the Battlescape look weird. (Actually, if you update the source code link, I could try to do it myself. The current source doesn't seem to include your more recent changes. --[[User:Mikawo|Mikawo]] 20:30, 12 August 2009 (EDT))
** Thanks for uploading the new source code. I managed to add the letterboxing that I wanted. If you wanted to make it an official feature I could upload the updated files. And I don't think I said this before, but thanks for the great loader! --[[User:Mikawo|Mikawo]] 18:40, 14 August 2009 (EDT)
:Go ahead and upload/PM me the file (d3d.cpp I presume?), I'll gladly incorporate your modification. [[User:Seb76|Seb76]] 19:14, 14 August 2009 (EDT)

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

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

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

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

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

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

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."
:The above works perfectly. [[User:KingMob4313|KingMob4313]] 00:05, 13 August 2009 (EDT)

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.
:Fixed via Keyboard Shortcuts - and configurable too.
-- Sorry, I am having trouble finding this addition. Is it in the newest version? I can't see where to configure it if so.

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....
Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)
:I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that 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?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human 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?

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).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
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!
:I think this is a known issue with LOS, not sure though
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).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

There are major issues with your current weight calculations. I'm not exactly sure how it was occurring, but repeatedly messing around unloading and loading weapons, switching clips from the ground them putting them back in... at least one of these functions causes 'phantom weight' to be added to the soldier (e.g. strip them bare and they are still carrying a load). This was happening by 3 units of weight at a time; the weight of a clip. It's so bad that I managed to get 18 phantom weight units on a soldier before getting bored. Occasionally, 3 units of phantom weight would be removed again! It's hard to tell if this was in the original game, due to the lack of weight display in the inventory screen.

Edit: I've worked out what's happening. Add a loaded weapon to a soldier, unload it, and remove the ammo and gun: this ''removes'' 3 phantom weight units. But, add an unloaded weapon to a solider and load it... this ''adds'' 3 phantom weight units. [[User:Stubbs|Stubbs]]
:This is a genuine bug because they forgot to unassign the clip of a weapon when you drop it. Also the default weapon's clip is not initially assigned to the wearer so if you unload and reload the clip, your soldier weights more. [[User:Seb76|Seb76]] 13:27, 3 February 2010 (EST)
:: So is this impossible for you to override and fix? It's really irritating... I've edited lots of item weights, but I guess I'd have to make ammo light and guns heavy to minimize the effects of this bug. [[User:Stubbs|Stubbs]]
:::I second that, it would be great if this could be fixed. [[User:Rovlad|Rovlad]] 17:45, 13 May 2010 (EDT)

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

:: Alien reaction fire works fine for me within Alien Pets. -- [[User:Zaimoni|Zaimoni]] 12:41, August 12 2009 (CDT)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)
:Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)

The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. <3
:Uploaded a new version, you need to add a "HQ4x=1" line under the "Mod" section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)

Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)

Now the question is, how do you use DXWnd with the loader?
[[User:KingMob4313|KingMob4313]] 11:02, 12 August 2009 (EDT)

==Works but won't multitask==

Target system: prefab HP Vista with global data execution prevention. Problem is the same native, with D3D, and/or with HQ4X. (The two do combine nicely, visually, but a bit laggy for my tastes).

ALT-TAB terminates all further screen display on restore; the sea of blackness continues until Task Manager is used to kill the application, at which point D3D admits that it has "lost the device". (This is after the improved error reporting patch. Before, 0xc0000005 as Data Execution Prevention takes over.)

-- [[User:Zaimoni|Zaimoni]] 12:27, 12 August 2009 (CDT)

: Solved on Win7 for the most recent version: Program Properties dialog has an "unblock" button. Unblocking allows the program to survive being alt-tabbed away from. -- [[User:Zaimoni|Zaimoni]] 22:03, 24 June 2010 (CDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)
:That's great ;-) By dev I was refering to the "dev" version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)

Hi Seb, I've been playing the UFO series since the beginning but just joined this wiki. I've tried just about every mod there is for these games, and I must say, yours is one of the best as far as creating a "more complete" and stimulating game experience. My question is in regards to your "Heavy Laser" mod. I liked what you did by creating new "abilities" for the weapon with the Full auto and Burst fire mode, but every time I play I can't help but think that it just doesn't belong to the Heavy Laser as a weapon. I always envisioned the Heavy Laser as more of a long range "Sniper" support weapon, and I like the mod that the X-ComUtil added that gave the Heavy Laser a new life by increasing the accuracy and damage of the weapon making it one of the best Sniper weapons available (even if it is heavy to lug around) as well as finaly giving my troops a greatly needed new weapon for disposing of those pesky sectopods (on any difficulty). I do, however, think that the new fire modes (full auto and burst fire) would be a perfect addition to the Auto-Cannon. The in game image alone has always brought to mind a "mini-gun" type weapon that should be capable of very rapid fire, but at the expense of accuracy due to the encumbering nature of the beastly AC. I never liked how the AC seemed like a generic Heavy Cannon with less damage and only the added auto shot function. Also, I always wondered why that weapon even had an "Aim" function. Who's going to sit there trying to carefully aim a Gatling Gun? Nobody... that's who, you use a weapon like that for mass devistation and shock value, PERIOD! This is why I think that your mod to the Heavy Laser should be reconsidered for the Auto-Cannon. I think, at the very least, it will give people a reason to use the AC in the mid to late portion of the game, and being that it still has weak stats compaired to other weapons, it's not going to be overpowered or infringe on the use of specialty weapons (I think the Heavy Laser with full auto and burst fire is a little un-balanced due to its considerably higher power). If you don't agree that's fine, but since I'm not very knowledgeable about game programing, I was wondering if you could at least give me a hint on how to create similar weapon functions for other weapons, cause I'd like to at least try it out for myself. Thanks for any help you can give me and keep up the good work, you're mod is awesome.

== REng UFO with IDA ==

Hi Seb =)

I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.

So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).

Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.

I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.

My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).

Any advice is deeply appreciated mate =)

XCom forever!
--[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)
:Hi k9,
:Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.
:For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...
:Good luck with your project,
:[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)

:::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...

void InsertCall(int dst, void *func)
{
DWORD oldProtect;
DWORD *pOffset=(DWORD *)(((char *)dst)+1);

VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&oldProtect);
*(char *)dst=(char)0xE8;
*pOffset=(int)func-(int)dst-5;
VirtualProtect((void *)dst,5,oldProtect,&oldProtect);
}

::: This calculation here is interesting:

*pOffset=(int)func-(int)dst-5;

:::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).
:The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).
:The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)

:::Can you suggest some good reading material to better understand this? Cheers!
:::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)
:You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the "UFO Defense" process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)

== D3D ==

If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has.

I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)
:You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)

Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)

OK I ran the dxdiag utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)
:Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.
:Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)
Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)

D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J'ordos]] 19:09, 8 August 2009 (EDT)
:edit: forgot to mention, I have directx 9.0c installed and dxdiag reports no problems. I have a Geforce2 MX *blushes*
:Do you know if this card supports non power of two textures? [[User:Seb76|Seb76]] 05:10, 9 August 2009 (EDT)
::no idea, but since your new version works fine with the D3D option on I assume it doesn't :) [[User:J'ordos|J'ordos]] 11:38, 9 August 2009 (EDT)
:That's great. Spike, does it fix your problems too? [[User:Seb76|Seb76]] 16:04, 9 August 2009 (EDT)
::Sorry for the late reply - yes that fixes my problems too, D3D is working fine now. Thanks, [[User:Spike|Spike]] 15:55, 26 August 2009 (EDT)

== Save equipment ==

Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:

*1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of "invisible" equipment!
*Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips.
*The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.
*Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment.

Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked?

Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)
:Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.
:The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?
:As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.
:I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)
::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a "before" and "after". [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)
:In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)
::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns & ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)
:OK, I'll have a look at this, thanks for the effort.
:Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the "i/b" one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)
::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)
::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)
::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)
:I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)
:: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)
:Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)
::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)

Hmm more problems with Save Equipment. Ammo of all types seems to disappear. Eg I have 6 pistols and 6 pistol clips on the craft, but the Equip screen just gives me 6 empty pistols. Other weapons are short of ammo too. Is the Save feature perhaps "remembering" empty weapons (or loaded weapons) and somehow eliminating the clips. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)
:This looks like an issue with ''UnloadClips''(). I noticed that the clip object's ''loaded_into'' is set to 0xff, but the ''not_loaded'' remains as 0. The game may see this as the clip still being loaded in an object, so the clip effectively disappears. --[[User:Mikawo|Mikawo]] 11:05, 19 August 2009 (EDT)
::This is possible. The wiki is wrong on these 2 fields BTW: it is in fact just one field (loaded_into signed extended to 16bit). I'll have a look at that. [[User:Seb76|Seb76]] 14:33, 19 August 2009 (EDT)

I think Mikawo is right. UnloadClips() should look something like this:

void UnloadClips()
{
obpos_dat *pObPos=pObpos_dat;

for(unsigned char i=0;i<170;i++)
{
if(pObPos->itemType != 0xff && pObPos->not_loaded == 0 && IsXComItem(i))
{
pObPos->loaded_into=0xff;
<big>'''pObPos->not_loaded=0xff;'''</big>
}
pObPos++;
}
}

Quite a few other functions in '''equipment.cpp''' use this check '''pObPos->not_loaded == 0xff''' so it is important to set this flag just for UFOExtender, regardless of whether the game needs it set (which it probably does). Eg items unloaded by UnloadClips will thereafter fail to be found by GetFreeItem, during execution of LoadSoldierEquipment. That probably explains the problems observed.
[[User:Spike|Spike]] 15:24, 26 August 2009 (EDT)

:I did some rework based on that. Do you have other problems? [[User:Seb76|Seb76]] 16:08, 30 August 2009 (EDT)

::Thanks Seb. This seems to be working mostly ok now. Some remaining smaller issues I have seen:

::* The weight calculation is so accurate, it is more accurate than the unmodified game. So the "weight free ammo" (the first clip loaded into a weapon, before the user takes any action in the Equip screen) is no longer weight free. Not sure if you want to "fix" this or not? It is debatable. Really, you have fixed a bug. But the normal game behaviour has changed. Maybe make the "weight free ammo" optional?
::* There is a weird glitch. If I unload a weapon, put it and the clip on the ground seperately, that works fine. But if I pick up the clip '''directly from the ground''' and load it straight into the weapon, then drop the weapon, the weight of the clip is still shown on the soldier. And actually the same thing happens with a clip that is first moved into the soldier's equipment. So in fact the problem is that a clip loaded into a weapon, doesn't get removed from the soldier weight when the weapon is dropped onto the ground. It happens even if the clip is pre-loaded by your routine.
::* Still outstanding - you can't use the right arrow to move onto a second screen of equipment. So you can't have more than one screenload of equipment on the ground. Or maybe you can, if you start the Equip screen with more than one screenload on the ground - I didn't check that.

::[[User:Spike|Spike]] 13:10, 1 September 2009 (EDT)

== Glitch with Alien Pets and Big Brother? ==

Hi Seb. I was trying to do some initial research on the idea of [[User:Spike#Tank mods|Tank mods]] but it looked like these 2 useful features of your Loader, Alien Pets and Big Brother, have both stopped working. Can you test this, on the latest version? I'm using a very recent version (last 2 weeks) but not the absolute latest as I have internet download problems.

Also, have you seen this new Wiki article: [[Enemy Unknown Extended]]. It is a package including your loader plus a few other odds and ends.

cheers,
[[User:Spike|Spike]] 11:16, 17 August 2009 (EDT)
:My mistake, I commented out that part of code a while ago and only recently noticed that. It was corrected one or two versions ago.
:The article is a good idea, it should allow less techies an easy start. [[User:Seb76|Seb76]] 13:51, 17 August 2009 (EDT)
:: OK cool yes the Hacks are back in place, thanks. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)

== Alien Bleeding ==

Test results:

* 1-unit and 4-unit aliens can be healed by anyone (alien or human) holding a Medkit
* 4-unit aliens can be healed by standing in any of their 4 squares
* 4-unit aliens can only be healed while they are stunned. Pointing to their "control" square does not seem to work.
* 1-unit aliens can be healed either while conscious or while stunned
* Wounds on aliens can be correctly seen with Medkits
* The Medkit display shows a human silhouette regardless of the alien type, of course
* Healing aliens with Medkits, stops them from dying of wounds (not 100% tested but seems to be true)
* Aliens (large and small) seem to lose the correct amount of Health per turn from Wounds
* Aliens with wounds that are not treated, eventually die (not 100% tested but seems to be true)
* A Mind Probe can see if an alien has Wounds.

Anomalies:

* I had a lot more reports of Reapers dying than I would expect. I would not have expected any to die, and I had 3 reports of death by wounds. Even heavily wounded Reapers take a long time to die. In my test I was only shooting them with Pistols. Maybe there is a problem with the reporting? Maybe the death of the same Reaper was reported more than once? More testing needed on this.
:I wonder if Reapers are receiving wounds on all 4 sections when hit by explosives (I don't know which weapon you were using). They really shouldn't, although I'm unsure how you'd get around this. If possible, put a cap on the maximum number of wounds something can ever have (perhaps 6). You could argue their multiple hearts really empty their blood out quickly, but I don't think fatal wounds should ever become more dangerous than burning alive.

:: Well, why not: hit four times by one explosive, check for incurring fatal wounds four times. -- [[User:Zaimoni|Zaimoni]], 13:49 Sept. 6 2009 CDT

* Question: should the death of an alien by wounds be reported, or should it die silently? Did I only see these messages because I was using Alien Pets, and so they were on "my" side?
:Regarding death reports, I enabled the dialog for aliens/civilians (it usually only shows up for xcom operatives) to help in testing. The final version will not show them. [[User:Seb76|Seb76]] 14:10, 3 September 2009 (EDT)

Caveats:
* I used the Alien Pets, Big Brother, and Alien Inventory hacks to do this test. I also hacked a save game to give me Pistols, Medkits, PsiAmps and Mind Probes. [[User:Spike|Spike]] 16:03, 3 September 2009 (EDT)

To Do:
* Test if aliens (small, large and mechanical) suffer from [[Fatal Wounds#Other effects of Fatal Wounds|other effects of wounds]], e.g. penalties to Energy, Accuracy, Time Units
* Do Cyberdisks, which have no legs or arms and probably no head, only ever receive Torso wounds?

=== Mechanical Bleeding ===

* Question: Do Cyberdiscs and Sectopods receive Fatal Wounds? I'm wondering whether an unconscious Cyberdisc is safe to be around. Even if they didn't explode, Fatal Wounds would be stupid for a robot. If XCOM tanks can't end up leaking fuel and sparking dangerously, neither should enemy robots. [[User:Stubbs|Stubbs]]
: I think you can make a case for tanks and robots having "wounds", i.e. damage that gets progressively worse by itself. You can even make a case for them being "stunned" - temporarily non-operational. You can even make a case for it applying to alien robots but not to X-COM tanks, since alien robots all have some degree of organic component (which is why they can be Mind Controlled). But I still think you are right, neither effect should apply to machines, whether alien or human. As for your question, see the tests below:

Cyberdisk Bleeding Test Findings:
* Cyberdisks take Wounds (with Alien Bleeding option enabled)
* Cyberdisk wounds can be healed (though only after unit is stunned)
* Cyberdisks lose health from wounds
* Cyberdisks can die from wounds
* Cyberdisks don't seem to explode when they die from wounds ("has died from wounds" popup)

Cyberdisk Bleeding TestTest Caveats:
* Same caveats as previous tests (above), plus:
* The Cyberdisks were modified from Reapers using xcomutil :rpl
* Some Pistols were changed to Laser Rifles using xcomutil :chg
* (xcomutil was not installed in the game directory however, it was used from another location)
* The stats (Armour 34 all round, Health 120) appeared normal for Superhuman
* However the Cyberdisks seemed to fall too easily to Laser Rifle fire (e.g. 1 hit)
* Also, they seemed not to explode as often. This was because they were often stunned.
* Hard to tell in-game whether a Cyberdisk is dead or stunned. The graphic is the same, you can't use a Mind Probe, nor look on the ground, nor even check by changing sides.
* Actually there is one way to tell: stand over it and use a Medkit. Didn't think of that. [[User:Spike|Spike]] 08:22, 5 September 2009 (EDT)

:Thanks for finding out, Spike. Autopsy text shows you are right about the Sectopod( but not about the Cyberdisc) having biomechanical components, but it's not like there are gallons of blood pumping around the thing to gush out. One thing: did you check both conscious and unconscious death-by-wounds for the Cyberdisc? [[User:Stubbs|Stubbs]]
::No problem Stubbs. I didn't deliberately test this, but I had numerous deaths-by-wounding while unconscious and I think at least a few while conscious. I believe those that died while conscious, exploded. (I think this is the basic rule for Cyberdisks. If they are stunned, they don't explode. This typically happens with stun weapons but can also happen with regular weapons, if you are lucky.) [[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)

* Seb76: maybe robots receiving wounds was an oversight, or maybe you really do want robots to take wounds. In either case, it would be nice to have a separate option for this. My arguments against robot wounds are pretty simple: tanks do not receive them, the bled-out dialogue "X has died from a fatal wound" sounds silly for a robot that was never alive, and finally that a Medkit should not be able to heal a robot.
: It's reasonable that alien mechanisms (Sectopod, Cyberdisk) would not suffer from wounds. Possibly also Zombies should remain immune to wounds? From a note Seb made elsewhere, I think the UNITREF.DAT "can be wounded" flag is the same as the "can be stunned" flag. Wounding is probably prohibited globally for aliens, by an override somewhere in the executable. Seb has probably removed this override, unconditionally. To remove the override more selectively, I suspect Seb would need to put a logic test in the code, to check the alien type. .[[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)
::There was a check for ownership that I simply removed. Next version will have an explicit check for robots/chryssies/zombies not to bleed. [[User:Seb76|Seb76]] 12:29, 6 September 2009 (EDT)

* If you want a sense of "the Sectopod's leg got damaged" or even "the tank's track was broken", perhaps robotic units could be 'wounded' by damaging max TUs.
* If, however, the above won't let weapon usage TU %s recalculate as TUs are lost (i.e. the units lose firing ability as well as walking), then certain values of Energy with the correct Energy usage modifier could emulate loss of speed without losing firing ability. Since Energy is returned at a rate of 1/3 of TUs, these units could have an Energy value of (slightly less than) exactly 1/3rd of their TUs. Their energy usage modifier is then changed to allow this small energy value to usually suffice. Now, when Energy is damaged, the units will be permanently slowed, but their weapons won't be affected. [[User:Stubbs|Stubbs]]

=== Zombie Bleeding ===

Zombies that bleed to death don't seem to turn into Chryssalids. As discussed above, it might be better to disable wounding for Zombies. (Death by wounding for Zombies was already possible, without this fix, if the Zombie was mind controlled, wounded while mind controlled, then released back to Alien control.) [[User:Spike|Spike]] 21:07, 5 September 2009 (EDT)

== Hostile Civilians ==

This fix also seems to prevent:
* [[Exploiting_Mind_Control#Zombie's_Permanent_Control_of_Aliens_via_Stunning|Permanent Control of Aliens via Stunning]] Exploit - as was hoped for.
* [[Exploiting_Mind_Control#Resurrect Zombified Agents|Permanent Control of a Chryssalid/Tentaculat]]

It does not fix:

* Various Mind Control bugs:
** [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]
** [[Known_Bugs#Mind Controlled Aliens Count as MIA if you Abort]]

(Probably because fixing both of these requires special, end-of-mission processing)

Still To Be Fixed:

* [[Exploiting_Mind_Control#Exponential Mind Control|Exponential Mind Control]]

(This requires a check in UNITPOS to ensure that the unit attempting Mind Control is not, itself, already mind controlled.)

[[User:Spike|Spike]] 16:16, 3 September 2009 (EDT)

== Fixed Funky Fire and Zombies ==

Fixed Funky Fire still permanently kills Zombies, when the killing damage comes from (end of turn) fire damage. [[User:Spike|Spike]] 21:02, 5 September 2009 (EDT)

== Research Tree ==

I've found a way of modding the research tree and was wondering if people are interested in an updated version. I've read of stuff like enabling hovertanks from cyberdisc autopsies or flying suits with floater research, but I think there is more that can be done. The limitations from the original game is that having researched a topic cannot unlock more than 4 new topics, and cannot unlock the production of more than 4 new item types. Any ideas? [[User:Seb76|Seb76]] 12:40, 6 September 2009 (EDT)

* Another one I mentioned was: Mind Probe before Psi-Amp, although I'm going to retcon that to "Mind Probe before Psi-Lab" (which then leads to Psi Aimp as per usual). The logic behind this is that the first step of a psi-attack must be scanning for enemy brainwaves to pick them out of the other signals. Before you can teach soldiers to do this, you'd have to have studied the mind probe to see how the non-psychic aliens are managing to find targets. You've got to walk before you can run, after all.
* I'm unsure if the next suggestion is possible, given what you have said. I'd like some kind of necessity to research at least some corpses/aliens - is it possible to require, say, any 6 alien 'live' or 'autopsy' reports finished before Alien Origins unlocks? You might also make it dependent on difficulty (6/7/8/9/10 needed). You could also include alien missions in this count.
* My only other suggestions are: you should have to research Elerium before you can build anything that requires Elerium to build. You should have to research Alien Alloys before you can build anything that uses those (which is true only for some things currently. It doesn't seem to be a prerequisite for building alien weapons). Is it possible for a manufactured item to require two separate research entries to be manufactured?
* Question: is there also a limit of 4 prerequisites for a research item? [[User:Stubbs|Stubbs]]
:There is no limit on prerequisites, it's the code that shows "you can now build/research xxx" that has a 4 entries limitation. [[User:Seb76|Seb76]] 15:05, 6 September 2009 (EDT)

A boring suggestion but how about making sure that for all weapon research, you need to do the pistol before the rifle before the heavy weapon, etc. And similarly with the ammo types. Apart from that, I'll think on it. [[User:Spike|Spike]] 17:42, 6 September 2009 (EDT)

Another boring suggestion: each specific laser weapon should take a little longer to research - force you to use the starting weapons for a little longer. You could also rebalance the Plasma research times so that the rifle took a little longer and the Heavy Plasma took significantly longer. It might then be more viable to research them from weakest to strongest, without forcing your hand as Spike suggested. [[User:Stubbs|Stubbs]]

:Yep that's a good alternative.

You could make the Stun Launcher a little harder by requiring (as well as Alloys and Elerium), perhaps a live Medic to be researched before the Stun Launcher (since it's usually Medics that carry them and presumably understand how to operate them), and an Engineer for a Blaster Launcher. It's not much extra but it helps to make these powerful weapons a little harder to get. If you wanted to make Blaster Launcher quite a lot harder to get you could add something like UFO Navigation (something to do with plotting all those waypoints, alien-stylee), or at least a Mind Probe for similar reason.

But, what are we trying to do here? Make things harder in general? That's one option. Or "rebalance", i.e. make things that are relatively too easy to get, relatively harder to get? Or make things more "logical"? There's lots of ways to play this.

It's a shame there's not a distinction in the game between using, and manufacturing, alien weapons - as is done in XcomUtil. Really, there should be a world of difference between figuring out how to use scavenged alien weapons, and actually being able to manufacture them. But that's not really a research tree topic, '''unless''' - would it be possible to create new topics? Could you separate out the using of an item from the manufacturing of it? (If not, it would be good to have a game variant in which nothing that can be scavenged, is allowed to be manufactured).

UFO Navigation might also be a good prerequisite for Hyperwave Decoder. I'm sort of rambling here, but what are the most powerful technologies, that are kind of easy to get... which ones need to be made harder. (Are there any that need to be made easier?)

Powerful technologies:
* Psionics (Psi Lab == Psi Amp). Adding the Mind Probe, as suggested, would be a good idea. Maybe a psionic Commander capture required for each.
* Blaster Launcher - maybe require an Engineer and a Soldier research, as well as Elerium & Alloys. Mind Probe or UFO Navigation for the "plotting" element? A separate Engineer capture to produce the ammo? What else?
* Stun Launcher - Medic and an Engineer? Maybe a full set of autopsies - but that's too onerous.
* Heavy Plasma - stretching the research time would be good, though this can already be done. Additional pre-reqs - maybe add a live Engineer requirement (maybe for ''each'' Plasma weapon type?). If you keep making these requirements you probably need to add a hint in the UFOPaedia along the lines of "we will need to interrogate alien technical experts to further understand this weapon technology". (OK that's hardly a hint.)
* Laser Cannon (?) - But I'm not sure this Laser Cannon factory thing is a big deal. Arguably building a new intercept base is a better cash cow than building a 50-Engineer Laser Cannon factory.

[[User:Spike|Spike]] 16:34, 8 September 2009 (EDT)

== 64 bit compatibility ==

Any way to make the loader compatible with 64-bit operating systems, like 64-bit XP/Vista/7? [[User:Jwilcox25|Jwilcox25]]

: I'm using it on Windows 7 and it's working fine. Not sure if that's 64 bit though. [[User:Spike|Spike]] 07:26, 9 September 2009 (EDT)

:: If you're not sure, you are probably running the 32-bit version of Windows 7. Starting from XP, Windows comes in both 32-bit and 64-bit flavors. Most 32-bit programs are backwards compatible, but apparently not X-COM from my experience. [[User:Jwilcox25|Jwilcox25]]

: It works fine with Windows 7 64-bit. Didn't have to enable any compatibility options or anything like that. [[User:Rovlad|Rovlad]] 02:29, 23 April 2010 (EDT)

== Music bug ==

When enabled "MIDI freeze" bugfix, after entering first combat the music stops playing completely, for the remaining game session.

Also, when using Extender, for some reason music is playing at really low volume, i have to manually reduce my main sound channel and crank up the volume to hear it. When just starting normal UFO CE volume levels of music and sfx are about equal. I have SB Live & WinXP.

== Fire Speed bug ==

Sometimes, for no apparent reason, fire speed setting jumps to 3, instead of what you had it set on.

: I believe it's a bug in the game itself, not the loader. I remember encountering it in both DOS and CE versions. [[User:Rovlad|Rovlad]] 02:31, 23 April 2010 (EDT)

== Reserve TU for x-Shot ==

Not sure if this has been addressed or fixed, but if you reserve Time Units for any shot type, all you get is Snap Shots for the reaction phase - never aimed or auto. Is there any way you could enable these two unused types for reaction shots? --[[User:Zombie|Zombie]] 22:51, 25 October 2009 (EDT)
:As far as I can tell, the reserve is only meant to be used during the active turn. Reaction shots are hardcoded to snapshots (that's true for the aliens too), it's no bug that your guys don't use reaction autoshots. [[User:Seb76|Seb76]] 12:10, 16 January 2010 (EST)

== TFTD ==

I know you're hoping to perfect the current version before taking on any new projects, but I just want to add my plea to the others requesting a TFTD version. Even some of the basic functionality would be awesome and probably completely portable, such as the stats on the equipments screen, default new base, etc.

== Can't change tasks in D3D ==

Hey, I'm having an issue with D3D. If I alt-tab out, I can't switch back to the X-Com task. I'll switch to it but nothing can happen. I'm on Windows 7 x64 with an ATI Radeon HD 5770. [[User:Rlbond86|Rlbond86]] 20:19, 15 January 2010 (EST)
:I too have hangups sometimes when alt-tabbing out of XCom, sadly I'm no D3D expert :( I'll add more checks to see if resetting the D3D device worked though. If anyone knows of a 100% working way of dealing with "device lost" conditions, now is your chance... [[User:Seb76|Seb76]] 12:06, 16 January 2010 (EST)

== Battlescape Soldier's Stats Crash ==

I'm having this little problem with this and I wanted to know if I'm the only one that's suffering with it: everything works fine, but when in battlescape mode I want to check the stats of a soldier (by clicking his rank icon) the entire game CTD. Does it happen to anyone else? How can I fix it?
:Never saw such problem...
:* Does it still crash when you disable the extender (and what options did you enable)?
:* Do you have the address where the crash happens?
:[[User:Seb76|Seb76]] 15:55, 22 January 2010 (EST)
::It didn't, but now I reinstalled the game and it works wonderful. This is a great job you did here. Is there any chance that you could access to the stats of the soldiers from the assign crew screen? --[[User:Slibluhr|Slibluhr]] 16:56, 22 January 2010 (EST)
::OK, I could reproduce the crash this time, it has nothing to do with the stats screen as I supposed to do. The game crashes RANDOMLY if I have turned on the D3D thingy, any clue? I've also noted that if I turn on the caps mod (to put most of 'em in 150-200 to overcome the distance penalty) the soldiers do NOT improve, even after kicking a large scout's butt with KAtherine Sharpe, she didn't get any FAc point! --[[User:Slibluhr|Slibluhr]] 05:30, 23 January 2010 (EST)
:The caps bug is a known one, and a fix is available. I thought I'd wait for more substancial stuff before releasing a new version though. You can try the latest dev version that has the fix included.
:As for your crash I cannot do much without a crash address... [[User:Seb76|Seb76]] 11:46, 24 January 2010 (EST)
::This is what it said during last crash:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00011689

::--[[User:Slibluhr|Slibluhr]] 15:29, 24 January 2010 (EST)
:Sadly the address is of no use (crash inside Windows code, most likely because of wrong arguments). I've put a new version up with better D3D error handling, does it help with your crashes? Also since I was feeling like it, I updated the "Reorder Soldiers" feature so that when you click the name of the soldier, his stats show up. You must click the rank/name of the ship to assign the soldier. [[User:Seb76|Seb76]] 18:00, 24 January 2010 (EST)
::Thank for the access to the stats of the soldiers via crew screen, it releases them from having their FAcc and PStr in the name.

:: btw, the crash moved to this location now:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00028c0b

::could it be that's my pc's fault? does this happen to anyone else?

::------------------
::System Information
::------------------
::Time of this report: 1/25/2010, 01:25:00
:: Machine name: 0X000001
:: Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.090804-1435)
:: Language: Spanish (Regional Setting: Spanish)
::System Manufacturer: FOXCONN
:: System Model: A6VMX
:: BIOS: BIOS Date: 03/13/09 09:59:28 Ver: 08.00.14
:: Processor: AMD Sempron(tm) Processor LE-1250, MMX, 3DNow, ~2.2GHz
:: Memory: 3072MB RAM
:: Page File: 466MB used, 4490MB available
:: Windows Dir: C:\WINDOWS
:: DirectX Version: DirectX 9.0c (4.09.0000.0904)
::DX Setup Parameters: Not found
:: DxDiag Version: 5.03.2600.5512 32bit Unicode

== Store limit question ==
Nice to see you've implemented the general store change (unfortunately, UFOExtender doesn't work under wine, so I can't test this). I'm curious why 187 is the limit? I thought it would be a power of 2 (possibly minus 1)... Possibly you wanted to write 127? [[User:Cesium|Cesium]] 19:43, 21 February 2010 (EST)
:You can build 35 general stores max in a base and 65535/35 ~= 1872 (the internal representation is ten times what's shown ingame). [[User:Seb76|Seb76]] 00:19, 22 February 2010 (EST)

== Mouse scaller not working on Windows 7 x64 ==

with d3d=1 and Scale Mouse=1 I still have issues with the mouse going way off screen.
--[[User:BladeFireLight|BladeFireLight]] 01:57, 22 February 2010 (EST)
:I have noticed that alt-tabbing out of X-COM at the title menu (or any other point that won't crash it) and then alt-tabbing back into it fixes this problem for me in Win7-64. --[[User:Xusilak|Xusilak]] 13:12, 22 February 2010 (EST)
::Thanks for the heads-up. I uploaded a test version here: http://www.ufopaedia.org/index.php?title=Image:UFOExtender-dev.zip
::Does it fix you problems? [[User:Seb76|Seb76]] 14:36, 22 February 2010 (EST)
:::Yep. Seemingly no issues with the mouse going off the screen using it, although I didn't test for long. I'll try to get more test time in later. --[[User:Xusilak|Xusilak]] 20:46, 24 February 2010 (EST)
::::Actually, it doesnt work for me either, in WinXP. And it was broken since the version of 7th November, the one with windowed mode addition. Also, Alt-Tabbing didnt work too. This fix makes things right, though.
::::Edit : also, this dev version crashes in 100% cases when going to battlescape.
::Strange, I do not have any trouble even when using split binaries. Do you have an address for the crash? [[User:Seb76|Seb76]] 14:03, 1 March 2010 (EST)
:::Okay, i hope this is what you wanted, but it says the adress is 0x0000000000bd22ca. I can load an actual save with tactical mode, but cant go into tactical from geoscape. So i use the version from 1st November still.
:Hum, you say the dev version crashes and that you are stuck with the version from 1st november. Do you mean you have the problem since the version of november the 7th, independently from the dev version? [[User:Seb76|Seb76]] 14:08, 4 March 2010 (EST)
::Actually yes. At first i didnt want to use it, because i use a tablet instead of mouse, and its really noticeable when a window failed to scale properly, since a tablet works in absolute screen coordinates. But just now i checked several new (non-dev) versions for the crash - its there. Crashes every time i try to enter tactical mode from geoscape. Saves from tactical load up fine. Version from Nov.1st gives no problems whatsoever.
:Do you still have the problem if you disable D3D or use windowed mode? Also if you load a tactical game, don't you get a crash when it goes back to geoscape? [[User:Seb76|Seb76]] 03:20, 6 March 2010 (EST)
::When disable D3D - yes. When enable windowed - yes. When going from tactical to geoscape - no.
:OK, I suspect this has to do with the "Save Equipment" feature. Can you try disabling it if you have it on? [[User:Seb76|Seb76]]
::OK, um...i tried all my saves, and with that feature disabled all my saves load up fine, and i can go from geoscape to tactical and back. So i thought everything was alright, and kept playing - the very next tactical mission loads up fine, but as soon as i try to move anyone - it crashes. And that is the same in all my saves, first mission is alright - second one always crashes. The crash adress is 42064f, in case you're gonna ask.
:Alright, can you PM me a savegame before the crash? I doubt it'll help but who knows...[[User:Seb76|Seb76]] 12:43, 6 March 2010 (EST)

== Extender in Steam (+ maybe XComUtil) ==

Hi do you know of any way to use the two apps together with the Steam version? I would really like to be able to combine the 'Reorder Soldiers' feature of Extender and the 'Capturing Aliens for Research' of XcomUtil.

Actually now that Ive put a bit more time into it I can't get UFOLoader.exe to run in steam's dosbox implementation at all. I can just run UFOLoader but it doesn't run in dosbox which makes the game run horribly. If you don't have a steam copy for testing / integration of the basic Extender program please let me know and I would be happy to send you a gift copy.

-Dogfish

P.S. What a great program, you are a credit to gaming.
:As far as I know, the Steam version also ships with the windows CE edition, the default shortcut just happens to point to the dosbox one. Also the latest version of XComUtil is able to detect the loader presence and act accordingly. [[User:Seb76|Seb76]] 15:42, 25 February 2010 (EST)

:: STEAM comes with both EXE. XcomUtil and UFO Extender work together with STEAM. To use Setup UFO Extender in the game folder. Then Download and install the latest build of XcomUtil 9.7. It will auto start XcuSetup in windows, Detect UFO Extender and allow you to configure RunXcom to use it. To use UFO Extender, or UFO:CE you can't launch the game from STEAM. You have to create a short cut for RunXcom. (Right click > send to > Desktop as Shortcut) --[[User:BladeFireLight|BladeFireLight]] 19:13, 25 February 2010 (EST)

Thanks guys I was able to start the game with both mods. I apparently had everything configured correctly but I kept launching it from steam. Is there a way to play in windowed mode (since its not using dosbox)? I tried launching dosbox and running 'RunXCom.bat' file from there but it does not recognize UFOExtender.

Oh boy the game is fast, even on slowest scroll it is difficult play a battle :)

-Dogfish
:What options did you turn on? [[User:Seb76|Seb76]] 14:18, 26 February 2010 (EST)

Show Stats=1
Apply=1 (wreck analysis)
Proximity Grenades Experience=1
Elerium-fueled Craft Bug=1
Save Reserve Mode=1
Rank In Inventory=1
Manual Interception Fire Mode=1
Crafts Always Ready=1
Reorder Soldiers In Crafts=1
No Funkers=1
TFTD Doors=1

Full System Specs:
Win Vista 64
Intel i7 920
6GB RAM
GTX 285 Video
Asus p6t

Everything is fast the geoscape tics are at least 5 times faster than running the non-Extender mode via dosbox.

Would you have any suggestions how to slow it down? I've actually been playing in steam(dosbox) with XComUtil only and then saving/loading between missions so I can reorder the soldiers.

Aha! I found the D3D Windowed option...
HQ4x=0
D3D=1
D3D Windowed=1
Always On Top=0
Clip Cursor=1
Scale Mouse=1
Screen Ratio=0.833333

I can manually resize it to be bigger, excellent!
What is strange is that running it in windowed mode seems to slow it down enough for the scroll speed settings to make it playable :)

I ran into a "Unsupported 32/16/64 bit error message switching from geoscape to battlescape but it happens only 1/3 times maybe?"

I will be playing this and let you know if I run into any more problems.

Thanks a bunch!
-Dogfish

Hi guys, dogfish again I've been getting a couple of glitches.

1. Switching from battlescape back to geoscape in the cmd prompt it displays
'echo----------------------------Leaving' is not recognized as an internal or external command, operable program or batch file.

2. This has happened twice

Get someone who has been shot is at low health and has fatal wounds

Have them pass out due to smoke inhalation

Let them bleed to death and get the "Joe McSoldier has died from a fatal wound" *while unconsious from the smoke*

I will lose points for the mission but the soldier will be recovered at the end of the mission but terribly wounded. (Currently Hans 'Jesus' Vogel is taking 55 days to recover his 41 health.)

:Both of these are XcomUtil issues. 1 has been fixed in Build 413 but I need a saved from just before ending combat to fix 2. --[[User:BladeFireLight|BladeFireLight]] 18:19, 28 February 2010 (EST)

::Sent the savegame to your gmail (whatever was listed on my paypal reciept from your donate button). Just hit end turn (all the aliens are dead) and the bug is triggered. -Dogfish
::: I got it. Was up all night with Bomb Bloke and we worked out what was going on. The fixed works with your save. The next build will fix the zombie bug. Also Thanks for the donation. Every little bit helps. --[[User:BladeFireLight|BladeFireLight]] 16:02, 1 March 2010 (EST)

--
Hi! I'm thefarside. This is my first time ever editing a wiki page so please bear with me. I'm not even sure I'm allowed to do this.

However, I have a problem with the cursor. It moves WAY out of the screen to the right and downwards. I've read something about a "clip cursor" fix but I can't seem to find out where and how to implement it.

Regards,
thefarside
--

== Manually Select Promotions ==

Just an Idea, not sure how easily done it is but I was thinking it would be really cool if (when its time for promotions) it would bring up a soldier screen with the eligible soldiers so that you could pick who gets promoted. Bonus if you could click on the candidates and be taken to their stats screen.

Love,
Dogfish

== Xusilak's Patch Additions ==

Since my patches are being integrated into the main release now, everyone should let me know if any issues are found with them. I'll try to get on fixing them as quickly as possible.

For clarity, the patches in the current build that I developed are:

* AutoSell
* Show Money

Thanks! --[[User:Xusilak|Xusilak]] 14:51, 24 March 2010 (EDT)

I went ahead and set up my own user page: [[User:Xusilak]]. If possible, direct discussion about my patches to my [[User_talk:Xusilak|discussion page]] there. Thanks again! --[[User:Xusilak|Xusilak]] 15:44, 24 March 2010 (EDT)

----

Hi Seb,
I've been working with IDA, your database, and your patcher's code for some time now, learning my way around it, and so on. So far, I've managed to come up with three UI improvement patches, although they still need some polish and testing.

The first one is a battlescape movement confirmation patch; it requires the user to click twice (double-click with no time limit) on the same tile to move, instead of once, to eliminate movement errors. In practice, I have found this very helpful.

The second one shrinks the geoscape clock and adds your current funds above it, letting you see your financial situation at a glance while waiting for time to pass.

The third one enables auto-selling of manufacturing items. Pressing the down arrow when the production quantity is at 0 engages this mode. When in this mode, production of that item never ceases (unless resources become unavailable), and the item is immediately sold upon completion.

Would you like me to make the code for these available once I've finished polishing them up? They currently consist of a few C functions accompanied by some InsertCall()s and Nop()s, as well as some additions to XCOM.h. I haven't added INI options to enable them, so I'd leave that up to you. You may use them as you wish, with no conditions.

Note: I'm still learning x86 assembly, so the patches may not be bug-free. I'm hoping to give them a good testing myself, though.
--[[User:Xusilak|Xusilak]] 16:10, 19 March 2010 (EDT)
:Glad to see you could make something out of this database :-) Do not hesitate to send me your modifications, I'll incorporate them in the codebase so others can enjoy them. I'm sure your autosell feature will make a few happy ones ;-) [[User:Seb76|Seb76]] 19:12, 19 March 2010 (EDT)
:::Yeah those features would all be '''great!''' Thanks Xusilak. [[User:Spike|Spike]] 15:08, 22 March 2010 (EDT)
::OK. I'm going to finish up my last touches on them, then test them for a while; they should be ready within a couple days. --[[User:Xusilak|Xusilak]] 21:59, 19 March 2010 (EDT)

== v1.21, Battlescape crashes ==

I enabled the new mods and they worked ok in Geoscape. Then this Popup box starting the first Battlescape:

Application failure
XCOM crashed at 0x10002571 with error 0xC0000005 trying to access 0x0968DF43

[[Media:UFOExtender1.21.BSCrash.zip]] contains the UFOExtender.ini file.
This was a New Game but not a new install of XCOM, just an overlay of updated UFOExtender.

*Win XP Pro 2002 SP2 32bit PAE
*Pentium-4 3.00GHz 3.5GB RAM

Any ideas? Need more info? [[User:Spike|Spike]] 20:20, 24 March 2010 (EDT)
:Does it happen consistently? I've been plagued by a random geoscape->battlescape transition crash in the collector's edition. It's one of the things I'm looking to fix at some point. The current UFOExtender doesn't appear to crash any more than previous ones do for me. I managed to do four missions in a row just now. --[[User:Xusilak|Xusilak]] 21:00, 24 March 2010 (EDT)

I'm doing some research into this; I started up in debugging mode and spammed missions until I hit a crash. The crash (on this occasion) is an access violation caused by an invalid pointer stored at 0x49B954 (the offset that pSoldierDat points to). This means *pSoldierDat is being changed at some point. It took many, many tries to get this crash to happen; I reloaded something like 20 times hitting the same mission, went ahead and did the mission quickly, proceeded, did another mission, proceeded, then the next mission crashed. Given that I'm in debug mode, it's not impossible this is due to the various hacks enabled by it, so that should be kept in mind. I'm going to continue working on this. --[[User:Xusilak|Xusilak]] 22:26, 24 March 2010 (EDT)
:It appears the "invalid" pointer is actually set by malloc() - 0x0771D380 (for me). I can only assume something along the way disrupted the data on the heap, as the pointer was the same when examined on a battlescape transition that didn't crash. Still researching. Note that for me, the crash itself happened inside GetSolderUUID() in the Save Equipment patch functions when it attempted to use that *pSoldierDat pointer. However, I assume it would still happen if the Save Equipment patch were disabled, just elsewhere. This is something I'll test as well. --[[User:Xusilak|Xusilak]] 23:41, 24 March 2010 (EDT)

::Sorry I'm guilty of reporting a bug I didn't (couldn't) repeat. But as I had no previous save game positions I couldn't repeat anything - the crash happened on the first Battlescape mission which for me is unusual, I would say that for me that transition crashes less than 1 in 100 times, if even that many. I had enabled Save Equipment I think and on instinct I would suspect that mod as being responsible. Those UFOExtender functions would run while setting up the Battlescape presumably. The equipment handling functions and structures ''already'' present in the game are known to be buggy. BladeFireLight and I just found another issue with them last week. Manipulating them is still risky. If you can investigate that would be very helpful.

::In the meantime I will see if I can try to repeat the fault, with and without Save Equipment enabled, and starting from a clean XCOM install. One trick I may use is to set No Score Game Over and then just abort from each mission rather than fighting it, to speed up the testing.

::Thanks for your good work Xusilak, it is appreciated! [[User:Spike|Spike]] 03:25, 25 March 2010 (EDT)

One possibility: On this mission I had only 6 soldiers (2 HWPs) but enough weapons in the Skyranger to equip 14 soldiers. Is there some known issue with needing to allocate '''all''' weapons to soldiers during the equip phase, in order to avoid a crash? If so that might be the cause. I will try to recreate those conditions and see if it provokes a crash. In case it's not clear, Battlescape never appeared to start, no Equip Phase screen ever came up. [[User:Spike|Spike]] 03:31, 25 March 2010 (EDT)
:Assuming the same crash is afflicting us, then the crash is when the very first soldier is accessed, when the Soldier.Dat data is first used for that mission. It's unlikely that volume of equipment is affecting that, and in particular, I hadn't changed my Skyranger's loadout to any degree whatsoever, having only briefly touched researching and manufacturing; it was otherwise a gamestate set entirely by doing one quick regular mission and one quick terror mission. However, I was also in debug mode, which enables certain cheats, like Alien Pets, automatically. This might, itself, have unseen bugs that could corrupt the data structures and cause a similar crash. When I get the time to, I'll be testing again with those cheats disabled, trying to further isolate the conditions involved. --[[User:Xusilak|Xusilak]] 08:34, 25 March 2010 (EDT)

I've repeated this multiple times now, with a clean install of XCOM and a clean install of UFOExtender 1.21. The game crashes everytime, after the "mission screen" that comes up just before the Equip Phase of Battlescape for the first mission. It's regardless of my equipment loadout or number of soldiers/tanks: it happens with totally default equipment and Skyranger load. So I imagine it must be due to some combination of the UFOExtender.ini file options I selected, and maybe code changes in 1.21. My .ini file is the upload at the top of this section. The error is always "error 0xC0000005 trying to access 0x0968DF43", though the crash location (in the code) varies. [[User:Spike|Spike]] 20:31, 25 March 2010 (EDT)
:If you have time, could you try to 1) confirm it's specific to 1.21 2) try to correlate it to ini options? Turn everything but the basics off and see what happens... if that works, turn on Save Equipment and try again, etc. I haven't seen any behavior like that in my local tests, on either of my computers (Win7-64 and XP-32). I'll try it with your ini, though. Maybe I can find something. --[[User:Xusilak|Xusilak]] 20:39, 25 March 2010 (EDT)
::Just tested with your ini, although with D3D and D3D window enabled. Started a mission, didn't crash. I also noticed one thing: you have General Stores capacity set to 1. I don't think that's helping anything, but it's probably not causing the crash, either. Experimenting more. --[[User:Xusilak|Xusilak]] 20:48, 25 March 2010 (EDT)

::: Save Equipment=1 is part (at least) of the problem. If I turn that off, and leave all my other .ini settings as is, I no longer get the Battlescape crash. Seb, did you make some changes there? Maybe after the investigations we were doing with BladeFireLight? [[User:Spike|Spike]] 21:13, 25 March 2010 (EDT)

I have isolated the problem (on my end) to the fact that the SOLDIER.DAT data in memory is deallocated when the transition to the Battlescape starts. When Seb's Save Equipment code attempts to use it, it's getting random unallocated (or unrelated) memory instead of the SOLDIER.DAT data. Interestingly, the dynamic memory used to hold the SOLDIER.DAT data is deallocated on the transition to the Battlescape, and reallocated to a new memory address on the transition out of the Battlescape. I assume this is an artifact of the way the Collector's Edition merged TACTICAL.EXE with GEOSCAPE.EXE, because TACTICAL.EXE had no need of SOLDIER.DAT, and only used UNITREF.DAT and similar. At any rate, this problem can be resolved by not relying on **(0x49B954) (or **pSoldierDat) to contain the correct data. Instead, a workaround to get the needed data should be used. One option would be to patch the way the transition works to prevent the deallocation from happening, and then ensuring on exiting the Battlescape that the old memory block is still used. I may be able to work in that fix myself. If so, it would require no changes to the Save Equipment code.
I'm not sure if this is a general issue or local to me only. I'll try to test on my XP system and see if it suffers from the same problem; if it does, it's a safe bet this is a general issue, and the likely cause of your crashes. --[[User:Xusilak|Xusilak]] 00:06, 26 March 2010 (EDT)

Save Equipment did used to work for me before. Maybe it's because I also selected Reorder Soldiers In Craft. Does that sort and rewrite SOLDIER.DAT? [[User:Spike|Spike]] 03:39, 26 March 2010 (EDT)

I have confirmed this behavior in the original X-COM Collector's Edition UFO Defense.exe copy, running on my XP system. As such, it ''cannot'' be a result of any patches Seb has made (because it still happens even when not using Seb's loader). I'm not sure if it will crash without Seb's patches still, but the way Seb uses the *pSoldierDat pointer in GetSoldierUUID() appears to be unsafe, as *pSoldierDat has already been deallocated at that point. On some systems, it may work, because the nature of memory on the heap is such that different systems give different results when dealing with deallocated memory and bad pointers. Regardless, the crashes can be at least partially (maybe entirely) resolved by using a workaround that avoids the deallocation of *pSoldierDat when the battlescape transition starts. I'm going to see if I can implement the fix I suggested, that prevents the memory from ever being deallocated. That should completely resolve it. At the least, I am going to study the assembly responsible for deallocating it to see if I can confirm the exact issue on the code level. --[[User:Xusilak|Xusilak]] 13:26, 26 March 2010 (EDT)
:It seems that when GotoGeographMode() returns to move into GotoTacticalMode(), it calls FreeEverything() in the process, deallocating all data structures. Then, GotoTacticalMode() never bothers to reinitialize *pSoldierDat, so when the equipment phase comes up, it's still unallocated. Still working on a fix. --[[User:Xusilak|Xusilak]] 14:29, 26 March 2010 (EDT)

::Surely at some point the (unmodified) game needs to at least read the *pSoldierDat structure, in order to populate the [[UNITREF.DAT]] and [[UNITPOS.DAT]] structures for Battlescape? Unless it reads SOLDIER.DAT but doesn't bother storing it, not even temporarily, in *pSoldierDat.[[User:Spike|Spike]] 15:27, 26 March 2010 (EDT)
:::Nice piece of analyse there :-). I'll modify the patch to load the soldier data when needed and clean up afterward. [[User:Seb76|Seb76]] 15:30, 26 March 2010 (EDT)
:::Edit: I uploaded a test version. Can you check if it fixes your crash? [[User:Seb76|Seb76]] 15:47, 26 March 2010 (EDT)
::::Looking good so far; Save Equipment works for me now, and it never has in the past. I'll run through a bunch of missions quickly and see if I get any crashes. Thanks Seb! --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:::No, thank you for figuring out the cause of the crash. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
:::::Just ran through several dozen (very quick, mostly aborted) missions all the way up to June. I never crashed, and Save Equipment always worked correctly. I think we're good to go. Hopefully it works for Spike as well. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)

I've also been narrowing in on another crash, unrelated to the patcher, I believe. It happens rarely upon clicking the air to move somewhere, like stepping out of the Skyranger by clicking the air one tile in front of the soldier, to move onto the ramp. It appears to be the result of a bad calculation on the tile to check in MoveUnitTo(). The calculation is looking at (char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize); // when esi is 2 or greater; this esi factor shouldn't be there, as far as I can tell, because it results in the offset used being much greater than it should be and frequently going out of bounds of the MAP.DAT data stored at *pMap. Continuing my research into this when I get a chance. --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:I noticed that crash also (I think it's the number one crash cause on a genuine XCOM setup) but was never able to reproduce enough to investigate it. I was tempted at one point to patch the GetTileAt function to check its arguments, but finding the cause of the corrupted value would be better. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
::Yes, it's definitely a hard crash to catch, because of how rare it is. I've got a few ideas, though. We'll see if they help. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)
:::Currently, my guess is that this line:
:::<pre>.text:00420534 BE 01 00 00 00 mov esi, 1</pre>
:::should be "mov esi, 0" instead.
:::To sum up the issue:
:::The way the 'click on air to move to a tile below unit' part of MoveUnitTo() works is that it examines each level below the unit until it finds a floor to move to. It does this by looping through the level below you, incrementing esi to loop through the next level below that, and so on. To do this correctly, esi should start at 1. However, the X-COM programmers appear to have made an oversight: they initialized esi to 1, but then incremented esi again before the initial value actually gets used. The net result of this, is that we get zpos += 2 for the very first cycle. This works OK on floors 3 and 4, but for floor 2, it will attempt to access a z level that doesn't exist (one below the ground), causing this line: <pre>(char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize);</pre> to exceed the bounds of the *pMap memory block. Obviously, running off the end of that block will cause unpredictable results, and if it reaches into a block that isn't allocated, it will crash. That's why the actual crash is very rare: it has to overrun into an unallocated memory block.
:::Of course, I could be completely wrong, but it makes sense, and patching 'mov esi, 1' to 'mov esi, 0' doesn't seem to cause any problems. I'm going to be testing with that patch enabled from now on, to see if I crash in that circumstance anymore.
::Looks like you are right. I instrumented the code and there are indeed systematic out of bound accesses when getting out of the craft, though the game does not crash every time. I suspect this is the same crash that happens during base defence when an alien tries to move down from the access lift. Kudos for figuring all this out! I'll provide the fix in the next version. [[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)
:::By the way, Seb, the 1.21 source code doesn't include autosell.cpp; I assume it's a simple oversight. I reconstructed it to get it compiling properly. Just wanted to make sure you knew. --[[User:Xusilak|Xusilak]] 20:37, 26 March 2010 (EDT)
::Oops, forgot to check the unversioned files before checking in...[[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)

== Minor cosmetic enhancements? ==

Had these ideas come to mind while I was at work today, and since your loader is doing some amazing things for the game, I thought I'd ask if the possibility of any of these enhancements exist.

The short of it is: Are you able to overlay any additional bitmap surface on top of the battlescape view, and are you able to play additional sounds?

The main idea for drawing an extra bitmap (semi-transparent) over them map would be to simulate rain/snow for some outdoor maps. Lightning even - though that would require clever use darkening and lightening the overlay. This would have some issues attached to it such as knowing when to display it and when not to, thanks to the various other screens available.

As for playing sounds, which would be simpler, would be to play a looping sound clip to provide environmental sound effects, such as insects chirping and owls hooting at night in woodland maps or town noises at terror sites. Or during the day in a jungle map, some tropical bird calls made at random intervals. TFTD already does the looping environmental sounds, such as teh under water bubbly noises or the wind and sea noises when on land mission. Would it be possible to duplicate this for UFO CE?

Not the most important of enhancements, but I was still wondering if the possibility is there.

-[[User:NKF|NKF]] 01:41, 25 March 2010 (EDT)

== Save/Load shortcuts ==

Seb, would it be possible to enable shortcuts for the Save/Load in geospace & tactical (like F2 or F3) ? ;) except for saving in the final battle (from level 4 if remember) :)

Other things:
- rosvell incidents occured for me too often - 5 in the first month while there was no other alien craft movement detections

- option to disable mission briefing window with the only ok button :) supposedly for advanced users ;)

== Aliens continue using pistols&rifles ==

Hi Seb, sorry to bother you - i have been playing X-COM titles on and off for about 10-15 years now, and one thing always bothered me: Why do the aliens always swith to heavy plasma (or the Sonic cannon in case of TFTD) later on? It encourages the player to swith to heavy plasma too, if only for the free ammunition you almost drown in later on. Would it be possible to have the aliens continue using the plasma pistol&rifle after june/july? It would make using those weapons more feasible, getting ammunition during missions and not having to use elerium to produce it.

Another request (don't know if it is possible) - let the aliens continue using the abductor and the harvester for the respective missions. Later on, all you get are large scouts or even battleships doing those missions - getting some variety in there would make the endgame more interesting. You get to do 50+ battleship missions in a game, but only 4 or 5 with a harester/abductor. Those ships should see a lot more use during the missions they are "designed" for. The "[[MISSIONS.DAT]]" page says something about ufo and mission counters and their associated ufo-types - would it possible to modify those entries via the loader?

Regards, Equinox

== ALIEN MISSION DATA CLARIFICATION ==

According to
[http://ufopaedia.org/index.php?title=Talk:MISSIONS.DAT#Alien_missions_data_discovered_in_geoscape.exe_.5Bfinally_.3B-.29.5D link title]

I found it in TFTD. At offset 505448 (decimal) is starting (mission Probe). Next Interdicition/resource raid/infiltration/colony expansion/surface attack/Floating base attack

I understood what is 3-rd word. If You interesting - I can exlain

Seeing speeds of USO sub we can determine the mission of this USO sub even without transmission resolver - even in january 2040
Every USO sub in every missions (interdiction, colony, probe and other) have unique speeds and we can determine mission of USO on their speed
And we can determine what amount of times a sub touch down on his mission - because every mission has unique rule for touch down USO subs
And we can determine what amount of time USO Sub will touch down on their mission - because every Sub in every mission has unique and ALWAYS equal amoun of time to touch down (p.s. this time we can see in file Loc.dat)
Here - I attached file speeds.zip
[http://www.strategycore.co.uk/forums/Ion-Beam-Accelerator-in-What-file-t8099.html&view=findpost&p=95994#entry95994 link title]

3-rd word - it is reference to unique speed of each sub

4-th word - is time that precede to arrive next uso sub. In other word, in line ufo/c 0/0 if time = for example = 200 - it's time to arrive sub that indexes 1/0.
And where can I get time to arrive EXACTLY sub 0/0 is incomprehensible for me. I assume that this time contain at similarly word of last uso for this mission - but its'not truth because at some missions time in the line of last ufo/c = 2 half-hours and it's means that ufo/c 0/0 can to arrive at new month at 2 half-hours. It's true for Surface attack Mission but not truth for other missions.
I assumed that time in line ufo/c 0/0 - that time to arrive for NOT next ufo - and I assumed that it's time to arrive exactly ufo/c 0/0 itself. But many my tests (more than 100) denies my suppositions.
In example, at line ufo/c Cruiser mission Colony Expansion time in file =2. Cruiser in that mission arriving much more than 2 half-hours after Escort. Instead Fleet supply Cruiser in that mission arriving after 2 half-hours exactly after Cruiser.

'''Question - Where can I find time to arriving for ufo/c 0/0 for each missions except Surface attack mission ?'''

I am sorry for disturbance and will great thank for you for help.
:After the first month the game creates a mission per month, up to the 6th where it generates 2. I guess a mission starts immediatly, there is no timing added for its first ship. [[User:Seb76|Seb76]] 15:18, 30 April 2010 (EDT)

Mission starts not immediately. often time to arrive to survey ship (first sub) about 10-15 days.
1-st day of month at 0-00 we can see it time at Missions.dat but wants to know average time similarly such average time for other subs from alien data mission at executable if possible.

What is exactly 6-th? mission from Probe to Colony Expansion? or from January to June?
:Yep, 6th month. [[User:Seb76|Seb76]] 20:04, 30 April 2010 (EDT)

what happens after 6-th month June?

I so sorry for reminder and bother you, but don't you know it? ((

== Formules about Retaliation/Floating base attack mission ==

Hi

My great respect to you for you formules
I need few help. I am great thank to you in advance

Now I found alien data missions in TFTD (in a similar in EU ) and I ask generously to you to check 3 your formules in TFTD. Is these same or not?

1. After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours
:Xusilak is more knowledgeable than I concerning TFTD. I cannot help you here... [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

Formule 2 and 3 probably contins mistake. formule 'll have to have symbol > instead symbol <. Otherwise retaliation mission activates more often on Beginner diificulty than Superhuman difficulty. Is is strange.

2. A retaliation mission will be scheduled if RAND()*100 < 4*(24-difficultyLevel).
:There is indeed a mistake there. It's been so long I cannot remember if I got it wrong or just messed it up wikifying it ^^ [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

3. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from. The first UFO is scheduled in 100 half-hours (the value is taken from the table I speak of later at the bottom of this page).

And RND() - what values may has? from 0 to 1 or not?
:When I write RAND()*100, it just means a random number between 0 and 100. [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

I will be very thank for given help

== MISSIONS.DAT formula clarification ==

Hi Seb76. I've been having a discussion with Alexchamp and trying to interpret the formula you mentioned on [[Talk:MISSIONS.DAT]] about retaliation missions being scheduled after a shoot down. Namely: if RAND()*100 < 4*24-difficultyLevel

We mainly need clarification on the logical operator. Should it be less-than or greater-than?

As it reads now, it could be interpreted as though retaliation missions are generated more frequently on the easier levels. But if we treat it as >, then this means that retaliation missions are generated about (Beginner) 4%, 8%, 12%, 16% and (Superhuman) 20% (or 28% for TFTD) of the time on their respect difficulty levels.

If you could clarify that for us it would be great, thanks. - [[User:NKF|NKF]]
:Yep, I goofed up. Don't take everything I say as gold ;-) [[User:Seb76|Seb76]] 14:45, 30 April 2010 (EDT)

And I precise too one '''mainly moment'''. Whether there must be the opened bracket after the sign of multiplication? Because if no, then right interpretation formule in Superhuman example such: Rand*100>4*24=96-6=90 and that means that retaliation mission would be sheduled in 10 cases from 100.
IF there must be opened bracket then rand*100>4*(24-6)=4*18=72 wouid be sheduled in 28 cases from 100
What is this versions is right?

Then needs clarification for second formula yours. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from.
What logical operator there? should it be too greater-than or less-than?

You have found later formules about activation retaliation mission (if we shotdown alien craft)
Where exactly in assembler is subprogram that determines it? What address/offset of it?

== COLONY SUPPLY MISSION ==

As we know, When alien base built, Fleet Supply Cruisers with missions Colony Supply can to arrive to this base.

Where can I see (file/offset)
1) average time to arrive colony supply ship for examle/at least in XCOM-EU. As I said later, in responsible offset is time '''to PRECEDE to ARRIVE NEXT UFO SUB''' '''it's not''' time to arrive this sub
2) real time to wait arriving colony supply ship similarly times in file Missions.dat

According to [http://www.strategycore.co.uk/forums/Colony-Supply-ship-time-to-arrivin-t8103.html&view=findpost&p=96011#entry96011 Colony Supply - time to arriving]

If guesses of NKF is right, we need to formule of probability to arrive Colony Supply ship.
Can you to render courtesy with this formule?

Thank you very very great in advance
:I added details in the LOC.DAT talk page. The supply ship is spawned randomly and starts its mission. There is no "time to first supply ship" that I can see. [[User:Seb76|Seb76]] 15:11, 30 April 2010 (EDT)

Thank tou very much for this clarification. I found this offset in TFTD even. Changed, checked - it works.
You are greatly people!

== Roswell mission bug? ==
Hello, Seb76.

I've just had two consecutive games (meaning, I restarted the application and began a new game) where the same strange behavior occurred.

Both games had Roosevelt mission as the first one. It showed the window (type, terrain, UFO size) as usual. Afterward, whenever I clicked on it (to check mission conditions again), it showed a typical "hyperwave transmission decoded" window, stating race/mission type, etc. Needless to say, I had no decoder at this time, since it happened both times in the first game week.

I have a saved game if you want to take a look at it. It's completely reproducible, at least for me. You just click on the white cross and get this window.

Also, I'm using plain CE version with a "complete UFO patch" from StrategyCore. The saved game was not hacked in any way.

Cheers!
[[User:Rovlad|Rovlad]] 10:08, 30 April 2010 (EDT)
:Hum, I gave it some shots but could not reproduce your problem. Anyone experiencing the same problem? [[User:Seb76|Seb76]] 15:36, 30 April 2010 (EDT)

::Here's the [http://rovlad.nm.ru/GAME_1.zip savegame]. Let me know if it works fine for you. [[User:Rovlad|Rovlad]] 21:47, 30 April 2010 (EDT)
:Looks like the CRAFT.DAT entry is not cleared when a new craft is created and the offset 0x64 could be garbage till the craft is detected by a base/another ship. Since I bypass the detection when "crashing" a UFO, it is possible the "HWD detected" flag is set randomly, producing a full report. I'll clear the bit and we'll see if it corrects the issue, just wait for the next release. Thanks for providing the savegame BTW. [[User:Seb76|Seb76]] 14:22, 5 May 2010 (EDT)
::You're more than welcome. Fantastic job on the extender, keep up the good work. [[User:Rovlad|Rovlad]] 19:04, 5 May 2010 (EDT)

== ALIEN RACE SPAWN ==

Your post: In EU, the race is based off a lookup table starting at offset 0x46E53C (containing 300 entries).

Offset-0x46E53C is absent. Is one symbol odd?

Your posr:The table is made up of 10 entries lines.

It means that this bit of array has 10 rows width of 30 bytes. is right?

What is means this 10 entries lines? Can you copy 2-3 lines from exe and explain that means known for you offsets in line?As simiilarly as you done for alien data mission in file Missions.dat
Can you get more particularly answer about values it this array?(naturally if know it)
:0x46E53C is the address in memory. In the file it should be 0x6E53C (UFO Gold edition).
:The begining starts like this:
.data:0046E53C byte_46E53C db 0, 0, 0, 0, 0, 0, 0, 1, 4, 4 ; 0
.data:0046E53C ; DATA XREF: CreateAlienMission+15B�r
.data:0046E546 db 0, 0, 0, 0, 0, 1, 1, 4, 4, 4 ; 0
.data:0046E550 db 0, 0, 0, 0, 0, 0, 4, 4, 4, 4 ; 0
.data:0046E55A db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E564 db 0, 0, 0, 1, 1, 4, 4, 4, 4, 4 ; 0
.data:0046E56E RaceForTerrorMission db 0, 0, 0, 4, 4, 4, 4, 4, 4, 4 ; 0
.data:0046E56E ; DATA XREF: GeoPerformMonthlyActions+15E�r
.data:0046E578 db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E582 db 0, 0, 0, 0, 0, 0, 1, 4, 4, 4 ; 0
:till the end:
.data:0046E67C db 0, 1, 1, 2, 2, 2, 3, 3, 2, 4 ; 0
.data:0046E686 db 0, 0, 1, 1, 1, 2, 2, 3, 3, 4 ; 0
.data:0046E690 db 0, 1, 2, 2, 2, 2, 3, 3, 4, 4 ; 0
:As you can see, at the begining you'll get tons of sectoids (0), a few floaters (4) and even less snakemen (1).
:At the end, you'll get ethereals (2) one time out of two. Also note that for terror missions, the line is taken a bit farther than normal missions, which means that you'll get stronger aliens sooner in terror missions. HTH, [[User:Seb76|Seb76]] 13:36, 5 May 2010 (EDT)

Thank you greatly for your detailed answer ...
I want a few more precise ...
I right understand? I guessed That line 1 - is used for January mission Research? Line 2 - Jan Harvest? Line 3- Jan-Abduction Line 6- January Terror?
What define Line 7?
Line 8 - is February Research?

According to - Line 13 -Feb terror? Line 20 - March terror? Line 27 -April Terror? Line 34- May terror? that sequence and guesses is right?

And question 2) does affect score to choose the value among values in line? How differ choose values in line at the level superhuman and level beginner ?
If you know, naturally, I would be greatly thanks to you for this wonderful magic help.

== Research tree in executable ==

Do you know location (starting offset) of research tree in EU? and how much entries it contains ? and what means values within this array?

Very great thank in advance for this help to you
:The research tree is not stored as a data array but is a hardcoded sequence of "if this is already researched and that is also researched and such item is in the inventory, then enable this research". Modding this would require a complete reengineering, not just patching. Still feasible though. [[User:Seb76|Seb76]] 13:25, 5 May 2010 (EDT)

What is starting offset (ce version) of this hardcoded sequence? and what is latest offset of it? what is length of one sequence? If possible -what is structure of it briefly? (how much bytes to tech requirements, how much bytes to items requrements)

Thank you for this help '''VERY VERY GREAT'''
:As I said, there are no *sequences* but just a cascade of hardcoded ifs:
:[[Image:Research.png]]
:If you want to take a look, the function begins at address 0x446A0. [[User:Seb76|Seb76]] 07:28, 24 May 2010 (EDT)
'''
Seb76, you are GREAT GENIUS!!!! GREATLY RESPECT FOR YOU!!! THANKS FOR YOU VERY VERY MUCH!!!'''
I have found research tree in TFTD too with your help. Now I can do some changes in it.
Maybe do you know, how can I find subprogram that run 1-st day of any month in assembler code of game?
This subprogram determines new mission's month and terror ship route (in TFTD)
There is not in EU terror ship route, I know. But If you know and tell me - what is subprogram in EU that runs 1-st day of any month, I would be able to edit probability of terror ship route in TFTD.
Greatly thanks in advance to you dear Seb76!
:In EU, monthly actions start here:
.text:0043B9B0 GeoPerformMonthlyActions proc near ; CODE XREF: GeoIncrementDayAndDoMonthlyActions:loc_4420C1�j
:HTH, [[User:Seb76|Seb76]] 16:31, 28 May 2010 (EDT)

== Any way to slow down geoscape time? ==

Is there any way to slow down geoscape time progression on fast computers, esp. multiprocessor ones, where it is impossible to significantly slow it down using utilites like MoSlo and Turbo?--[[User:AVE|AVE]] 03:01, 5 May 2010 (EDT)
:Did you try enabling D3D? If you're drivers are configured to wait VSync, it should limit the game speed (well, if you use a CRT@120Hz it'll still be too fast I guess...). Also is it still too fast if you put it windowed? (enabling both D3D and D3D Windowed options) [[User:Seb76|Seb76]] 13:19, 5 May 2010 (EDT)
::Yes, both D3D and D3D Windowed are enabled. This is even more surprising, because it shows the same results on two different computers (Dual Core one and simple P4Celeron) with different video cards (NVidia and ATI). Both have vsync explicitly enabled. LCD@60Hz both. Also I've tried to use different combinations of Video Pitch, D3D, D3DWin and HQ4x settings - no luck. [[User:AVE|AVE]] 04:20, 6 May 2010 (EDT)
:Personally I've never been able to reproduce this "CE game running too fast" thing people keep harping on about. Perhaps I just have a different perception as to what "too fast" means.

:Anyways, I know [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's patched executable] includes a timer hack for the Geoscape, but I found that makes it run far too slow for my taste. Not sure off the top of my head whether it works with Seb's loader, either - you'd probably need to at the very least need to rename Mok's executable to replace the original in order to try it that way. - [[User:Bomb Bloke|Bomb Bloke]] 05:14, 6 May 2010 (EDT)

== Some problem with edit research tree ==

I want to add new 20-30 commands to research tree. I wrote this subprogram. How can I add it to game?
I tried to write "call sub" instead useless 5 bytes in subrogram research tree. I checked in IDA after it, all other commands is preserved.
And I placed my new subprogram after latest byte of executable file. But game is crashed.
I tried to place my new subprogram after all subprograms and before first byte of idata, but game is crashed too.
All indexes in subprogram was exactly.
in second case IDA displayed "sp-analysis failed".

Where and how can I placed my new subprogram that will be addition to current subpogram research tree?
:To add new code, you need to modify the PE header of the exe file accordingly. I'm not quite knowledgeable regarding the procedure (that's one of the reasons why I made a loader instead of patching the file directly) so you're gonna have to find help somewhere else on this one. [[User:Seb76|Seb76]] 16:36, 28 May 2010 (EDT)

== Update to IDA database ==

Hey again Seb76 :)

After a long time I've come back to your extender, dusted off my copy of VC Express, and decided I'd have another go at doing some UFO modding (don't ask how the first attempt went; it's not pretty! :p )

I'm assuming you've probably updated the IDA database since last time I asked. Would be extremely grateful if I could get the latest version.

Thanks for all the hard work, staring at assembly code all day is no joke! --[[User:K9wazere|K9wazere]] 18:07, 6 June 2010 (EDT)

Arf, didn't realise I could send you an email, so this new section on your talk page is a bit redundant now :p Oh well, maybe someone else will want the file too!

== Line of Sight Origin Points ==

Hiya.

A while back you mentioned the co-ords for the [[User talk:Bomb Bloke:Firing Accuracy#Firing Point Origin|firing point origin]]. The zpos is calculated according to the unit's effective height, and the x/ypos co-ords come from look-up tables depending on which way the unit is facing.

I was wondering, are these same two tables used for the purpose of line of ''sight?'' And by any chance could you find the formula for the initial LOS zpos?

Any help would be appreciated, as usual. There are many other obvious questions around this issue (such as where the ''end'' point for these lines is), though the origin would be a good start. - [[User:Bomb Bloke|Bomb Bloke]] 07:44, 24 June 2010 (EDT)

== Training Stat Request ==

Hi there.

In the Equipment screen where the Weight and TUs are displayed during battle, would it be possible to also include the current unit's number of Reaction shots, Hits, Psi attempts and (possibly) Throws? Possibly along the bottom in a horizontal string where there's room?

User talk:Seb76

2011-03-27T08:40:33Z

Mannon: /* UFOloader and Xcomutil */

Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.

(I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)

Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)

Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a "comment" and a "repeatable comment"? Or any of the several other types of comments, for that matter.

What exactly does "mov cs:word_102F9, ax" do? At first I thought it was just copying the accumulator into the data word at 02F9, but the "cs:" part is confusing. word_102F9 is 0, I think ("seg000:02F9 word_102F9 dw 0"). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.

Okay, one more and then I'll go to bed: what does "jmp short $+2" do? It looks like it just means "jump to next instruction", which is kinda redundant, but it could be "jump ''over'' next instruction", which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)

: The last two questions are actually general Intel 16-bit assembly ;)

: The cs in "mov cs:word_102F9, ax" is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The "seg000:02F9 word_102F9 dw 0" is probably from C default initialization, but could be from an explicit initialization to 0.
::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the "tiny" one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:
seg000:0140 mov dx, 157h
seg000:0143 push ds
seg000:0144 push cs
seg000:0145 pop ds
seg000:0146 mov ax, 2566h
seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR
seg000:0149 ; AL = interrupt number
seg000:0149 ; DS:DX = new vector to be used for specified interrupt
seg000:014B pop ds
seg000:014C call sub_1067A
seg000:014F mov dx, ax
seg000:0151 mov ax, 3100h
seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT
seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs

::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.

::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT

: "jmp short $+2" is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT

:: I can see several instances of this in music.com for simple "return value" functions. Most likely a "feature" of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)

Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.

(Holy crap. I just discovered that hitting "P" (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)

Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to "jmp short $+2" [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's "used to clear the cache, before going in or out of protected mode". Not entirely sure what clearing the cache does, but it's good to know.

Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a "ridiculous hacking ideas" section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)

:Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple "off by one" issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)

::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)

Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)
[[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)
:Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)
::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)
:Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)
:Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)

Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)
:Only flares can cast light currently. It is not a property in obdata, but a hardcoded "objectType=0x1B" check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)
:Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)
:Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:
struct {
short bulletVisual;
short shootSound;
short impactSound;
short impactAnimation;
}
Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)

: Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)

== Error running UFOExtender ==

Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:

C:\Games\X-com\UFO Defense\UFOLoader.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)
:Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)
::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)
:Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)
Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)
:My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)

My problem is the following: if I try to run the loader normally, a console window pops up for a few seconds then I get an "illegal instruction" error from NTVDM (and the window disappears, yet it's button remains on the taskbar until I kill the process). If I try to run it with DosBox however, I get "illegal command: UFOLOADER.EXE". Point is, I can't run this at all.--[[User:Amitakartok|amitakartok]] 11:27, 13 October 2009 (EDT)
:Looks like you're trying to use the DOS version here. Only the CE (windows) version is supported. [[User:Seb76|Seb76]] 13:48, 13 October 2009 (EDT)

Hi, is it in any way possilbe to run the Extender in Win98? I just set up an old machine with it and wanted to give it a try but as you said above, it won't work with Win9x. But is there a way to manually mod the game? I am asking becaus on my WinXP Machine the game often crahes in battlescape and that really sucks =(--[[User:Skaw847|Skaw847]] 19:28, 21 May 2010 (EDT)

== UFOloader and Xcomutil ==

Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!
Oh and btw when's the TFTD version coming out? ;-)
[[User:J'ordos|J'ordos]] 14:09, 24 July 2008 (PDT)
:You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)

:: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.
:The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.
:Edit: I added a "Video Pitch" bug fix to compensate for the incompatibility of the 2 loaders ;)
:: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.
:: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)
:Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)
:: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )
:I start the runxcomw.bat batch from a shell and I have to do a "ctrl-C" between phases . Maybe it is because I replied yes to "Do you want to see XcomUtil messages after combat?"
:: using the previous version I can enter battles just fine, but none of the UFOloader features work.
:Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied "no" to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)

:: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(
:About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a "slight" pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)

:: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&flags. I'll do some more testing. [[User:J'ordos|J'ordos]] 10:31, 27 July 2008 (PDT)

:: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J'ordos]] 10:37, 27 July 2008 (PDT)
:: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J'ordos]] 10:50, 27 July 2008 (PDT)
:Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)

:: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?
:I was talking about the "a program has cause xxx to close unexpectedly" (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the "ctrl-C" issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)

:: <3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)
:: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]
:: Whew, was quite a ride... Now, where's my ammo clip fix? ^^
:Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)
:::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)
::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J'ordos]] 05:01, 9 September 2008 (PDT)
: Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)
::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)
:::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)
:::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)
::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)
::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)
:Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J'ordos]] 12:58, 26 April 2009 (EDT)
::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)
:::I for one am a huge fan of XcomUtil, though I'm now also a huge fan of UFO Extender! I'm really hoping I can get the two to play nice. I was up until now playing a dos version, myself. Mainly because the version I bought years and years ago was the DOS version on CD and it still worked via dosbox, which also has several filters similar to your HQ4x. (Some run a little faster and I think they can run in a window while I can't get HQ4x to run windowed at all. I don't mind that so much, though the game runs noticeably slower when I run HQ4x and I prefer to run windowed these days so I can more easily multitask. Still I LOVE UFO Extender so I switched to the Windows version just for this.) Some of XcomUtil's features only work in the DOS version with split exe's because it goes back into the batch file and allows XcomUtil to play with things when switching from Geoscape to Battlescape and vice versa. But, it's not that big a deal for me. UFO Loader's feature list is more than robust enough to give that up. As for the sounds the Windows CE versions changed a lot of the sound effects. If you're used to this version then it's Np, but if you played the DOS version and got used to it then it's VERY off putting. Luckily it's easy to patch it back to the DOS sound effects. The "Enemy Unknown Extended" page here lays out an install that includes UFO Extender, the original DOS sounds, ect... It's a good place to start. Anyway, great tool. Now let's see if I can get these to play nice.[[User:Mannon|Mannon]] 04:40, 27 March 2011 (EDT) (I keep forgetting to sign things... too used to forums instead of discussion pages.)

== Heavy Laser Mod ==

Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots > 5 shots). A few units still standing? Bring on the next heavy laser.
Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though)
Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.
[[User:J'ordos|J'ordos]] 05:44, 31 August 2008 (PDT)

OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your "Full Auto" mode would be 100% TUs for 10 rounds and your "Burst Mode" could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)

: On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)

Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ.

Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz:

See if you can get the "hidden item", Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)

:Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:
:*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front
:*reduce accuracy even further when shooting out of sight (this was mentionned in another post)
:*change the damage model and reduce the probability that terrain is destroyed when shot
:*have a cooldown period where the weapon is not useable (not sure if it's feasible though)

::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J'ordos]] 16:27, 7 September 2008 (PDT)
:::Hm, I already cannibalized the unused "open" and "close" actions for the heavy laser mod, there is no more room for a new "hit" command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)

:OK, here is the last draft before I finalize:
:*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)
:*Each shot of a burst will reduce the accuracy (amount not determined yet)
:*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL
:If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)

Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)
:OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)

It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J'ordos]] 12:41, 28 February 2009 (CST)
:It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)

Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.
--[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)

:The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the "shortcuts" patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)

I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)

== Wish List please please please ==

=== New and Outstanding Requests ===

* Could we get TUs (in current/max format) at the inventory screen while on a mission? It would greatly help with swapping weapons among soldiers.

* Could we get little numbers [like on the screenshot of accuracy mod] showing how much TUs an action on the inventory screen would take? Some players (me, of course, included) can't really remember all that reloading from backpack or from a leg slot TUs. Also...

* a "drop all" button, maybe?

* Soldiers' positioning in Skyranger is very good... but with the Avenger it is not so pretty. The ones at the top are not the ones closest to the trap door. Chooseable patterns, maybe?

* Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.
: '''Save Equipment''' is under development, still some bugs

* Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.

* Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode.

: Has this been completed via the "Save Reserve Mode" feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair.

* Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:
** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.
** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix.
** Eliminate "infinite fuel" exploit for conventional aircraft.
* Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns "no line of fire". This would avoid a lot of the "hit the ceiling" issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)

* With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''
* Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.
* Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]].

* [[Wish List#Prior Recon of Battlefield|"Eye in the Sky"]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings.

* Grenades that [[Wish List#Warm Grenades|function normally]].

* Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].

* Enable native alien melee attacks within Alien Pets. The Floaters are pleading. (At the moment, Alien Pets+Big Brother means a crashed Superhuman Floater Large Scout costs 6-8 X-COM agents; corresponding crashed Sectoid Superhuman Large Scout is only worth 3-5 X-COM agents. Floater Large Terror Ship on just Big Brother : only one agent, and that was due to the top-of-stair pinning bug providing enough TU to do something.) -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Do something to help out the psi aliens as well within Alien Pets, as above. -- [[User:Zaimoni|Zaimoni]] 12:39, August 12 2009 (CDT)

* Would it be possible to change the master volume level in the game, or at least have a no sound option? [[User:Epiceuropean|Epiceuropean]] 00:26, 12 January 2010 (EST)

=== A few more ===

Do any of these take your fancy:

* Draw the Radar detection radii onto the map as a circle(s) around the base (also for moving aircraft?)

* Show All UFOs (Ultrawave Detector - like Show All Locations, but doesn't show Alien Bases, you still have to hunt for those).

* Sensible Ammo Recovery = add up all remaining rounds of ammunition at the end of a mission (in the ship, if Aborting), and recover a number of (full) clips equal to that number divided by the clip capacity (rounded down maybe).
: There's a reason I didn't turn Clip Recovery on, and it's that I guessed that it didn't work exactly as it's suggested here. If it did work like this, I would use it. [[User:Stubbs|Stubbs]]

* Implement tactical time limits for UFO Assaults/Recoveries. After a random period (within a pre-defined upper and lower time limit), the aliens leave. Pop up warnings appear at the end of each turn, saying the UFO engines are powering up. When the aliens leave, all aliens/items/equipment inside the UFO is gone - no loot, no score. Any soldiers still inside the UFO are considered MIA. The soldiers are ''captured'' in fact - score penalty worse than MIA? There must be one conscious alien inside the UFO for it to leave or attempt to leave. Maybe any live aliens outside are 'beamed' or 'tractored' inside the UFO, complete with their equipment? (E.g. the mission ends and you don't get score for them or their equipment either - just for the corpses and dropped loot).

* No Milk Please: After XCom withdraws from an Alien Base, randomise the base's location and make it hidden again. Just like what happens to the aliens after they fail to assault an X-Com base. Though you would probably still need to locate it within the same country or region so finding it again wouldn't take long I guess. Would it mess things up to move the base to a random part of the world?

* [[User:Spike#Tank mods|Tank Armour and Equipment Mods]]

But I should probably code this up myself, looking at your source code it doesn't look '''too''' hard. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

[[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

* Burning Zombies

It's more or less impossible to prevent Zombies from hatching into Chryssalids by killing the Zombies with fire, since fire does such a small amount of damage, and the requirement is that the actual killing point of damage is done by an incendiary. Apart from hitting them with an incendiary and running away, then waiting about ten turns for them to die (probably repeating the attack once or twice), this is only ever going to happen by blind luck.

It would be much more viable if the rule was (also?) that a Zombie which is '''on fire''' at the time of death would not hatch into a Chryssalid. This is not exactly easy either, but it is at least possible. It requires hitting the Zombie repeatedly with incendiary weapons until it catches on fire, then killing it right away with regular weapons (before the fire goes out).

A much easier version of this approach would be to say that if the Zombie is killed while it is '''in fire''', it does not hatch. But that is probably too easy.

A way to do this by hacking game files, without code changes, would be to increase the Zombie susceptibility to fire, to 200%. This would make incendiary weapons a viable way of killing them, as well as increasing the likelihood that the killing shot was an incendiary shot.

An alternative approach would be for the Zombie to have a chance of not turning into a Chryssalid, proportional to the percentage of health damage that had been caused by incendiaries. But that's probably too hard to track, it would require an extra/unused field in UNITREF.DAT.

[[User:Spike|Spike]] 13:12, 7 September 2009 (EDT)

* Fear of Fire

Apparently there is no morale effect from [[Incendiary#Damage|Incendiary damage]]. If anything, for humans, and maybe be for other humanoid aliens, fire should probably have a greater morale effect than ordinary damage, not none. A basic fix would treat fire damage the same as normal damage when reducing morale. A more complicated fix could add a weighting to this morale effect: multiply by the creatures susceptibility to fire (or reduce by its resistance to fire). Any creature or soldier that is immune to fire should not have its morale affected. Actually the affects of fire vary quite a lot (different aliens, different human armour types). Maybe this is why the designers didn't get around to implementing morale effects for fire, as it's a bit complicated.

[[User:Spike|Spike]] 13:40, 7 September 2009 (EDT)

=== Multi Stage Missions ===

Between each stage of a multi-stage mission:

* Send all artefacts (non-usable items), corpses and recoverables back to base
* If possible, remember the score for these items, and apply it to the score at the end of the mission
* Alternatively, pop up a score window between the mission stages, and apply the score then?
* Gather all loose usable equipment into the "equipment pile" for the next stage
* Or possibly re-run the Equip Screen between mission stages, again gathering all loose usable items into the equipment pile first.
* Keep an 80 item limit on what you can take into the next stage
* Prune down to the 80 item limit using some sensible rules, not sure what exactly.

This is of limited use in X-Com EU but would be much more use for TFTD, one day. EU has only one multi stage mission, and it ends the game, so only some of these points above will be relevant.

[[User:Spike|Spike]] 20:54, 2 September 2009 (EDT)

=== Even More ===

Tremendous work, you've pretty much made the game worth playing again. Best work since Xcomutil. As with everone else, I have a few requests. [[User:KingMob4313|KingMob4313]] 23:59, 12 August 2009 (EDT)

: Ability to change damage modifier. Right now the damage runs from 0-200% of damage values on the weapon. I'd love to see a way to change it to 50-150%, 75-125% or the like.

: A modifier to increase or decrease the explosion radius modifier. Right now the radius is either keyed to the explosive or to the explosive damage. I'll investigate it further. But it would be nice to have a very small radius, but high powered explosive for use as a breaching charge.
:: There is a "crimping" function on some of the explosions already so it might be possible to exploit that. Check the [[Explosions]] page. [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

: A modification of the range based accuracy. One handed weapons have a shorter range, to the point that even their aimed shots have an effective range, two handed weapons have a further range (and no aimed shot effective range) and really heavy two handed weapons have an even further range.

: Ability to enable the Burst fire (5 shots over 3 picked spots) and/or the full auto mod that is on the heavy laser on other weapons (set by a flag).

: A modification so that on the alien's side first turn, they do not have their full time units in reserve for reaction fire. Nothing like getting shot 3 times from the same sectiod after missing ONE shot on them.

:: You could always wait a turn before you open the door. :) [[User:Spike|Spike]] 14:46, 24 August 2009 (EDT)

::: Good point, I should be doing that anyways.

=== More Exploits to Close ===

* [[Exploiting Mind Control#Exponential Mind Control|Exponential Mind Control]]

Probably the worst single exploit in the game. What is needed is to disable any mind control actions for a Psi Amp, if the unit holding the Psi Amp is currently mind controlled.

Also a general mind control bug/exploit fix for:

* [[Exploiting Mind Control#Exponential Mind Control|Civilian Traitors]]
* [[Exploiting Mind Control#Exponential Mind Control|Resurrect Zombified Agents]]
* [[Exploiting Mind Control#Exponential Mind Control|Zombie's Permanent Control of Aliens via Stunning]]
: Above 3 bugs are fixed by '''Hostile Civilians''' fix.

* Probably many other missing/MIA-type bugs

These probably all arise from the daft decision to save a single byte (or even bit), by not recording separately the current vs default "side" a unit is on. The game only tracks the "current side". Consequently when mind control ends, the game often makes dumb decisions as to what side to "restore" the unit to. We could use an unused byte to track the default "side", but that would require overloading a presumed "unused" field and that could be risky. But actually we can always deduce the "default side" from the unit type: XCom for soldiers and tanks, Neutral for Civilians, Alien for everything else. So what is needed is just an end-of-turn check to restore everything to its correct side, based on its unit type. Actually it's slightly complicated by alternating turns. You need to update all (originally) Alien units at the end of the Alien turn, all originally XCom units at the end of the XCom turn. You might also need a special end-of-game update, to avoid the MIA-type bugs. [[User:Spike|Spike]] 12:22, 26 August 2009 (EDT)

: AlienSWP.py implements turnswapping via mind control, like XCOMUtil. Handling the alternating turns, as you described, is necessary to make mind control work properly (a mind-controlled alien remains with X-COM during the alien turn, and so on).

: I would assume that the original programming team had a coding policy forbidding both bitfields, and emulating them with bitwise shifts. That's really the only way I can explain most of the idiosyncrasies of the file format. [[User:Zaimoni|Zaimoni]] 12:07, 26 August 2009 (CDT)

=== Soldier Colouration ===

Not the most "practical" request in terms of changes to gameplay, but still something I feel would be pretty cool if incorporated. Basically, the option to have the battlescape engine display soldiers according to their race/hair colour, as according to their inventory screens, [http://www.strategycore.co.uk/forums/post-a1669-.html like this].

The stored tactical [[PALETTES.DAT|palette]] is made up of 16 groups of 16 colours (256 total), in this order (though the last 16 colours are replaced with a grey-scale shade list at run-time, similar to the other fifteen groups - refer to the page on palette data for more info on that):

[[image:5_BattleScapePal.Png|center|frame]]

Solders are drawn using colours from three of these groups: One for their clothing (x50-x5F for overalls/power armor, xE0-xEF for personal armor), one for their skin (x60-x6F), and one for their hair (x90-x9F). Flying suits use a few extra colours, but they don't matter for the sake of this explanation (they don't show hair/skin anyways).

With my [http://www.strategycore.co.uk/files/index.php?dlid=686 battlescape editor] I incorporated a feature where you could have the program redraw units on the fly (as per the screen shot), changing just the hair/skin colour. For example, to check to see if a colour index was supposed to represent hair, it simply checks if "(''value'' & xF0) == x90", and if so, it'd add or subtract a certain figure to achieve the desired colour.

Well, there's a bit more to it then that (males in personal armor have a different hair colour already), but I'm sure the basic concept is obvious to you by this point. If you're interested, you can see a sample function in a file included in my toolkit - "bb_tact\UnitDrawer.java", line 384. It's not exactly well documented, but if you check the hair/skin arrays it refers to, it should be fairly obvious what it does. While the program is running, the "characteristics" variable is set to "true" by tapping C on your keyboard. Of course, I've no idea how the actual game deals with drawing soldiers, but I assume it decompresses every [[Image_Formats#PCK|PCK]] image every time it wants to draw it, same as my code does.

- [[User:Bomb Bloke|Bomb Bloke]] 09:46, 4 May 2010 (EDT)

=== See Also ===

*[[Wish List]]
*[[Known Bugs]]
*[[Exploits]]

== Completed Items - Thanks Seb! ==

See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]

* Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault.
:The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:: Completed with the "Keep Base Navigation Tables" option.

* Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the "Roswell Incident". Crash site would be automatically detected & UFO would have random damage.
:Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)
:Update: feature almost complete, time to bake a new version ;-)

:[[Image:Roswell.png]]

:There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)

* Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)

: Fixed with "Faster base defence sequence" option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)

* Multiple Radar - Fixed.

Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]
:As I said, I used about the same as in you BaseFixer script:
float shortDetection=pow(0.9f,smallRadars);
float largeDetection=pow(0.8f,largeRadars);

*(short *)(&base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);
*(short *)(&base[0x12])=(short)((1.0-largeDetection)*100.0);
:However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)

* Accuracy reductions for long range snap and auto fire - Fixed.
* Aircraft always ready for mission despite re-fuel/re-arm status - Fixed
* Stack up base build orders in advance - Implemented
* More smoke and fire - Fixed
* Blaster drift and waypoint bug - Fixed
* Stats visible during Equip phase - Implemented
* Melee combat (bludgeoning) with any weapon - Fixed
* With "Council Funding Only", allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any "income" (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with "Council Funding Only". Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)
* Close Down Exploits
** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed

* More video options. In particular, an option to put padding at the top and the bottom of the screen to preserve the aspect ratio on a 4:3 monitor. Maybe it's just me, but stretching the original height of the game to fit a 4:3 screen makes the Battlescape look weird. (Actually, if you update the source code link, I could try to do it myself. The current source doesn't seem to include your more recent changes. --[[User:Mikawo|Mikawo]] 20:30, 12 August 2009 (EDT))
** Thanks for uploading the new source code. I managed to add the letterboxing that I wanted. If you wanted to make it an official feature I could upload the updated files. And I don't think I said this before, but thanks for the great loader! --[[User:Mikawo|Mikawo]] 18:40, 14 August 2009 (EDT)
:Go ahead and upload/PM me the file (d3d.cpp I presume?), I'll gladly incorporate your modification. [[User:Seb76|Seb76]] 19:14, 14 August 2009 (EDT)

* Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].

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

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

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

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

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

::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences.

::It will be interesting to see if patching out all 4 calls eliminates "impact" IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but "impact" damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff!

::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)

* Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.
[Utilities]
Run Utilities=0|1
Run before battle="xcomutil ..."
Run after battle ="xcomutil ..."
Run before base screen="xcomutil ..."
:The above works perfectly. [[User:KingMob4313|KingMob4313]] 00:05, 13 August 2009 (EDT)

* Allow scrolling the map with the keyboard. "WASD" as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.
:Fixed via Keyboard Shortcuts - and configurable too.
-- Sorry, I am having trouble finding this addition. Is it in the newest version? I can't see where to configure it if so.

== Warm Grenades ==

It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them.

This could be implemented by an extra bit of logic that increments the "Turn When I Will Explode" field by +2 if the grenade is being held/worn when the Explode check happens.

For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE.

Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)

== Facility maintenance cost bug ==

Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)
:I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)
::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)
:Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)
:Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)
::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], "Blind spots around the corner".
Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground?
:Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.
:*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...
mov esi, 11h
...
loc_44004C:
dec esi
mov word ptr [esp+3Ch+elementsArray], 0
jnz short loc_44004C
:*ecx is initialized to point to the maintenance cost data (nothing wrong here)
mov ecx, offset baseElements.maintenance
:*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):
movsx eax, ax
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea eax, [eax+eax*4]
lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000
:we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].
:*then after each row, we have this:
add ecx, 10h
:which explains why the cost changes for each row.
:I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).
:The fix required two patches:
:*remove the incrementing of ecx for each row
char nop[]={0x90,0x90,0x90};
PatchInPlace(0x44066E,nop,3);
:*make a working inner loop:
char patch[]={
0x03, 0xc0, // add eax,eax
0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element
0x0f, 0xb6, 0xc0, // movzx eax, al
0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining
};
PatchInPlace(0x440651,patch,13);
:this takes care of the nonsense code
inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type
lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented
xor eax, eax ;discard the address we just computed (!)
mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)

Very interesting stuff! By the way I'm playing a "Roswell" game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)

==Grenade Status Indicator==

Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go?
:Hmm, I'll see if I can find something

== Keyboard Support ==

Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)
:sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)

:: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT)

Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....
Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)
:I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)

----

First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already.
:Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)
BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).
:There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental.
A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again.
:I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.
Another suggestion is that I also understand that 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?
:At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.
If you psi control a human 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?

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).
:These two are on my secret todo list ;-)
::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)
80 item bug on base defense mission
:May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...
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!
:I think this is a known issue with LOS, not sure though
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).
:I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look
This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc.
:Hmm, you do know I don't have the original source code available, don't you? :p
Any plans to work on Terror from the deep?
:I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)

Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)

== Inventory screen ammo weight bug ==

I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)
:Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)

:: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)
:Does not ring any bell. Any link?

There are major issues with your current weight calculations. I'm not exactly sure how it was occurring, but repeatedly messing around unloading and loading weapons, switching clips from the ground them putting them back in... at least one of these functions causes 'phantom weight' to be added to the soldier (e.g. strip them bare and they are still carrying a load). This was happening by 3 units of weight at a time; the weight of a clip. It's so bad that I managed to get 18 phantom weight units on a soldier before getting bored. Occasionally, 3 units of phantom weight would be removed again! It's hard to tell if this was in the original game, due to the lack of weight display in the inventory screen.

Edit: I've worked out what's happening. Add a loaded weapon to a soldier, unload it, and remove the ammo and gun: this ''removes'' 3 phantom weight units. But, add an unloaded weapon to a solider and load it... this ''adds'' 3 phantom weight units. [[User:Stubbs|Stubbs]]
:This is a genuine bug because they forgot to unassign the clip of a weapon when you drop it. Also the default weapon's clip is not initially assigned to the wearer so if you unload and reload the clip, your soldier weights more. [[User:Seb76|Seb76]] 13:27, 3 February 2010 (EST)
:: So is this impossible for you to override and fix? It's really irritating... I've edited lots of item weights, but I guess I'd have to make ammo light and guns heavy to minimize the effects of this bug. [[User:Stubbs|Stubbs]]
:::I second that, it would be great if this could be fixed. [[User:Rovlad|Rovlad]] 17:45, 13 May 2010 (EDT)

== Equipment issue ==
Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)
:There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)

== Request For UFO PS Explosion Offset ==

Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:

Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)

I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)

== Great new features ==

Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)

:OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap>auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades.

:I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:
:* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units
:* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien
:* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it?
:* In night missions, even with Big Brother <strike>and View All Locations</strike> set, I could only see what my guys had illuminated & seen.
:* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)
::The "Hack" section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]
:* With Alien Bases and View All Locations, the X-COM bases show up as pink.
:* It wasn't obvious to me that I needed to set e.g. "Initial Alien Bases=20" rather than just "Initial Alien Bases=1". I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)

:Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission.
:I have not developed Heavy Laser yet, <strike>nor beaten up any aliens in melee,</strike> but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)

:: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it.
:::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]
::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)
: I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:
::Glad you're having fun :-) [[User:Seb76|Seb76]]

::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader.
: Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)
::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]

== Base Disjoint Bug Fix ==
A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. <strike>It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)</strike>. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).
: Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]

I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)
:Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)
:Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]
Yes I doubled checked a couple of times. I set the flag as

Base Disjoint=1

Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)
: Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!

== A couple of bugs to report ==

Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message "The Alien Food UFO was on an Damage Capacity mission in Power Sources." All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.

The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)
:Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)

Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)

:I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)

::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the "crafts always ready" option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)

Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)

:"Raiding" ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: <pre>Zone Discovered=Intel found out that the %s UFO was raiding %s</pre>If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)

:Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)

::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)
:Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)

Some more comments:
# Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add "usage" comments to the .INI file?
# Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!
[[User:Spike|Spike]] 13:20, 2 January 2009 (CST)
:What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)
*Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game

:: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)

Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)
Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)

== Glitches with Alien Pets ==

OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!

* If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?
* It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:
** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!
** Terror units can also equip weapons in their "hands". Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)
* I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly.

This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):

* When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error?

Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!

[[User:Spike|Spike]] 19:04, 5 March 2009 (CST)
:My pleasure. It was the very reason I allowed it in the loader in the first place!
:FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)

:: Alien reaction fire works fine for me within Alien Pets. -- [[User:Zaimoni|Zaimoni]] 12:41, August 12 2009 (CDT)

I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy ->> no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!
So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this "retreating" a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)
:Thanks for the support, I'm bored of the "the stuff does not work with ET" thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)
::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)
:Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)
::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)

== TFTD Door problem ==

Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)
:Hi Talon81, what do you mean by "other patches". Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)
:Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)

Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).

If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)
--[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)

: I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)

:Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)

== Initial Alien Bases ==

OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)

By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)
:Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)

Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)

:OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)

Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)

== Won't work on my rig Vista+CE version ==

Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.

My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.

* http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG
* http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG
--[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)
:Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):

[[Image:Dxwnd.png]]

[[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)

Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?

http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)

[edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.

:I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:
:[[Image:Scale2x.png]]

:When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)

::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?
:I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)
:Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)

The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. <3
:Uploaded a new version, you need to add a "HQ4x=1" line under the "Mod" section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)

Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)

Now the question is, how do you use DXWnd with the loader?
[[User:KingMob4313|KingMob4313]] 11:02, 12 August 2009 (EDT)

==Works but won't multitask==

Target system: prefab HP Vista with global data execution prevention. Problem is the same native, with D3D, and/or with HQ4X. (The two do combine nicely, visually, but a bit laggy for my tastes).

ALT-TAB terminates all further screen display on restore; the sea of blackness continues until Task Manager is used to kill the application, at which point D3D admits that it has "lost the device". (This is after the improved error reporting patch. Before, 0xc0000005 as Data Execution Prevention takes over.)

-- [[User:Zaimoni|Zaimoni]] 12:27, 12 August 2009 (CDT)

: Solved on Win7 for the most recent version: Program Properties dialog has an "unblock" button. Unblocking allows the program to survive being alt-tabbed away from. -- [[User:Zaimoni|Zaimoni]] 22:03, 24 June 2010 (CDT)

==Heavy laser mod==
My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]

:Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)
:Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)

::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)

::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)

I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)
:Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)

Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)

OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)
:I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)

I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)
:Hum, are youe using the "dev" version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)

Not sure what you mean by "dev" version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)

Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)
:That's great ;-) By dev I was refering to the "dev" version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)

Hi Seb, I've been playing the UFO series since the beginning but just joined this wiki. I've tried just about every mod there is for these games, and I must say, yours is one of the best as far as creating a "more complete" and stimulating game experience. My question is in regards to your "Heavy Laser" mod. I liked what you did by creating new "abilities" for the weapon with the Full auto and Burst fire mode, but every time I play I can't help but think that it just doesn't belong to the Heavy Laser as a weapon. I always envisioned the Heavy Laser as more of a long range "Sniper" support weapon, and I like the mod that the X-ComUtil added that gave the Heavy Laser a new life by increasing the accuracy and damage of the weapon making it one of the best Sniper weapons available (even if it is heavy to lug around) as well as finaly giving my troops a greatly needed new weapon for disposing of those pesky sectopods (on any difficulty). I do, however, think that the new fire modes (full auto and burst fire) would be a perfect addition to the Auto-Cannon. The in game image alone has always brought to mind a "mini-gun" type weapon that should be capable of very rapid fire, but at the expense of accuracy due to the encumbering nature of the beastly AC. I never liked how the AC seemed like a generic Heavy Cannon with less damage and only the added auto shot function. Also, I always wondered why that weapon even had an "Aim" function. Who's going to sit there trying to carefully aim a Gatling Gun? Nobody... that's who, you use a weapon like that for mass devistation and shock value, PERIOD! This is why I think that your mod to the Heavy Laser should be reconsidered for the Auto-Cannon. I think, at the very least, it will give people a reason to use the AC in the mid to late portion of the game, and being that it still has weak stats compaired to other weapons, it's not going to be overpowered or infringe on the use of specialty weapons (I think the Heavy Laser with full auto and burst fire is a little un-balanced due to its considerably higher power). If you don't agree that's fine, but since I'm not very knowledgeable about game programing, I was wondering if you could at least give me a hint on how to create similar weapon functions for other weapons, cause I'd like to at least try it out for myself. Thanks for any help you can give me and keep up the good work, you're mod is awesome.

== REng UFO with IDA ==

Hi Seb =)

I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.

So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).

Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.

I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.

My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).

Any advice is deeply appreciated mate =)

XCom forever!
--[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)
:Hi k9,
:Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.
:For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...
:Good luck with your project,
:[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)

:::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...

void InsertCall(int dst, void *func)
{
DWORD oldProtect;
DWORD *pOffset=(DWORD *)(((char *)dst)+1);

VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&oldProtect);
*(char *)dst=(char)0xE8;
*pOffset=(int)func-(int)dst-5;
VirtualProtect((void *)dst,5,oldProtect,&oldProtect);
}

::: This calculation here is interesting:

*pOffset=(int)func-(int)dst-5;

:::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).
:The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).
:The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)

:::Can you suggest some good reading material to better understand this? Cheers!
:::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)
:You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the "UFO Defense" process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)

== D3D ==

If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has.

I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)
:You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)

Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)

OK I ran the dxdiag utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)
:Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.
:Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)
Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)

D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J'ordos]] 19:09, 8 August 2009 (EDT)
:edit: forgot to mention, I have directx 9.0c installed and dxdiag reports no problems. I have a Geforce2 MX *blushes*
:Do you know if this card supports non power of two textures? [[User:Seb76|Seb76]] 05:10, 9 August 2009 (EDT)
::no idea, but since your new version works fine with the D3D option on I assume it doesn't :) [[User:J'ordos|J'ordos]] 11:38, 9 August 2009 (EDT)
:That's great. Spike, does it fix your problems too? [[User:Seb76|Seb76]] 16:04, 9 August 2009 (EDT)
::Sorry for the late reply - yes that fixes my problems too, D3D is working fine now. Thanks, [[User:Spike|Spike]] 15:55, 26 August 2009 (EDT)

== Save equipment ==

Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:

*1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of "invisible" equipment!
*Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips.
*The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.
*Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment.

Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked?

Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)
:Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.
:The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?
:As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.
:I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)
::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a "before" and "after". [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)
:In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)
::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns & ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)
:OK, I'll have a look at this, thanks for the effort.
:Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the "i/b" one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)
::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)
::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)
::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)
:I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)
:: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)
:Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)
::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)

Hmm more problems with Save Equipment. Ammo of all types seems to disappear. Eg I have 6 pistols and 6 pistol clips on the craft, but the Equip screen just gives me 6 empty pistols. Other weapons are short of ammo too. Is the Save feature perhaps "remembering" empty weapons (or loaded weapons) and somehow eliminating the clips. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)
:This looks like an issue with ''UnloadClips''(). I noticed that the clip object's ''loaded_into'' is set to 0xff, but the ''not_loaded'' remains as 0. The game may see this as the clip still being loaded in an object, so the clip effectively disappears. --[[User:Mikawo|Mikawo]] 11:05, 19 August 2009 (EDT)
::This is possible. The wiki is wrong on these 2 fields BTW: it is in fact just one field (loaded_into signed extended to 16bit). I'll have a look at that. [[User:Seb76|Seb76]] 14:33, 19 August 2009 (EDT)

I think Mikawo is right. UnloadClips() should look something like this:

void UnloadClips()
{
obpos_dat *pObPos=pObpos_dat;

for(unsigned char i=0;i<170;i++)
{
if(pObPos->itemType != 0xff && pObPos->not_loaded == 0 && IsXComItem(i))
{
pObPos->loaded_into=0xff;
<big>'''pObPos->not_loaded=0xff;'''</big>
}
pObPos++;
}
}

Quite a few other functions in '''equipment.cpp''' use this check '''pObPos->not_loaded == 0xff''' so it is important to set this flag just for UFOExtender, regardless of whether the game needs it set (which it probably does). Eg items unloaded by UnloadClips will thereafter fail to be found by GetFreeItem, during execution of LoadSoldierEquipment. That probably explains the problems observed.
[[User:Spike|Spike]] 15:24, 26 August 2009 (EDT)

:I did some rework based on that. Do you have other problems? [[User:Seb76|Seb76]] 16:08, 30 August 2009 (EDT)

::Thanks Seb. This seems to be working mostly ok now. Some remaining smaller issues I have seen:

::* The weight calculation is so accurate, it is more accurate than the unmodified game. So the "weight free ammo" (the first clip loaded into a weapon, before the user takes any action in the Equip screen) is no longer weight free. Not sure if you want to "fix" this or not? It is debatable. Really, you have fixed a bug. But the normal game behaviour has changed. Maybe make the "weight free ammo" optional?
::* There is a weird glitch. If I unload a weapon, put it and the clip on the ground seperately, that works fine. But if I pick up the clip '''directly from the ground''' and load it straight into the weapon, then drop the weapon, the weight of the clip is still shown on the soldier. And actually the same thing happens with a clip that is first moved into the soldier's equipment. So in fact the problem is that a clip loaded into a weapon, doesn't get removed from the soldier weight when the weapon is dropped onto the ground. It happens even if the clip is pre-loaded by your routine.
::* Still outstanding - you can't use the right arrow to move onto a second screen of equipment. So you can't have more than one screenload of equipment on the ground. Or maybe you can, if you start the Equip screen with more than one screenload on the ground - I didn't check that.

::[[User:Spike|Spike]] 13:10, 1 September 2009 (EDT)

== Glitch with Alien Pets and Big Brother? ==

Hi Seb. I was trying to do some initial research on the idea of [[User:Spike#Tank mods|Tank mods]] but it looked like these 2 useful features of your Loader, Alien Pets and Big Brother, have both stopped working. Can you test this, on the latest version? I'm using a very recent version (last 2 weeks) but not the absolute latest as I have internet download problems.

Also, have you seen this new Wiki article: [[Enemy Unknown Extended]]. It is a package including your loader plus a few other odds and ends.

cheers,
[[User:Spike|Spike]] 11:16, 17 August 2009 (EDT)
:My mistake, I commented out that part of code a while ago and only recently noticed that. It was corrected one or two versions ago.
:The article is a good idea, it should allow less techies an easy start. [[User:Seb76|Seb76]] 13:51, 17 August 2009 (EDT)
:: OK cool yes the Hacks are back in place, thanks. [[User:Spike|Spike]] 20:34, 18 August 2009 (EDT)

== Alien Bleeding ==

Test results:

* 1-unit and 4-unit aliens can be healed by anyone (alien or human) holding a Medkit
* 4-unit aliens can be healed by standing in any of their 4 squares
* 4-unit aliens can only be healed while they are stunned. Pointing to their "control" square does not seem to work.
* 1-unit aliens can be healed either while conscious or while stunned
* Wounds on aliens can be correctly seen with Medkits
* The Medkit display shows a human silhouette regardless of the alien type, of course
* Healing aliens with Medkits, stops them from dying of wounds (not 100% tested but seems to be true)
* Aliens (large and small) seem to lose the correct amount of Health per turn from Wounds
* Aliens with wounds that are not treated, eventually die (not 100% tested but seems to be true)
* A Mind Probe can see if an alien has Wounds.

Anomalies:

* I had a lot more reports of Reapers dying than I would expect. I would not have expected any to die, and I had 3 reports of death by wounds. Even heavily wounded Reapers take a long time to die. In my test I was only shooting them with Pistols. Maybe there is a problem with the reporting? Maybe the death of the same Reaper was reported more than once? More testing needed on this.
:I wonder if Reapers are receiving wounds on all 4 sections when hit by explosives (I don't know which weapon you were using). They really shouldn't, although I'm unsure how you'd get around this. If possible, put a cap on the maximum number of wounds something can ever have (perhaps 6). You could argue their multiple hearts really empty their blood out quickly, but I don't think fatal wounds should ever become more dangerous than burning alive.

:: Well, why not: hit four times by one explosive, check for incurring fatal wounds four times. -- [[User:Zaimoni|Zaimoni]], 13:49 Sept. 6 2009 CDT

* Question: should the death of an alien by wounds be reported, or should it die silently? Did I only see these messages because I was using Alien Pets, and so they were on "my" side?
:Regarding death reports, I enabled the dialog for aliens/civilians (it usually only shows up for xcom operatives) to help in testing. The final version will not show them. [[User:Seb76|Seb76]] 14:10, 3 September 2009 (EDT)

Caveats:
* I used the Alien Pets, Big Brother, and Alien Inventory hacks to do this test. I also hacked a save game to give me Pistols, Medkits, PsiAmps and Mind Probes. [[User:Spike|Spike]] 16:03, 3 September 2009 (EDT)

To Do:
* Test if aliens (small, large and mechanical) suffer from [[Fatal Wounds#Other effects of Fatal Wounds|other effects of wounds]], e.g. penalties to Energy, Accuracy, Time Units
* Do Cyberdisks, which have no legs or arms and probably no head, only ever receive Torso wounds?

=== Mechanical Bleeding ===

* Question: Do Cyberdiscs and Sectopods receive Fatal Wounds? I'm wondering whether an unconscious Cyberdisc is safe to be around. Even if they didn't explode, Fatal Wounds would be stupid for a robot. If XCOM tanks can't end up leaking fuel and sparking dangerously, neither should enemy robots. [[User:Stubbs|Stubbs]]
: I think you can make a case for tanks and robots having "wounds", i.e. damage that gets progressively worse by itself. You can even make a case for them being "stunned" - temporarily non-operational. You can even make a case for it applying to alien robots but not to X-COM tanks, since alien robots all have some degree of organic component (which is why they can be Mind Controlled). But I still think you are right, neither effect should apply to machines, whether alien or human. As for your question, see the tests below:

Cyberdisk Bleeding Test Findings:
* Cyberdisks take Wounds (with Alien Bleeding option enabled)
* Cyberdisk wounds can be healed (though only after unit is stunned)
* Cyberdisks lose health from wounds
* Cyberdisks can die from wounds
* Cyberdisks don't seem to explode when they die from wounds ("has died from wounds" popup)

Cyberdisk Bleeding TestTest Caveats:
* Same caveats as previous tests (above), plus:
* The Cyberdisks were modified from Reapers using xcomutil :rpl
* Some Pistols were changed to Laser Rifles using xcomutil :chg
* (xcomutil was not installed in the game directory however, it was used from another location)
* The stats (Armour 34 all round, Health 120) appeared normal for Superhuman
* However the Cyberdisks seemed to fall too easily to Laser Rifle fire (e.g. 1 hit)
* Also, they seemed not to explode as often. This was because they were often stunned.
* Hard to tell in-game whether a Cyberdisk is dead or stunned. The graphic is the same, you can't use a Mind Probe, nor look on the ground, nor even check by changing sides.
* Actually there is one way to tell: stand over it and use a Medkit. Didn't think of that. [[User:Spike|Spike]] 08:22, 5 September 2009 (EDT)

:Thanks for finding out, Spike. Autopsy text shows you are right about the Sectopod( but not about the Cyberdisc) having biomechanical components, but it's not like there are gallons of blood pumping around the thing to gush out. One thing: did you check both conscious and unconscious death-by-wounds for the Cyberdisc? [[User:Stubbs|Stubbs]]
::No problem Stubbs. I didn't deliberately test this, but I had numerous deaths-by-wounding while unconscious and I think at least a few while conscious. I believe those that died while conscious, exploded. (I think this is the basic rule for Cyberdisks. If they are stunned, they don't explode. This typically happens with stun weapons but can also happen with regular weapons, if you are lucky.) [[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)

* Seb76: maybe robots receiving wounds was an oversight, or maybe you really do want robots to take wounds. In either case, it would be nice to have a separate option for this. My arguments against robot wounds are pretty simple: tanks do not receive them, the bled-out dialogue "X has died from a fatal wound" sounds silly for a robot that was never alive, and finally that a Medkit should not be able to heal a robot.
: It's reasonable that alien mechanisms (Sectopod, Cyberdisk) would not suffer from wounds. Possibly also Zombies should remain immune to wounds? From a note Seb made elsewhere, I think the UNITREF.DAT "can be wounded" flag is the same as the "can be stunned" flag. Wounding is probably prohibited globally for aliens, by an override somewhere in the executable. Seb has probably removed this override, unconditionally. To remove the override more selectively, I suspect Seb would need to put a logic test in the code, to check the alien type. .[[User:Spike|Spike]] 20:54, 5 September 2009 (EDT)
::There was a check for ownership that I simply removed. Next version will have an explicit check for robots/chryssies/zombies not to bleed. [[User:Seb76|Seb76]] 12:29, 6 September 2009 (EDT)

* If you want a sense of "the Sectopod's leg got damaged" or even "the tank's track was broken", perhaps robotic units could be 'wounded' by damaging max TUs.
* If, however, the above won't let weapon usage TU %s recalculate as TUs are lost (i.e. the units lose firing ability as well as walking), then certain values of Energy with the correct Energy usage modifier could emulate loss of speed without losing firing ability. Since Energy is returned at a rate of 1/3 of TUs, these units could have an Energy value of (slightly less than) exactly 1/3rd of their TUs. Their energy usage modifier is then changed to allow this small energy value to usually suffice. Now, when Energy is damaged, the units will be permanently slowed, but their weapons won't be affected. [[User:Stubbs|Stubbs]]

=== Zombie Bleeding ===

Zombies that bleed to death don't seem to turn into Chryssalids. As discussed above, it might be better to disable wounding for Zombies. (Death by wounding for Zombies was already possible, without this fix, if the Zombie was mind controlled, wounded while mind controlled, then released back to Alien control.) [[User:Spike|Spike]] 21:07, 5 September 2009 (EDT)

== Hostile Civilians ==

This fix also seems to prevent:
* [[Exploiting_Mind_Control#Zombie's_Permanent_Control_of_Aliens_via_Stunning|Permanent Control of Aliens via Stunning]] Exploit - as was hoped for.
* [[Exploiting_Mind_Control#Resurrect Zombified Agents|Permanent Control of a Chryssalid/Tentaculat]]

It does not fix:

* Various Mind Control bugs:
** [[Known_Bugs#Mind_Controlled_Soldiers_go_MIA]]
** [[Known_Bugs#Mind Controlled Aliens Count as MIA if you Abort]]

(Probably because fixing both of these requires special, end-of-mission processing)

Still To Be Fixed:

* [[Exploiting_Mind_Control#Exponential Mind Control|Exponential Mind Control]]

(This requires a check in UNITPOS to ensure that the unit attempting Mind Control is not, itself, already mind controlled.)

[[User:Spike|Spike]] 16:16, 3 September 2009 (EDT)

== Fixed Funky Fire and Zombies ==

Fixed Funky Fire still permanently kills Zombies, when the killing damage comes from (end of turn) fire damage. [[User:Spike|Spike]] 21:02, 5 September 2009 (EDT)

== Research Tree ==

I've found a way of modding the research tree and was wondering if people are interested in an updated version. I've read of stuff like enabling hovertanks from cyberdisc autopsies or flying suits with floater research, but I think there is more that can be done. The limitations from the original game is that having researched a topic cannot unlock more than 4 new topics, and cannot unlock the production of more than 4 new item types. Any ideas? [[User:Seb76|Seb76]] 12:40, 6 September 2009 (EDT)

* Another one I mentioned was: Mind Probe before Psi-Amp, although I'm going to retcon that to "Mind Probe before Psi-Lab" (which then leads to Psi Aimp as per usual). The logic behind this is that the first step of a psi-attack must be scanning for enemy brainwaves to pick them out of the other signals. Before you can teach soldiers to do this, you'd have to have studied the mind probe to see how the non-psychic aliens are managing to find targets. You've got to walk before you can run, after all.
* I'm unsure if the next suggestion is possible, given what you have said. I'd like some kind of necessity to research at least some corpses/aliens - is it possible to require, say, any 6 alien 'live' or 'autopsy' reports finished before Alien Origins unlocks? You might also make it dependent on difficulty (6/7/8/9/10 needed). You could also include alien missions in this count.
* My only other suggestions are: you should have to research Elerium before you can build anything that requires Elerium to build. You should have to research Alien Alloys before you can build anything that uses those (which is true only for some things currently. It doesn't seem to be a prerequisite for building alien weapons). Is it possible for a manufactured item to require two separate research entries to be manufactured?
* Question: is there also a limit of 4 prerequisites for a research item? [[User:Stubbs|Stubbs]]
:There is no limit on prerequisites, it's the code that shows "you can now build/research xxx" that has a 4 entries limitation. [[User:Seb76|Seb76]] 15:05, 6 September 2009 (EDT)

A boring suggestion but how about making sure that for all weapon research, you need to do the pistol before the rifle before the heavy weapon, etc. And similarly with the ammo types. Apart from that, I'll think on it. [[User:Spike|Spike]] 17:42, 6 September 2009 (EDT)

Another boring suggestion: each specific laser weapon should take a little longer to research - force you to use the starting weapons for a little longer. You could also rebalance the Plasma research times so that the rifle took a little longer and the Heavy Plasma took significantly longer. It might then be more viable to research them from weakest to strongest, without forcing your hand as Spike suggested. [[User:Stubbs|Stubbs]]

:Yep that's a good alternative.

You could make the Stun Launcher a little harder by requiring (as well as Alloys and Elerium), perhaps a live Medic to be researched before the Stun Launcher (since it's usually Medics that carry them and presumably understand how to operate them), and an Engineer for a Blaster Launcher. It's not much extra but it helps to make these powerful weapons a little harder to get. If you wanted to make Blaster Launcher quite a lot harder to get you could add something like UFO Navigation (something to do with plotting all those waypoints, alien-stylee), or at least a Mind Probe for similar reason.

But, what are we trying to do here? Make things harder in general? That's one option. Or "rebalance", i.e. make things that are relatively too easy to get, relatively harder to get? Or make things more "logical"? There's lots of ways to play this.

It's a shame there's not a distinction in the game between using, and manufacturing, alien weapons - as is done in XcomUtil. Really, there should be a world of difference between figuring out how to use scavenged alien weapons, and actually being able to manufacture them. But that's not really a research tree topic, '''unless''' - would it be possible to create new topics? Could you separate out the using of an item from the manufacturing of it? (If not, it would be good to have a game variant in which nothing that can be scavenged, is allowed to be manufactured).

UFO Navigation might also be a good prerequisite for Hyperwave Decoder. I'm sort of rambling here, but what are the most powerful technologies, that are kind of easy to get... which ones need to be made harder. (Are there any that need to be made easier?)

Powerful technologies:
* Psionics (Psi Lab == Psi Amp). Adding the Mind Probe, as suggested, would be a good idea. Maybe a psionic Commander capture required for each.
* Blaster Launcher - maybe require an Engineer and a Soldier research, as well as Elerium & Alloys. Mind Probe or UFO Navigation for the "plotting" element? A separate Engineer capture to produce the ammo? What else?
* Stun Launcher - Medic and an Engineer? Maybe a full set of autopsies - but that's too onerous.
* Heavy Plasma - stretching the research time would be good, though this can already be done. Additional pre-reqs - maybe add a live Engineer requirement (maybe for ''each'' Plasma weapon type?). If you keep making these requirements you probably need to add a hint in the UFOPaedia along the lines of "we will need to interrogate alien technical experts to further understand this weapon technology". (OK that's hardly a hint.)
* Laser Cannon (?) - But I'm not sure this Laser Cannon factory thing is a big deal. Arguably building a new intercept base is a better cash cow than building a 50-Engineer Laser Cannon factory.

[[User:Spike|Spike]] 16:34, 8 September 2009 (EDT)

== 64 bit compatibility ==

Any way to make the loader compatible with 64-bit operating systems, like 64-bit XP/Vista/7? [[User:Jwilcox25|Jwilcox25]]

: I'm using it on Windows 7 and it's working fine. Not sure if that's 64 bit though. [[User:Spike|Spike]] 07:26, 9 September 2009 (EDT)

:: If you're not sure, you are probably running the 32-bit version of Windows 7. Starting from XP, Windows comes in both 32-bit and 64-bit flavors. Most 32-bit programs are backwards compatible, but apparently not X-COM from my experience. [[User:Jwilcox25|Jwilcox25]]

: It works fine with Windows 7 64-bit. Didn't have to enable any compatibility options or anything like that. [[User:Rovlad|Rovlad]] 02:29, 23 April 2010 (EDT)

== Music bug ==

When enabled "MIDI freeze" bugfix, after entering first combat the music stops playing completely, for the remaining game session.

Also, when using Extender, for some reason music is playing at really low volume, i have to manually reduce my main sound channel and crank up the volume to hear it. When just starting normal UFO CE volume levels of music and sfx are about equal. I have SB Live & WinXP.

== Fire Speed bug ==

Sometimes, for no apparent reason, fire speed setting jumps to 3, instead of what you had it set on.

: I believe it's a bug in the game itself, not the loader. I remember encountering it in both DOS and CE versions. [[User:Rovlad|Rovlad]] 02:31, 23 April 2010 (EDT)

== Reserve TU for x-Shot ==

Not sure if this has been addressed or fixed, but if you reserve Time Units for any shot type, all you get is Snap Shots for the reaction phase - never aimed or auto. Is there any way you could enable these two unused types for reaction shots? --[[User:Zombie|Zombie]] 22:51, 25 October 2009 (EDT)
:As far as I can tell, the reserve is only meant to be used during the active turn. Reaction shots are hardcoded to snapshots (that's true for the aliens too), it's no bug that your guys don't use reaction autoshots. [[User:Seb76|Seb76]] 12:10, 16 January 2010 (EST)

== TFTD ==

I know you're hoping to perfect the current version before taking on any new projects, but I just want to add my plea to the others requesting a TFTD version. Even some of the basic functionality would be awesome and probably completely portable, such as the stats on the equipments screen, default new base, etc.

== Can't change tasks in D3D ==

Hey, I'm having an issue with D3D. If I alt-tab out, I can't switch back to the X-Com task. I'll switch to it but nothing can happen. I'm on Windows 7 x64 with an ATI Radeon HD 5770. [[User:Rlbond86|Rlbond86]] 20:19, 15 January 2010 (EST)
:I too have hangups sometimes when alt-tabbing out of XCom, sadly I'm no D3D expert :( I'll add more checks to see if resetting the D3D device worked though. If anyone knows of a 100% working way of dealing with "device lost" conditions, now is your chance... [[User:Seb76|Seb76]] 12:06, 16 January 2010 (EST)

== Battlescape Soldier's Stats Crash ==

I'm having this little problem with this and I wanted to know if I'm the only one that's suffering with it: everything works fine, but when in battlescape mode I want to check the stats of a soldier (by clicking his rank icon) the entire game CTD. Does it happen to anyone else? How can I fix it?
:Never saw such problem...
:* Does it still crash when you disable the extender (and what options did you enable)?
:* Do you have the address where the crash happens?
:[[User:Seb76|Seb76]] 15:55, 22 January 2010 (EST)
::It didn't, but now I reinstalled the game and it works wonderful. This is a great job you did here. Is there any chance that you could access to the stats of the soldiers from the assign crew screen? --[[User:Slibluhr|Slibluhr]] 16:56, 22 January 2010 (EST)
::OK, I could reproduce the crash this time, it has nothing to do with the stats screen as I supposed to do. The game crashes RANDOMLY if I have turned on the D3D thingy, any clue? I've also noted that if I turn on the caps mod (to put most of 'em in 150-200 to overcome the distance penalty) the soldiers do NOT improve, even after kicking a large scout's butt with KAtherine Sharpe, she didn't get any FAc point! --[[User:Slibluhr|Slibluhr]] 05:30, 23 January 2010 (EST)
:The caps bug is a known one, and a fix is available. I thought I'd wait for more substancial stuff before releasing a new version though. You can try the latest dev version that has the fix included.
:As for your crash I cannot do much without a crash address... [[User:Seb76|Seb76]] 11:46, 24 January 2010 (EST)
::This is what it said during last crash:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00011689

::--[[User:Slibluhr|Slibluhr]] 15:29, 24 January 2010 (EST)
:Sadly the address is of no use (crash inside Windows code, most likely because of wrong arguments). I've put a new version up with better D3D error handling, does it help with your crashes? Also since I was feeling like it, I updated the "Reorder Soldiers" feature so that when you click the name of the soldier, his stats show up. You must click the rank/name of the ship to assign the soldier. [[User:Seb76|Seb76]] 18:00, 24 January 2010 (EST)
::Thank for the access to the stats of the soldiers via crew screen, it releases them from having their FAcc and PStr in the name.

:: btw, the crash moved to this location now:

::AppName: ufo defense.exe AppVer: 1.0.0.1 ModName: ntdll.dll
::ModVer: 5.1.2600.5755 Offset: 00028c0b

::could it be that's my pc's fault? does this happen to anyone else?

::------------------
::System Information
::------------------
::Time of this report: 1/25/2010, 01:25:00
:: Machine name: 0X000001
:: Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.090804-1435)
:: Language: Spanish (Regional Setting: Spanish)
::System Manufacturer: FOXCONN
:: System Model: A6VMX
:: BIOS: BIOS Date: 03/13/09 09:59:28 Ver: 08.00.14
:: Processor: AMD Sempron(tm) Processor LE-1250, MMX, 3DNow, ~2.2GHz
:: Memory: 3072MB RAM
:: Page File: 466MB used, 4490MB available
:: Windows Dir: C:\WINDOWS
:: DirectX Version: DirectX 9.0c (4.09.0000.0904)
::DX Setup Parameters: Not found
:: DxDiag Version: 5.03.2600.5512 32bit Unicode

== Store limit question ==
Nice to see you've implemented the general store change (unfortunately, UFOExtender doesn't work under wine, so I can't test this). I'm curious why 187 is the limit? I thought it would be a power of 2 (possibly minus 1)... Possibly you wanted to write 127? [[User:Cesium|Cesium]] 19:43, 21 February 2010 (EST)
:You can build 35 general stores max in a base and 65535/35 ~= 1872 (the internal representation is ten times what's shown ingame). [[User:Seb76|Seb76]] 00:19, 22 February 2010 (EST)

== Mouse scaller not working on Windows 7 x64 ==

with d3d=1 and Scale Mouse=1 I still have issues with the mouse going way off screen.
--[[User:BladeFireLight|BladeFireLight]] 01:57, 22 February 2010 (EST)
:I have noticed that alt-tabbing out of X-COM at the title menu (or any other point that won't crash it) and then alt-tabbing back into it fixes this problem for me in Win7-64. --[[User:Xusilak|Xusilak]] 13:12, 22 February 2010 (EST)
::Thanks for the heads-up. I uploaded a test version here: http://www.ufopaedia.org/index.php?title=Image:UFOExtender-dev.zip
::Does it fix you problems? [[User:Seb76|Seb76]] 14:36, 22 February 2010 (EST)
:::Yep. Seemingly no issues with the mouse going off the screen using it, although I didn't test for long. I'll try to get more test time in later. --[[User:Xusilak|Xusilak]] 20:46, 24 February 2010 (EST)
::::Actually, it doesnt work for me either, in WinXP. And it was broken since the version of 7th November, the one with windowed mode addition. Also, Alt-Tabbing didnt work too. This fix makes things right, though.
::::Edit : also, this dev version crashes in 100% cases when going to battlescape.
::Strange, I do not have any trouble even when using split binaries. Do you have an address for the crash? [[User:Seb76|Seb76]] 14:03, 1 March 2010 (EST)
:::Okay, i hope this is what you wanted, but it says the adress is 0x0000000000bd22ca. I can load an actual save with tactical mode, but cant go into tactical from geoscape. So i use the version from 1st November still.
:Hum, you say the dev version crashes and that you are stuck with the version from 1st november. Do you mean you have the problem since the version of november the 7th, independently from the dev version? [[User:Seb76|Seb76]] 14:08, 4 March 2010 (EST)
::Actually yes. At first i didnt want to use it, because i use a tablet instead of mouse, and its really noticeable when a window failed to scale properly, since a tablet works in absolute screen coordinates. But just now i checked several new (non-dev) versions for the crash - its there. Crashes every time i try to enter tactical mode from geoscape. Saves from tactical load up fine. Version from Nov.1st gives no problems whatsoever.
:Do you still have the problem if you disable D3D or use windowed mode? Also if you load a tactical game, don't you get a crash when it goes back to geoscape? [[User:Seb76|Seb76]] 03:20, 6 March 2010 (EST)
::When disable D3D - yes. When enable windowed - yes. When going from tactical to geoscape - no.
:OK, I suspect this has to do with the "Save Equipment" feature. Can you try disabling it if you have it on? [[User:Seb76|Seb76]]
::OK, um...i tried all my saves, and with that feature disabled all my saves load up fine, and i can go from geoscape to tactical and back. So i thought everything was alright, and kept playing - the very next tactical mission loads up fine, but as soon as i try to move anyone - it crashes. And that is the same in all my saves, first mission is alright - second one always crashes. The crash adress is 42064f, in case you're gonna ask.
:Alright, can you PM me a savegame before the crash? I doubt it'll help but who knows...[[User:Seb76|Seb76]] 12:43, 6 March 2010 (EST)

== Extender in Steam (+ maybe XComUtil) ==

Hi do you know of any way to use the two apps together with the Steam version? I would really like to be able to combine the 'Reorder Soldiers' feature of Extender and the 'Capturing Aliens for Research' of XcomUtil.

Actually now that Ive put a bit more time into it I can't get UFOLoader.exe to run in steam's dosbox implementation at all. I can just run UFOLoader but it doesn't run in dosbox which makes the game run horribly. If you don't have a steam copy for testing / integration of the basic Extender program please let me know and I would be happy to send you a gift copy.

-Dogfish

P.S. What a great program, you are a credit to gaming.
:As far as I know, the Steam version also ships with the windows CE edition, the default shortcut just happens to point to the dosbox one. Also the latest version of XComUtil is able to detect the loader presence and act accordingly. [[User:Seb76|Seb76]] 15:42, 25 February 2010 (EST)

:: STEAM comes with both EXE. XcomUtil and UFO Extender work together with STEAM. To use Setup UFO Extender in the game folder. Then Download and install the latest build of XcomUtil 9.7. It will auto start XcuSetup in windows, Detect UFO Extender and allow you to configure RunXcom to use it. To use UFO Extender, or UFO:CE you can't launch the game from STEAM. You have to create a short cut for RunXcom. (Right click > send to > Desktop as Shortcut) --[[User:BladeFireLight|BladeFireLight]] 19:13, 25 February 2010 (EST)

Thanks guys I was able to start the game with both mods. I apparently had everything configured correctly but I kept launching it from steam. Is there a way to play in windowed mode (since its not using dosbox)? I tried launching dosbox and running 'RunXCom.bat' file from there but it does not recognize UFOExtender.

Oh boy the game is fast, even on slowest scroll it is difficult play a battle :)

-Dogfish
:What options did you turn on? [[User:Seb76|Seb76]] 14:18, 26 February 2010 (EST)

Show Stats=1
Apply=1 (wreck analysis)
Proximity Grenades Experience=1
Elerium-fueled Craft Bug=1
Save Reserve Mode=1
Rank In Inventory=1
Manual Interception Fire Mode=1
Crafts Always Ready=1
Reorder Soldiers In Crafts=1
No Funkers=1
TFTD Doors=1

Full System Specs:
Win Vista 64
Intel i7 920
6GB RAM
GTX 285 Video
Asus p6t

Everything is fast the geoscape tics are at least 5 times faster than running the non-Extender mode via dosbox.

Would you have any suggestions how to slow it down? I've actually been playing in steam(dosbox) with XComUtil only and then saving/loading between missions so I can reorder the soldiers.

Aha! I found the D3D Windowed option...
HQ4x=0
D3D=1
D3D Windowed=1
Always On Top=0
Clip Cursor=1
Scale Mouse=1
Screen Ratio=0.833333

I can manually resize it to be bigger, excellent!
What is strange is that running it in windowed mode seems to slow it down enough for the scroll speed settings to make it playable :)

I ran into a "Unsupported 32/16/64 bit error message switching from geoscape to battlescape but it happens only 1/3 times maybe?"

I will be playing this and let you know if I run into any more problems.

Thanks a bunch!
-Dogfish

Hi guys, dogfish again I've been getting a couple of glitches.

1. Switching from battlescape back to geoscape in the cmd prompt it displays
'echo----------------------------Leaving' is not recognized as an internal or external command, operable program or batch file.

2. This has happened twice

Get someone who has been shot is at low health and has fatal wounds

Have them pass out due to smoke inhalation

Let them bleed to death and get the "Joe McSoldier has died from a fatal wound" *while unconsious from the smoke*

I will lose points for the mission but the soldier will be recovered at the end of the mission but terribly wounded. (Currently Hans 'Jesus' Vogel is taking 55 days to recover his 41 health.)

:Both of these are XcomUtil issues. 1 has been fixed in Build 413 but I need a saved from just before ending combat to fix 2. --[[User:BladeFireLight|BladeFireLight]] 18:19, 28 February 2010 (EST)

::Sent the savegame to your gmail (whatever was listed on my paypal reciept from your donate button). Just hit end turn (all the aliens are dead) and the bug is triggered. -Dogfish
::: I got it. Was up all night with Bomb Bloke and we worked out what was going on. The fixed works with your save. The next build will fix the zombie bug. Also Thanks for the donation. Every little bit helps. --[[User:BladeFireLight|BladeFireLight]] 16:02, 1 March 2010 (EST)

--
Hi! I'm thefarside. This is my first time ever editing a wiki page so please bear with me. I'm not even sure I'm allowed to do this.

However, I have a problem with the cursor. It moves WAY out of the screen to the right and downwards. I've read something about a "clip cursor" fix but I can't seem to find out where and how to implement it.

Regards,
thefarside
--

== Manually Select Promotions ==

Just an Idea, not sure how easily done it is but I was thinking it would be really cool if (when its time for promotions) it would bring up a soldier screen with the eligible soldiers so that you could pick who gets promoted. Bonus if you could click on the candidates and be taken to their stats screen.

Love,
Dogfish

== Xusilak's Patch Additions ==

Since my patches are being integrated into the main release now, everyone should let me know if any issues are found with them. I'll try to get on fixing them as quickly as possible.

For clarity, the patches in the current build that I developed are:

* AutoSell
* Show Money

Thanks! --[[User:Xusilak|Xusilak]] 14:51, 24 March 2010 (EDT)

I went ahead and set up my own user page: [[User:Xusilak]]. If possible, direct discussion about my patches to my [[User_talk:Xusilak|discussion page]] there. Thanks again! --[[User:Xusilak|Xusilak]] 15:44, 24 March 2010 (EDT)

----

Hi Seb,
I've been working with IDA, your database, and your patcher's code for some time now, learning my way around it, and so on. So far, I've managed to come up with three UI improvement patches, although they still need some polish and testing.

The first one is a battlescape movement confirmation patch; it requires the user to click twice (double-click with no time limit) on the same tile to move, instead of once, to eliminate movement errors. In practice, I have found this very helpful.

The second one shrinks the geoscape clock and adds your current funds above it, letting you see your financial situation at a glance while waiting for time to pass.

The third one enables auto-selling of manufacturing items. Pressing the down arrow when the production quantity is at 0 engages this mode. When in this mode, production of that item never ceases (unless resources become unavailable), and the item is immediately sold upon completion.

Would you like me to make the code for these available once I've finished polishing them up? They currently consist of a few C functions accompanied by some InsertCall()s and Nop()s, as well as some additions to XCOM.h. I haven't added INI options to enable them, so I'd leave that up to you. You may use them as you wish, with no conditions.

Note: I'm still learning x86 assembly, so the patches may not be bug-free. I'm hoping to give them a good testing myself, though.
--[[User:Xusilak|Xusilak]] 16:10, 19 March 2010 (EDT)
:Glad to see you could make something out of this database :-) Do not hesitate to send me your modifications, I'll incorporate them in the codebase so others can enjoy them. I'm sure your autosell feature will make a few happy ones ;-) [[User:Seb76|Seb76]] 19:12, 19 March 2010 (EDT)
:::Yeah those features would all be '''great!''' Thanks Xusilak. [[User:Spike|Spike]] 15:08, 22 March 2010 (EDT)
::OK. I'm going to finish up my last touches on them, then test them for a while; they should be ready within a couple days. --[[User:Xusilak|Xusilak]] 21:59, 19 March 2010 (EDT)

== v1.21, Battlescape crashes ==

I enabled the new mods and they worked ok in Geoscape. Then this Popup box starting the first Battlescape:

Application failure
XCOM crashed at 0x10002571 with error 0xC0000005 trying to access 0x0968DF43

[[Media:UFOExtender1.21.BSCrash.zip]] contains the UFOExtender.ini file.
This was a New Game but not a new install of XCOM, just an overlay of updated UFOExtender.

*Win XP Pro 2002 SP2 32bit PAE
*Pentium-4 3.00GHz 3.5GB RAM

Any ideas? Need more info? [[User:Spike|Spike]] 20:20, 24 March 2010 (EDT)
:Does it happen consistently? I've been plagued by a random geoscape->battlescape transition crash in the collector's edition. It's one of the things I'm looking to fix at some point. The current UFOExtender doesn't appear to crash any more than previous ones do for me. I managed to do four missions in a row just now. --[[User:Xusilak|Xusilak]] 21:00, 24 March 2010 (EDT)

I'm doing some research into this; I started up in debugging mode and spammed missions until I hit a crash. The crash (on this occasion) is an access violation caused by an invalid pointer stored at 0x49B954 (the offset that pSoldierDat points to). This means *pSoldierDat is being changed at some point. It took many, many tries to get this crash to happen; I reloaded something like 20 times hitting the same mission, went ahead and did the mission quickly, proceeded, did another mission, proceeded, then the next mission crashed. Given that I'm in debug mode, it's not impossible this is due to the various hacks enabled by it, so that should be kept in mind. I'm going to continue working on this. --[[User:Xusilak|Xusilak]] 22:26, 24 March 2010 (EDT)
:It appears the "invalid" pointer is actually set by malloc() - 0x0771D380 (for me). I can only assume something along the way disrupted the data on the heap, as the pointer was the same when examined on a battlescape transition that didn't crash. Still researching. Note that for me, the crash itself happened inside GetSolderUUID() in the Save Equipment patch functions when it attempted to use that *pSoldierDat pointer. However, I assume it would still happen if the Save Equipment patch were disabled, just elsewhere. This is something I'll test as well. --[[User:Xusilak|Xusilak]] 23:41, 24 March 2010 (EDT)

::Sorry I'm guilty of reporting a bug I didn't (couldn't) repeat. But as I had no previous save game positions I couldn't repeat anything - the crash happened on the first Battlescape mission which for me is unusual, I would say that for me that transition crashes less than 1 in 100 times, if even that many. I had enabled Save Equipment I think and on instinct I would suspect that mod as being responsible. Those UFOExtender functions would run while setting up the Battlescape presumably. The equipment handling functions and structures ''already'' present in the game are known to be buggy. BladeFireLight and I just found another issue with them last week. Manipulating them is still risky. If you can investigate that would be very helpful.

::In the meantime I will see if I can try to repeat the fault, with and without Save Equipment enabled, and starting from a clean XCOM install. One trick I may use is to set No Score Game Over and then just abort from each mission rather than fighting it, to speed up the testing.

::Thanks for your good work Xusilak, it is appreciated! [[User:Spike|Spike]] 03:25, 25 March 2010 (EDT)

One possibility: On this mission I had only 6 soldiers (2 HWPs) but enough weapons in the Skyranger to equip 14 soldiers. Is there some known issue with needing to allocate '''all''' weapons to soldiers during the equip phase, in order to avoid a crash? If so that might be the cause. I will try to recreate those conditions and see if it provokes a crash. In case it's not clear, Battlescape never appeared to start, no Equip Phase screen ever came up. [[User:Spike|Spike]] 03:31, 25 March 2010 (EDT)
:Assuming the same crash is afflicting us, then the crash is when the very first soldier is accessed, when the Soldier.Dat data is first used for that mission. It's unlikely that volume of equipment is affecting that, and in particular, I hadn't changed my Skyranger's loadout to any degree whatsoever, having only briefly touched researching and manufacturing; it was otherwise a gamestate set entirely by doing one quick regular mission and one quick terror mission. However, I was also in debug mode, which enables certain cheats, like Alien Pets, automatically. This might, itself, have unseen bugs that could corrupt the data structures and cause a similar crash. When I get the time to, I'll be testing again with those cheats disabled, trying to further isolate the conditions involved. --[[User:Xusilak|Xusilak]] 08:34, 25 March 2010 (EDT)

I've repeated this multiple times now, with a clean install of XCOM and a clean install of UFOExtender 1.21. The game crashes everytime, after the "mission screen" that comes up just before the Equip Phase of Battlescape for the first mission. It's regardless of my equipment loadout or number of soldiers/tanks: it happens with totally default equipment and Skyranger load. So I imagine it must be due to some combination of the UFOExtender.ini file options I selected, and maybe code changes in 1.21. My .ini file is the upload at the top of this section. The error is always "error 0xC0000005 trying to access 0x0968DF43", though the crash location (in the code) varies. [[User:Spike|Spike]] 20:31, 25 March 2010 (EDT)
:If you have time, could you try to 1) confirm it's specific to 1.21 2) try to correlate it to ini options? Turn everything but the basics off and see what happens... if that works, turn on Save Equipment and try again, etc. I haven't seen any behavior like that in my local tests, on either of my computers (Win7-64 and XP-32). I'll try it with your ini, though. Maybe I can find something. --[[User:Xusilak|Xusilak]] 20:39, 25 March 2010 (EDT)
::Just tested with your ini, although with D3D and D3D window enabled. Started a mission, didn't crash. I also noticed one thing: you have General Stores capacity set to 1. I don't think that's helping anything, but it's probably not causing the crash, either. Experimenting more. --[[User:Xusilak|Xusilak]] 20:48, 25 March 2010 (EDT)

::: Save Equipment=1 is part (at least) of the problem. If I turn that off, and leave all my other .ini settings as is, I no longer get the Battlescape crash. Seb, did you make some changes there? Maybe after the investigations we were doing with BladeFireLight? [[User:Spike|Spike]] 21:13, 25 March 2010 (EDT)

I have isolated the problem (on my end) to the fact that the SOLDIER.DAT data in memory is deallocated when the transition to the Battlescape starts. When Seb's Save Equipment code attempts to use it, it's getting random unallocated (or unrelated) memory instead of the SOLDIER.DAT data. Interestingly, the dynamic memory used to hold the SOLDIER.DAT data is deallocated on the transition to the Battlescape, and reallocated to a new memory address on the transition out of the Battlescape. I assume this is an artifact of the way the Collector's Edition merged TACTICAL.EXE with GEOSCAPE.EXE, because TACTICAL.EXE had no need of SOLDIER.DAT, and only used UNITREF.DAT and similar. At any rate, this problem can be resolved by not relying on **(0x49B954) (or **pSoldierDat) to contain the correct data. Instead, a workaround to get the needed data should be used. One option would be to patch the way the transition works to prevent the deallocation from happening, and then ensuring on exiting the Battlescape that the old memory block is still used. I may be able to work in that fix myself. If so, it would require no changes to the Save Equipment code.
I'm not sure if this is a general issue or local to me only. I'll try to test on my XP system and see if it suffers from the same problem; if it does, it's a safe bet this is a general issue, and the likely cause of your crashes. --[[User:Xusilak|Xusilak]] 00:06, 26 March 2010 (EDT)

Save Equipment did used to work for me before. Maybe it's because I also selected Reorder Soldiers In Craft. Does that sort and rewrite SOLDIER.DAT? [[User:Spike|Spike]] 03:39, 26 March 2010 (EDT)

I have confirmed this behavior in the original X-COM Collector's Edition UFO Defense.exe copy, running on my XP system. As such, it ''cannot'' be a result of any patches Seb has made (because it still happens even when not using Seb's loader). I'm not sure if it will crash without Seb's patches still, but the way Seb uses the *pSoldierDat pointer in GetSoldierUUID() appears to be unsafe, as *pSoldierDat has already been deallocated at that point. On some systems, it may work, because the nature of memory on the heap is such that different systems give different results when dealing with deallocated memory and bad pointers. Regardless, the crashes can be at least partially (maybe entirely) resolved by using a workaround that avoids the deallocation of *pSoldierDat when the battlescape transition starts. I'm going to see if I can implement the fix I suggested, that prevents the memory from ever being deallocated. That should completely resolve it. At the least, I am going to study the assembly responsible for deallocating it to see if I can confirm the exact issue on the code level. --[[User:Xusilak|Xusilak]] 13:26, 26 March 2010 (EDT)
:It seems that when GotoGeographMode() returns to move into GotoTacticalMode(), it calls FreeEverything() in the process, deallocating all data structures. Then, GotoTacticalMode() never bothers to reinitialize *pSoldierDat, so when the equipment phase comes up, it's still unallocated. Still working on a fix. --[[User:Xusilak|Xusilak]] 14:29, 26 March 2010 (EDT)

::Surely at some point the (unmodified) game needs to at least read the *pSoldierDat structure, in order to populate the [[UNITREF.DAT]] and [[UNITPOS.DAT]] structures for Battlescape? Unless it reads SOLDIER.DAT but doesn't bother storing it, not even temporarily, in *pSoldierDat.[[User:Spike|Spike]] 15:27, 26 March 2010 (EDT)
:::Nice piece of analyse there :-). I'll modify the patch to load the soldier data when needed and clean up afterward. [[User:Seb76|Seb76]] 15:30, 26 March 2010 (EDT)
:::Edit: I uploaded a test version. Can you check if it fixes your crash? [[User:Seb76|Seb76]] 15:47, 26 March 2010 (EDT)
::::Looking good so far; Save Equipment works for me now, and it never has in the past. I'll run through a bunch of missions quickly and see if I get any crashes. Thanks Seb! --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:::No, thank you for figuring out the cause of the crash. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
:::::Just ran through several dozen (very quick, mostly aborted) missions all the way up to June. I never crashed, and Save Equipment always worked correctly. I think we're good to go. Hopefully it works for Spike as well. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)

I've also been narrowing in on another crash, unrelated to the patcher, I believe. It happens rarely upon clicking the air to move somewhere, like stepping out of the Skyranger by clicking the air one tile in front of the soldier, to move onto the ramp. It appears to be the result of a bad calculation on the tile to check in MoveUnitTo(). The calculation is looking at (char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize); // when esi is 2 or greater; this esi factor shouldn't be there, as far as I can tell, because it results in the offset used being much greater than it should be and frequently going out of bounds of the MAP.DAT data stored at *pMap. Continuing my research into this when I get a chance. --[[User:Xusilak|Xusilak]] 17:01, 26 March 2010 (EDT)
:I noticed that crash also (I think it's the number one crash cause on a genuine XCOM setup) but was never able to reproduce enough to investigate it. I was tempted at one point to patch the GetTileAt function to check its arguments, but finding the cause of the corrupted value would be better. [[User:Seb76|Seb76]] 17:21, 26 March 2010 (EDT)
::Yes, it's definitely a hard crash to catch, because of how rare it is. I've got a few ideas, though. We'll see if they help. --[[User:Xusilak|Xusilak]] 18:00, 26 March 2010 (EDT)
:::Currently, my guess is that this line:
:::<pre>.text:00420534 BE 01 00 00 00 mov esi, 1</pre>
:::should be "mov esi, 0" instead.
:::To sum up the issue:
:::The way the 'click on air to move to a tile below unit' part of MoveUnitTo() works is that it examines each level below the unit until it finds a floor to move to. It does this by looping through the level below you, incrementing esi to loop through the next level below that, and so on. To do this correctly, esi should start at 1. However, the X-COM programmers appear to have made an oversight: they initialized esi to 1, but then incremented esi again before the initial value actually gets used. The net result of this, is that we get zpos += 2 for the very first cycle. This works OK on floors 3 and 4, but for floor 2, it will attempt to access a z level that doesn't exist (one below the ground), causing this line: <pre>(char *)pMap + 4 * (xpos + (currentUnit_zpos + esi) * map_numTilesPerLevel + dword_4A28AC * tac_mapYSize);</pre> to exceed the bounds of the *pMap memory block. Obviously, running off the end of that block will cause unpredictable results, and if it reaches into a block that isn't allocated, it will crash. That's why the actual crash is very rare: it has to overrun into an unallocated memory block.
:::Of course, I could be completely wrong, but it makes sense, and patching 'mov esi, 1' to 'mov esi, 0' doesn't seem to cause any problems. I'm going to be testing with that patch enabled from now on, to see if I crash in that circumstance anymore.
::Looks like you are right. I instrumented the code and there are indeed systematic out of bound accesses when getting out of the craft, though the game does not crash every time. I suspect this is the same crash that happens during base defence when an alien tries to move down from the access lift. Kudos for figuring all this out! I'll provide the fix in the next version. [[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)
:::By the way, Seb, the 1.21 source code doesn't include autosell.cpp; I assume it's a simple oversight. I reconstructed it to get it compiling properly. Just wanted to make sure you knew. --[[User:Xusilak|Xusilak]] 20:37, 26 March 2010 (EDT)
::Oops, forgot to check the unversioned files before checking in...[[User:Seb76|Seb76]] 14:04, 27 March 2010 (EDT)

== Minor cosmetic enhancements? ==

Had these ideas come to mind while I was at work today, and since your loader is doing some amazing things for the game, I thought I'd ask if the possibility of any of these enhancements exist.

The short of it is: Are you able to overlay any additional bitmap surface on top of the battlescape view, and are you able to play additional sounds?

The main idea for drawing an extra bitmap (semi-transparent) over them map would be to simulate rain/snow for some outdoor maps. Lightning even - though that would require clever use darkening and lightening the overlay. This would have some issues attached to it such as knowing when to display it and when not to, thanks to the various other screens available.

As for playing sounds, which would be simpler, would be to play a looping sound clip to provide environmental sound effects, such as insects chirping and owls hooting at night in woodland maps or town noises at terror sites. Or during the day in a jungle map, some tropical bird calls made at random intervals. TFTD already does the looping environmental sounds, such as teh under water bubbly noises or the wind and sea noises when on land mission. Would it be possible to duplicate this for UFO CE?

Not the most important of enhancements, but I was still wondering if the possibility is there.

-[[User:NKF|NKF]] 01:41, 25 March 2010 (EDT)

== Save/Load shortcuts ==

Seb, would it be possible to enable shortcuts for the Save/Load in geospace & tactical (like F2 or F3) ? ;) except for saving in the final battle (from level 4 if remember) :)

Other things:
- rosvell incidents occured for me too often - 5 in the first month while there was no other alien craft movement detections

- option to disable mission briefing window with the only ok button :) supposedly for advanced users ;)

== Aliens continue using pistols&rifles ==

Hi Seb, sorry to bother you - i have been playing X-COM titles on and off for about 10-15 years now, and one thing always bothered me: Why do the aliens always swith to heavy plasma (or the Sonic cannon in case of TFTD) later on? It encourages the player to swith to heavy plasma too, if only for the free ammunition you almost drown in later on. Would it be possible to have the aliens continue using the plasma pistol&rifle after june/july? It would make using those weapons more feasible, getting ammunition during missions and not having to use elerium to produce it.

Another request (don't know if it is possible) - let the aliens continue using the abductor and the harvester for the respective missions. Later on, all you get are large scouts or even battleships doing those missions - getting some variety in there would make the endgame more interesting. You get to do 50+ battleship missions in a game, but only 4 or 5 with a harester/abductor. Those ships should see a lot more use during the missions they are "designed" for. The "[[MISSIONS.DAT]]" page says something about ufo and mission counters and their associated ufo-types - would it possible to modify those entries via the loader?

Regards, Equinox

== ALIEN MISSION DATA CLARIFICATION ==

According to
[http://ufopaedia.org/index.php?title=Talk:MISSIONS.DAT#Alien_missions_data_discovered_in_geoscape.exe_.5Bfinally_.3B-.29.5D link title]

I found it in TFTD. At offset 505448 (decimal) is starting (mission Probe). Next Interdicition/resource raid/infiltration/colony expansion/surface attack/Floating base attack

I understood what is 3-rd word. If You interesting - I can exlain

Seeing speeds of USO sub we can determine the mission of this USO sub even without transmission resolver - even in january 2040
Every USO sub in every missions (interdiction, colony, probe and other) have unique speeds and we can determine mission of USO on their speed
And we can determine what amount of times a sub touch down on his mission - because every mission has unique rule for touch down USO subs
And we can determine what amount of time USO Sub will touch down on their mission - because every Sub in every mission has unique and ALWAYS equal amoun of time to touch down (p.s. this time we can see in file Loc.dat)
Here - I attached file speeds.zip
[http://www.strategycore.co.uk/forums/Ion-Beam-Accelerator-in-What-file-t8099.html&view=findpost&p=95994#entry95994 link title]

3-rd word - it is reference to unique speed of each sub

4-th word - is time that precede to arrive next uso sub. In other word, in line ufo/c 0/0 if time = for example = 200 - it's time to arrive sub that indexes 1/0.
And where can I get time to arrive EXACTLY sub 0/0 is incomprehensible for me. I assume that this time contain at similarly word of last uso for this mission - but its'not truth because at some missions time in the line of last ufo/c = 2 half-hours and it's means that ufo/c 0/0 can to arrive at new month at 2 half-hours. It's true for Surface attack Mission but not truth for other missions.
I assumed that time in line ufo/c 0/0 - that time to arrive for NOT next ufo - and I assumed that it's time to arrive exactly ufo/c 0/0 itself. But many my tests (more than 100) denies my suppositions.
In example, at line ufo/c Cruiser mission Colony Expansion time in file =2. Cruiser in that mission arriving much more than 2 half-hours after Escort. Instead Fleet supply Cruiser in that mission arriving after 2 half-hours exactly after Cruiser.

'''Question - Where can I find time to arriving for ufo/c 0/0 for each missions except Surface attack mission ?'''

I am sorry for disturbance and will great thank for you for help.
:After the first month the game creates a mission per month, up to the 6th where it generates 2. I guess a mission starts immediatly, there is no timing added for its first ship. [[User:Seb76|Seb76]] 15:18, 30 April 2010 (EDT)

Mission starts not immediately. often time to arrive to survey ship (first sub) about 10-15 days.
1-st day of month at 0-00 we can see it time at Missions.dat but wants to know average time similarly such average time for other subs from alien data mission at executable if possible.

What is exactly 6-th? mission from Probe to Colony Expansion? or from January to June?
:Yep, 6th month. [[User:Seb76|Seb76]] 20:04, 30 April 2010 (EDT)

what happens after 6-th month June?

I so sorry for reminder and bother you, but don't you know it? ((

== Formules about Retaliation/Floating base attack mission ==

Hi

My great respect to you for you formules
I need few help. I am great thank to you in advance

Now I found alien data missions in TFTD (in a similar in EU ) and I ask generously to you to check 3 your formules in TFTD. Is these same or not?

1. After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours
:Xusilak is more knowledgeable than I concerning TFTD. I cannot help you here... [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

Formule 2 and 3 probably contins mistake. formule 'll have to have symbol > instead symbol <. Otherwise retaliation mission activates more often on Beginner diificulty than Superhuman difficulty. Is is strange.

2. A retaliation mission will be scheduled if RAND()*100 < 4*(24-difficultyLevel).
:There is indeed a mistake there. It's been so long I cannot remember if I got it wrong or just messed it up wikifying it ^^ [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

3. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from. The first UFO is scheduled in 100 half-hours (the value is taken from the table I speak of later at the bottom of this page).

And RND() - what values may has? from 0 to 1 or not?
:When I write RAND()*100, it just means a random number between 0 and 100. [[User:Seb76|Seb76]] 14:41, 30 April 2010 (EDT)

I will be very thank for given help

== MISSIONS.DAT formula clarification ==

Hi Seb76. I've been having a discussion with Alexchamp and trying to interpret the formula you mentioned on [[Talk:MISSIONS.DAT]] about retaliation missions being scheduled after a shoot down. Namely: if RAND()*100 < 4*24-difficultyLevel

We mainly need clarification on the logical operator. Should it be less-than or greater-than?

As it reads now, it could be interpreted as though retaliation missions are generated more frequently on the easier levels. But if we treat it as >, then this means that retaliation missions are generated about (Beginner) 4%, 8%, 12%, 16% and (Superhuman) 20% (or 28% for TFTD) of the time on their respect difficulty levels.

If you could clarify that for us it would be great, thanks. - [[User:NKF|NKF]]
:Yep, I goofed up. Don't take everything I say as gold ;-) [[User:Seb76|Seb76]] 14:45, 30 April 2010 (EDT)

And I precise too one '''mainly moment'''. Whether there must be the opened bracket after the sign of multiplication? Because if no, then right interpretation formule in Superhuman example such: Rand*100>4*24=96-6=90 and that means that retaliation mission would be sheduled in 10 cases from 100.
IF there must be opened bracket then rand*100>4*(24-6)=4*18=72 wouid be sheduled in 28 cases from 100
What is this versions is right?

Then needs clarification for second formula yours. If RAND()*100 < (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from.
What logical operator there? should it be too greater-than or less-than?

You have found later formules about activation retaliation mission (if we shotdown alien craft)
Where exactly in assembler is subprogram that determines it? What address/offset of it?

== COLONY SUPPLY MISSION ==

As we know, When alien base built, Fleet Supply Cruisers with missions Colony Supply can to arrive to this base.

Where can I see (file/offset)
1) average time to arrive colony supply ship for examle/at least in XCOM-EU. As I said later, in responsible offset is time '''to PRECEDE to ARRIVE NEXT UFO SUB''' '''it's not''' time to arrive this sub
2) real time to wait arriving colony supply ship similarly times in file Missions.dat

According to [http://www.strategycore.co.uk/forums/Colony-Supply-ship-time-to-arrivin-t8103.html&view=findpost&p=96011#entry96011 Colony Supply - time to arriving]

If guesses of NKF is right, we need to formule of probability to arrive Colony Supply ship.
Can you to render courtesy with this formule?

Thank you very very great in advance
:I added details in the LOC.DAT talk page. The supply ship is spawned randomly and starts its mission. There is no "time to first supply ship" that I can see. [[User:Seb76|Seb76]] 15:11, 30 April 2010 (EDT)

Thank tou very much for this clarification. I found this offset in TFTD even. Changed, checked - it works.
You are greatly people!

== Roswell mission bug? ==
Hello, Seb76.

I've just had two consecutive games (meaning, I restarted the application and began a new game) where the same strange behavior occurred.

Both games had Roosevelt mission as the first one. It showed the window (type, terrain, UFO size) as usual. Afterward, whenever I clicked on it (to check mission conditions again), it showed a typical "hyperwave transmission decoded" window, stating race/mission type, etc. Needless to say, I had no decoder at this time, since it happened both times in the first game week.

I have a saved game if you want to take a look at it. It's completely reproducible, at least for me. You just click on the white cross and get this window.

Also, I'm using plain CE version with a "complete UFO patch" from StrategyCore. The saved game was not hacked in any way.

Cheers!
[[User:Rovlad|Rovlad]] 10:08, 30 April 2010 (EDT)
:Hum, I gave it some shots but could not reproduce your problem. Anyone experiencing the same problem? [[User:Seb76|Seb76]] 15:36, 30 April 2010 (EDT)

::Here's the [http://rovlad.nm.ru/GAME_1.zip savegame]. Let me know if it works fine for you. [[User:Rovlad|Rovlad]] 21:47, 30 April 2010 (EDT)
:Looks like the CRAFT.DAT entry is not cleared when a new craft is created and the offset 0x64 could be garbage till the craft is detected by a base/another ship. Since I bypass the detection when "crashing" a UFO, it is possible the "HWD detected" flag is set randomly, producing a full report. I'll clear the bit and we'll see if it corrects the issue, just wait for the next release. Thanks for providing the savegame BTW. [[User:Seb76|Seb76]] 14:22, 5 May 2010 (EDT)
::You're more than welcome. Fantastic job on the extender, keep up the good work. [[User:Rovlad|Rovlad]] 19:04, 5 May 2010 (EDT)

== ALIEN RACE SPAWN ==

Your post: In EU, the race is based off a lookup table starting at offset 0x46E53C (containing 300 entries).

Offset-0x46E53C is absent. Is one symbol odd?

Your posr:The table is made up of 10 entries lines.

It means that this bit of array has 10 rows width of 30 bytes. is right?

What is means this 10 entries lines? Can you copy 2-3 lines from exe and explain that means known for you offsets in line?As simiilarly as you done for alien data mission in file Missions.dat
Can you get more particularly answer about values it this array?(naturally if know it)
:0x46E53C is the address in memory. In the file it should be 0x6E53C (UFO Gold edition).
:The begining starts like this:
.data:0046E53C byte_46E53C db 0, 0, 0, 0, 0, 0, 0, 1, 4, 4 ; 0
.data:0046E53C ; DATA XREF: CreateAlienMission+15B�r
.data:0046E546 db 0, 0, 0, 0, 0, 1, 1, 4, 4, 4 ; 0
.data:0046E550 db 0, 0, 0, 0, 0, 0, 4, 4, 4, 4 ; 0
.data:0046E55A db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E564 db 0, 0, 0, 1, 1, 4, 4, 4, 4, 4 ; 0
.data:0046E56E RaceForTerrorMission db 0, 0, 0, 4, 4, 4, 4, 4, 4, 4 ; 0
.data:0046E56E ; DATA XREF: GeoPerformMonthlyActions+15E�r
.data:0046E578 db 0, 0, 0, 0, 0, 0, 1, 1, 4, 4 ; 0
.data:0046E582 db 0, 0, 0, 0, 0, 0, 1, 4, 4, 4 ; 0
:till the end:
.data:0046E67C db 0, 1, 1, 2, 2, 2, 3, 3, 2, 4 ; 0
.data:0046E686 db 0, 0, 1, 1, 1, 2, 2, 3, 3, 4 ; 0
.data:0046E690 db 0, 1, 2, 2, 2, 2, 3, 3, 4, 4 ; 0
:As you can see, at the begining you'll get tons of sectoids (0), a few floaters (4) and even less snakemen (1).
:At the end, you'll get ethereals (2) one time out of two. Also note that for terror missions, the line is taken a bit farther than normal missions, which means that you'll get stronger aliens sooner in terror missions. HTH, [[User:Seb76|Seb76]] 13:36, 5 May 2010 (EDT)

Thank you greatly for your detailed answer ...
I want a few more precise ...
I right understand? I guessed That line 1 - is used for January mission Research? Line 2 - Jan Harvest? Line 3- Jan-Abduction Line 6- January Terror?
What define Line 7?
Line 8 - is February Research?

According to - Line 13 -Feb terror? Line 20 - March terror? Line 27 -April Terror? Line 34- May terror? that sequence and guesses is right?

And question 2) does affect score to choose the value among values in line? How differ choose values in line at the level superhuman and level beginner ?
If you know, naturally, I would be greatly thanks to you for this wonderful magic help.

== Research tree in executable ==

Do you know location (starting offset) of research tree in EU? and how much entries it contains ? and what means values within this array?

Very great thank in advance for this help to you
:The research tree is not stored as a data array but is a hardcoded sequence of "if this is already researched and that is also researched and such item is in the inventory, then enable this research". Modding this would require a complete reengineering, not just patching. Still feasible though. [[User:Seb76|Seb76]] 13:25, 5 May 2010 (EDT)

What is starting offset (ce version) of this hardcoded sequence? and what is latest offset of it? what is length of one sequence? If possible -what is structure of it briefly? (how much bytes to tech requirements, how much bytes to items requrements)

Thank you for this help '''VERY VERY GREAT'''
:As I said, there are no *sequences* but just a cascade of hardcoded ifs:
:[[Image:Research.png]]
:If you want to take a look, the function begins at address 0x446A0. [[User:Seb76|Seb76]] 07:28, 24 May 2010 (EDT)
'''
Seb76, you are GREAT GENIUS!!!! GREATLY RESPECT FOR YOU!!! THANKS FOR YOU VERY VERY MUCH!!!'''
I have found research tree in TFTD too with your help. Now I can do some changes in it.
Maybe do you know, how can I find subprogram that run 1-st day of any month in assembler code of game?
This subprogram determines new mission's month and terror ship route (in TFTD)
There is not in EU terror ship route, I know. But If you know and tell me - what is subprogram in EU that runs 1-st day of any month, I would be able to edit probability of terror ship route in TFTD.
Greatly thanks in advance to you dear Seb76!
:In EU, monthly actions start here:
.text:0043B9B0 GeoPerformMonthlyActions proc near ; CODE XREF: GeoIncrementDayAndDoMonthlyActions:loc_4420C1�j
:HTH, [[User:Seb76|Seb76]] 16:31, 28 May 2010 (EDT)

== Any way to slow down geoscape time? ==

Is there any way to slow down geoscape time progression on fast computers, esp. multiprocessor ones, where it is impossible to significantly slow it down using utilites like MoSlo and Turbo?--[[User:AVE|AVE]] 03:01, 5 May 2010 (EDT)
:Did you try enabling D3D? If you're drivers are configured to wait VSync, it should limit the game speed (well, if you use a CRT@120Hz it'll still be too fast I guess...). Also is it still too fast if you put it windowed? (enabling both D3D and D3D Windowed options) [[User:Seb76|Seb76]] 13:19, 5 May 2010 (EDT)
::Yes, both D3D and D3D Windowed are enabled. This is even more surprising, because it shows the same results on two different computers (Dual Core one and simple P4Celeron) with different video cards (NVidia and ATI). Both have vsync explicitly enabled. LCD@60Hz both. Also I've tried to use different combinations of Video Pitch, D3D, D3DWin and HQ4x settings - no luck. [[User:AVE|AVE]] 04:20, 6 May 2010 (EDT)
:Personally I've never been able to reproduce this "CE game running too fast" thing people keep harping on about. Perhaps I just have a different perception as to what "too fast" means.

:Anyways, I know [http://www.strategycore.co.uk/files/index.php?dlid=474 Mok's patched executable] includes a timer hack for the Geoscape, but I found that makes it run far too slow for my taste. Not sure off the top of my head whether it works with Seb's loader, either - you'd probably need to at the very least need to rename Mok's executable to replace the original in order to try it that way. - [[User:Bomb Bloke|Bomb Bloke]] 05:14, 6 May 2010 (EDT)

== Some problem with edit research tree ==

I want to add new 20-30 commands to research tree. I wrote this subprogram. How can I add it to game?
I tried to write "call sub" instead useless 5 bytes in subrogram research tree. I checked in IDA after it, all other commands is preserved.
And I placed my new subprogram after latest byte of executable file. But game is crashed.
I tried to place my new subprogram after all subprograms and before first byte of idata, but game is crashed too.
All indexes in subprogram was exactly.
in second case IDA displayed "sp-analysis failed".

Where and how can I placed my new subprogram that will be addition to current subpogram research tree?
:To add new code, you need to modify the PE header of the exe file accordingly. I'm not quite knowledgeable regarding the procedure (that's one of the reasons why I made a loader instead of patching the file directly) so you're gonna have to find help somewhere else on this one. [[User:Seb76|Seb76]] 16:36, 28 May 2010 (EDT)

== Update to IDA database ==

Hey again Seb76 :)

After a long time I've come back to your extender, dusted off my copy of VC Express, and decided I'd have another go at doing some UFO modding (don't ask how the first attempt went; it's not pretty! :p )

I'm assuming you've probably updated the IDA database since last time I asked. Would be extremely grateful if I could get the latest version.

Thanks for all the hard work, staring at assembly code all day is no joke! --[[User:K9wazere|K9wazere]] 18:07, 6 June 2010 (EDT)

Arf, didn't realise I could send you an email, so this new section on your talk page is a bit redundant now :p Oh well, maybe someone else will want the file too!

== Line of Sight Origin Points ==

Hiya.

A while back you mentioned the co-ords for the [[User talk:Bomb Bloke:Firing Accuracy#Firing Point Origin|firing point origin]]. The zpos is calculated according to the unit's effective height, and the x/ypos co-ords come from look-up tables depending on which way the unit is facing.

I was wondering, are these same two tables used for the purpose of line of ''sight?'' And by any chance could you find the formula for the initial LOS zpos?

Any help would be appreciated, as usual. There are many other obvious questions around this issue (such as where the ''end'' point for these lines is), though the origin would be a good start. - [[User:Bomb Bloke|Bomb Bloke]] 07:44, 24 June 2010 (EDT)

== Training Stat Request ==

Hi there.

In the Equipment screen where the Weight and TUs are displayed during battle, would it be possible to also include the current unit's number of Reaction shots, Hits, Psi attempts and (possibly) Throws? Possibly along the bottom in a horizontal string where there's room?