I need to snap plants to exact points quite often, the current example being trees at the centre of gardens in irregular locations.
I have also noticed that plant labelling works the same way - defaulting to osnaps/tracking off. F3 does not turn on osnaps for labelling, and using the button still does not allow snapping.

I am finding that I have to create snap points for plants and also realign my labels after placing them. It would be much easier if osnaps, osnap tracking and polar tracking were the same as if placing blocks and leaders.

Most users would prefer to set osnaps/tracking as required when planting and labelling as they do with any other drafting task.

It would be great to have full osnap/tracking functionality and for the setting to remain as the user defined it prior to using the tool. As you say, turning off is as simple as F3.
I hope this makes sense and is within the capacity of the software.

We have found it to be more the opposite -- that most users like to keep Osnap turned on, and then ask us why the plants are "jumpy" when they attempt to place them.
Which is why the system currently defaults to turning them off during placing, but allows you to press F3 for those situations. Even in your example, it sounds like the trees would be in the minority compared to the volume of other planting, would they not?
But this is certainly something we have been considering, and we would like the Osnap support to be more consistent across the breadth of the software.
We'd like to use this forum as an opportunity for other users to chime in with their suggestions.

--J

I suspect users are asking why the plants are jumping because the osnap and tracking markers are not visible, which is very unusual. It appears as if the OSMODE default is a workaround because osnaps just aren't working properly.

I personally work with osnaps more often than not when planting, and always use osnaps for labelling. I turn them on and off at will and for me, having the osnap setting change automatically interrupts my work process.

I think everyone would agree that regardless of default, when osnaps is turned on that both the 'Place Plant' and 'Label' tools (and any other drafting tools) should have full osnap functionality, including tracking and visible markers. I hope this is an easy fix.

It is not an easy fix -- if it was, I would think we would have noticed the missing OSnap markers sometime in the last decade.
It is part of the trade-off in being engineered entirely in AutoLISP -- on one side, we have a very stable common code base that works with all versions of AutoCAD. On the other, some things like Osnap support is challenging when we dynamically display a block (like a plant or label) that moves with the mouse.
So without the visible OSnap markers, the consensus has actually been very stark -- users tend to think the software is misfiring when the plant jumps all around, and do not think that it could be Osnap. As well, the vast, vast majority of our users do not use Osnaps more often than not when placing plants.
However as I said, we like to use this forum to see what others feel. It could be something we add to the Preferences screen as an option.

--J

Excuses and sarcasm aside, it is concerning that you have been aware of this fundamental problem and it hasn't been tackled over the period of a decade.
Let's not focus on the preferred settings for a workaround. Let's focus on the fix.

I'll jump in. In general, I would prefer OSNAP to be OFF during plant placement. While I can see an argument for it in certain circumstances (rigid/formal garden design), I rarely have an occasion to use snaps during planting design. For reasons Jeremiah outlined, I am selective with the use of snaps. While powerful, it can lead to jumpy and frustrating behavior (both in LandFX commands and vanilla AutoCAD commands).

I think Jeremiahs suggestion of making it a preference option is ideal, as it will let each user set his default behavior.

Jeremiah - thanks for the explanation of the lack of visual feedback in landFX for snaps in these situations being tied to the AutoLISP platform.

After understanding the problem more clearly, it is broken into two inter-related problems - 1. OSNAP marker visibility; and 2.OSNAP defaults.

OSNAP MARKER VISIBILITY
This one is quite simple. If marker visibility isn't available with OSNAPS ON, people will be confused. The markers are necessary to know that you are snapping and what you are snapping to, otherwise the accuracy is lost. For this reason I understand that OSNAPS is OFF by default (as a lesser of two evils). I also think it is imperative that the marker issue is fixed, even if it means incorporating another programming language

