I have made an inventory that uses globalDict to store the items.
items are stored into categories that you can define for each object.
This will make it easier to implement a crafting system, sorting object, or what ever you like.
What can you do?
- grab items and place it in an inventory
- show/close inventory
- drop items on the ground
- drag the inventory around
- see what item you have dropped/picked up
- stack items
- create categories
inventory will restore to last known position on opening
What options can you set?
global:
- amount of slots
- stack size
- max slots allowed a row
- border size
- text positions of the items
- notification time
- some minor things
does it store the objects name, and properties etc?
This is a rough version of the version i am using.
the grabbable item got 4 properties:
inventory - pickable yes/no
category - witch category the item gets into
item - item name, same as the plane representing the item in the inventory. You can also change this into a property, this version uses the plane name and cheks it with the item property.
this info will get into the GD, while the item/plane name links the object, it should not be a problem to get it all saved and loaded if that is what u mean.
not tested but it should be saveable with the save actuator, or use the save/load in my description.
glad you like it, im sorry, i am not going to make tutorials about that subject, just ad a material with a texture to the plane, simplest solution. if you need more details llok for tutorials for texturing objects.
If you have questions about my inventory sure, if you have question on the one you are building on your own, then you should create an topic in the support and discussion sub forum.
why not directly put all properties into a list while creating the list?
obj_data['properties'] = {prop: obj[prop] for prop in obj.getPropertyNames()}
all properties are now saved into an object property. No messing around creating additional lists.
you can save all with an easy for loop looking for a property the items carry then act to it:
objects_array = []
for obj in [obj for obj in scene.objects if 'a_property' in obj]:
obj_data = {}
if obj.getPhysicsId():
obj_data['velocity_L'] = list(obj.localLinearVelocity)
obj_data['velocity_A'] = list(obj.localAngularVelocity)
obj_data['name'] = obj.name
obj_data['position'] = list(obj.localPosition)
obj_data['orientation'] =
[list(vector) for vector in obj.localOrientation]
obj_data['properties'] = {prop: obj[prop] for prop in obj.getPropertyNames()}
obj_data['color'] = list(obj.color)
obj_data['scale'] = list(obj.scale)
objects_array.append(obj_data)
own['all_data'] = objects_array
copied and adjusted this example from my save and load. (did not test color and scale, so no idea if its a list or vector thought list would be enough, but its all about the example)
this way you really can grab anything without much effort and put objects array into the slot.
I typically have some hiarchies that know each other by storing a ref to a game object, I created a serial key that is +1 every object added and assign each obj a serial, so when closing you convert game object ref to serial numbers.
so I itterate props and do diff stuff depending on type(object[prop])
ah ok, im just using its name as a reference,no idea what i have against serials/id’s, same with mysql i always add an id to the database but end up never using it, so i just see it as an additional check to be sure that you don’t have duplicates.
However i rather store data into the GD so i can always acces anything i want to from where i want to.
For neighbors it’s great, but this inventory does not look for neighbors , it’s simply an empty that moves a slot space for every item in the inventory(GD) and adding an item from the GD, so you can sort it by placing the items from the GD to a list that you can sort any way you like.
to be fair, your system is feature complete already,
the game object stuff and serial number stuff I am using for mapmaking in game* (so tiles can look up objects pinned to them and update their entry before deleting them etc)
Hehe indeed, seen some if not all that you share(d), but somethings are just 1 degree to high for me to understand it right away, and i’m to busy with all kinds of stuff, that means i cant always dive deeper into it so i kinda get stuck at times, but that’s a total other story.
Thanks, wel to be honest it can use a tiny bit of a cleanup/adjustments but its not necessary
it’s still working strong, so i’m happy about that.
#edit
(so tiles can look up objects pinned to them and update their entry before deleting them etc)
are you not using obj.children for that? at least if with pinned you mean parented to it.
tiles are vertex splat mapped and are used over and over by pulling tiles from the back, saving the contents (vertexDataDict,objects,roadTiles)
then deleting them, then moving the tile to a open position ahead of the player, deforming it, set vertex color / normal, and than spawn objects / road tiles that belong to that tile.
so it’s like each tile has a inventory in a way, that is changed each time the tile is reused. (the first time a tiles fills a location the player has not seen,
it procedurally generates the tile using perlin worm/ perlin noise)
since I am using upbge ge_normals branch,
adds KX_meshProxy.recalcNormals(index)*
I can generate the tile data in realtime at 60 fps.
You came a far way with it, i like it, but my problem is that it is made in UPbge. I’m stubborn and sticking with BGE till it has no good use for me anymore, or till i need the quality UPbge delivers. For now BGE is enough, (sadly) i need to do it without some good features, but this gives me time to learn more before i jump to it as well. But looking at your video, it rises more questions but i won’t bother you with it i can’t use it for now anyway, and the topic is getting to far off the rails. Anyway great job.
#edit
so it’s like each tile has a inventory in a way
exactly, and that is why i use the GD as a database instead of the objects itself.
GD = logic.globaldict['tiles']
for tile in GD:
print(tile['name'], tile['location'], tile['neighbors''])
in a way it’s exactly the same, but lighter i guess.
you can use your serial to look up info from the database (GD) rather then trough objects. And the beauty of it is you can use this data everywhere with ease, just call the GD and all data is at your fingers.