Talk:Managing the Item Limit
Does anyone know if modding the .exe to raise the 80-item limit is feasible? The 80-item limit is the most "dated" thing about the game... that, and the limit on alien containment capacity.
It's not possible as of now. (We do not know the location of this limit). Even if we could "up" the limit for X-COM agents, it would cut into the aliens item limit and some alien units would probably get "shorted" on weapons since there are only so many items which can be placed on the battlescape map. A real pickle this is, but a necessary evil. --Zombie 19:53, 19 January 2007 (PST)
Well, I should have said, raise the overall limit as well... since memory isn't an issue now. Eric 10:30, 20 January 2007 (PST)
Memory is always an issue in 16-bit DOS binaries. It is not possible for a single DOS pointer, in 16-bit mode, to address more than 64K of memory.
The simplest way to implement the savefile format is that each file corresponds to one array of C structs. PROJECT.DAT is the exception, but even that may be a single C struct internally. Then each file in the savefile is simply dumping/loading the array using the relevant functions from stdio.h...very fast, somewhat clean.
Good programming practice would be to either dynamically allocate the relevant arrays on tactical/battlescape start, or statically allocate them. Since none of the save files vary in length or have explicit record counts, I'd conjecture that the intended sizes of the arrays are compile-time constants, either #define'd or (for statically allocated arrays) computed using the sizeof(array)/sizeof(array_element) paradigm.
Note that there is a total limit of 64K on static data in all 16-bit DOS memory models. So the larger save files (e.g, map.dat and soldier.dat) have to be dynamically allocated.
In any case, there is plausibly no single "location" for these limits -- such a mod would have to not only locate and adjust the storage (and all later storage, in the case of statically allocated array), but also locate and adjust the compile-time constants everywhere they were used.
Zaimoni 13:27, 20 January 2007 (CST)
Some of the arrays do seem to vary in size - The map being one of them, by memory. However, the game simply overwrites the contents of each file with each new save, so the only time a file size changes is if it needs to be extended.
As for the 64K limit, none of the save files come close. The item table is a constant 170 records of 16 bytes each (2720 bytes total). Even the largest map file I've ever seen is only 40K.
In order to extend this, a number of things would need to be done:
- Find out where the array size is defined. My bet is there is a single location in both the geoscape and the tactical engines. Tactical uses it for battle, geoscape uses it for working out what items have been recovered at end of combat.
- Find the bit that deals with the save files (again, in both the geoscape and tactical engines) and force them to read/write the updated amount of data.
- Find the bit that limits your item count to 80 and extend it. This is only in the geoscape engine.
On the other hand...
What are the limits for alien gear? What's the largest amount of kit they've been known to bring into battle? They typically bring a max of four objects per unit, typically three (again, by memory). I don't think raising the 80 item limit alone is going to flood the item table, so it may just be that the third item on my list is the only one that needs tweaking.
- Bomb Bloke 20:42, 20 January 2007 (PST)
Erratum: I somehow forgot that structs can contain arrays, so PROJECT.DAT is not an exception.
Yes, there should be a single location in the original C source code defining these array limits. While the map data has a dynamic saved size, the unit and object data not only do not have a dynamic size, they have "unused records" markers. So these limits are likely either:
- a (logically) const variable set at program start, or
- a #define'd constant
A const variable can be modded by adjusting only one location. A #define'd const becomes a zoo of inlined constants.
Zaimoni 10:56, 21 January 2007 (CST)
The obpos format isn't entirely clear, however it seems to be the case that each record is made up of 16 single byte values. That can be summed up as a 170x16 byte array... Which is how my editer stores it. (I then use methods, or functions if you like, to manipulate the data).
That doesn't mean that's how the programmers did it. I'm leaning towards the #define method, I'm afraid, as I'm sure it's more efficient.
- Bomb Bloke 19:21, 21 January 2007 (PST)
biger problem
The 80 item limit is part of a biger issue. it's imposed as a stopgap on hiting the 255 total item limit in the file tracking items on the battle field. the index to that file is only one byte long. This item list include all weapons, ammo and dead/uncountious bodies on the battlefield. On the superhuman level this limit can often be reached leading to unarmed aliens, and units disapearing if they get knocked uncontious or killed.
--BladeFireLight 21:35, 20 January 2007 (PST)