News | Forum | People | FAQ | Links | Search | Register | Log in
The NetRadiant Level Editor
NetRadiant has been around a long time but there are some who do not know how to set it up for Quake 1 mapping. Based on GTKRadiant which has supported numerous games and was originally based on QuakeED.

Direct Download: netradiant-custom.7z
Quake 1 Gamepack: Quake1Pack.zip
Quake 1 Build Menu:quake1buildmenu.xml

You read about how to setup Radiant here: quakeone forum
You can read more about the recent changes here: q3df forum

Tutorial Video(not specifically for Quake):Basic Netradiant Tutorial: Part 1
 
That new NetRadiant is a pro-click btw, for anyone still stuck on the 2012 version. Fixes loads of stuff and runs a lot better! (the 2012 version hogged my cpu when flying around in the 3d view for some reason) 
Not Sure This Thread Is Necessary 
Also somewhat misleading since this is actually about the recently modified "custom" version which is a fork of the original Netradiant. The later seems to have gotten at least a little attention by Ingar up to 2015.

Having said that, this new version does look nice and has the floating windows layout working/fixed - something which the other developers/maintainers seem to have been incapable of doing.

How does one bring back the classic (shift+drag type) selection box? 
I Use Ingar's Version 
Gonna give this a shot. 
 
Yeah really digging the new bits here and there in this version. Problem is, to find out what's new, you have to read through an eleven page thread. 
 
you can read the changes in changelog-custom, new mouse shortcuts are documented too. 
 
One thing I really like in Netradiant is the ability to just click in the 3D window and move around in the map as if in Quake using noclip. I can use the mouse and arrow keys exactly the same way as I do in game. I hope that hasn't been changed. 
 
you can read the changes in changelog-custom

Lol, oh right :} Chalk me up as another one of those fellas who always misses the readme file...

Rick: 3D window movements are the same as before, and for me it runs silky smooth now (before it was a bit chuggy for some reason). Only crit is that the FOV is locked to 110 (before it was 90), but I have requested the FOV to be exposed in preferences in the q3df thread (my username is SlugWobblerBumbleChops). 
Does This 
have a Mac version? 
Pro Tip 
About where the custom settings are stored, because bugger me it took me a while to figure this out.

If you create a subdirectory called "settings" in your NetRadiant install, the install becomes "portable", that means it'll write its settings there. If you don't do this, it will write its settings in some bullshit random directory like C:/Users/ben/AppData/Roaming/....blah blah blah....

E.g. on my pc, my "portable" settings folder would be:
C:/NetRadiant/netradiant-custom/netradiant-custom-20160911/settings

Now I *think* the new NetRadiant comes with a portable settings folder by default. Old NetRadiants certainly did not though. Check yours to make sure! 
 
Anyone by chance registered at the q3df forum?

Three things about the Custom Radiant: it crashes if the mouse is locked in camera freelook mode when the camera window/Radiant is moved to the background by some other program taking priority on screen. Floating window layout, but probably occurs with the other modes, too.

There's still (or again?) that feature from 1.5 that adds numbers to the target/targetnames of copied/cloned entities. Always hated that as it does more harm than good. Used to be removed in NetRadiant. I wish it was disabled or at least had a field to customize it where you can choose whether to have it append numbers, letters, any kind of string, or leave the field empty to keep the original names.

When rotating entities with the 90� buttons, it adds 0.000003 instead of "0". 
Hi 
How do i reproduce that crash exactly?
Was there 'freezepointer: can't freeze' assertion?
There is focusout handler, that disables freelook, once app is focused out and it works well in all 1.5 branch radiants.
XYwnds have that handler too, but one never worked in nonfloating layout, untill i accidentally fixed that by adding some focus-in events -) (in 9.11 release)
Texbro has no such handler atm, thus it's possible to alt+tab, while tracking (m2), and still keep tracking, once switched back; though is unlikely to get crash here, since tracking is done in widget's center

2.Need some more extended data on this, since i can get both types of behavior in all 1.5 branch radiants
What do you do, in what version used to be removed...

3.Is not real problem. Might think of adding some rounding to int later (for gloss) 
 
I haven't found a reliable way to reproduce the error, yet (although it did occur several times since). Radiant.log doesn't show anything, and there's no error message by Radiant, either (only the standard Windows thing "The application has stopped working").
What sometimes seemed to trigger it is switching to the MP3 player (VLC in this case) with alt+tab or win+tab while mouselook mode is active. Upon switching back, the camera window is behind the 2d and entities windows and mouselook is still active for a brief moment before the error. At other times, it works.

I'll report back here if I have more information.

Target/targetnames: afaik the name change upon copying/cloning entities were introduced in Gtkradiant 1.5 and it was removed in Netradiant (Yngar branch).
I like to keep track of the entity linking myself and adjust it accordingly. When making single player maps, often multiple entities are targeted at once, all with the same targetname; or, when scipting entities, e.g. a chain of triggers or waypoints, it's really annoying if the editor constantly screws up the numbers.


Some other things:

There's an error when using doubleclick on a texture in the texture window:
radiant/texwindow.cpp:785
assertion failure: pointer "archive" is null

Obviously standard Q1 editing, so there are directories or shader lists.

When zooming in and out repeatedly with alt+mouse2, the focal point changes. It doesn't stay at where the mouse arrow was when starting the action.

Dragging the horizontal borders in the entities window, the ones between the entity list/description/keys, is wonky. They appear to be somewhat linked and can't be moved independent of one another in order to enlarge a section without affecting the other.

File menus (open, save, ...) and preferences should be always on top until closed - currently, they can get behind the other windows.

Three ideas: when using ctrl+mouse1 clipper, it would be nice if the clipping could also be executed with mouse3. This way, one could do fast clippings without having to lift the hand off the mouse to reach the enter key.

