View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000262 | DarkRadiant | Map Editing | public | 08.04.2007 17:54 | 15.06.2007 22:26 |
Reporter | SneaksieDave | Assigned To | greebo | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 0.9.0 | ||||
Fixed in Version | 0.9.1 | ||||
Summary | 0000262: Apply texture to func_* requires tab after select | ||||
Description | This will probably/hopefully go away after the selection/grouping overhaul, but just so it isn't forgotten: To texture a func_* brush, currently you must first select it, and then also hit tab. | ||||
Tags | No tags attached. | ||||
Isn't this correct behaviour? When you first select a func_static, you are selecting the entity not the brush -- you cannot really apply a texture to an entity. | |
It's possible in DoomEdit to directly apply textures to child brushes when the parent entity is selected. It's most probably a hack in DoomEdit to enable this, but I can see the practical use (although this is a minor issue IMO). | |
I know this probably won't be on the list for a little while, but just to add a thought... :) Am I correct that this category (and some related) of problem arises from: 1. the need to see the origin of such an object (new func, and required), and 2. the desire to be able to drag the origin to a new position (new func, and luxury)? If so, considering the difficulties that this is causing (little things here and there for selecting, manip, texturing), I'd definitely lean toward just mimicking DoomEd. It's pretty much straightforward and intuitive there. Need to texture a func_*? Just select it and texture it. Need to move a func_* (even multi-part)? Just select it and move it. The addition of # 2 above (requiring tab, and leading to some weird behaviors and confusion) is (IMO) not worth all of the trouble it seems to be causing, I for one could live without it. By contrast, while I was testing and trying to map for a bit yesterday, all of these related things (my assumption) were catching me repeatedly. So, it's not so much that it's more difficult in DR (only by a keypress or two), but that it's "inconsistent feeling"/counter-intuitive. To a mapper, a brush they made is a brush, no matter what it really is, so they naturally expect to select and immediately be able to texture, move, resize, rotate, etc. So it really goes beyond just texturing, and this one issue. Maybe simply (<-- well, I don't know) propagating the selection from the ent to the brush as a first step (thereby reversing the whole need for tab to do the most common operations (texture, move), in favor of one rare operation (dragging an origin)) would skirt this whole issue. |
|
I would happily mimick DoomEdit's behaviour (that's what I've been trying to do most of the time here), but the problem is, that it's NOT straightforward for DarkRadiant to target the brush when operations are done while the parent func_static is selected. If a func_static is selected, it's "just another entity" for DarkRadiant, like a statue or a info_player_start. There is no such thing as propagating operations to the child objects (the brushes) in DarkRadiant, that's why everything goes bad. It would be (theoretically) possible to revert everything I've implemented in the last few weeks/months concerning func_statics, which I'm not very fond of. We wouldn't just lose the origin being rendered, we would bring back all those issues that were the main reason why I've changed anything in the first place (prefabs for example). The SelectionSystem and some of the Transformation/Scenegraph routines have to be changed, because they're the root of all these problems. I'm not sure and I'm personally curious how many bloody hacks have been necessary to let DoomEdit work the way it's working now. |
|
Func_* entities are affected now by "Apply Shader to Selection". | |
See now that wasn't so bad was it? I'm kidding! Put the gun down! |
|
Date Modified | Username | Field | Change |
---|---|---|---|
08.04.2007 17:54 | SneaksieDave | New Issue | |
08.04.2007 19:27 | greebo | Status | new => confirmed |
08.04.2007 20:53 | orbweaver | Note Added: 0000549 | |
08.04.2007 20:59 | greebo | Note Added: 0000553 | |
09.04.2007 16:55 | SneaksieDave | Note Added: 0000560 | |
09.04.2007 16:56 | SneaksieDave | Note Edited: 0000560 | |
09.04.2007 17:39 | greebo | Note Added: 0000561 | |
09.04.2007 17:40 | greebo | Note Edited: 0000561 | |
09.04.2007 17:40 | greebo | Note Edited: 0000561 | |
04.06.2007 19:00 | greebo | Status | confirmed => assigned |
04.06.2007 19:00 | greebo | Assigned To | => greebo |
04.06.2007 19:02 | greebo | Status | assigned => resolved |
04.06.2007 19:02 | greebo | Fixed in Version | => latest SVN |
04.06.2007 19:02 | greebo | Resolution | open => fixed |
04.06.2007 19:02 | greebo | Note Added: 0000665 | |
15.06.2007 22:26 | SneaksieDave | Status | resolved => closed |
15.06.2007 22:26 | SneaksieDave | Note Added: 0000688 |