Crystal environment variable

[DaHoC]

Hi,
I think it would be a good idea to explain how to change/access the CRYSTAL or CEL environment variables since that is needed if a CS game is released. The variables should be changeable internally so the real system variables remain untouched.
The aim is that if a CS game is shipped, a user who has a CRYSTAL var set different to the CS game specific directory, the game probably will not run/work properly (I noticed that several times now). That should not be too tricky, but I don't have a clue.

[jorrit]

Hi,
I think it would be a good idea to explain how to change/access the CRYSTAL or CEL environment variables since that is needed if a CS game is released. The variables should be changeable internally so the real system variables remain untouched.
The aim is that if a CS game is shipped, a user who has a CRYSTAL var set different to the CS game specific directory, the game probably will not run/work properly (I noticed that several times now). That should not be too tricky, but I don't have a clue.

That's just a standard C function call: 'setenv'.

Greetings,

[mark]

yes, you can do this with C. This is how I have done it:

Code:

int main(int argc, char* argv[]) {
    std::string dir;
    char* pfadname = new char[PATH_MAX];
    dir = getcwd(pfadname, PATH_MAX);
    delete [] pfadname;

#ifdef _WIN32

    setenv("CRYSTAL",(dir+"\\lib\\crystalspace").c_str(),1);
    setenv("CEL",(dir+"\\lib\\cel").c_str(),1);
#else

    setenv("CRYSTAL",(dir+"/lib/crystalspace").c_str(),1);
    setenv("CEL",(dir+"/lib/cel").c_str(),1);
#endif

    int retval = Starter().Main(argc, argv); // start csApplicationFramework
    putenv("CRYSTAL=");
    putenv("CEL=");
    return retval;
}

notice that you must not use any CS datatypes, functions etc pp because CRYSTAL isn't set before this code.
Also notice that you must use getcwd if you want to stay OS independent (Win32+Linux, I don't know if it works on Mac though it should).
When you're using getcwd you must start your application from within the directory in which the binary lies, or else "dir" will be set wrong.
The function realpath is much better than getcwd, because it gets the real path for the binary - but MinGW doesn't support this (though it's POSIX).
Also notice that you must use putenv to unset the variables, not unsetenv - yes, because that crappy Redmond "OS" doesn't support this neither.

Maybe you have to include limits.h, though it works without that on my systems.