Jump to content
The Dark Mod Forums

Manipulation Of Func_statics


Recommended Posts

Right now, func_statics can be selected and moved (the origin is updated accordingly). At the same time it's possible to move the "child" brushes as well, allowing for positioning relative to the func_static origin.

 

A problem arises if the drag-selector is used to select a func_static entity. Because of the way the drag-selector works both the brushes and the parent entity are selected. Moving the selection around results in the translation being applied to both the entity and its child brush, hence the group is moved at double speed. This is especially annoying if the func_static is selected along with other objects, because the func_static's relative position gets completely screwed up.

 

I had a look at DoomEdit and it seems to handle this a bit differently. Selecting a brush that is child of a func_static, seems to select the whole group/entity. Selecting the brush using the Alt-Shift cycle modifier allows to select the brush alone and moving it around, but it seems like the origin of the entity is moved as well, which is a bit weird.

 

How do we want to handle this situation?

Link to comment
Share on other sites

  • Replies 66
  • Created
  • Last Reply

Top Posters In This Topic

I think my "ideal interface" for this feature would be that a func_static behaves as a single object, and is selected as a group whether clicked directly or caught in a selection volume. It would then be possible to enter the group with TAB (or a configurable key) and move around the group components individually.

Link to comment
Share on other sites

Hmhm, I think that makes sense, although I don't know if it feels intuitive for the mapper to hit Tab to access the child objects. However, I can't came up with a better solution right now anyway, so let's try this.

 

I'm currently digging into it and see if it's easily possible to easily retrieve the parent instance of a given object and if this can easily be incorporated into the Selectiontest walkers.

Link to comment
Share on other sites

I'm currently digging into it and see if it's easily possible to easily retrieve the parent instance of a given object and if this can easily be incorporated into the Selectiontest walkers.

 

It depends if you have a Node or an Instance. If you have an Instance, you can call path().parent() to get the parent entity. There is code for this in the Entity Inspector so when you select a brush, it will display the keyvalues on the parent entity.

 

The reason I suggest TAB is because this is what DoomEdit uses, it could equally be any keyboard shortcut. It would probably be best to have an "Enter group" menu command exposed somewhere as well, perhaps on the context menu, for maximum discoverability.

Link to comment
Share on other sites

I just committed a change that prevents objects from being selected if their parent is other than worldspawn. So far everything seems to work ok, the func_static behaves as group and all the other objects same as before.

 

Next thing is to look into the Tab command.

Link to comment
Share on other sites

It's frustration time again. :D

 

I think I found another approach of avoiding the double-speed translation thing, but this relies on finding a way to disable the auto-selection of parent instances as soon as a child is selected.

 

Currently, if you selected the brush belonging to a func_static, the func_static is automatically selected as well. I waded through the selectionlib and tried to figure out, where this damn call is propagated to the parent instance, but I couldn't find it (and I better don't start complaining about the selectionsystem here - you wouldn't want to know how unbelievably entangled this maze of callbacks is).

 

The question is: Is it always desired that, if a child brush is selected, the parent entity is selected as well? I notice that this behaviour also applies to brushes that are child of worldspawn (as soon as it is selected, the worldspawn properties appear in the entity inspector). You can watch this behaviour in the Entity List as well.

 

edit: Thinking about this, it probably is desired, otherwise you wouldn't be able to actually see a func_static that exists of exactly one brush. Hm...

Link to comment
Share on other sites

The question is: Is it always desired that, if a child brush is selected, the parent entity is selected as well? I notice that this behaviour also applies to brushes that are child of worldspawn (as soon as it is selected, the worldspawn properties appear in the entity inspector). You can watch this behaviour in the Entity List as well.

 

edit: Thinking about this, it probably is desired, otherwise you wouldn't be able to actually see a func_static that exists of exactly one brush. Hm...

 

It really depends what is meant by "selected". Obviously it is necessary to be able to retrieve the parent entity for key values etc, but whether this entity needs to be flagged as "selected" is debatable. Is the concept of selecting a brush-based entity even properly defined? After all, such an entity does not actually have an physical existence, it is just a container for primitives.

Link to comment
Share on other sites

Don't know if a proper concept exists, but it seems that child instances automatically get notified when the parent selection is changed (compare scenelib.h).

 

I consider this useful for top->bottom propagation (func_static selected > all children appear highlighted) but not for bottom->top propagation, although I'm not sure. Maybe it's necessary, because the SelectionTests rely on the child objects, I don't seem to recall to see anything like testSelect propagation in the Doom3Group class.

 