I noticed that the outer grid coordinates in the 2D window are gone. Can't think of the correct word right now - you know, where it says 0...1024...2048... on the sides. I found them useful, especially since Q1 has restrictions when it comes to map boundaries.

Would it be possible to allow the editor to accept multiple entity types with the same classname in the def file? For example, "trigger_multiple" as both brush and point entity coexisting at the same time. In the other versions of Radiant, there could be only one; the other type would disappear from 2D/3D view.


By the way, I really appreciate your work on this. I had already given up hope of ever seeing useful development on a Radiant-type editor again. Many nice additions/changes on top of Win10 support. Good job! 
Correction 
Standard Q1 editing, so there are *no* directories or shaders. Only texture wads. 
Windows Error Log 
Source
radiant.exe

Summary
Stopped working

Date
10/15/2016 11:44 AM

Status
Report sent

Description
Faulting Application Path: D:\Netradiant-custom\radiant.exe

Problem signature
Problem Event Name: APPCRASH
Application Name: radiant.exe
Application Version: 0.0.0.0
Application Timestamp: 57d5aedb
Fault Module Name: libgtk-win32-2.0-0.dll
Fault Module Version: 2.24.29.0
Fault Module Timestamp: 5691a1e1
Exception Code: c0000005
Exception Offset: 001e50c2
OS Version: 10.0.14393.2.0.0.256.48
Locale ID: 1033
Additional Information 1: 2beb
Additional Information 2: 2beba6fb4680d73a8c78ca7c24ccdb46
Additional Information 3: 34b8
Additional Information 4: 34b85e01dbe9529312a819250a584bb2

Extra information about the problem
Bucket ID: 66f1dc540daf84cedf9a668c638cfbfd (108433453934)
 
 
>>mouselook is still active for a brief moment before the error
Is not healthy, must autoquit freelook on unfocusing
Idk what to start with... best errors are reproducible ones, so you can trigger them, while running in debugger, and see, what exactly happens
Exception Code: c0000005 is very common case, access violation
May be it's not random (can be actually) and is related to some circumstances?
For instance, i'v recently spotted crash on releasing m2 in texbro w/o pressing one b4


Target/targetnames: it is option in 1.4/1.6: prefs-editing-fix target/targetname collisions; def = yes
Is not optional in 1.5/net (always yes)
It only fixes collisions .) Doesn't on clone though. Does on clone-make-unique, on copy/paste.

Ingar's quote: I did not write GtkRadiant or NetRadiant. While I do commit patches, I mostly download the source code, build executables and add documentation and game packs. My goal is to provide a package that is easy to install for anyone who might need it.

>>There's an error when using doubleclick on a texture in the texture window
Is fixed in wip version

>>When zooming in and out repeatedly with alt+mouse2, the focal point changes.
That is bc 'zoom in to mouse pointer' option is on + zoom out does it from center, not pointer
Might do zooming out from pointer too, though i see the only reason to do so (named by you); would be more consistent in general; On the other hand such kind of zooming out doesn't feel natural + it is hard to understand, how to get wanted specific effect, while using one (or it's just me-)

>>Dragging the horizontal borders in the entities window, the ones between the entity list/description/keys, is wonky. They appear to be somewhat linked and can't be moved independent of one another in order to enlarge a section without affecting the other.
Well, those aren't some abstract splits; Those are container widgets, splitting area in two
So, wnd is split in two areas by central one + both resulting areas are split too
It's made linked on purpose, so that all areas were scaling consistently along with containing window (for free)
It is possible to make artificial handler for scaling + make splits unlinked, but that would require quite some investigation + might be risky
For instance, 4 views layout was broken due to using such handler
You can adjust splits just fine now, once start doing that from central one
I like, how it behaves now btw, sorta rubber thing -)

>>File menus (open, save, ...) and preferences should be always on top until closed - currently, they can get behind the other windows.
That appears to be general gtk architecture flaw; Basically it has setting to keep some wnd on top of the other wnd
So all floating wnds are set to be on top of main wnd (and it works almost fine in non floating layouts :p)
I havent been able to google any solution for this... would need something like 'set transient for group of wnds' setting (there is no one, afaik)
Perhaps, can invent some dirty hacks to achieve this; though floating layout isn't the most developed one; luckily it works at least, h3h3
I'v tried really big gtk apps: gimp and inkscape; both have named issue (even though gtk stands for Gimp ToolKit-)

>>it would be nice if the clipping could also be executed with mouse3
M3 would be quite out-of-structure and very specific one tbh (and breaking cam control)
Ic that double click can be used there (since no action, when you click existing point)
Atm you can use right ctrl and enter for efficiency :)

>>I noticed that the outer grid coordinates in the 2D window are gone.
View->show->coordinates
Defaulted 'off', bc aren't too useful for most of games (paint sizing info does the job just fine)

>>Would it be possible to allow the editor to accept multiple entity types with the same classname in the def file?
That is quite a LOT of things to rewrite :X (not sure, if i can handle that even)
In 1.5 branch you can obtain group entities w/o contained primitives
No many ways to do that left in my branch (atm can do via removing whole brush with clipper and then can control via origin key) + there is recent fix to not to save such ones, bc it is a buggy behavior in general: q3, for instance, refuses to load bsps, containing group ents w/o submodel.
What is this behavior needed for? (something like triggers, defined via min/max?) What editors support that? 
 
- We'll see if I can properly reproduce the error at some point. The only circumstance I'm currently aware of is switching haphazardly between applications.

- Yes, not Ingar; Divverent is the one I meant. I was under the impression it was disabled completely there, not just for cloning. At any rate, it's an improvement over 1.5.

- Multiple types: in Quake (1) certain entities can exist as both point and group entities, for example triggers that have a big touchable volume or triggers that touch only at a single point. Sometimes it's preferable to have them point entities for scripted sequences or to optimize a map towards engine limits. Another example is map hacks where it's also possible to use info_notnull to create custom items/monsters (point) or brush-based things like trigger volumes/doors (group).


