User talk:Seb76

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! 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. 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 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. -- 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). -- 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 ;-) 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" 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... ;) 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... 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. 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? :) 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, Phasma Felis may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. 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 :) 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. 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? 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. - 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...). 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. 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.) 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? -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. --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 here. Tools like 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. 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. 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... 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 --col_w 11:08, 12 July 2008 (PDT)

My pleasure man. Glad you enjoyed it ;-) Seb76 12:07, 12 July 2008 (PDT)

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? ;-) J'ordos 14:09, 24 July 2008 (PDT)

You can try this version: File: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 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 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 ;-) 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. 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? 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 :-) 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)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. 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: [1]

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 ;-) 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: File:RunXcomW.zip with a simple explanation. Hope you don't mind.--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! 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. 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? 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 :) 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 Hobbes 11:34, 14 September 2008 (PDT)

No success, doesn't surprise since I have the barest clue of what I should be doing. 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. Seb76 12:09, 14 September 2008 (PDT)

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. 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. 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). 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. 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. ^^ 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... ;-) 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 Range Based Accuracy will always apply to the HL

If everybody likes it, I'll got with that. Any comment? Seb76 09:16, 22 November 2008 (CST)

Sounds good to me. 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 ;-) Seb76 05:24, 23 November 2008 (CST)

Wish List please please please

New and Outstanding Requests

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

The Dmg/TU stats for Stun Fest look very sensible. Spike 08:54, 23 November 2008 (CST)

• 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. -NKF 03:10, 2 September 2008 (PDT)

Has this been completed via the "Don't Defend Bases" feature? Well it's one solution anyway. :) Spike 08:54, 23 November 2008 (CST)

• 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:
  • Free Manufacturing. Probably needs to add a check that the manufacturing project has >0 units before allowing it to start.
  • Robotic Manufacturing / Cybernetic Laboratories. I think this just needs changing an "X <> 0" check to a "X >= 0" check.
  • 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.
• 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.

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 Also

Wish List

Completed Items - Thanks Seb!

• 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. 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 :( Seb76 07:19, 7 September 2008 (PDT)

Update: feature almost complete, time to bake a new version ;-)

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. Seb76 07:47, 13 September 2008 (PDT)

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. 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 ;-) Seb76 07:19, 7 September 2008 (PDT)

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? Spike 02:00, 2 September 2008 (PDT)

Facility maintenance cost bug

Could you fix that? 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? 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. --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. Seb76 16:53, 17 September 2008 (PDT)

Edit: Done. What's next? ;-) 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: [[2]], "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! 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? -NKF 00:48, 19 September 2008 (PDT)

such as? 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. -NKF 12:39, 19 September 2008 (PDT)

---

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 File:UFOExtender-dev.zip 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. :-)--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 ;-) 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. --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? 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 ;-) 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?

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? -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 ;-) Seb76 03:40, 27 September 2008 (PDT)

Request For UFO PS Explosion Offset

Hi Seb, in the 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. 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! --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! 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 and View All Locations 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 ;-) Seb76

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, nor beaten up any aliens in melee, but I will let you know how that goes. Thanks for all your amazing work! 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? 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? Seb76

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 :-) Seb76

• A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. 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?). It's the normal, bottom of the map edge kind. Here is a screenshot (anyone got a freeware TGA converter?).

Most likely because of the 2x2 base element. I'll have a look at that. 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. 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. Seb76