Item ID - Revision history

BlueCrab: Checked that lower word does indeed go past 8-bits.

2010-12-01T04:54:47Z

Checked that lower word does indeed go past 8-bits.

← Older revision		Revision as of 04:54, 1 December 2010
Line 3:		Line 3:
	The first client (whose client ID is 1) in a lobby's Item IDs are (when a game starts) 0x0021xxxx, where xxxx is as described in the next paragraph. This is regardless of what the character data says when the game starts. The second client (whose client ID is 2) in a lobby's Item IDs are formed similarly, but are 0x0041xxxx. The third person in the lobby (client ID 3) has Item IDs of the form 0x0061xxxx. The last person in a lobby (with client ID 0) is formed as 0x0001xxxx. Thus, if divided into two parts (an upper word and a lower word), the upper word is formed as follows: <code>((client ID << 5) \| 0x0001)</code>. The lower word is the index within the items for that client ID (see paragraph below for the lower word).		The first client (whose client ID is 1) in a lobby's Item IDs are (when a game starts) 0x0021xxxx, where xxxx is as described in the next paragraph. This is regardless of what the character data says when the game starts. The second client (whose client ID is 2) in a lobby's Item IDs are formed similarly, but are 0x0041xxxx. The third person in the lobby (client ID 3) has Item IDs of the form 0x0061xxxx. The last person in a lobby (with client ID 0) is formed as 0x0001xxxx. Thus, if divided into two parts (an upper word and a lower word), the upper word is formed as follows: <code>((client ID << 5) \| 0x0001)</code>. The lower word is the index within the items for that client ID (see paragraph below for the lower word).

	If no client has been in a given slot, the lower word will start from 0x0000 and count up to whatever is in their inventory. If a client has been in a given slot, the item IDs start from where that earlier client left off. For instance, if the client with ID 1, and their highest item ID was 0x00210011, the next person that comes in and gets assigned client ID 1, their first item ID starts from 0x00210012. ~~I suspect that things may extend to 16-bits for the slot, but I don't actually have the patience to check that right now.~~ What happens when it overflows, I have no idea (by then, it'd most likely have to be safe to go back to 0x0000 as the base).		If no client has been in a given slot, the lower word will start from 0x0000 and count up to whatever is in their inventory. If a client has been in a given slot, the item IDs start from where that earlier client left off. For instance, if the client with ID 1, and their highest item ID was 0x00210011, the next person that comes in and gets assigned client ID 1, their first item ID starts from 0x00210012. What happens when it overflows, I have no idea (by then, it'd most likely have to be safe to go back to 0x0000 as the base).

	When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off. When a user picks up an item that is stackable (Monomate, for instance), if they already have a stack of them, the new item gets added to the current stack (and thus inherits the current stack's ID).		When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off. When a user picks up an item that is stackable (Monomate, for instance), if they already have a stack of them, the new item gets added to the current stack (and thus inherits the current stack's ID).

	Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.		Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.

BlueCrab: Expanding a bit...

2010-12-01T03:22:28Z

Expanding a bit...

← Older revision		Revision as of 03:22, 1 December 2010
Line 1:		Line 1:
	Item IDs are treated somewhat strangely by PSO... Here's a few notes regarding them that I've figured out from what I've learned thus far...		Item IDs are treated somewhat strangely by PSO... Here's a few notes regarding them that I've figured out from what I've learned thus far...

	The first client (whose client ID is 1) in a lobby's Item IDs are (when a game starts) ~~0x002100xx~~, where xx is ~~the position~~ in the ~~inventory~~. This is regardless of what the character data says when the game starts. The second client (whose client ID is 2) in a lobby's Item IDs are formed similarly, but are ~~0x004100xx~~. The third person in the lobby (client ID 3) has Item IDs of the form ~~0x006100xx~~. The last person in a lobby (with client ID 0) is formed as ~~0x000100xx~~.		The first client (whose client ID is 1) in a lobby's Item IDs are (when a game starts) 0x0021xxxx, where xxxx is as described in the next paragraph. This is regardless of what the character data says when the game starts. The second client (whose client ID is 2) in a lobby's Item IDs are formed similarly, but are 0x0041xxxx. The third person in the lobby (client ID 3) has Item IDs of the form 0x0061xxxx. The last person in a lobby (with client ID 0) is formed as 0x0001xxxx. Thus, if divided into two parts (an upper word and a lower word), the upper word is formed as follows: <code>((client ID << 5) \| 0x0001)</code>. The lower word is the index within the items for that client ID (see paragraph below for the lower word).

	If a client has been in a given slot, the item IDs start from where that earlier client left off. For instance, if the client with ID 1, and their highest item ID was 0x00210011, the next person that comes in and gets assigned client ID 1, their first item ID starts from 0x00210012. I suspect that things may extend to 16-bits for the slot, but I don't actually have the patience to check that right now. What happens when it overflows, I have no idea (by then, it'd most likely have to be safe to go back to 00 as the base).		If no client has been in a given slot, the lower word will start from 0x0000 and count up to whatever is in their inventory. If a client has been in a given slot, the item IDs start from where that earlier client left off. For instance, if the client with ID 1, and their highest item ID was 0x00210011, the next person that comes in and gets assigned client ID 1, their first item ID starts from 0x00210012. I suspect that things may extend to 16-bits for the slot, but I don't actually have the patience to check that right now. What happens when it overflows, I have no idea (by then, it'd most likely have to be safe to go back to 0x0000 as the base).

	When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off. When a user picks up an item that is stackable (Monomate, for instance), if they already have a stack of them, the new item gets added to the current stack (and thus inherits the current stack's ID).		When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off. When a user picks up an item that is stackable (Monomate, for instance), if they already have a stack of them, the new item gets added to the current stack (and thus inherits the current stack's ID).

	Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.		Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.

