I tend to explain ideas elliptically / badly.

you mean hiding them from the view? Yes, but this would mean making the entity inspector powerful enough so that it wouldn't be necessary. The complex logic systems usually needed for set pieces in a map aren't helped by having the various entities visible in 3D space. There are much nicer systems that logic tree front ends but that'd be a lot of work to include.

More than anything this would be a new layer of interface.

By "edit entity pane" you mean the entity inspector?
Yes.

what do you mean by "showing physical entities" there?

Anything that is only logic wouldn't be visible, but other entities, for example "monster_thing" would be visible as well.

So a setup of:

monster_thing
monster_thing
monster_thing
+
trigger_counter
=
func_door

would have the door and monsters visible in 3D but not the trigger counter. All however would be shown in the entity inspector.

All of this is kind of dancing around the feature I'm suggesting though, which is referred to as a Visual Scripting Editor.

There are many different implementations of this, from very simple to extremely complex. Having a Quake version would be yet another evolutionary leap.

Ideas like the WC Entity Report or even the original id1 path system eventually evolved into Visual Scripting Editors.

Which are just more intuitive or user friendly ways of setting up level logic.

What I've written here is so open ended it could take years of work, whereas a more elegant and direct solution could provide the same functionality and take half a day. I need to get into the guts of the editor more to make more feasible suggestions. Converting over my current stuff should provide that though :) 

Now I understand what you want. We should discuss this more when the other, more essential features have been implemented. 

Lower priority. 

If it can be done without, that's great. However I find myself using the arrow keys more and more. The question to me is whether a slower and more calculated approach will save time in the end over a loose approach that requires more moves to complete. The current approach requires to switch the view constantly to get into a decent position to move stuff. I used to do sub-d modeling in Silo where pressing crtl will let you move vertices around parallel to the viewport. That's highly intuitive, but over time I found myself evolving to the 'slower' method of doing per axis movement since I didn't need to rotate the view constantly in order to get precise tweaks. So, I personally often prefer to take the ugly and slow 'long shortcut'... mileage might vary 

Are you getting an error from the compiler or from the GUI frontend ? The compiler should definitely support this. 

So, I'm just saying, if you can find something that keeps things as simple and straightforward as they are now, it's win-win. But I just feel more precise movement would save me a lot of time in the end, and I'm skeptical a non-gizmo thing can do that. They've been in virtually all 3D packages for almost 2 decades now which should account for something. But at the same time I would honestly love to be proven wrong. 

I get an error from the command line when I run the compiler and the BSP fails to run. (error code 01) 

For me, the best thing about gizmos is it means you can securely move an object in any direction without having to get the camera view in a better position, and more importantly you don't have to keep holding different keys on the keyboard. 

So, I'm just saying, if you can find something that keeps things as simple and straightforward as they are now, it's win-win. But I just feel more precise movement would save me a lot of time in the end, and I'm skeptical a non-gizmo thing can do that. They've been in virtually all 3D packages for almost 2 decades now which should account for something. But at the same time I would honestly love to be proven wrong. 

 

 

You refreshed the page. Your browser sucks. 

Can mean whatever its perceived as.

The task requirement is 'tool that allows precision movement along specified axis'.

Doesn't exactly roll off the tongue though. 

 

 

Changes
- Improved Quake.fgd and Quoth2.fgd (thanks negke!).
- Improvements to clipboard pasting.
- Fixed a crash bug when loading maps with invalid brushes. 

I saw this in the notes for 1.0.3 and wanted to say that:

"Objects are no longer displaced when duplicated"

This is still offsetting duplicated things for me. Do I need to clear a config file or something? I checked the About box and it said 1.0.3 ... 

Same with 1.0.4 ... heh.

Am I interpreting that correctly as saying ctrl+d shouldn't be offsetting anymore? 

I think it *should* displace but should only displace one grid block toward you. 

Displacing sucks. :) We've talked about it already but every time it displaces my duplicate, I have to move it back into place before working with it. It's almost never what you want... 

I made an error, the displacement will be gone in 1.1. Sorry! 

Heh, no worries! Thanks... 

I just realised that CTRL+D displaces by a small amount rather than the huge amounts that Copy and Paste are doing... I've wasted so much time (also, if you're duping brushes you're moving it somewhere else, plus it's better that it displaces so that you don't accidentally dupe multiple times without noticing). 

You'd think that, logically, but my experience says otherwise. Over time it becomes far easier to dupe in place and then move it since at least one of the axis that it got bumped on is going to be wrong. 

yeah, that is my experience with it also. I almost always follow a Ctrl+D with a Up and Left to push the brush back to the original spot.