ZeroRadiant 1.6 Development Thread

[^misantropia^]

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.

That is the beauty of git and GitHub: you can clone xpc's repository and merge in the changes from AEon or vice versa. Cake, eat, too.

[AEon]

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.

Hmm... I might have to clear up a few things... sorry about the confusion:

• Yesterday right into this morning xpc and I spent setting up git (Source Control System) to make it work for me. Both of us (me a lot more obviously) are still learning to get more out of http://github.com, so this took up a lot of time.
• xpc is only human, just because I happen to have added some commits (coded out version change suggestions, basically), does not mean that xpc will not add them in his main (the real) branch. It's just a matter of time.
• I am *not* planning on my own version - it is only a test to try out ideas. The primary version will be that of xpc. And I don't really see us having different ideas, those are more or less just a discussion of possible implementations.
• As ^misantropia^ pointed out the GitHub is set up for me to "suggest" code snippets, that xpc can then very easily add to his main editor build (after some testing), so we are *not* diverging in code per se - just temporarily.
• For those confused about how Hipshot could test "my" version, I PM'ed it to him as a favor, though I do not really want to do that on a regular basis. It's not really a public version, the public versions come from xpc's releases. Personally, I don't fully trust my version, because I am still seeing disappearing clip brushes from time to time on map load.

The current feature change list:

