Itches, Glitches & Anything Else...

[OrbWeaver]

However, what I don't understand is why just selecting the keypair causes the pause at all. I understand the pause when opening the dropdown (it has to prepare the list), but not the pause just for clicking the keypair; that's unfriendly.

 

There is no way (AFAIK) to only populate the combo box when it is expanded; it has to be populated when it is first made visible. That said, I thought all of this auto-populating combo box stuff was inactivated some time ago due to the performance problems you are encountering, but maybe it was only the entity class property editor that I modified.

 

EDIT: Now it comes back to me; I did modify the entity class property editor to use a button and a dialog instead of a dropdown, and intended to do the same with the target property editor (i.e. it would pop up a new dialog with a tree of all entities) but never got round to it.

[SneaksieDave]

Ah, that makes sense. I hadn't thought of the fact that once the control is created it needs something in it.

 

Sounds good then. I'll track an issue about giving this control the same treatment that the entity class property editor.

 

Edit: http://bugs.angua.at/view.php?id=1826

[greebo]

I had some time to do some DarkRadiant coding during my vacation, so there are a few changes in SVN (after doing a painful patch-commit-patch-commit process starting from one large .diff file to separate the commits).

 

- Speakers are drag-resizable

- Lights are showing their models if the "model" property is set

- edit: Some entities like func_emitters can be rotated in all room directions ("editor_rotatable").

- Lights and speakers can be resized with their origin fixed

- EntityInspector is updating its keyvalue display on undo/redo

- ESC-to-cancel-operation was not working in Embedded layout

- Removed all home-grown containers like Array, Single, UniqueSet and replaced them with STL items

- Refactored selection workzone code

- tons of minor stuff

 

Soon it's time for the next 0.10.0 release, it's been a while since 0.9.12.

[SneaksieDave]

- Lights and speakers can be resized with their origin fixed

YES!!! Awesome! Have been needing that a lot lately.

 

Any chance of a snapshot?

[greebo]

Any chance of a snapshot?

Hm, I'd rather upload the actual release, it won't be long.

 

@OrbWeaver: do you have time this weekend for the 0.10.0 release? I can handle the Win32/Win64 and website part, I guess.

[Springheel]

Excellent, those sound like some big improvements.

[OrbWeaver]

- Speakers are drag-resizable

- Lights are showing their models if the "model" property is set

- Lights and speakers can be resized with their origin fixed

 

Excellent, those are three issues which I thought about quite recently as being seriously needed (I had a look at the draggable speaker stuff myself, but didn't have time to actually understand the code and didn't want to just copy-and-paste from the light classes).

 

@OrbWeaver: do you have time this weekend for the 0.10.0 release? I can handle the Win32/Win64 and website part, I guess.

 

Sounds fine with me, it certainly has been rather a long time since the last release.

[AluminumHaste]

- edit: Some entities like func_emitters can be rotated in all room directions ("editor_rotatable").

 

Does this actually translate to the game world? If I rotate a smoke particle, will it point in that direction in game? If so then you rock!

[OrbWeaver]

Greebo -- I see you have been doing some work on the selection system. There is a problem somewhere in the ownership of INodePtrs which means that light entities that are deleted are not actually disposed of (and hence are not removed from the renderer), which cases phantom lights to appear at the origin whenever you delete a light. I don't know whether this is anything to do with the selection system or not (debugging shared_ptr ownership is hard), but if you see anything that might be relevant please let me know.

[SneaksieDave]

- Lights are showing their models if the "model" property is set

Wait. Does that mean that for example the combo entity torch thingies will show a light radius?

 

Edit: err, wait maybe that was the other way around... that the torch entities tried a property that would show radius, not lights having models. I'm confused and can't remember the discussion. What does this do?

[greebo]

Greebo -- I see you have been doing some work on the selection system. There is a problem somewhere in the ownership of INodePtrs which means that light entities that are deleted are not actually disposed of (and hence are not removed from the renderer), which cases phantom lights to appear at the origin whenever you delete a light. I don't know whether this is anything to do with the selection system or not (debugging shared_ptr ownership is hard), but if you see anything that might be relevant please let me know.

This applies to render mode only, I understand correctly? I'll look into it.

 

Wait. Does that mean that for example the combo entity torch thingies will show a light radius?

