[Gtkradiant] RE: [Bug 402] Radiant doesn't handle changing entity classnames w ell

[Joseph, William]

[replying this to gtkradiant list]

The behaviour is different in gtkradiant 1.3.x (not yet released)

Original feature (pre-1.2.x):

Create a brush, or select any brush that is not an entity already.
Rightclick anywhere in the 2D views (not specifically on a brush) and choose
an entity type from the menu.
If the entity type is fixedsize, produces an entity containing the
selection.
Else produces a fixedsize entity at the position of the selection.


New feature (1.3.x):

Rightclick anywhere in the 2D views and choose an entity type from the menu.
If the entity type is fixedsize, produces an entity at the point clicked and
deletes the selection.
Else produces an entity containing the selected brushes (ignoring any
fixedsize entities selected).

This has the behaviour you want... when you create a fixedsize entity such
as a playerstart, anything selected will be deleted.

-SPoG

-----Original Message-----
From: shadowspawn [mailto:shadowspawn@mail.shadowspawn.net]
Sent: 24 May 2002 18:22
To: wjoseph@europe.ea.com
Cc: Timothee Besset
Subject: [Bug 402] Radiant doesn't handle changing entity classnames
well


Hey guys,

This bug I posted about was a requested functionality before gtkRadiant was
even conceived, was added pre 200 and stayed in all the versions of radiant
until it's behaviour was changed in this latest release. As a matter of
fact, I think the only id-engine level editor that this doesn't work with in
this manner is the latest version of gtk.

It was touted as a 'finally, this feature is in!', it was in all the manuals
based off of radiant, it was used by people who design levels as it was
intended. It mimics (or did before this change) almost every other CAD
program out there in this manner of placing entities, from 3ds to lightwave
(well sorta, I think of it as a really extreme modifier). Its benefit must
be used and applied to be understood; the reasons for it's addition to
radiant were numerous and that's why it was integrated. For a real-world
example, it made steps like adding an ent in the basic tutorial manual and
questioning it's position, step 4c (adding a player starting point) moot. No
guessing was needed in an 'is it in there?' situation, it's where the last
selected brush was. That was it's point, that's why it was done.

Changing that behaviour was something that hurt allot of people and not just
myself. I can handle keeping a version of an editor on my computer that I
like, and switching between versions to use features that I need. But when
this poor fellow came to me and told me what he did, it brought it to light
that "old school" designers are going to see this removal as a bug and still
makes allot of good manuals that exist out there null and valid for the new
mapper. It was a logical addition, after all.

Using more then one version of radiant is commonplace, most experienced
designers that I work with also use multiple versions for the same reasons;
one version of radiant always has features that don't work as intended or
don't exist in others, or they prefer the interfaces that they grew to
become comfortable with. They don't complain, they accept it as it is and
that it probably will never change. But the level designers new to the
latest version of GTK are the ones that don't have time to read over the
changes.txt or cruise through the bugzilla, they are the ones I'm thinking
about here; there is enough cool features to learn about already in the new
editor without having to hunt through functionalities that were omitted,
discovering them by methods of trial and error.

However getting this function and it's widely used feature back seems to be
impossible. I therefore requested the old warning popup as it appeared in
pre/old q3radiant/qeradaint for changing ents; otherwise ents may overlap
(as I never even thought would've been the case) by following standard
documented mapping procedures or habits, and more confusion and frustration
may arise which I just want to avoid as I am sure you do as well.

The reasoning behind the change still leaves me at a loss, at why the time
of adding feature was put in if it was never intended to be used, and why
instructions were written based on the addition were made (and still
distributed with the current version of GTK's documents, the very last line
in the entity mouse function docs for example), and why it was called a
function if it was never intended to be used as one.

Just a formal proposal for the change, that's all.


-Keith