[Gtkradiant] Analyzing the mapq3 parser & some suggestions

["Eduard Aumüller"]

Once I have analyzed the code enough I could propably come up with an implementation, would be a lot easier with a somewhat useful documentations.

I have a lot respect of the developers that wrote GTK Radiant without any documentation really, but on the other hand it should be a priority to get  a decent documentation done.

btw. I have read the most important topics of the last 6 months


-------- Original-Nachricht --------
Datum: Thu, 15 Mar 2007 19:41:14 +0100
Von: namespace <spam at codecreator.net>
An: GtkRadiant developer discussion <gtkradiant at zerowing.idsoftware.com>
CC: 
Betreff: Re: [Gtkradiant] Analyzing the mapq3 parser & some suggestions

> Am Donnerstag, 15. März 2007 17:51 schrieb Eduard Aumüller:
> > I wasn t aiming the messageboard as a mapping community, but more
> towards a
> > programmer platform with the focus on GTKRadiant + Plugindevelopment
> What development? For how long do you read the ml now?
> I think that you can't estimate gtkrs status in terms of 
> developer-attractiveness or user-demand.
> GtkR was always short on developers, even in its better times.
> To be honest I don't see much future for gtkr as a major editor.
> GtkR relies on brushwork and a "build -> compile" production cycle.
> Modern editors focus on the managment of staticmeshes and are
> capable of instant preview.
> Sure, things can be implemented, but who should do it and how long will it
> take?
> Open source is late be definition, esp. in our case. Support for a new
> game
> like et:qw can only be implemented after the game has been released.
> And after that gtkr has to compete with the proprietary devtools that were
> available at releasetime. A lost battle right from the start.
> 
> > so why not simply paste the decals onto the regular brushes and let the
> > editor handle them internally? Safes a lot of time. 
> > some sort of console at the bottom of the editing views would be nice
> > so you can enter tiny commands or execute selfmade macros writting in
> some  
> > scripting language:
> Nice ideas, I vote for python as scripting language.
> I assume that you will be one to implement them, right?
> I don't want to sound unfriendly here, but we get alot of good ideas for
> cool features, but when it comes to the hard part (implementation)
> these people usually exercise restraint.
> 
> namespace
> 
> -- 
> www.codecreator.net | GPG: 0xD4DB516D

-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out