BlueCrab: Note about when people leave and other people take their spot in the party.

2010-12-01T03:17:00Z

Note about when people leave and other people take their spot in the party.

← Older revision		Revision as of 03:17, 1 December 2010
Line 1:		Line 1:
	Item IDs are treated somewhat strangely by PSO... Here's a few notes regarding them that I've figured out from what I've learned thus far...		Item IDs are treated somewhat strangely by PSO... Here's a few notes regarding them that I've figured out from what I've learned thus far...

	The first client (whose client ID is 1) in a lobby's Item IDs are (when a game starts) 0x002100xx, where xx is the position in the inventory. This is regardless of what the character data says when the game starts. The second client (whose client ID is 2) in a lobby's Item IDs are formed similarly, but are 0x004100xx. The third person in the lobby (client ID 3) has Item IDs of the form 0x006100xx. The last person in a lobby (with client ID 0) is formed as 0x000100xx.		The first client (whose client ID is 1) in a lobby's Item IDs are (when a game starts) 0x002100xx, where xx is the position in the inventory. This is regardless of what the character data says when the game starts. The second client (whose client ID is 2) in a lobby's Item IDs are formed similarly, but are 0x004100xx. The third person in the lobby (client ID 3) has Item IDs of the form 0x006100xx. The last person in a lobby (with client ID 0) is formed as 0x000100xx.

			If a client has been in a given slot, the item IDs start from where that earlier client left off. For instance, if the client with ID 1, and their highest item ID was 0x00210011, the next person that comes in and gets assigned client ID 1, their first item ID starts from 0x00210012. I suspect that things may extend to 16-bits for the slot, but I don't actually have the patience to check that right now. What happens when it overflows, I have no idea (by then, it'd most likely have to be safe to go back to 00 as the base).

	When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off. When a user picks up an item that is stackable (Monomate, for instance), if they already have a stack of them, the new item gets added to the current stack (and thus inherits the current stack's ID).		When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off. When a user picks up an item that is stackable (Monomate, for instance), if they already have a stack of them, the new item gets added to the current stack (and thus inherits the current stack's ID).

	Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.		Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.

BlueCrab: Add 3rd and 4th clients (and clarify what the client IDs are).

2010-12-01T02:43:03Z

Add 3rd and 4th clients (and clarify what the client IDs are).

← Older revision		Revision as of 02:43, 1 December 2010
Line 1:		Line 1:
	Item IDs are treated somewhat strangely by PSO... Here's a few notes regarding them that I've figured out from what I've learned thus far...		Item IDs are treated somewhat strangely by PSO... Here's a few notes regarding them that I've figured out from what I've learned thus far...

	The first client in a lobby's Item IDs are (when a game starts) 0x002100xx, where xx is the position in the inventory. This is regardless of what the character data says when the game starts. The second client in a lobby's Item IDs are formed similarly, but are 0x004100xx. ~~I have not tested beyond this yet~~ (~~but intend to soon, hopefully~~).		The first client (whose client ID is 1) in a lobby's Item IDs are (when a game starts) 0x002100xx, where xx is the position in the inventory. This is regardless of what the character data says when the game starts. The second client (whose client ID is 2) in a lobby's Item IDs are formed similarly, but are 0x004100xx. The third person in the lobby (client ID 3) has Item IDs of the form 0x006100xx. The last person in a lobby (with client ID 0) is formed as 0x000100xx.

	When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off. When a user picks up an item that is stackable (Monomate, for instance), if they already have a stack of them, the new item gets added to the current stack (and thus inherits the current stack's ID).		When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off. When a user picks up an item that is stackable (Monomate, for instance), if they already have a stack of them, the new item gets added to the current stack (and thus inherits the current stack's ID).

	Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.		Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.

BlueCrab: Add note about stackable items

2010-11-29T17:05:47Z

Add note about stackable items

← Older revision		Revision as of 17:05, 29 November 2010
Line 3:		Line 3:
	The first client in a lobby's Item IDs are (when a game starts) 0x002100xx, where xx is the position in the inventory. This is regardless of what the character data says when the game starts. The second client in a lobby's Item IDs are formed similarly, but are 0x004100xx. I have not tested beyond this yet (but intend to soon, hopefully).		The first client in a lobby's Item IDs are (when a game starts) 0x002100xx, where xx is the position in the inventory. This is regardless of what the character data says when the game starts. The second client in a lobby's Item IDs are formed similarly, but are 0x004100xx. I have not tested beyond this yet (but intend to soon, hopefully).

	When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off.		When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off. When a user picks up an item that is stackable (Monomate, for instance), if they already have a stack of them, the new item gets added to the current stack (and thus inherits the current stack's ID).

	Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.		Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29\|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.

BlueCrab: Add page with some notes about Item IDs.

2010-11-29T17:03:42Z

Add page with some notes about Item IDs.

New page

Item IDs are treated somewhat strangely by PSO... Here's a few notes regarding them that I've figured out from what I've learned thus far...

The first client in a lobby's Item IDs are (when a game starts) 0x002100xx, where xx is the position in the inventory. This is regardless of what the character data says when the game starts. The second client in a lobby's Item IDs are formed similarly, but are 0x004100xx. I have not tested beyond this yet (but intend to soon, hopefully).

When an item is picked up in-game, the item ID does not change from what the item on the ground said it was. It will change when the user leaves the lobby (to match what is stated above), but will not actually change in the character's data until the user logs off.

Meseta has an Item ID when its on the ground, but does not appear in the user's inventory (it is stored elsewhere in the character data). Removing meseta from a user is done by using a delete item message ([[Packet 0x60#Subcommand 0x29|Packet 0x60, Subcommand 0x29]]) with the Item ID set to 0xFFFFFFFF.