News | Forum | People | FAQ | Links | Search | Register | Log in
The NetRadiant Level Editor
NetRadiant-custom is continuation of NetRadiant, based on GTKRadiant, which supports numerous games, with some emphasis on Quake.

win32 build
win64 build

Simple install instructions are included in q1pack\q1pack.txt
First | Previous | Next | Last
It sounds like a bit a faff then if the model loader is only set up to read one frame. I know a bit about the .mdl frame format and yes they did complicate it with frame groups.

It's probably not worth the effort then for now.

Here's another thing I found whilst messing around with misc_model...

in the editor, I orient the model by setting "angles" until it looks good.

In the Quake engine though, "angles" is treated differently, and the model is oriented differently in game to how it appears in the editor.

The difference is how NetRadiant seems to treat the x value of the angles vector, compared to how Quake treats it...

They seem to be reversed with respect to each other. This is best illustrated with a picture, so....

This sign discrepancy only appears on the x value of angles, the y and z are treated the same in the editor vs in quake.

The current workaround is to set the angles visually in NetRadiant, getting it to "look" correct, but then before saving, I just reverse the sign of the x value. This fixes it in game, but it just adds another layer of fiddliness to everything. 
Thats No Good Lol 
This is so-called 'stupid quake bug'
Orienting model is much simpler via rotation manipulator
ad_quake misc_model definition: angles: "pitch roll yaw"; actually is pitch yaw roll :) 
A very small/minor feature request. The pointfile that Q1 compilers generate uses the extension .pts instead of .lin, so it would be nice if the Pointfile function in the editor searched for a .pts file as well if it can't find one with .lin. 
True. Does .pts uses same format, as .lin? 
Yes, when renaming the file it displays fine in Radiant. 
This is so-called 'stupid quake bug'

I think its more just a difference in how Quake 1 interprets angles_x versus radiant. I'm not saying radiant's wrong - I assume its treatment of angles conforms to how Quake 3 does it.

Orienting model is much simpler via rotation manipulator

Yep, that's what I am using.

ad_quake misc_model definition: angles: "pitch roll yaw"; actually is pitch yaw roll :)

Yes, although that's an unrelated issue I think.

I'll just check with the coders to see what Quake 1 is doing with angles vs Quake 3... 
It's not question of interpretation, but well-known pain-in-the-ass bug, making even more problems, than necessity to inverting pitch everywhere in engine.
Problem src is mathematical mistake in VecToAngles function;
Bug is present in q1, hl, q2 and possibly in q3 in some masked form, since function is still wrong there.
Need to sorta support that behavior in editor, it seems.
I'll look, if this is possible.
Is it problem only with misc_models, or some more entities use angles key? 
Yeah Sorry My Mistake 
I guess it is a bug with quake, not a "feature", heh.

Well, existing workaround is easy now that I know what's going on. However, it could make sense to support it in the editor, for future users who are not aware of the bug or don't want to mod it out in the quakeC.

I am not aware of any other entities it affects - I think misc_model is the only thing where you want to mess with angles_x and also see the model in the editor. 
Flipping And Grid Offset 
Hi, I've noticed a change in behaviour with the flip operation, from previous versions, that for me is undesirable.

In older versions of NetRadiant, when you flipped an object, it sort of mirrored it along a grid line, so the components still had the same grid relationship when flipped. I find that 90% of the time this is what I want.

Now, it makes it so the flipped object sits in the same space as the original, but typically this will just mean all the components of the flipped object are now sitting on the wrong grid, and it takes longer to re-position it.

See image here:

This is not a problem for simple objects, but with large complex structures, I find I have to spend more time shuffling it into the desired position.

Could I request either adopting the old behaviour again, or adding an option? 
Ok, i'll try to add snapping of transform origin specially for flip commands.
Atm there are two options to get old result, but behaving like that by default is likely to be better. 
Great, thanks for this :) 
Entity Def 
I noticed the Q1 entity definitions file contains some errors. The box size of the powerups is wrong, posing the risk of them falling out of the level. There also were some non-existing entities and missing spawnflags here and there. Apart from that, I was almost inclined to rewrite the entity descriptions, because the writing is inconsistent and in some places misleading, to say the least. Maybe I'll do it at some point.

