Baal

It's not as complicated as it sounds. I find brushes are much easier to work with than patches.

The way I did that, was to simply build brushes to fill the gaps.

Well, it's obvious that nobody ever had the slightest clue why guards suddenly were alert (me included). I propably thought it would mix things up a little, but it just causes confusion. It has to be fixed, and the easiest way is to just remove the spawnarg. Otherwise I have to make it clear what exactly will be missed; and I don't know how to do that.

Hm, I don't know. Normally you can just nick everything. That would change the expected, established rules. Does anyone have a strong opinion about that?

Oops. I completely forgot about that. I thought the cup was the only one. That feature seems to cause only confusion and the spawnarg should propably be removed on all entities.

Yes, but that is so inconvenient that I would never put something in a parent. So, while the restriction doesn't have to be there, in practice all parents would be empty. The workflow would then always be to create an empty layer, and then put the other layers beneath it. That should be automated (with layer grouping feature).

After working with the layer hierarchy for a bit, I've come to the conclusion that only the leaf nodes should contain geometry. You can't easily select a parent node alone; you have to move its contents to a child if you want to do that. So instead of making one node the child of another node, they should be selected, then grouped. That would create a new, empty parent with the grouped layers as children. Unless there is some error in my thinking, this makes more sense to me.

No, it's the sequel to Sir Talbot's Collateral.

This is very much work in progress but it's starting to take shape.

An example: I have properties docked on the right. Most of the time I want it narrow, leaving more space for the 2d and 3d view. When I switch to the texture tab, I want it large and at the same time I don't need 2d, so it can be narrow or hidden. Switching tabs should automatically restore the sizes I set. I hope that makes it more clear.

Is it feasible to have the properties change size on switch of its subtabs so that the user can size them individually?

Is it possible to reorder layers with drag and drop? Parenting and unparenting layers works; but it is trial and error.

Can I change the colors locally somehow? I don't know much about gtk and wxwidgets.

Ok, hiding via the checkbox works now. Drag and drop seems to work to, but I can't tell where I am dropping a node (above, below or on it). The highlight needs to colored more clearly.

Maybe drag the child onto the parent to unparent (make a sibling)?

Did you take the golden cup on the floor in front of the sofa in the library? I think I gave this one the special property of being noticed when missing. I don't remember the details (maybe I should take a look), but this might be the cause of that problem.

I would like the possibilty of having the properties window be a separate, temporary window. Preferably each subtab could have its own window so it can be sized and placed individually. The information that is displayed (Entity dictionary, media browser, texture view etc.) is not needed most of the time, but when you shrink them to save screen space they are hard to work with. The idea is to quickly open them with a key press, do the work then close them with another key press. I also would like an option to switch the search on key press off that some windows use. It disrupts my workflow by preventing keyboard shortcuts (which I use very often). Thank you for your continuing work on this, by the way. It's much appreciated.

I much prefer the old behaviour of opening the media browser or entity view in a temporary window. This way you can make them comfortably large and they dont't waste screen space when you don't need them (which is most of the time). Mostly yes. But it is still a problem. You cannot quickly switch to the media browser and then back to another view. I think this behaviour of capturing keys and stop shortcuts to work as expected is bad. If it's not to difficult to implement, I would say ditch the automatic search on keypress.

I'm running linux; darkradiant compiled from source (most recent commit of master). In the 'Regular' and 'RegularLeft' window layouts keyboard input doesn't work at all. Some windows (console or media browser) don't open. The layer dialog does not work as supposed. I can't assign a parent layer by drag and drop. Hiding through the checkboxes does nothing. Everything else seems to work. Maybe not a bug: When the media browser is shown (or some other window with a search function) the search field captures keypresses. Which is really, really annoying and disruptive.

Thank you. I am mainly concerned about the grouping of portals and their shape. What happens if i deviate from the basic brush shape (90° angles) or when i join portals of different sizes instead of using one big portal to fit? Can that cause issues?

A question for anyone that has some insight into the inner workings of the current version of the engine: Will this setup of visportals cause me any kind of pain? Like path finding, sound propagation or performance issues?

I am enjoying this very much so far. It took me an evening to even get to the mansion. One tiny problem: you need to activate the "Open doors on unlock" option. Otherwise the elevator doesn't work correctly (the doors won't open)

Congratulations! What a surprise. I am looking forward to see what has become of this. Thanks to everyone involved in getting this done.

GUIs are fine to have, yes. I was just saying that not everybody needs them. They can make your life much more difficult if you try to use them beyond the functionality they expose.