Is it intentional behavior that in camera mouselook mode shift+mouse2 selects brushes or entities? I lost quite a few intricate selections by accident because of that... 
 
- an improvement over 1.5.
Indeed, just rechecked 1.5's behavior; was sure, that it had ability to preserve names. Is quite inconvenient to have no one -)

- Multiple types: atm entity system in radiant is name based, i.e. specific classname must have unique name.
Ic some thirdparty solution
using different classnames for special entities
then batch compilation like:
sed -e 's/oldstuff/newstuff/g' inputFileName > outputFileName
compile outputFileName

- shift+mouse2 = tunnel objects selector in all modes
Were you trying to quit freelook with shift+m2? :-) 
 
Just selecting multiple brushes, then trying to move the view in order to select some more, but too slow at releasing shift before pressing m2... 
 
The more power you have, the more control you need -)
Though condition for shift+m2 click/drag selectors is releasing m2, while shift is down.
(+exactly zero move for click and quite big one for drag) 
Update 
https://goo.gl/UyXRUJ

binds...

* ctrl + shift + v: MoveToCamera (translate selection to camera origin)
* m2 in entities creation menu: change classname; ctrl + m2: change classname, don't close menu
* ctrl + m1 in entities creation menu: create entity, don't close menu (+offset every next entity by 8u or gridsize, if > 8)
* m1x2 on clipper point = do clip

menus...

* Shortcuts item moved from Help to Edit
* misc->colors->opengl font selector

misc...

* do not delete selected on entities creation, just deselect
* ExpandSelectionToEntities: do not select invisible nodes
* fix: snap translation amount on paste/move to camera commands instead of stuff's origin (to keep one with size (2*N + 1)*gridSize on grid)
* MapName build system variable (can use to make build menu entry to run map in a game)
* build->customize: list available build variables
* texture browser: gtk search in directories and tags trees
* fix: build menu->customize Cancel button cancels (was reloading menu from disk)
* build menu->customize Reset button (= reload menu from disk = editor start state)
* fix: laggy selectors, manipulators in mlook mode
* scale free->snapped mode: constrain to two axes, most perpendicular to view direction (i.e. works for two axes in 3d too)
* scale free->snapped mode: use min move delta for scale (was max = hard to scale down); fix ZY projection case
* fix: pointfile was considered as shown, when trying to load missing one
* entity inspector->EntityProperties treeview: Tab keypress = focus Key field
* 2x2 layout: allow gtk to handle separators positions; fixes: unmaximize wnd, maximize = horizontal separators > center
fixes: unmaximize wnd = not updated views glwidget positions on some systems
* fix: paint selector, selecting occluded faces
* camera->field of view option
* wider Texture Gamma preference range
* wad games->texbro treeview: do not group names, using underscore; fixes crash on loading parent; fixes mess if path contains underscore
* fix: do not quit freelook on autosaving
* entity creation menu has ability to be 'tearoff'
* wad games: fix TextureBrowser_ShowDirectory crash on loading common dir (can cfg to load .wad), on loading containing dir (do nothing)
* wad games: fix crash on selecting a shader (not a plain texture) in tex bro
* wad games: more reliable filterbar texturing defaults
* shader for 'caulk new brushes' and 'clipper uses caulk' options is optional via 'shader_caulk' option in .game
* fix: q1 mdl reader out of bounds reading crash
* fix: q1 mdl loading of MDL_FRAME_GROUP case
* fix: rightclick main wnd border, release in texbro glwidget == crash (unfreezepointer)
* texbro: search in currently shown textures
* ask for saving nonsaved map on project settings change
* func_detail to nongame group ents counter
* deiconify main wnd, unmaximize maximized view on app closing to save correct layout data
* close preferences dialog on ESC
* Enter = Ok in global and path settings dialogs
* print renderer stats in XY views too
* global 'show renderer stats' option, def = off
* ~10x faster opengl text rendering
* calculate farplane from g_MaxWorldCoord, g_MinWorldCoord (was const 32768)
* 1.0f nearplane
* numerous code fixes
* texbro search: SearchFromStart option (match start of texture name)
* texbro search: entry is activated/deactivated by mouse pointing
* texbro search: clear button
* renewed q1 gamepack ( by w_w )



Some questionable idea is to remember last action of clipper (clip or split) and use it while triggering action via m1x2 (can confuse...)

Q1 default build menu is open for suggestions: want same simple structure (3 singles, rough test, final)
want bounce for final, may be something else

Question: are filterbar texturing bindings fine in q1 mode? (i'm not experienced in q1 common textures usage) 
Oops 
forgot .[ExecutableType] in build menu :3
Reuploaded the file 
Nice 
The Q1 gamepack is somewhat problematic, though (and I accidentally overwrote my own :P). In my view, the way Radiant handles models is impractical for editing, because it displays either the model (if set in the entities def file) or the bounding box. Having only the model can make proper placement awkward. It would be better if the outline of the box was shown around the model as well. As it stands, I deleted all "model" paths again.
Additionally, in Q1 the ammo models are BSP files, so they don't show up in the editor at all. The md3 files referenced in the new gamepack are not included apparently, and furthermore the bounding boxes set in the def file are wrong (all Q1 items are 32*32*56 regardless of their physical size). This can cause items to fall out of the level if placed partially inside geometry by accident.

Q1 build menu: I don't use that personally. If anything, it maybe should have "qbsp only", "quick compile" (qbsp, light, vis -fast) and "final compike" (qbsp, light -extra, vis -level 4) default options, but even these can vary depending on which compilers are used. For instance, current tools all support light -extra4 for smoother lightmaps, but older tools do not.

Filterbar: They don't seem to do much at all. The only special textures used in Q1 are: "trigger", "clip" and "skip" (no variations like weapclip etc). Some new compilers also have rudimentary support for "hint". Liquids are determined by an asterik in texture name, e.g. *water. A few new source ports allow alpha textures, but I think the naming standards differ - like textures beginning with a }, I think. Someone else please clarify.
There are no internal detail brushes or brush flags in general - the only way to achieve this in Q1 is to turn geometry into "func_detail" entities which newer compilers then convert back to structural brushes without generating vis portals for them. 
 
Having bbox, represented by lines, is one of wished features, it helps, while placing, for sure; though, i'v been told, that entities with models appear ingame exactly, as seen in editor.
There is visual representation of entity origin atm; it is possible to use it for placing, but need to offset halve bbox size in mind -)