OSNAP DEFAULTS
Assuming the marker visibility can be resolved, let's look at the situation logically. User wants to place plants. User will most likely place multiple plants at one time in a very similar fashion. e.g. multiple trees/shrubs, or shrub areas/ground covers, or multiple labels. The command should allow the user to decide what OSNAP settings they want to use as they do with any other command. For plant labelling, the user will switch between on and off quite frequently - perhaps OFF for plant selection, but most likely ON for label location. User would also be more likely to DRAW shrub areas and ground covers within the command with full OSNAP functionality.

As Jeremiah said, switching is as simple as F3. Automatically setting a default is not advanced functionality, it is interruptive to typical AutoCAD use. As I said above, I understand why the OFF default exists while markers are not visible.

If the marker visibility cannot be added, or it will take significantly more effort than adding a default option to preferences, I would suggest that one of the preferences is UNCHANGED. I'd also suggest a warning on limited OSNAP functionality when selecting ON or UNCHANGED.
If the marker visibility can be be given high priority and fixed, it seems preferences would be superfluous. Users will most likely want to switch as required rather than have a default for all scenarios.

I have just noticed that this issue also exists in detailing, and so I suspect it occurs throughout Land FX commands.
I cannot emphasise enough how dramatically a fix to OSNAP and TRACKING marker visibility would improve the plugin.

Actually Aaron, you really haven't emphasized it very much at all -- all you have done is just repeat yourself again and again.
To emphasize it would be to present scenario after scenario where this capability is critical. It would also include comparisons to other high-priority items, and indicate specifically why this is more important.
Here's just a small slice of what we are working on, you tell me exactly where and why OSnap markers fits in this list:

- cloud-based data, allowing instant and seamless transitioning between multiple installs/reinstalls
- native Mac version
- embed plant information into the dwg to allow recovery if the project data is lost or missing (and allow Copy/Paste plants between drawings)
- Site Colorization tool
- convert all leaders to MLeaders
- Color/Material picker for Site Amenities
- additional Lighting capability
- create dockable Palette for RefNote and Detail Managers
- expanded plant database, linking to preset and custom fields and photos
- multiple Irrigation items I will spare you from listing

Keeping in mind that all of these items utilize our same code base. Your OSnap markers will require porting a chunk of code to a different language, and then engineering a distribution system for the new code files, unique for each version of AutoCAD.
I agree it would be nice to have OSnap markers, absolutely that would be nice. As for where that fits in the above list... well, let me know your opinion.

--J

My vote is for dockable refnotes and detail managers. Move it to the top I'll open another request as I have a request on how it is implemented.

t.

- cloud-based data, allowing instant and seamless transitioning between multiple installs/reinstalls - I don't know what functionality this adds beyond installing on local server. I doubt many small companies are even using the Autodesk cloud. Also, I imagine cloud integration is quite a big investment as well, in implementation, hardware and management. - low priority
- native Mac version - low priority as most AutoCAD users are on Windows, and Mac AutoCAD is still severely lacking. The last company I worked at used Macs and we preferred the slowness of Parallels and Windows to AutoCAD on OSX.
- embed plant information into the dwg to allow recovery if the project data is lost or missing (and allow Copy/Paste plants between drawings) - sounds like a bad idea to me. will bloat dwg, and seems to provide little additional functionality to the existing backup tools. A simple autosave option within preferences would be enough. There are workarounds for copy/paste. There isn't one for osnaps.
- Site Colorization tool - sounds like an additional feature that is not necessary to improve existing workflows.
- convert all leaders to MLeaders - worth putting before osnap markers only because it will be easier to implement. Very similar to osnap markers as a fundamental requirement.
- Color/Material picker for Site Amenities - an additional feature that is not necessary to improve existing workflows. Good drafting only needs black and white.
- additional Lighting capability - an additional feature that is not necessary to improve existing workflows. Still won't be able to snap lights properly.
- create dockable Palette for RefNote and Detail Managers - I like the dockable plant manager and can appreciate making it consistent with other managers. It would also be great to have the dock setting remain upon closing and reopening, and also the ability to autohide as with other palettes. For me this is below mleaders and above osnap markers.
- expanded plant database, linking to preset and custom fields and photos - this sounds relatively simple to implement and requires more data entry than programming. It would improve planting workflow but not details or irrigation. This is actually a feature I was going to request, along with better search capabilty (plant species and cultivar refinement) - medium priority.

