FIRST:
Apologies to those for whom English is not their first, or preferred, or competency language.
I would ask that the Flex License code be, without args or excuses, amended to allow for:
Multiple same-user account + same session launch of app, but not if the account and session are networked and data is being sent outside the account. (The only exception is if the company has stubs or licenses allowing for networking the instances, but that assumes keys node IDs, and money are all accounted for.)
That should be sufficient to protect the IP and licensing intent.
Why do I suggest a change to the Flex license?
I've had wacky files that could and would repeatedly in an instant crash VCP, or SLT, or SFX, and even SC12, I NEEDED to get into the file (my files, my own files — I don't open other people's filea, not even the ones people share in the forum), or, after getting into the file, the clock was running and the app would be doomed to crash. Back then between 2008-2019), I didn't appreciate or exploit the auto-save/auto backup. Even so, my files are HUGE and I can't tolerate 2 minutes backups-related intereuptions every five minutes all day long.
And, when I'm mulling (or muttering) about what control point to move, or what curvature to try, I constantly run into the 20-minute timer (used to be 5 mins, but as the files grow past 50 mb saved, even with only curves in view the other stuff hidden of turned off, I pushed it to 20 mins). It happens to me so often (mulling and muttering) that I often feel tempted to turn off the auto backup. It's easier to swallow than to go through the tedium and pain of trying to resuce file sizes by less-than-fun export of layers I can't with finesse manage the way I need to do, so, everything is in one file.
Files that crash need not be 55mb 120mb saved, or 900mb 1.8 GB in RAM. Some files are just 1 MB and when I do a compact, BAM, the instance of Shark takes with it anything that wasn't saved. I have had numerous instances of being grateful to the point of ecstasy that auto save was on and not only on, just finished 30 seconds before a change I made took the instance down. Sometimes, compacting canncause anninstant crash, sometimes its "Resolve Links". And, when a wacky file is in RAM with a main sessionnfile, and locks up 5he GUI, that's as traumatizing/enraging as if a spurious crash happens.
I absolutely need to have a crashy of suspect or rando-crash file take doen only the instance of it's own file, not my main session. I can't always remember to hit save because I'm intentionally opening another file.
(And, it's frustrating to invoke a 70 seconds save just to open a 1 mb file onnthe anticipation ther may be a crash. It's like a brain surgen being told habaneros might intermittently be let into the surgical bay, but, the surgeon still solely carries the liability, licensing, and potential prison time for sneezing.)
That forced me to open wacky (even no-reasin-to-expect-a-crash) files in a separate instance. I don't share Shark with others, and certainly not with bootleggers. I simply have a low tolerance for a wacky file opened for copying/pasting/reviewing taking down a main session file that takes 40 seconds to open, or 70 seconds to save.
So, that's why I suggest making the locked node code much more aware of what at the network level and on-system number of accounts are greater than local or greater than one.
There's no legit need to compel people to "all-or-nothing" accept a license that is (presumably) code-easy to change so long as the ultimate intent of protecting the IP VC/SC and underlying licensed, 3rd party modules is met.
Even if Shark uses IP of other parties, if those parties are humane, they need to just let Tim prove to them that the code change protects the source's IP and beneficially serves the purpose of reducing pain in the VC/SC user experience.
On the same subject, this is 2023, not 2013, 2003, or 1993. Just as people can copy and paste content between two spreadsheets and even two spreadsheet apps, people ought to be able to copy and paste and non-destructively paste content, and paste it in a way that recognizes the source and target layers having the same names so that a pasted has been done intelligently between files. The CAD world is too viciously secular/isolationist, demanding users transfer only via filters and anointed export/import mechanisms. I get that unmanaged data exchange can or will crash apps and trash files if no structure is in place, but, the day will come when a Microsoft decides to do CAD, and CAD data exchange is an intelligent copy-paste affair, not the current OK Corral/High Noon thing.
The reason I assert that is, whether Shark ran in Win 7 in VirtualBox on a Linux host, or runs natively in Win 11, there is another incredibly infuriating, annoying thing that happens to me:
Toggling by keyboard or toggling by menu, each in-same-instance-of-Shark toggling act causes the magnification or zoom level to progressively reduce. This seriously destroys the ability to to pickoffs or takeoffs of measurements in same-scale drawings.
The ONLY way to disrupt that pain is to open a second instance of Shark and toggle if both are same-display, or drag one to the other screen. Using a matching scale, and then using a plastic W scale or ruler to go from screen to screen, as archaic and inexact as it may be, is a LOT less maddening than constantly manually restting the two switched images or geometry zooms. Both toggled images eventually scale down to zero and the point of toggling becomes questionable. "Zoom Previous", whatever it's meant to be or do, does not oreserve or restore the zooms I set. Shift+Tab or menu to switch between drawings should in no way be putting a user through stress. It shouldn't matter to the user whether it's traceable to Tim, the 3D graphics kernel writer, or the bazillion of graphics chips on the main board.
This is something I've mentioned over 5 or 8 years ago, and it hasn't been fixed. I don't know if it's legacy crap behavior in graphics kernels a kernel maker won't fix (or in the chips), and thus Tim is just stuck, or if it's something Tim CAN fix, but he's swamped with a million other, higher-prioriy fires to out out. Or, if it's something he COULD fix, but some damned license over him is hamstringing him. (Neurotically, daily, these kinds of thoughts invariably, inevitably creep into virtually any and all my drafting sessions. Conspiracy theories don't advance drafting skills or the creation of work content.)
Whatever the case is, the users should not be artificially, needlessly, painfully, and counterproductively forced to suffer because of licensing language that won't flex to reduce pain because Legal Department in various companies or subsidiaries can't figure out how to appease users while honoring the various suppliers' contractual impositions.
In summary, two things related to instance count need fixing:
— loosen it up so long as no networking and no multi-user shenanigans are in play, and
— fix the zoom/scale issue so that users quietly "violating" the TOU aren't doing so out of pain and frustration because distant parties can't or won't allocate resources to quashing a real problem that inevitably forcing users to violate the license in the first place.
Again, apologies to those for whom English is not their first, or preferred, or competency language.