If anyone is interested in a slightly updated version, you can grab it here
Nice one, numerous worthy commits there.
I do grab it for sure :) 
Found Another Error In The Def 
The spawnflag to have a light start switched off is 1, therefore the correct line in the definition must be:
<flag key="START_OFF" name="Start off" bit="0"/>

Btw, this thread should probably be renamed to "The Custom NetRadiant editor" since it's really only about this new version. 
Which Ironically Was Introduced By Myself 
Don't Look At Me 
I took my cues from you all in the General Abuse thread before compiling this into one list. Ironically, I still have never even used any Radiant. 
the default for all spawnflags should be zero. 
Qmaster: I meant the error was introduced by me, because the whole start_off part is missing in the def file that comes with the editor and I added it in the first place.

metl: It is. Just the way the def file works: bit=0 makes it spawnflags 1; bit=1 is spawnflags 2; bit=2 is spawnflags 4 and so on. 
Ah Ah 
i see. 

* doubleClick/Enter in Entity inspector Class list = convert entities
* ctrl during creating brush = cube brush
* m3: apply texture name and alignment to selected primitives
* ctrl + shift + m3/drag: project tex from face in tex clipboard to brushes(BP format) and curves[/list]

* on worldspawn entity create/convert to one do most expected move-selected-primitives-to-worldspawn
* convert point entity to group one = placeholder brush at origin + remove origin key
* convert group entity to point one: set origin key to contained primitives center
* fix uniform rotation operations for eclassmodel, miscmodel entities
* scale miscmodel entities uniformly
* added func_detail to world and detail filters
* region->set_xy: using active projection, not just xy one; is subtractive (no region off before applying)
* new brush prefab: icosahedron
* refactored CSGTool, improved Hollow::diagonal algorithm stability
* fix scaling for doom3 brush format
* Pointfile function: try to also load .pts leak line file (q1), if .lin isn't found
* snap transform origin for flip commands
* change light intensity save format from %f to %g to prevent .99999 on transforms
* support 'stupid quake bug' (invert pitch in angles)(generic and miscmodel ents)(cfg: entities="quake" in .game)
* clipper: place 1st and 2nd points far, 3rd near to ease 3 points clipping
* fixed q1 entity definitions (negke)
* changed surface inspector behavior from 'set whole texture projection' to 'set modified value' (makes sense for multiple surfaces selected)
* BP: surface inspector and Tex* binds scale texture by its axes, not world axes
* BP: fix rotation of tex projection with scale S != scale T
* BP: fix ruining nonregular tex projections by surface inspector (for example after fit/seamless/arbitrary projection)
* jump over tex projection scale = 0 case, while modifying one (AP and BP)
* fixed and improved normal finding in patch texture autocap algorithm
* removed axis cycling in patch cap texture; using autocap
* patch cap texture: project, using brush texture projection math of current mapformat to make it seamless with brushes by default
* Surface inspector->Project functions work for curves (in AP map format too)
* place created simple patch mesh not in middle of bbox, but on edge to make result more usable
* prefs-interface-layout-single scrollable toolbar
* tweaked Human Radaint GTK theme: toolbar pixmap separators, more compact toolbar
* Human Radiant Dark GTK theme
* new texture lock algorithm for BP map format, supporting any affine transformations
* more robust texture lock algorithm for AP map format, locking what is possible to; also improves seamless face2face tex paste function
* experimental fix of rendering scene and evaluating brush/patch representation TWICE on every transform (literally after every mouse move fraction) 
That's A Great Update! 
Thanks For The Update 
very happy to see lots of little fixes for things that bugged me in the past!

