Inventory system - Door-key item / Respawn

Grab your favourite IDE and tinker with the innards of game engines

Inventory system - Door-key item / Respawn

Postby Garrador on Wed Jan 01, 2014 3:45 pm


I'm currently developing an inventory sytem to a sourcesdk 2013 mod. Without going in to more about that, I have a more specific problem that is related to one specific item: A key.

Note: I'm very familiat with the source-engine, but not so much the code base (learning about its syntax/"rules" as I go).

It is a generic item that is to be configured to work properly in Hammer, by the level designer. The key (for now) takes two keyfields:

- Target to unlock : FIELD_STRING
- Discard on use : FIELD_BOOLEAN

The first one is the issue at hand (more or less).

In my "OnUse" handler, I need to be able to check if the key is being used on an entity with that name, as well as checking that the player is facing in the right direction and is pressing use in a given radius of that door/entity.

So, I have two psuedo-solutions I'd prefer:

- Handle all the unlocking and tracing logic in "OnUse"
- Use a custom trigger entity (brush entity) that the level designer creates paralell to the door entity that takes an input and searches the players' inventory for the matching entity.

If that is the case, the trigger will have to know about the door entity, the name of the key and then it will have to match it all up and work out the logic.

For any experienced SourceSDK programmer: Which is the best (or are there better solutions)?

EDIT: I encountered another issue that needs solving
So, obvious as it was, I loose properties that has been set, in Hammer editor, to an entity when I remove the entity from the world on-pickup.

I.e: I create an "item_key" in hammer. I set its "unlock target" to "door_03". It's all well and good when it spawns. When I pick it up in-game, my code calls on "UTIL_Remove" to remove the entity from the world. However; if I discard it from the inventory to spawn it back to the world, these properties are lost (my code simply creates the same type of entity and spawns it). This was quite obvious when I first encountered such an instance.

So my question is: Are there any standard functions/ways-of-doing-things when an entity and the properties set in hammer, needs to be saved?

Best regards,
You click on Build or type
make (or some equivalent), and you are astonished, then mortified, as you realize that the whole world is being
recompiled and relinked!
- Scott Meyers
User avatar
Joined: Fri May 12, 2006 10:39 pm
Location: Norway

Re: Inventory system - Door-key item / Respawn

Postby zombie@computer on Wed Jan 01, 2014 5:42 pm

Hmm, I would probably create derived door and/or button classes that check the players' inventory.

i.e., func_door

1) onuse:
2) door opens


1) onuser:
2) get 'using player's inventory
3) check for key
4) if key, remove from inventory, unlock (animation?), open as usual
5) else, show message, sound, etc.

As for the key properties, thats a wee bit more difficult; Because datadescs have a limited size (iirc 1 or 2 kb max) you cant really create an inventory easily where each item has (text-based) properties. I see three possibilities:

1) Number-based properties. For instance, have one or more bytes per item reserved for item properties. This byte can then hold info such as

health vials: health left in vial
Weapons/ammo clips: no of bullets
Key: unlock door no #1-255

This way you need to limit properties, but its pretty easy to implement. Besides that, you can add a Key# property which can take the value of 0-255, and simply checks for key #0-255 in the inventory. Im sure 255 keys is enough, and you can even recycle numbers with some careful planning. If not, increase the number of bytes per item to 2 or more.

Option 2: Add some kind of 'security level' flag to the player class. As soon as a key is sent to the inventory, the respective flag is set. Doors then check for the flag. Not really easier than the first option, but you can combine it with some extra data saving stuff if you want to keep names, eg by using savegame headers ( ... Game_Files) to store the data.

ie. Key 'opens the friggin door of the office' => on pickup adds the string 'opens the friggin door of the office' to a cutlvector in the player class. The door of the office checks for the string 'opens the friggin door of the office' to see if the player has the key, then does its things. The cutlvector can be save-restored in the save game. Cant remember how this stuff is carried over in level transitions, but its possible to get around the standard datadescs this way.

Option 3: Forget the datadescs completely and, expanding on option two, use your own networking and savegamefile headers to save load stuff. Quite some work, i never done it, so im not sure exactly how much work it is, but i cant recommend it, especially if you want to keep it portable (ie easily implemented in sp and mp mods and games)
When you are up to your neck in shit, keep your head up high
Forum Goer Elite™
Forum Goer Elite™
Joined: Fri Dec 31, 2004 5:58 pm
Location: Lent, Netherlands

Return to Programming

Who is online

Users browsing this forum: No registered users