Beyond APPLOAD: A local script manager for those of us with too many LISPs

[VicoWang]

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

[rlx]

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 1 hour ago by rlx

[VicoWang]

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 35 minutes ago by VicoWang