zaimoni

In principle, we could map each tile hit to a frustrum [set of space angles]. Note that when designing a test map, windows are useful (because shots go through them some of the time). Fences, less so.

List of questions.... * Do we have a divide-by-zero error (or other weirdness) at FFA 0? * How wide is the cone at FFA 0? (or 1, if 0 divides-by-zero) * The 45 degree horiontal angle error point would also be interesting. I'm thinking it's somewhere around 20 FFA, but would like a more explicit calibration. * Is the shape of the "cone"'s base rectangular, or elliptical? What kind of distribution do the error angles have (uniform, bell curve? can we pin down the bell curve?) If ellipitcal, are we using phi-theta from spherical coordinates after all? Assuming that we have a two-angle model (horizontal and vertical error), I'm inclined to think of FFA as a divisor. That is, doubling the FFA should halve each of the horizontal and vertical errors.

I have, but it was something like DOS V1.2 (whatever was extant in 1995). All that's really required is for the unit type to index LOFTEMPS data. Trivium: at 49 squares range (maximum non-diagonal range on a 50x50 map), the floating-point error from missing by 0.125 degrees is between 1/9th and 1/10th of a square. I'm not sure how that will work under integer math.

Or angles. If the misses really were generated physically, the empirical choice of "pair of deviation angles" would be altitude-azimuth (a horizontal angle deviation, and a vertical angle deviation). Spherical coordinates on the bearing (phi-theta) would also be tempting, but that's not what happens with real firearms. Or through it. Floaters have a narrower collision model than their graphics intimate. Shots do go between the legs of unarmored X-COM units harmlessly, so their collision model isn't a simple tube.

