Repository navigation
Maybe divide into separate mods (or add functionality toggles in a config)? #33
Description
I love this mod for terrain modifications and world grid placement (looking forward to some pickaxe functionality and slope smoothing).
I currently prefer other mods for build-mode snapping, as I feel they provide cleaner control (and include updated control-scheme tips in the build HUD). I also find that Shift doesn't prevent snapping when I'm using this mod, which drives me nuts when I do need custom placement. And don't get me started on precision mode being bound to the same key as flying if using devcommands.
As a result, for more elaborate builds, I find myself closing and reopening the game to switch between mods for different stages of construction, using this one for the terrain and foundation and Extra Snap Points Made Easy for the actual building and decorating. And then maybe this again for certain things, like stacking the stacks.
I don't care for the added build pieces, as I prefer to only use vanilla prefabs, even if they're those that are usually inaccessible to players and unlocked with something like More Vanilla Build Prefabs. I at least know they'll still be in the world if I'm no longer using a mod. Ironically, my OCD gets twitchy when I see non-vanilla build pieces in the hammer menu.
Because of all this, I'd love to see this mod split into multiple smaller mods. Either that, or the ability to toggle functionality via config. It wouldn't solve everything, but it might mean being able to pick and choose a bit more.
Overall, what this mod aims to do is great. I don't think I could stand to go back to the vanilla hoe functionality. And I do use and appreciate a lot of the build mode functionality, when I don't need the cleaner control of something else. Thanks much for all the work that went into this.
Activity
java-devil commentedon Jul 11, 2026
There's a lot to unpack here ;)
I know this actually seems like an inconsequential comment from your perspective, but from my perspective it's actually the core piece of feedback ;) You may not know this, but most snapping mods... are actually based on OCDheim code :D
So. If you could please elaborate extensively: in what way do you feel other mods are more satisfying / feature complete in the snapping department (other than the key hints)?
I don't know where to go with this. Should I simply remove the feature. Recommend other mods. Try to reach feature parity. Or keep developing OCDheim as its own flavor. But to be able to decide I need to first understand how the landscape looks, what are the remaining painpoints, what are the available superior solutions, and in which specific regards are they superior.
...it so happens that you can actually personally help on this front ;)
This should have been fixed in today's bugfix release (
v0.2.3). Would be much obliged if you could confirm :)Alle of those will be addressed in the next feature release (
v0.3.0) precisely the way you would expect - by a config file which allows you to override keybindings and disable mod sub-modules at will :)Cheers,
Adam
gizmorphium commentedon Jul 12, 2026
Hi there.
Can confirm; so far, Shift appears to function as expected, preventing snapping. However, in precision mode, it appears to be connected to the following:
[Info :OCDheim.Logger] [ENABLED] PRECISION MODE
[Error : Unity Log] InvalidOperationException: Collection was modified; enumeration operation may not execute.
Stack trace:
System.Collections.Generic.List
1+Enumerator[T].MoveNextRare () (at <73ac12a12f9a4ebca156b41ddce95fbe>:0) System.Collections.Generic.List1+Enumerator[T].MoveNext () (at <73ac12a12f9a4ebca156b41ddce95fbe>:0)OCDheim.SnapTree.FindNearestSnapNodeTo (System.Collections.Generic.List
1[T] buildPieceSnapNodes, System.Collections.Generic.List1[T] neighborPieces, System.Func2[T,TResult] isDesired) (at <1b851c3a36cb4efca679c38f51d3982b>:0) OCDheim.SnapTree.FindNearestSuperiorPrecisionSnapNodeCombinationOf (Piece buildPiece, System.Collections.Generic.List1[T] neighbourPieces) (at <1b851c3a36cb4efca679c38f51d3982b>:0)OCDheim.PrecisePieceSnapper.SnapInternally (Piece buildPiece, System.Collections.Generic.List`1[T] neighbourPieces) (at <1b851c3a36cb4efca679c38f51d3982b>:0)
OCDheim.PrecisePieceSnapper.SnapToNeighbourPiece (Piece buildPiece) (at <1b851c3a36cb4efca679c38f51d3982b>:0)
OCDheim.PrecisePieceSnapper.SnapBuildPiece () (at <1b851c3a36cb4efca679c38f51d3982b>:0)
(wrapper dynamic-method) Player.DMDPlayer::UpdatePlacementGhost(Player,bool)
Player.LateUpdate () (at :0)
Obviously, my pain points will be different than the pain points that others experience. First, I prefer being able to double-place on a snap point. For instance, I like being able to place two sloped walls in the same place so that the cross beams form an X; Other mods allow this.
For me, I don't bother using both Q and E for cycling snap points on the current part; I only use one and just go around the bend again if I happen to miss my stop. Because of this, it makes sense to me to have one work for the target and one for the current. That said, precision mode would be hilariously tedious if cycling through a target with dozens of points, especially if one cannot backtrack and has to, as I said, go around the bend again. An argument could be made that precision mode simply shouldn't have target cycling at all.
That said, maybe the user would sometimes be willing to cycle through them anyway for the perfect placement. There are times I would, like when a complex build has me unable to get a direct line on the needed target point, but more often I'd probably only need points available without precision mode if I'm cycling both target and current. What I find clean about some of the other solutions is that they allow these options, but separate them in some way using modes. Toggle target line-of-sight snapping versus target point cycling. Use Q and E on their own to cycle back and forward on current, but a modifier key and Q or E to cycle the target. And what definitely helps keep this sort of thing clean is that the key hints indicate how to change modes, and when modes are changed, the key hints update.
One thing to consider is that if cycling the target in precision mode, the user might want the same target point on the next target of that type. I say this because many of my own builds are repetitive, geometric designs. I could see having a short-term memory of the last target snap point used for placement, so that the next time the user points at that type of piece, the same point is selected on the target. This could be for a single build piece type for only the last actual placement, or for a small handful of recent target types.
Overall, I wouldn't want to see the feature removed. I'd either want to be able to disable just that feature, and for that option to prevent this mod from interfering with using another mod to fill that particular role, or I'd want to see it continue to grow into its own flavor (the next step being those changes that are already soon to come). Preferably both. I say this because no mod can be all things to all people. We'll all have preferences, so the ability to customize an experience by picking and choosing individually makes more sense to me.
That's basically where my thoughts are, anyway.
java-devil commentedon Jul 13, 2026
I'll look into this first. Are there any noticeable in-game consequence or does it simply end up spamming the logs?
gizmorphium commentedon Jul 21, 2026
Seems to just be spamming the log. Snap doesn't happen in Precision mode while Shift is held, as expected, but whether that's because it's properly recognizing that Shift is held, or because it's erroring out, is unclear. Otherwise, everything still seems to be fine. I haven't done extensive testing.
java-devil commentedon Sep 21, 2026
@gizmorphium the main concern from this ticket has been implemented in v0.3.0. I haven't yet properly looked into the rest so I will keep this issue open.
Feel free to report any bugs you may find while playing around (if you still are interested in using the mod), since I didn't sufficiently play-test this release in order to rush it out the door for obvious reasons.
Cheers,
Adam
searica commentedon Sep 23, 2026
Author of Extra Snap Points Made Easy chiming in here. First off, OCDHeim was one of two mods that made me love building in Valheim, the other was the original Snap Points Made Easy mod.
Amusingly, Extra Snap Points Made Easy is actually based on Snap Points Made Easy rather than OCDHeim and takes a different approach to adding snap points so that they are always active but can be disabled via the configuration settings on either a piece by piece basis or for whole categories of pieces. However, my mod Advanced Terrain Modifiers is very much based on OCDHeim. I loved the precision raise tool back when I first found your mod but I couldn't use it due to version of OCDHeim at that time being required on the server. Similarly to gizmorphium, I also did not want to use non-vanilla pieces in case I had to stop using the mod. So I created Advanced Terrain Modifiers as a way to merge features from other terrain mods with OCDHeim and fix some of the issues with custom terrain modifications in multiplayer.
Looks like the updates since I last used OCDHeim have made lots of improvements and some new features though, which is very cool and I'll have to check them out. Also, the repo for Extra Snaps is public and under the GPL v3 license, so if you switched your license to a compatible one then you're more than welcome to integrate features from Extra Snaps.
Regardless, just saw that you were active and wanted to share the impact you had for myself. Trying to implement the precision hoe tool was my first time dealing with any graphics elements in unity so having your code as an example is what made it possible. Many thanks for paving the way (pun intended).