View source for Talk:Under The Hood

For saved game file discussion, NKF's analysis of LOC.DAT "20 binary rows, 50 entries" contains Geoscape tokens 

*Nothing = 0
*UFO = 1
*X-Com Craft = 2
*X-Com Base = 3
*Alien Base = 4 
*Waypoint = 7
--[[User:JellyfishGreen|JellyfishGreen]] 06:05, 23 Aug 2005 (PDT)

== JFG or anybody, what's the Great Circle Route? ==

enquiring minds want to know!

----

The best way to explain great circles is to first think of the old saying: "the shortest distance between two points is a straight line". For example, the shortest distance between the points (0,0) and (4,4) lies directly on the line y=x. To find distances in planer geometry it is as simple as finding a straight line which goes through those two points. But we have to remember that this is only true for Euclidean (or planer) geometry.

The Earth, however, is not a plane. It is a sphere. Spherical geometry is not the same as Euclidean geometry. A point-to-point distance is simply a line segment on a Euclidean graph, but when translated into spherical coordinates it is now an arc. (Case in point: the Euclidean distance formula is rather easy, whereas the spherical distance formula requires sines, cosines and the arctangent to compute). In the same manner as extending a line segment creates a line, extending an arc creates a circle. Navigational buffs out there call this circle: "the great circle". Catch is, in order for the circle to be considered "great" it must bisect the globe into two identical hemispheres.

If you ever see what the flight plan for transconinental airlines flying between London and New York is, it is an arc extending almost up to the Arctic Circle and then back down. That distance is shorter than flying on a direct line of latitude. Hope this helps. --[[User:Zombie|Zombie]] 10:31, 5 Nov 2005 (PST)

----

Thanks Z! Now I see. I gather that XCOM doesn't do it properly? And we should re-route with "waypoints" to save a little time?

---[[User:MikeTheRed|MikeTheRed]] 05:41, 7 Nov 2005 (PST)

----

Well, I fooled around with this a bit today and for the most part X-COM does a pretty good job of finding the shortest distance. From all the tests I ran from the northern hemisphere to the southern hemisphere, the game always beat my time by a few minutes. Heck, I even went as far as calculating the anticipated "great circle" and following it as close as I could. Result: the game still put up better times than I did (though, not by much). I'm thinking that the problem may arise when the two points are near the equator or the poles, since those are by definition great circles. Gimme a chance to look at this closer.

--[[User:Zombie|Zombie]] 21:36, 7 Nov 2005 (PST)

== Suggestion ==

I'm not familiar with the great circle route myself, but you could try this experiment: 

Set up a base in, say, Berlin. Station a Lightning there. 

Now, plot to waypoint in Vancouver. See how far the Lightning gets. 

Refill, rearm then make another trip to Vancouver, only this time plot a course through the polar cap, using short waypoints so that the Lightning doesn't default to moving around the curve of the globe. 

You should, in theory, make it to Vancouver with a bit more fuel than when you set the one waypoint and let your ship do all the flying. 
 
- [[User:NKF|NKF]]

== Arctic Waypoints ==

It pretty much applies to manually routing your craft to the North Pole first, when going from North America to Europe/Russia/Siberia. The game's default route between any waypoints is to proceed north or south until it can follow a line of latitude, which takes longer than a pure diagonal (or great circle). Manually crossing the North Pole leaves out the latitude-following delay.  Australia to Africa over the South Pole would be another application.
[[User:JellyfishGreen|JellyfishGreen]]

----


Thanks guys. Yep, built a base in North America and Australia. Then sent a craft to different points on the globe. It just seems like points in the same hemisphere and near a pole make the games waypoint system break down. Sent a Lightning from Chicago to the center of Russia - the game did it by sending the craft up to the arctic circle, then around it till it reached its destination. Elapsed time: 4 hours. When I manually plotted waypoints directly over the North Pole, it took 2 hours. Even manually plotting a waypoint near the pole is a little dangerous - crafts tend to do some wierd stuff. [[User:Zombie|Zombie]]

----

Ethereal Cereal - the spawn priority refers to the order in which units are generated in the battlescape. It's generally HWPs, X-Com Soldiers, Aliens, terror units etc. I forget where civilians fit into that order. 

