• get(id)
• getAll(interface)
• has(id)
• getCount(id)

Events ItemPickUpEvent ItemLostEvent

IWorldViewObject ← IWorldViewItem ← IWorldViewItemContainer

Note that there is no method “remove” in the IInventory - how to define custom “game mechanis” like “eat apple”? Ha! We will introduce a new layer to our diagram that will catch “commands” from the Agent and if needed produce new events for the worldview, thus we will able to create virtual commands “eat apple” that will be caught by the new layer, consumed and it will produce new event for the worldview. Thus we are able to adhoc define new capabilities to the used world.

As you can assume, there are plenty of items in UT2004 and some of them has some attributes. For instance a flak cannon is clearly a weapon, it can cause certain amount of damage and has a maximum of ammo you can stuff in it. As we can assume, those attributes does not change during the game and thus it is useless to send them all over again every time. Thus we can export those “fixed item characteristics” at the beginning of the game (in GB handshake similar to the way the navpoints and items are exported). Moreover a user can need his own items - let's say a cucumber, which has a certain taste, color and weight. So we need some way how to allow this and keep the communication low at the same time. Problem is that every item has different attributes. More precise every item class has different variables - thus we need a mechanism that translates string identificator of the item class into real Java Object (preferably with real fields not string map). So we need ItemTranslator object.

The item (or more precisly it's class) is sent inside AIN, IPK and INV messages. AIN messages states that the you has gained a new item into it's inventory (comes only the first time the bot gets the item). IPK message tells you that you have just picked up some item. And INV message tells you that you see some item. Each of those three messages should be transformed into a certain event that will be propagated to the world view - the problem is that each of those events should have information about the item written inside themselves. That's why we will have an object that can return you an “Item” for given “Item class” (that is obtained from the message).

So the idea is the same: 1) we make GameBots to send informations about item classes in the handshake (simply GB will iterate through all the items in the map and send those informations for every item class encountered) - it will be ITC message (ITemClass message) 2) based on ITC message we will create a Java factory that will produce new item's (java objects) of that class 2.1) those factories will be configured by the map of attribute_name:attribute_value that will be taken from ITC message 2.2) when INV, IPK, AIN message came it will take “class” attribute (that refers to item class) and ask the ItemTranslator “would you be so kind to provide me with the item of this kind?” and ItemTraslator will reply “be my guest, here it is” then this item will be wrapped into the appropriate event

Just the item translator doesn't know the item the user will be notified and new <GETCLASS> command shoul be send.

New proposal. We will have allmighty ITC batch info message in the handshake. ITC message will recognize attributes of all UT weapons and inventory. Because not all of the weapons/inventory share attrs. all attrs. will be optional. The ITC message will consist of ITC {PickupType xPickus.RocketLauncherPickup} {InventoryType xWeapons.RocketLauncher} {1Damage 30} …… a lot of other attrs.

This message will be accepted by a translator. Its position is marked on the picture below. It processes the given map of attributes and values and creates a factory which then produces configured items.

The problem is when we want to add some new item to UT at runtime. Solution: When using Pogamut add methods we will check if we have exported item of sel. class, if not we will send ITC message before spawning the object.

If some mutator does the same then the user will be notified that his bot sees something he doesn't know about and that he should send some new <GETCLASS> command.

• INV contains:
  • Item item;
  • Location location;
  • boolean reachable;
  • something else?
• IPK:
  • Item item;