So I’ve hit yet another roadblock! This time it’s something I haven’t really found any sort of example for because as far as I know this isn’t a commonly used system if it’s used at all. I’m designing my item system to be easy for my partner, who is an artist, to be able to implement any item he comes up with without me being here. So if it worked it would work by taking the object that is to become an item and giving it some properties in the logic editor: item, and the stat to be upgraded by the item. The thing that isn’t working out is I can’t get the name of the property from the item. The name of the second property will be different in different items so I need to access the second property it has without knowing the name, then use the name to know what stat to upgrade, then use the value of the second property to upgrade said stat.
Rundown: Player collides with item, players script gets a list of properties inside item, the second property’s name indicates the stat to be changed, the value of it indicates how much to change it by
The property item is just for the collision detection.
So my official question is how do I get a list of the properties in an item without knowing their names?
You can get all property names with KX_GameObject.getPropertyNames(). [something like that … I can’t verify as the API site has problems since weeks.]
Better do not rely on the order of properties. See the game object as a container with un-ordered properties. You can’t change the order anyway. What you see in GUI and what you get in Python might not match.
I suggest you use a specific naming convention e.g. with a prefix or suffix “my.property.001”. (Be aware properties with “.” cause some problems with Property logic bricks. This is a leftover from 2.48 -> 2.49 API change).
According to your description your interface with your partner seems not to be that good as you think of. Usually it should not be a big deal to define some required names beforehand.
When I was prototyping a rpg game I always thought I’d make such system like this:
There are x number of stats such as strength, agility, vitality, speed, that can be affected by equipment. Then each equipment only needs properties named “strength” “agility” “vitality” “speed” if they wish to modify the stat.
In script I would handle this in basic outline:
eq = scene.objects("Holy Armor")
if "strength" in eq:
own["strengthbonuses"].append(eq["strength"])
if "agility" in eq:
own["agilitybonuses"].append(eq["agility"])
if "vitality" in eq:
own["vitalitybonuses"].append(eq["vitality"])
You can probably see a pattern there and if you have a lots of stats, say 8 or more you might want to parametrize and loop the function instead.
Ofc the setup needs to be a bit more complex because you need to be careful to only count each bonus for each item once even if there is a hiccup somewhere in loading/saving, player input etc.
I won’t have more than three or four stats and they are there for my benefit, not the players. The player won’t even see them in game, except for health. Thanks for the tips, my system isn’t set in stone and I’ll definitely take into account everything you guys said
You can store your inventory as a list, each item slot as a list item, this way you can cap how many items you can carry at a time. When the item is dropped, you can shift all the items over in the list. This way you can get the object name from the list, then compare it to an array with all the stats of every item. There can be a value in this array that defines the object to represent it as then replace the mesh. They can then effect an array that defines the player stats. This system is way more modular, in my mind.
Oh and monster the problem with allowing my partner to make items is not that I don’t know what he’ll name them, but rather that he has no sort of programming knowledge and I wanted him to be able make an item just by giving it properties in the logic editor. We will have set in stone names for the properties that you can and can’t access, they’ll just have different names depending on what the items do and I want the script to be able to work with any item that has those properties without specifically coding in each item.
This is exactly how you should implement code. The 3D-Model designer should not care the code, but he has some tools that enables him to add information the code might need. But he need to know this tools. The tools should be simple to be used from all participants with sufficient information for all parties.
As you describe your tools are the properties (which is simple). You tell him how you want the properties and he can apply them as needed (= interface).
The interaction is two ways. While you want the properties, he might want to know how to combine animations (e.g. hit, grab, walk etc.) as they are strongly logic driven.