When mod changes from inside (connecting to a server of using the mods menu), what happens is:
1. Filesystem is changed to the new mod
2. Everything restarts
3. q3config.cfg is executed
What should happen is:
1. q3config.cfg is written to current mod directory
2. Everything is cleared (cvars, I mean)
3. Filesystem is changed to the new mod
4. q3config.cfg and autoexec.cfg are executed
5. Everything restarts
Example:
mod1:
r_mode 3 // in q3config.cfg
set myChatMacro "say HAHA; vstr nextmacro" // in autoexec.cfg
mod2:
r_mode 6 // in q3config.cfg
set myOtherMacro "say HOHO; vstr nexttaunt" // in autoexec.cfg
When changing, video mode should be changed (this half-works now: the value is latched, but the user has to restart the subsystems manually), the corresponding chat macro has to be loaded (doesn't work now, you have to exec autoexec.cfg manually), and ideally the other one would have banished (this is specially important if there's still a 1024 cvar limit which I used to hit constantly with scripts).
When first changing to a mod, the config will be copied automatically, as reading from q3config.cfg will read from baseq3/ since there's none in moddir/. After that, configs will remain independent but unlike now, they'll work consistently and loading mods won't break havoc.
Forgot to mention that there are some special read-only cvars which are meant to be read the first time from q3config.cfg, which fail when switching mods:
execing q3config.cfg
g_spVideos is read only.
g_spAwards is read only.
g_spScores1 is read only.
cl_consoleHistory is read only.
Also forgot to mention that during normal startup, autoexec.cfg gets executed after initialization, so changes will need one restart to propagate.
I'd say it's better to execute it before init, but care must be taken since autoexec.bat can:
* exec other scripts
* use scrpting (vstr)
* issue commands, in particular ***_restart commands
If done before startup, ***_restart commands could be safely ignored since they are not longer needed.
Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.
--ryan.
When mod changes from inside (connecting to a server of using the mods menu), what happens is: 1. Filesystem is changed to the new mod 2. Everything restarts 3. q3config.cfg is executed What should happen is: 1. q3config.cfg is written to current mod directory 2. Everything is cleared (cvars, I mean) 3. Filesystem is changed to the new mod 4. q3config.cfg and autoexec.cfg are executed 5. Everything restarts Example: mod1: r_mode 3 // in q3config.cfg set myChatMacro "say HAHA; vstr nextmacro" // in autoexec.cfg mod2: r_mode 6 // in q3config.cfg set myOtherMacro "say HOHO; vstr nexttaunt" // in autoexec.cfg When changing, video mode should be changed (this half-works now: the value is latched, but the user has to restart the subsystems manually), the corresponding chat macro has to be loaded (doesn't work now, you have to exec autoexec.cfg manually), and ideally the other one would have banished (this is specially important if there's still a 1024 cvar limit which I used to hit constantly with scripts). When first changing to a mod, the config will be copied automatically, as reading from q3config.cfg will read from baseq3/ since there's none in moddir/. After that, configs will remain independent but unlike now, they'll work consistently and loading mods won't break havoc.