md3 models are included (and more things); try q1pack dir, q1pack.txt

Filterbar: it is reconfigured in supplied q1.game, would like to know, if fine or not. 
 
The q1pack included is basically for ease of use. The filterbar enables filtering (m1 click) and texturing (m2 click) for clip, skip etc.
Also added a scripts folder to go in id1 which allows transparent textures/filtering in editor. You can add any texture to the shader for trans - useful for *water n stuff.

As for models, they show in game exactly as placed in editor; bar the ammo boxes which are all 32x32 big box over the 24x24 small box. The box="" sizes I didn't touch =p
Would be cool to see a bounding box along with the models for sure, 
Update 
https://goo.gl/UyXRUJ

* extradebug_quicker BUILD mode (defines _DEBUG_QUICKER = no slowing down debug renderables)
* draw bbox for having model + selected entities
* disabled depth write for qer_trans surfs and highlight (=any amount of layers is visible)
* 20x faster light radii rendering
* light radii are coloured and additive
* improved q1 pack (common textures, fix entities sizes)
* anisotropic textures filtering option (def = yes)
* GL_TRIANGLE_STRIP light radii spheres (2.5x faster)
* new very fast entity names rendering system
* render entity names in cam within < 768u dist or if selected
* fix: noninitialized lightradii, if light value is not set (example: lightjunior)
* light power is adjustable by mouse drag
* oranje names for group entities, having childrens selected (also no distance cull in cam for those)
* QuakeLive game pack 
 
How can I get this running on Linux? 
 
netradiant-custom.7z/netradiant-custom/netradiant-custom-20161202/src.7z\_bak69/COMPILING :) 
 
Would it be possible to have two independent "Show" options for the entity names in order to enable/disable their display for each window (one for 2D and one for Camera)? Or maybe a way to customize the rendering distance (either in menu or in .pref file)? 
 
Im in doubts about entity names options, too much ones are possible -)
Atm thinking about two ones: 'show for unselected' and 'show for selected'
This + may be display dist feels not too much to confuse user
What is your problem, something like 'cam, spammed by names'?
Btw, there was alternative suggestion: command to toggle *hide world + show entity names*

I have question about your crash on switch to diff app, while in freelook: does it always stay in freelook after switching out and back? (i e when no crash too?) 
 
It's just a little strange seeing all the names through the walls even if the actual entities are blocked by world geometry. If there was an entry in local.pref where one could set the distance at which names are rendered, I would certainly lower it.

Crash: I haven't encountered it again, yet (although haven't done much mapping, either). I tried a few things just now and, at least now, it didn't seem to stay in freelook. In most cases, the camera window was still moved behind the other two windows even when it was on top before switching apps. Tried switching apps with alt+tab, win+tab and win key. Though still not sure what exactly triggered the crash in the first place. 
 
Made two things about names:
* preferences->display->entities->Names Display Distance (in cam) def = 768u
* always show selected/childSelected entity names (unselected is optional)

About cam window, is funny, but going behind is normal gtk behavior
I made helloworld test app and it does the same (and big gtk apps do)
Basically it displays active window 1st, then the rest of windows, so active appears behind xD
Prolly can grind out some hack around that to present last active wnd, but the rest of wnds gonna be still tossed
mhm, just noticed, that 'activate main wnd, (focus out,in)*2' restores wnds order correctly

About modal windows, going behind: it is possible to set them 'always on top' (this works systemwide)
Sup with nonmodal tools windows then though (want them to be on top of canvas, right?) 
Niger 
Just to say you are doing God's work here - I love the feel of NetRadiant, and it's just getting better with your improvements :)

A little thing I wondered if you could consider:

Would it be possible to have options in the editor to set the paths to qbsp, vis and light? Currently this has to be done by editing an xml file tucked away in an obscure folder somewhere...I think? 
 
Atm there is no conception like 'path-to-Nth-build-tool', instead generic variables are used.
So may be ability to edit generic variables?
Or may be built in 'BuildToolsPath' variable, defaulted to RadiantPath and with ability to select path via dialog.
But using that in build menu would break backwards compatibility.
Still is not clear why these extra preferences are needed, atm it's as simple as 'drop compiler binaries to radiant folder, use' and even portable.

About floating windows layout: after fairly massive research i see two ways to fix that:
One is to make canvas wnds children of main wnd (i e built in = delimited by main wnd borders); examples: doom3edit, jack
This would be quite straight way to fix wnds order problem
Second is: dynamically set tools wnds transient to canvas ones in focus in event of 2nd ones; it seems, that gimp does that for detached canvas wnds
This is more tricky and risky option + there are plugins windows out of simple reachability
Tossing wnds would still occur on app focus out, in... that is how gtk transient function works; if i grab Windows Manager window and set transient via Windows function, it works just fine (no tossing); though that is really hacky (and Windows only) 
Build Tools Path 
Ability to edit generic variables sounds useful but obviously not worth doing if it's gonna break backwards compatibility.

It just took me a fair bit of fiddling around before I realised how to change the paths, but probably more my dumbness than anything.

Rather than dropping the build tools in the radiant folder, I prefer to keep them in a centralised place so multiple editors can reference them, and when the build tools need updating I only need to update them in that one place. 
 
