[CRITICISM] "Snap Point Disaster" / STUDIO WILDCARD please read

Hey there!

The following text may seems a bit raging, but please don’t get me wrong, in the first place I’m thankful for this game and the effort brought by Studio Wildcard and the people in this forum. This is what I am feeling about modding in ARK and I may be wrong in some points, but it could be that I’m not alone.

Let’s rage a bit:
Snap Points are a mess! Especially if you want to do something a little bit more complex…
For example: In my current project I try to add some new structures to the game. One of those structures is a new sloped roof.
This sloped roof shall have additional snap points so it can be snaped to the bottom and the top of walls, so that you can build the roof right away from the wall, without placing a sloped wall aside. And it shall snap to its own kind of roof at the top and the bottom, so you can build higher roofs without sloped wall support.

  1. point of my criticism: It is as good as impossible, or just achievable with a huge amount of time to get behind the snap mechanics. It took hours to get a selfmade roof model working like a vanilla roof.
    Why I didn’t just copy all snap point relevant parameters from the existing roof?
    Because I want to add the new snap points from above.
    Where is the problem now?
    The problem ist that the vanilla roof has some special-I-don’t-where-the-hell-those-parameters-came-from Location attributes.
    Let’s have a look at WoodRoof_SM:
    In the Transform->MyStaticMesh->Location is X:25 Y:-10 Z:-100
    and Rotation X:0 Y:1 Z:-90
    So this 3D object is off-set by those parameters. As far as I can see, do the snap point Loc and Rot settings just off-set the pivot of an object.
    Summaryzed there is the “permanent” MyStaticMesh off-set and then the “variable” off-set(if there is more than one snap point) defined by a snap point.
    These pictures may help:

2. permanent X:25 Y:-10 Z:-100 Rot:-90

3. variable X:172.5 (could also be X: -125)

I know that the snap point offset doesn’t move the pivot, but this picture shows where the “anchor” is. No matter what the point is for, in pic 3 you see where this object snaps “from” or “to”.
By the way, for me it’s unable to see why the roof is off-set by those values, but ok, it seems to work in the game…
If you want to set up some additional snap points for this structure, you not only have to include those permanent transformations, but also the permanent and variable transformations from the object/structure(e.g. sloped wall) you want to snap “to” or “from”.
So at the end you got 2 objects with at least 4 transformation in 3 dimension + rotations… to calculate the right values for the snap points is just mind-boggling. Not only because of this amount of transformations, but also because some transformations are in local and some in global space(seems to me so).

To make this a little bit more easy, I’ve set all the permanent offsets of my selfmade roof to 0, except of the rotation by -90 degree. So this is -1 transformation todo I thought. Wrong!
It is such a hard task to configure new snap points, so that they will fit with everything else. Change settings, start testmap, see result, change settings, start testmap, see result, … for hours. (workflow hints?)

And then if you finally get a structure to snap where you want it to, it snaps to 1 million other points as well like crazy, because you don’t EXCACTLY know how the Snap Point Match Groups, Snap Flags etc. are set-up in the engine (I know the reference by Woden87. Thank you for this by the way :slight_smile: ) But this isn’t enough to get things work.

To come to an end with this(I also could go on for a while): most of the time I’m just trying random suggestions from my brain, because the things are not obvious enough to understand how this system works. That’s depressing. I want to produce mods without bugs like in-the-air-floating-roofs, so that players could use it as some kind of exploit, or it would simply destroy any kind of immersion.
There are no tutorials on this topic(or they are very well hidden) and finding all the things out is just wasting a ton of time, because all the knowledge is there, it’s just not shared.
Studio Wildcard, please show us how specific things work in ARK!
I am really enthusiastic with my project and I also want to participate in the international modding contest, but I can’t spend this amount of time in blackholes like snap points. I am a 3D modeler(hobbyist since six years) and I want to produce some beautyful structures for the game, but without professional support it will not happen(it’s just a time and motivation thing).

The Contest is a motivation, the creativity and patience is there, but the undescribed technical side is just demotivating. And here is something I don’t realy get: (this is propably point 2. of my criticism…?)
Why do you(Studio Wildcard) put out a modding contest, without having a whole bunch of (official)-tutorials(nothing against unofficial, but those who make it know the best workflow and all the details) to support new and old modders with the necessary knowledge, to let them spread out in many different directions? (As far as I can see, are the best looking mods on the “total conversion” and “map” side of the contest.)

Thank you for your time! Best regards.

think most of us all dealt with this issue i just worked around it and make sure u adjust the meshes to fix or just create ur own snap points like most of us do

Like Spezz said, I’m not sure why people bother with the existing snap system for completely custom items as I’ve made my own and them seem to work well. However I understand that your system is meant to work with vanilla structures, are you looking for assistance with anything or simply writing a review?

Don’t we all love snap points :slight_smile: You’re best bet would to be to create your own snap points. I do understand that you are trying ton add functionality to the existing snap points but in all honesty there isn’t a lot of documentation on it. Sure we could have someone invest time in putting that together but it would be a dev. Sadly, I don,t think that is a priority right now given what everyone is working on and considering there are ways to work around it.

Believe me though, I realize there is a need to understand snap points better. You have been heard :slight_smile:

Ok, thank you :slight_smile:

It’s a little bit of both. But if you can give some assistance I would be very thankful.
To break it down I would say that I need to seperate some of the snap points, so they don’t interact with each other.
The plan:
I got a sloped roof with snap type flag 88, like the vanilla one. It shall snap to the same kind of roofs side to side.
So, thats a snap point(SP from now) for Left and for Right.
It also shall snap to sloped walls like the vanilla roofs. Thats also for SPLeft and SPRight.
SPLeft and SPRight got “match group” = 6 and “to point flag” = 12, like the vanilla roof. This is working perfectly well.

Ok, next 2 SPs are for snaping the bottom of a roof to the top of another and vice versa. So, thats SPBottomToTop and SPTopToBottom. I don’t know what match group should work here… It shouldn’t interact with SPRight and SPLeft.?

And then, there are 2 SPs for snaping the roofs bottom to the top of a wall and the roofs top to the top of a wall. So thats SPBottomToWall and SPTopToWall. Those 2 SPs need match group 14, beacuse it should work like Wall to Wall? They also, shouldn’t interact with the others above.

My current configuration is:
SPLeft, SPRight: Match Group = 6; To Point Snap Type Flag = 12; Attach to + Attach from = checked
SPBottomToWall, SPTopToWall: Match Group = 14; To Point Snap Type Flag = 0; Exclude Flag = 88; Attach from = checked
SPBottomToTop, SPTopToBottom: Match Group = 6; To Point Snap Type Flag = 88; Attach to + Attach from = checked

With this configuration, I got some ugly interactions between the SPs. e.g. the is floating in the air above another roof, but it also got all snap positions that I want too.
How do I exclude the rest?