In a broad sense the argument against osnaps sounds like a car company ignoring steering functionality in their cars because it isn't compatible for whatever reason. It really isn't the users concern. While the car company is marketing its new electric motor and motion detection, all the user will do is warn other interested drivers off this company and keep searching for one with similar features and steering included.

I understand the hurdle in getting a relatively primitive function back into the plugin, but I also see a lot of opportunity for the future in expanding to deeper languages and developing a distribution system. Once you overcome it, so much more is possible.
The two advantages this plugin has over Vectorworks are cost and integration with AutoCAD. The two advantages it has over Revit and Civil 3D are cost and ease of use.
If integration with AutoCAD is improved (correctly) I suspect it would give you increased access to other Autodesk software. If integration and ease of use are improved, you will be able to increase the price. In my opinion if you keep adding new features without tackling the fundamental issues, you will corner yourself into an obsolete product.

Having had the plugin for less than a month it is difficult to compare this issue to every other issue and particularly everything you are working on behind the scenes. Repetition is enough to emphasise a point, but as I said, I can't emphasise it enough. I hope this reply adds emphasis to my point.

Oh Jeremiah. You published your software release roadmap... Now we get to critique it. So, since we are prioritizing, I'll throw in my thoughts.

Dockable Refnotes/Details Manager - 1st priority
Cloud integration - 2nd priority for me. As you know from previous requests, we utilize our office server, and offsite installs (laptops, remote offices), and want to keep more than the project names in sync.
Site colorization tools - 3rd. Want. It. We have been pretty dedicated to Adobe for our renderings, and have a dedicated graphics person for that. BUT, we are finding that our turn around times are getting shorter, and have been using the plant colorization tools quite a bit. Would like to see more enhancements in the site color side.
Plant data expansion - 4th. Mainly because I would like to see more expansion into handling Tree inventory and salvage plans. Having the inventory tag number relate directly to the tree information, and have it tie across all plan sets.
Color Material Amenities - 5th. I am finding it very handy to spec within the software directly to the vendor, and have all the info at hand in the software. Very BIMmy. Hopefully this will translate into the sketchup version too.
Lighting - 6th. We are using it more, but its been pretty good for us so far.

finally...
Embed plant info in DWG - I guess we have been lucky and haven't lost anything yet. But, stability and robustness of the software is a good thing...
Irrigation - you asked the wrong guy. Actually you didn't ask... so...
Native Mac - Bleh. I don't care... ask a Mac person.

Tim,

To keep it on topic though, where in your amended list do you put OSnap markers?

--J

Ok. Fair enough.

I am generally happy with the snaps being off during planting. Its a low priority for me. I can see the argument Aaron is presenting, and can understand how it might be important for some users. It took me a little while to get used to how the plan blocks jumped to lines and auto aligned in landFX. But now I like it.

I'd put it 6th. You can move the lighting down..

I am curious... sounds like the complexity in solving the OSNAPS relates to LandFX being AutoLISP based. I'm no coder, but I know AutoLISP has been around a LONG while. I know VBA is out, and DCL isn't the future. I've read that AutoCAD is pushing towards DotNet. I assume you all are tracking this debate so that you don't end up on a dead end road, as Aaron suggested. Comments?

Yes I think you would be aiming at .NET to allow you to work from the UI right down to C++ in the same environment. The advantage of .NET is that it is relatively language independent.

The interesting thing is that all the developers who listened to everything Autodesk said, and translated their code to VBA and then to ARX, are now having to translate into DotNet. Maybe DotNet is the future, or maybe the OpenGL demands of 3D will push AutoCAD to something used by the game industry.
Meanwhile BIM demands are bringing a welcome open file format back to it all, which may see a bit of competition back the industry.

We're already porting code to DotNet, and that's where our tests for OSnap support has been.
Good to get a sense for priorities across users -- thank you.

--J