Talk:Managing the Item Limit - Revision history

Bomb Bloke at 03:21, 22 January 2007

2007-01-22T03:21:35Z

← Older revision		Revision as of 03:21, 22 January 2007
Line 51:		Line 51:
	[[User:Zaimoni\|Zaimoni]] 10:56, 21 January 2007 (CST)		[[User:Zaimoni\|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.

			- [[User:Bomb Bloke\|Bomb Bloke]] 19:21, 21 January 2007 (PST)

	== biger problem ==		== biger problem ==

Zaimoni at 16:55, 21 January 2007

2007-01-21T16:55:34Z

← Older revision		Revision as of 16:55, 21 January 2007
Line 38:		Line 38:

	- [[User:Bomb Bloke\|Bomb Bloke]] 20:42, 20 January 2007 (PST)		- [[User:Bomb Bloke\|Bomb Bloke]] 20:42, 20 January 2007 (PST)

			----

	Erratum: I somehow forgot that structs can contain arrays, so [[PROJECT.DAT]] is not an exception.		Erratum: I somehow forgot that structs can contain arrays, so [[PROJECT.DAT]] is not an exception.
Line 47:		Line 49:
	A const variable can be modded by adjusting only one location. A #define'd const becomes a zoo of inlined constants.		A const variable can be modded by adjusting only one location. A #define'd const becomes a zoo of inlined constants.

	[[User:Zaimoni\|Zaimoni]] 13:27, 20 January 2007 (CST)		[[User:Zaimoni\|Zaimoni]] 10:56, 21 January 2007 (CST)

Zaimoni at 16:54, 21 January 2007

2007-01-21T16:54:00Z

← Older revision		Revision as of 16:54, 21 January 2007
Line 38:		Line 38:

	- [[User:Bomb Bloke\|Bomb Bloke]] 20:42, 20 January 2007 (PST)		- [[User:Bomb Bloke\|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.

			[[User:Zaimoni\|Zaimoni]] 13:27, 20 January 2007 (CST)


	== biger problem ==		== biger problem ==

BladeFireLight: biger problem

2007-01-21T05:35:13Z

biger problem

← Older revision		Revision as of 05:35, 21 January 2007
Line 38:		Line 38:

	- [[User:Bomb Bloke\|Bomb Bloke]] 20:42, 20 January 2007 (PST)		- [[User:Bomb Bloke\|Bomb Bloke]] 20:42, 20 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.

			--[[User:BladeFireLight\|BladeFireLight]] 21:35, 20 January 2007 (PST)

Bomb Bloke at 04:42, 21 January 2007

2007-01-21T04:42:51Z

← Older revision		Revision as of 04:42, 21 January 2007
Line 18:		Line 18:

	[[User:Zaimoni\|Zaimoni]] 13:27, 20 January 2007 (CST)		[[User:Zaimoni\|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.

			- [[User:Bomb Bloke\|Bomb Bloke]] 20:42, 20 January 2007 (PST)

Zaimoni at 19:33, 20 January 2007

2007-01-20T19:33:50Z

← Older revision		Revision as of 19:33, 20 January 2007
Line 9:		Line 9:
	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.		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 ~~or two arrays~~ 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.		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.		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.

Zaimoni at 19:29, 20 January 2007

2007-01-20T19:29:29Z

← Older revision		Revision as of 19:29, 20 January 2007
Line 6:		Line 6:
	[[User:Eric\|Eric]] 10:30, 20 January 2007 (PST)		[[User:Eric\|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.		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 or two arrays of C structs. [[~~PROJECTS~~.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.		The simplest way to implement the savefile format is that each file corresponds to one or two arrays 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.		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.

Zaimoni at 19:27, 20 January 2007

2007-01-20T19:27:41Z

← Older revision		Revision as of 19:27, 20 January 2007
Line 5:		Line 5:
	Well, I should have said, raise the overall limit as well... since memory isn't an issue now.		Well, I should have said, raise the overall limit as well... since memory isn't an issue now.
	[[User:Eric\|Eric]] 10:30, 20 January 2007 (PST)		[[User:Eric\|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 or two arrays of C structs. [[PROJECTS.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 <b>later</b> storage, in the case of statically allocated array), but also locate and adjust the compile-time constants everywhere they were used.

			[[User:Zaimoni\|Zaimoni]] 13:27, 20 January 2007 (CST)

Eric at 18:30, 20 January 2007

2007-01-20T18:30:32Z

← Older revision		Revision as of 18:30, 20 January 2007
Line 4:		Line 4:
	----		----
	Well, I should have said, raise the overall limit as well... since memory isn't an issue now.		Well, I should have said, raise the overall limit as well... since memory isn't an issue now.
	~~````~~		[[User:Eric\|Eric]] 10:30, 20 January 2007 (PST)

Eric at 18:30, 20 January 2007

2007-01-20T18:30:09Z

← Older revision		Revision as of 18:30, 20 January 2007
Line 2:		Line 2:
	----		----
	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. --[[User:Zombie\|Zombie]] 19:53, 19 January 2007 (PST)		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. --[[User:Zombie\|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.		Well, I should have said, raise the overall limit as well... since memory isn't an issue now.
			````