[Gtkradiant] Analyzing the mapq3 parser & some suggestions
basiror at gmx.de
Thu Mar 15 11:51:50 CDT 2007
I wasn t aiming the messageboard as a mapping community, but more towards a programmer platform with the focus on GTKRadiant + Plugindevelopment
Mailinglists aren t that attractive anymore either, now that everyone has broadband connections.
I also think GTKRadiant should go beyond the current feature sets for editors. There s a lot of work for mappers to do for mappers nowadays, so the editing tool should automate some of the work
e.g.: in call of duty 2 you had to place decal brushes with a special decal texture on all sides + a visible decal texture on the visible side of the brush, doing this for large map requires ages,
so why not simply paste the decals onto the regular brushes and let the editor handle them internally? Safes a lot of time.
another example, creating a realistic environment is a tough and time intensive job
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:
console:> push; rot 90; trans 128; create_fence(); pop; push; rot 180; trans 128; create_fence(); pop;
this would create 2 fences perpendicular to each other and 128 units shifted away from the editing origin( creation brush, selection brush, whatever you call it)
console:> record macro <name_of_macro>;
// create some brushes, assign textures ...
console:> stop recording;
repeat the same action with the new selection/creation box
console:> push; name_of_macro(); pop;
just some tools to automate repetitive tasks
maybe even integrate a physics engine and allow something like this
console:> push; exec_n_times( 100, <macroname>); pop
this executes the macro 100 times at the current selection/creation box
in conjunction with a physic engine that would allow you to simulate the debris placement, where the macro takes care about all aspects of the debris spawning. ...
executes the macro every 4 seconds for a period of 60 seconds, so you can move the creation box around your map and let the debris fall down
console:> push; exec_timed( 4 sec, 60 secs, <macroname>); pop;
these would be engine independent features which add a lot to productivity
maybe the whole editing mechanism should be replaced with a text command driven system and a transactional storage mechanism as you know it from databases
------ Original-Nachricht --------
Datum: Thu, 15 Mar 2007 13:14:10 +0100
Von: namespace <spam at codecreator.net>
An: GtkRadiant developer discussion <gtkradiant at zerowing.idsoftware.com>
Betreff: Re: [Gtkradiant] Analyzing the mapq3 parser & some suggestions
> One argument against a messageboard is that the gtkr community is fading
> very quickly. Almost every website that is about mapping looks like a
> ghosttown today. Even the the bigger messageboards have one a few active
> members who do posts, or even do some mapping.
> I don't want an empty "offical-gtkr"-forum that would support the
> "everything goes down"-feeling.
> I'm not sure what the reseans are for that regression but my theory is,
> that with doom3, contentcreation (and content that looks acceptable) got
> very difficult and that doom3 limits you to a dark environment with only a
> lights and lots of shadows.
> Q3 was much more open and flexible in that regards.
> I mean look at the UT games, UT 1 up to 2k4 have lots of customcontent
> made by gamers. I bet that this will go down to zero as soon as UT 3 gets
> released. UT 3 would require the same amount of work, or even more as
> (normalmaps for everything, maybe even heightmaps for parallaxmapping...)
> and is therefore unatractive to everybody who doesn't want to spend a
> hole week to get a custom staticmesh look right.
> Am Donnerstag, 15. März 2007 01:41 schrieb Jorge Peña:
> > Haha, how about a message board for GtkRadiant in general? I think
> having a
> > 'central' one would be great, we could use it for GtkRadiant help,
> > development, and whatever else we want. But as it seems now, it looks
> > we're kinda broke on a lot of things; no wiki, etc. etc., so I too think
> > that the mailing lists should suffice, as long as we get the spam fixed
> > haha.
> > On 3/14/07, namespace <spam at codecreator.net> wrote:
> > > Am Mittwoch, 14. März 2007 16:46 schrieb Eduard Aumüller:
> > > > 1.) Why don t you at least add a //! blah blah infront of each
> > > > declaration so doxygen can generate the complete class hierarchy.
> > >
> > > Ask the former devs.
> > > 99% of radiants code is very old (dates back to 1.1 times) or
> > > got rewritten by Spog for 1.5. My contribrutions are mostly fixes and
> > > smaller
> > > improvements. The only bigger source-chunk from me is the brushexport
> > > plugin which was never intended for public release in the first place
> > > was
> > > published because of popular demand.
> > >
> > > > 3.) Also what happened to the GTKRadiant wiki? Maybe setup on at
> > >
> > > wikipedia?
> > > It was taken offline after it got spammed. According to TTimo its not
> > > completly lost and will be back online after a server switch.
> > >
> > > > 2.) How about adding a picture code to the bugsubmission form, this
> > > > spam
> > >
> > > is
> > >
> > > > really annoying
> > >
> > > I hate that spam too, however I don't have admistration privileges to
> > > that. I guess we have to wait for the serverswitch.
> > >
> > > > 4.) A message board for developers would be very nice too^^
> > >
> > > Developers? Right now there is just me and LordHavoc.
> > > The mailing list is sufficent imho.
> > >
> > > namespace
> > >
> > > --
> > > www.codecreator.net | GPG: 0xD4DB516D
> > >
> > > _______________________________________________
> > > Gtkradiant mailing list
> > > Gtkradiant at zerowing.idsoftware.com
> > > http://zerowing.idsoftware.com/cgi-bin/mailman/listinfo/gtkradiant
> 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
More information about the Gtkradiant