SeaMonkey is even more affected (some versions can't even save web pages reliably). I generally use Opera when I have to download content onto the hard drive.

At only 121 samples, distinguishing between this and the theoretical 2d2 distribution isn't tenable.

The latest versions of Virtual PC (after M$ bought out Connectix) allow connecting to a physical CD-ROM or floppy, which simplifies things quite a bit compared to the Connectix versions. Also, Virtual PC allows saving the total state of the virtual machine. I didn't quickly find any comparable functionality in VMWare's documentation, which sealed my choice (some of the classic game studies I do require saving the total machine state).

The RIAA would prefer just breaking into, then destroying the offending system. Cf. H. R. 5211 alias "Berman Bill", 2002. This got one of the Democratic Party cosponsors eliminated from office with a 75% rejection in a solid Democratic Party district, but Berman is from Hollywood.

It's every month thereafter, until an appropriate counter-edit is made.

Sent by three distinct PM's. Feel free to ask questions. I wasn't trying to carefully emulate your style, and mine has a few quirks...a blend of Ellemtel and GNU, with a few enhancements for C++.

Well, that puts the US firmly in the 'unreasonable nation' category. Agreed, even with the implicit constraint of "first strike" in context. (The U.S. does openly have a nuclear first-strike plan for the Mideast; all other plans are retaliatory).

That doesn't make sense. Bush cut off the oil because the U.S. had intelligence that North Korea had a nuclear weapons program and had, therefore, already violated the agreement. ... Ignoring, for the moment, that the credibility of said intelligence at the time depends on one's choice of political alignment (I happen to agree it was credible, but a sufficiently liberal perspective won't even accept that): The aid program had multiple facets. What would have made pragmatic sense (having decided to continue the agreement in 2000), is terminating most of the program while keeping North Korea addicted to crude oil. Furthermore, the violations were the acquisition and testing of blueprints for reprocessing. The entire practical missile and warhead development was post-2002. [And, judging from the extant test results, three years behind schedule on becoming a threat to the U.S.]

Almost none -- initial funding was U.S., and it takes far less hard currency funding to run a breeder nuclear reactor after construction than a oil-fired electric power plant. Clinton cuts a deal with North Korea to develop a partially nuclear electric grid (with breeder reactors, of course...why invest in technology with less than four decades of fuel when technology with multiple centuries of fuel is out there), with liberal subsidized fossil fuels, in exchange for no nuclear program. Bush Jr. cuts off the oil imports in 2002...forcing North Korea to go predominantly nuclear electric grid, and providing perfect cover for a nuclear weapons program. Keep in mind that North Korea sources hard currency from the black market (and at least 50% of the national government budget), so the fact nuclear power requires no hard currency to operate is very attractive. Pretty clear case of inconsistent policy being worse than consistent policy...either approach by itself would have worked, it was the switch that created the huge threat to Red China and Japan. Direct threat to U.S.: minimal.

No reasonable nation. U.S. policy has had cause to think North Korea isn't reasonable, since the failure to end the Korean War with a formal treaty in the 1960's. Aside from the pro forma exercise of a nuclear war with Russia, all other U.S. nuclear war plans are with nations that have not ruled out being willing to be completely destroyed.

Is that stun recovery rates for active large aliens, or inactive? A KO'ed Reaper goes down by 4 stun/turn (which doesn't help it wake up faster, alas)...one for each section in UNITPOS.DAT. I don't recall testing live ones recently.

I've been doing some playing around with this (for speed optimization). Load times are down by about 2/3rd on my system (1GHz PIII), and Scale2X is no longer *slow*. Key change targets: Scale2X.java, PalImage.java, UnitDrawer.java. * PalImage.java was just lifting a loop invaraint out. * Scale2X.java formerly had rather extensive reevaluation of common subexpressions. * UnitDrawer...stylebuster change: the switch operator is much maligned in coding standards. But very useful for performance here. Other changes I did on my end did not result in drastic enhancements, although I believe they are formally faster. Shall I prepare context diffs for you to merge in?

Automation, automation, automation.... The only way to drive the programmer time down (beyond programming practices suitable for small development teams), is to have a suitably artificially intelligent development environment. Artist time is even harder. Regrettably, I don't see one out there even for programming. So I started coding one (with XCOM-likes as one target) in C++. It's vaporware right now, even with using the Boost library moderately.

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

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

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.

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. Crouching certainly would "lower" the computed trajectory slightly (in the 16x16x12 detailed space model). If the arc-breaker was the virtual ceiling (trying to go to machine cell height -1), then lowering the trajectory could make the difference between UTTH and throwing in borderline cases.

The UTTH message is also influenced by stance. I decided to check the range difference between crouching and standing for weight 11, STR 184 (while doing the range 27/33 cutpoint checks by weight...proposed ratio passes). Standing is range 33 before UTTH, crouching is range 34 before UTTH No boost for standing range 27. But when the standing range is 46, the crouching range is 47. IIRC, the small scout map has the same height as the map you're testing on (four cells), so the ceiling chop should behave the same.

Just completed some spot checks on my end. The revised ratios I posted above allowed modifying Zombie's spreadsheet to include a "maximum strength for range for given weight" calculator, and a "minimum weight for range for given strength calculator". I think the game must do the calculations like the first, since it uses the floor function (so the test values could be obtained by integer math). * All meaningful thresholds checked: STR 255/ all range transitions except 2/3, weight 255/ range transition 2/3. * After using the rechecked values for STR 86,87/weight 7 (23 rather than 27), exactly replicates weight columns 1-10.

V1.0 had uncapped strength, and the Battlescape display goes to 150. That throwing range goes automatic OOR at strength 151 for a weight 3 object suggests that whatever algorithm was used, was calibrated to not fail for any intended-displayable strength and any weight used in V1.0. I'm thinking that if a formula exists, it's going to be taking a scaled integer quotient of something that itself was from a scaled integer quotient. I just don't immediately see how you're going to relate the long stretches of 33 and 46.

I hope so, because that's all I did to Zombie's table to get my initial estimates. Which bungled the initial threshold between range 2 and range 3. Not only don't I have a formula that explains the table yet. I suspect that what's going on is a lookup table rather than a formula. What I do know is that (within the test space), the table is "homogeneous" in strength and weight. (Regrettably, there are several mutually irrelevant definitions. I'm using the algebraic one, rather than the differential equation one that actually gets taught in undergraduate mathematics.) Look at the entries for weight 1. E.g., weight 1, strength 1 has range 3 -- and if you multiply both sides by any of 2 through 10, it is also range 3. And exactly the same for strength 2 through 25. If we exclude scalings whose needed strength exceeds 255, everything works. [The values I retested are missed by this mesh.] So the failure of intermediate ranges to appear is important: a simple formula should have generated a range of 15 somewhere before or in weight 10 in the exhaustive listing. The choice of far cutoffs looks like it's from whatever source Steve Jackson's GURPS used (table lookup, extreme examples are strength 25x weight and strength 50x weight). This suggests the the ratio of strength to weight is being tested precisely, so it is possible that the actual comparison is of two integers being multiplied. (Cast to unsigned short from unsigned char to prevent overflow). (fudge factor)*strength <= 50*weight One way to do this would be to loop down through a lookup table until the condition goes off, with a failsafe of OOR should no range trigger. I haven't checked whether a simple integer math algorithm exists that gives range 46 for 1, range 33 for 2, and so on through range 2 for 20. [That would go a long way towards removing the lookup table.]