- [[User:NKF|NKF]]

----

Ah, okay, thanks, it'd be nice to have an article on this, even just a 1-liner... Is there anything useful that one can make use of from knowing the spawn priority? --[[User:Ethereal Cereal|Ethereal Cereal]] 20:21, 11 May 2006 (PDT)

== Manufacturing Time Estimates vs Actual ==

One thing which doesn't seem to be covered in this wiki is how you only get a message concerning an event once the clock's hour counter advances (save for UFO detection, which also happens 30 minutes after the hour).  Why?  When do other events actually happen?  Well, rather than seem like a lazy douche, I did a little testing to see for myself.  Specifically... these ones:

'''''Formula for calculations'': Engineer Hours required / # of Engineers = "real" hours required''' (I realize this is almost stupid, but trust me, it's a necessary precedent so you know where I'm coming from, yada yada - also too lazy to write up the formula into LaTeX)

*Test 1: Production of One Motion Scanner with 31 Engineers; the game "anticipates" it'll take 7 hours; it "really" takes 7:05:48.38 by outside calculation.
**Starting at 21:59 it finishes at 5:00, where it would finish at 5:04 by my calculations.
**Starting at 22:00 it ends at 6:00, where it would finish at 5:05 by my calculations.
*Test 2: Same as Test 1 except with 25 Engineers.  Computer "anticipates" it will take 8 hours, but it "really" takes 8:48
**21:59 -> 6:00.  Should be 6:47.
**22:00 -> 7:00.  Should be 6:48.
*Note:  I also tested starting a production at different minutes during the same hour, and they all yielded the same "anticipated" time from the computer, and the same end hour.
Conclusions:
*From the Production screen, with the aid of the above formula, you see that the computer always rounds ''down'' its anticipated production time.
*How long it takes to manufacture is based on which hour you are in; minutes and seconds hold no influence whatsoever.
*The computer's "anticipated" hours are totally correct, the Engineers just need that many ''whole'' hours for the job.
So what am I getting at?  Well, I can't test my conclusion yet, since I only ''have'' 31 Engineers so far in the game, but my conclusion (which is probably wrong) is that you only need 1 + half the hours required for the job # of engineers to either complete it in an hour, or else the fastest a single item can be completed is 2 hours.  I think once someone can really get, or just show, me the data for this, then it ought to go into a page.

The ''core'' of my conclusion, however, which my data all ''but'' proves, is that you can manipulate exactly how many (obviously one would choose the minimum number) engineers you have working on a project to get it done in the lowest integer # of hours available to you.  Also that you only have to make sure that you start a project before the end of the hour, and it will get done just as fast as if you did it at the start of the hour.  I'm not sure but I'd guess the same goes for transfers (where research only checks the time at midnight).

Also I'm guessing this is common knowledge for some of you.  But it wasn't here (not to mention the only discussion being about the great circles), and I figure it deserves a chance at being included in the article if someone can sum it up into something a little more useful.

--[[User:NightChime|NightChime]] 18:56, 17 October 2008 (CDT)

: I know our host of inner game mechanic boffins had a good chat on the engineering hours somewhere on the wiki at one point, but I can't think of where. Two places I might recommend having a look is the [[Manufacturing Profitability]] page and its talk page. Come to think of it, the information on how manufacturing hours ought to go in the [[Manufacturing]] page at one point or another. -[[User:NKF|NKF]] 21:20, 17 October 2008 (CDT)

:: I think discussion about how the Geoscape deals with time may be relevant here Under The Hood, or of course better yet in the Geoscape section. -[[User:NightChime|NightChime]] 23:25, 17 October 2008 (CDT)

