I have read that adriansnetlis problem is solved.
Best way to debug this script is by removing all save properties from the objects until you find the object you try to save that gives errors.
I have not tested this, but it should work i guess. try this:
for obj in [obj for obj in scene.objects if 'save' in obj]:
obj_data = {}
if 'Text' in obj:
properties = {prop: obj[prop] for prop in obj.getPropertyNames()}
obj_data['name'] = obj.name
obj_data['properties'] = properties
obj_data['save'] = obj['save']
objects_array.append(obj_data)
else:
print('- ' + obj.name + ' (' + str(obj['save']) + ')')
position = list(obj.worldPosition)
orientation =
[list(vector) for vector in obj.worldOrientation]
properties = {prop: obj[prop] for prop in obj.getPropertyNames()}
obj_data['position'] = position
obj_data['orientation'] = orientation
obj_data['name'] = obj.name
obj_data['properties'] = properties
obj_data['save'] = obj['save']
objects_array.append(obj_data)
Keep in mind this is only the save part, you need to adjust the loading aswell, else it will throw out errors because you arent saving position and orientation of those objects, so the script cant set them.
Are you aware that you cannot save āstaticā objects using this method? Any objects that were not instantiated during the game cannot be re-loaded. Iāve implemented this support in my resource, if you would like to take a look.
Youāre clearing the scene objects before loading them by spawning new objects. If the objects that you delete were not added using addObject or the add object actuator (i.e they were already in the active layer, from blender) then you cannot use addObject to add them
Youāre clearing the scene objects before loading them by spawning new objects. If the objects that you delete were not added using addObject or the add object actuator (i.e they were already in the active layer, from blender) then you cannot use addObject to add them
Ah is that what you mean, i thought something else. It works agoose, thats why i making use of a boolean.
True is inactive (spawned objects)
False is object that are in the main layer.
It is all working, so please donāt say that something isnāt working while you didnāt test it!
I only load data from the main layer, and i spawn new objects from the inactive layer.
And why would you kill something from the main layer, if you want to ise it lateron?
so those objects should be added already instead of being in the main layer.
I tested it, and enabling āsaveā caused an error. I suggest that this shouldnāt happen, and in order to prevent it you should take care to consider how instances are managed. If the user deletes an object in game, then the script will fail later on, which instead should probably display an error.
In addition, partially due to the naming of the property - āsaveā, I skimmed through the code and overlooked the saving object main layer objects. I would recommend, if you decide to keep the property, using two properties - one called āsaveā to mark the object as saveable, and one called āis_instanceā, to avoid confusion. You can, however, infer this when you load objects back in - if theyāre on a hidden layer, then any instances should first be deleted before loading.
I tested it, and enabling āsaveā caused an error.
So you tested it with an object in the main layer? yup you will get an error because active(main layer) objects needs āsaveā to be false.
Tell me in what senario would you like to delete objects that are in/from the main layer?
Just donāt kill em, and all data will be reloaded upon loading the game.
Killable data should be in an inactive layer, with āsaveā true.
they get spawned into the main layer, can be killed and respawned when the user whants.
If the user deletes an object in game, then the script will fail later on,
Only if the object is from the main layer with āsaveā True. And this is something you want to avoid.
Indeed, I suggest that this shouldnāt happen, and instances should be detected by the script without needed explicit saving. This can be done by checking if there is an inactive object with the same name. In addition, the name āsaveā implies the object should be saved, with the value toggling this state, whereas you use the value of āsaveā to indicate whether is is an instance or not. Perhaps splitting this into two parameters (if you want to manually indicate that this object is an instance) would avoid this confusion.
Generally speaking, assume users make mistakes, and display an error and catch this exception.
I was about to suggest this - saving the local space state will ensure that parenting doesnāt cause issues if you set objects in the wrong order. Try replacing worldPosition with localPosition (some for orientation, velocity)
