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

[Timothee Besset]

Keep in mind that we like to proceed by small changes. Complete revamps
are usually much more work than what you had expected at the beginning.
Because we have to keep releasing new versions to fix bugs and support
more games, big changes are usually left for the next major version. 1.3
is already using XML storage for instance. So before you try doing any
further design, make sure you have enough knowledge of the code.

Another way to put this would be 'hey I'd rather see JKII support working
with adaptation of the current 1.2 strategy instead' ;-)

TTimo

On Tue, 7 May 2002 09:18:44 -0400
"Ryan Marc Lahaie-Cohen" <rmarc@sympatico.ca> wrote:

> That's actually what I've been spending a lot of time thinking about while
> trying to figure the best way to add JK2 to the editor without the hard
> coded info (which I'm willing to do for quick support).
> 
> I'll be preping a design doc over the next few days that I think might be an
> adequate solution for us as well as for mod developpers... What I'm thinking
> goes in the same vein as what Tim wrote, but I do see a difference between
> editor preferences and project/game/mod settings (including bsp settings, to
> allow for mutiple compilers such as sof2map).
> 
> What I'd like to work towards :
> 1) Separation of the game data from the editor data (fs_basepath... grrrrr)
> 2) Standardisation between the game
> 3) A mod wizard for users not interested in worrying about the legacy
> project settings.
> 4) XML file formats for the project file, and hell even the entities (maybe
> the game companies will follow suit?) :D
> 
> That's just the beginning...
> 
> riant
> 
> 
> ----- Original Message -----
> From: "Timothee Besset" <ttimo@idsoftware.com>
> To: <gtkradiant@zerowing.idsoftware.com>
> Sent: Tuesday, May 07, 2002 6:49 AM
> Subject: Project Settings (was Re: [Gtkradiant] spog checkin question)
> 
> 
> > 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
> > >
> > >
> > >
> >
> > _______________________________________________
> > Gtkradiant mailing list
> > Gtkradiant@zerowing.idsoftware.com
> > http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant
> 
> 
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant@zerowing.idsoftware.com
> http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant
>