[Gtkradiant] [Bug 402] Radiant doesn't handle changing entity classnames well

[gtkradiant@zerowing.idsoftware.com]

http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=402

ttimo@idsoftware.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|1.2.9                       |1.3.3



------- Additional Comments From ttimo@idsoftware.com  2002-05-25 08:47 -------
I remember that a general design guideline for radiant was to create brushes,
and turn them into whatever you want later. That was something I had talked a
bit with Duffy in QERadiant / early Q3Radiant times. That worked for creating
entities, and still works for creating patches for instance, or non fixedsize
entities.

The functionality got changed by Spog during a cleanup of the entity code. Can't
blame spog for not following design rules, he never really did anyway :-) As I
understand, the 1.3 codebase works again by selecting a brush and turning it
into an entity if you want. So this is a non issue. Will just move to 1.3
milestone and we'll close at some point after we verify the change.

---------------------------------------------------------------------------
At 13:21 24/05/2002 -0400, shadowspawn wrote:
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




------- You are receiving this mail because: -------
Whoops!  I have no idea!