(The more I see from the SelectionSystem, the more I want to rewrite it. I know that this is not a good idea at this stage and it would probably take me forever but everything's such a mess).

 

Perhaps this can be overcome if the Doom3Group class was redesigned to a real container class that propagates the calls, but I feel my motivation slipping through my fingers. :D

Link to comment
Share on other sites

I think my "ideal interface" for this feature would be that a func_static behaves as a single object, and is selected as a group whether clicked directly or caught in a selection volume. It would then be possible to enter the group with TAB (or a configurable key) and move around the group components individually.

Ding ding. That's the one for me.

 

I think that makes sense, although I don't know if it feels intuitive for the mapper to hit Tab to access the child objects.

Absolutely - in DoomEd, when you're selecting an arch for instance, to get around the patch faces of the whole object, you tab around. When you have a giant func_static like Dram's railings with 100+ parts, you cycle through the family with tab. Gotta have tab!

 

I hate living across the sea that I come to these debates so late! :rolleyes:

 

Currently, if you selected the brush belonging to a func_static, the func_static is automatically selected as well.

Yes, so it should be - I'd be bothered if I selected a func_static brush and the rest didn't become selected. I think that might be tracked, even. You select a part, which selects the whole. Then, if you want part only, you tab to it (unless a better more direct mechanism can be devised, which might be worth trying, because I don't think anyone wants to have to tab through, e.g., Dram's 100+ part railings).

 

Maybe I'm confused by this and need to see it in action to try it. A safe assumption is that anything that acts radically different from DoomEd is probably a risky idea. It's not because we can't come up with great ideas; it's because id, Doom, and the community have been at it and around for more than a decade perfecting how this stuff can and should be done, and we shouldn't be reinventing the wheel for things which don't require it. Obviously things like Objectives Editor don't even exist, but for stuff like selection and manipulation, they've got it pretty solid.

Link to comment
Share on other sites

A safe assumption is that anything that acts radically different from DoomEd is probably not a great idea. It's not because we can't come up with great ideas; it's because id, Doom, and the community have been at it and around for more than a decade perfecting how this stuff can and should be done, and we shouldn't be reinventing the wheel for things which don't require it.

 

That's not really true -- like most game editors, DoomEdit is hacked together quickly in order to allow the level designers to produce the content in order to meet the deadline, and does not have the focus on usability that we are aiming for.

 

In situations where there is no obvious improvement on the DoomEdit solution, or there are various competing alternatives with no clear winner, I would agree that adopting the DoomEdit model is the best way forward; however there are plenty of cases where this is not appropriate (think of the massive DoomEdit right-click menu which makes it impossible to find anything).

Link to comment
Share on other sites

That's not really true -- like most game editors, DoomEdit is hacked together quickly in order to allow the level designers to produce the content in order to meet the deadline, and does not have the focus on usability that we are aiming for.

 

Quite true. While doom edit is pretty good, as far as editors go, it's still quite the buggy mess in places. There used to be quite the extensive list of bug fix requests on doom3world, I don't think many of them were ever fixed. Quake Wars might just have a pretty snazzy editor though. Those guys were modders, so I think they will build the tools with that in mind.

Link to comment
Share on other sites

Of course, I'm not speaking of adapting bugginess, or even general quality of the tool, just items proven of design. For example:

 

-Select one part of a func_static gets you the whole func_static: this is a convenience. It would be a pain in the ass to have to select the whole thing.

 

-Being able to tab through the parts is a necessity and a convenience.

 

There's no real need to change this proven and established method. That's what I'm trying to say.

Link to comment
Share on other sites

There we go: I added Tab / Shift-Tab commands that allow the cycling of child primitives, if one single entity like func_static is selected.

 

This is the new snapshot:

http://208.49.149.118/TheDarkMod/DarkRadia..._latest_SVN.zip

 

Btw: The snapshot link will stay the same, the ZIP will always contain the latest build (if I don't forget uploading, that is).

Link to comment
Share on other sites

Hm, either I'm doing something wrong, or something's up. I created four brushes, and made them into a func_door. I select one, which selects them all, then I hit tab to cycle through the 'parts' (as in DoomEd). All four stay selected. Tried same with func_static and got same behavior.

 

BTW selection priority (special ents over brushes) rules!

 

Edit: Oh wait! is it a new command that must be assigned? Searching...

 

Edit: is it GroupCycleForward? that seems to do it I think. Awesome. I like how part of the cycling is 'all' so you can step between moving part, or all.

Link to comment
Share on other sites

Another issue arose: http://bugs.angua.at/view.php?id=162

 

It seems that the moving origin upon func_static translation is causing troubles, because the brushes are positioned relatively to the origin (and move along) with their TexDefs staying unchanged >> hence the appearing texture translation.

 

There must be a way around this, although I'm running out of ideas here.

Link to comment
Share on other sites

That's as a result of the new ability to move brush and origin separate I guess?

 

Regarding that, I hate to throw this out there, but I just closed #154, and then thought of a problem with the method in place (which otherwise works fine). If it's a complex object, like a portcullis door (that example is serving me a lot lately), it'll be hard to reposition the origin. Reason being, they'd have to drag the origin into place, and then reposition each and every part of the portcullis (maybe 20 or more parts). Ugh. So I may have jumped the gun on closing 154. What do you think? Should there be explicit origin repositioning for this type of reason? Maybe reversing the treatment of this is possible (brushes first, origin last). Or, maybe the origin could be part of the tab cycle?

 

I can confirm that typing the origin value does still move the whole brush, so that's not a way around it.

Link to comment
Share on other sites

A moveable origin might be possible -- is there an OriginChangedCaller or anything on the Doom3Group class? I think you'd have to intercept the changing origin and then traverse the group's primitives, offsetting them appropriately in order to keep them at the same position in world space when the origin moved.

Link to comment
Share on other sites

That's a good idea, this callback is there. I will look into that and see if I can come up with something. It would be easier if the Doom3Group was a "real" container / group, and not just the home a simple origin/rotation value.

 

What definitely has to be assured is that the brushes are actually translated by a translate()-call, because this method checks for the texture lock property being set and updates the TexDef accordingly.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...