Hello Ev!
How can I make 2 or more instanced static meshes generated from the same static mesh independent of each other? I’m trying to modify their transforms separately but at the moment, each new transform is applied simultaneously to all the isms of the same type. Can anyone help me? Thanks everyone!
Hey @Cykablatta
You can modify each instance in the ISM component.
Follow this steps.
1 - Add a new instance in your ISM Component.
2 - You can grab your new static mesh instance and move it freely or you can modify the transform
Let me know if that works for you 
2 Likes
@JonathanBengoa thank you for the answer! The problem is that I am trying to spawn the same instanced multiple times, but each one receives different transforms at runtime. Because in my case the instanced represent interior meshes that must be allocated in predetermined rooms of my game world. So I am confused, because every time an ism is spawned, then all the previously spawned ones get the same current transform in unison, and they all overlap in one room, instead of each populating its own. And it’s strange because each one is registered under a unique key in a dictionary, which contains the room to which they must attach, the world rotation z, the relative location and the name of the socket for the attach.
Can you show me how are you instancing the ISM in runtime?
Are you using a different actor? Are you modifying one actor in particular?
Looks like a problem with targets.
1 Like
Actually I tried different approaches. Because initially the spawn worked but it was not automated with the current variables, so before I had the bp manager that collected the spawned rooms in the dictionary and in event dispatcher it transmitted them to the interior spawner, so before I had that for each room, branch on the tag, for each possible tag I did a manual spawn, with spawn actor from class (bp interior) and in the pin output “return target” I did get directly on the ism already inside the bp but not in scene, then from spawn actor from class I did add instance and attach component to component.
I see remember the positions of the transform are in local context.
Be sure you are adding the local transform when you create new instances. If not is going to be just an offset from your actor.
1 Like
Then I decided to rewrite the code and add more dictionaries so that if in the future I add more rooms and interiors, everything is already tested. Now the code, from the manager, takes all the isms present in the bp interior, and after having grouped them, chooses for each room and by tag/socket name correspondence, a random ism among the compatible ones and then inserts everything into another dictionary. Then at spawn time, I do for each loop on the dictionary, and for each room, I take the transforms I need, I take the current ism variable and use it in spawn actor/add instance/attach component to component with the current socket name.
I tried to be as brief as possible, forgive me. Now I’ll send you a screen, but I have to put things in order because over time I have altered the code. @JonathanBengoa
I tried to quickly reconstruct the code as it was. I shouldn’t have left anything out.
Ok! Please check this, your are spawning the instance in the 0.0.0 of the actor.
To take full advatange of the ISM you need to have only one component with all the instanced inside of them. (If you have really big map, is useful to split it some ISM Actors)
Other thing I am seeing is your are using the relative transform of another component to spawn? What is SMC Corrent?
If you get the relative transform you are getting the local transform you should a GetWorldTransform() if you want a world location.
1 Like
@JonathanBengoa SMC stands for Static Mesh Component (the current room).
I tried different combinations, initially I only used world transforms, then I had problems and I tried different settings, so it seemed to work, or rather, if I stop using the current variables on the nodes that concern the ism it works, the problem is that then I don’t have the automated spawn system.
Also because snap automatically fixed the fact that they spawned on 0,0,0, happens later. I repeat the problem arose when I decided to automate to avoid lengthening the code with too many branches and other manual commands. I’m very confused. 
@JonathanBengoa
No worries give me sometime I will write you a quick blueprint where you can do something similar you are trying to do now.
2 Likes
@JonathanBengoa In the meantime I also share a screenshot of the old code that worked
The differences are that, instead of iterating directly on the keys of the dictionary with for each loop, in another event I extracted the dictio in an array container. Then in this event I used the index of the copy, to process each element individually, I inserted branches to check which static mesh corresponded to the current ism, and based on this, from the pin output of spawn actor, I directly dragged the get on that specific ism, contained in the same bp. The rest is unchanged.
First Approach is doing this in editor time manually.
You create a Room with a static mesh component and ISM component
Then you add the instances. Selecting the ISM Component and Adding items in the instances array.
I like this solution because you can see the meshes in editor timer and you can change it.
The other approach is iterating sockets from a static mesh.
Check I get the transform in world related location and I pass it directly to the ISM Component.
Related to previous post:
I saw the previous version is working.
Even if you use that like that you will having the same problem. You are using ISM to avoid extra callouts right? You need to add many instances as possible in the same ISM Component.
The differences I see is here with the attach component to component.
I think you are setting other target.
Let me know if you want to go further in any example.
2 Likes
@JonathanBengoa Yes I’m using ism to keep the project light in terms of performance.
The problem is that the room smcs are handled differently, and adapting my project to your example could be a big problem for me. Because I would be forced to change blueprints and all the code I have already written to iterate on them.
Basically I would like to get the same result that I had initially, which is perfect, it is exactly as it should because each interior snaps to its specific room in a perfectly aligned way, but avoiding having to use branch and boolean for each case. The only thing that creates the problem and I still can’t understand why, is how the output pin of the spawn actor from class node is managed. That is, if I drag manually from that pin and do “get” (name of the ism), it works, but if I do “get” (current ism variable), it doesn’t work anymore because then the previous spawn doesn’t keep its transform and follows the next spawn and so on until the rooms of that type are exhausted.
Also because I can’t know in advance, before the game starts, how many isms I’ll need, per type of interior and type of room. The rooms that spawn, basically increase as the “record” increases. I thought of doing it like this. @JonathanBengoa
