MrDoomBringr's reply wasn't quite accurate. You can align props using this and axis (or any other constraint that moves the original prop), but it isn't good if you just want props next to each other, not joined. For your purposes, you may find [url=http://forums.facepunchstudios.com/showthread.php?t=493671]Easy Precision[/url] easier.
Very useful :D
Regarding the FPS drops, it seems the newest update of Gmod is much laggier with Lua drawing. Spawning a bunch of lua-rendered bouncy balls runs a LOT slower on the newest Gmod than it used to.
No more Chuck E. Cheese ball pits. :(
Yeah. FPS drops real bad sometimes :(
I would like to inform you that you have just won my personal BEST ADDON EVER award!
My escape pods fly STRAIGHT!!!!
Second only to spacebuild.
Actually, no, better, because SB is no fun if nothing flies straight.
Best Addon EVER :D :D :D
coming from a guy with negative smartness...Oh well, I agree that this is the best AIM ASSISTER ever, better than many aimbots, including JetBot, which doesn't work...At all.
Nice job dude, this helps me in everything I make.
When easy-welding two things together is there a way to have the rotation snap to angles using this this? (like shift-e with physgun)
Or is that not built in and I need a special easy-weld tool instead?
I accept if you don't want to implement this into SmartSnap but I think it would complete the ability to make perfect welds.
Check the tool mentioned 6 posts above yours.
[QUOTE=BradB]Nice job dude, this helps me in everything I make.
When easy-welding two things together is there a way to have the rotation snap to angles using this this? (like shift-e with physgun)
Or is that not built in and I need a special easy-weld tool instead?
I accept if you don't want to implement this into SmartSnap but I think it would complete the ability to make perfect welds.[/QUOTE]
What Vir hinted, SmartSnap is only intended for aiming, and features like angles, position is left for other addons to implement, basically because I would have to implement special features for every tool otherwise and it still probably wouldn't work very well (aka, it would be up to easy-weld to implement that, or some other addon which does).
Thank, i been looking for something useful as this for a long time ^_^
Perhaps in the next version, you could make grids for the life support items? It would greatly help in spacebuild. :D Thanks
Turn on the option to display on all entities, it'll show up.
There is a anoying error when you use the sodan cloaking device from the stargate pack :
[code]
Hook 'SmartsnapPaintHUD' Failed: autorun/client.lua:382: Tried to use a NULL entity![/code]
And i reported this on the stargate mantis but i heard it is a bug from smartnap.
[QUOTE=kevkev]There is a anoying error when you use the sodan cloaking device from the stargate pack :
[code]
Hook 'SmartsnapPaintHUD' Failed: autorun/client.lua:382: Tried to use a NULL entity![/code]
And i reported this on the stargate mantis but i heard it is a bug from smartnap.[/QUOTE]
Ah, thanks for reporting it.
Could you please try this "fixed" version of SmartSnap and see if it persists?
[url]http://home.syranide.com/download/smartsnaptest.rar[/url]
Thanks!
Testing..
[b]Edit:[/b]
It seems to be working, i can't recreate the error.
[QUOTE=kevkev]Testing..
[b]Edit:[/b]
It seems to be working, i can't recreate the error.[/QUOTE]
Great (it should be working).
Thanks!
I'll upload it as an official version "soon".
Cool. Really cool i seen this on someones video and i wondered what it was.
Time for some goodies!
SmartSnap is now up to version 1.0.0, and guess what?
It appears that I found a cure for FPS drops, still I'd like to point out that it is not directly caused by smartsnap, but an appearingly not so clever garbage collector in Lua. I'd like to have feedback on how this works out for you all.
2008-03-30, v1.0.0 (important update):
● FPS drops when the grid is showing have been fixed, it is not directly caused by SmartSnap, but the use of SmartSnap increases per frame memory consumption and the garbage collector obviously handles this very poorly. Please give me some feedback on how this works out for you all.
● "default model offset" has been removed to improve consistency for model addons, it now hardcoded to 0.25 which appears to the default for the source models.
● Bumped to version 1 because it is about time now!
2008-03-30, v0.9.5 (useful update):
● Grid offset only affects the outer border of the grid now and does not scale the entire grids, provides better snapping for "building blocks".
● Per model offsets are now provided for each separate model addon instead, update your model addons! (links above)
● Added "click grid" mode, disables the grid until USE is clicked while looking at a prop, looking away from a prop disables the grid again.
● Fixed a very rare bug that causes SmartSnap errors (thanks kevkev)
Awesome finally is the damn lag gone!
[QUOTE=Syranide]I'd like to have feedback on how this works out for you all.[/QUOTE]
Works as described, though the maximum fps is only very slightly lower with it on. Average fps over time is much higher thanks to this.
Also, thank you so much for not scaling the whole grid by the outer offset anymore; before I used to snap by using the corners only, now I can use anywhere as long as it's not corner to non-corner and still remain as accurate :D
Regarding the custom offsets that are to be included in model addons; I've not changed custom offsets before. Is it easy enough to specify the same offset for all models in a pack? Like copy+paste the config then change the name to a different model?
I've just tested with my tiled blocks, and it seems 0.228 is slightly better than the default 0.25, though I'll need to test a bit more to get a more accurate reading, I suspect the offset will be the same for every model I make.
[QUOTE=hunter_hunte]Works as described, though the maximum fps is only very slightly lower with it on. Average fps over time is much higher thanks to this.
Also, thank you so much for not scaling the whole grid by the outer offset anymore; before I used to snap by using the corners only, now I can use anywhere as long as it's not corner to non-corner and still remain as accurate :D
Regarding the custom offsets that are to be included in model addons; I've not changed custom offsets before. Is it easy enough to specify the same offset for all models in a pack? Like copy+paste the config then change the name to a different model?
I've just tested with my tiled blocks, and it seems 0.228 is slightly better than the default 0.25, though I'll need to test a bit more to get a more accurate reading, I suspect the offset will be the same for every model I make.[/QUOTE]
Ah glad to hear, I was having the same results, but you never know with certain setups. ;) Funning thing with the grid offset, it never occured to me how wrong it was until I noticed joeblooms note on his model pack about it.
Custom offsets are exactly the same as before, what you do is simply put a smartsnap_offsets_*.txt in your data folder for you addon, and smartsnap will read it. As you say, copy and paste works when doing multiple models, sadly no "wildcard" support though (and you can almost automate it with a little batch-hackery and notepad "dir /B /S *.mdl", just remember to flip all the backslashes to / and trim the path).
I did check your models and as far as I can see, the blue bounding box line up _perfectly_ on 0.25 so your model pack is fine as it is. Just so there isn't any confusion, the offsets refer to the blue bounding box being shown, and if it is correct, it should perfectly line up with every side of the prop.
[url]http://home.syranide.com/download/align.jpg[/url] (like it does for this tile of yours on default 0.25)
PS. yes, the offset should be the same for every model you make it seems, I don't even know why there is an offset in the first place. Default source props and phoenix however has some varying offsets for different types of props for some reason.
Epic, working great for me now!
[QUOTE=Syranide]as I can see, the blue bounding box line up _perfectly_ on 0.25[/QUOTE]
I tested by seeing how much my aim moves up or down when snapping at a shallow angle to the top of my models, the screen moves slightly with 0.25, but not noticeable with 0.228 unless zoomed in. Oddly the smartsnap grid and the bounding box move slightly when view doesn't when repeatedly snapping/unsnapping to a point.
Edit: Another indication appears to be the snap accuracy color when +use is released, it's red on 0.25 but yellow on 0.228. I'm now trying more variations to see if I can ever get it to stay green.
Edit2: 0.218625 is the closet I've come sofar, by indication of how far away from my feet I can remain green when unsnapping on a plate I'm standing on. With this value I can remain green until just over 10x phx distance away. (still goes yellow if I snap at a very shallow angle, but won't go red anymore on an 8x8)
Phx plastic appears to benefit from this value too, though the phx metal, glass, wood and window plates are perfect as they are.
I love you...
[QUOTE=hunter_hunte]I tested by seeing how much my aim moves up or down when snapping at a shallow angle to the top of my models, the screen moves slightly with 0.25, but not noticeable with 0.228 unless zoomed in. Oddly the smartsnap grid and the bounding box move slightly when view doesn't when repeatedly snapping/unsnapping to a point.
Edit: Another indication appears to be the snap accuracy color when +use is released, it's red on 0.25 but yellow on 0.228. I'm now trying more variations to see if I can ever get it to stay green.
Edit2: 0.218625 is the closet I've come sofar, by indication of how far away from my feet I can remain green when unsnapping on a plate I'm standing on. With this value I can remain green until just over 10x phx distance away. (still goes yellow if I snap at a very shallow angle, but won't go red anymore on an 8x8)
Phx plastic appears to benefit from this value too, though the phx metal, glass, wood and window plates are perfect as they are.[/QUOTE]
Ah ok, so this is how it works.
You have a model, a collision model and a bounding box.
The model is what you see, then you have a collision model which is what you see mostly just slightly larger than the model, and then you have the bounding box which describes a box that is large enough to contain the model, and is larger than the model (for some reason). (You probably already know most of that, but just making sure we're on the same side)
Since the only one of these that are directly exposed in GMOD is the bounding box, and the only "physically correct box", it is used to determine the side of the grid for each face of the object.
So at this point, there are two ways to offset the grid, either to offset the grids to fit what you see (the model), or fit what you can "shoot" (the collision model). So here I've chosen to map the grid to what you see, because that is probably what feels most natural, and what you intuitively expect, also because it means the model proportions remain accurate.
This means that there is a small difference between the placement of the grid and the actual placement of props, but SmartSnap traces the snaps to the collision model and this is why the aim jumps when you snap (and the same reason why SmartSnap works on non-square models as well.
And for completeness, the color of the cursor is indicates the difference between the snap point and the aim "hit position", meaning, how much the aim differs from the optimal position (yellow means "less than 0.001", which is very accurate too), this difference might increase due to a few different "problems". One is that there is another prop in the way, you are too far away and/or the angle is too great and the calculations become less precise. So it isn't directly affected by the grid itself, because the snap points are calculated by tracing the actual collision model (a uniform offset does not affect the center snap points at all).
So while 0.218 might be the accurate offsets for your collision model, it would slightly scale the grid out of proportion (although only by very little) and also makes the grid appear outside of the shown model. Both ways are fine, but I've chosen to offset the grid to the shown model because it in my opinion "performs" better in most cases than offsetting it to the collision model.
Sorry for boring you :v:, just ask if anything remains unclear!
Great work with the tiled models by the way!
[b]Edit:[/b]
I'm considering the idea of being able to specify a few additional options on a per model basis:
* "power of <x>", what I mean by that is that (mostly block) models can specify how grid division will occur, right now the grid will create as many snap points as fits within the user criterias. However, using for instance power of 2 (2^x), would mean that for the regular blocks, for instace the cuboid tiled building blocks, the grid lines would exactly match the lines in the block at all times, and never split tiles unevenly etc.
* "fake dimensions", most of the block models follow the "PHX sizes", but often vary just enough to make the snap points unevenly distributed for non-square blocks and appears to require the user to enter odd decimal values such as "11.52" for the grid to show up as intended. Often the sizes are 95.1 instead of 96, 1.05 instead of 1 etc, what this would allow is for models to fake these dimensions to be 96 and 1 instead, making it simpler for the end user.
Any ideas or comments on this? Would it be worthwhile and would you model developers find it "meaningful"?
[QUOTE=Syranide]Sorry for boring you , just ask if anything remains unclear![/QUOTE]
Not at all; it was very informative. Now for me to risk boring you with another lengthy reply. :D
[QUOTE=Syranide]
yellow means "less than 0.001", which is very accurate too
[/QUOTE]
I've always been making sure it's green anyway, I'm a bit compulsive when it comes to accuracy as you've probably guessed :)
[QUOTE=Syranide]
I've chosen to offset the grid to the shown model
[/QUOTE]
Ah, OK. I didn't realise the grid was above the shown model when I was testing, as i was doing one side at a time and the other sides reverted to 0 so were floating anyway.
I also see now how it can change the grid spacing frequency undesirably.
Just checked and the phx glass/metal/wood/window tiles bounding boxes are slightly above. I was just assuming their accuracy was the standard.
I'll leave my offsets as default, as I make sure my collision models are the same size (though lower detail on the curves) as the visual models in the editor, and let the game add the random offset for consistency with other models.
[QUOTE=Syranide]
I'm considering the idea of being able to specify a few additional options on a per model basis:
* "power of <x>"
* "fake dimensions"
Any ideas or comments on this? Would it be worthwhile and would you model developers find it "meaningful"?[/QUOTE]
I like the specific grid distance idea; currently I have to set minimum offset to just below the actual texture spacing of 11.8625 (quarter of phx 1x1 which is 47.45) as exactly on confuses it into sometimes drawing too few. 11.86 appears to work for all sizes of plates, though 11.862 would make sure of it.
Currently, I also set the maximum grid points as high as I can (64 for an 8x8) to avoid the sizes changing between types of plates.
This also fails currently if the object has an odd number of segments, due to it starting with a center line.
I would like to see the center line kept for all models, but be able to show in addition to custom 'power of <x>' offset.
I also suggest some sort of 'override' so that the user can specify exact units, or use the current method, and have it override the individual model grid spacing presets while enabled.
For the "fake dimensions", I'm unsure if I like the idea or not. It would indeed make it easier for users to use the dimensions (I've long wished PHX was exactly 50 or even 48)
However, it might be even more confusing for any that use tools that use exact measurements (Stacker, Easy Precision).
Also: the previous 'power of <x>' suggestion should improve usage for users.
Would there be many instances they would need odd decimals if all custom models had their own accurate grids?
[QUOTE=hunter_hunte]Not at all; it was very informative. Now for me to risk boring you with another lengthy reply. :D
I've always been making sure it's green anyway, I'm a bit compulsive when it comes to accuracy as you've probably guessed :)[/QUOTE]
Me too ;)
[QUOTE=hunter_hunte]Ah, OK. I didn't realise the grid was above the shown model when I was testing, as i was doing one side at a time and the other sides reverted to 0 so were floating anyway.
I also see now how it can change the grid spacing frequency undesirably.
Just checked and the phx glass/metal/wood/window tiles bounding boxes are slightly above. I was just assuming their accuracy was the standard.
I'll leave my offsets as default, as I make sure my collision models are the same size (though lower detail on the curves) as the visual models in the editor, and let the game add the random offset for consistency with other models.[/QUOTE]
Ah, they weren't is the answer, but as of the new offsets system, they have yet to be bundled with PHX2 (due to its massive size), so if you tested using 1.0.0, they will be incorrectly outset by 0.03 (the offsets should be 0.28 for the plates). Also, did you notice the snap_dev_alloffset-command? It offsets all sides by the same amount, which simplifies the job for almost every model.
[QUOTE=hunter_hunte]I like the specific grid distance idea; currently I have to set minimum offset to just below the actual texture spacing of 11.8625 (quarter of phx 1x1 which is 47.45) as exactly on confuses it into sometimes drawing too few. 11.86 appears to work for all sizes of plates, though 11.862 would make sure of it.
Currently, I also set the maximum grid points as high as I can (64 for an 8x8) to avoid the sizes changing between types of plates.
This also fails currently if the object has an odd number of segments, due to it starting with a center line.
I would like to see the center line kept for all models, but be able to show in addition to custom 'power of <x>' offset.[/quote]
Hmm, yeah, I totally forgot about the center-line being offset if the power would be 3 :v:
Valid point indeed, and yes I would definitely keep the centerline regardless.
[QUOTE=hunter_hunte]I also suggest some sort of 'override' so that the user can specify exact units, or use the current method, and have it override the individual model grid spacing presets while enabled.[/quote]
Hmm, that's true, that might still be desireable.
[QUOTE=hunter_hunte]
For the "fake dimensions", I'm unsure if I like the idea or not. It would indeed make it easier for users to use the dimensions (I've long wished PHX was exactly 50 or even 48)
However, it might be even more confusing for any that use tools that use exact measurements (Stacker, Easy Precision).
Also: the previous 'power of <x>' suggestion should improve usage for users.
Would there be many instances they would need odd decimals if all custom models had their own accurate grids?[/QUOTE]
Ah, you might've misunderstood me there, the "fake dimensions" would only affect the "grid division" (snapping, grid size etc would still be exactly the same), so that plates that are 3x4 can be classified as proper 96x128 when calculating how many lines there should be, instead of working with the 95.1x129.3 kind of sizes, this would make sure that a "minimum distance" of "12" works for all model packs for instance, also making it easier to e.g. get double the grid resolution by simply typing "6" instead of "5.whatever", for all of these blocks.
What do you mean by "Would there be many instances they would need odd decimals if all custom models had their own accurate grids"?
So definitely the "power of x" would work, but could this perhaps be a better option? Having an override button (which probably is necessary), could cause it to become permanently checked for most people, and I think that this solution could might work better overall, because with the correct minimum distance set, the grid should automatically divide itself correctly if people use twice the grid resolution so that each tile gets split, which doesn't sound unreasonable to me that people would find "more convenient" (I personally like this because it allows me to place stuff near corners without placing them in the very corner). This would work across "all" models without any additional changes too.
By the way, I did some testing and I found that actually just rounding off "proplength / cellsize" (number of lines per axis) instead of flooring the result, allowed "sensible" values such as 6 and 12 to work perfectly across all my model packs, and the source models as well. Perhaps it would be wiser to just go for that instead?
Thanks!
Thanks Dude Now my House can look even!
I vote for this to be the most useful building addon ever (closely followed by easy constraint).
Syranide = God
Can someone plz tell me what are good settings for smartsnap for the PHX 2 model pack PLZ!
Sorry, you need to Log In to post a reply to this thread.
