Quake3World

cityy wrote: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?

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

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

extone wrote: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.

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.

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.

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.

obsidian wrote: 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.

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: as replacement for ? (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: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.

AEon wrote:? (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.

AEon wrote:Ctrl + Shift + Alt +...

The menus and submenus show the Qualifiers in that order... looks nice and consistent with other tools now. Have it on HD as commit, but this will probably not make it into a release, required some "hacking". Note the "Page Down" and "Page Up" have been replaced with the more compact PgDn and PgUp. (By some accident, it actually removed the shortcuts from the detached menus, but then the original menu, also loses the shortcuts... oh well, just testing )



Oh, also demonstrates xpc's new code for detachable submenus.

Why would you wanna detach those menus when they won't be on top anyway. It's a bit annoying...
Don't misunderstand, it's cool and nice feature, but if you detach a menu and places it over the grid, it will disappear if you work on the grid....

And I don't agree with the state that no original keys should be modified. It's not like Radiant is some kind of effective editor when it comes to shortcuts and if it's ever going to be possible to have normal (modern) camera movement in this editor somethings got to give (people that wants a WASD movement in the cam view can't for sure believe that "s" will stay as surface inspector?) . Also, since a lot of people are using space to duplicate groups and selections here, it's a mystery why there's no short for rotating somewhere in the left area of the keyboard that is easy to reach.

But I don't really care, if I ever get a way to change keys myself, this problem would not exist and everyone would be happy =)

Hipshot wrote:Why would you wanna detach those menus when they won't be on top anyway. It's a bit annoying...

Use the tool you suggested always-on-top.exe for now. I hope a new release will be available soon.

Hipshot wrote:(people that want a WASD movement in the cam view can't for sure believe that "s" will stay as surface inspector?) .

Oh, I do ... I'd suggest making those keys strictly modal to the "fly mode", meaning after a RMB-click in the Camera view, the "normal" S-key for the Surface Inspector will no longer be available... it will be used as Cursor key replacement. Same for the other keys.

Who ever would want to switch on the Surface Inspector when in "fly mode" anyway? At least that is my hope. The keys for the camera movement can already be remapped, but this does not yet work properly, because the "key-up" event for non-cursor keys is ignored for some reason.

Hipshot wrote:Also, since a lot of people are using space to duplicate groups and selections here, it's a mystery why there's no short for rotating somewhere in the left area of the keyboard that is easy to reach.

Do you mean the toolbar function z-axis Rotate or the like? Or are you referring to what Cursor Left/Right do, i.e. rotate the Camera view left and right? If you did mean the latter, A,D would do the rotation, ironically. Why not done before, probably because all the other keys are already in use on the left of the keyboard.

Personally I find the bindings of a,z (on the German keyboard it's y, and thus does not work BTW) and d,c completely useless. If I want to change the view I use the "fly mode".

But I don't really care, if I ever get a way to change keys myself, this problem would not exist and everyone would be happy =)

Hmm... did you actually ever try to use the shortcuts.ini file? If not, then you should - if you did, then it would be of interest what you wanted to change/bind but could not.

Things can only be improved if they are explicitly stated.

AEon wrote:Use the tool you suggested always-on-top.exe for now. I hope a new release will be available soon.

Yes, ofc I can, but you know - that's not really a global solution for anyone else to use... =)

AEon wrote:Oh, I do ;)... I'd suggest making those keys strictly modal to the "fly mode", meaning after a RMB-click in the Camera view, the "normal" S-key for the Surface Inspector will no longer be available... it will be used as Cursor key replacement. Same for the other keys.
Who ever would want to switch on the Surface Inspector when in "fly mode" anyway? At least that is my hope.

Yea, you're right, I didn't think about that. I mean, you can toggle it while flying, but then it goes out of fly mode - kinda breaks the flight - seems better to disable it then yes. You can't really move the mouse to the inspector when it's locked in the 3d view anyway.

AEon wrote:The keys for the camera movement can already be remapped, but this does not yet work properly, because the "key-up" event for non-cursor keys is ignored for some reason.

Tried this in "NetRadiant" I think (shortcuts.ini), and that didn't work and I didn't really try any other command, so I just though it was a broken file.

AEon wrote:Do you mean the toolbar function z-axis Rotate or the like? Or are you referring to what Cursor Left/Right do, i.e. rotate the Camera view left and right? If you did mean the latter, A,D would do the rotation, ironically. Why not done before, probably because all the other keys are already in use on the left of the keyboard.

Personally I find the bindings of a,z (on the German keyboard it's y, and thus does not work BTW) and d,c completely useless. If I want to change the view I use the "fly mode".

I meant the axis rotate of brushes. And the most suitable keys for that would be "X, C, V" I guess. But V is tied to vertex mode and B to bend. Functions that might as well be moved up to F and G. And Who uses bend mode anyway, it's a broken feature (or the rotation is set to "R, F, C", but then R needs to be remapped, since that is free rotation now.
And about that camera shifting with the keyboard, I find that totally useless too. I used that for Quark back in 1998 - today, you can't seriously use that...

AEon wrote: Hmm... did you actually ever try to use the shortcuts.ini file? If not, then you should - if you did, then it would be of interest what you wanted to change/bind but could not.

Things can only be improved if they are explicitly stated.

Read up a few quotes about the ini...
And yes, ofc the problems needs to be explicit stated. And I fully understand that people won't want the keys to change. I just want them to be more effective. In a perfect world there would be a preference option that lets you chose old key setup and new key setup... Just loads two different key settings files... one default and one that can be changed.

id like to throw my 2 cents in... in codradiant.. u can naturalize textures in the surface inspector view.. rather than having to do ctrl + n, maybe u guys can add this in if possible.

Hipshot,
it occurred to me that it might help to have the editor save the actual shortcuts.ini format, either right into the commandlist.txt file or a new file called e.g. shortcut_cmds.ini, letting those interested simply copy/paste the keys they want to change, into the actual shortcuts.ini. This way the shortcut_cmds.ini would always reflect the up to date "hook commands" available.

Did not read much complaining about the shortcuts.ini here at LEM, any links what "other" problems there are?

It should not be to difficult to let the user chose a shortcut.ini (filenname) of their own choice in Prefs, allowing for different setups, or to turn off external remapping. As I understand it, you only need to mention the keys you what to remap (well you'd have to look out for key conflicts obviously and remap the conflicting keys as well).

If you like I could help you set up your keys in a shortcuts.ini file letting me better see what problems there are in doing that.


Update: First thing is to find out where exactly the shortcuts.ini is supposed to be loaded from by the editor. For this run the editor, then open the console O-key, Ctrl-A (select all the text), copy and past it into some editor, letting your search the log.

As it turns out my install method, i.e. install the last official release v1.6.1, then duplicate that folder, unpack xpc binary releases into it - does not quite work, namely: Even though I am running the editor from the D:/Games/aeRadiant 1.6.x/ (and many things actually do get loaded from here, the above resources (5 removed) are loaded from the last full install folder D:/Games/GtkRadiant 1.6.1/. Not good.

For now I'd have to change the 'D:/Games/GtkRadiant 1.6.1/installs/Q3Pack/game/shortcuts.ini' file (check in your console dump were that is exactly for you).

Update II: There is a Prefs, Other, Paths, User INI path, though it does not seem to let you point it to *you* shortcuts.ini (i.e. the file seems to be ignored by the editor).

AEon wrote:If you like I could help you set up your keys in a shortcuts.ini file letting me better see what problems there are in doing that.

I would love to go back and test changes to that file, but... - I have none. No one in the entire games folder... And I have 3 Radiants installed...

They are pretty well hidden... I am presently working on an updated shortcuts.sample file with instructions on how to use it, plus the latest list of internal commands listed in such a way to be usable right away. Still need to code some of this though, and also take a closer look how "flexible" the shortcuts.ini code actually is.

Testing the attachments here, added a beta shortcuts.ini file... this uses *age old* key bindings, still from QERadiant it seems. But should get you going. Please follow the above steps on the editor console, to find out were to place the file and take a look at the info I typed in the file. I'd recommend using a file that only replaces a few keys (deleting most of the entries after the [Command] block) for testing.

anyway you can get q2 or nexuiz support.

Hipshot,
So here is the new shortcuts.ini.sample16 file I edited, providing a lot of info on how to get the shortcuts going, and an updated list with the actual commands & shortcuts the editor v1.6.x uses:

• shortcuts.ini.sample16 @ github.com

The latest code I checked in converts the commandlist.txt file into a format that can be directly used in the shortcuts.ini. Not really a big deal, but it should help in the future. If you had wanted it would have been possible - with some editing - to convert the commandlist.txt file manually, but since we are lazy...

Hope we can up the new binaries soon...

Note: My recent changes are not required to use the above, the last MFN binaries should work just as well.

Hope that helps those interested in remapping their keys.

Sorry for my absence, a bit too much right now when work started again.
However, your file works, but as long as certain commands are excluded, like brush rotate, I don't really have a need to change keys. But I have tried and the file works fine, I changed some bindings to the Func buttons, that's nice for me.

What I wanna be able to bind is "remove" the grid from the regular numbers and just have them at the numpad, I would like to be able to bind rotate and so... Seems some functions in the editor just doesn't exist in the ini...

At some point I might really need to recode the routine that loads the shortcuts.ini... I could fix the 1-0 vs. KP1-KP0 issue by defining new commands like SetGrid1Alt (as secondary command hook for SetGrid1), letting you define the grid keys as you like... i.e. 2 different keys turning the SetGrid1 on/off. Alas this would *really* start to bloat the internal Command list.

The functions you would like to bind do not have a command hook attached presently, they can only be accessed via menus.

I'll have to talk with xpc about this... in my "Design Philosophy" mentioned further up, I'd want to make all menu commands available to be bound to keys. Note: Most of them would not have a key set, but you could set the key if you liked.

Hipshot, it should be no problem to define another 10-15 more such "command hooks" for functions folks really would want to bind keys to. I'd then simply add the hooks. The beauty of this, run Shortcuts list, and a new shortcut_cmd.txt will be created listing the new hooks. Please explicitly list what functions you'd like to assign to keys.

Coder note: I have the feeling adding command hooks for all editor functions may slow down a few things... hmm... will need testing.

Psa. Computers are fast. Add those hooks and be done with it. If you want, I'll review your code.

^misantropia^ wrote:Psa. Computers are fast. Add those hooks and be done with it. If you want, I'll review your code.

Good to hear... my old PC should be a good test bed to check on slowdowns. If it's fast enough on my PC, it will be pretty fast on any modern PC.

Since all such stuff is at github.com the diff in the source can be looked at, and I'll probably have some binaries out as well. Hope xpc is with us again this weekend. Thank for the review offer, addition checking is always a good thing.

^misantropia^,
do you have experience with the editor's C++ code? Or just C++ and GTK?

Boolean logic: yes =)

Point me to the relevant commits and I'll have a look.