I see 3 option here:
1) You're confusing object ID with its model
2) You have imported 50 different mine pillar models
3) You defined 50 different objects using the same model, and confused the model with the object name
Solutions:
1) Objects present in the dungeon automatically alter themselves to what you defined them upon reloading the dungeon, so you don't have to change anything about them. (Unless you've added/removed special components such as a timer)
For example, I placed an object named my_object in the dungeon, and I told it to use the skull item model. It will appear as a skull.
Then I go back to the definition and tell it to use a sword model instead. Upon reloading, the object will use the sword model.
2) I really hope this isn't the case...
You can define a lot of objects by typing one definition with a "for" function.
Something like this: (You can just copy-paste it and change the model path to what you need)
Code: Select all
for i=0,3 do
local str = function(str) return (string.gsub(str, "?", iff(i > 0, i, ""))) end
defineObject{
name = str("mummy?"),
baseObject = "base_obstacle",
components = {
{
class = "Model",
model = str("assets/models/monsters/mummy?.fbx"),
storeSourceData = true,
},
},
}
end
Here, the definition will define 4 different models for mummies. (0,1,2,3)
Every question mark symbol inside an
srt() will be changed to a number (or removed if the number would be 0) based on the current
i.
In the
for i=0,3 do, you can change the 3 to the number of models you have -1. (because 0 counts as 1 already)
All your models will have to same the same path, and same name except for the last number. For example:
Code: Select all
assets/models/monsters/mummy.fbx (i = 0)
assets/models/monsters/mummy1.fbx (i = 1)
assets/models/monsters/mummy2.fbx (i = 2)
assets/models/monsters/mummy3.fbx (i = 3)
3) Here you can only hope you're using a custom
base_object so you could go there, and set minimalSaveState there to true.
base_object is what you're currently defining will use as a base. It copies all data from that object, and then it gets altered based on what you defined. (if at all)
For example, I'm using the base_door as my base_object. In my object, I change the model and add a particle. The door and the controller components from base_door will transfer to my object. Think of it as a son getting his fathers riches through a will.
So in this case, if you give the base_object minimalSaveState, it will transfer to everything that uses the base_object. I highly recommend you
don't change/reimplement base_pillar with minimalSaveStae, because many vanilla pillar objects use base_pillar, and it might cause some issues.
If these custom object don't use a base_object, you have no choice but to go through all of the definitions by hand.
I suggest you implement a new object named base_pillar_minimalsave, give it minimalSaveState and have all of your custom pillar objects use it
as a base_object. Will also save trouble in the future if you're going to define new pillars.