Defining objects from scratch

[Sophia]

I realize this has been addressed before, and back then, the general consensus was that cloning was better. However, I'm seeing a lot of suggestions on this thread for "make this editable, make that editable, can we have an item that can do X?" and so forth and so on, so, I'm thinking it'd be a lot less work for George in the long run to simply expose all of the internals of an object definition in some form, and come what may. Dungeon designers can combine properties to their hearts' contents, and produce all sorts of bizarre objects that don't really follow the rules-- flexibility at the price of usability, I'd imagine.

Cloning is somewhat the RTC equivalent of ADGE and such tools, this would be more like hex editing.

The kind of person who would actually go nosing around in the nuts and bolts of an object probably doesn't strictly need the editor, so support could probably be limited to the txt file (as long as the editor was able to load and save the new objects, that is!) Indeed, it'd be more like "programming" than editing, so maybe a text interface would be cleaner, anyhow. Of course, if a sane interface to the editor is possible, I'm not opposed, either!

[beowuuf]

I would like clone items where you have the advanced option of seeing, as you say, all the internals. That way you have a sensible starting place but then could alter then all to your hearts content so they become as crazy of as different as needed

[copperman]

I agree with beo, simply expose more of the object variables. I disagree that this shouldn't make it to the editor, that would be like shiping UT without UnrealEd. I see virtue in being able to get in and tinker with the text file but not adding features to the RTCed just because a couple of hardcore betatesters/users have had since day 1 to learn the dungeon format as it has changed. No that's exclusionary and not good. I've waited close to 20 years to be abe to mess with dungeon layout, so please support the editor , don't sideline it.

[beowuuf]

I think the argument would be like with DSAs. If Paul S had started DSAs and coded them from the point ogf few of GUI interfacing, then they wouldn't be half as flexible as they are now. The downside is a learning curve, but some of that is documentation and perception.

If George only allows what internals as are easy toshow and interract with in a gui first then flexibility will be slow and he will keep gettign requests and requests to expland more

If he can start with opening it wide open, but mostly text driven easy interface of language , with the editor slowly coming up behind, mthen uch better. Basically how the engine proceeded in the firts place - editor came second, before that there was a format of language in place to learn, use, and twist if you wanted until you had an editor to do it easier for you .

[Sophia]

Right. The editor will still allow you to mess with dungeon layouts, same as ever.

What I'm asking for is more access to the internals: a good deal more flexibilty, at the price of immediate usability. Such an approach would really make a GUI somewhat impractical, unless it's a rather spartan collection of text boxes and check boxes. This is why I said, I'm not opposed to a sane way to put it in the editor, but I actually have no clue how that'd work!

Though the "hardcore users" may be able to use it first, having the knowledge, it's not like we're not willing to help and teach, and share neat things we've found.

To stretch your UT analogy, this is more like UnrealScript than UnrealEd.