I don't quite understand the window fixes, but from the sound of it, the first one seems better. Although, like I said, I haven't encountered the crash so far. Maybe it's already fixed? Only things about the windows I noticed (that are different compared to Gtkradiant 1.5) is that some windows sometimes require me to click on their title bar to focus instead of just anywhere inside them. And I occasionally close the entity window by accident, and upon toggling it again, it's centered instead of the position it was before. But this is a not really an issue.

Feature request (unless already present in some form): it would be nice if one could use the mousewheel to zoom in and out onto an object in orbit mode (freelook+tab), because with the default distance, the object in the center can easily be obscured by other stuff.

Not to be bothering about the entity model + bounding box display again... but would it be possible to include an option (e.g. checkbox in preferences) to enable the rendering of the bbox around the models all the time instead of only when they are selected?

By the way, is it just for me or do the buttons read "Cance" instead of "Cancel" for everyone else, too? 
 
It displays all models except for player.mdl?! 
 
-window fixes: it's not about crash, but occluding some wnds like scale dialog or csg tool by canvas wnds (in floating wnds layout)

-some windows sometimes require to click on their title bar: only time, when this happens, i'm aware of, is trying to bring on top already focused wnd (after app focus out, in: this doesnt happen in 1.5, since no wnds tossing in old GTK version, used there); Calling present() function on all clicks/scrolls isn't healthy (adds lag), so is called only on focus change

-entity window is centered instead of the position it was before: what are steps to reproduce? after some change in GTK there actually was problem with correct wnds positions restoring, but entity wnd has workaround already (floating canvas wnds still need that)

-orbit mode: it's ''fit selection bbox to camera view'' function actually; not sure what to do, since no things like distance there (though i agree, usability of current function is limited)

-bbox around the models: will add, can imagine its usability (but spoiling the view on the other hand)

-"Cance": Is it true for any dialog? "Cancel" here usually, may be button size < text with your settings?

-player.mdl: it's the way, .ent is configured; ww decided to left boxes there, because same model would be used for various spawns; might be fine idea to use model there too, as ent names are shown in camera too 
Seems I Suck 
I thought the entity window thing was sometimes triggered by closing it with ESC when actually intending to deselect an entity, but I can't seem to reproduce it now...

"Cance" was indeed caused by the custom text size setting in Windows. I had it at 125%, because otherwise the text would be a little too small for comfortable use. Something about the transition to Windows 10 that caused this hiccough. I've now set it to default and then back to 125% and it say "cancel" like it should. However, now certain other things look a bit weird, e.g. the menu bar buttons are slightly larger and the lines in the 2D window are fairly thick and black. Some weirdness in other programs, too. FFS, Windows!

Player.mdl display works, too. I did add it in the .ent file, but it still didn't show up, that's why I wondered. Apparently the reason is that I had backup copies of the file in the same directory ("entities - copy.ent" as Windows does it) which Radiant loaded instead of the actual file. :P 
 
It loads all found .ent and .def files.
So it's easy to drop in mod entities.
To make backup change/add some other file extesion 
 
So I keep fiddling around with this script for hours, wondering why it wouldn't work, just to discover Custom Radiant simply refuses save entities that don't match the .def?! In this case, a point-based trigger_once when the def has files as group-based. I would very much appreciate if Radiant would stay the hell out of my meddling and save everything I do regardless of how erroneous it may seem! (1.5 did) 
Re: Angle Decimal Rounding Bug 
It appears to only affect point entities without models that have a negative angle set, and only changes the value when moving them. So for instance, angle -2 (=down in Quake) becomes -2.000006. Obviously, this must not happen, because it makes the affected entities stop working correctly. 
 
It's always done odd things like that, though I've never noticed with the up/down angles. I set an angle to 270 and it saves it a -90. I set an angle to 180 and it saves it as 179.99995 or something. 
Displaying Models On Entities 
Hi can someone give me a quick rundown on how to make entity models show up in the editor (e.g. monsters)

I'm using the .def file provided in Arcane Dimensions 1.5 - this .def file seems to have the information for model display (e.g. it contains the line

{ model(":progs/mon_hknight.mdl"); }

After the hellknight definition.

Also, I have set the custom mod correctly to AD through the project settings. 
 
save everything I do regardless of how erroneous it may seem!
I thought, this was discussed, but again:
some games (for example q3) don't load maps with empty group entities.
The most classic rad 1.5/net user's forum post is "Hello, i be building my map for a month, and now suddenly can't run it in game, halp :@"
The most classic solution is "open map in radiant 1.4, which removes such entities, and resave" or "rebuild from scratch/last backup"
Ridiculous, eh?
Yes, 1.5 discards brushes, contained in entities, defined, as point (with red warning in console)
Yes, there are ways to get empty group entites during normal map editing process; catching every possible way is like fighting the wind, also solution is always unique.
I added discarding empty group entities on map saving (with red warning in console); this fixes one of the biggest flaw in 1.5 branch
This is most important for non-advanced users; ofc advanced ones are aware of such behavior (literally every user hit one at some point) and can remove problem entities in 3 keypresses.
I, being advanced user, like you, would rather setup small suggested batch and keep creating with full comfort; or just use entities with brushes for tests and remove brushes for release version.
Only real solution is actual support of different entities with equal names; will look into that, though i expect too heavy research there.

angle -2 (=down in Quake) becomes -2.000006. Obviously, this must not happen
For the sake of interest, what point entities use -1 -2 angles for hardcoded directions?
In radiant brush entities angle is a string, and point entities one is actual number, transformable by editor.
Point entities also have 'angles' vector3 key for arbitrary 3d directions, thus there are no problems, except aestetics, for games, designed that way.
Transforms are performed in unified way like SceneGraph.forEachInstance( getTransformNode().transform() ), i e single function for all transforms, so you have angle transformed and committed, even if you just translate object;
One idea is to try to catch that case to omit commiting.
Meth around rotating is quite interesting:
rotation angles->radians->quaternion->matrix
current state angles->radians->quaternion->matrix
matrix*matrix
get_rotation_euler_xyz_degrees(result)->angles
Once computers computing precision is not limitless, even zero rotation can commit values.
Second idea is to use the way, entities with model use for rotation, when possible (with predefined quaternions); so -2.000000 would stay -2.000000, 180.000000 180.000000 etc


