128 | | Your done. Now you have a new pickup type with an appropriate representation for your use. If you feel that it is useful in general please don't hesitate create a template for the pickup and add your pickup to the pickup_representation_templates.oxt file and the pickups.oxi file, so that anyone who wants to use kit can do so quite easily. |
129 | | |
130 | | Let's assume you're still not satisfied. I mean, come on, we just used a pickup that already existed and created a new type by changing some parameter values and adding a representation, that's not really anything new now, is it? |
| 129 | Also there is a parameter defining how the pickup is displayed in the Pickup Inventory (a menu to browse your currently equipped pickups). |
| 130 | |
| 131 | {{{ |
| 132 | inventoryRepresentation = "MediumHealth" |
| 133 | }}} |
| 134 | |
| 135 | This is the name of an image defined in the PickupInventory imageset, which can be found in data_extern/gui/imagesets. |
| 136 | |
| 137 | Your done. Now you have a new pickup type with an appropriate representation for your use. If you feel that it is useful in general, please don't hesitate to create a template for the pickup and add your pickup to the pickup_representation_templates.oxt file and the pickups.oxi file, so that anyone who wants to use it can do so quite easily. |
| 138 | |
| 139 | Now let's assume you're still not satisfied. I mean, come on, we just used a pickup that already existed and created a new type by changing some parameter values and adding a representation, that's not really anything new now, is it? |
169 | | * The enity that carries your pickup needs to be derived from the PickupCarrier interface. And you need to implement the PickupCarriers virtual functions getCarrierChildren() and getCarrierParent(). Now let me explain, very briefly, why these functions are needed. All pickups are initially picked up by a pawn and the "propagated", or handed down to the entity that carries them. With the above mentioned two function just that is done. A hierarchical structure is established with one parent and a set of children, where the Pawn is the root node of this hierarchical structure, the only entity with no parent. |
170 | | * Once you have done that you will also want to specify in your pickup by which carriers it can be picked up, this is done via the addTarget() function. So you have to make sure the target is added whenever one of your pickups is created (so, most conveniently somewhere in the constructor), with the following command. |
| 179 | * The enity that carries your pickup needs to be derived from the PickupCarrier interface. And you need to implement the PickupCarriers virtual functions getCarrierChildren() and getCarrierParent(). Now let me explain, very briefly, why these functions are needed. All pickups are initially picked up by a pawn and then handed down to the entity that effectively carries them. With the above mentioned two function just that is done. A hierarchical structure is established with one parent and a set of children, where the Pawn is the root node of this hierarchical structure, the only entity with no parent. |
| 180 | * Once you have done that you will also want to specify in your pickup which carriers can pick it up, this is done via the addTarget() function. So you have to make sure the target is added whenever one of your pickups is created (so, most conveniently somewhere in the constructor), with the following command. |
176 | | Now that we have the skeleton of a pickup and we have defined which carriers are allowed to pick our pickup up we are going to take a look at all the methods we can (or sometimes have to) overload from Pickupable, for our pickup to work properly. Bu firstly I will introduce some more concepts to make the need for these methods more obvious. |
177 | | * Since one pickup class can itself be many pickup types we need a way to find out whether a particular instance of a pickup is of the same type as another instance of a pickup. To that end the PickupIdentifier (in the following just called identifier) was created. The PickupIdentifier accounts for the type of class your pickup is of and also for the parameters (and their values) that distinguish different types of pickups of the same class. Much of the functionality of the pickup module relies on this identifier being correct, thus it is very important to initialize it correctly. (We will see, how that is done in a short while.) |
| 186 | Now that we have the skeleton of a pickup and we have defined which carriers are allowed to pick our pickup up we are going to take a look at all the methods we can (or sometimes have to) overload from Pickupable, for our pickup to work properly. But first I will introduce some more concepts to make the need for these methods more obvious. |
| 187 | * Since one pickup class can by itself be many pickup types we need a way to find out whether a particular instance of a pickup is of the same type as another instance of a pickup. To that end the PickupIdentifier (in the following just called identifier) was created. The PickupIdentifier accounts for the type of class your pickup is of and also for the parameters (and their values) that distinguish different types of pickups of the same class. Much of the functionality of the pickup module relies on this identifier being correct, thus it is very important to initialize it correctly. (We will see, how that is done in a short while.) |
204 | | * initializeIdentifier() The initializeIdentifier() method initializes (or more simply put, creates) the PickupIdentifier of the instance of your pickup. Since the important values of the parameters are not yet available in the constructor of your pickup this initializeIdentifier() method must be called as soon as they are available, which normally is in the XMLPort() method, and the clone() method, as seen above. In the initializeIdentifier method you need to register each parameter that is important for the type of your pickup to its identifier, this is normally done as follows: |
| 215 | * initializeIdentifier() The initializeIdentifier() method initializes (or more simply put, creates) the PickupIdentifier of the instance of your pickup. Since the important values of the parameters are not yet available in the constructor of your pickup this initializeIdentifier() method must be called as soon as they are available, which normally is in the XMLPort() method, and the clone() method, as seen above. In the initializeIdentifier() method you need to register each parameter that is important for the type of your pickup to its identifier, this is normally done as follows: |
221 | | Be aware, this only works for parameters that are simple enough, meaning with pointers for example it will, naturally, not work. |
222 | | |
223 | | * createSpawner() The createSpawner() method needs to be implemented by any pickup directly inheriting from Pickupable (so if you inherit from Pickup, you don't need to implement this). It is used to create a spawner when the pickup is dropped. A standard implementation would look like this. |
| 232 | Be aware, this only works for parameters that are simple enough, meaning with pointers for example it will, naturally, not work, and other ways must be found (this is for example done in PickupCollection with a derived class of the PickupIdentifier, the PickupCollectionIdentifier). |
| 233 | |
| 234 | * createSpawner() The createSpawner() method needs to be implemented by any pickup directly inheriting from Pickupable (or directly from CollectiblePickup), so if you inherit from Pickup, you don't need to implement this. It is used to create a spawner when the pickup is dropped. A standard implementation would look like this. |