For me, the holy grail would still be a "one-click" method for rotating a texture to align with a given face edge, but it's still great to see the various little texturing improvements in this update. 
* doubleClick/Enter in Entity inspector Class list = convert entities
Hm, I always used that to turn world brushes into the specific group entity. Seemed more intuitive than the m2 menu for some reason.
While allowing group<->point conversion is neat in theory, for my purposes anyway, it's really a non-standard edge case thing that I'm not sure needed dedicated editor support. By "dedicated" I mean a way to actively do it, rather than simply accepting manually converted entities.

Not sure if this is actually the case, but earlier on it seemed like an increased UNDO queue size does not affect redo in the same way?!

I only just noticed the color/theme settings. Good stuff.

Minor feature idea: There's that option to make the clipper use caulk. Since in Q1 there is no "caulk" texture, there could be an extra checkbox to make the clipper use "skip" instead. Or maybe even one with a field where you can enter the name of any texture to be used when clipping. 
Or maybe even one with a field where you can enter the name of any texture to be used when clipping. 
"one-click" method for rotating a texture to align with a given face edge

Interface could be something like: select face, then (whilst holding a key combination) just click on/near one of the face edges, and it rotates the texture to line up with the edge. 
...maybe 4 different key combos to specify which side of the texture (top/bottom/left/right) butts up against the face edge. 
gland: do you have more of those small bugging things? I have huge list of ones, but probably ones, you noticed, are important/easy to fix.

doubleClick/Enter in Entity inspector Class list = convert entities
It was always possible to convert entites via typing in new classname key (but code didn't handle all cases correctly)
The purpose of converting is to avoid redoing entity keys
I added converting by rightclick in right click menu, but that is not too intuitive
Also Class list behavior for point entities was to create one in 0, 0, 0, which was quite confusing
That is why i changed that behavior; I can look, if it is possible to create group entities from world primitives instead of showing error msg, but can't tell, if this is possible in enough elegant manner-)

increased UNDO queue size does not affect redo in the same way?!
I'v just tried to increase 64->128 and it worked for redo too. May be you cleared redo sequence... i noticed it happening sometimes, when you start transform w/o accomplishing it.

make the clipper use "skip"
I'v just tried and it does it:)
cfg is>shader_caulk = "textures/skip"

align texture with a given face edge
this is work for uv editor for sure, since it's just a part of wished texture aligning possibilities ( + i don't quite imagine the math around this:)

