Difference between revisions of "User talk:Bomb Bloke"

From UFOpaedia
Jump to navigation Jump to search
 
(34 intermediate revisions by 6 users not shown)
Line 2: Line 2:
 
Here be a list of images and / or pages that I think can be deleted safely (because they've been replaced with other files or links, or created by accident).
 
Here be a list of images and / or pages that I think can be deleted safely (because they've been replaced with other files or links, or created by accident).
  
−
<i>None at the moment.</i>
+
*[[:Image:SCANG.gif‎]]
 +
*[[:Image:SCANG_(TFTD).gif]]
  
 
= You Have New Messages =
 
= You Have New Messages =
Line 15: Line 16:
  
 
= Firing Accuracy =
 
= Firing Accuracy =
−
Consider this a draft/discussion on firing accuracy. This topic has been dragging on for quite some time now, so I figure it to about time I had a stab at it.
+
Section moved [[User talk:Bomb Bloke:Firing Accuracy|here]] so that this user page doesn't take so long to load on my poor slow internet connection.
  
−
My view on the matter is this: When you fire a gun, UFO works out the horizontal and vertical angles between your unit and the target, then modifies these depending on your [[Accuracy_formula|overall accuracy stat]].
+
= Can't get Hybrid to work =
  
−
Say for example you have a perfect 100% (or better) "accuracy". The lines are nearly unmodified, and so near guaranteed to hit (assuming there are no obstructions, in which case you <i>should</i> get a "No LOF!" message when you attempt to fire. Note that the game doesn't ALWAYS give this message and will sometimes allow you to attempt "impossible" shots. In these cases, less-then-perfect aim might still allow the shot to land).
+
Hey BB, I've downloaded your Hybrid program but I can't seem to be able to run. I got latest Java, I unzipped Hybrid to the UFO folder and I have changed the Hybrid.bat file to:
 +
set CLASSPATH=D:\Terror\
 +
Every time i ran it though I get an exception- Can you please tell me what i've been doing wrong? [[User:Hobbes|Hobbes]] 10:34, 22 March 2008 (PDT)
  
−
As your rated accuracy decreases, target size and distance become all important: As size decreases and distance increases, the range of angles that could land a hit fall. As accuracy decreases, the range of angles that a shot can take rises and so it becomes less likely that a given shot will fall within the "hitting" range of angles.
+
----
  
−
(As for why multiple angles can "hit", think of your target as a dartboard: Perfect aim would result in a bullseye, approximate aim would still hit the board, and bad aim would miss altogether. However, in X-Com, you get full "points" so long as the bullet hits the target at all).
+
Edit edit edit, I forgot how this thing worked...
  
−
That is to say, the ultimate firing accuracy formula would be (range of acceptable hitting angles)/(range of possible firing angles). Assuming, of course, that when firing you're just as likely to fire at your maximum "worst" angle as you are your "best", the range of angles that can hit is determined by target distance and size, and the range of angles that can be fired along is determined by your rated firing accuracy.
+
Ok, extract the archive into your game folder, open up a prompt window. If UFO is in D:\UFO, the program should end up in D:\UFO\Hybrid. Change to that folder and run it with the other game's path as a parameter. eg:
  
−
However, as it turns out, the angle your shots take isn't entirely random - they follow a bell curve. You're more likely to at least hit near the target then you are to get a massive "air ball" shot. So the formula in truth will end up looking a bit more complex then that.
+
Hybrid D:\Terror
  
−
== Firing Point Origin ==
+
If that gives an exception, lemme know what it is.
  
−
To get the absolute range of angles a unit can fire along, you first need to know where a unit is firing from. To this end I created a copy of my game folder and modified a save game, some terrain files, and the LOF templates.
+
The classpath line should be left as it was. It's just required on some systems for java to work correctly.
  
−
[[image:BBFiringPointTest2.png|right|thumb|200px|A basic map of a tile. As it turns out the Y axis really points the other way.]]Now, when we talk about UFO maps, we generally refer to their dimensions in terms of how many tiles there are. However, each tile is really made up of smaller "points": A 16x16x24 point space. This means that a 30x30x4 map has 3,600 tiles in it, and 22,118,400 points within those. When a unit fires, he doesn't aim from his tile at his target's tile, he aims from a point <i>within</i> his tile at a point within his target's tile.
+
- [[User:Bomb Bloke|Bomb Bloke]] 16:17, 22 March 2008 (PDT)
  
−
This first test was aimed at discovering exactly where a shot originates from, by creating tiles on units to selectively block their LOF. By seeing which tiles did and which did not, it could be seen exactly (or, at least, as accurately as I think I'm going to get it) where the shots were coming from.
+
= Inventory screens =
  
−
[[image:BBFiringPointTest3.png|right|thumb|200px|The Empire's got nothing on BB's clone army.]]The first row of units served as targets for the second, which stood on tiles similar to the large earth blocks you see in bases but with one layer removed from each. Each therefore entirely blocked LOF <i>so long as</i> the removed layer wasn't at the same height as the unit's firing origin point. The only unit able to fire through the gap was the one sitting on the tile with the <b>third layer down removed</b>.
+
Hi Bomb Bloke
  
−
However, when defining tiles with [[LOFTEMPS.DAT|LOFTemps]], you can only stack the layers 12 high. Presumably the game "double stacks" them to make the resulting 24 point high object. Because of this, the removed layers accounted for <i>two</i> possible Z co-ordinates, meaning the exact value there is still unknown. Might be able to work something out to get it more precise, I dunno.
+
I really love your Map editor, which in fairness is a full Battlescape editor. It crashes for me a lot but probably that's because I have other mods messing with the files.  
  
−
The third row stood on walls facing to the east/west. Unlike the second row, in this example I moved a single thin wall through each tile, as opposed to moving a "gap". This meant that only one unit would not be able to fire, and that was the one sitting on the <b>ninth tile</b> (made up of my layers from LOFTemps[<b>15</b>]).
 
  
−
[[image:BBFiringPointTest1.png|right|thumb|200px|LOFtemps used, as opposed to the [[LOFTEMPS.DAT|usual set]].]]The forth row followed more or less the same concept, with the walls facing north/south. Only the <b>first unit</b> was unable to fire (LOFTemps[<b>23</b>]).
+
My question is - do your cool Inventory screens work with the actual game? I would love to see my weight and TUs while loading up my guys. Otherwise you need paper and pencil and printouts.  
  
−
So! With this information, getting a (x,y,z) co-oridinate is easy enough: It's either <b>(8,15,18)</b> or <b>(8,15,19)</b> (the Z co-ord being imprecise due to the 12 LOFTemp layer limitation).
+
thanks! [[User:Spike|Spike]] 11:28, 25 March 2008 (PDT)
−
 
 
−
Note that this value only goes for units with a facing of north. When I get time I'll go through and work it out for the other directions. Furthermore, Sectoids are likely to have a lower firing point (as their guns are rendered lower on the screen).
 
  
 
----
 
----
  
−
[[Image:origins.png|frame]]
+
The alien portraits do, the editor tweaks the save files so the actual game will use them. I'll be making that optional though (because if the saves are then transferred to a system that doesn't have the extra graphics the game could crash).
  
−
I found an interesting piece of code (offset 40D8E0 for the curious). The formula for the starting zpos when firing looks like this:
+
I'm afraid I can't add the weight display stats to the original game. [[User:Seb76|Seb76]] or one of the other machine coders out there might be able to pull it off, but it's a big ask (right up there with adding stuff to the tech tree).
−
''unitpos.zpos*24+unitref.terrain_height-unitref.standing_height+27-unitref.floating_height''
+
:You mean stuff like that? [[Image:Ufo weight.zip]] ;-) [[User:Seb76|Seb76]] 18:09, 28 March 2008 (PDT)
−
and for kneeling units:
 
−
''unitpos.zpos*24+unitref.terrain_height-unitref.kneeling_height+27-unitref.floating_height''
 
−
(unitref.terrain_height is offset 0x27 in unitref.dat)
 
−
I did a live check with a debugger, for a standing unit on the lowest level it gives this:
 
−
''3*24+0-16+27-0=77''
 
−
Since the engine seems to use zpos=0 for the ceiling of the topmost level, then the floor must be at offset 4*24=96. floor_level-firing_level=96-77=19, in accord with your empirical results.
 
  
−
Now for xpos and ypos, the engine uses several tables, indexed by the facing orientation (offset 0xa in unitref.dat):
+
::That's pretty impressive... :O Reckon you could get it to display unit strength as well? [[User:Bomb Bloke|Bomb Bloke]] 20:53, 28 March 2008 (PDT)
−
''.data:0046B5E4 dw  8,0Eh,0Fh,0Fh, 8, 1, 1, 1''
 
−
for xpos, and
 
−
''.data:0046B5C4 dw  1, 1, 8,0Fh,0Fh,0Fh, 8, 1''
 
−
for ypos. When facing north, the shot should come from 8x1x19. Note that it is in disaccord with your experience. Maybe you don't use the same point of origin as the engine? [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)
 
  
−
----
+
::: You are correct, I could have done it. Have a look at the updated version ;-) [[User:Seb76|Seb76]] 10:23, 29 March 2008 (PDT)
  
−
You are correct. Moving my origin to match yours brings my data into line (I was limited to guessing it's correct location). Awesome to see the ceiling size confirmed at long last. :D - [[User:Bomb Bloke|Bomb Bloke]] 02:52, 8 May 2008 (PDT)
+
:: That's nearly perfect, but... well, there's always a catch, isn't there? ;)
  
−
----
+
:: For whatever reason, the weight carried by some troopers won't display. Here's a sample save game: [[Image:GAME_4.zip]] (check the guy in front of the ramp). I've tried loading up the units in concern and they do get their TU penalty if I go over their limit, but the weight carried always shows up as "0" on their inventory screens.
  
−
Big units use 2 other tables located at offsets 46B604 and 46B624. I did not try to change these values to see if it changes the position where the shots come from. [[User:Seb76|Seb76]] 08:44, 3 May 2008 (PDT)
+
:: In most of my saves (just about any that involve flying suits) it doesn't work for any units. [[User:Bomb Bloke|Bomb Bloke]] 19:53, 29 March 2008 (PDT)
  
−
----
+
::: I'm using offset 0x28 of unitref.dat to get the soldier.dat index (to in turn get the carried weigth via an already builtin function). Strangely it is set to 0xff for some units. Did you mess too much with this file? Or maybe offset 0x28 is not yet completely understood. [[User:Seb76|Seb76]] 02:07, 30 March 2008 (PDT)
  
−
The xpos/ypos information agrees with my own <i>in vivo</i> research (it explains several LOS different than LOF paradoxes I have explicitly verified). -- [[User:Zaimoni|Zaimoni]] 11:49, 3 May 2008 (CDT)
+
::: I think I nailed it. Care for another try? [[User:Seb76|Seb76]] 02:42, 30 March 2008 (PDT)
  
−
== Rated Accuracy Vs Angle Range ==
+
:: Yes, this one seems to be working perfectly. Mind if I build it into a patcher tomorrow and stick it up on StrategyCore, so it can be used with other mods? (or does it add code to the end of the executable, like Mok's does)?
 +
::: Some code is added in the executable in a padding section (unused space in the binary) so the file has still the same size. It'll conflict with other patches if they use the same place in the executable to inject their code (the patch specifics are available on the download page). I have no account in SC so I don't know what other mods do... Perhaps a bit of testing is required before posting this (does it works if you MC an alien and go to its inventory screen?). [[User:Seb76|Seb76]] 10:09, 30 March 2008 (PDT)
  
−
[[image:BBFiringPointTest4.png|thumb|200px]][[image:BBFiringPointTest5.png|thumb|200px]]Just a few results before I go off camping for the weekend. First off, note that [http://www.strategycore.co.uk/forums/index.php?act=ST&f=22&t=5805 the logger] used on this occasion is one I wrote up a year ago. It's not entirely accurate, and needs to approximate values (this is because I can only get it to think in terms of angles between tiles, as opposed to angles between points - as a result you see "steps" in the line graphs provided here). I've thought up some improvements for it (like sticking a roof in the map used so I can get some decent vertical angle stats), but even if I implemented those it'd still never be "accurate".
+
:: That offset isn't used by non-X-Com troopers (the trooper in front of the ramp was created with my editor, which "wipes" that offset for clones). So it should've also failed for civilians and aliens.
  
−
That said, I got [http://pastebin.com/mcbc752a 2550 results for 0% firing accuracy] overnight and [http://pastebin.com/mdf60034 1876 for 50%] today. I've got the system in concern running trials for 25% until tomorrow.
+
:: Not sure why it failed for my flying suit troopers. I was starting to think large units might've been messing up the calculation. [[User:Bomb Bloke|Bomb Bloke]] 08:34, 30 March 2008 (PDT)
 +
::: The first version was faulty anyway: it used the soldier.dat entry index instead of unitpos index. It worked as long as noone died else things start to get out of sync. [[User:Seb76|Seb76]] 10:09, 30 March 2008 (PDT)
  
−
The graphs displayed summarise these angles. Essentially they go from "those that went to the left" across to "those that went to the right". The longer the line stays at a given level, the more shots took that angle.
+
If you know specific methods to crash the editor, or have certain save games it won't load, I'd love to see them. I'm forever working bugs out of the thing but I'm limited in that I never get any actual bug reports. :(
  
−
At 0% accuracy, the largest horizontal angle I got AWAY from the target was 27.5 degrees (that is to say, a shot could go anywhere within a range of 55 degrees), the average angle being 7.32 degrees. With the side graph you can get an idea of the distribution: Your shots are more likely to hit or at least get close then they are to be far away.
+
I do know that it probably won't load XcomUtil based saves that use alternate terrain sets (eg. Hobbes's maps).
  
−
Bumping the rated accuracy to 50% lowered the maximum angle to 17.01 degrees (average of 2.75). Again, you're a lot more likely to get close to the target then you are to reach the possible extremes.
+
- [[User:Bomb Bloke|Bomb Bloke]] 19:02, 25 March 2008 (PDT)
  
−
I've since done tests at 100% accuracy and found that the same curve exists, just squished right down. You still have a chance to miss, but only by slight amounts. A formula should be apparent in there somewhere.
+
----
 +
Thanks BB. What tends to happen is the editor hangs during file load, on the saved games list screen. The only clue is that the mouse pointer is visible/movable(normally the pointer disappears during file load). Back in the BBmap_edit.bat Dos window, it will have an "Array out of bounds" error (generic, I know). Will try to get a reproducible bug and send you the game save dir. Cheers, [[User:Spike|Spike]] 01:56, 27 March 2008 (PDT)
  
−
At a glance I think it's an exponential equation divided by your rated accuracy? With a few more tests I suppose it'd be more apparent.
+
=Categorization Guidelines=
 +
Hey BB, I've noticed that you've removed some categories from a few pages and stated you reason as 'redundant categories'. My first thought was that there isn't such thing as a redundant category (the more the merrier since I see them as tags for the articles that help connect common theme pages together) but I've been reading Wikipedia's policy regarding categorization and while I do not agree with all aspects of their policy I think it might be better if we set a common guideline of our own. What do you think should be accepted regarding categorization? [[User:Hobbes|Hobbes]] 13:06, 18 December 2009 (EST)
  
−
: My theory is this that the program first runs "was shot accurate?" check. If yes, then shot deviates 0 and hits the target. If shot misses, calculate path of bullet. Path of bullet follows formula that gives that bell curve.
+
----
−
: I rather suspect that at 25% accuracy, 25% of your shots will be on target, at 50%, 50% will be on target, so on and so forth.
 
−
: There might be some additional weird "random drift" that makes 100% and higher accuracy still miss. *Shrugs*. - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
 
−
:: I am absolutely convinced that there is no "was shot accurate?" check. If there was one, I reckon it'd be apparent on the graphs here. I could be wrong, but I believe I've seen no data that supports the theory. No, finding that a certain accuracy rating "seems right" when firing from a certain distance is not supporting data, in that this is the case regardless of whether an "accurate shot" check exists. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
 
−
: Despite the fact it will make your life even harder, I have to remind you that there is also PARTIAL COVER to factor into the tests... what happens when the target is behind a window (modded to be indestructible?), behind a hedge, only his head is visible poking out through the floor (bug here lol)... sometimes a shot will go THROUGH a window, sometimes it will HIT the window... - [[User:Jasonred|Jasonred]] 11:07, 15 March 2009 (EDT)
 
−
:: Remember, the "accuracy formula" I'm looking to determine simply returns an angle, which, dependant on your overall accuracy score an the random number generator, will go off on some who knows what direction. Whether that angle leads to the target is dependent on the visible target area versus the angles you'll get based on your accuracy stat (this "target area" concept is the purpose of the next section down, mostly unwritten because it's pointless until THIS formula is figured out).
 
  
−
:: That is to say, there's no real formula that can tell you the REAL chance to hit a target without actually inputting all the tile data in addition to using the "angles formula" I'm after here. Luckily, once the angle formula is determined, it shouldn't be too hard to have my battlescape editor calculate the "true" chance of a shot hitting. - [[User:Bomb Bloke|Bomb Bloke]] 11:25, 15 March 2009 (EDT)
+
The way I see it, pages should be in as few categories as possible, and preferably child categories at that. If you want an example as to why, take a look at the [[:Category:Apocalypse|Apocalypse]] cat - it's downright ''broken''. Page one tells you there are 199 articles - there's actually 271 at present (and four sub-cats, only ''one'' of which is visible on the first page - hardly intuitive for finding stuff!), but you won't be given that information unless you jump to page two. And as for using a list like that to locate articles on a specific theme? There's too much junk to read through, you can only get anywhere if you already know exactly what you're looking for!
  
 +
In comparison, try looking at the [[:Category:Enemy Unknown/UFO Defense|Enemy Unknown/UFO Defense]] category. You should find it dead easy to get to a page about any given topic that's categorised in there, even if you didn't start out knowing what it was called. Obviously I still consider there to be some more work to be done (base modules, X-COM craft + their weapons, not to mention the game files), but I'm sure you get the general idea of how that style of things affects practicality.
  
−
: I wonder if it's possible that the game's maximum firing angle (e.g. at zero accuracy) is one radian - about 57.3 degrees? This is near your observed limit of 55 degrees. The game engine would probably use trig functions based on radians as I believe they are the most efficient. Given the power of the computers they were programming for, this vector work was pushing the envelope so they would need to be efficient. - [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
+
If an article looks like it belongs in two categories, ask yourself - should one of those categories actually belong in the other as well? If so, then the article certainly doesn't need to be placed in both.
−
::I would say that yes, given the close proximity (and the inherent inaccuracy of my logger, due to the inability to pick up on the precise ''point'' a bullet hit), one radian is correct.
 
  
−
::The [[COS.DAT]] page will probably be relevant at some point, dunno if you've read that. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)
+
We also had not one, but two categories for UFO - one called "Enemy Unknown/UFO Defense" and one called just "EU". I've since moved all articles out of EU.
  
−
:Also could you clarify the axes on these 2 graphs/histograms? I'm having a lot of trouble understanding them. Is it possible that the vertical axis should be frequency, and the angle should be on the horizontal axis? Or am I being dumb? If I'm understanding them correctly, we are not seeing a linear distribution of error angles - as you would get from say
+
Ideally, all categories will eventually link back to one "master" category, sorta like how all articles lead back (eventually) to the main page.
  
−
ActualAngle=AngleToTarget+(rand(57)-(57/2))  
+
-[[User:Bomb Bloke|Bomb Bloke]] 17:57, 18 December 2009 (EST)
  
−
:what we are getting is angles that cluster together near the correct aimpoint, and frequency falls off quickly as you move away from the correct aimpoint.
+
----
  
−
:: You are reading the charts correctly. The vertical axis shows how often a specific angle was picked to fire along by the game, and the horizontal axis shows the angles themselves. The reason the charts are symetrical is because shots can either go to the left or right of the target (an angle of 0 means it hit). Even with 0 FFA, you're a lot more likely to send a bullet near the target then you are to send one on the maximum diverging angle - hence my statement, "I think it's an exponential equation divided by your rated accuracy". - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)
+
OK, makes sense, my idea originally for the categories was that we should look at them simply by looking into the page elements and creating cats for each for them, making as much associations between pages as possible (an 'horizontal' view, i guess). Your 'vertical' helps to keep things tidier but at the same time i'm wondering if it doesn't prevent the creation of common categories to which all games can be related. [[User:Hobbes|Hobbes]] 17:50, 19 December 2009 (EST)
  
−
:Guess: The graphs look not unlike a tangent or inverse tangent function. That might suggest that the firing function injects a linear amount of perpendicular drift (horizontal and maybe vertical) onto the bullet's vector. Maybe try graphing the tan() or arctan() of the data from the "zero accuracy" tests, and see if you get a horizontal straight line.
+
----
  
−
: arctan (0.5), which might be relevant if maximum "perpendicular error" is 1 map square wide per map distance unit, is 26.565 degrees, near to your value of 27.5 degrees. Arctan (0.25), which corresponding to half that "perpendicular error", half a map square wide per map distance unit (and maybe corresponding to 50% FFA????), is 14.036 degrees, again near to your value of 17 degrees for 50% FFA. But only 'near', and higher. Hmm. Your data have a horizontal granularity of 1/16th of a map square distance unit, is that right? So there could be some data slightly outside the true upper limit for angles. It depends on the range to your target in your test setup I guess. [[User:Spike|Spike]] 11:28, 15 March 2009 (EDT)
+
It allows for common categories ([[:Category:UFOs/USOs|assuming you mean stuff like this?]]), but unfortunately most of the obvious names to use for them are dedicated to UFO:EU articles - meaning a whole bunch of pages need to be moved to allow for it.
  
−
:: This is where my brain starts to melt, mind you, it's 3:15am here so I'm probably not good for any number crunching right now. But I reckon you're onto something even if I can't wrap my brain around what!
+
But what the heck. I'm up for that.
  
−
:: I put the target about 25 squares back (middle of the map). Really can't remember. Ideally I'd've set him to be a pixel in size, but back then the "using LOFTemps for unit size" thing was just a theory I had, not a proven fact (I never got around to updating this page when it WAS proven, that's how long these notes have been here).
+
- [[User:Bomb Bloke|Bomb Bloke]] 17:55, 19 December 2009 (EST)
  
−
:: Yes, granularity is a 16th of a standard user-visible map tile. On the horizontal plane anyway. Can't remember if I set it to 24ths on the vertical, but I probably did. The problem is, of course, that it can only pick up data according to whether a bullet hit a tile or not (as opposed to data on where the tile was hit), so although the range of angles should be "close to accurate" there's still those nasty steps everywhere which have to be "guesstamated".
+
----
  
−
:: I never really bothered much with the vertical data as I was mostly "proving the concept", figured I'd get to that later. I know I logged it (I was even able to draw an ellipse to show where all the bullets would fall, your maximum vertical angles are of course no where near your maximum horizontal ones), but I can't find the charts in concern. They weren't that good anyway as the test map had no ceiling.
+
Come to think of it, I'm tempted to just scrap the [[:Category:UFOs/USOs|UFOs/USOs category]] and just throw the contents in the generic [[:Category:Craft|Craft category]]. Can't see the need to have both. - [[User:Bomb Bloke|Bomb Bloke]] 18:08, 19 December 2009 (EST)
  
−
:: I distinctly remember logging and graphing the 100% FFA data but can't find that either. Probably deleted it from my system (in the misguided belief that I'd uploaded it all here). I cannot find any of my related logs at all, in fact, just a single zip file with the logger, test map and automated script file ready to go. Again, this may be because I've deleted them, or because I have nearly ten thousand files in my UFO directory. My main one, anyway. I have a few such directories. - [[User:Bomb Bloke|Bomb Bloke]] 12:14, 15 March 2009 (EDT)
+
----
  
−
: OK. The curve you graph above for "zero accuracy" looks not unlike what happens if you graph tan(x) (in degrees), where x is from +0.5 to +0.5. But I think that's a coincidence, since your graph is not a standard histogram - you are showing "frequency" by the length of lines on the x axis, rather than by the height of bars along the y axis as in a standard histogram. In order to turn your graph into a standard histogram it would need to be more or less inverted I think.
+
We now have a [[:Category:Main|primary category]]. - [[User:Bomb Bloke|Bomb Bloke]] 19:29, 19 December 2009 (EST)
−
: The link to the "zero accuracy" data set is broken now. From what you said above, the data is lost now, which is a shame as it would be nice to do a histogram of tan(a) for all the angles "a" in that data set. You might see a flat line, linear distribution. Or not. If the angles are "bunching up" in frequency toward the target centre, then that suggests a ''linear perpendicular'' distribution of angles. With a linear perpendicular distribution (eg varies by +/- 0 to N units, perpendicular to the path to target, per unit of distance), you would expect a "bunched" angular distribution, i.e. if you sorted all the angles in the data set, the separation between one angle and the next widest would steadily increase.
 
−
: The Z component is going to complicate things and prevent finding an exact solution. For example, say that the Z (vertical) error/cone and X (lateral) error/cone are not independent of each other. For example, they might be constrained to add up to some constant N that's related to FFA: Z + Y < N. Or in fact, it might be more like (vertical x 4 + horizontal x 1) < N (since we suspect the actual 'bullet group' is an oval, wider than it is high, rather than a circle). A circle is almost the simplest case, but again unless Z and X are totally independent, you're not going to find a close fit for the function without knowing both terms. Hopefully the oval is very 'flat' and so the horizontal-only function will be a good enough approximation of the data to get in the right ballpark. Or even better, maybe the Z component is a totally independent function. Hope so.
 
−
: Let me make a prediction or a series of predictions then for maximum angle off-target:
 
−
:*  0% FFA = 1.0 perpendicular error per unit distance = +/ 0.500, arctan(0.500) = +/- 26.6 degrees
 
−
:* 50% FFA = 0.5 perpendicular error per unit distance = +/ 0.250, arctan(0.250) = +/- 14.0 degrees
 
−
:* 75% FFA = .25 perpendicular error per unit distance = +/ 0.125, arctan(0.125) = +/-  7.1 degrees
 
−
:* in general, horizontal maximum angle off target =  +/-  arctan(((100-FFA)/100)/2)
 
−
: Well that's most likely wrong but it's good to have a starting point for testing! [[User:Spike|Spike]] 17:40, 15 March 2009 (EDT)
 
  
−
Hey, guess what? First thing on completing a fresh round of tests, I discover all my old logs.
+
----
  
−
Of course.
+
OK, it's making sense to me right now how the Category: Apocalypse should be reorganized. It is still a mess but it helps that you don't have to look for all Apoc related pages since they are already there :) [[User:Hobbes|Hobbes]] 20:24, 21 December 2009 (EST)
−
 
 
−
Originals (with no roof on the map so the vertical shot data is a bit iffy): [[User_talk:Bomb_Bloke:0acc1|0%]] - [[User_talk:Bomb_Bloke:25acc1|25%]] - [[User_talk:Bomb_Bloke:50acc1|50%]] - [[User_talk:Bomb_Bloke:75acc1|75%]] - [[User_talk:Bomb_Bloke:100acc1|100%]]
 
−
 
 
−
New data (with a roof, vertical shot data might actually be worth something): [[User_talk:Bomb_Bloke:0acc2|0%]] - [[User_talk:Bomb_Bloke:25acc2|25%]] - [[User_talk:Bomb_Bloke:50acc2|50%]] - [[User_talk:Bomb_Bloke:75acc2|75%]] - [[User_talk:Bomb_Bloke:100acc2|100%]]
 
−
 
 
−
Comma separated data, one shot per line. First three columns are the absolute tile x/y/z co-ords of where the shot ended up hitting (keeping in mind the shooter is at tile 24/49/2). Next three columns are the x/y/z of where the shot landed, relative to where the shooter is. Final two columns are the important ones, they cover the horizontal and vertical angles the shot took, respectively.
 
−
 
 
−
Yes, the wiki doesn't represent it very neatly. Use the edit button to get the line breaks back.
 
−
 
 
−
Hrm. Looks like the max angle at 75% comes out to 11.53 degrees... Not 7.1. :(
 
−
 
 
−
- [[User:Bomb Bloke|Bomb Bloke]] 09:37, 18 March 2009 (EDT)
 
  
 
----
 
----
  
−
[[image:BBFiringPointTest6.png|thumb|200px]]
+
Indeed. There's a couple of hundred pages related to the other games that simply aren't sorted at all. - [[User:Bomb Bloke|Bomb Bloke]] 06:33, 22 December 2009 (EST)
−
Here is a graph that somewhat better displays the results of my initial 0FA results. The blue line represents the recorded numbers (2550 different values). The red line represents an equal number of results generated by the spreadsheet formula "SIN(RAND()*1.5)*28.64788975*IF(RAND()>0.5;-1;1)".
 
  
−
(Which is, effectively, "The sine of a random number between -1.5 and 1.5 multiplied by half a radian").
+
=Windows 7 64-bit + XcomUtil + bb_tact=
 +
"This version of D:\games\ufo\BBReset.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."
  
−
Unfortunately the two formulas don't line up (even if you mirror 'em on the diagonal), but they're fairly close. Much closer then the exponential equations I tried graphing, at any rate. I'm thinking I might be able to get something better still with TAN, but I don't seem to be having much luck with that...
+
I'm getting the above message on every switch between geoscape and tactical when using your mod with XcomUtil. Does that mean your mod won't run, or am I doing something wrong? [[User:Rovlad|Rovlad]] 19:37, 5 May 2010 (EDT)
 +
:Nevermind, I figured it out after skimmering through .bat files a bit. For some reason your installer did not detect my system to be 64 bit (could be because it's not AMD-based). I've manually replaced BBReset.exe with BBReset32.exe and it works fine now.
 +
Cheers! [[User:Rovlad|Rovlad]] 20:31, 5 May 2010 (EDT)
  
−
- [[User:Bomb Bloke|Bomb Bloke]] 02:18, 15 April 2009 (EDT)
+
That's odd; last I knew, it used the same check that XcomUtil uses for its own executables. Having users manually moving files about isn't an ideal solution, so I'll have to take a closer look at it. Thanks for the heads-up. - [[User:Bomb Bloke|Bomb Bloke]] 21:10, 5 May 2010 (EDT)
 +
:No problem, let me know if you need any specific information on the system, steps taken during setup process or whatever. One thing for certain, XcomUtil has detected 64-bit correctly right off the bat. Perhaps your installer could just check for "64-bit system" flag from XcuSetup to set everything up accordingly? It would not be a perfect solution, but since running XcomUtil is the only way to use bb_tact with 64-bit system (at least for now), it probably still is a feasible thought. [[User:Rovlad|Rovlad]] 08:06, 6 May 2010 (EDT)
 +
:Actually, never mind that. I've digged a bit more and discovered that Example.txt file in \XcomUtil\Addon directory is a bit outdated in terms of detecting 64-bit OS. You can fix your installation script by taking a look at \XcomUtil\batch\SysCheck.bat to see how it handles system detection now. [[User:Rovlad|Rovlad]] 10:19, 14 May 2010 (EDT)
  
−
: tan eyeballs great if you assume the distribution going in is some flavor of "sum of linear distributions".  tan<sup>-1</sup>(25&deg;)=0.466307658155; halving this and taking the tangent again gets me ~13.1&deg;, which is reached about 1/16th of the way across.  I'm assuming some sort of discretization error for the asymmetry.  (My initial gut reaction was "sum of two linear distributions", but that isn't correct; that would have landed about 1/8th of the way across.  The quick-and-dirty way to fake a bell curve is to sum three linear distributions.) -- [[User:Zaimoni|Zaimoni]] 11:52, 15 April 2009
+
=Night vision goggles for soldiers during night missions=
−
(CDT)
+
Hello there again.
  
−
: Per geometric check; tan works if the incoming angle is from a sum of three linear distributions.  That is: tan(K*rand()*rand()*rand()) should recover the graph up to discretization error, for some K. -- [[User:Zaimoni|Zaimoni]] 12:02, 15 April 2009 (CDT)
+
I have drawn some graphics today which replace several images to add night vision goggles on soldiers' heads (for overalls and personal armor troopers). There are 19 images for both xcom_0.pck and xcom_1.pck, 38 in total. I've compiled them into pck files for testing (using your tools, of course!) and they seem to be working properly.
  
−
:: Is there any chance it's some function of (Kx rand(x), Ky rand(y), Kz rand(z)? [[User:Spike|Spike]] 17:53, 15 April 2009 (EDT)
+
Thing is, I'm not very keen in actual modding, and seeing as your camouflage mod serves the very similar purpose (being purely a visual enhancement), I was wondering if you would be interested in using these for your own mod. As far as I understand, it would require a pre-battle check to see if it's a night mission, and only use new graphics in this case.
  
−
::: It depends on what you mean...
+
Anyway, let me know what you think.
  
−
::: I was presuming rand() was a zero-parameter function that needed "massaging" to get to any range other than its default.  C rand() would be 0..RAND_MAX. XCOM almost certainly has a wrapper that returns values in a range 0..N.  Given when XCOM was written, I don't think it has any sort of floating-point RNG.  I wrote K to subsume all of the range-massaging that was needed.
+
- [[User:Rovlad|Rovlad]] 20:05, 14 May 2010 (EDT)
  
−
::: That said, a general sum of three linear distributions would have been tan(K1*rand()+K2*rand()+K3*rand()-AVERAGE) [ignoring overflow issues], where AVERAGE is the statistical average expected from K1*rand()+K2*rand()+K3*rand().  The geometric check almost certainly wouldn't pass if the three constants were obviously distinct.  The actual expression I'd try retrofitting is tan(K*(rand()+rand()+rand())-AVERAGE).  -- [[User:Zaimoni|Zaimoni]] 14:07, 16 April 2009 (CDT)
+
----
−
 
 
−
:::: If rand() was to receive any parameter at all, it'd be a seed; but calling the function three times should result in three different numbers anyway (typically you seed the RNG first).<br><br>I'd be surprised if even the original game didn't have a floating RNG. Even back on the Spectrums/Commodores/BBCs you could generate within most any range by typing something like RNG*N.<br><br>I tried graphing TAN(RAND()*1.5) then TAN(1.5*(RAND()+RAND()+RAND())-2.25), though the first formula wasn't right and the second was worse. :( It's a bit too steep (a little like what you get from 1/x but flopped around). Maybe something a bit higher then 1.5 would sort that out, but I dunno how high you can legally go with TAN? - [[User:Bomb Bloke|Bomb Bloke]] 20:36, 16 April 2009 (EDT)
 
  
−
::::: tan goes unbounded at &plusmn;&pi;/2 radians i.e. &plusmn;90&deg;  Given that the initial bounds appear to be ~&plusmn;25&deg;, I'd calibrate things so that we were looking at a total span of 50&deg; i.e. ~0.872 radians. In radians, with rand() being a uniform distribution 0..1: TAN(0.872*(rand()+rand()+rand())-0.436) would be my guess.
+
I think that sounds awesome. Right off the bat, you'd be able to tell whether night-rules were in effect for that battle or not, simply by checking how your soldiers are outfitted. Though, I don't suppose you could also update the [[Inventory_Backgrounds|SPKs for inventory screens]]? There's a tool in my pack for converting those back and forth, works much the same way as the PCK one.
  
−
::::: XCOM 1.2 had some source code comments indicating that the C source targeted Watcom C. That means the "easy rand" available is the C standard library rand(), which without processing returns an integer from 0..RAND_MAX, where RAND_MAX may be as low as 32,767. -- [[User:Zaimoni|Zaimoni]] 12:36, 17 April 2009 (CDT)
+
Actually, I could even take it a step further: Make it so that, when using the goggles, mission light-levels are capped at the point ''just before'' "night-time" rules come into effect. So that it's visibly "dusky" to the user, but your troops still have full range of vision (like when you're in a base defense mission for eg). It always seemed rather silly that soldiers didn't have ''some'' sort of attached visual aid (like, say, a flashlight).
  
−
===Vertical Error vs Horizontal Error===
+
- [[User:Bomb Bloke|Bomb Bloke]] 02:38, 22 May 2010 (EDT)
  
−
Hmmm.... I don't know about you guys, but I notice that in my games, when firing from Level 0 at enemies on level 0, my soldiers seem like their vertical deviation tends to be very small, even with high inaccuracy. Their horizontal deviation seems much much larger. Is this my imagination?
+
=Clean Up=
 +
If it is in your abilities can you erase all these Russian blank pages (and their discussions)? They are redundant and left after vandals invasion. Thanks. ---[[User:Ufo.mesh|ufo.mesh]] 05:32, 27 August 2010 (EDT)
  
−
- [[User:Jasonred|Jasonred]]
 
  
 
----
 
----
  
−
You're quite right, they're two different things. There's enough error there to miss at point blank range against a short target, but still nothing like what you get in the horizontal scheme of things.
+
=BBmod.bat error: "dont find xcloader"=
  
−
- [[User:Bomb Bloke|Bomb Bloke]] 08:46, 17 April 2009 (EDT)
+
I cant install the BB mod set. When I run the BBMod.bat, the game begins with the intro without sounds and I get a black screen. When swap to the desktop I see the error message: unable to locate "xcloader". But, the xcloader.exe is in the folder.
 +
I have xcomutil and the seb76 extended mod installed. I run xcusetup and recognices the BBmod. But when a mission beggins the game crashes: error, unable to find kevlar brown...(the BBMod.bat dont worked)
  
−
== Target Size ==
+
- user: man.manza (juny 2011)
  
−
Units are cylinders, made up of a [[LOFTEMPS.DAT]] layer determined by [[UNITREF.DAT|UnitRef[48]/[52]]], stacked according to their [[Height]].
+
:Sorry, I made some changes the other week and probably didn't test them too well before uploading.
  
−
The full purpose of UnitRef[52] is still in doubt, though it always seems to mirror the value held at [48]. My personal guess is that one is (or at least, was supposed to be) used when bullets come in on one angle, and the other value is used when bullets come in on a perpendicular-ish angle (hence allowing the cylinder to act more like a squished tube, which is closer to the shape of a real person - or it would do if 48/52 didn't always match).
+
:Am sick at the moment, and not really in the mood to smooth it all out. You should be able to work around the main issue though.
  
−
So, yeah, set [48] to 0, all your units get set to an empty LOFTemps record, they cannot be seen/hit by the aliens. Hurrah.
+
:Grab a fresh copy of [http://www.strategycore.co.uk/files/index.php?dlid=21 f0dder's loader]. In the "xcom1" folder of the archive, there's a file "patch.dll", you'll need to replace the one BBMod had with this. If you're running TFTD then don't worry about getting the new patch file.
  
−
== See Also ==
+
:There is no good reason why the batch wouldn't be able to find XCLoader, which is included in the toolkit archive now, so I'm assuming you're seeing the prompt to locate the game EXE instead... Either way I have no clue why the game would've started anyway.
  
−
Pages relevant to this subject:
+
:Anyway, if that doesn't sort things, odds are it's unhappy because you didn't run "UniGen.bat" from the bb_tact folder before starting the mod. I'd tried to rig things so that you didn't need to do this unless you wanted to use the uniform manager, but I may have messed that up - if so, you'll probably need to reinstall the game and try again from scratch (backup your save folders if you're worried they'll be affected).
−
*[[Firing Accuracy]]
 
−
*[[Accuracy formula]]
 
−
*[[Firing Accuracy Testing]]
 
−
*[[Height]]
 
−
*[[LOFTEMPS.DAT]]
 
  
−
= Can't get Hybrid to work =
+
:If you're still having trouble, I'll need some more info to go off. OS? Windows Collectors Edition, or through DOSBox? Which release of the game - Steam, GameTap, original disks/CD?...
  
−
Hey BB, I've downloaded your Hybrid program but I can't seem to be able to run. I got latest Java, I unzipped Hybrid to the UFO folder and I have changed the Hybrid.bat file to:
+
:By the by, you can automatically generate a signature for your comments by typing four tiles (<nowiki>~~~~</nowiki>).
−
set CLASSPATH=D:\Terror\
 
−
Every time i ran it though I get an exception- Can you please tell me what i've been doing wrong? [[User:Hobbes|Hobbes]] 10:34, 22 March 2008 (PDT)
 
  
−
----
 
  
−
Edit edit edit, I forgot how this thing worked...
 
  
−
Ok, extract the archive into your game folder, open up a prompt window. If UFO is in D:\UFO, the program should end up in D:\UFO\Hybrid. Change to that folder and run it with the other game's path as a parameter. eg:
+
:- <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 07:28, 22 June 2011 (EDT)
  
−
Hybrid D:\Terror
+
Sorry, my previous post show a lack of information.
  
−
If that gives an exception, lemme know what it is.
+
My PC: AMD Phenom II X4 965 processor, 2.18Ghz, 3,25Gb ram. WindowsXP ue.
  
−
The classpath line should be left as it was. It's just required on some systems for java to work correctly.
+
And detailed steps:
 +
-clean copy of Steam "ufo defense" (windows CE version... I think)
 +
-Applied the seb76 extended mod. (The game runs successfully).
 +
-Copy the BB tool files in the ufo folder. (xcloader.exe is there)
 +
-Check bb_tact\Config\BBmod.ini: uniforms: off
 +
-run BBModBat...
 +
-black screen. Nothing happens...
 +
-press enter, again, and again...
 +
-at least several error messages:
 +
error: cant find personal armor set "alloy"
 +
using default instead...
 +
...path not found in module BBreset at address 26EC:19Ac
 +
unable to found xcloader...
 +
etc...
 +
-I exit to the desktop. A windows tell me: "unable to fing xcloader.exe etc..."
 +
-I finish the process at the task manager.
  
−
- [[User:Bomb Bloke|Bomb Bloke]] 16:17, 22 March 2008 (PDT)
+
Delete the entire ufo folder.
  
−
= Inventory screens =
+
Download again from steam.
  
−
Hi Bomb Bloke
+
-New clean copy. Now without Seb76 Extended mod.
 +
-Check the vanilla game. Run "UFO Defense.exe". OK. Exit game.
 +
-Copy the BBtoolpack files in the game folder
 +
-This time I run the UniGen.bat first: ...procesing. It works.
 +
-I enable the uniforms in BBmod.ini
 +
-Run the BBMod.bat
 +
-intro without sound, black screen, exits to desktop, and the same windows message: "unable to fing xcloader.exe etc..."
  
−
I really love your Map editor, which in fairness is a full Battlescape editor. It crashes for me a lot but probably that's because I have other mods messing with the files.  
+
-Copy the files from the xcom1 folder of xcombugfix091 (the file you linked me) and replace patch.dll.
 +
-Same error.
  
 +
--[[User:Man.manza|Man.manza]] 12:34, 22 June 2011 (EDT)
  
−
My question is - do your cool Inventory screens work with the actual game? I would love to see my weight and TUs while loading up my guys. Otherwise you need paper and pencil and printouts.
+
:Ok, if it's the Steam release, try this.
−
 
 
−
thanks! [[User:Spike|Spike]] 11:28, 25 March 2008 (PDT)
 
  
−
----
+
:Goto the folder that contains the DOSBox executable and configuration file. This will typically be:
  
−
The alien portraits do, the editor tweaks the save files so the actual game will use them. I'll be making that optional though (because if the saves are then transferred to a system that doesn't have the extra graphics the game could crash).
+
:C:\Program Files\Steam\steamapps\common\xcom ufo defense
  
−
I'm afraid I can't add the weight display stats to the original game. [[User:Seb76|Seb76]] or one of the other machine coders out there might be able to pull it off, but it's a big ask (right up there with adding stuff to the tech tree).
+
:In there is "dosbox.conf", open that in a text editor (eg drag'n'drop the file into a Notepad window) and scroll right down to the bottom of it.
−
:You mean stuff like that? [[Image:Ufo weight.zip]] ;-) [[User:Seb76|Seb76]] 18:09, 28 March 2008 (PDT)
 
  
−
::That's pretty impressive... :O Reckon you could get it to display unit strength as well? [[User:Bomb Bloke|Bomb Bloke]] 20:53, 28 March 2008 (PDT)
+
:You'll see a line that states "call ufocd.bat", change this to "call bbmod.bat", then save the file. Run "dosbox.exe" (or just launch the game through the Steam interface, which uses DOSBox by default) and it should work. If you want to go back to running the game normally, just change the line in "dosbox.conf" back to "call ufocd.bat" again.
  
−
::: You are correct, I could have done it. Have a look at the updated version ;-) [[User:Seb76|Seb76]] 10:23, 29 March 2008 (PDT)
+
:The idea is that BBMod seems to be getting confused by the fact that the Steam release contains BOTH DOS and Windows versions of UFO. It sees the DOS version first and tries to run that, but fails horribly unless you use DOSBox. There's plenty of irony there, because I'm the one who requested that it be that way... - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 23:01, 22 June 2011 (EDT)
  
−
:: That's nearly perfect, but... well, there's always a catch, isn't there? ;)
+
::If, on the other hand, you want to force it to use CE, then delete UFOEXE\Black.exe and run BBMod.bat directly. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 23:22, 22 June 2011 (EDT)
  
−
:: For whatever reason, the weight carried by some troopers won't display. Here's a sample save game: [[Image:GAME_4.zip]] (check the guy in front of the ramp). I've tried loading up the units in concern and they do get their TU penalty if I go over their limit, but the weight carried always shows up as "0" on their inventory screens.  
+
:Remember when editing wiki pages that when you hit submit, the page is replaced with whatever you had in the edit box. Meaning that if you hit edit, wait a few hours, then submit the page... if anyone has made any other changes within to the page within that time, they'll be lost. Best to re-press the edit button if you've left it a while, just in case the page version you're looking at is no longer up to date.
  
−
:: In most of my saves (just about any that involve flying suits) it doesn't work for any units. [[User:Bomb Bloke|Bomb Bloke]] 19:53, 29 March 2008 (PDT)
+
:You can keep track of when a page was last changed using the "history" link at the very top of the article, or, using the "recent changes" link listed in the toolbox to the left. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 18:30, 23 June 2011 (EDT)
  
−
::: I'm using offset 0x28 of unitref.dat to get the soldier.dat index (to in turn get the carried weigth via an already builtin function). Strangely it is set to 0xff for some units. Did you mess too much with this file? Or maybe offset 0x28 is not yet completely understood. [[User:Seb76|Seb76]] 02:07, 30 March 2008 (PDT)
+
= Convusopedia? =
  
−
::: I think I nailed it. Care for another try? [[User:Seb76|Seb76]] 02:42, 30 March 2008 (PDT)
+
Why to keep in the toolpack a ready to use script for converting Ufopedia while not another one for TFTD?
 +
There is one here: [[File:convusopedia.zip]], perhaps you will add it to your pack?
  
−
:: Yes, this one seems to be working perfectly. Mind if I build it into a patcher tomorrow and stick it up on StrategyCore, so it can be used with other mods? (or does it add code to the end of the executable, like Mok's does)?
+
[[User:Sherlock|Sherlock]] 06:12, 20 January 2013 (EST)
−
::: Some code is added in the executable in a padding section (unused space in the binary) so the file has still the same size. It'll conflict with other patches if they use the same place in the executable to inject their code (the patch specifics are available on the download page). I have no account in SC so I don't know what other mods do... Perhaps a bit of testing is required before posting this (does it works if you MC an alien and go to its inventory screen?). [[User:Seb76|Seb76]] 10:09, 30 March 2008 (PDT)
 
  
−
:: That offset isn't used by non-X-Com troopers (the trooper in front of the ramp was created with my editor, which "wipes" that offset for clones). So it should've also failed for civilians and aliens.
+
:I threw that batch together in order to populate [[UP001.SPK-UP042.SPK|this page]], and I'm fairly sure I did one for TFTD too in order to churn out [[UP001.BDY-UP112.BDY|this one]] too. But I don't think I got around to putting it in my main "release" folder, so that one got lost somewhere along the line...
  
−
:: Not sure why it failed for my flying suit troopers. I was starting to think large units might've been messing up the calculation. [[User:Bomb Bloke|Bomb Bloke]] 08:34, 30 March 2008 (PDT)
+
:I'll certainly throw that new one into my next update, thanks. :)  - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 09:12, 21 January 2013 (EST)
−
::: The first version was faulty anyway: it used the soldier.dat entry index instead of unitpos index. It worked as long as noone died else things start to get out of sync. [[User:Seb76|Seb76]] 10:09, 30 March 2008 (PDT)
 
  
−
If you know specific methods to crash the editor, or have certain save games it won't load, I'd love to see them. I'm forever working bugs out of the thing but I'm limited in that I never get any actual bug reports. :(
+
= UFO/TFTD CE EXE Splitter / Merger =
  
−
I do know that it probably won't load XcomUtil based saves that use alternate terrain sets (eg. Hobbes's maps).
+
Files produced by this splitter differs from that produced with XComUtil. And even if we took the correction for TFTDextender error when exiting geoscape, there are still 5 bytes different. What is it for?
  
−
- [[User:Bomb Bloke|Bomb Bloke]] 19:02, 25 March 2008 (PDT)
+
BTW., the newest version of TFTDextender generates Geoscape-exiting errors with any known version of the split exe.~Perhaps any further corrections are needed.
  
−
----
+
[[User:Sherlock|Sherlock]] 06:12, 20 January 2013 (EST)
−
Thanks BB. What tends to happen is the editor hangs during file load, on the saved games list screen. The only clue is that the mouse pointer is visible/movable(normally the pointer disappears during file load). Back in the BBmap_edit.bat Dos window, it will have an "Array out of bounds" error (generic, I know). Will try to get a reproducible bug and send you the game save dir. Cheers, [[User:Spike|Spike]] 01:56, 27 March 2008 (PDT)
 
  
−
=Categorization Guidelines=
+
:''Five'' bytes? Well that's interesting...
−
Hey BB, I've noticed that you've removed some categories from a few pages and stated you reason as 'redundant categories'. My first thought was that there isn't such thing as a redundant category (the more the merrier since I see them as tags for the articles that help connect common theme pages together) but I've been reading Wikipedia's policy regarding categorization and while I do not agree with all aspects of their policy I think it might be better if we set a common guideline of our own. What do you think should be accepted regarding categorization? [[User:Hobbes|Hobbes]] 13:06, 18 December 2009 (EST)
 
  
−
----
+
:The reason the files differ is because kryub came up with [http://www.strategycore.co.uk/forums/topic/10103-tftdxcomutil-error-message/#entry119203 a fix] for the error in Scott's original code, and I implemented that fix into my version of the splitter. And I tested it, and it worked, though I now can't remember if it worked in conjunction with Extender. It's the sort of thing I'd've tested, but I just can't remember for certain.
  
−
The way I see it, pages should be in as few categories as possible, and preferably child categories at that. If you want an example as to why, take a look at the [[:Category:Apocalypse|Apocalypse]] cat - it's downright ''broken''. Page one tells you there are 199 articles - there's actually 271 at present (and four sub-cats, only ''one'' of which is visible on the first page - hardly intuitive for finding stuff!), but you won't be given that information unless you jump to page two. And as for using a list like that to locate articles on a specific theme? There's too much junk to read through, you can only get anywhere if you already know exactly what you're looking for!
+
:But I also get the same crash as you do when used with TFTDExtender. And maybe without it, too, though TFTDExtender causes the game to report the same errors in different ways. I'd been meaning to try playing with the Extender INI to try and narrow it down, but since kryub told me to alter six bytes, I might've messed up. Though I've got a vague memory he might've told me to change a byte to something it was already set to, which'd explain the thingy. I've sorta been assuming something in Extender changed after I implemented the patch.
  
−
In comparison, try looking at the [[:Category:Enemy Unknown/UFO Defense|Enemy Unknown/UFO Defense]] category. You should find it dead easy to get to a page about any given topic that's categorised in there, even if you didn't start out knowing what it was called. Obviously I still consider there to be some more work to be done (base modules, X-COM craft + their weapons, not to mention the game files), but I'm sure you get the general idea of how that style of things affects practicality.
+
:Urgh. Too late at night for thinking. If I got the patch wrong then I should be able to fix it in the morning. Or later in the morning, I should say. Otherwise I can hopefully at least isolate it down to a specific cause. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 09:12, 21 January 2013 (EST)
  
−
If an article looks like it belongs in two categories, ask yourself - should one of those categories actually belong in the other as well? If so, then the article certainly doesn't need to be placed in both.
+
::Ok, did some tests, here's what I can say for sure at the moment:
  
−
We also had not one, but two categories for UFO - one called "Enemy Unknown/UFO Defense" and one called just "EU". I've since moved all articles out of EU.
+
::Kryub's patch works and is implemented in my version of the splitter correctly.
  
−
Ideally, all categories will eventually link back to one "master" category, sorta like how all articles lead back (eventually) to the main page.
+
::On my Windows 7 machine, I created a fresh install of TFTD, used my splitter, and confirmed it worked as intended. I then installed the latest TFTDextender+patch, and it still worked just fine. Ditto with my ComboMod going (which tweaks the TFTDextender INI a bit).
  
−
-[[User:Bomb Bloke|Bomb Bloke]] 17:57, 18 December 2009 (EST)
+
::I copied that installation over my network to my XP Pro SP2 machine, and tested there: that errored out, but only when using TFTDextender.
  
−
: OK, makes sense, my idea originally for the categories was that we should look at them simply by looking into the page elements and creating cats for each for them, making as much associations between pages as possible (an 'horizontal' view, i guess). Your 'vertical' helps to keep things tidier but at the same time i'm wondering if it doesn't prevent the creation of common categories to which all games can be related. [[User:Hobbes|Hobbes]] 17:50, 19 December 2009 (EST)
+
::So it appears there's an OS-specific problem there (either that or Windows 7 is somehow suppressing the error - actually, having TFTDextender suppress errors entirely would be a somewhat viable fix in itself). I'll see if I can do some more tests tonight, and hopefully I can narrow it down to a specific function of the extender that's conflicting. - <span style="font-size:xx-small">&nbsp;[[User:Bomb_Bloke|Bomb Bloke]] ([[User_talk:Bomb_Bloke|Talk]]/[[Special:Contributions/Bomb_Bloke|Contribs]])</span> 19:55, 21 January 2013 (EST)

Latest revision as of 00:55, 22 January 2013

Redundant Images / Pages

Here be a list of images and / or pages that I think can be deleted safely (because they've been replaced with other files or links, or created by accident).

You Have New Messages

Now that I've started using this talk page again, I get the message "You have new messages" attached to the top of every page (other then this one) that I visit. Most annoying. Anyone know how to get rid of it? - BB

Do you still get those messages BB? --Zombie 00:04, 11 September 2006 (PDT)

I just figured out the answer a couple of days ago. Up the top of the page is an watch/unwatch link that toggles. Whenever a new post is made on the messages page, the page becomes "watched", and you have to click it before the notifications stop. - Bomb Bloke 03:16, 11 September 2006 (PDT)

Firing Accuracy

Section moved here so that this user page doesn't take so long to load on my poor slow internet connection.

Can't get Hybrid to work

Hey BB, I've downloaded your Hybrid program but I can't seem to be able to run. I got latest Java, I unzipped Hybrid to the UFO folder and I have changed the Hybrid.bat file to: set CLASSPATH=D:\Terror\ Every time i ran it though I get an exception- Can you please tell me what i've been doing wrong? Hobbes 10:34, 22 March 2008 (PDT)

Edit edit edit, I forgot how this thing worked...

Ok, extract the archive into your game folder, open up a prompt window. If UFO is in D:\UFO, the program should end up in D:\UFO\Hybrid. Change to that folder and run it with the other game's path as a parameter. eg:

Hybrid D:\Terror

If that gives an exception, lemme know what it is.

The classpath line should be left as it was. It's just required on some systems for java to work correctly.

- Bomb Bloke 16:17, 22 March 2008 (PDT)

Inventory screens

Hi Bomb Bloke

I really love your Map editor, which in fairness is a full Battlescape editor. It crashes for me a lot but probably that's because I have other mods messing with the files.


My question is - do your cool Inventory screens work with the actual game? I would love to see my weight and TUs while loading up my guys. Otherwise you need paper and pencil and printouts.

thanks! Spike 11:28, 25 March 2008 (PDT)

The alien portraits do, the editor tweaks the save files so the actual game will use them. I'll be making that optional though (because if the saves are then transferred to a system that doesn't have the extra graphics the game could crash).

I'm afraid I can't add the weight display stats to the original game. Seb76 or one of the other machine coders out there might be able to pull it off, but it's a big ask (right up there with adding stuff to the tech tree).

You mean stuff like that? File:Ufo weight.zip ;-) Seb76 18:09, 28 March 2008 (PDT)
That's pretty impressive... :O Reckon you could get it to display unit strength as well? Bomb Bloke 20:53, 28 March 2008 (PDT)
You are correct, I could have done it. Have a look at the updated version ;-) Seb76 10:23, 29 March 2008 (PDT)
That's nearly perfect, but... well, there's always a catch, isn't there? ;)
For whatever reason, the weight carried by some troopers won't display. Here's a sample save game: File:GAME 4.zip (check the guy in front of the ramp). I've tried loading up the units in concern and they do get their TU penalty if I go over their limit, but the weight carried always shows up as "0" on their inventory screens.
In most of my saves (just about any that involve flying suits) it doesn't work for any units. Bomb Bloke 19:53, 29 March 2008 (PDT)
I'm using offset 0x28 of unitref.dat to get the soldier.dat index (to in turn get the carried weigth via an already builtin function). Strangely it is set to 0xff for some units. Did you mess too much with this file? Or maybe offset 0x28 is not yet completely understood. Seb76 02:07, 30 March 2008 (PDT)
I think I nailed it. Care for another try? Seb76 02:42, 30 March 2008 (PDT)
Yes, this one seems to be working perfectly. Mind if I build it into a patcher tomorrow and stick it up on StrategyCore, so it can be used with other mods? (or does it add code to the end of the executable, like Mok's does)?
Some code is added in the executable in a padding section (unused space in the binary) so the file has still the same size. It'll conflict with other patches if they use the same place in the executable to inject their code (the patch specifics are available on the download page). I have no account in SC so I don't know what other mods do... Perhaps a bit of testing is required before posting this (does it works if you MC an alien and go to its inventory screen?). Seb76 10:09, 30 March 2008 (PDT)
That offset isn't used by non-X-Com troopers (the trooper in front of the ramp was created with my editor, which "wipes" that offset for clones). So it should've also failed for civilians and aliens.
Not sure why it failed for my flying suit troopers. I was starting to think large units might've been messing up the calculation. Bomb Bloke 08:34, 30 March 2008 (PDT)
The first version was faulty anyway: it used the soldier.dat entry index instead of unitpos index. It worked as long as noone died else things start to get out of sync. Seb76 10:09, 30 March 2008 (PDT)

If you know specific methods to crash the editor, or have certain save games it won't load, I'd love to see them. I'm forever working bugs out of the thing but I'm limited in that I never get any actual bug reports. :(

I do know that it probably won't load XcomUtil based saves that use alternate terrain sets (eg. Hobbes's maps).

- Bomb Bloke 19:02, 25 March 2008 (PDT)

Thanks BB. What tends to happen is the editor hangs during file load, on the saved games list screen. The only clue is that the mouse pointer is visible/movable(normally the pointer disappears during file load). Back in the BBmap_edit.bat Dos window, it will have an "Array out of bounds" error (generic, I know). Will try to get a reproducible bug and send you the game save dir. Cheers, Spike 01:56, 27 March 2008 (PDT)

Categorization Guidelines

Hey BB, I've noticed that you've removed some categories from a few pages and stated you reason as 'redundant categories'. My first thought was that there isn't such thing as a redundant category (the more the merrier since I see them as tags for the articles that help connect common theme pages together) but I've been reading Wikipedia's policy regarding categorization and while I do not agree with all aspects of their policy I think it might be better if we set a common guideline of our own. What do you think should be accepted regarding categorization? Hobbes 13:06, 18 December 2009 (EST)

The way I see it, pages should be in as few categories as possible, and preferably child categories at that. If you want an example as to why, take a look at the Apocalypse cat - it's downright broken. Page one tells you there are 199 articles - there's actually 271 at present (and four sub-cats, only one of which is visible on the first page - hardly intuitive for finding stuff!), but you won't be given that information unless you jump to page two. And as for using a list like that to locate articles on a specific theme? There's too much junk to read through, you can only get anywhere if you already know exactly what you're looking for!

In comparison, try looking at the Enemy Unknown/UFO Defense category. You should find it dead easy to get to a page about any given topic that's categorised in there, even if you didn't start out knowing what it was called. Obviously I still consider there to be some more work to be done (base modules, X-COM craft + their weapons, not to mention the game files), but I'm sure you get the general idea of how that style of things affects practicality.

If an article looks like it belongs in two categories, ask yourself - should one of those categories actually belong in the other as well? If so, then the article certainly doesn't need to be placed in both.

We also had not one, but two categories for UFO - one called "Enemy Unknown/UFO Defense" and one called just "EU". I've since moved all articles out of EU.

Ideally, all categories will eventually link back to one "master" category, sorta like how all articles lead back (eventually) to the main page.

-Bomb Bloke 17:57, 18 December 2009 (EST)

OK, makes sense, my idea originally for the categories was that we should look at them simply by looking into the page elements and creating cats for each for them, making as much associations between pages as possible (an 'horizontal' view, i guess). Your 'vertical' helps to keep things tidier but at the same time i'm wondering if it doesn't prevent the creation of common categories to which all games can be related. Hobbes 17:50, 19 December 2009 (EST)

It allows for common categories (assuming you mean stuff like this?), but unfortunately most of the obvious names to use for them are dedicated to UFO:EU articles - meaning a whole bunch of pages need to be moved to allow for it.

But what the heck. I'm up for that.

- Bomb Bloke 17:55, 19 December 2009 (EST)

Come to think of it, I'm tempted to just scrap the UFOs/USOs category and just throw the contents in the generic Craft category. Can't see the need to have both. - Bomb Bloke 18:08, 19 December 2009 (EST)

We now have a primary category. - Bomb Bloke 19:29, 19 December 2009 (EST)

OK, it's making sense to me right now how the Category: Apocalypse should be reorganized. It is still a mess but it helps that you don't have to look for all Apoc related pages since they are already there :) Hobbes 20:24, 21 December 2009 (EST)

Indeed. There's a couple of hundred pages related to the other games that simply aren't sorted at all. - Bomb Bloke 06:33, 22 December 2009 (EST)

Windows 7 64-bit + XcomUtil + bb_tact

"This version of D:\games\ufo\BBReset.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."

I'm getting the above message on every switch between geoscape and tactical when using your mod with XcomUtil. Does that mean your mod won't run, or am I doing something wrong? Rovlad 19:37, 5 May 2010 (EDT)

Nevermind, I figured it out after skimmering through .bat files a bit. For some reason your installer did not detect my system to be 64 bit (could be because it's not AMD-based). I've manually replaced BBReset.exe with BBReset32.exe and it works fine now.

Cheers! Rovlad 20:31, 5 May 2010 (EDT)

That's odd; last I knew, it used the same check that XcomUtil uses for its own executables. Having users manually moving files about isn't an ideal solution, so I'll have to take a closer look at it. Thanks for the heads-up. - Bomb Bloke 21:10, 5 May 2010 (EDT)

No problem, let me know if you need any specific information on the system, steps taken during setup process or whatever. One thing for certain, XcomUtil has detected 64-bit correctly right off the bat. Perhaps your installer could just check for "64-bit system" flag from XcuSetup to set everything up accordingly? It would not be a perfect solution, but since running XcomUtil is the only way to use bb_tact with 64-bit system (at least for now), it probably still is a feasible thought. Rovlad 08:06, 6 May 2010 (EDT)
Actually, never mind that. I've digged a bit more and discovered that Example.txt file in \XcomUtil\Addon directory is a bit outdated in terms of detecting 64-bit OS. You can fix your installation script by taking a look at \XcomUtil\batch\SysCheck.bat to see how it handles system detection now. Rovlad 10:19, 14 May 2010 (EDT)

Night vision goggles for soldiers during night missions

Hello there again.

I have drawn some graphics today which replace several images to add night vision goggles on soldiers' heads (for overalls and personal armor troopers). There are 19 images for both xcom_0.pck and xcom_1.pck, 38 in total. I've compiled them into pck files for testing (using your tools, of course!) and they seem to be working properly.

Thing is, I'm not very keen in actual modding, and seeing as your camouflage mod serves the very similar purpose (being purely a visual enhancement), I was wondering if you would be interested in using these for your own mod. As far as I understand, it would require a pre-battle check to see if it's a night mission, and only use new graphics in this case.

Anyway, let me know what you think.

- Rovlad 20:05, 14 May 2010 (EDT)

I think that sounds awesome. Right off the bat, you'd be able to tell whether night-rules were in effect for that battle or not, simply by checking how your soldiers are outfitted. Though, I don't suppose you could also update the SPKs for inventory screens? There's a tool in my pack for converting those back and forth, works much the same way as the PCK one.

Actually, I could even take it a step further: Make it so that, when using the goggles, mission light-levels are capped at the point just before "night-time" rules come into effect. So that it's visibly "dusky" to the user, but your troops still have full range of vision (like when you're in a base defense mission for eg). It always seemed rather silly that soldiers didn't have some sort of attached visual aid (like, say, a flashlight).

- Bomb Bloke 02:38, 22 May 2010 (EDT)

Clean Up

If it is in your abilities can you erase all these Russian blank pages (and their discussions)? They are redundant and left after vandals invasion. Thanks. ---ufo.mesh 05:32, 27 August 2010 (EDT)


BBmod.bat error: "dont find xcloader"

I cant install the BB mod set. When I run the BBMod.bat, the game begins with the intro without sounds and I get a black screen. When swap to the desktop I see the error message: unable to locate "xcloader". But, the xcloader.exe is in the folder. I have xcomutil and the seb76 extended mod installed. I run xcusetup and recognices the BBmod. But when a mission beggins the game crashes: error, unable to find kevlar brown...(the BBMod.bat dont worked)

- user: man.manza (juny 2011)

Sorry, I made some changes the other week and probably didn't test them too well before uploading.
Am sick at the moment, and not really in the mood to smooth it all out. You should be able to work around the main issue though.
Grab a fresh copy of f0dder's loader. In the "xcom1" folder of the archive, there's a file "patch.dll", you'll need to replace the one BBMod had with this. If you're running TFTD then don't worry about getting the new patch file.
There is no good reason why the batch wouldn't be able to find XCLoader, which is included in the toolkit archive now, so I'm assuming you're seeing the prompt to locate the game EXE instead... Either way I have no clue why the game would've started anyway.
Anyway, if that doesn't sort things, odds are it's unhappy because you didn't run "UniGen.bat" from the bb_tact folder before starting the mod. I'd tried to rig things so that you didn't need to do this unless you wanted to use the uniform manager, but I may have messed that up - if so, you'll probably need to reinstall the game and try again from scratch (backup your save folders if you're worried they'll be affected).
If you're still having trouble, I'll need some more info to go off. OS? Windows Collectors Edition, or through DOSBox? Which release of the game - Steam, GameTap, original disks/CD?...
By the by, you can automatically generate a signature for your comments by typing four tiles (~~~~).


-  Bomb Bloke (Talk/Contribs) 07:28, 22 June 2011 (EDT)

Sorry, my previous post show a lack of information.

My PC: AMD Phenom II X4 965 processor, 2.18Ghz, 3,25Gb ram. WindowsXP ue.

And detailed steps: -clean copy of Steam "ufo defense" (windows CE version... I think) -Applied the seb76 extended mod. (The game runs successfully). -Copy the BB tool files in the ufo folder. (xcloader.exe is there) -Check bb_tact\Config\BBmod.ini: uniforms: off -run BBModBat... -black screen. Nothing happens... -press enter, again, and again... -at least several error messages: error: cant find personal armor set "alloy" using default instead... ...path not found in module BBreset at address 26EC:19Ac unable to found xcloader... etc... -I exit to the desktop. A windows tell me: "unable to fing xcloader.exe etc..." -I finish the process at the task manager.

Delete the entire ufo folder.

Download again from steam.

-New clean copy. Now without Seb76 Extended mod. -Check the vanilla game. Run "UFO Defense.exe". OK. Exit game. -Copy the BBtoolpack files in the game folder -This time I run the UniGen.bat first: ...procesing. It works. -I enable the uniforms in BBmod.ini -Run the BBMod.bat -intro without sound, black screen, exits to desktop, and the same windows message: "unable to fing xcloader.exe etc..."

-Copy the files from the xcom1 folder of xcombugfix091 (the file you linked me) and replace patch.dll. -Same error.

--Man.manza 12:34, 22 June 2011 (EDT)

Ok, if it's the Steam release, try this.
Goto the folder that contains the DOSBox executable and configuration file. This will typically be:
C:\Program Files\Steam\steamapps\common\xcom ufo defense
In there is "dosbox.conf", open that in a text editor (eg drag'n'drop the file into a Notepad window) and scroll right down to the bottom of it.
You'll see a line that states "call ufocd.bat", change this to "call bbmod.bat", then save the file. Run "dosbox.exe" (or just launch the game through the Steam interface, which uses DOSBox by default) and it should work. If you want to go back to running the game normally, just change the line in "dosbox.conf" back to "call ufocd.bat" again.
The idea is that BBMod seems to be getting confused by the fact that the Steam release contains BOTH DOS and Windows versions of UFO. It sees the DOS version first and tries to run that, but fails horribly unless you use DOSBox. There's plenty of irony there, because I'm the one who requested that it be that way... -  Bomb Bloke (Talk/Contribs) 23:01, 22 June 2011 (EDT)
If, on the other hand, you want to force it to use CE, then delete UFOEXE\Black.exe and run BBMod.bat directly. -  Bomb Bloke (Talk/Contribs) 23:22, 22 June 2011 (EDT)
Remember when editing wiki pages that when you hit submit, the page is replaced with whatever you had in the edit box. Meaning that if you hit edit, wait a few hours, then submit the page... if anyone has made any other changes within to the page within that time, they'll be lost. Best to re-press the edit button if you've left it a while, just in case the page version you're looking at is no longer up to date.
You can keep track of when a page was last changed using the "history" link at the very top of the article, or, using the "recent changes" link listed in the toolbox to the left. -  Bomb Bloke (Talk/Contribs) 18:30, 23 June 2011 (EDT)

Convusopedia?

Why to keep in the toolpack a ready to use script for converting Ufopedia while not another one for TFTD? There is one here: File:Convusopedia.zip, perhaps you will add it to your pack?

Sherlock 06:12, 20 January 2013 (EST)

I threw that batch together in order to populate this page, and I'm fairly sure I did one for TFTD too in order to churn out this one too. But I don't think I got around to putting it in my main "release" folder, so that one got lost somewhere along the line...
I'll certainly throw that new one into my next update, thanks. :) -  Bomb Bloke (Talk/Contribs) 09:12, 21 January 2013 (EST)

UFO/TFTD CE EXE Splitter / Merger

Files produced by this splitter differs from that produced with XComUtil. And even if we took the correction for TFTDextender error when exiting geoscape, there are still 5 bytes different. What is it for?

BTW., the newest version of TFTDextender generates Geoscape-exiting errors with any known version of the split exe.~Perhaps any further corrections are needed.

Sherlock 06:12, 20 January 2013 (EST)

Five bytes? Well that's interesting...
The reason the files differ is because kryub came up with a fix for the error in Scott's original code, and I implemented that fix into my version of the splitter. And I tested it, and it worked, though I now can't remember if it worked in conjunction with Extender. It's the sort of thing I'd've tested, but I just can't remember for certain.
But I also get the same crash as you do when used with TFTDExtender. And maybe without it, too, though TFTDExtender causes the game to report the same errors in different ways. I'd been meaning to try playing with the Extender INI to try and narrow it down, but since kryub told me to alter six bytes, I might've messed up. Though I've got a vague memory he might've told me to change a byte to something it was already set to, which'd explain the thingy. I've sorta been assuming something in Extender changed after I implemented the patch.
Urgh. Too late at night for thinking. If I got the patch wrong then I should be able to fix it in the morning. Or later in the morning, I should say. Otherwise I can hopefully at least isolate it down to a specific cause. -  Bomb Bloke (Talk/Contribs) 09:12, 21 January 2013 (EST)
Ok, did some tests, here's what I can say for sure at the moment:
Kryub's patch works and is implemented in my version of the splitter correctly.
On my Windows 7 machine, I created a fresh install of TFTD, used my splitter, and confirmed it worked as intended. I then installed the latest TFTDextender+patch, and it still worked just fine. Ditto with my ComboMod going (which tweaks the TFTDextender INI a bit).
I copied that installation over my network to my XP Pro SP2 machine, and tested there: that errored out, but only when using TFTDextender.
So it appears there's an OS-specific problem there (either that or Windows 7 is somehow suppressing the error - actually, having TFTDextender suppress errors entirely would be a somewhat viable fix in itself). I'll see if I can do some more tests tonight, and hopefully I can narrow it down to a specific function of the extender that's conflicting. -  Bomb Bloke (Talk/Contribs) 19:55, 21 January 2013 (EST)
Retrieved from "https://www.ufopaedia.org/index.php?title=User_talk:Bomb_Bloke&oldid=44308"