I set an angle to 270 and it saves it a -90
arctangent returns values in range ( -180, 180 ) :)

{ model(":progs/mon_hknight.mdl"); }
This looks, like autoconverted from fgd w/o correct model key handling
Correct syntax in def is:
model="progs/mon_hknight.mdl"
find/replace :) 
Numerical Stability Is Key 
Shrinker here,

I disagree with your defense about the limited precision in computing.
It should not be used to defend deteriorating numbers, but rather be taken into account to make sure that doesn't happen in the first place whenever possible. Numerical stability is very important because this is about user input, and the little errors can add up over time and cause frustration.
Also, what is often not considered is that the conversion of floating-point byte patterns to strings and vice-versa can also lead to a loss of stability already because of only limited digits being shown depending on the format configuration.

Your effort to have the editor "understand" all geometric keys is very commendable and allows you to do neat things an editor without that understanding can't do, like manipulating rotation values, velocity vectors and the like accordingly or making sure all of this also works when shearing or scaling the selection too. Putting it all through a unified computation pipeline is also nice in order to make sure you can deliver a high processing quality in everything.

But:
When doing translations, and you can certainly discern those based on where your transformation comes from, and carry that through with a flag, rotational values shouldn't be touched.
When doing 90 degree rotations, which again could be carried through with a flag (the original Radiant's Tab key caused this transformation), the transformation matrix should be tuned to have perfect 0s and 1s in it* so that in the end, for coordinates and directional vectors, you have perfectly swapped coordinates instead of slightly deteriorating coordinates.
(*): something along the lines of that is also found in C++ optimizer settings for a reason - special treatment for 0s and 1s in computation to be more in line with the user's expectations and to ensure numerical stability better

Normalizing your angles between (-180, 180] is a design decision, and that's okay - you could also have decided to make them always negative or always positive depending on taste or what your users are familiar with. -- but as just mentioned, that should only apply when you actually have to manipulate the angles.

Keep up the good work! 
 
Hey, Shrinker.
I'm not the author of all those cool transformation codes, but SPoG - primary 1.5 radiant branch developer (and 3ds max fan, i believe);
I'm just telling, why that half transparent black box works, like it does, and name visible solutions (ones you named in general).
Though all these workarounds don't look as neat and straight, as original code does; perhaps other way could be converting all computations to doubles; also things to mention, current way produces no problems for games like q3 or doom3, you simply edit visually and don't care about not super accurate values.

One thing, code is not fully mathematically correct there: works ok only when rotating on axis, entity is rotated initially (or initial rotation = 0). Perhaps you have idea why that could happen in described meth, one looks legit for me :) 
 
For the sake of interest, what point entities use -1 -2 angles for hardcoded directions?

Shooter traps, for example. Like with group entities, the game code automatically translates the values into angles the engine can work with.

I don't know about the code and how it has changed over time/versions, but this did not occur with Radiant 1.5, and I'd be very surprised if it did with the old Netradiant. "-2.000000" seems to do the job as a workaround. 
Normalisation 
It's undeniable that Quake is doing something very hacky with those -1 and -2 angle values, but the fact is that any editor which wants to support Quake can't afford to normalise angles to the range -180 to 180. Leaving aside the precision issues, if I want to have an entity facing at 358 degrees, normalisation will change that to -2, and now my entity faces down when it's loaded into Quake.

Of course, the developers of Radiant are under no obligation to support Quake. There are other editors available today which do have this as a goal, and get these kind of details right. But I'm sure it's a shame for people who prefer it as an editor. 
 
Oh snap!
Good observation about radiant 1.5, found related commit:
https://gitlab.com/xonotic/netradiant/commit/f85ed10a525f0740eea98350f2cb0ed84db8530c
Fixing one, breaking the other >_<
Changing number to string format... %g was supressing those small inaccuracies automatically, except 0 case: stuff like -3.50835e-015 occurred

Preach: i think restricting those unwanted angle commits on every move will be enough to repair the problem, so you will be able to safely set 358 and even 359 angle :3 
 
Maybe use "%.3f" to round to 3 digits after the decimal point?

I added discarding empty group entities on map saving (with red warning in console); this fixes one of the biggest flaw in 1.5 branch

How about checking for an "origin" key. If there is no "origin" key, it's probably an accidentally created empty brush entity and can be deleted. If there is an "origin", the mapper probably made it on purpose like negke's case, and the entity should be preserved. 
 
%.3f might be not enough precise in case of aligning big models
Though snapping with reasonable epsilon would be nice, if other means wont work.

Thanks for fresh idea about "origin" key, will be okay for tmp workaround (TM).
Actually group entities can use origin key in editor and in games, but this is rare case, it seems. 
Update 
https://goo.gl/UyXRUJ

binds...
* ctrl + e: ExpandSelectionToPrimitives (select group entities w/o parent node)
* ctrl + m3 texture painting by drag
* Tab + mWheel in freelook: offset focus distance with dist2origin/8 step; exponentially, if moving far away
* m2 drag in cam = sideways+updownways strafemode; do not enter/quit freelook, if long button press (>300ms)
* m1 drag in freelook = sideways+updownways strafemode (mainly for visual editing)
* ctrl + m3/drag = seamless brush face to face texture paste; works for any faces in BP mode, only axial ones in AP
* ctrl + shift + a: select all visible brush faces and curves, textured by selected shader
(more obvious way, than existing ones: components mode::faces->shift+a and find/replace to empty)
* shift during creating brush = quadratic brush
* drag clipper point + shift = constrain to axis with biggest move amount

