Okay, a funny thing happened on the way to this forum.

I loaded xcal's "FBL Dynamic 1.7" theme, but it loaded a different version of xpopup than what was specified in the theme.rc file. I ended up deleting almost all modules out of the litestep\modules folder and reloading, forcing a "clean" download. Then the theme worked correctly.

My question is this: Do I need to clean out the modules folder periodically to ensure the theme downloads and uses the dll's it's looking for? Has anyone else had to do this?

Okay, that's TWO questions.

I think I know what the problem is. If you've ever been unable to DL a particular module, whatever the reason, Netloadmodule asks you if you'd like to select a different version/module to use instead. It then stores those in a file (NetLoadModule.ini). Mine has this line, for instance (among many others):

popup2=$litestepdir$modules\popup2-2.1.7.dll

I imagine that somewhere along the line you picked up an entry either deliberately or by accident that "reassigned" the module in question. I also assume that deleting all your modules made NetLoadModule scrap those assignments and start fresh. Rabidcow can probably confirm that.

Well... in theory, that makes sense. In practice however, the only line I had referencing xPopup is this:

xpopup2-1.1.9=$litestepdir$Modules\xpopup-1.1.9.dll

so... i'm not sure how THAT would have affected the version I was being hit with (1.2 loaded instead of 1.2.5) ?

By the way, I copied NetLoadModule.ini to a different file and deleted all entries in there. I'm sure your thinking is probably correct, I'm just not sure how the entry I had was affecting the version I was looking for.

Well, that's not at all clear to me now either, given the contents of your INI file. It seemed like a likely culprit, though. Odd.

I suppose if you right clicked on a module in the dl box and selected a zip (rather than a dll) of the wrong version, it might take the dll and give it the wrong name. Then you'd get the wrong version without an entry in the ini file. Or a theme could wire this wrong by listing an incorrect zip file on a *NLM line. Or a server could send the wrong zip file. (and of course there's no way for NLM to know what version the dll actually is)

If it happens again, you might try doing a !NetUninstallModule for the version that it's trying to load and then recycling. That *should* delete any wrong files/mappings.

I'd consider that to be the authoritative answer.