User:Renegrade

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

Various Utilities

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

dirt.exe

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

Paperdoll Improvement Project

Enemy Unknown

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

To do:

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

Done:

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

I'd love to commission Niklas Jansson (Examples) to this end.

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

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

TFTD

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

NameStat

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

UnitScan

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

Mission Item Recovery Enhancement

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

Example 1:

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

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

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

Example 2:

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

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

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

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

Z-Com

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

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

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

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

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

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

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

Random Z-Com thoughts

(things to consider implementing in Z-Com)

The bug that lets one access a bad inventory (aliens/HWPs) could be fixed in one of two ways, user selectable in config menu:

prohibit access to the inventory entirely. Skip over it when toggling through troops.
allow access to the inventory, but with proper item storing(ie aliens don't stick things in that one slot at their feet), a proper paper doll (ie NOT MAN_0M0), etc

Show the current AND expected stock in the Buy screen; ie, including transfers 'in flight' to that base. Could work one of two ways:

Show it as non-summed items. Ex: Rifle Clip 14 (20) --> 14 rifle clips at the base, 20 en route via transfers from purchasing or other bases.
Show it as summed items. Ex: Rifle Clip 14 (34) --> 14 rifle clips at the base, with 20 enroute = a total of 34. I tend to favor this approach as it eliminates the possibility of faults with mental math.

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

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