• The changes are listed in the NEWS file when you download the latest binaries (see xpc's post above), and also mentioned on the 19651-zeroradiant-featuresbug-fixes page where you also get the binary updates.

Consolidating Ideas:

• Yes, it is getting a bit confusing, largely due to my feedback in this thread, alas.
• It would greatly help if those interested in suggesting ideas would get an account (for free) over at github.com to then explicitly suggest the idea on the mfn/GtkRadiant/issues page - by simply hitting the Create Issue button.
• Then the ideas can be suggested and discussed on a per idea basis there, making it easier to keep suggestions apart, and also get an overview what is planned.
• I had a talk with xpc, and I will be updating the "Issues" list on that page with the various suggestions from other folks and those I made - from *this* thread, spread out over separate issue posts there.

So... I hope this is not a matter of "taste" or "preference", but a matter of what we would *all* like to see updated.

Note: That some changes got done more quickly has to do with the fact that they are easy to implement, other ideas will take much more time and work to add.

xpc, might want to comment on the above though.

[AEon]

AEon, your texture shift change was excellent, incredibly usable feature [...]. 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 have to admit that I am starting to use those keys as well... just to quickly fine-tune the texture offset.

Idea:

• Setting the Grid Size should be defining the texture shift stepping (much like nudge Alt+Cursor works)? I thought that when you set the grid to 1u (1-key), that the texture shifts would then also be 1u (via normal Shift+Cursor). And that this used to be an option in Prefs. Under v1.6 I don't see any of this though. In theory implementing this could make the Ctrl+Shift+Cursor redundant, because you only need to change grid to set the shift you prefer, e.g. 1u, 2u, 4u, 8u...
  
  Update: As a test I implemented this for Ctrl+Shift+Cursor, now the texture shift is defined by the currently set grid size (1-key to 9-key). Seems to be quite convenient, question is would you folks out there want to change the grid size and back often, for this to work?

Suggestion - Texture 1° Rotate Keys?

• That brings up the idea, of creating such a key combo, Ctrl+Shift+PgUp/PGDn, to fine-tune the texture rotation. Question is, would 1° be a fine enough rotation change, or go to 0.5°?
  
  Update: Implemented... the smallest rotation angle is 1°, if you set smaller values they are reset to 0 (rotation angle is an integer in code).
  
  Reminder: You set the rotation angle for Shift+PgUp/PgDn via Prefs (P-key), Interface, Editing, Rotation increment, 45 (default)

(Sorry, suggesting ideas here in the thread again...)

[AEon]

xpc started to merge my changes into his main code, whee

Texture-centered fine control:

• Seems that Ctrl+Shift+keys can be developed into a set of texture manipulation related fine control shortcuts. So far we have Shift (GridSize controlled) and Rotation (1°), IMO trying this with Scale might get ugly? Hmmm.

[Hipshot]

Hmm, scale... Might be ugly yes.
I can't see why you would (even if possible) wanna change the scale up and down that much on too many faces. It's different with rotation and location shifting. I just mean, that too many shortcuts might be annoying, even if you don't use them - it's delicate.

It would be nice to be able to configure the keys on you own, so that you can disable things if they are "in the way" so to say.



Edit: 16 is like Winamp 5, it's the best from W2 and 3, because everyone hated only 3. And the reason I have stuck with 14 is because many things in 15 are very annoying, even though some things are really good, but for the most, only annoying.

[AEon]

Hmm, scale... Might be ugly yes.
I can't see why you would (even if possible) wanna change the scale up and down that much on too many faces. It's different with rotation and location shifting. I just mean, that too many shortcuts might be annoying, even if you don't use them - it's delicate.

True... I'd only like to have the things you would want to have at hand bound to keys. There are a few other things that could use binding (if I could only remember them ). But you are right one should not overdo it.

It would be nice to be able to configure the keys on you own, so that you can disable things if they are "in the way" so to say.

I am not quite sure about the disable part, but all the new key shortcuts, have their own "hook-in" commands, see Help menu, Shortcuts list, and these are also listed in the file aeRadiant 1.6.x\commandlist.txt:

Code: Select all

TexRotateClock1deg        Shift + Control + PageDown
TexRotateCounter1deg      Shift + Control + PageUp
TexShiftDown1u            Shift + Control + Down
TexShiftLeft1u            Shift + Control + Left
TexShiftRight1u           Shift + Control + Right
TexShiftUp1u              Shift + Control + Up

So you can remap them to anything you want. Alas not many folks seem to *ever* have used the shortcuts.ini file, in theory you would list all the hook-in commands, and leave the key shortcut empty to "deactivate" those. Never tested this though.

Edit: 16 is like Winamp 5, it's the best from W2 and 3, because everyone hated only 3.

Hopefully we can make it more usable in all the important features.


For those interested, the latest wishlist of Gtkradiant Issues on github have been updated at:

• http://github.com/mfn/GtkRadiant/issues

Hipshot, thanks for the feedback there, this really helps.

[jal_]

Alt+Cursor
Shift+Cursor
Ctrl+Shift+Cursor
Ctrl+Shift+PgUp/PGDn
Shift+PgUp/PgDn
Ctrl+Shift+keys

I wish all this cmd key combo mentallity of radiant could be changed. If something sux of radiant is not having real buttons you can find when you don't remember something :/

A perfect example of how bad it is, is a mapper I know, who was mapping for 2 years before discovering there was a SHIFT + S button to pop up a window to edit textures on patches. I don't even understand how did he manage to get some curves properly done.

I probably know less than a 25% of the key combos, and won't learn more of them either.

[Hipshot]

Yea, the combos. If it were up to me, a lot of functions could be placed on regular buttons, but you need combos for certain extended functions I guess. Also, why isn't the F-keys used? They could be mapped for filter instead of having to use ALT-key to filter many things...

[AEon]

Maybe because Alt+4 - even though it requires some finger acrobatics - requires the left hand to move less than trying to hit e.g. F4 all the way up there on the keyboard.

But good that you bring up the function keys. Usually they are connected to default toolbars, i.e. the left-most 10 buttons are F1 to F10 or something like that. Interestingly the commandlist.txt shows no Fx-key bindings, though the menu shows F1 for Help (no workie though). It might be spiffy to have the toolbar buttons mapped in this way:

• F1 x-axis Flip
  F2 x-axis Rotate
  F3 y-axis Flip
  F4 y-axis Rotate
  F5 z-axis Flip
  F6 z-axis Rotate
  
  F7 Scale X
  F8 Scale Y
  F9 Scale Z

I'd actually use those F1-F6 keys, and only just now discovered the Scale, buttons, seem to be axis lock for edge dragging... interesting.

That brings up File menu, Save as, it might help to have that mapped to the standard Ctrl+Shift+S. I use it often, because I re-save a new .map file at least once every hour, so that shortcut would get quite some use.

If you have more intelligent suggestions for Fx-key bindings, feel free to point them out.

[AEon]

I wish all this cmd key combo mentality of radiant could be changed. If something sux of radiant is not having real buttons you can find when you don't remember something :/

A perfect example of how bad it is, is a mapper I know, who was mapping for 2 years before discovering there was a SHIFT + S button to pop up a window to edit textures on patches. I don't even understand how did he manage to get some curves properly done.

I probably know less than a 25% of the key combos, and won't learn more of them either.

I am probably a bit more hardcore than most, I know most key combos for the tools I use (Ultra Edit, Directory Opus, GtkRadiant...), but you have a point. After 3.5 years I did not remember Shift+S, I was using S, because under v1.2.13 you can change patch settings from there as well (barely). This is *bad*, you need to be able to quickly look up things (I mean in menus not the Shortcuts List).

As an example, I completely remapped Directory Opus, with the following philosophy:

1. *Every* function can be looked up in the menu.
   This is the primary reference to check what a tool can do.
2. Add toolbar icons primarily to give real-time feedback on certain states... in GtkRadiant I'd like to see this for
   • modes like Rotate (exists), Edge, Vertex, and Clip (exists) - probably forgot some.
   • for all the filters (presently you always have to double-check in the menu to see if you have accidentally filtered something or not).
3. Add toolbar icons secondarily, for functions that are useful, but *not* used all the time, the x-axis Flip or Merge/Split Patch are a good example of this.
   
   I'd completely remove icons for Open and Save, that's what the menu is for, or use their shortcuts.
4. The final layer are the shortcuts, conveniently listed for lookup, providing shortcuts to all functions you often use. This includes showing the shortcuts in menus, but also for in the toolinfo (mouseover) for the toolbar icons. This way you *can* learn the shortcuts if you find the buttons too inconvenient.

IMO, with this approach a beginner can look up functions in the menus, plus look into the toolbar icons, and only after using the editor a while start using the shortcuts that can be looked up and learned quickly.

I'd want to add the new functions like Ctrl+Shift+Cursor to a submenu that lists their use. No-one would ever use them from the menu (unless submenus become detachable - under discussion presently), but you could look them up and be made aware that they exist.

Bottom line: Hands off the old key shortcuts we all have learned! (Having to relearn keys is *really* annoying).

[Hipshot]

I have to think about the func keys, I would love to have rotate on short cuts, but I don't know if it's practical enough...

What I do think is that shortcut list should be put on F1, like in most other applications, where help and similar is placed there.

[AEon]

I agree... F1 should be some sort of "real" help. I'd now start the above list with F3 for x-axis Flip, leaving F2 for something other, maybe help related, i.e. open up the Shortcut list window from the Help menu.

[Hipshot]

It's better you start with F5 if so. Else there will be a gap in the mid of the axis-rotate keys =)

[AEon]

That brings up File menu, Save as, it might help to have that mapped to the standard Ctrl+Shift+S. I use it often, because I re-save a new .map file at least once every hour, so that shortcut would get quite some use.

Just noted that Make Structural uses Ctrl+Shift+S... oops. So that shortcut is taken.

[cityy]

Would it be possible to merge "make detail" and "make structural" to one key - so that you have some kind of toggle function?

[AEon]

Would it be possible to merge "make detail" and "make structural" to one key - so that you have some kind of toggle function?

That would probably be possible, through we have a shortcut for each function. A toggle would need to use one or even both of those shortcuts, leading to confusion for old-timers used to "blindly" using them, IMO. Maybe for a new toolbar icon instead?

[extone]

i have one suggestion - adding "shift" modifier to cursor while in 3d view reducing (or increasing) camera speed by 5x

[cityy]

Hm, you are probably right - the toolbar entry sounds good.

[AEon]

i have one suggestion - adding "shift" modifier to cursor while in 3d view reducing (or increasing) camera speed by 5x

Yes, when in "fly mode", using the cursor keys can be pretty slow when navigation a larger map. That's the reason I started to place the camera in XY View with Ctrl+MMB recently. An "acceleration key" could be convenient.

Added your suggestion and that of cityy to the Radiant v1.6.x Issues (wish) list.

[obsidian]

I'd be rather careful about implementing all suggested shortcuts, since everyone has different needs for certain things, one may like it one way, someone may like it another way, and it's hard to accomodate both without pissing someone off. Especially for the old-school bunch who have been so used to the keys as they are, relearning new shortcuts or having them completely remapped would be completely crippling.

Perhaps do a brainstorm of all the extra features and shortcuts and see what would make sense more while other ones may be better left out. For the vast majority, I would perhaps assign handlers in the program to have it as an additional option that the user can set whatever keys they want, but disabled by default. If you wanted them enabled, you can just assign them to whatever you want.

As an example, that shift key acceleration might be useful for some who are used to working in the camera view a lot, but personally, I would just move the camera using CTRL+MMB on the grid. I would prefer to keep the shift key strictly as a modifier, like CTRL and ALT. The idea is, getting used to CTRL+MMB might be the easiest solution for most people negating the need for a shift accelerator. If that's really how you prefer it, you can then choose to enable it by assigning whatever key you want to do the camera acceleration.

A lot of people didn't like using GtkRadiant 1.5 because a number of the shortcuts have changed from 1.4 and it really threw a lot of people off. Despite all the extra new features, faster performance and new GTK2 toolkit, a lot of people are still stuck on 1.4 because that has the keys stuck to the way they want. It's hard for old dogs to learn new tricks, is all I'm saying.

[AEon]

I am completely against remapping of old keys. The old keys should stay as they are. I am only discussion *additional* key shortcuts that do *not* conflict with the core shortcuts we all know.

And as mentioned most shortcuts can be redefined as you like, via shortcuts.ini. Only no one will ever do that. So it's either you have new keys added or you don't have them at all. No one will fiddle with a shortcuts.ini file to "selectively" turn on keys.

One thing I do agree on is the brainstorm idea, i.e.

• What are the functions that you have used a *lot*, but never had a shortcut assigned to?

If we get a consolidated list together, we can see what could actually be implemented. I have not done any mapping lately, but I am sure using the editor would remind folks quickly what is amiss.

Update: Alas, just noted in code, that those functions presented in the menus that do not already have a key assigned, will also *not* have a command hook letting you actually reassign a key combination via shortcuts.ini. E.g. Save as, has no command hook. Hmmm... guess this is something for the Issue list. Expanding the command hook list on the other hand will probably lead to slowdowns.

[obsidian]

What I mean is that you have to be really selectful of what additional functions you do add in. Even small shortcut additions can throw someone off if they hit the wrong key combination.

[Silicone_Milk]

A lot of people didn't like using GtkRadiant 1.5 because a number of the shortcuts have changed from 1.4 and it really threw a lot of people off. Despite all the extra new features, faster performance and new GTK2 toolkit, a lot of people are still stuck on 1.4 because that has the keys stuck to the way they want. It's hard for old dogs to learn new tricks, is all I'm saying.

I'm still on 1.4 mostly because of that exact reason.

[AEon]

Submenus can now be detached in the editor, this lets you place the bobtoolz right next to the views on your desktop, every function becomes a one-click operation, *finally*. By detaching the Filter submenu, you can set filters quickly, plus have a real-tie filter status in view, very nifty IMO.

This brings up an idea. The detached Filter windows shows the shortcuts as well, these make the window quite wide (turning them off does not seem to be trivial for detached menus only), so...

Would the folks here understand a shortcut like:

Code: Select all

World         A+1
Structural  S+C+D
Patches       C+P

as replacement for

Code: Select all

World              Alt+1
Structural  Shift+Ctrl+D
Patches           Ctrl+P

? (Wonder if GTK lets you set bold in menu text, e.g. for the shortcut letters Structural S+C+D).


Another thing I always found strange is the order the Qualifiers are presented in the menus, here examples of what other tools do:

Code: Select all

GtkRadiant 16   Shift + Ctrl  + Alt   +
GtkRadiant 1213 Shft  + Ctl   + Alt   +

UltraEdit       Alt   + Ctrl  + Shift +
Notepad++       Ctrl  + Alt   + Shift +
Photoshop       Alt   + Shft  + Ctrl  +

Opus            Ctrl  + Shift + Alt   +
Firefox         Ctrl  + Shift + Alt   +
Visual C++ 2008 Ctrl  + Shift + Alt   +

Personally I'd go for Ctrl + Shift + Alt +... you can probably tell I am bit bored . But I always found it weird to see the Shift before a Ctrl.

[^misantropia^]

? (Wonder if GTK lets you set bold in menu text, e.g. for the shortcut letters Structural S+C+D).

Not without an unseemly amount of hacking. And besides, you probably shouldn't do this anyway. Anything that deviates from the standard UI makes a new user do a double check and that is a Bad Thing.