BaseCamp 4.3.5 is Now Available

Great. I will open a case. Thanks!

Re-post due to lost forum posts:

Installed 4.3.5 recently. Noticed new option in Options/General, to “Use ‘alt’ while dragging to move or insert data”. (Probably introduced with 4.3.0, but I didn’t try that.) Decided I didn’t want to do that, so I left it UNCHECKED, so the hand tool behavior would be as before, which I’m used to.

I discovered that now if I try to pan the map by dragging the hand tool, and happened to have started the drag with the tool anywhere near a route or waypoint, the tool immediately switched to insert or move and I was locked into this action. Ctrl-Z to undo. Very annoying!

I realized though that if I CHECKED the box about using the “alt” key, but then never actually USED the “alt” key, then and only then was the hand tool behavior back to “normal”.

Is this as designed? It seems very counter-intuitive to me, bad design I think to have to check a new option so tool behavior stays as before. I have no problem with the feature for those who use it, but suggest you need 3 check boxes/tool actions:

1 Hand tool will not change to another function automatically.
2 Hand tool changes to insert or move when “alt” is pressed during drag.
3 Hand tool changes to insert or move when drag is started near a route or waypoint.

We are working on fixing the help issue. This will update on its own when corrected.

Re-post due to lost forum posts:

Above quote from 8/1; It seems the PC version of BC is still pointing to the Mac help version. In 3 weeks the correct PC help can’t be stored on the server at the pointed-to URL? Really?

Re-post due to lost forum posts:

Installed 4.3.5 recently. Noticed new option in Options/General, to “Use ‘alt’ while dragging to move or insert data”. (Probably introduced with 4.3.0, but I didn’t try that.) Decided I didn’t want to do that, so I left it UNCHECKED, so the hand tool behavior would be as before, which I’m used to.

I discovered that now if I try to pan the map by dragging the hand tool, and happened to have started the drag with the tool anywhere near a route or waypoint, the tool immediately switched to insert or move and I was locked into this action. Ctrl-Z to undo. Very annoying!

I realized though that if I CHECKED the box about using the “alt” key, but then never actually USED the “alt” key, then and only then was the hand tool behavior back to “normal”.

Is this as designed? It seems very counter-intuitive to me, bad design I think to have to check a new option so tool behavior stays as before. I have no problem with the feature for those who use it, but suggest you need 3 check boxes/tool actions:

1 Hand tool will not change to another function automatically.
2 Hand tool changes to insert or move when “alt” is pressed during drag.
3 Hand tool changes to insert or move when drag is started near a route or waypoint.

We have made some adjustments to this UI for 4.4. There is a beta available.

"Driving" will route cars on a hiking trail or mule trail in U.S. Topo 24k West if the logical highway route is closed in winter and "Avoid date/time closure" is checked. (Is this new? I did not have this problem with routes created before the update to 4.3.5.).

This is a bug. Instead of silently creating impossible or dangerous routes, BaseCamp should refuse to route to points along a seasonal road if the avoidance is checked.

Repro: Checkmark the avoidance "date/time closure." Create a new route between two points on the Tioga Highway 120 in Yosemite National Park. Garmin's route will go through wilderness to avoid the highway. However if "Trucking" is selected, it will route along 120 even though the highway is closed for most of the year.

Thank you for your feedback. We have opened a case on this issue.

After upgrading to 4.3.5 about an hour ago, when using the waypoint tool, a click will insert the waypoint in the desired location. After about 3-5 seconds, the waypoint self deletes. Reinstalled 4.3.5 and still have the same problem. This problem is only occurring when I try to create the route on my memory card (removed from GPS and inserted into desktop computer via card reader). Only BirdsEye images reside on the card. I have always used the memory card to create routes so I can see the trails via the BirdsEye images.

I'm an experienced Mapsource user new to Basecamp (though I read quite a bit about BC before I made the leap). I just installed 4.3.5 a few days ago and have been both pleased and frustrated. In particular, the enforced unique name for waypoints is giving me fits.

Regarding the mandated unique names, I've read this thread, which was recently closed with the direction to post in the current release thread if there are questions or problems:

So I am posting here. Please let me know if I need to post this elsewhere.