No. It's for lights having their own model spawnargs (not particles, although these are technically the same as models). Like say, you create a light and then apply the streetlamp model to it. In-game the light will appear as model, and you can pass the light brightness down to the model shaders. I.e. if you switch off the light, the model shaders will go dark too (assuming they have the colored keyword set). I'm using this in the gathers map for my streetlight array.

 

(You can even assign sounds to lights, and let the light textures flicker along with the sound shader volume.)

[OrbWeaver]

This applies to render mode only, I understand correctly? I'll look into it.

 

The effect is only visible in render mode, because the light node emits actual light, but I suspect the problem with INodePtrs not being disposed on removal is a more general one (although I haven't done much investigation).

 

Two things I thought of doing were (1) making the SelectionSystem store only weak_ptrs instead of shared_ptrs, since the SelectionSystem should never keep nodes alive past their removal from the scenegraph, and (2) removing the Node::setSelf() code and using the boost::enable_shared_from_this functionality instead. Although these refactorings are probably good from a design point of view, I don't actually know that either of these will solve this problem however.

[greebo]

I can imagine what's happening, as the scene::INodePtrs are not actually deleted, the TraversableNodeSet is emitting a copy of itself to the UndoSystem, where it's stored in the Undo Stack and restored on demand.

 

To fix the behaviour you described, I think it's necessary to hook into the LightNode::instantiate() and LightNode::uninstantiate() methods, which are controlled when the node enters or leaves the actual scenegraph. Deleted nodes are uninstantiated and when they are re-inserted into the scenegraph, instantiate() is invoked again. So, I assume the lightnode needs to detach itself from the renderer on uninstantiate(). I'll check it out sometime today.

 

edit: saw your edit. I'll check out the boost::enable_shared_from_this stuff, this seems to be exactly what I was needing back then. The setSelf() stuff was only a workaround for my problem. Good info.

[OrbWeaver]

I can imagine what's happening, as the scene::INodePtrs are not actually deleted, the TraversableNodeSet is emitting a copy of itself to the UndoSystem, where it's stored in the Undo Stack and restored on demand.

 

Ah, OK, I didn't consider the UndoSystem. So the non-destruction of nodes is actually correct behaviour, not a bug.

 

To fix the behaviour you described, I think it's necessary to hook into the LightNode::instantiate() and LightNode::uninstantiate() methods, which are controlled when the node enters or leaves the actual scenegraph. Deleted nodes are uninstantiated and when they are re-inserted into the scenegraph, instantiate() is invoked again. So, I assume the lightnode needs to detach itself from the renderer on uninstantiate(). I'll check it out sometime today.

 

That makes sense: the actual problem is not that the nodes are not destroyed, but that the light only unregisters itself on destruction. I was thinking about adding a "hack" whereby a method would be called on scenegraph removal in this way, but it sounds like there is already such a method by design.

[greebo]

Yes, the method already exists. It has its origins in the old GtkRadiant node+instance design, hence the name. I shall rename that method to onSceneGraphInsertion() and onSceneGraphRemoval() to better reflect what it's doing.

[SneaksieDave]

Having a prob with the 0.10 release where I can't get split views to go any larger than this (image attached). Usually I shrink the bottom two all the way down so that I have a 2-split, like this.

 

Worse, though I haven't reproduced it yet: on the first launch, I tried to size a bottom window all the way to the top bar, and DR crashed out.

[OrbWeaver]

Having a prob with the 0.10 release where I can't get split views to go any larger than this (image attached). Usually I shrink the bottom two all the way down so that I have a 2-split, like this.

 

Being able to drag the split panes to zero and hide the child widget was actually a bug, which was causing problems in the entity inspector. I did not consider that people might want to intentionally do this for the splitpane windows however.

 

This could probably be fixed by giving the 2D views a very small (or zero) minimum size.

[SneaksieDave]

Yes please, I'd definitely say have this as permitted behavior. I have been sizing them 'out of the picture' for quite a long time now, and in fact our (for $$) software at work even allows for that, hiding of panes by sizing to zero.

 

And/or are you saying this can be jury rigged in the interim? So far I haven't found a setting in the config files...

[OrbWeaver]

And/or are you saying this can be jury rigged in the interim? So far I haven't found a setting in the config files...

 

No, this would have to be set in code.

[SneaksieDave]

Okay. Can we please have this addressed (however works best for the code)? I'm losing at least 12 square inches of (already tight) screen space due to this change, and I doubt I'm the only one affected.

 

[sob story]

There I was terribly excited to dive back in on the trainer section on my new faster (work) system with LCD, with fixed origin light resizing... and then this change happened. :`(

[/sob story]

 

Edit: There's also a semi-reproducable crash associated with this change. I've gotten it 4/4 times before this edit. Get into DR, in split mode. Play with the splitter bars, pushing them to min and max values until the crash occurs. Happens on both of my XP (32bit) systems.

[greebo]

Come on, are you actually saying you lose your motivation for mapping because of 100 fricking pixels?

 

I can look into the crash, but it will take a while - please report that on the tracker.

[SneaksieDave]

Sigh. Did the fact that I prefaced it with [sob story] not indicate that I was making light of it? I didn't realize it was going to be a point of contention. Maybe if those pixels (100,000 actually, at 1024x768) were taken away from everyone, it'd be taken more seriously. It represents approximately 25% of this user's available workspace.

 

The change causes a significant UI problem. If it can be remedied by simply allowing a size of zero or one, why not simply fix it as a bug?

[greebo]

The change causes a significant UI problem. If it can be remedied by simply allowing a size of zero or one, why not simply fix it as a bug?

I never said it shouldn't be fixed, but your wording made it sound like you want this done ASAP ("Okay. Can we please have this addressed") - probably a misinterpretation on my behalf, so let's forget about it.

 

Is the main intention of resizing it to 0 to have a full camera view? I can whip up a separate window layout ("Camera Only") to which a shortcut could be assigned.

[SneaksieDave]

Is the main intention of resizing it to 0 to have a full camera view? I can whip up a separate window layout ("Camera Only") to which a shortcut could be assigned.

Though it's not my main intention, that would also be very cool and IMO is worth pursuing. I recall setting up some hotkey to switch modes some time back, between my splitpane view and a floating view with full size camera, but IIRC it didn't work flawlessly, so I didn't adopt the method.

 

My main desire when using splitpane view though is just to be able to fully decide how those four views are laid out at any time. With that two-half-size-views method I use, going between full cam, full iso, or any proportion between them is as convenient as dragging a single bar. I drag that bar very frequently and it.

[OrbWeaver]

Greebo, I have encountered a serious crash (assertion failure) if you create a brush and then drag it so that it would become infinitely thin. The stack-trace is:

 

#0  0x00007fc84dcdefb5 in raise () from /lib/libc.so.6
#1  0x00007fc84dce0bc3 in abort () from /lib/libc.so.6
#2  0x00007fc84dcd7f09 in __assert_fail () from /lib/libc.so.6
#3  0x00000000006469aa in Brush::update_faces_wireframe (this=0x6a5a728, 
wire=@0x6a5a9f8, visibleFaceIndices=0xc39c00, numVisibleFaces=1)
at brush/Brush.cpp:502
#4  0x000000000063447d in BrushNode::evaluateViewDependent (this=0x6a5a440, 
volume=@0x6b9df10, localToWorld=@0x6a5a548) at brush/BrushNode.cpp:436
#5  0x00000000006344a9 in BrushNode::renderWireframe (this=0x6a5a440, 
collector=@0x7fff5c05b8b0, volume=@0x6b9df10, localToWorld=@0x6a5a548)
at brush/BrushNode.cpp:460
#6  0x00000000006345eb in BrushNode::renderWireframe (this=0x6a5a440, 
collector=@0x7fff5c05b8b0, volume=@0x6b9df10) at brush/BrushNode.cpp:383
#7  0x0000000000696d9f in RenderHighlighted::render (this=0x7fff5c05b740, 
renderable=@0x6a5a690) at ./render/frontend/RenderHighlighted.h:23
#8  0x00000000006a2e35 in RenderHighlighted::pre (this=0x7fff5c05b740, 
node=@0x6f79110, parentVisible=VOLUME_INSIDE)
at ./render/frontend/RenderHighlighted.h:63
#9  0x00000000006a2f36 in ForEachVisible<RenderHighlighted>::pre (
this=0x7fff5c05b6e0, node=@0x6f79110)
at ./render/frontend/ForEachVisible.h:58
(More stack frames follow...)

 

I could investigate if needed but I don't know anything about this code -- is this related to any of your recent changes?