menus...
* view->show->Entity boxes (always show bbox for ents with model)
* Misc->Colors->Themes->Blender/Dark color theme

Misc...
* fix: QNAN texture projection after scaling cuboid on Z axis (brush primitives + texture lock)
* preferences->display->entities->Names Display Distance (in cam) def = 512u
* always show selected/childSelected entity names (unselected is optional)
* fix: mouse texture grab/paint commands ignore filtered faces (caulk filter)
* fix name case sensitivity in shaders (non plain textures) loading during map/model loading
* all patch prefabs are created aligned to active projection
* preferences->display->entities->Names Display Ratio (2D): hide names, if view_size/bbox_size > value; def = 64
* surface inspector: renamed poorly named Axial button to Reset
* arbitrary brush texture projections in brush primitives map format: axial, from ortho view, from cam
* frame 2 frame time render stat
* renamed confusingly named command GroupSelection to RegroupSelection
* fix: changing clipper color via theme loading doesn't require restart
* fix: changing CameraSelectedBrushColor, SelectedBrushColor don't require restart
* -gamedetect command line option to enable game detection
* don't disable aero by default; -aero command line option disables one
* "Don't show" (during session) checkbox in Light Intensity dialog
* fix: show-grid toggle hides grid, when snap-to-grid is off too
* region mode: draw out of region part of grid in subtle style
* restrict unwanted angle(s) keys commits on moving generic, eclassmodel, miscmodel entities
* reverted angle(s), origin, scale entity keys save format from %f to %g
* fix uniform rotation operations for generic entities with angles key
* use more precise meth for rotating point entities with only angle rotated
* snap tiny inaccuracies in angle(s) and origin point entities keys
* workaround: don't discard empty group ents, having origin key
* entity class convertion: prevent converting worldspawn; prevent converting point entity to empty group 
Thanks - And A Request 
This looks, like autoconverted from fgd w/o correct model key handling
Correct syntax in def is:
model="progs/mon_hknight.mdl"
find/replace :)


Great, thanks :)

I also have a feature request. I think it would be a big texture alignment time-saver if you could select a face, and an edge, and then have a command to automatically rotate/align the face texture along the selected edge - possible specifying what axis of the texture to align along the edge (e.g. align horizontal or align vertical) 
 
I agree, something of that sort would be fine, custom texturing opportunities were always nearly nonexistent in radiants.
Described setup is quite complex, best thing, i can imagine around this, is uv editor with nifty snappings, like in trenchbroom.
Other (more simplistic and usable for mass processing) idea was a button to toggle through edges, aligning to ones; though texture has two axes, so two buttons :) That would be possibly cool, just have no idea, if i can handle related meth, one is black magic for me, tbh.
But after all, when got it aligned, you most likely would like to scale/shift to match other edges, while keeping align to initial edge; that is work for uv editor for sure 
 
niger - ah, it seems you have a good sensibility for the issue. If you do ever get around to a solution it would be very much appreciated here :)

I mentioned my idea because it's already possible in the editor to have an edge and a face selected at the same time, so you wouldn't need much extra UI stuff (maybe just shortcut commands to execute the texture align operation?) 
Awesome 
Thank you for looking into and addressing those issues. The new features seem nice, too. I'll have to teach myself to use the texture projection/drawing stuff more (usually a ctrl+c/v type of user).

What I now expect is for Kinn to make a map! 
 
What I now expect is for Kinn to make a map!

Born too late to make maps in 1997, born too soon to make maps in the Honeysock era - born just in time to spank a couple out in 2004 before being whisked off to enjoy a life of crushing responsibility and lack of free time. 
Amen 
 
Harsh Fates 
 
Func_detail And The Detail Filter 
In Quake 1 mode, would it be possible to make func_detail subject to the details filter, instead of the entities filter? That would be very handy :) 
 
True, added func_detail to world and detail filters.
Filter system is nonmodal + ericw might add actual detail face flag support one day (or has it been it added?), thus there is problem with correct structural filter processing, if i try to to make it to work for func_detail too:
-it filters brushes, having structural faceflag inside func_detail
-filters all entities besides func_detail :D
So let's run w/o this one 
Nice One - And Here's Something I Would Love To See... 
Some Radiant versions have a "Z Window" - for me, I always found this ultra handy when you have room-over-room stuff. Image here: http://www.planetpointy.co.uk/archive/editing/tutorials/images/figz_1.gif

I can currently region things off in the z-axis by creating a brush and using Region->Set Brush.

Problem is, I am constantly turning regions on and off, and having to create a region brush every time like this really slows things down.

If I don't care about stuff above and below, Region->Set XY (bound to a shortcut) is extremely quick, but obviously this isn't great with room-over-room

The addition of the old Z-Window would complement Region->Set XY and give the best of both worlds without having to create a brush everytime.

Food for thought! 
Edit... 
I may be thinking of DoomRadiant with that Z-window thing - I remember there being clamps in the z-window that let you bound what gets displayed in z.

Or I may be imagining things! I wish I could check actually but I don't have Doom 3 anymore 
 
So it shows only z bounds of only selected stuff.
Can't quite imagine the special use of it.
May be you want to choose layout with more projections shown.
The way, i use, is rectangular selector + region button on toolbar; one feels enough quick. Can combine that with hiding too.

Some thoughts to think there tho:
Region->Set XY indeed always does XY; might work for other projections too
Region->Set Brush can be removed, as duplicate of 'select inside brush', 'region set selected' and forcing to use slower method. 
 
Ic better now, z view probe position is set via shortcut and all stuff is displayed there
Clamps appear to do nothing (q4 editor)

So it's basically for aligning things on z
Levels tend to be more flat, than high, so side wireframe views (with z) are usually more complicated
So that additional system benefit is somewhat simplification i think 
 