Actually it's not just waypoints that must be unique, the following objects: waypoints, routes, tracks, lists and list folders. In essence, all such objects have a global scope.

This limitation (especially with waypoints) poses a significant obstacle to those wishing to integrate existing data into BC without major change.

I keep reading explanations such as "it is a database", as if that explains it and makes it clear and final. As a guy with a few decades of database and application design experience, I can't accept that.

I have a large collection of Mapsource data I'd like to manage in BC. Many waypoints have names like "8PM" or "10 A M DAY 5" or "Get Gas" or "CheckWX". These are waypoint names it is important to me to have available for use in multiple routes, at different locations. I can't imagine a practical way to manage this data in BC without polluting my planning process and losing fine control of what displays on my GPS when traveling.

So your mandated global scope creates a significant obstacle.

I propose that global scope remain the default, but that each object may optionally be assigned a more limited scope from this hierarchical list:

List Folder, List, Route.

Current BC internal logic regarding name uniqueness would be employed only within the scope in which that object is defined.

If implemented, users not needing this feature would not be impacted by the change. Objects are global today, and global would remain the default. Only users who need the expanded functionality would need to bother with it.

But for those who do need it, Basecamp would offer a significant and powerful new way to manage their data.

Given the existing hierarchical display logic, by which you can drill up and down in scope while viewing all "children" of the scope currently selected, I can see the possibility that a unique name would be required globally even for objects defined with limited scope.

There could still be a unique global name/alias for each object regardless of scope. This global name would be used when the object is shown in a scope broader than it is defined. The suffix to make such object names unique could be something like X_name where "X" is F, L or R (for folder, list or route) and "name" is the name of the folder, list or route in which the object is defined.

Let me put this all into an example:

As things are now, assume I have a route named "MountEvans" with a waypoint named "summit". I have another route named "MountStHelens", and try to create a waypoint named "summit".

If created directly, I get an error telling me to make it unique. If brought in via import it gets the name "summit 001".

With my suggestion, when creating the second "summit" waypoint, in the UI the user would modify the scope from its default of "Global", to "Route" (e.g. via radio button). The waypoint would be created without error with the name "summit", but the "global alias" would be "summit R_MtStHelens" for use when displaying the waypoint name in a scope above "route".

The global alias would be used only inside of basecamp, it would not be included in what is loaded onto the GPS.

Similarly, the import process would include a default scope of Global for objects being imported, but also permitting the selection of an alternative scope at import time.

Users would not be able to directly edit the global alias. BC would maintain the global alias based on the object name and scope.

I realize this is not a trivial suggestion, with some database changes as well as UI changes, but it's just an incremental enhancement. One that I believe cures a critical limitation of BC.

After upgrading to 4.3.5 about an hour ago, when using the waypoint tool, a click will insert the waypoint in the desired location. After about 3-5 seconds, the waypoint self deletes. Reinstalled 4.3.5 and still have the same problem. This problem is only occurring when I try to create the route on my memory card (removed from GPS and inserted into desktop computer via card reader). Only BirdsEye images reside on the card. I have always used the memory card to create routes so I can see the trails via the BirdsEye images.

I can't replicate that behaviour and so unsure what's happening. It certainly isn't normal.

...I realize this is not a trivial suggestion, with some database changes as well as UI changes, but it's just an incremental enhancement. One that I believe cures a critical limitation of BC.

Alas, BaseCamp must "talk" to a myriad of devices, including some fondly known as "legacy devices" which, I believe, given your suggestion would somehow have to keep track of the "scoping" while the waypoints lived on them to say nothing of those born on the devices. With clean sheets on both devices and BaseCamp it would be trivial to implement a unique key algorithm while letting the user see only a human derived name field. But that is not going to happen any time soon!

One solution might be to employ the newly implemented category specification along with the human specified name to make a unique key into the database. Maybe that's where they are going?

Believe me, we ALL feel your pain :)

Re-post due to lost forum posts:

It seems the PC version of BC is still pointing to the Mac help version. In 3 weeks the correct PC help can’t be stored on the server at the pointed-to URL? Really?

Finally seems to be fixed. Thank you.