Hotkey Profiles Proposal

[Conzar]

Greetings,
  I am planning on implementing Hotkeys for buildings/units abilities.  This will also incorporate the idea of profiles so that players can remap the default keys if they like.  The profiles will be faction dependent.  The default hotkeys will be included in the xml of the units.  The default keys will be used to build the profile.  There will also be global hotkeys (similar to how the hotkeys currently work).  Hotkeys like move, attack, screenshot are considered global and can be set for player profiles as well.

A list of TODO's to make this happen.

• Add default hotkeys to all factions
• Add new class for Handling profiles
• Add parsing code to build default profile from xml
• Add code for handling key events with profile (update the current menu class that handles the hotkeys)
• Add new menu system for creating and modifying hotkeys

Here is an example of a GUI for editing profiles: SC2 Hotkey Profile Editor

Is this ok?  Is anyone else working on this?

[titi]

Hotkeys would be great but we are facing several problems with this!
As you might have seen I also added a menu in the options menu to set hot keys. But I skipped it for the moment because it gets too complicated and use it just to show the keys at the moment.

The problems and things I faced:
- Megaglest uses SDL only now for key input. But original glest used different methods for windows and otheres. By this glest had his own abstraction layer for keyboard inputs. This has to be removed completly until you start anything with keyboards!
This Change is HIGH PRIORITY and very much welcomed if you look for it!

- Keyboard settings have to be shown to the user somehow. For this we need a display ( to String ) method for all keyboard inputs we want to support. I didn't found a good/common possibility for this.

- For showing the keys we might be able to use UTF8 and for utf8 we might need charsets which support all the utf8 things ....

These are all not so funny things but I think we have to face them one day ....
The minimum is the SDL input thing and way to display the keys. I think this is what you should start with.
Then build a global keysetup ( maybe we should introduce wxwidget in this context ) and after this is done the specific one for each faction which is faction specific.
On top you maybe have to think about user profiles .....

All in all this is a really big thing! And I would really love to see this addressed!
( before you start with this we should look together at all the patches you made for MG and if/how to take them over to the MG mainline. Best is if we meet in the chat )

[olaus]

hi titi,

you asked in my sf-feature-request about the best place for the highlighted key (with the problem that it might not appear in the unit-or command-name) doing it in the icon like there would be perfect:

Here is an example of a GUI for editing profiles: SC2 Hotkey Profile Editor

... except that the icons in MG are far smaller (i think they're anyway too small, i mostly move the mouse over the icon to read the text)

regards olaus

[Conzar]

If I were developing a Java game, I would use the jinput library.  It has support for osx, windows, and gnu/linux and have used it in several of my own projects.  I would love to port glest to using the jMonkeyEngine so glest would be enjoying the java goodness.  But I guess that might be crazy talk.

So what are the problems with using SDL for handling keyboard events?

[titi]

There are no problems using SDL! As I said We already use it, but there is still a glest abstraction layer used yet , which has to be eliminated ....

.... and you talk about java/glest :-)
I once tried it a bit just for fun with the jmonkey engine:

Code: [Select]

http://jmonkeyengine.org/groups/graphics/forum/topic/splatting-in-jme2-jglestI was able to load/show g3d models including animations too, but I was facing too much work, so I gave it up.

[Conzar]

There are no problems using SDL! As I said We already use it, but there is still a glest abstraction layer used yet , which has to be eliminated ....

.... and you talk about java/glest :-)
I once tried it a bit just for fun with the jmonkey engine:

Code: [Select]

http://jmonkeyengine.org/groups/graphics/forum/topic/splatting-in-jme2-jglestI was able to load/show g3d models including animations too, but I was facing too much work, so I gave it up.

OH, so basically SDL should be the only library used for handling keyboard events.  I will look into removing everything not SDL.

As for your jme implementation, awesome  !!!!  Do you still have the code, when did you work on it, and what made you interested in starting the project?  What would you use for networking (I just found this kryonet)?  Any interest in continuing work on it if you had help?

[Conzar]

I was thinking about the work Titi has already done with jme and how to fit that into glest.  What if we built a new map editor and unit viewer using jme?  That way we don't need to re-implement the whole game but we can add some needed features for the map editor like:

• instant viewing of the rendered map - meaning, you click on a button and view the map in 3d
• automatic screenshot for map-preview
• automatic map-preview generation (instead of zooming out a great distance, this instead generates a 2d stylized image that shows the basics of the terrain and highlights the resource patches )
• Adding g3d objects into the 3d render of the map (this is extremely useful for unit/building designers because they can easily see how their models look in relation to the map environment)
• Show g3d objects (like how the g3d viewer works already

My thinking is that this tool will be directed at modders and map makers.  Sort of a one stop interface for all glest related content integrating.

What do you think?

[will]

I think a 'modding' menu that appeared in-game when its paused that let you terraform would be the best approach.  You could imagine scenarios and such being built from people's 'save game' even.

Creating an alternative yet compatible renderer is hard work, and keeping it in sync is much harder.  The g3d_viewer in MG and GAE regularly breaks, doesn't use quite the same renderer as the game and so on.  Its already a nightmare and clearly we have trouble finding people finding time to keep it up to date.

I'm going for the in-game map making myself in my new engine, so as to avoid having two or more tools to keep updated.

[Omega]

I don't think I like the concept of building the editor in java... By having all parts of the product c++, we keep them more standardized and can go from one project to another with ease and with the same compiler.