Region->Set Brush can be removed, as duplicate of 'select inside brush', 'region set selected' and forcing to use slower method.

I would be inclined to leave it alone actually - it's better to keep the option of doing it in one step ("region set brush") than having to do it in two steps ("select inside brush", "region set selected")

Region->Set XY indeed always does XY; might work for other projections too

I quite like the idea of "Set XY" to work in other projections. For that to be useful though, successive region operations would have to be subtractive - e.g. you would typically want to do a "Set XY", and then change the view to (e.g.) ZX, and set the region again, but everything that was hidden in the XY step would have to remain hidden in the ZX step.

Currently, regioning is not subtractive (the region is reset each time) - but making it subtractive to better support different projections might not be a bad idea. 
Edit 
If you were to do that, having "successive region operations are subtractive" as an option in preferences might be best, so as to not upset those who like regions to work the old-fashioned way 
 
I agree, at least region-set-xy must be subtractive.
For old behavior can click region-off; one additional click is ok, as cost for not overcomplicating preferences and code.
Though rectangular selector + region button on toolbar way does wanted thing quickly and w/o creating brushes.o 
 
Though rectangular selector + region button on toolbar way does wanted thing quickly and w/o creating brushes.o


Ah yes I've just tried that and that's not bad, probably better than the creating brush method. 
Editor Model & Frame Display 
For editor display purposes I would find it really useful to be able to set any individual non-brush entity to appear as a model with a given frame in the editor. This would be most useful for things like "misc_model" entities, where you need to be able to see the correct model and frame in the editor in order to position the thing in the environment.

Now - I can set the model in the editor with the "model" key, but I can't set the frame. However, the "model" key is used by the QC, and really I'm looking for something that can't affect the QC, because there's no telling what keys the QC are expecting to be set (e.g. for AD you have to set the "mdl" key), and furthermore, setting the "model" key on an entity that shouldn't have it set from the editor - could break a mod.

So really to ensure it can't break mods - I'd want something like these keys:

_editor_model
_editor_frame

Importantly the _ underscore makes the QuakeC ignore it, ensuring this can't affect anything in the mod.

Any thoughts? 
 
Hey, i don't quite get, what you want
Entities with classname misc_model do show arbitrary models
Frame is bbox, right?
Showing arbitrary models and boxes for any point entities would mean adding corresponding functionality to all ones, which is huge overkill
You are able to set displayed model and bbox in .def or .ent, like for weapon_* entities for instance 
 
Frame is bbox, right?

Frame is model frame - nothing to do with bbox. Many models intended to be used as "misc_model" would have multiple frames where the model varies wildly in size and/or appearance. Imagine a tree model with multiple frames each representing different sized trees, with branches in different positions.

Being able to see different frames in the editor is also really useful when placing (for example) crucified zombies (monster_zombie) or any other entity where you want super-precise positioning in the world.

Currently the models are displayed only at frame 0.

Entities with classname misc_model do show arbitrary models
Showing arbitrary models and boxes for any point entities would mean adding corresponding functionality to all ones

Ok, I'm fine with it only working for misc_model.

Currently in the editor, using the "model" key works, yes.

This is fine if setting that key doesn't cause unintended consequences in the mod. As I say, some mods might not want this to be set through the editor. For example, AD's implementation of misc_model requires you to set the "mdl" key instead.

Someone like Preach is probably better qualified than me in explaining if there are any situations where setting "model" in the editor could cause issues in the QC

Really it's just the editor has no knowledge of what the mod might do with any given key/value which is why I suggested using keys that are totally insulated from game code (i.e. keys prefaced with the underscore character). Same reasoning applies with any hypothetical key that would specify what frame to display.

You are able to set displayed model and bbox in .def or .ent, like for weapon_* entities for instance

That's great for most stuff, but really I'm talking about things like misc_model and related entities which are all about placing custom models.

Just to re-iterate, I'm fine for this only working with misc_model if it's problematic to make it a general thing. 
You Know What? 
I'm overthinking this and overcomplicating it. Please ignore my posts #70 and #72.

Using the "model" key on misc_model works. That's fine. Leaving it at that, all I'm requesting in addition, if at all possible, is some way of also specifying which model frame to display in the editor on the misc_model. 
 
Aha, model frame
Mdl loader doesn't support loading frames other than 0 atm, and this format stuff is obscure for me
From what i read, while repairing loader, mdl models can contain groups of frames ('sequences'?) and lone frames
The only found code with support of loading sequences was game src

Besides that there are quite a few of pretty q1 specific stuff: loading skins from .mdl, loading correct sequences, depending on spawnflags, loading different models, depending on spawnflags, loading .bsp as model; Which also would require .ent/.def/.fgd formats change 
Ah 
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....

http://i.imgur.com/KpBsWHB.png

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 :) 
Pointfile 
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: http://i.imgur.com/25pRmmI.png

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. 
#84 
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. 
Update 
https://goo.gl/UyXRUJ


binds...
* 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]

misc...
* 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. 
+1 
Or maybe even one with a field where you can enter the name of any texture to be used when clipping. 
+2 
"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 q1.game->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 
Update 
win32 build
win64 build (mainly for the sake of x64 q3map2, but also may improve smoothness, comparing to w10's VM + win32 build)

binds...
* 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

Misc...

* 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\q1.game if you want to enable q3 brush primitives texture projection. 
 
http://ericwa.github.io/tyrutils-ericw/

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: https://gitlab.com/xonotic/netradiant/issues/100 
 
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:
https://youtu.be/qA9eNOkD1iY 
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 q1.game 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 ( https://ericwa.github.io/tyrutils-ericw/ ) has a map converter built in. you can use it from the command line like this:
qbsp -convert bp something.map
will convert to Q3 brush primitives (iirc it writes the output to a file called something-bp.map) 
 
You guys are awesome, thanks! 
Update! 
Whoa 
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. 
Niger 
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 
Thanks 
It's good. 
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.