Bomb Bloke

kyrub and Tycho provided me with plenty of data afterwards. I wouldn't've been able to merge UFO with TFTD if not for their efforts.

Sure it's "easiest", but it requires knowledge and experience that most people will never have. Heck, I've been programming since before I hit my teens; but "regular programming skills" don't cut it when it comes to reading op-codes. It took less time to nail down certain data points via empirical research than it would've to learned how to read the code directly. Well, certain data points, anyway. "All of the ones I was interested in"? A different story - so I do regret failing to learn machine code. For example - firing accuracy. We all did tests on it. I did some seriously convoluted ones, writing custom software and automating thousands upon thousands of shots to generate enough data for just a notion as to the "real" chance to hit. It wasn't until kyrub weighed in with what he'd read from the code that I could say "yes, that's how it works!", though. And, um, then I never got around to integrating that information into a rather more visible article. But no one's contradicted the formulas I posted here yet, and I was pretty quick off the mark in figuring them out using observations alone... I do take a small measure of pride in that. Mind you, these "newer" games are far simpler than the originals. It's more precise to just say that formulas derived from decompiled code should be tested for accuracy to guarantee a complete reading. In theory, a thorough analysis will cover all edge cases. In practise, a thorough analysis will only ever be performed if plenty of testing is done on any proposed results. The issue is that just as it's difficult to be sure that the formula you've found in code is the only *relevant* formula unless you observe the in-game behaviour, likewise it's difficult to determine how many formulas are producing in-game results without in turn reviewing the game's code. But that led to a more realistic and in-depth game (certainly compared to the modern titles) - the developers threw in a bunch of principles, play-tested a little to make sure they more or less worked, and then called it a day. If you'd asked any of them, even at the time of release, what the odds of hitting a Sectoid at a given range with a given weapon through a set of different terrain obstacles were, they'd've had no idea. Half of the relevant details weren't solved until well after the bullet was already in the air. Even today I'm sure there are game mechanics buried in there which no player has a clue about. They came about around the same time as OpenXcom really seemed to be taking off. Personally I felt like a member of an older generation watching a younger one take over - happy to provide help when asked, but I didn't see any need to impose myself on them, as much of what I had to say related to games they just weren't playing. For a time there was a renewed interest in image editing tools and then that was that. This sums things up rather well, perhaps. The bulk of my own research has been filled in around the documents you wrote before I got started. There's a reason you're called NKF-sensei. I would like to think that if anyone cares what "Bomb Bloke"'s done, then I've left enough of a trail around the web that it's not all that hard to figure out. I don't much care about anyone who can't (ie most people), as they'd be unlikely to have any interest regardless. Which is fair enough.

Technically yes, but its reactions are terrible. It's much more likely that the tank will be scrapped. That plus the Manta.

Beats me, though I'd imagine it's the same deal as with the Extender's other developers (Seb an kyrub): they lost interest over time and drifted off. It's been a fairly long running project. In my experience, though, if you stick around long enough everyone drifts back eventually.

Oh yeah, certainly it's "possible". Problem is that Tycho's developed an uncommon skill set. Occasionally coders on a similar level come through the boards, but they're the exception rather than the rule. Don't get me wrong, anyone can learn that sort of stuff, it just takes a fair bit of time and effort to do.

Correct. Most of what we've got documented consists of tables of information - not "code" as such, but simple raw data that the developers chose to embed into the executable files. Actual instructions determining how the game behaves are much, much harder to "read". I suspect this sort of thing might be a bit easier to edit with OpenXcom?

Research.dat is part of your game saves; it covers what you've researched, but doesn't control how the research tree itself works. That's covered by the executable, but unfortunately, editing most compiled code is a bit beyond the knowledge of the average modder.

One of those magic cameras that can record all angles at once would be pretty cool. I could use my cardboard viewer... https://support.google.com/youtube/answer/6178631?hl=en

I'd imagine it's the same deal as with the last map - you've still got XCU rigged to implement more terrains into sub missions.

The game uses paletted graphics; every pixel in a sprite has a number attached to it that points to a colour in the current palette set. When you're on land, these colours tend to be brighter; a slightly darkened and tinted set is used when performing an underwater mission, and gets it darker still if you're somewhere in the deep sea. Night missions also shift things around a bit, but they don't switch the game to an entirely different palette as the different depths do. So making the hull of a cruise ship appear to be underwater would typically just be a matter of changing the map's depth setting from "land" to "sea", and hey presto, everything's blue-ish. Catch is that this is another "per map" flag - you can't make pockets appear using the land shading, it's another whole-map-or-nothing deal. To my mind, the way to go would be to simply make it an above-water map with random "wave" tiles placed throughout it (their positions could even be randomised on the fly, cutting off select passages each time such a mission starts). It's possible to make some tiles passable to some units but not others, so civilians could be kept in check. I think it'd look a bit odd, though. To my mind, once any decent amount of water starts coming in, I'd expect the boat to sink nearly immediately - and really the "wave" art pre-existing in the game might look a bit out of place.

Yes, that's an XcomUtil map.

Where ever you're comfortable.

That doesn't sound right... are there any ship parts around the place, or even a hole where the ship should be? To my memory the island terrain set is too large to load alongside that of a USO... Normally when you go to start a mission, the game dumps a temporary save of sorts into its MissDat folder, then loads that data up again as it transitions to tactical combat mode. If the game happens to crash just before writing that save (as it sometimes is wont to do), the tactical engine will find the save from the previous battle you played and end up loading that. Ring any bells? Then there's whatever XcomUtil might be doing, though unless you've activated "random terrain" or somesuch I wouldn't expect that to be involved here. I could tell you more with access to a mid-mission save accompanied by whatever's in the MissDat directory.

You can "effectively" kill them by destroying the corpse item, but that requires an explosive. There's just no other way; items lack the 3D LOF data required for a regular weapon to connect with them.

The medkit can target them, but they'll indeed stay unconscious anyway. Once they're down they're staying down.