I sent you an email but I add it here as well since I believe the bug I reported in email is the same one I was talking about on the previous page. It seems that when you try to snap things but they are inside a large collision volume, the snapping does not work. My setup is such that I have room BPs wich contain arrow meshes with sockets so that I can place the arrows exactly where I want the snap point. This works well but once I place collision volumes around the rooms the snapping stops working.
For now I moved the volumes int a separate level that is loaded during gameplay only but it should be fixed
Hi Wallenstein,
Yes, there is a problem with that if you have âsnap open onlyâ enabled. The plugin considers that the socket is closed because itâs overlapped by the volume. It feels weird because the volume is invisible, but the plugin only sees collisions, so there is no difference. The runtime version (mssr) uses different logic, so there is no such problem. I did not figured yet how to fix it properly, i need to look into it. Your workaround is pretty clever, I didnât think of that.
I probably should add a specific option to exclude collision volumes so that will fix the problem.
The reason why I didnât want to simply remove collision volumes from consideration is that there are legitimate uses for them. Imagine for example you have a huge spline road made of many spline meshes. Enabling collision on those will make the editing very slow, so what I did instead is to add little collision primitives around the sockets and the plugin manages to find the spline from there.
OK, maybe you should add tags to volumes to be used or whatnot. One easy way to avoid confusion is to put a bold remark in the popup help for the âOpen Socket Onlyâ checkbox that explains this problem in more detail. I didnât think of unchecking that because itâs checked by default and I thought thereâs a reason for that. That way people would immediately see a workaround. It was frustrating because the same socket would snap to some sockets but not to others and I didnât know what is the reason.
Right now I am making another snapping object where the socket is inside a wall and caused the same problems. So this option there is definitely something that should be made clear, how it works and why, and perhaps you can find a way around this
I have another idea for an update: I build up BPs from several meshes to drop in the scene, for instance a room made up of several walls etc. I have a special mesh that is an arrow with a socket that is supposed to mark the exits for the room to snap to other rooms. This works most of the time but sometimes the system snaps other sockets from meshes in the BPs together which I donât want. it would be good if there was a way to disable sockets in a BP by name or at least have an edit field in the options where you can enter the prefix of the only sockets you want to snape
Hi Wallenstein,
I would like to better understand your issue. Can you show me an example of your setup, when it works and when it doesnât? With socket names etc.
- Make a mesh A and a Mesh B with a snap point each
- Create a Blueprint X. Add Mesh A and Mesh be . Make it so that A extends on one side. Bascially the purpose of this BP is to make the A meshes snap to each other. However the B meshes are part of the visual as well and at some point we might want to place B in a scene alone and therefore we need it also to have a snap point
- Create a BP Y with the same setup but this time scale mesh B to 0.5
- Now place Y in a level
- Then place X and make it snap. Depending on where you release the mouse it might snap correctly the way we want A to A, but it might also snap to Bi Y at which point not only the position is wrong but the second BP will be scaled to 0.5 in itâs entirety.
Again we need snap points in all meshes because we might want to place the meshes in the level by themselves so having B without a snap point is not an option
âââââââ
Thank you, I see the problem. I will think about.
For the scale, could you just disable scale snap in parameters?
@Wallenstein I think maybe component tags can be used to solve this problem. There could be some tag, like âno_snapâ for example, which will disable the snap for the component. The plugin could check those tags and, if the tag is here, ignore the component and all its sockets.
So in your case, your BPs X and Y will have static mesh component B with the component tag âno_snapâ, therefore the plugin will ignore it. But if you use B alone, like a static mesh actor, or inside another BP, without tags, then it will snap.
Would that work for you? At first sight that should be easy to implement I think.
@Wallenstein
I made a prototype, take a look:
It works with component tags, so you can choose which component is snappable and which is not. You can even add/remove those dynamically, like in construction script. What do you think.
I would like also to solve the other problem with collisions in some cool way but I donât know yet how. If you have some idea let me know.
@Wallenstein
I looked into the blocking volumes etc. problem a little bit more, and I think it can be solved same way as in the MSSR. Namely, the âcheck open onlyâ option will only consider components which are in the âtarget componentâ list in the plugin settings. So, if you only have âstatic mesh componentâ in this list, it means only a static mesh can block a socket from snapping. Therefore, the plugin will ignore stuff like blocking volumes and such.
And if you need some kind of collision component to act as a socket blocker, then you just add it to the âtarget componentsâ list. In the video below I use a sphere collision component placed around spline endpoints.
Maybe you should add a written documentation. Videos are great but they always cost time to watch and when you are looking for one specific tip how to do things you canât scroll through them because you donât know what youâre scrolling over and have to watch them all again.
I will write a documentation about this. Those videos are just to show an example how it will work.
Anyway, I submitted an update and it seems itâs already published so you can test it.
For the ânosnapâ feature, you just need to edit your blueprints X and Y and add a component tag ânosnapâ to B.
The problem with blocking volumes should go away too.
Let me know if it works.
I realized that the documentation was pretty outdated, so I rewrote it, now we should be up to date. Check here: Modular Snap System Documentation â Inu Games (also linked in the top post)
Thanks, thatâs helpful. Reading is simply faster than watching a whole video.
Submitted new version 1.4.5 with a new feature: socket bulk export/import tool. Should be published soon. Is published.
The tool can be used to export/import sockets for many meshes at once. For example, if you made sockets for some third party asset pack you can share them with other people without sharing the meshes. Also useful for backup. The export file is a simple text file with pretty straightforward format, see below. This way the socket definition can be easily shared, even simply pasted into a web page or a forum.
Anyway, if you feel like sharing, you can export some and post them here 
There is a video of importing sockets for a whole asset pack :
The free pack from the video can be found here here and you find the socket file attached below.
Documentationis updated too:
The export/import tool allows to export and import socket definitions from multiple Static Meshes to a text file. To use the tool select some Static Meshes in the Content Browser, then right click and choose âSnap Systemâ sub-menu in the Asset Actions section. You can select meshes from many folders by using Content Browser filters.
**Export **option will write sockets from the selected assets to a text file. **Import **will read the text file then add or modify sockets in the selected assets which match the entries of the file. **Delete **will remove all sockets from selected assets.
The export file is a simple text file that can be edited with a text editor or pasted in a web page. The file is composed of asset names followed by one or more socket definitions. Example:
StaticMesh /Game/Meshes/SomeMesh
S SomeSocket 0.0,-25.0,0.0|0.0,-90.0,0.0|1.0,1.0,1.0
S OtherSocket 0.0,25.0,0.0|0.0, 90.0,0.0|1.0,1.0,1.0
The import tool can manage the case when the assets were moved to another folder. In this case it will try to find an asset with the same name and the most similar path, then ask the user for confirmation.
Hey Iâm willing to share my settings here, Thereâs one thing you might want to consider though. I changed the pivot in some meshes to be more in the meshâes center when they were off. I know it must be relatively simple to do that somehow. I used the pivot tool from the marketplace to do that. Maybe you can build in a function to read out the pivot and also set it automatically from these files.
Here is my first socket pack. It is for this pack: https://unrealengine.com/marketplaceâŚctorian-street
I have altered the pivot point of the street tunnels so you may have to redo the sockets for those models yourself but itâs only 3 meshes.
Many wall meshes come without collision so donât forget to set up collision or snapping wonât work
Hereâs another socket pack for Luoâs caves (https://unrealengine.com/marketplace/en-US/product/luos-s-modular-rocks-caves) but I only added sockets for the caves not the decorative stones etc which are mostly placed free-handed anyway, but with this you can edit a huge cave system in no time
2 Likes
@Wallenstein Thatâs awesome, thank you!
I wish I could test it, but I donât have any of those packs. I tried with luos caves free demo, but the meshes are not the same it seems.
For the pivot, I will try to understand how it works. I suppose the sockets will not transfer correctly from a mesh with changed pivot to the original mesh? Can you test it?
I have the impression that UE doesnât store a pivot and the plugin modifies the mesh itself by moving the vertices and the sockets.
Btw, there is no need to zip the files, they are already small and the forum accepts txt files too.
I tested it, the altered pivot point makes a difference and the sockets have an offset. There arenât many cases where one changes the pivot, so itâs up to you, I suppose it must be easy when you work in C++ somehow. but I wouldnât spend a lot of time on it