Deactivating Unused Instances used for properties

Put the object in your Layout if you want it to be loaded into memory. Otherwise if you Create an object that is not in your Layout (but in your objects folder) the game could jank pretty hard and this is generally not done.

Usually you put all objects that could be in this (layout) part of the game and for certain objects we don't actually want them to actually spawn just yet.

I create a group under my On-Start-Of-Layout event and I call the group Destroys, in there I destroy everything that I don't want in the layout.

The only problem with this is that if you have an OnCreated or OnDestroy Trigger, these WILL trigger. Which is why I also declare a global variable called Once=false. At the end of the sheet I set Once to true, then both my OnCreates and OnDestroy also check if Once is true, that way it won't fire that first time. Not sure if this latter part is part of your problem or not.

To add to jobel's comment.. XanthorXIII, It depends on what you mean by "deactivate instances". You can make them invisible and disable collisions. But they can still interfere and mess with your events, for example when you use For Each loops, count the number of instances left etc. So the safest option is to destroy all instances that you don't need anymore.

I don't know why do you need to read imageWidth/imageHeight properties for sprites that are not on the layout, but maybe you can do this in advance. For example, on the loading layout or your main menu screen - add sprites to that layout and save their image dimensions in global variables or an array.

Exactly as jobel explained in the previous comment, instances on a "ObjectBank" layout work as "blueprints". When you create a new object instance in runtime, Construct needs to get object properties (angle, size, opacity etc.) from somewhere. If there are no instances for this object in your project, Construct will not be able to read these properties and will fail to create a new one.

That's why the common practice is to have a separate unused layout as a storage for default instances.

Of course, you don't need to dump everything on this layout, only the objects which don't exist on other layouts and which you are planning to create in runtime.

Edit: I guess your question was more about "how Construct engine can read these properties from another layout, but I can't do this with events"? I don't know.

Think of Objects as House Blueprints

Think of dragging objects to the Layout as making a House from that blueprint.

When the layout runs, it creates any Houses that are already in the layout. If you run a System Event: Create Object, it will create another House of that type.

When the game leaves that layout, objects get unloaded from memory, now all those objects are in oblivion - if there's data from those houses that you need saved, you need to save it to a global.

For example: playerHealth. If your game needs to remember a player's health between layouts (at runtime), best to have a global variable called playerHealth, these variables will NOT be unloaded between layouts, these stay intact throughout the game's uptime.

For one step further: If you want to have the game remember a player's health between exiting the game and your next play, then you need to save those variables to disk and load them on start. For this you would use the System Save Game function.

You need to have that object in your layout in order to get its properties, so either drag and drop it into your layout, get the info you need at start of layout then destroy it. If you need to be able to access this info during actual gameplay or if it changes then you will have to keep it in your layout, just hide it at something like X -5555, Y -5555.

If you are using an ObjectBank layout ( not necessary in my opinion ) you will have to load that layout first ( I think ) and get the info, save the info to a global variable probably,m then quickly unload that layout and proceed to game, or create the necessary objects in your current layout to get the info, .