ZeroRadiant 1.6 Development Thread

[AEon]

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.

[Hipshot]

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 =)

[AEon]

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.

(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.

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.

[Hipshot]

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... =)

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.

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.

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

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.

[^Ghost]

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.

[AEon]

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:

Code: Select all

Edit5(269): Looked for a 'D:/Games/GtkRadiant 1.6.1/installs/Q3Pack/game/shortcuts.ini' keyboard shortcuts file, not found

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).

[Hipshot]

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

[AEon]

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.

[Theftbot]

anyway you can get q2 or nexuiz support.

[AEon]

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.

[Hipshot]

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

[AEon]

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.

[^misantropia^]

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

[AEon]

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?

[^misantropia^]

Boolean logic: yes =)

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

[AEon]

... neat... presently nothing to review, but that will probably change once I get the nerve to try more complicated stuff.

[Hipshot]

Hmm, do you still need me to write down what functions, or will you just add all buttons now?
You don't need to assign all functions to keys, just so it is possible, then I can try it.

[AEon]

Hmm, do you still need me to write down what functions, or will you just add all buttons now?
You don't need to assign all functions to keys, just so it is possible, then I can try it.

I wouldn't even try to assign keys... just adding command hooks. Since I'll try to add everything you would not really need to list anything... but I'd still be interested in what you consider important, because those functions might then get "special attention" later on.

The toolbars is another thing I want to look into later.

[Hipshot]

Alright, I need to sleep now though, don't be up to late =)
There must be other people who can input on this too...

[AEon]

^misantropia^,
I am presently looking into the File menu code used by Radiant (mainframe.cpp), here the relevant code snippet:

• http://gist.github.com/278236

Question:

• In the code block START CODE A I am wondering why certain menu entries require a g_object_set_data call - here Open... and Save... but the other menu entries do not?
• At first I though this has to do with them being linked to command hooks (i.e. they have an "accelerator", thus can be bound via shortcuts.ini), but in code block START CODE B the Pointfile..., also has a shortcut but no g_object_set_data call.
• Do some functions need to set a "state" (data) while most don't?
• Presently have the feeling these g_object_set_data calls are superfluous, though I doubt it.

Thanks.

[^misantropia^]

Yep, it's state but I don't think it's superfluous. The state gets attached to the window object which functions as a dropbox for the various modules in Radiant (module A drops it, module B picks it up). In this case, it's references to the menu items themselves that are stored. I wager it's to dynamically update the menu entries, like graying out the Save option when the map hasn't been changed yet.

[AEon]

Yep, it's state but I don't think it's superfluous. The state gets attached to the window object which functions as a dropbox for the various modules in Radiant (module A drops it, module B picks it up). In this case, it's references to the menu items themselves that are stored. I wager it's to dynamically update the menu entries, like graying out the Save option when the map hasn't been changed yet.

Hmm... the graying out of entries would have been a good idea, only that does not seem to happen. Luckily, the new command hooks I am adding for the shortcuts.ini presently work without understanding this... will look into this again later.

Thanks.

[AEon]

Well, I now have 108 new command names added, letting you bind keys to them via shortcuts.ini. This basically lets you bind almost every exiting menu entry. This should be *very* convenient.

• Present exceptions: All the entries in the Plugin menu (not sure you can actually bind those commands, todo), the explicit color settings (Misc menu), and a few other menu entries that never really worked.
• If you are interested here is the current command list - the new commands are those without a key assigned.
  • shortcut_cmd_20100117.txt @ gist.github.com
• There are a few new commands I "internally" bound to keys, these do not conflict with any existing (known keys):

  Code: Select all

    BrushArbitrarySided=1+Ctrl
    Exit=Q+Ctrl
    FindBrush=F+Ctrl+Shift
    HelpCommandList=F2
    TextureReplaceAll=F+Ctrl

• More details on my recent commits can be looked into at:
  • http://github.com/AEonZR/GtkRadiant/commits/

[Hipshot]

I need binaries to get this working right? Tried just using the .ini with my old bins, didn't really work...

[Survivor]

I'll just note the constant throwovers between the hobbes with the occasional lama inbetween amuses me. Keep on the good work.