: Funnily enough I was looking at this a week ago (manufacturing time estimates vs reality) and I got the impression that the game's estimate is often one '''less''' than the actual, i.e. it often takes an hour longer than the game tells you. This hits your efficiency very badly when you manufacture small runs, with the worst case being a run of one unit. I was basically manufacturing 1, 2, 3 ,4... 9 Gauss Cannons in a cycle (then selling my profit and going back to 1 again). The impression I got was that production per hour is rounded down, with the 'extra' unit (the rounding error) being produced in the final hour of manufacturing. So let's say (hypothetical case) you are manufacturing 7 cannons and it says it will take 6 hours. One new cannon will show up in your stores each hour, and then 2 new cannon will show up at the end of the last (sixth) hour. If you manufacture one cannon, it says it will take one hour (rounding down 1.16 hrs), but actually it takes 2 hrs (rounding up 1.16 hrs). These are made up examples but you get the principle. From this I'm inferring that the games tracks "number of units produced so far" as a decimal number, but obviously only deliveres complete integers of units into your Stores (and only at the top of the hour). I did not record the estimated vs actual times scrupulously, however, so someone should test this scrupulously to be sure. The tests should be done with things that take a decent time to manufacture, otherwise your results get skewed by the bug that you can't produce more than one object of the same type at the same base in the same hour. [[User:Spike|Spike]] 09:02, 18 October 2008 (CDT)

::Spike, your, how shall I say, correction, resonates soundly with me.  When I was running those tests the conclusions I made were done with quick, fuzzy, mental calculations, at best (and let's not mention the worst).  Anyway, what you say sounds right, although also as you say it deserves proper testing to be known.  I don't know about making more items than the number of hours it takes to produce them (considering how it's said that you can't "make more than one unit an hour"), but making one unit at a time definitely seems to stifle productivity.  This is especially important for me *exactly* right now in the game, since I can either make one Laser Cannon at a time, or a few Motion Scanners.  Even without running the tests that "prove" this theory, it makes sense to me that the scanners may be more productive.  Especially if I use a tactic probably not foreign to you, manually going to the base BEFORE production ends, selling the products, and increasing the product line's length with the increased revenue.  [[User:NightChime|NightChime]] 00:39, 23 October 2008 (CDT)

:::The one-unit-an-hour thing is a limitation of the game engine.  You can't produce more than 1 unit of a give item per hour; in fact, the game won't allows you to assign more engineers to an item than the number needed to produce the item as 1 per hour, if I recall correctly.  Except for the Gauss weapon ammo in TFTD; you can still only produce one clip or shot per hour, but you can assign as many technicians as you want, potentially causing serious lost productivity.  This would be one more oversight among the approximately 2,943,756 other oversights made when hacking TFTD together.  [[User:Arrow Quivershaft|Arrow Quivershaft]] 01:59, 23 October 2008 (CDT)

:NightChime, I feel your pain! In theory, selling produced units '''before''' "Manufacturing Complete", and using the money to increase the number of Units to Produce, should create a "never-ending" production run. This ought to have maximum efficiency. But does it? My gut feel was that this seemed to make things worse, that the rounding down went against me. I must stress there was no measurement at all, that is pure gut feel. 
:The other part of the question is: how inefficient is it to make just 1 Laser Cannon? Is maximally efficient Motion Scanner production more, or less, profitable than maximally inefficient Laser Cannon production? I may need to return to the labs, with a stopwatch and notebook in hand. 

:AQ, it's strange that only the Gauss craft ammo production is bugged in this way. That suggests the programmers deliberately disabled an existing general safeguard, with the intention of adding a feature to increase the production rate of this ammo (a sorely needed feature), and then lost the plot? [[User:Spike|Spike]] 04:01, 23 October 2008 (CDT)

::Spike: I find it far more logical and easier to accept that that the safeguard had to be hand-coded for each item and the programmers at Microprose either didn't realize this or didn't care.  Probably the former.  [http://en.wikipedia.org/wiki/Hanlon%27s_Razor| Hanlon's Razor] and all.  [[User:Arrow Quivershaft|Arrow Quivershaft]] 08:34, 23 October 2008 (CDT)

:OK I tested TFTD, and actually it never seems to check if you are allocating a uselessly large number of Technicians. I checked for all ammo types requiring less than 400 Tech Hrs/unit. In every case it will allow you to allocate more Technicians than are required to produce the maximum of one unit per hour. So, the safeguard is missing because... there is no safeguard! We probably only ever noticed it in the egregious case of Gauss Cannon ammo. For Enemy Unknown, there is a safeguard, all manufacturing is capped to allocate no more engineers than the number required to produce one unit in an hour (tested all items under 250 Eng Hrs/unit). [[User:Spike|Spike]] 18:09, 23 October 2008 (CDT)