Formulas

[Zombie]

Well....not sure if it does so reliably. [it certainly didn't help the 27-range any.] An exhaustive pass at weight 10 would be an informative sample.

Very well, I'll do this next. Hold on tight, it'll take me a little time.

 

- Zombie

[Zombie]

Ok, I worked pretty hard on this last night. Weight 10, and kneeling does have an effect on distance thrown when compared to standing. First of all, here are the breakpoints:

 

 

			  Kneeling
Clean	   Unable to		  Out of
Throw	   throw here		 Range
 21			 --			  ---
 24		   25-26			 27+
 27		   28-34			 35+
 34		   35-49+			NA
 47		   48-49+			NA
		  Standing
 21			 22			  23+
 23		   24-27			 28+
 27		   28-35			 36+
 33		   34-49+			NA
 46		   47-49+			NA

21 tiles is now a strict clean throw with no "UTTH" message anymore. 23 goes to 24, 27 stays the same, 33 goes to 34 and 46 goes to 47 when kneeling. Interesting, when strength is really high (83+) the distance basically increases by one. However, this is kinda negated as when strength is low some distances are shorter. I better attach something here so you guys can see what I'm saying:

 

Excel: Stand_vs_Kneel_Throw_Dist__Weight_10_.zip

Adobe: Stand_vs_Kneel_Throw_Dist__Weight_10_.pdf

 

See? You can't throw as far when strength is low and you are kneeling. I guess this makes sense as in real life applications you end up side-arming a throw when you are kneeling to get any kind of accuracy, while the longer distances require an overhead-throw.

 

By the way, this all has implications. If distances change while kneeling, it would mean a second look-up table is necessary. I doubt the programmers would have went this far. Also, look at the 27 clean throw row in the tables above. Same clean throw, different "UTTH" and "OOR" distances. In addition, I double-checked what happens when a weight of 0 is hacked in. The game crashes to the desktop. This indicates a division by zero error like BB mentioned. What this all means is an eqation is responsible for the differences noted, not look-up tables.

 

If anyone needs more data on something, let me know and I'll try and knock out a few tests.

 

- Zombie

[zaimoni]

The crashing out when attempting 0 weight doesn't help decide. I'm inclined to think the trajectories are computed in real time. (If you ignore air resistance, it's easy and can be done just knowing the starting and ending points...then check after the fact whether the STR required for the trajectory is met.) The crash could be from the trajectory calculation (weight 0 would cause a division by zero when computing the maximum height of the no-air-resistance parabola).

 

Also, if the trajectory was calculated before checking the STR, we would see standing ranges 15, 17, and so on.

 

The easy way to get the long 46 standing-throw range before UTTH suite (fully half of the throwable interval for objects of weights 1 through 5) is 50*WGT/STR...the high strength half of those results is indexed by integer math 1.

 

Also, something is telling the trajectory calculator to suddenly use a flatter throwing angle at the breakpoint for 33/46 standing throwing range. Ignoring air resistance, the maximum-range angle is 45 degrees; once UTTH starts happening from the ceiling, the only way to extend the maximum range before UTTH is to reduce the throwing angle.

 

If we wanted to handle the prescreen by dividing by weight...then the standing range 2 would be from the integer quotient in the prescreen finally zeroing out. The threshold for that looks like WGT = 5/6 STR (pending exhaustive verification), so we'd want (6*STR)/(5*WGT). But that gives quotient 1 at STR 5, WGT 6 -- which is range 2, contrary to the assumption that range 2 happens when the quotient zeros out.

====

Hmm...does anyone know if a 60x60x4 map for testing could be constructed? That is the largest 4-height map that can fit into 64K (important for 16-bit addressing), but I don't immediately know what buffer size was actually allocated for the map.

 

The largest 5-height map that can fit into 64K is 50x50x5.

[zaimoni]

Having a reasonable direct trajectory calculation in hand would help. Don't know when I'll spare the time for it, through.

[Zombie]

Hmm...does anyone know if a 60x60x4 map for testing could be constructed? That is the largest 4-height map that can fit into 64K (important for 16-bit addressing), but I don't immediately know what buffer size was actually allocated for the map.

 

The largest 5-height map that can fit into 64K is 50x50x5.

Well, MapEdit allows you to change height of base modules, so I'd assume this is possible. I'll give it a whirl. Right now, I'm testing throwing distance in a 60x60x2 base defense mission map. Hangars are really easy to edit as there is basically nothing there to begin with. I edited out the walls and rooms and let the mission begin. Bummer, I forgot the game adds corridors - even in an fully-open hangar! BB's map edit proggy fixed that up real quick-like. I'll work on the number-gathering aspect tonight.

 

After that, perhaps a 60 wide by 1 height map would be good to test. And a 60x3. And a 60x4. That should cover all the possibilities. Don't think a 5 height map is possible, even in 50x50 format. Daishiva or Hobbes knows more about the mechanics than I do though.

 

So let's see, what variables do we have so far? Soldier Strength, Item Weight, Standing/Kneeling, and possibly map height. Anything else I'm missing? I checked Throwing Accuracy and it doesn't play a role in distance.

 

- Zombie

[JellyfishGreen]

I still think it's a lookup table, as there are only 21 possible distinct max throw distances (eg. you can never get a max distance of 41 or 42), and one Strength/Weight division followed by up to 21 "GREATER THAN" comparisons to the corresponding ratios is probably as fast as any real-time formula with multiple divisions - as the CPU flies. A 42 integer table was never going to take up that much memory space, anyway. (Hey, is it hidden in a .dat file, or hardcoded in the .exe?)

[Hobbes]

Hmm...does anyone know if a 60x60x4 map for testing could be constructed? That is the largest 4-height map that can fit into 64K (important for 16-bit addressing), but I don't immediately know what buffer size was actually allocated for the map.

 

The largest 5-height map that can fit into 64K is 50x50x5.

Well, MapEdit allows you to change height of base modules, so I'd assume this is possible.

 

Battlefields can have a maximum of 10.000 squares, or 50x50x4. That is why the bases are limited to 60x60x2 (7.200 squares).

I've run a game with 60x60x4 dimensions once, using XComUtil, but that happened because XComUtil's designer had added a few features I had requested (the ability to use 30x30 and 40x40 buildings) and had forgotten to set the dimensions right.

What happened when I ran a map with 60x60x4 was that the effect of explosions would be replicated ALL over the map, not just the area where the grenade hit. It was amusing, but it also made the game unplayable.

[Knan]

Battlefields can have a maximum of 10.000 squares, or 50x50x4. That is why the bases are limited to 60x60x2 (7.200 squares).

 

Hmm. So could an (x-com|alien) base be modified to be 70x70x2? (=9800)

[Hobbes]

Battlefields can have a maximum of 10.000 squares, or 50x50x4. That is why the bases are limited to 60x60x2 (7.200 squares).

 

Hmm. So could an (x-com|alien) base be modified to be 70x70x2? (=9800)

 

Good question. It could be possible to change XComUtil to use those dimensions for bases but that would require changing the .exe file since map dimensions can't be defined on the .cfg. But I don't know anything about coding, so the question remains.

[zaimoni]

Hmm...so the game can't handle 60x60x4 algorithmically (at least the explosion code), but it didn't overwrite anything that would crash it immediately either. And it's too large to be a convenient static variable in 16-bit code (the usual limit for 16-bit code is 64K for all variables combined).

 

But with the reported maximum range at height 4, the interesting case is 50x50x5. I'll have to schedule that and see what happens. [but not tonight.]

[NKF]

The UFO map engine only handle so much, but perhaps one solution would be to use TFTD. TFTD allows 4 levels of elevation, and base missions are 4 levels high and have the standard 60x60 tile grid.

 

- NKF

[Zombie]

Now that's an idea. But, I'd first have to determine if throwing distances correlate between the games. If they do, then editing out the walls ceilings/floors between existing structures would probably help a bunch. Question: are hangars in TFTD 2 levels or 4? Can't remember offhand but I think 2 are accessable and 2 aren't. Is that right?

 

- Zombie

[NKF]

Well, the air lock does allow you to move between 4 different levels - though it doesn't really go anywhere. The majority of the unused area of the base is just filled with solid blocks. If you turned them into ordinary empty tiles, it should work.

 

I don't think throwing is any different in TFTD, but I suppose you never know.

 

- NKF

[Bomb Bloke]

Kneeling affects throwing distance? Argh! That probably means that the units' height stat has something to do with the matter, which would make me think that different unit types have different throwing capabilities. Cue another link to the Wiki to demonstrate (and yes, for the last time, civilians do float above the ground).

 

I've had very little time for anything over the last little while, but with any luck I'll be able to create a basic map generator tonight. I've found that the game engine is quite happy to load a 50x40 map, so I see no reason why this couldn't be used to make a thin/long/tall area.

[Zombie]

Gee, I'm hoping that unit height doesn't factor into the equation. It should be easy to find out though. I'm guessing that editing the unitref.dat height data is enough, but you never know as X-COM heights are defined in the executable (probably near the starting soldier attributes) and it's location isn't known yet. I'm looking though.

 

- Zombie

[Bomb Bloke]

Right. Last night I finally sat down and started work.

 

This evening I've got a working logger. I'm afraid I've only put a little testing into it, but I reckon it works, and hopefully I've managed to account for all errors.

 

Usage is simple. Extract archive into game folder, run "bb_throw.bat".

 

The program backs up your desert terrain, before replacing it with my numbered tileset. It then lets you set things up the way you want them - You can preset the unit's height and strength, as well as the item's weight (the item, of course, being a football).

 

Furthermore, you can define the dimensions of the map. A minimum of two levels is enforced, but other then that, you can do much as you like. The default is 10x100x4 but you can extend the length somewhat without any problems. Needless to say silly dimensions will cause UFO to crash, but there's no harm in trying them.

 

And yeah, more then four layers is an option. However, this causes some rendering... issues. I doubt this could have any effect on throwing distances (other then extending the maximum somewhat due to the higher ceiling), but again, I haven't done much testing.

 

Using extra layers makes it impossible to tell where the football lands. Not to worry, once you've made your throw, you just abort the mission and the logger automatically records where it went anyway.

 

If you feel a mistake has been made, however, you can manually correct it, or just repeat the trial, before allowing the logger to raise the variables and start the next test.

 

And when you're done, the desert terrain is removed and the football weight is returned to it's original value (or at least, whatever it was before you ran the logger).

 

Unlike my previous logger, the logs aren't stored in a text format. The reason for this is that the program handles 256 logs, each containing 65536 records, and you can start, stop or resume logging from just about any point. Automatically converting the logs would result in some slow down, so they're only done one at a time, as requested via the main menu.

 

One log per height possibility. It's not recommended that you auto-raise the height stat unless you're prepared to sift your way through a lot of files for the results (which are stored, by the way, in \bb_tact\tlogs).

bb_throw.zip

[Zombie]

Wow, this is good news. Thanks for putting this together. I'm assuming that XcomUtil is necessary, just like your other loggers, correct?

 

- Zombie

[Bomb Bloke]

For CE users, yes. As usual, it's only required in order to split the executable.

 

For those who don't already have XcomUtil, I recommend backing up your game folder before installing it, then restoring the backup over the original once setup is complete. That way XcomUtil isn't able to modify anything else.

 

I now realise that I probably didn't tweak the throwing accuracy of the soldier. Not sure how much of a problem that is. My map editer will allow you to change it anyway if you can't be bothered with a manual fix, though there's some possibilty it'll wreck the map (which the logger can always rebuild).