Talk:Base Stores

From UFOpaedia
Jump to navigation Jump to search

Q & A

Not sure it can be using integers here for the volumes internally - because you can fit 1-19 grenades into one space, which indicates there is rounding going on as they are 0.1 each. --Sfnhltb 05:11, 6 March 2007 (PST)

Yeah, you're right. It was real late at night when I wrote that and thought not using decimals would be simpler but using the 'round to the nearest 10' is more complicated. Pi Masta

Well I thought I would have time to flesh this out a bit, but somethings have come up recently and I won't have the time. So if you were waiting on me to finish this up, don't. (I put Zombie's notes back and removed mine). --Pi Masta 10:41, 8 March 2007 (PST)

Where'd all this data come from? Is there a file that lists the space taken up by these items? If so, where is it, so I can compile the list for TFTD items? Arrow Quivershaft 01:08, 14 June 2007 (PDT)

Internally game uses integer numbers, not floating-point. So each General Stores module capacity is 500. And game contains internal table for all 96 storable items at address .data:00472B98 (for UFO:EU CE).--Volutar 14:33, 25 February 2011 (EST)

Base Stores Anomalies

I'm not sure the behaviour described on the main page is fully correct. It may describe the display behaviour of screens, but not the actual behaviour of storing items in Stores.

There is definitely some weird behaviour with respect to Space limits in Stores. I've tried to dig into it a little further. There are various kinds of anomalies. I suspect what's going on is a mixture of inconsistent rounding/truncation techniques being used in different places, and the occasional "loop off by one" type of coding error (boundary condition error).

First of all here are the different ways you can increase (or lower) the amount of stuff stored in a Base:

  1. Base: Purchase/Recruit screen (Purchase items for the Base)
  2. Base: Equip Craft screen (Move items from a Transport to the Base Stores)
    1. Ammunition unloaded from an HWP also ignores the current Space (provided the HWP itself is ok to move into Stores)
  3. Base: Transfer screen (move items from another Base)
  4. Base: Manufacture (Items will still be manufactured at a Base whether there is free Space or not)
  5. Geoscape: Recoverable items in a Battlescape mission are teleported back to the originating Base immediately upon return to the Geoscape, regardless of Stores capacity at that base.

Here are the different ways you can attempt to determine the total Stores space used in a base:

  1. Base: Base Information (totals) screen
  2. Base: Base Information: Stores (detail) screen
  3. Manual count using the Space factors on this page
  4. Trial and error using any of the methods above (1-3) that are Space-limited when they add items to Stores

All of the preceding methods of storing items and displaying the Space used have slight discrepancies with each other.

Display Anomalies

The top level Base Information (totals) screen gives probably the most accurate picture, but it's not exactly accurate. The function that seems to be used here is to add all the individual items weights up, and then apply integer truncation. So 49.9 space units will be shown as 49; 0.9 space units used will be shown as 0.

The detail-level Base Information: Stores screen uses a similar but different integer truncation function. Unlike the top-level screen, the Stores screen has a minimum value of 1 for any non-zero amount. This means that in effect it rounds up between 0 and 1.0, and then (like the totals screen) rounds down for all values greater than 1.0. This makes the detailed Stores values inconsistent with the totals screen.

Another discrepancy is that the top level screen includes the space used by incoming Purchases and Transfers; the detail screen ignores anything that is not actually in the Base at present.

Note that the integer truncation on both screens is display only. It does not mean that you can store e.g. 9 rifle clips (total 0.9 Space) and it will take up no space in Stores (contrary to the current article page statement). (To prove this, sell everything, then buy 250 pistol clips and 250 HC-AP clips. Then try and buy 9 rifle clips, or transfer them from a Transport or another Base: You can't.)

Lastly, while it is possible by various in-game means to store more volume of items than you have storage Space, the totals display will never go above the maximum rated "100%" official capacity. The detailed Stores display, on the other hand, will show totals that are greater than the official capacity. For example, if you load 9 HWPs into only one General Stores, the Total screen will show 50 Spaces used (incorrect), but the detailed Stores screen will show 54 Spaces used (correct).

Storage Anomalies

There are some off-by-one or boundary condition issues which will sometimes allow you to store one more, or one less, item than you were expecting. As noted on the main article page, the Purchase function will allow you to buy one additional unit of anything, regardless of whether it exceeds available Space, provided you are currently below your storage space limit. So for example with storage space of 49.9 out of 50 in use, you could Purchase one tank (6 spaces). So in fact you would be storing 55.9 spaces of equipment in only 50.0 spaces of storage. As noted above, your Base Information display will report only 50 Space used, even though it's actually should report 55 (truncated from 55.9).

Similarly, the Purchase screen will allow you to buy 1 more of an item than the highest number that will fit in your remaining Store space. So since 8 tanks (Space=48) will fit in an empty stores, you are actually able to Purchase 9 tanks in a single purchase (Space=54).

The Transfer screen does not suffer from this "off by one" checking bug, so it would appear to use a different Space checking algorithm. The Transfer screen seems to be have exactly as would be expected from the rated Stores capacity and the item Space requirements shown on this page.

In any of the situations (listed above) where "official" maximum storage capacity is exceeded, a strange anomaly occurs in which you can remove an item from Stores, but you are then unable to immediately replace the exact same item in the very same Stores you just took it from. Even though it "fit" in Stores when you removed it, when you try to put it back it won't fit. The reasons for this do make sense, but would be much easier to understand if the Base Information display had been accurate and told you that your Stores were more than 100% full before you removed the item.

The Equip Craft function behaves the most unpredictably. This can lead to some strange anomalies when moving equipment to and from Transports, with Stores nearly full, that are hard to understand. Sometimes it allows you to store more than the correct maximum, sometimes it allows you to store less than the maximum. Furthermore, different item types of the exact same weight will often show very different limits. For example, you can have items of the same size on a Transport (Rifle/Pistol/HC/AC Clips for example), and be able to move several of one item type into Stores but none of the other item type.

This looks like it might be something along the lines of the game engine in some way rounding or truncating the total weight of that particular item type to an integer, before doing the check to see if that number of items (with total weight rounded) could fit into Stores. This hypothesis gives an approximate explanation of observed results, but not an exact one. Perhaps this is part of the explanation, but also interacts with some off by one errors that are similar to the Purchase behaviour. Further testing is needed to confirm this. In analysing this, it is important to keep in mind that the various methods of moving items into Stores may well all use different, inconsistent, check logic and integer rounding/truncation. Also it's important to examine the various combinations of Transferred in-Transit, Purchased in-Transit, and transfers using Equip Craft. Also it's important to use combinations of multiple item types with different Space requirements, and not just the very simple cases such as all the same item (500 Pistol Clips) or all the same Space requirement (250 Pistol Clips and 250 Rifle Clips).

Summary and Next Steps

In conclusion, the game counts currently-used storage Space with good accuracy, but displays it inconsistently and somewhat inaccurately, and makes some minor logic errors when testing to see if an item can be stored.

Overall, management of Space is actually more accurate and more fair than is implied in the current article. There are some small errors but they cut both ways and the net effect is hardly a serious exploit or serious handicap. The biggest 'exploit' would be to store 60.7 Space worth of equipment in 50 Space of Stores (unload a loaded rocket tank into Stores with 49.9 currently used Space). The main irritant is weird and illogical behaviour, such as taking something out of Stores and then not being able to put it back in again.

If people are interested in getting to the bottom of this, next steps for investigations could involve a much more systematic look at where the rounding/truncation breakpoints occur in all of the 3 methods of deliberately storing items in Stores, including looking at combinations of multiple types of items. I have done this but only really with Purchasing and Equip Craft, and not thoroughly. A more promising approach might be to decompile the relevant sections of the code. Probably the approach that is used will depend on the skill set of whoever tries it.

Ultimately, a patch could be provided to make at least one, and preferably both, of the display methods show accurate and consistent results. Adding one digit of precision (tenths of a Space unit) would be helpful. Removing the minimum of 1 Space shown for non-zero Space on the detailed Stores screen would be very helpful, as would removing the cap of 100% on the totals (Base Information) screen - perhaps with a highlight colour when 100% Space has been exceeded. Spike 11:41, 30 November 2008 (CST)