• Welcome to MX Bikes Official Forum. Please login or sign up.
 
June 02, 2020, 07:51:52 PM

News:

MX Bikes beta14d available! :)


JNS' Suggestions (05/11: UI)

Started by JNS47, April 14, 2020, 09:45:12 PM

Previous topic - Next topic

JNS47

April 14, 2020, 09:45:12 PM Last Edit: May 11, 2020, 11:20:24 PM by JNS47
This thread will be updated with further suggestions, to prevent spam
(I have a lot of suggestions, just not written in full words yet. And you'll probably hate me, because most of my suggestions would be a hell lot of work to implement)

1. Binding
Today when I wanted to watch a replay I realized all those replay actions like play/pause, fast forward, ... are now binded to the numpad. The problem with this is, in b13 default binding of rotating and changing FOV in replay were bound to the numpad. So now when I want to rotate it jumps to the next/previous frame at the same time and there is no way (I think) to unbind the replay actions. It's possible however to rebind rotating and changing FOV, so I tried that. When I bound it to another button, it worked fine but I preferred having those on the numpad, so I wanted to bind it there again. Next problem: You can't bind it to the numpad anymore after changing.

So the first suggestion is to make EVERYTHING (un)bindable and add it to the settings.

But I wouldn't create a thread just to mention this, in my opinion binding needs to be reworked.
Besides all the binds in the settings there is a "control.txt" file in our profile directory but it's a pain just looking at it. You'd argue we don't need to change anything in there, if it can be done ingame.
But is that a valid argument to have ugly config files? (It's not just the controls.txt, some other config files could use a rework as well. No offense.)
And some people might really need to change something in there, for some advanced configuration which can't be done ingame. (for example changing replay rotation back to numpad keys)

My second suggestion isn't polishing the controls.txt however, but rethinking the binding concept first.
At the moment it seems like keys are bound to actions (maybe it's not implemented that way, and it just looks like in the controls.txt) but I think it's smarter to bind actions to keys.
What I mean:
a line of the controls file looks like this atm:
CTRL_CHANGEVIEW KEY 46 0.000000 0.000000 0.000000 0 10.000000 10.000000 0 1.000000 0.000000 0.000000This way it looks like it's saying "the action ("CTRL_CHANGEVIEW") can be activated with the key (46 -> 'C' on the keyboard. Don't know why tbh, since ASCII value of 'C' is 67)"
but it's better to say "the key (46) will activate the action ("CTRL_CHANGEVIEW")".

Why? Doesn't sound like a useful change, doesn't even sound like it'd change anything, right?
But there are some things which are done cleaner if the "binding a action to an key"-way is chosen in my opinion.

The first thing is having multiple keys doing the same thing.
Here's an example done in both ways, I want to bind the throttle to my XBOX Controllers RT but I want to be able to use my 'W' key on the keyboard for the throttle as well. I'll change the syntax a bit (similar to csgo's bind commands).
Action bound to key:
bind XBOX360_RT "throttle"
bind W "throttle"
Key bound to action:
bind "throttle" XBOX360_RT
bind "throttle" W
as you can see, there is two lines starting with "bind "throttle"". That's a problem if you don't read the whole file explicit but just search for the first entry of "throttle". Sure, with the action --> key-way, you have to read the whole file as well but it makes sense to do there.

Next is binding with arguments. Currently there is no changeable bind with arguments, but the autochat uses arguments (probably it does... I mean... It has to). Thats just a stylistic thing to have everything organized.
bind 1 "autochat 'gg wp'" is better than
bind autochat 1 "gg wp" because it has the action right in front of it's argument instead of having the key between those.

Lastly, where the current way of binding key to actions looks probably cleaner: Binding multiple actions to one key.
You'd just have two separate lines like this:
bind "clutch" Y
bind "shiftUp" Y
But as csgo shows you can have multiple actions on one key with the other way as well:
bind Y "clutch; shiftUp"
You can then easily separate those actions by splitting the string inside the " on semicolons.

Yes, there was a thread already suggesting multiple actions with one key and it was rejected, but I think it's a pretty useful feature even if you can't think of a use case, someone will find one for sure.
Idk, maybe having a button for moving in replay mode and decreasing speed to X before. (If there was the possibility of binding a button to set a specific speed instead of decreasing with every click)


With that aside I can talk about the syntax of the controls.txt. I guess nobody will deny it's not very readable. I mentioned csgo before and they do a pretty good job in binding I think, in this guide you can see it.
Normal binds, toggling, increment, ... they have it all.
Those binds are just console commands which are stored in a file, this file is loaded on startup.

I've created an example syntax, it's mostly similar to JSON:
InputDevices: [
Keyboard1: {
ID: ?,
AnalogKeys: {}
},
Gamepad1: {
ID: ?,
AnalogKeys: {
RT: {
deadZone: ?,
...
},
RStickX_Negative: {
...
},
RStickX_Positive: {
...
}
}
}
],
AnalogActions: [
throttle: {
linearity: ?,
...
},
rotate_left: {
...
},
rotate_right: {
...
}
],
General: [
? ? "vr_reset"
],
Menu: [
// = click (just activate for one tick), UPARROW, DOWNARROW instead of Keycodes for readability
Keyboard1 UPARROW "focus_previous",
Keyboard1 DOWNARROW "focus_next",
...
],
OnTrack: [
// ~ = analog input
Gamepad1 RT "~throttle",
// + = key down (keep active as long as key is down)
Gamepad1 Y "+clutch;shift_up",
// '\' for escaping the ' " '
Keyboard1 G "chat \"gg\"",
...
],
Replay: [
Gamepad1 RStickX_Negative "~rotate_left",
Gamepad1 RStickX_Positive "~rotate_right",
...
]
I guess most of it is pretty clear, at least with the comments. You have different bindings for being on track than in replay, ...
But why do I have deadZone bound to the key but linearity (some other settings should be there as well) bound to the action?
Well, you most likely have a dead zone because of your controller not being perfectly centered, so such stuff should be bound to the key/stick/trigger.
But if you had linearity there as well, you wouldn't have as much control. For example if you'd have front brake and rear brake on the same button, (yeah, there is a setting for combined breaks, but still you could do this.) you don't want to brake the same amount on both of them, so they need their own setting, not the keys one.

Probably would be overkill to have linearity and such for every action AND every key separated. (if I bind throttle to "W" I want it to have a linearity of 100%, on "E" I want a linearity of 80%)

I was talking about csgo having commands for binds, well... In csgo there is actually everything a command which can be used in console. ("+forward" for moving forward, "disconnect" to go back to main menu, "connect 127.0.0.1" to connect to a server, ...) So you can bind EVERYTHING if you wish, even connecting to a specific server. I think thats pretty cool, perfect if those commands could be bound to UI, (but a lot of work) but thats gonna be another suggestion I'll once post.

Oh, maybe you've seen "focus_next" and "focus_previous" in my syntax example. My thought on this is having a boolean of "focusable" on every UI Element and with "focus_next" you jump to the next UI element (mouse over/hover) which has "focusable = true" and is visible. with a bind of "element_click" you could fulfill the possibility of Controller support in the UI.


Alright, that's it for now, thanks for reading!
-Jonas

(Hope I made it clear what I mean, there might be some misunderstanding, english isn't my native language. Feel free to ask.)

JNS47

So here's part 2. It's a lot and it's kind of a mess, since I've spent so much time with some parts of it and wanted to get it posted finally, so some parts are more detailed than others.
The order doesn't have any background.

2. UI
No, I'm not asking for a prettier UI, I want to create a pretty UI myself.

2.1. Image scaling
Problem
At the moment you have to do all the calculation yourself when creating UIs, which includes images. This can be a problem, with different screen resolutions, if the image isn't big enough.

Solution
It would be cool to be able to have a fixed box-size for the image, but being able to change whether the image should be stretched to fit the box, or being kept as it is. (CSS contain and cover)
But this would need two more options to work properly:
keeping the aspect ratio of the image or changing it to fit the box
where to position the image (for both axis, horizontal and vertical: start, center, end)

2.2. More units for position and size
Problem
The only way of setting size and position of an ui element at the moment is to set the percentage of the space it takes of the axis, that's a problem when creating a square for example. You can't just set the same percentage to width and height because it's relative to the axis, which differs if you don't have a 1:1 aspect ratio.

Solution
More units. Again, I'm referring to CSS where you have
  • vh (view height - percentage relative to the height)
  • vw (view width - percentage relative to the width)
  • vmin (percentage relative to the smaller axis)
  • vmax (percentage relative to the bigger axis)
  • % (percentage relative to the containers same axis you change the value for)
But I'd also add something like
  • %w (percentage relative to the container width)
  • %h (percentage relative to the container height)
as relative units and
  • px (pixels)
as absolute unit.

Sure, there are even more, but those are probably the more important ones (ignoring font related ones like "em" and "rem").

Why absolute units? (pixels)
For example as padding or a border you sometimes want a absolute width no matter what resolution you are on, or if you want a image to be it's full size but not being stretched (because of quality loss) you could just set it's width and height to the original images size.
I know that's covered with image-scaling, but it's just an example.

2.3. maths
Why?
For example to define a start-position to something like
((3*buttonWidth)+(4*borderWidth))

What?
  • (+) addition
  • (-) subtraction
  • (*) multiplication
  • (/) division
  • (%) modulo? lol
  • (round) rounding value x to n decimals

2.4. min-width/height, max-width/height
Why?
Having definitions like
width = 10%
min-width = 100px
max-width = 300px
so the element is set to a width of 10%, but if 10% is less than 100px it's set to 100px. If it's more than 300px, it's set to 300px.

2.5. Something similar to CSS media queries (adaptive design instead of responsive)
Why?
If someone is playing on a different aspect-ratio than 16:9 you might want to layout the UI differently, which isn't as easy atm.

What?
CSS has media queries which allow you to change styles depending on (min/max)aspect-ratio, (min/max)width/height, orientation (if someone is playing 9:16, lol), resolution (something like pixels per inch) and a lot more. But those are probably the only needed ones. (at least aspect-ratio and width/height)

2.6. positioning
What?
  • Instead of (or in addition to) start- and end-positions there should be start-positions and width/height
  • Padding and margin would be pretty neat as well
  • Positioning relative to sibling elements
    positionX = ElementID.positionX + ElementID.width + 10px

Why?
width/height instead of end-positions is a must-have to reduce calculation while creating UIs.

margin might not be pretty important since you can just change position and width/height, but padding would be useful for images and text inside of containers to prevent those reaching the border of the element.

positioning relative to sibling elements could be useful when sizes change and aren't static all the time. (which would be nice)

2.7. Events and Functions for UI elements
Problem
We are pretty limited in what buttons and stuff do, we just set a id to the element and that's it. No way (None I know about at least) to bind custom functions to a button.

Solution
Instead of setting a ID to give a element a function, there could be a few events in which you can call a function or create a own one.

Event examples:
onClick
onMouseEnter
onMouseLeave
onMouseHover
onSelect(item)
For Checkboxes, Dropdowns and similar stuff
onCheck
onSelect
...

Function examples:
OpenUI(uiID)
  Testing
  Race
  Replay
  Garage
...
AddClass(ElementID, Class)
RemoveClass(ElementID, Class)
ChangeLanguage(language)
SetBikePaint(PaintID)
Exit()
ExportResult()

If we could rewrite some functions like the race result export function, it would be pretty neat.

2.8. invisible elements
I guess I don't have to explain that, just adding a style option to make a element invisible, so you can toggle the visibility without having to re-create the element.

2.9. change background
What?
It would be cool if you had the option to change the menu background (where you see your bike) to different predefined scenes (or could even create own ones).
I don't know how the background really works, but having some small maps where you can see your bike in different poses would be cool.
For example a map with just a small jump with your bike whipping (and the rider on it of course) and being able to see it from every side (like you can rotate the camera in the current background with the bike stand). Or one shredding some whoops, one with the rider just sitting on the bike, or whatever.
The bike could be dirtier in some scenes as well, so you can see your bike in race conditions.

The standard bike stand scene shouldn't be replaced of course, it should just be additional scenes you can choose.
Speaking of the bike stand scene, it would be nice, being able to turn off the rider, so just the bike is visible.

Why?
It's just a visual improvement, not necessary, but cool.

And I know it's possible to change the background already and I think it's working through maps (not sure though) but afaik it's not possible to change the pose of the rider and the bike to something else than the bike stand.

2.10. change and create elements on events
Referring to Events and Functions for UI elements I'd like to be able to change and create elements on these events. This would make the UI files a lot more readable as well. afaik changing elements on hover and click is done by naming for example the color "color2" and "color3". That's no clear naming, instead I'd suggest Json similar syntax which I'll talk about later.

2.11. elements focusable (controller support)
I explained that in my first post already, where I talked about binding. You should be able to add a line like "focusable" on UI elements and then have a bindable function to iterate through all the elements with the "focusable" line ("next focusable element", "previous focusable element") in the order they are defined.

2.12. more changeable UIs and HUD / own UI pages/HUD elements
for example:
  • chat
  • gear
  • pitboard

yes, you can change gear a bit already and the pitboard as well. But it's always the same format, I'd like to be able to do stuff like writing my time in a circle or right to left, whatever. Even if it's dumb.

So it would be nice if you just had variables which you could use in EVERY UI file.
Variables like "profiles[]", "profiles[].name", "activeProfileID", "currentBike", "currentBikePaint", ... Just everything we can see in the UI.
There are also a lot of variables which are available in plugins, using them in the UI language might be cool as well.

2.13. videos
It would be a nice addition to have videos just like bitmaps. For example as a background.

2.14. Polygons, ellipses and lines
Don't have to see a lot about that either, but it should be possible to not use the whole ellipse but cut out a rectangle or triangle out of the ellipse.
Lines should be possible to make tilted as well.

2.15. use variables and classes (for text, color, ...)
variables should be a value which can be stored, changed and used. Like saving "10px" as width, or saving the string "test" to insert as content.
classes should be a few styles which can all be applied to multiple elements. Styles defined in the element itself should overwrite class-styles.
Example:
className = {
  width = 10px;
  height = 30px;
  color = #00ff00;
}
A nice addition would be to use values from another element (I mentioned that as relative positioning), like "elementID.color"

2.16. display steam group tag in front of name
So you don't have to put your team name in your steam name and the tag is limited to users who are in the group.

2.17. add nation to display
I've read that suggestion somewhere else, I'd like it a lot.

2.18. separate stuff (manufacturer, kit, ...)
I think it would be useful to provide separated manufacturer, model and color variables for kits, helmets, boots, bikes, ... so you could add multiple dropdowns for it.
(bike - manufacturer: MSM, model: 450xf, color = paint)
(boots - manufacturer: Alpinestars, model: tech10, color: black)

I know, not everybody might like that, that's why I said just providing variables for it.

2.19. reload button in bike selection
So there is no need to switch to another paint and back to the changed one again while creating a paint.
Possible to achieve ourselves if we'd get the possibility to have functions.

2.20. search function (tracks, bikes, paints)
Again, through functions and using variables from an input field we'd be able to do this ourselves.

2.21. using everything everywhere
Instead of having predefined buttons for a page it would be better being able to use everything everywhere. Goes with the "bike+rider inspect view thing" as well. (Using it on every menu screen if you wish)
I'd also like to have this view just as a element, so it's downscaled to the size and doesn't contain the whole screen.

2.22 conditional styles
style being dependable on variables. Like making the text red if the string contains "Honda", or underline the track name, if you don't have it installed.

2.23. defining elements
I'd suggest to remove the button element or change it so it's more unique. But I think every element should have the options a button has.
Indeed I think we need just a few elements and have the real stuff that's changing it inside of it.
Like every element should have a name, position and size (always a rectangle) for sure, but also optional things like background (for a background-color), events (onClick, onHover) and content (to make it a container). So pretty much like a HTML div (sure, other HTML elements can do this too, but divs are most commonly used), which can be almost everything with the right CSS and JS.
A container can then either have more elements, a shape (another rectangle, a line, a polygon or a circle, which then has either a fixed color or a sprite to draw), text or a tooltip.

Would be perfect if it was possible to create own elements which consist out of another (or multiple) elements and just has own defined variables to change. I'll use this on the syntax example under "readability".

stackable containers
not sure, if already possible, there are "button"s inside of "item_button"s, but I guess you can't stack it deeper.

change children on parent-elements events (onClick, ...)
If I had a container which acts as a button I'd like to change all the children elements on a onClick event sent by the container. (for example changing the color of each children)

2.24. better display of server missing mods
I think just a "*" isn't the best way of marking a track as missing, so coloring it or something like this could be better. (or a variable "hasModInstalled" --> see conditional styles)

2.25. readability
do onHover, onClick, ... instead of sprite1, sprite2, ...
example:
  • onClick = {sprite()}
  • onHover = {sound()}
  • onClick = {
       hide(ELEMENT_ID);
       joinServer(ServerInfos);
    }

json like syntax
here (pastebin) is an example, I just came up with. It's a lot more lines than the current language, but a lot comes from brackets through deep containers. And a lot of it could be shortened by using element templates (if added), but I wanted to show more of the stuff I mentioned.
And I think it's a bit better readable. Especially if you had syntax highlighting for it.
There might be some things there, I didn't mention here, but no very important ones.
I'm not 100% sure if this would be a usable UI, since I haven't tested it (I mean, I have no way to test it currently) but I think it's kinda realistic stuff.

Maybe my syntax sucks, it's just my thought, not a must.

2.26. instead of changing the UI language replace it with HTML/CSS


I know that's a lot, if some stuff is planned to implement, I'd be glad to help, for example with writing a parser for all the UI language stuff (If the language is changed. I'm by far not as good with C/C++ as with C#, JS,... but if wished I'd try), or just something else. But I know it's unlikely you hook up a random guy helping with your code. :D

-Jonas