Project Settings (was Re: [Gtkradiant] spog checkin question)

[Timothee Besset]

Actually, it looks like we are going to have to rework the project
settings/preferences/game config stuff and work on a more unified design
than what we have been doing so far.

.game have been introduced to bring in support for RTCW quickly. 1.3
developement and more games supported raises more and more issues about
all those config files. If you looked at 1.2.7 you saw that the project
file doesn't make a lot of sense anymore.

Here are the main points that a new design would have to evolve around:

- the scope of the configuration:

'general' configuration, which is independant of the game you edit for,
and independent of what you are currently working on. (your view layout
for instance)

'project' configuration, those are settings that you may want to change on
a per project basis. For instance specific fs_game settings for a mod,
etc.

The problem is that those things tend to overlap each other. The BSP
commands have been in the project settings for legacy reasons, but they
really belong to the general configuration.

- non editable game settings versus configuration:

the .game files are holding some settings information that you can't edit
graphically. because they are not preferences, they work at the upper
level, bringing some information such as wether or not a game has seperate
SP and MP binaries, what is the base directory for the shaders (that will
have to be introduced for JKII), what are the specifics of the BSP command
tools, etc.


Those things are for 1.3, or maybe even 1.4. Not very clear yet, but I
suppose we could drop the preferences/project distinction.

TTimo

On Mon, 6 May 2002 23:33:16 +0100
spog@planetquake.com wrote:

> When the user edits the project in the project dialog, it cleans up 
> the path strings (unix-style + end-slash), but not when the project 
> is loaded/saved, because that required the checking function to be 
> hardcoded to know which project strings to check and which to 
> ignore. When the user edits the paths, we know which ones are 
> paths to check and add slashes to. I rewrote the cleanup function 
> and dumped it into the only place it needs to be used. If the role of 
> the project settings stuff changes (ie. we might now be sure that it 
> contains only path strings) we could do the check/clean on load as 
> well.
> 
> -WJ
> 
> 
> On 6 May 02, at 22:33, Timothee Besset wrote:
> 
> > Those were added in 1.3 tree. What was the initial reason? We used to have
> > a centralized cleanup function that was called on each project save.
> > 
> > http://zerowing.idsoftware.com/viewcvs/viewcvs.cgi/GtkRadiant/radiant/gtkd
> > lgs.cpp.diff?r1=1.18&r2=1.19&only_with_tag=MAIN
> > 
> > _______________________________________________
> > Gtkradiant mailing list
> > Gtkradiant@zerowing.idsoftware.com
> > http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant
> 
> 
>