[Gtkradiant] mo' bullshit

[jeremiah sypult]

> > feedback welcome obviously :)

>From a tolerating mappers standpoint, I still appreciate everything you
developers are doing. If there were a noble cause to coding that I could
partake in, it would definetely be the id Editors and utilities. Ignore the
bullshitting and ranting, please continue doing what you do because you like
doing it -- not because people are pissed at you. I commend you guys for
taking such harsh words repeatedly over and over, time after time.

I have some comments on what has been said as of late... And in terms of
problems, some of them are rather obscured that it is difficult to
pinpoint... I will keep trying though (who likes losing their hours and/or
months of work anyways?). When I find concrete proof of a problem I attempt
to explain it as best as I can and try and give solutions.

> Perhaps a remote installer that people could run to update their
GtkRadiant
> installs, with the option of preserving older builds.

This is a good idea, but after already reading ttimo's reply I can
understand the somewhat difficulty.

There is an alternative idea, and that is to take a little bit of time and
'modularize' things from the editor and basically have an 'updater' page
that has the latest full package, or the updated 'modules' for the editor --
modules like binaries, game packs, media packs, examples, documentation --
all dated; maybe even with a change history?

This would be a very simple page with nothing on it but the listitems that
could be bookmarked; check the version number/date and download/install... I
would be happy with just ZIP files in this situation --

I would imagine that maintaining a single HTML page with links sure beats
writing an automatic updater program...

> I'm not sure what kind of action we should take. Could just post on
> qeradiant.com with some more explanations. But I think a more definitive
> page on the website may be good. Some kind of manifest, explaining how the
> QA is done, how the releases are handled and stuff.

In terms of 'development', I do have an opinion. Some of the biggest
problems I have seen with the editor is data corruption, as stated in the
bullshit rant. Although unfortunate, it does happen. Personally, in the
middle of doing so many changes and so many updates -- while implementing so
many new features and processes things are bound to get out of whack.

(This might sound a little cheesy, but I know where it is coming from. Try
to bear with the cheesy wording... :)

Above all else, the map data is the most important thing. Once the map data
starts to get corrupt that problem should be immediately attacked and
corrected. Halt all other development -- especially new features and
processes (they can be the cause)... Most -- if not ALL other bugs can wait
when it comes to map data corruption.  Corruption is the ultimate poison to
creativity and usage. Once you take something that allows people to express
themselves happily, and allow it to destroy their creations, it becomes a
disheartening poison... Think of it this way: what if your Microsoft or GNU
C compiler corrupted small parts of your source as it compiled it? Or what
if your text editor corrupted the buffer and places random characters in
place of spaces and/or other characters? Determination starts to lower and
the need to get away from the work increases.

Who wants to eat the fruit from a poisoned tree?

I hope I get the point across... Program crashes are one thing when you lose
at a minimum of hours of work... But when your data becomes corrupt -- even
if you have backups every week -- redoing that kind of work (especially on a
creative level -- mapping AND coding) for a weeks worth of time can make
someone who does something for free and fun want to give up. The thoughts
have crossed my mind, but encouragement has kept me going. It goes a long
way.

Does this make sense? I'm up for comments and discussion...

.jer