ZeroRadiant 1.6 Development Thread

[AEon]

Anyone else having the problem that the editor moves down a bit on the screen? The main windows (menu window) that is, not the blueprint or any other view.

I had to place the windows several times until they (all separated) finally stuck were I wanted them. It seems to help to be *very* careful to place the main window exactly *inside* the desktop area, if you are one pixel out of screen, the editor places the window further down on restart. One pixel in-screen should be on the "very" safe side.

This is probably part of the multi-monitor legacy code that tries to avoid your windows suddenly being off-screen (e.g. you had two monitors, then disconnected one and can no longer see the window). Just a guess.

[AEon]

This might be really heavy (or not), but is it possible to make it so that you can undock the texture and ent inspector from each other so that they are two seperate windows and also, make an option to put windows always on top. So that I can always have the surface inspector where ever I want it and always open? =)

I guess it very much depends on how often you actually use the Textures dialog. I only use it a lot at the beginning, and later in the map simply grab the texture I need from another surface. The option for a separate Texture dialog might be nice though.

Here is my current editor layout on a single monitor (sorry, image is 600KB):

• http://aemap.hugelaser.com/misc/GTKlayo ... 6%2754.png

For me a quick tap on the T-key to change from Entities tab to Textures tab is not really much of a deal. *But*, if you happen to be using two monitors, separating the windows could be quite handy, e.g. Surface inspector, Textures, Entities all permanently open on the 2nd monitor, maybe also the 3D view or the Console (it logs everything happening in the editor in real time, this may also be interesting to follow).

The "always in front flag" for windows should be system standard, Directory Opus (WinAmp?, mIRC?) and a few other tools let you do that. Again as a Prefs option for the folks who would rather not have this happen would be good, as you mentioned.



I had a short discussion with xpc about the Textures dialog, i.e. implementing a texture/shader file browser to the left of the textures like in v1.5. I suggested that the browser part of the window can be hidden/folded away, to give you the maximum space to view textures once you picked the folder of interest. It could be nifty to control such things via some icons at the top of the Textures window, i.e.:

• Show/hide texture file browser.
  Selecting a texture will highlight the texture folder name/shader name in the file browser view.
• Show textures at one fixed size.
• Scaled by 50%, 25% etc.
• Show/hide quick filter bar for texture names.
• Show/hide texture names.
• Define texture favorites that take up space in the upper part of the window (always visible), e.g. clip, botclip, caulk, and in-game main textures, hide the rarely used textures.
• That brings up a nifty alternate possibility, sort textures by usage counts... this sorts textures rarely used to the bottom of the list where they get less in the way, e.g. weapon/item decals.
• Sort by file name.
• Sort by texture folder / shader file name.
• Show source code for selected shader.

I'm sure there are other nifty things that might be useful in the Textures view. Just dreaming here... personally I'd want to see quite a few other things added first (primarily the real-time rotation code for models - and the texture alignment ideas, as suggested further up).

[Theftbot]

what are the levels for?

[-=skOre=-]

This might be really heavy (or not), but is it possible to make it so that you can undock the texture and ent inspector from each other so that they are two seperate windows and also, make an option to put windows always on top. So that I can always have the surface inspector where ever I want it and always open? =) Now I need to resize windows and shit to keep that "open" else it falls behind.

Apart from the undocking of texture/entity tabs - I use KDE, so I can do this kind of stuff out of the box Go Kubuntu!

[AEon]

what are the levels for?

Levels?

[Hipshot]

