VicoWang Posted July 23 Posted July 23 Hi everyone, I'm Vico, an architectural designer. I've found this forum incredibly helpful over the years— so many of the LISP routines shared here have become the backbone of my daily workflow. But as my collection grew, one thing started driving me absolutely crazy: the APPLOAD dialog. The problem (I suspect I'm not alone) Managing dozens of .lsp, .fas, and .vlx files through that interface is clunky at best. You can't see what's loaded, what's conflicting, or even what half of them do without opening each file. And the Startup Suite? Let's just say it and I have a complicated relationship. Then there's the real nightmare: upgrading to a new PC. You spend half a day manually rebuilding your Startup Suite, redefining aliases in acad.pgp, and fixing broken Support paths — and you still forget something. My attempt at a solution Over the past few months I built a tool to solve this for myself, and I thought the community here might find it useful. It's part of a side-project I've been tinkering with called VedaCAD. The tool comes as a single compiled .vlx. By default it runs in Base mode — completely offline, no accounts, no network calls, nothing phoning home. It just sits quietly and manages your local scripts. What it does: Gives you a clean UI to see all your loaded scripts in one place — no more hunting through APPLOAD. Lets you assign custom command aliases directly from the interface, without manually editing acad.pgp or writing wrapper LISPs. Has a one-click "Export Config" that builds a lightweight JSON mapping of your entire environment. Take that file (plus your LISP folder) to a new machine, hit "Import Config", and everything comes back exactly as it was — script mappings, custom aliases, and paths, bypassing the native Startup Suite entirely. A couple of disclaimers It's written entirely in pure AutoLISP/Visual LISP and DCL, so it should be compatible all the way back to AutoCAD 2006 — none of that "requires .NET Framework X.x" nonsense. I've personally tested it on 2006, 2014, and 2024, and it runs smoothly right across that range. And again: fully air-gapped in Base mode. No telemetry, no registration nag, no "sign up to unlock." If you're paranoid about that sort of thing (I certainly am), you can verify with any network monitor like Wireshark. Why I'm posting I built this to scratch my own itch, and it's made my life genuinely easier. But I'm one person with one workflow — I'd be really curious to hear if this solves a real problem for anyone else, or if I've just been doing APPLOAD wrong all these years. If you'd like to give it a spin, the .vlx is attached. Happy to answer questions, and very open to feedback (including the critical kind). Cheers, Vico VedaCAD V1.0.VLX 2 Quote
rlx Posted July 23 Posted July 23 (edited) It looks great , you centainly know how to lisp like a pro, thanx! Not sure the image is getting through , ah , now it its , had to switch browser with a little less security... Edited July 23 by rlx 1 Quote
VicoWang Posted July 23 Author Posted July 23 (edited) 41 minutes ago, rlx said: It looks great , you centainly know how to lisp like a pro, thanx! Not sure the image is getting through , ah , now it its , had to switch browser with a little less security... THX,By the way, I noticed RlxBatch in your screenshot. Assuming that's a subroutine library or a dependency file rather than a standard command, I thought I'd share a quick "hidden feature" built into the manager: If you are loading a core library that doesn't need a direct command alias to trigger it, you can leave BOTH the "Native Cmd" and "Custom Alias" fields completely blank when adding it. When you do this, VedaCAD flags it as a System Library: It hides it from the main DCL listbox, keeping your UI clean and focused only on actionable commands. It forces the file to load immediately upon AutoCAD startup. This actually ties into how VedaCAD handles performance. For standard commands (where you define an alias), the tool uses strict Demand Loading (similar to CAD's native autoload behavior, but managed internally). The actual LISP payload isn't evaluated into memory until the exact moment you type the alias. This means you can throw 100+ heavy routines into the manager without increasing your AutoCAD startup time or memory footprint. But for dependency files like RlxBatch, leaving the fields blank ensures those subroutines are pre-loaded into the namespace and ready for your other scripts to call.· Just thought that trick might be handy for your setup! Edited July 23 by VicoWang 1 Quote
BIGAL Posted Friday at 12:12 AM Posted Friday at 12:12 AM You have posted twice about the same topic, as a newbie here there is no need to do that, Admin may decide to merge your two posts together. Made a comment in other post about installing new software. 1 Quote
VicoWang Posted Friday at 03:24 AM Author Posted Friday at 03:24 AM 2 hours ago, BIGAL said: You have posted twice about the same topic, as a newbie here there is no need to do that, Admin may decide to merge your two posts together. Made a comment in other post about installing new software. Hi BIGAL, First off—huge apologies for the double post! I originally stumbled across that 2007 thread, dropped a reply, and then realized it would be much better to create a dedicated thread so I could properly attach the .vlx file without hijacking the old discussion. Definitely a newbie mistake on my end, and I completely understand if the Admins merge or delete the old reply to keep the board clean. Thanks for the heads-up! I just went back and read your comment on that older post regarding your Install.lsp method. Extracting a ZIP natively via LISP COM objects, automatically creating directories, and injecting Support paths and CUIx menus is an incredibly resourceful and clever solution! It proves we've all been battling this exact same deployment nightmare for decades. Actually, your Install.lsp workflow is basically the spiritual predecessor to what I built with VedaCAD. The main difference is that instead of moving physical ZIP files, VedaCAD relies on pure mapping logic: At the atomic level, a 6-character VCID resolves a single asset. To migrate a whole PC, it simply compiles a list of those VCIDs into a lightweight config profile to batch-restore your entire setup. Scaled up for enterprises, it dynamically syncs environments based on user permissions. The engine handles all the file routing natively in the background. Since you clearly have a deep history with this community (20k+ posts is incredible), I actually have a question for you: Historically, the vast majority of AutoLISP routines and CAD tools have been strictly local. From your perspective, how far has the landscape evolved regarding web-connected or cloud-synced plugins? Are there many developers successfully exploring REST APIs or cloud-fetching inside AutoCAD nowadays, or is the community still heavily leaning toward local, air-gapped deployments? I'd genuinely love to hear your thoughts on where the ecosystem is heading. Quote
lucas0510_12311 Posted Sunday at 09:04 AM Posted Sunday at 09:04 AM i got .vlx file and i dont know the command pls Quote
Nikon Posted Sunday at 09:31 AM Posted Sunday at 09:31 AM (edited) 30 minutes ago, lucas0510_12311 said: i got .vlx file and i dont know the command pls Type VC to start. Read it on the command line when loading .VLX. Edited Sunday at 09:34 AM by Nikon 1 Quote
BIGAL Posted Monday at 12:24 AM Posted Monday at 12:24 AM (edited) @VicoWang I don't do anything with the cloud but I know some of my clients are going that way for various reasons, in the very simple way the Install.lsp works there is no reason why the programs etc can not be loaded to the cloud. You only need correct support paths hopefully set, I don't use the cloud. One other thing is we had laptops where I worked, so when outside in the field the user would select the correct icon on the desktop, we had two icons "In office" and "Out of office" then the correct profile was loaded. The "out of office" would look on the laptop for programs etc, Yes had a slightly different set of menu's. The profile choice is in the ICON properties. Edited 18 hours ago by BIGAL 1 Quote
VicoWang Posted Monday at 04:05 AM Author Posted Monday at 04:05 AM (edited) 3 hours ago, BIGAL said: @VicoWang I don't do anything with the clous but I know some of my clients are going that way for various reasons, in the very simple way the Install.lsp works there is no reason why the programs etc can not be loaded to the cloud. You only need correct support paths hopefully set, I don't use the cloud. One other thing is we had laptops where I worked, so when outside in the field the user would select the correct icon on the desktop, we had two icons "In office" and "Out of office" then the correct profile was loaded. The "out of office" would look on the laptop for programs etc, Yes had a slightly different set of menu's. The profile choice is in the ICON properties. Hi BIGAL, First off, thank you for sharing your perspective on how the community and your clients are handling the "cloud" today. It’s really insightful to hear where the landscape actually stands from someone with your experience. You’re spot-on that most people currently just map AutoCAD Support Paths to a static cloud drive folder. And that "In office" / "Out of office" dual-icon setup you mentioned? That is a brilliant piece of classic IT problem-solving! It perfectly captures the exact nightmare CAD Managers have dealt with for years when engineers take laptops to construction sites. Analyzing those classic IT workarounds highlights that the core deployment challenges in CAD haven't changed, but modern architectures give us new ways to tackle them. At their core, almost all traditional methods—whether passing local ZIPs or mapping static cloud drives—rely on static distribution. Once a file leaves the source, its connection is severed, inevitably leading to version fragmentation across the firm. This is exactly why we designed VedaCAD to provide dynamic lifecycle management through a "Cloud-Managed Local Sandbox", rather than just live cloud mapping. From an engineering standpoint, here is how we structured the technical measures to handle those specific scenarios: Solving the offline field scenario Mapping directly to a cloud drive introduces fragility—if the internet drops, CAD freezes. To prevent this, everything in our architecture physically runs from a local sandbox cache on the C drive. The client simply pings the server with a lightweight heartbeat. If an engineer opens their laptop on a site with zero Wi-Fi, the LISP kernel silently transitions into Offline Mode. They keep drawing seamlessly using their local cache until the configured offline grace period expires. No need for separate desktop icons. Managing binary updates and file locks When a developer patches a .vlx or .dll, expecting users to manually download and replace ZIPs leads to version fragmentation. We shifted this to a heartbeat-driven sync. When the server detects a version drift, the update is pulled into the sandbox. Depending on the workspace policy (Manual, Auto, or Enforced), the user either clicks to approve it, or the engine hot-swaps it silently in the background. To bypass Windows file locks on running binaries, the engine utilizes a backend .bak renaming trick to perform the in-place replacement without crashing CAD. Resolving subcontractor environment consistency How do we ensure that all subcontractors perfectly align with the drafting standards set by the general contractor, even down to the absolute uniformity of a single linetype color? We tackled this by building isolated containment fields we call "Project Arks". Instead of emailing ZIP files of CAD standards, a General Contractor can package their absolute drafting environment and issue a time-limited "Visa". When a subcontractor mounts it, their CAD temporarily mirrors the GC's standard. Crucially, if the GC updates a .ctb or other environment configuration files mid-project, the subcontractors pull the latest standard on their next heartbeat or upon manual sync, allowing the GC to monitor exactly which external terminals are lagging on outdated standards. Asset revocation and self-healing If a subcontractor's Visa expires, or an internal employee's device is unbound, the system relies on a zero-trust model. Upon the next ping, the engine executes a remote kill-switch, physically shredding the proprietary CAD assets from the local cache. Conversely, if a user accidentally deletes a cached plugin, the LISP reactor detects the loss via a native (findfile) check and instantly auto-fetches the replica from the cloud, ensuring the execution chain never breaks. It’s always a pleasure geeking out over deployment architectures with veterans. Thanks again for the great discussion! Cheers, Vico Edited Monday at 04:06 AM by VicoWang Quote
zaphod Posted yesterday at 06:15 PM Posted yesterday at 06:15 PM Nice Lisp VicoWang! This looks like a great solution to the dreaded startup suite, some suggestions; Is it possible to have the "Asset Name" be the file name by default? Could the "Version" field default to 0? 1 Quote
VicoWang Posted yesterday at 06:47 PM Author Posted yesterday at 06:47 PM (edited) 33 minutes ago, zaphod said: Nice Lisp VicoWang! This looks like a great solution to the dreaded startup suite, some suggestions; Is it possible to have the "Asset Name" be the file name by default? Could the "Version" field default to 0? Hi zaphod, Thank you so much for testing it out and sharing this feedback! 1. Auto-filling Asset Name from File Name: Absolutely agreed! You’re 100% right—when you browse and select a file like AreaCalc.lsp, the system should intelligently parse (vl-filename-base) and automatically pre-fill "AreaCalc" into the Asset Name if the field is empty. This eliminates repetitive typing when adding a batch of local tools. We are incorporating this directly into the next build! 2. Defaulting Version to 0: Why we intentionally keep it blank. You bring up an interesting point, but keeping the Version field blank is actually a deliberate architectural design choice on our end. In VedaCAD's ecosystem, published version numbers are immutable once uploaded to ensure clean version tracking and hot-updates. If we pre-fill 0, a user adding a local script and casually clicking "Publish" would permanently stamp their cloud asset with version 0 without making a conscious choice. Leaving the field blank forces a brief pause, ensuring authors explicitly set a structured initial version (such as 1.0 or 1.0.0), which keeps the public ecosystem metadata clean and reliable for everyone. Really appreciate you taking the time to share these ideas—feedback like this helps us fine-tune both the user experience and the underlying discipline! Vico Edited yesterday at 06:49 PM by VicoWang Quote
VicoWang Posted 1 hour ago Author Posted 1 hour ago (edited) VedaCAD is still a relatively new platform and client. Thank you to everyone who has been testing the offline Base Mode of our client—your suggestions and bug reports are highly welcome. Under offline BASE Mode, the client will never actively connect to the internet, making it convenient for those who need a purely local, long-term tool without network dependencies. I'd really love to introduce the "Online" side of our platform today. Our user tiers are generally divided into 6 levels: BASE, FREE, PRO, TEAM, CORP, and CORP (DED). They are all unified within a single client (the .vlx file shared above). Apart from the BASE mode, the other 5 tiers require periodic internet connectivity. Before diving into the tiers, I want to mention our online account system. There are no passwords in our system, so you never have to worry about exposing your password habits. We primarily support four login methods: OAuth Login: Currently supporting Google, Microsoft, and Autodesk platforms. Magic Links: Enter any email address to receive a real-time, secure login link. OIDC (SSO): Supported exclusively for the two CORP tiers (e.g., Auth0, Microsoft Entra ID). Client Reverse-Login: Once logged into the CAD client, your machine acts as a hardware identity token. Anytime you click the Manage or SOPs (for enterprise employees) button in the client, it securely bypasses passwords and logs you straight into your Web Portal. BASE Tier: As you have seen, you can mount local LSP, FAS, and VLX plugins. The maximum size per asset is capped at 1MB (which is more than enough for pure LISP scripts), and the client acts as a proxy loader. We guarantee that the BASE mode will never actively initiate network requests., and there are absolutely no quantitative limits for local use (no limit on mounted assets, no limit on config imports/exports). FREE Tier: This is our community edition for individuals and students. You just need to register a free account. It supports the same LSP, FAS, and VLX formats (local or via VCID), but the single asset limit is raised to 3MB. This tier is free forever. Besides managing local assets, FREE users can publish assets to generate and share VCIDs. You can also combine your published assets with downloaded plugins to create a bundle, generating a B- prefix VCID. You or anyone with this Bundle VCID can input it via "Install via VCID" to batch-pull the entire toolkit. (Note: If a FREE user pulls a bundle created by a PRO user that contains ARX or DLL files, the system will actively drop those advanced formats).For example, the following two real testable plugins: [Codebase Packer] VCID: 0FBGZB @ VedaCAD [Quick Annotator] VCID: 7JAU18 @ VedaCAD In addition to format and size limits, FREE users have a generous cap of publishing up to 50 assets per day. What happens if you delete your account? This is something you need to know, and I’ll try to explain it clearly. We will execute compliant data anonymization. If an asset you published was only ever used by you, it will be destroyed from our system. If your asset was downloaded at least once by someone else (especially if an enterprise incorporated it into their asset pool), the physical plugin will remain in the system, but the author will be fully anonymized. This ensures the stability of the entire CAD ecosystem so someone else's workflow doesn't suddenly break because a plugin vanished. PRO Tier: This is designed for professionals. Besides the features in the FREE tier, the main differences are: Single asset size limit is increased to 15MB to accommodate ARX and DLL plugins. Asset format support is aligned with the Enterprise matrix. Plugins include: LSP, FAS, VLX, ARX, DLL. Environment configs include: CTB, STB, DWT, SHX, PAT, LIN, TXT, XML, JSON, INI, PGP, SCR, CUIX, DWS, PC3, PMP, ATC. (Note: All environment config files can only be published as private assets requiring authentication. Essentially, they are for your own use—even if someone knows your VCID, their download will be blocked). Tip-Jar Linking: If a PRO user configures a sponsor link, a tip button will appear in these locations: upon first download, via a dedicated toast popup when the command finishes executing 24 hours after installation, when the asset is selected in the manager, during bundle pulling, and on the user's public profile (if visible, e.g., vedacad.com/@vico). You can also connect Webhooks (Discord, Slack) to receive real-time tipping intent notifications. Can accept and mount ARK- Project Ark Visas issued by General Contractors to sync environmental standards. Push Updates: You can push updates to your plugins (e.g., patching to v1.1 with a new file) without changing the distributed VCID. On the user's end, the update will execute manually or automatically based on their workspace policy. Personal Cloud Config Sync: You can PUSH your entire local state to the cloud and PULL it on a new PC for a sub-second full environment restoration. What you need to know about cloud sync: even absolute local paths (e.g., D:/CADTools/abc.lsp) are mapped and synced. As long as the new PC has that file in the same D-drive path, the migration is complete. (Note: Ark Visas are strictly isolated and are never synced via cloud config). Syncing is a manual action to avoid overriding correct setups. We provide three strategies: push local to cloud, pull cloud to local, and smart merge. If unsubscribed, you naturally downgrade to the FREE tier. Account deletion follows the FREE tier rules. TEAM, CORP, CORP (DED) Tiers: These are our Enterprise tiers. Note that when a TEAM+ tier expires, the workspace is physically frozen (Archived), not downgraded to FREE, because enterprise data structures are fundamentally different. Here is the general enterprise logic flow: The Foundry (Enterprise Asset Pool): When an admin adds and publishes an asset in the client, it is pushed to the web-based Enterprise Foundry. Admins can also mount external VCIDs (from independent devs) or Ark Visas into this pool. This is a centralized, pending-allocation list. Admins can attach SOPs (Standard Operating Procedures) to environment files and plugins (including external ones). Our system supports GIF + Markdown for SOPs. Internal Squads: Admins create groups (e.g., Architecture Squad) and assign employees and assets to them. An employee might belong to multiple squads simultaneously; our algorithm deduplicates their assets. When the employee logs into the CAD client, the unified asset list is silently deployed to their local sandbox. On the next heartbeat or manual sync, the client checks for missing files or updates and executes silent replacements. The SOPs button in the employee's panel links directly to the online SOPs of their assigned assets. Admins can also monitor the "Out of Sync" status of any specific plugin for any employee via the dashboard. Project Arks: Arks are decoupled from the main enterprise seats. You might have a 20-seat Enterprise plan but purchase 100 Ark slots because Arks manage external sub-contractors. Arks are strictly limited to environment config files (no executable plugins allowed). GCs issue Visas to external PRO users or sub-contracting firms. Arks have expiration dates and a unique Paid Archive Status: For a retainer fee (monthly/yearly), the Ark version is frozen (e.g., snapshotted on July 30, 2026), and includes 2 maintenance slots. If modifications are needed in 2028, the GC issues the 2 slots, and the sub-contractors will pull the exact environment state from that archived day (even if the active config has iterated to v2.0 since then). Employee Onboarding: TEAM relies on Magic Links. CORP allows direct OIDC (SSO) login, but employees enter a buffer pool awaiting admin approval before consuming a paid seat. Domain Hegemony: Our system anchors enterprise ownership to the corporate email domain. If an employee previously registered a personal FREE or PRO account using their corporate email, when the Enterprise workspace is created, their next login will trigger a forced choice: DESTROY their personal space to join the enterprise, or SPLIT (transfer) their PRO assets and billing to a personal email (like Gmail), leaving the corporate email clean for enterprise approval. This ensures absolute domain sovereignty. Tier Differences: TEAM includes SOPs, Magic Links, and on-demand Arks. CORP includes all TEAM features plus SSO, BYOS (S3) storage mounting, and EDR sandbox threat interception. CORP (DED) is identical to CORP but operates on an isolated, dedicated physical database tenant (requires manual admin deployment). If you are interested in the enterprise features, you can check out our Enterprise Dashboard Demo by clicking the Get Demo button next to the TEAM or ENTERPRISE cards at vedacad.com/pricing. Edited 55 minutes ago by VicoWang Quote
CivilTechSource Posted 40 minutes ago Posted 40 minutes ago That is cool! But didn't AutoCAD 2027 released something tiny bit similar (project workspace?) 1 Quote
VicoWang Posted 26 minutes ago Author Posted 26 minutes ago 9 minutes ago, CivilTechSource said: That is cool! But didn't AutoCAD 2027 released something tiny bit similar (project workspace?) I checked and indeed there are some similarities, but the overall logic may be different. Thank you for the information. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.