I also investigated possibilities to support model frames, skins, plural textures from .bsp, when loaded, as model (i.e. things, missing for satisfying q1 support)
File formats don't look like very big issue, main problem is used hashed cache scheme for resources, where resource name is its unique identifier (hash)
That's why we can see only one of textures, having equal names and sitting in different wads (i also wonder, if texbro is nuff usable atm, i.e. with all loaded texs shown)
So supporting that kind of stuff would mean tweaking a lot of tricky code (which i do not understand very well) for namely all sorts of resources; That is likely more efficiently to focus on more generic things instead of this (except of texbro, if it's not fine, as it is) 
Same Name Group/point Entities 
Trying out some prog tricks with info_notnull and func_stuff but am been forced to choose between either point or group entity. No mixing basically. Is there a way around this? Reading above in the change notes about group point conversion etc.. But it makes no sense to me what this is or how to make it work. Any ideas? 
It's doable via some anal tricks atm:
create group entity
erase its primitives completely (for example via clipper tool)
now you'v got it shown at 0,0,0 and selectable via entity list
note: origin key must be set to get it saved to .map 
win32 build
win64 build (mainly for the sake of x64 q3map2, but also may improve smoothness, comparing to w10's VM + win32 build)

* shift + m3: apply texture name and alignment to selected primitives and faces (m3 was inconsistent + often required quite deep planning)
* ctrl + shift + m3: also project tex from face to selection


* entities converting: also create group entities from world primitives instead of "do not want to convert worldspawn entity" error
* fix: group dialog: prevent focusing on texbro->filter entry and console, if switching to ones by click on tabs (was blocking hotkeys)
* prefs->cam->Selected faces wireframe option (def = yes)
* Textured+Wireframe camera render mode
* render scene to FBO to get following options:
preferences->camera->MSAA (def = 8 samples)
preferences->orthographic->MSAA (def = 8 samples)
coloured camera POV icon w/o rerendering the scene
coloured rectangular selector box w/o rerendering the scene
* fallback to glCopyTexImage2D (NPoT), if FBO isn't available
* lazy cursor updates in clipper mode
* update cursor immediately on clipper mode toggles
* fixes and optimizations of entity names rendering; for instance: don't prerender textures for unneeded names
* selection system: fixes of: selecting point behind point (not perfectly precise distance)
selecting occluded objects and faces via direct and indirect hits
* select models from back in 2d
* entity inspector, entity list->'autofocus on selection' buttons: also do FocusAllViews() on clicking them
* focus on preferences treeview on 2nd+ call to make text search to work
* fixed WindowPositionTracker globally: minus many particular hacks, plus correct wnds positioning in Floating viewports layout
* fixed ToggleShown functionality: shown/hidden wnds states are saved and loaded correctly in Floating viewports layout
* also save/load XY and Cam viewports visibility states
* new preferences->layout icons
* fix: stop chaseMouseMotion on mouse button release 
Entity List 
Minor feature request for the entity list ("L"): it would be nice if it was possible to press any key while the entity list is open and selected to make it jump to the entities starting with the corresponding letter. A quicker way to select and edit specific entities than having to scroll through the whole list all the time - since Quake maps typically have hundreds of entities, with all kinds of different classnames and targetnames.

In addition to that there could be a related feature to switch between the list sorting/displaying entities by targetnames or classnames = in the latter case basically ignoring the targetname field of entity if it exists. 
Since QuakeOne Is Down... 
Anyone have info on setting up Q1 with this? Just bullet points would be great. THX! 
It doesn't need any setting up. Just run radiant.exe and point to quake exe.
Wad file and some editor models are included in q1pack folder/paste contents to id1.
Check out \games\ if you want to enable q3 brush primitives texture projection.

Unpack the binaries to sit alongside radiant.exe 
#107 / 108 
Thanks - all set and wow it's quite speedy. 
negke, i have both features in wishlist, though:
1.dilemma: that would break global hotkeys, when entity list would be focused (at least single character ones)
Any ideas on how bad would that be or about smart way to implement this?
2.i tried to make it to work for existing 'entity names = targetnames' option, but that appears to require quite deep research -) Basically editor crashes after any edit towards to that
It's using complicated code to update only required parts of treemodel, but not the whole one after every sneeze
We'll see what is possible to

Remark about 'floating viewports layout': i tried 4 different(sic!) options to achieve correct windows priorities, but every one just spawns extra issues/is imperfect; mainly because GTK performs some unwanted job, when i try something hacky
The most legit way is used in GIMP, it seems: with it main wnd and viewports would be separate toplevels; the rest wnds would be WINDOW_TYPE_HINT_UTILITY; then WM (at least on ms windows) would care of keeping them on top
Issues with this: main wnd can be on top of viewports and dirty implementation in general.
negke, what is your use of this layout?
Probably i can make regular (built-in viewports) layout enough configurable to satisfy respective needs

ww: no any setting up is required, but still required xD Though, all two simple things are listed in q1pack.txt
Also: editor supports valve220 format almost well; i only found two broken functions in surface inspector 
Perhaps global hotkeys could be disabled when the entity list window is focused? Though I don't know if this creates any repercussions elsewhere or with the other layouts. (*)
Alternatively, a small text search field at the bottom of the window (next to "auto-focus") could work as well. It'd be one click more but still faster than scrolling. A search performed automatically with each input (=no confirmation required).

The way I use the floating layout, and the reason I prefer it over the others, is basically having each of the three main windows (almost) maximized, minus the menus and status bar of the main window, all cascaded. pic This way I can easily switch to the window I need while always having them fill most of the screen without needing to resize them all the time. I dislike working with small camera/2D views that the fixed layouts have, because I feel like they impede my (over)view
The downside of the floating layout is that sometimes the focus get messed up, usually when clicking outside the editor. I can live with it. (*) Only in some cases it gets annoying: when small windows like rotate/map info/surface inspector and map list (though it doesn't usually happen to me with the latter two due to the position i keep them in) accidentally lose focus and end up behind all other windows effectively blocking further actions everywhere while at the same time being unable to close them again with the shortcut key. 
I see quite a few single char hotkeys, usable in the entity list: I, H, L, Z, C, N; So that should be text search field it seems (can be auto focusable on mouse hover, like texbro's one).

Ic your way of using the layout; Once i was trying to use similar cfg with cam + 3 ortho windows -)
There was idea for regular (embedded viewports) layout, which may work for you: autoenlarging views on mouse pointing; Splits' positions should be configurable normally, just keeping own values for every quarter.
Do you think, that this will do the job?

As for focus, it's not focus, but wnds z order, which gtk is messing up.
Named dialogs can be closed by hotkeys actually: rotate - esc, map info - space/enter/alt+f4, surface inspector - s (or esc, s), entity list - l 
Autoenlarging, I don't know. Would have to see a prototype to be sure. It sounds possible, but I can't say for sure how easily I could adapt or accept it if it's too much of a change. Certainly sounds like neat feature (if not too complicated to add) that could just become a fourth layout option while keeping the floating layout despite its gtk limitations. 
I have a fairly annoying issue of my own, where the camera jolts several degrees at a time, even when I turn it slowly. For some reason, it happens only after I select an object or I create a brush.

Using Windows 10. The old March 2012 version doesn't have the problem but Ingar's most recent build (June 2015) also has this problem. Why is that so? 
This could be significant, he seems to have the same problem as me but on Linux: 
Well, I found a band-aid to my problem. It doesn't actually resolve the problem but it makes the editor not annoying again. Leaving the DPI scaling to the application instead of the system somehow fixes the camera despite changing nothing else (my system is already at normal scaling).

I can finally get back into mapping but it still feels weird that this is happening. 
Good find! Still judders now n then, but way less often. 
Thanks, quite worthy note about 2012 vs 2015 builds.
Basically comment on github is right, and the difference between these two builds is exactly that fix for touchpad on linux.
I'll consider reverting that commit back, since it's producing more harm, then use (mapping via non apple touchpad is the heck anyway (imo)) 
Does this have a MAC build somewhere? If so a mod should add it to the main post. 
It got no mac build, but build system allows to make one 
Some tip on requested 'align texture with given face edge' feature here: 
I'm Amazed At How Fast You Built This! 
Map Text Encoding 
Some quirk I (or ericw, for that matter) discovered: apparently this version of Radiant saves the .map files in UTF-8 enconding which is probably fine most of the time, but can cause issues in specific cases.

In Quake, there are some special characters used for colored text and symbols that can be used in level/player names and centerprint messages. x. The problem is that the file encoding appears to be incompatible with the compilers, so these characters get all messed up in the compiled BSP and are displayed incorrectly in game. Converting the map to some other format like ISO8859-1 or even ANSI solves the problem and subsequent editing in Custom Netradiant won't change the encoding back.
In Radiant 1.5, message fields with those special characters would be garbled and trying to edit the corresponding entities could even lead to a crash. In Netradiant, the message fields are displayed correctly - except after converting to ANSI, they show placeholder characters, which isn't a problem, in my view.

This is not a big issue, and I'm not even sure something should be done about it, especially if there's a risk something else breaks in the process. At any rate, it's a little heads-up for people to know in case they run into the same issue. 
What i see, is that GtkEntry handles these chars as UTF ones, and then radiant saves them correctly (not the whole .map, but only respective string)
I think that compilers do nothing with them too, so you end up with UTF chars in your bsp (which aren't understood by engine apparently)
I barely could find an application, which was truncating such strings in wished manner (they either show UTF one, or '?' char) 
Texture Alignment - Face Projection? 
Is there a way to align a texture to a face instead of to the grid? I have a sloped surface 30-degrees from xy-plane, and then 45-degrees around z-axis. I cannot seem to get the texture to project to the face, only the grid, meaning I cannot really get a non-slanted texture alignment. I can post a picture if I am unclear. 
Does NetRadiant support the "Valve 220" map format? 
Yes, you can get it non-slanted in this particular case (i'v got it by rotating a brush with texture lock enabled), but not every time, because default q1 map format is 'axial projection', which has quite strong limitations.
There is newer format from q3: 'brush primitives', which is face projection by definition and has no limitations (you can get axial or w/e projection with it); It is enableable via and is supported by modern ericwa's compilers.
Valve 220 format is almost supported except of a few malfunctioning tools in Surface inspector;
The plan is to make these 3 formats switchable via preferences for most of games and convertible to unlimited ones.
Probably video explanation of various texture projections in mapformats could be useful? 
Thanks For The Info! 
Is there any way to convert quake brushes to quake3 brushes? 
Outside Of Radiant.. 
v0.15.10 of my qbsp ( ) has a map converter built in. you can use it from the command line like this:
qbsp -convert bp
will convert to Q3 brush primitives (iirc it writes the output to a file called 
You guys are awesome, thanks! 
Great to see this is still improving! I can smell my mapping trousers warming up... 
Valve220 map format has arrived btw .) 
The Link Is Dead 
You read about how to setup Radiant here: quakeone forum

Is there a backup?
Also, does this work on Windows 10? 
That was odd tutorial anyway (was considering classic radiants)
netradiant-custom\q1pack\q1pack.txt is enough to setup; 1st post got to be updated

Also yes, it does work on Windows 10. 
Yeah, apparently all the links are dead except for the Radiant direct download. 
Very Nice 
Just wondered if it's possible to make the free rotate tool (R) use some (customizable) fixed value like Step in the surface inspector, e.g. steps of 5 or 15 degrees - as quicker way of doing 'conservative' rotations than the Arbitrary Rotation window. 
Snap Rotate 
you can hold shift after grabbing the rings to snap at 15 degrees 
It's good. 
Quake 1 Wad Path 
Hi, is there a way to specify a custom folder for my wad files (i.e. somewhere other than [enginepath]/id1)

This is for the editor (not the compiler - I'm already aware of the bsp compiler wadpath switch)

I prefer to keep my "game" files separate to my "development" files where possible. 
Hey, i think this was asked and replied:
Just change base directory to use
Or configure, as for mod, and use its directory for wads
Or just make separate fresh install for mapping
Numerous possibilities kinda 

So, is this basegame field only used to tell the editor where to find the wad files? It's not used for anything else? 
It's used for anything, which is normally loaded from id1
Also is used for build menu variables
We'v just figured out, that it also loads
Users\Username\Documents\My Games\q3a\ (q3a is cfged by .game: prefix=".q3a")

I think it's a good idea to add option to load one more specific directory, once it's supported in q1 and q3 compilers 
I See 
To be honest I think it would be a really useful feature for netradiant to have a "wad path" option, that can be an absolute path, totally independent to anything else. 
Another Question 
Using netradiant's build menu, is it possible to specify an output directory for the bsp that's different to the directory of the map file? 
It's up to compiler, radiant does nothing with .bsp 
Ah Ok 
yeah the compiler will chuck the .bsp in the same folder as the .map when fed the commands as generated by the netradiant build menu. 
Build menu commands can be configured accordingly, if compiler supports saving bsp to arbitrary path. 
Build menu commands can be configured accordingly, if compiler supports saving bsp to arbitrary path.

OK I've just messed around with the build menu xml file and I appear to have got it configured how I want now, cheers. 
Late To The Party 
#121 posted by niger [] on 2017/08/02 19:26:48
Some tip on requested 'align texture with given face edge' feature here:

When he got to the bit here:

And started aligning the arch textures by making them "flow" seamlessly over from the top faces with the texture paste shortcut...I won't lie, I did a little sex wee. 
that's awesome, wish I knew this sooner. 
Clear All 
About the "Clear all" button in the entity tab: probably not getting that much use overall, although I do use it every so often. However, in its current form it only works on brush entities - using it on point entities causes problems, because it removes the origin field. Can this be changed so that the origin field is kept if the button is used on a point entity? 
Sounds like making sense from the first look.
Don't other means replace wished behavior well? (del key to del unwanted keys or save origin in key/val fields, then restore) 
Netradiant And Windows Aero 
specifically aero glass which is disabled while netradiant is open. Anyone know why this is/has a solution? 
netradiant-custom shouldn't disable aero, unless you put -aero command line parameter 
That is one spicey changelog!

Will give it a spin this evening :) 
google says it's a thing, though not very common... still can't find a solution though. must be my system. 
-I recall internet topics about windows, disabling aero for applications sometimes; there was a solution too; reason to disable was wrongly detected low performance iirc
-There is a way to disable aero via compatibility settings of windows application
-Normal Netradiant is disabling aero to fix rendering issue; Custom one does not, since it's fixed (are you speaking about custom one?) 
are you speaking about custom one?

Occurs with both Ingar's package and this custom one. I haven't tested others. I'm sure it's my system, I just haven't investigated it very deeply. 
Cmdline 724 951 90

to match in game and cam window 
Rariant/Aero Update 
The issue doesn't occur when using an old gpu and legacy nvidia drivers. Tinkering with latest drivers has proven futile so far... 
Clipper and brush creation, working in camera, among other things. 
NetRadiant: TrenchBroom Edition 
Nice! Will give this a whirl :) 
In my previous version I could select serveral brushes with shift and left mouse button. How it worked now? 
I Already Figured It Out. 
Another question. I now move and highlight the brushes with the right mouse button. This creates complexity, because if I accidentally clicked the right mouse button with CTRL, then all the surfaces that were highlighted are canceled and only one is selected. Can I somehow disable a selection of CTRL + right mouse button? Now the selection works as a left button and this is enough 
ctrl + m2 is tunnel face selector, allows selection of face behind face and to avoid hitting 'deselect' all the way.
It's not optional.
This is expected problem, when adding new actions to combinations, which were doing nothing before; afaik it's not too costly to get used to.
Mouse shortcuts are documented btw, help->mouse shortcuts. 
Yes, I'm just used to navigating with m2 and Ctrl + m2. Therefore, I accidentally select something. I hope that I will get used to it. Thank you 
For the future (if possible): please add to the map info the number of clip brushes.

Now I do map for 100brushes, and can't see, how many clip brushes I have 
Ic; m2 alone does navigation in Ctrl + m2 style atm.
Hopefully this solves the problem. 
Yes, But Not Yet Customary :) 
I will be retrain 
Clip Brushes Info 
is quite specific.
I think about 'show selected objs count in statusbar, when selected; total when not'
Atm you can use 'm3 on clip face, shift+a, i, z' combo to get this info. 
Wow! Cool ))) 
Regroup Entity 
Did you break or change the former regroup (now "move pritimives to entity") function in the latest WIP build? Originally I would select the brush entity with shift+a, then the world brush and hit regroup in order to add the brush(es) to the entity, but this doesn't seem to work anymore?! 
Old one had some bug so was replaced. Now you select brush, select entity and link. 
Regroup is replaced by 'move primitives to last selected entity', requiring no shift+e and determining target entity by ultimate selected primitive.
Also EntityMovePrimitivesToFirst command is added to be used, if old logic feels more convenient.
Entity menu->worldspawn does 'ungroup selected primitives'.
Entity menu->worldspawn rmb does 'ungroup whole entities'. 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.