Cervator edit: Moved to Incubator, added header Name: Client Settings (GUI) Summary: An options UI providing game settings and in particular custom key bindings Scope: Engine (and supports mods) Current Goal: Stabilize and add more options Phase: Maintenance Curator: @ddr2 taking over from @overdhose who built on top of stuff by @Immortius and @ironchefpython Related: Other GUI threads had a need to have some config settings of my own, delayed it long enough here is what I made, might be temp solution, let me know if it's acceptable I created a ModData and MinionData proto respectively.
I'll include experimental options to enable / disable sound / music, think we had an issue open for that, can be moved to general settings later, I prefer not to interfere with existing things
heh ok that shouldn't be to hard looking at the issues I'll see what I can do for the jumping and the keybinding, about keybinding though, I'm thinking of adding a seperate screen like modData called InputData, with matching proto. Might have azerty defaults though
to easily map mouse and key buttons, I used this trick : Code: public int getKey(String skey) { if(skey.startsWith("MOUSE")) { if(skey == "MOUSELEFT"){ return 256; }else if(skey == "MOUSERIGHT"){ return 257; }else if(skey == "MOUSEMIDDLE"){ return 258; }else if(skey == "MOUSEWHEELUP"){ return 259; }else if(skey == "MOUSEWHEELDOWN"){ return 260; }else { return 261; } }else { return Keyboard.getKeyIndex("KEY_" + skey); } } so mapping keys in the config screen uses the default Keyboard enum values and the Mouse values in the function. Let me know if you don't like it.
InputSystem code Code: private int linkMouseByConfig(int button) { switch(button){ case 256 : return 0; case 257 : return 1; case 258 : return 2; case 259 : return +1; case 260 : return -1; default: return 2; } } private void REPLACE_THIS_WITH_CONFIG() { InputConfig inputConfig = InputConfig.getInstance(); int keyvalue; registerBindButton(InventoryButton.ID, "Inventory", new InventoryButton()); keyvalue = inputConfig.getKeyInventory(); if(keyvalue < 256){ linkBindButtonToKey(keyvalue, InventoryButton.ID); }else{ linkBindButtonToMouse(linkMouseByConfig(keyvalue), InventoryButton.ID); }
all that extra work what I wanted to do was toy around with the controller input yet another screen I'll need to add after all this.
should this be kept together or split? optional bool animated_water_and_grass = 19 [default = false];
Animated water is gone for the time being anyhow (animated vertices). We'll just need "animated grass".
I've pushed the stuff to develop. All you need to enabled the water reflection is to adjust... in the Config class. If you want to add this to your config menu, make sure to trigger a shader recompile. This incorporates some compiler directives in the chunk shader.
I wish I knew what you were saying I'll uch make the screens and add options, you might have to add the trigger yourself
Thanks begla. IronChefPython deserves thanks too as he contributed the foundations of the Input System and got the ball rolling. @overdhose - I like what you are doing, but have some suggestions around the persistence of the config. It would be nice if the config files were in a human editable format - I would suggest using Java Bean + gson instead of protobuf to save the config as JSON. Then for the the keys/mouse buttons you could store the string name of the button (using Keyboard.getKeyName() and Mouse.getButtonName()), prefixed with KEY_ or MOUSE_ respectively (assuming that is appropriate). You can then convert back by reading off the prefix and using Keyboard.getKeyIndex() and Mouse.getButtonIndex() respectively, plus some quick checks for the mouse wheel names. This would also handle mice with more than 3 buttons (such as mine ) A nice format for the input may be something along the lines of: Code: { "input" : { "engine" : { "moveForwards" : "KEY_W", "moveBackwards" : "KEY_S", "fire" : "MOUSE_1" ..... }, "minions" : { "toggleMinionMode" : "KEY_X" } } } So the inputs are grouped by their owning mod. I realize this probably would perform a bit worse than just storing the integer values like you are doing, but since this would be done rarely (only during load, plus a small amount when updating inputs), it should be acceptable.
I was planning to add a whole interface to that thing so you wouldn't need to edit the file yourself. So human readable seemed less necessary. I'm gonna finish this round first, will look into changing it into gson. I only copied the config way of doing things tbh, I'm already glad I made it a seperate file.
sneak peak : input screen must be about the most boring thing I did in Terasology. It leaves room to add stuff, if this seems unnecessary let me know I can center it more I was pondering what would be the best way to add mod related button configs, maybe a button with the mods name that opens a seperate screen? Might get crowded though. I initially thought of adding it in the mods... section but that might be counter intuitive spreading it so far out.
Maybe now is the right time to introduce UI layouts! Like a simple centering one. So you don't have to do that manually all the time.
yeah I considered that myself, even a full fledged ui editor Just as a fyi : the most work is actually copy pasting the same thing over and over again, the positioning was actually pretty fast, hence the editor idea
I've merged this code to our integrate branch after testing that it (mostly) works, or at least doesn't break too much Feels a bit like the key mappings are stuck in AZERTY or something? But testing around with different keys (oohh, I forgot what 'r' did!)I can move enough to prove to myself that the game still works - now we just need to make the key mapping popup work! I've discussed with new contributor @ddr2 on IRC and am tagging him as curator for this feature, taking over from @overdhose (who'll be in hibernation due to RL for a while). There are other potential interested parties too, join in if you're available, this is the perfect time! I also moved this thread to the Incubator and added the standard header