I fixed the always on top with an external application. Could be useful to some.
(http://www.labnol.org/software/tutorial ... -top/5213/)

(This is my radiant with the surface insp on top, very handy for checking the problem mentioned below: http://zfight.com/misc/images/editors/r ... 012009.jpg)

Another very annoying bug, you guys must as well have come across this many many times. That textures offsets them selves a unit or two, sometimes by 10th of a unit or so. Very very annoying, could this be fixed? I guess it has something to with rotate and the target coordinates or something... don't really know, I just know it's a pain on small things...

[AEon]

always-on-top.exe
Indeed that is a pretty practical tool, very simple to use: Select window, Ctrl+Space and it stays on top. Though I still don't really need it.

Another very annoying bug, you guys must as well have come across this many many times. That textures offsets them selves a unit or two, sometimes by 10th of a unit or so. Very very annoying, could this be fixed? I guess it has something to with rotate and the target coordinates or something... don't really know, I just know it's a pain on small things...

Hmm... I noticed even under v1.4 that texture alignment on small brushes, even with texture offset/rotation lock turned on will simple not stay locked properly. Hipshot, maybe you could create a mini-map (.map) file that let's us reproduce the issue. And also add a step by step list that would let us try this out. That should help xpc track down the problem.

My guess is this is some sort of precision cropping happening (i.e. the number of "significant" float digits get cut off somewhere in the code. Or that a conversion from an initial double to float happens).

[Hipshot]

Hmm... I noticed even under v1.4 that texture alignment on small brushes, even with texture offset/rotation lock turned on will simple not stay locked properly. Hipshot, maybe you could create a mini-map (.map) file that let's us reproduce the issue. And also add a step by step list that would let us try this out. That should help xpc track down the problem.

My guess is this is some sort of precision cropping happening (i.e. the number of "significant" float digits get cut off somewhere in the code. Or that a conversion from an initial double to float happens).

It happens here in 1.6 too, I will work with 1.6 now for this thread to keep it version consistent, less confusion that way.

Here's a test level:
http://zfight.com/misc/files/q3/coord_test.map

It's units I actually use for my current level, but the lamp fixture uses compatible textures here.

If you select these and duplicates them, both units will have various errors with the some faces.
Most notable is the angled lamp, which will become very strange when duplicated.
But it's totally random, doesn't happen all the time, not the same error, etc, sometimes it works doing a duplicate and then another one, etc, super random, hard to repro.

[Hipshot]

Bug:

# Paste to camera doesn't work (didn't work in 1.4 either) or I'm using it the wrong way? alt-v?
# Doesn't work to change the grin size on the numeric keypad.


Feature:

# Does the lock button in the surface inspector need to be enabled by default? Isn't that just stupid, why is it even there?
# Isn't it possible to add a button that makes you texture nudge by one(1) unit no matter what the Step value says? Like also holding CTRL when nudgeing, so it becomes ctrl-shift-[direction arrow]
# Can't the surface inspector update it's values in real time, if you have it open and changes the texture using the keyboard?
# Instead of displaying the path to the level in the task bar, show the name of the level? Very practical if you have more than one instance open (Yes I know about the tool tip thingie).

[AEon]

Will look into your map example later...

# Paste to camera doesn't work (didn't work in 1.4 either) or I'm using it the wrong way? alt-v?

Indeed does not work... problem seems to be a shortcut conflict with the Alt+V View menu. I tested this in aeRadiant by using Shift+V, alas...

mainframe.cpp, about line 240

Code: Select all

//  {"PasteToCamera", 'V', RAD_ALT, ID_EDIT_PASTEBRUSHTOCAMERA, "menu_edit_pastebrushtocamera"},
//	Alt+V (0x02) would open the View menu, if that worked... using Shift+V (0x01)
  {"PasteToCamera", 'V', 0x01, ID_EDIT_PASTEBRUSHTOCAMERA, "menu_edit_pastebrushtocamera"},

Alas that does not work... the code seems to be broken (i.e. copy to camera).

xcp, the RAD_ALT seems to be legacy code, I had been thinking of replacing the qualifier codes (0x01, 0x02, 0x04, with variables GTK_QSHIFT, GTK_QALT, GTK_QCTRL, e.g. 0x04 = GTK_QSHIFT + GTK_QCTRL ) to make them easier to read.

# Doesn't work to change the grin size on the numeric keypad.

xpc, mainframe.cpp, about line 180, was missing explicit numerical keyboard shortcuts, just needed to add them via:

Code: Select all

  {"ToggleGrid", GDK_KP_0, 0, ID_GRID_TOGGLE, "menu_grid_toggle"},
  {"SetGrid1", GDK_KP_1, 0, ID_GRID_1, "menu_grid_1"},
  {"SetGrid2", GDK_KP_2, 0, ID_GRID_2, "menu_grid_2"},
  {"SetGrid4", GDK_KP_3, 0, ID_GRID_4, "menu_grid_4"},
  {"SetGrid8", GDK_KP_4, 0, ID_GRID_8, "menu_grid_8"},
  {"SetGrid16", GDK_KP_5, 0, ID_GRID_16, "menu_grid_16"},
  {"SetGrid32", GDK_KP_6, 0, ID_GRID_32, "menu_grid_32"},
  {"SetGrid64", GDK_KP_7, 0, ID_GRID_64, "menu_grid_64"},
  {"SetGrid128", GDK_KP_8, 0, ID_GRID_128, "menu_grid_128"},
  {"SetGrid256", GDK_KP_9, 0, ID_GRID_256, "menu_grid_256"},

Works fine in aeRadiant now.

[AEon]

Does the lock button in the surface inspector need to be enabled by default? Isn't that just stupid, why is it even there?

Agree... found it stupid... usually you *know* what you are doing, and would not accidentally change something. I'd suggest replacing UNLOCK with a RESET button, that resets the above values to their default. I hate doing this by hand.

# Isn't it possible to add a button that makes you texture nudge by one(1) unit no matter what the Step value says? Like also holding CTRL when nudging, so it becomes ctrl-shift-[direction arrow]

Checked this... even I could quickly add this. The Ctrl+Shift (0x05) qualifier + Cursor keys are still available, so you'd only need to add 4 key shortcuts, plus, copy-paste existing functions ( OnSelectionSelectNudgeleft() etc.) to only offset by 1u. Will try that later.

Instead of displaying the path to the level in the task bar, show the name of the level? Very practical if you have more than one instance open (Yes I know about the tool tip thingie).

Both might be nice, i.e. name of the level from the worldspawn message key, plus the full file path (just in case).

[obsidian]

Ideally, shortcuts should be user modifiable, like in GtkRadiant 1.5.0. There's a shortcuts.ini file that one can edit to a certain extent.

[AEon]

obsidian,
I have not looked into the code related to the shortcuts.ini, yet, but from what I have seen so far: It seems the code defines Command Variables, those shown in the shortcuts list from the Help menu, and then lets you alias/assign keys to them via the shortcuts.ini, IOW as I added code, I also added the re-mappability automatically (I think).


Lol... accidentally using Ctrl+Shift+Cursor keys to nudge selected entities by 1u... instead of offset (shift) the texture face by 1u

Hopefully, I can give xpc (once it works) a source code update, that he can then diff to double-check... freeing him to do the *really* hard stuff, not getting boggled down with copy/paste coding basically. I love to code

[AEon]

Isn't it possible to add a button that makes you texture nudge by one(1) unit no matter what the Step value says? Like also holding CTRL when nudgeing, so it becomes ctrl-shift-[direction arrow]

Added dedicated keys that let you shift texture on brushes or brush faces by 1u, using the Ctrl+Shift+Cursor keys.

xpc,
I used your latest code and merged my changes into the mainframe.cpp and mainframe.h files:

• mainframe_aerad_1u_texshift.zip (57.7 KB) @ hugelaser.com

Changes:

• SelectNudgeDown key shortcut entry, moved to where SelectNudgeLeft and the others reside.
• Added the new Ctrl+Shift+Cursor shortcuts.
• New functions (e.g. OnSelectionTextureShiftleft1u) and calls to them added.
• Removed dead variable *b2 in OnSelectFuncGroup() to fix compiler warning.
• Updated header file.
• The keys on the numerical keypad 1-9 and 0 now also change the grid.

Hope this is actually useful.

[Hipshot]

Another feature that might be good, is to automatically force a reload models after you do a reload textures. If you don't have any models, this won't affect anything, if you have models, it will do it for you (since you need to reload models after textures else they for some reason gets the wrong texture).

If not, maybe the reload bug can just be fixed =)

[AEon]

For me the reloading of shaders/textures never really worked... it messed up the shaders on the models big time... that's the reason I normally restart the editor. Fixing this issue would indeed be nifty.

[xpc]

xpc,
I used your latest code and merged my changes into the mainframe.cpp and mainframe.h files: ...

Please no full files, they're highly impractical to work with, because usually my version is out of sync due development; overwriting would destroy my work.

I was already writing about providing a unidfied diff, but since you're already created a github account, I would really suggest you simple fork from my project and hack away, I can then pull in your changes into my tree; that's the major reason I actually choose github.

[xpc]

Delta NEWS Update (see http://forums.urbanterror.net/topic/196 ... bug-fixes/ for more details, downloads, etc.):

New:

• Protected more operations via undo (nudging selection, changing entity key/values from dialog)
• Clear undo history when loading or creating a new map.
• Always mark a map as modified after an undo-able action has been recorded.

Changes:

• Disable color scaling when changing entity color from color chooser.
• Sync main window title with undo/redo and on disk saved states.
• Don't clear undo history when opening preference dialog.

[Hipshot]

Maybe there could be a marquee box when using alt-mouse1 to drag select. Now there is none and there was no one in GTK14 either... very strange that there is no... an idea is to give it a blue color compared to the regular red one, so you know you're not just draging out a brush...

[xpc]

Maybe there could be a marquee box when using alt-mouse1 to drag select. Now there is none and there was no one in GTK14 either... very strange that there is no... an idea is to give it a blue color compared to the regular red one, so you know you're not just draging out a brush...

I think adding a marquee box is absolutely necessary.

Why alt-mouse1 and not simply mouse1?

I see the behavior of alt-mouse1 is, that you've to "fully" select objects.

Why not let (the proposed new) shift mouse1 drag select behave like select partial tall ?

I'm suggesting this not out of creativity, but because learned it from 1.5 and it speeds up things (unless I missed something obvious that we can't map shift mouse1 drag select :/ ).

Update: added "shift", that's what I actually meant

[fKd]

more texture selection tools would be nice

ie select all surfaces with x texture

[AEon]

Well, after some gruesome testing/reading etc... I now have opened a direct fork to mfn's (xpc here at LEM) code, letting me download and upload my own code changes. This should greatly simplify "small" changes I make in code, letting xpc double-check if they should go in the actual release builds. Things are sorted out so that I could actually release "my own" binary AEradiant ( , boy what a pompous name) builds for Win32, but that will most likely not happen.

As a first step I have submitted two commits at AEonZR - GtkRadiant (suggested by Hipshot):

• Set Grid Size via NK Pad 1-0 additionally
• Ctrl+Shift+Cursor Offsets Textures by 1u

Hopefully they work, and that some other changes/enhancements will follow.

Why not let (the proposed new) mouse1 drag select behave like select partial tall ?

I am not quite sure about this... it might conflict with normal dragging... but I am guessing the code will check for anything selected, if so, no LMB-drag will work.

[AEon]

Here's a test level:
http://zfight.com/misc/files/q3/coord_test.map

It's units I actually use for my current level, but the lamp fixture uses compatible textures here.

If you select these and duplicates them, both units will have various errors with the some faces.
Most notable is the angled lamp, which will become very strange when duplicated.
But it's totally random, doesn't happen all the time, not the same error, etc, sometimes it works doing a duplicate and then another one, etc, super random, hard to repro.

Very strange:

• Loaded your map into GtkRadiant v1.6.x MFN (xpc's latest build).
• Texture lock for shifts and rotations had been already activated from a previous session.
• Using Ctrl+Shift+LMB selected each of the 2 brush groups.
• Used Clone (Space), and Copy/Paste, and nudged the groups in the XY View (LMB-drag).
• I also used NK+, NK- to change height, and even rotated them via rotate icons (90°).
• I saved the file and reloaded it.
• I then loaded the map in v1.4 and did some more tests.

I no case did I notice an offset in the textures, I especially looked at the light texture. I am aware that some fishy things seem to happen sometimes, but that must have been primary using the Rotate mode (R-key).

I did notice that for the left group, the gray grate on the right of the wood is slightly offset horizontally, but that was already the case for the "original", that did not get worse. I used my Ctrl+Shift+Cursor code to fix that... whee

So... alas, I have no idea what might be the issue here. Maybe someone else could test this as well?

[Silicone_Milk]

Hmm... I think a to-do/wishlist needs to be created. Personally I'm a bit lost on what's going on with the alterations to the 1.4 source

[Hipshot]

Yea I feel that too. But it's like, I mean, xpc is doing his things and now AEon his things, so it's a fork from a fork, it's bit annoying... because it's a bit personal, I can see that xpc don't wanna do everything everyone else wants, the same with AEon. It's a personal interest (I guess (??)). Because Now I use Aeons version but then I don't get XPCs changes that he's doing.

AEon, you texture shift change was excellent, incredibly usable feature, everyone should try it and XPC should see about getting that into his branch too.
The thing is that now I don't need to go into the inspector and change the step value to 1 to adjust a texture slightly, I can keep it at 8 and just nudge it a bit when ever I want.

I think adding a marquee box is absolutely necessary.

Why alt-mouse1 and not simply mouse1?

I see the behavior of alt-mouse1 is, that you've to "fully" select objects.

Why not let (the proposed new) mouse1 drag select behave like select partial tall ?

I'm suggesting this not out of creativity, but because learned it from 1.5 and it speeds up things (unless I missed something obvious that we can't map mouse1 drag select :/ ).

I am not quite sure about this... it might conflict with normal dragging... but I am guessing the code will check for anything selected, if so, no LMB-drag will work.

XPC, 15 has it so that you need to hold shift+mouse1, not only mouse1 (how would ONLY mouse1 work when you create a brush using that, if you want that feature it's kinda like that already, but you need to use the option in the context menu). My suggestion about the alt might at well be shift. It's just in 14 and 16, there's no marquee, in 15 there's a gray box instead of the red. But gray's a bad color, it interferes with the grid and other things during default color conditions.