LiteStep.net Forums

Imm using the litestep installer that came out yesterday that has the default theme of austerity and when i go to change themes it tells me that some modules need to be updated and downloads like the 6 it needed except the first 2 which were shortcut2 and popup2.... what does this mean, where can i get those files needed and how would i install them if the installer for them cant find them

Actually it's RabidCow's NetLoadModule that does the module downloading, not the theme installer or anything like that.

And there's nothing wrong with the downloading. ;)

You need to contact the author of whatever theme the download is failing for and ask them to fix it.

Please keep in mind when you encounter a problem with a theme that it is a problem with the theme 99% of the time. Is that so difficult to believe? ;) Your first resort should always be to contact the author of a problematic theme.

In the meantime, you can try fixing the theme yourself...

Change lines in theme.rc like:

*NetLoadModule shortcut2
*NetLoadModule popup2

to:

*NetLoadModule shortcut2-2.0
*NetLoadModule popup2-2.1.1

This will download the modules properly. It may not be enough though if the theme is using !Reload with the popup or something. The theme's author needs to fix their theme.

Hope that helps. :P

omar: that's where setting $evars$ for those !reload-specific modules comes in real handy.....

ceeslans: nothing is stopping anyone from doing that in their themes, but it's not something that needs to be part of the OTS. and I don't see how it applies in this case anyway. ;)

the author of this theme made a mistake and that's what needs to be be addressed, no need to workaround problems created by others. :P

btw, RabidCow is working on making it so that themers that find working with modules too difficult/users that need to store modules in different ways need not worry about pesky things like module paths and versions.

imo it would really make sense for !netreloadmodule to just take the base name of the module without the version number.

however, if it does that, it would have to be set to download the newest version (which could be another problem, since version numbering isn't always constant). but the newest version isn't always the optimal version, as we all know.

It wouldn't have to use the newest version. If the version has already been specified, say with *NetInstallModule, then it could take it from there. But then there's the trouble of how it would know whether you wanted it to guess the version or wanted an actual module that doesn't have a version.

NLM 2.4.3 (which is pretty much ready, I just have to package it up) will allow you to use:

!ReloadModule "$PathToPopup2$"

but it's a bit fragile because of the flaky nature of $constants$.

sorry, I meant that if there wasn't a version specified, THEN it would need to use the latest version. or check on a central listing (on loose-screws.com or shellfront) for the latest "certified" module version. or something like that. which would be even MORE of a hassle for you, so just forget I said anything.

Yeah, I meant that the themer would specify the version number in the *NetLoadModule line.
I'm not really a big fan of the evar changing stuff. You never know how/if it works and how/if it changes from build to build. The variable system just wasn't designed for this.

sure, understand your point.
anywayz, sofar the evar 'solution' works great for me on a theme where eight different modules are *netloaded and (script)!netreloaded...

I know, that's why I say $constants$ ;) For any given er, "session", they are theoretically constant. (not always the way NLM uses them, but nearly always)

Really I'm trying to do something that doesn't fit with the way litestep was designed. I can't play nice and still get what I want.

@ceeslans: The big caveat is that they get wiped out by !reload, so it may not be as convenient as you think. This is not a bug. (but you can work around that)

@ilmcuts: I don't understand:

I'm not really a big fan of the evar changing stuff. You never know how/if it works and how/if it changes from build to build. The variable system just wasn't designed for this.