UFO:Alien Invasion

General => User modifications => Topic started by: homunculus on December 22, 2011, 03:00:04 pm

Title: Lazy battlescape HUD
Post by: homunculus on December 22, 2011, 03:00:04 pm
This is a UFO:AI battlescape HUD that attempts to reduce the required clicking.
This makes it a convenience mod, not a gameplay mod.

Started out as an attempt to popularize mouse wheel use, but found several other ways to make the HUD more convenient, like using the weapon container as a button for shooting rather than having a small button to open the firemode list.

Main features are:

1) The rather large weapon box is used as a button for shooting (right click for shooting, left mouse button for dragging the weapon to another container or floor).
A menu of firemodes pops up when mouse hovers over weapon hand, and the firemodes in the menu can also be clicked with both mouse buttons to shoot.
Alternatively, firemode selection can be changed by mouse wheel.

2) Putting a grenade in hand is as simple as dragging the grenade from belt to hand container (without opening inventory popup, and afterwards closing it).
In the attached screenshot the secondary hand is not visible right now (because the hand is empty), but it will get highlighted when you start dragging.
I think this is a great improvement, as otherwise the inconvenience of opening the inventory popup has often been enough to make me decide in favor of shooting where using a grenade would have been more appropriate.

Also, reaction fire button displays more info (TU of the selected firemode in button label and firemode info in tooltip), option to highlight tiles that are reachable for a soldier, selected soldier panel displays wounds as little bars in main screen in 2.5-dev version, etc.

The 'readme.txt' and 'lazy.bat' are no longer included in the .zip.
Because "it is just a mod" and there are probably many (and possibly more correct) ways of enabling it.
My instructions are as follows:
Quote
the way i use this (ufo:ai battle screen hud mod) on windows xp:
extract (unpack) into userdata folder (folder 'mods' should appear next to the 'base' there):

C:\Documents and Settings\<user name>\Application Data\UFOAI\2.4\mods
(for 2.5, it would be C:\Documents and Settings\<user name>\Application Data\UFOAI\2.5-dev\mods)

and run the game (from where you installed the game) as:
ufo +set fs_gamedir mods
me being lazy enough i certainly don't type it in command prompt, but i have 'lazy.bat' in the folder where i installed the game (same folder where 'ufo.exe' is), and i use a desktop shortcut to the bat.

there are probably other ways to enable the mod, this is just what i did.

summary:
1. unpack in userdata folder
2. create lazy.bat in the folder where the game is installed.
lazy.bat contains one line: ufo +set fs_gamedir mods
3. create shortcut to lazy.bat
4. change icon of lazy.bat shortcut (if you wish) and drag the shortcut to desktop
5. 'lazy hud' should now appear in hud selection in gameplay options.
I hope this is clear, at least it looks clear to me (but I am the one who wrote it, so that doesn't mean much).
You can ask questions if something is not clear.
And I am interested in feedback, especially about things that people don't like about this HUD (because the only person I have got criticism from so far is myself).
Title: Re: A try at a wheel-intensive HUD
Post by: MCR on December 23, 2011, 05:01:38 pm
1.1, 1.2 very good idea
1.3 should be standard for all battlescape HUDs, right click could reload the weapon
1.4 good idea also
1.5 visually better than using just a string

2.1 I am not sure if I like that one, but I see your point.
2.2 2.1 implies that
2.3 it would be enough to drop it anywhere outside the weapon and belt/holster zones

3.1 also a good idea, some kind of visual level indication is nice to have
3.2 I am not sure how this would end up as it is important to see the main soldier stats of all the soldiers at one glance
3.3 the player should have more control over this one, but currently the code just allows to switch to the next visible alien or the next visible alien from the selected character, so this needs some C code to work
3.4 for consistency...

4.1 I agree (as you know).
4.2 should already be possible (OnMouseEnter, OnMouseLeave script commands)

The biggest problem you will face is the implementation of this - it looks like a LOT of work ;)

If you ask me: GO FOR IT !

You have proven already that you have great ideas regarding the UI, time to implement them :)
If you have troubles with something just ask. Someone always can help you. You could also join our IRC channel...
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on December 23, 2011, 10:54:38 pm
The biggest problem you will face is the implementation of this - it looks like a LOT of work ;)
Well, I like to work intensely, or not at all.
I hope it will be done in a few days.
If you have troubles with something just ask. Someone always can help you. You could also join our IRC channel...
No experience at IRC, but as for troubles with scripting, I certainly have some : )
I think I should concentrate on the firemode selection and shooting, that seems to be "the greatest learning barrier", before I do anything else.

2011/12/23 20:24:20 [cmd] add_hud_name
2011/12/23 20:24:20 ^2      Confunc callback
2011/12/23 20:24:20 [cmd] disable_crouch
2011/12/23 20:24:20 ^2      Confunc callback
2011/12/23 20:24:20 [cmd] disable_stand
2011/12/23 20:24:20 ^2      Confunc callback

'add_hud_name' is what is called from within the HUD from within 'func onScriptLoaded', but the other two examples look like the game might call those functions, and that would mean those functions should be implemented in the HUD, so that the HUD could, say, set the 'crouch' button to 'disabled' when the game calls 'disable_crouch'.
Now I am wondering what is the meaning of 'Confunc callback'.

And, how do I know what parameters the 'cmd' things want?
Title: Re: A try at a wheel-intensive HUD
Post by: bayo on December 23, 2011, 11:11:37 pm
I am sorry, i mostly understand nothing, else generalities.
I think you should create a more precise mockup before coding anything. Especially with a real screen size of 800x600.
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on December 23, 2011, 11:40:21 pm
I am sorry, i mostly understand nothing, else generalities.
?
Right now I have been digging into the cvar-s and cmd-s that I got from the cvarlist and cmdlist in the console, to see what is available.
That is where the questions about the meaning of 'Confunc callback' and 'cmd' arguments (like cmd "hud_fireweapon r 0;") came from.
Like trying to learn to cooperate with the framework rather than becoming a victim of the framework and the examples (bit too dramatically said, perhaps, but something in that direction).
Title: Re: A try at a wheel-intensive HUD
Post by: H-Hour on December 24, 2011, 09:25:11 am
If you haven't, you should also read about the UI scripts (http://ufoai.ninex.info/wiki/index.php/UFO-Scripts/ui/*.ufo) in our wiki. Especially the 2.4 dev node behaviours (http://ufoai.ninex.info/wiki/index.php/UI_node_behaviours/2.4-dev).

A confunc is just like a function you can create and then call as you like. For instance, you can have the following node, which, when clicked on, calls the confunc. When the confunc is called, it hides the node:

Code: [Select]
nodetype mynodename
{
invis false
onClick { cmd "my_confunc_name;" }
}

confunc my_confunc_name
{
*node:parent.mynodename@invis = true
}

The commands you are asking about are special confunc's that are called from within the game. Disable_crouch is called when the selected soldier does not have enough TUs to crouch or for whatever reason is unable to crouch. You should write a confunc into your HUD with the name "disable_crouch" and it should effect your crouch button in a way that makes it clear to the player he can not crouch.

If you search for "disable_crouch" in the existing UI files, you will find several similar confuncs that are called from within the game. (disable_stand, disable_reaction, disable_headgear, deselect_*, startreactiononce, startreactionmany).
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on December 24, 2011, 11:53:28 am
Yeah, I'll try to take 'add_hud_name' out of 'onScriptLoaded' and see what happens, to find out if add_hud_name is really a callback or not : )

I guess I should warn people not to take me very personally, some people think I am weird for nitpicking on things like that, and some people even seem to hate me a bit.
Hopefully the result is a HUD, and hopefully the script is as much according to spec as possible, nothing personal about it : )
And hopefully this "horror" will be over soon enough : )

For example, in abstractnode there is such thing as
textalign    V_UI_ALIGN    Alignement of the text into the node, or elements into blocks.
but when I used it, it crashed the game (maybe I would need a layout manager for that, but there is nothing mentioned about it).
So I guess scripting according to spec is not possible to full extent anyway (btw should I report such thing somewhere?).

And the minds of the scripters seem to have worked in the most crazy ways in the past (nothing special about me here), like in hud.ufo
window hud extends levelbuttons {
which should read as 'hud is a levelbuttons', quite an amusing exercise in imagination, I would say.

The question about cmd parameters remains atm, but it looks like it might not be a great obstacle, as I might be able to find examples with the parameters of all the commands that I need in the .ufo files.
Title: Re: A try at a wheel-intensive HUD
Post by: MCR on December 25, 2011, 01:33:22 am
The wiki maybe outdated sometimes...

The best way to learn is to analyze the ufo scripts and the C UI code.

I have integrated some of your ideas into the MiniHUD, so you can look at that file also...

I told you it is more work than one would initially think it is ;)

Do not give up  8)
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on December 25, 2011, 11:54:45 pm
There might be some ugly things that I am thinking of doing.

1) There is the container that shows the weapon, I can't seem to be able to find out how to detect that the contents of the container has changed.
But there are confuncs like reserve_shot_clear, deselect_reaction, deselect_primaryright, probably more, that get called at every click the user makes, and the 'ugly thing' would be to use those to check if contents of the container has changed.
Well, unless someone has some other idea.

2) I don't know how ugly this one is, but thinking of using 'onSelect' to make the container behave as button for shooting.
Because the container seems to consume the LMB otherwise.
Could try to use RMB for shooting, though, and maybe then reloading would be dragging ammo to weapon.
But LMB for shooting would be nice, even if it duplicates the RMB shooting.

3) There is such thing as scrollbar, and it would be nice to use scrollbar for scrollables, like level and firemode.
Scrollbar on a panel that can show one item at a time should do the trick.
But there is limited space and I would sort of like to indicate the scrollbar position as a combination of two bars in the whole background area of the selection box, which is nonstandard (and therefore, ugly solution imho, matter of taste).
It would be one bar with dark foreground and light background in forward direction, and another bar with dark foreground and transparent background in the opposite direction on top of it, so that the "scrollbar" would appear as a light bar in the center.
Like this:
|-------bar-1------->|---bar-1-background---|<-------bar-2-------|
Title: Re: A try at a wheel-intensive HUD
Post by: MCR on December 26, 2011, 09:34:47 am
1) The content of the container is the weapon, so it should be quite easy to check if the weapon changes...  ::)

2) The problem here is that you are able to drag the weapon from the container, so that is why the left mousebutton is already checked and ignored. You could create an invisible empty panel on top of the weapon, which would allow you to assign the LMB again, but you would lose the drag functionality then, which you wanna use also...

3) I'm sorry, I do not get what exactly you wanna do here  :-\
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on December 26, 2011, 12:12:18 pm
1) I guess I'll need to store the weapon in some variable, and when the user clicks then check if the weapon in the 'container right' is the same as the stored weapon. Edit: Actually I was more worried about not knowing a better shortcut.

2) No, I wouldn't loose the drag functionality : )
I would exclude a 25x25 rectangle in the lower right corner of the firemode string on top of the weapon container (and put a ghost 'hand' icon at that spot; or maybe change cursor, but I havn't tried changing cursors yet).

3) Maybe it is bit more clear this way.
I want to put two bars on top of each other (the lower one in the script would appear on top).
Code: [Select]
|----bar-1-(dark)---->|-----bar-1-background-(light)--------|
|----bar-2-background-(transparent)----|<---bar-2-(dark)----|
This way the light colored area (background of the first bar) would indicate the position in the list like a scrollbar (but without the icons at both ends).

I don't know if that now clarified it or not, but for the last 5 hours or so (lol!), I have been trying to figure out how to create such reusable component, but without success.
The thing I can't figure out how to do is child node variables based on parent node variables (tried several variations).
Code: [Select]
component bar forwardBar
{
    {
        size     <some default values here>
        max      <some default value here>
        current  <some default value here>
    }
    bar oppositeBar
    {
        <i would like size to be the same as the parent size>
        <i would like max to be the same as the max in the parent>
        <i would like to calculate current based on current in the parent>
    }
}
Tried things like:
<calculate current based on current in the parent!>
<i would like current calculated based on current in parent>
<i would like current calculated based on current in parent, please>
but nothing seemed to help.
(well, maybe not exactly like that, but the end result was the same)
Title: Re: A try at a wheel-intensive HUD
Post by: MCR on December 26, 2011, 04:49:20 pm
1) The weapons are already stored: see mn_lweapon_item and mn_rweapon_item

2) This would be a possibility

3) I would not try to code that with bars as you do not need any of the bar functionality here...
To achieve that simply take a backgound image and a foreground image and change the x size and x position of the foreground image dynamically, no ?
Title: Re: A try at a wheel-intensive HUD
Post by: geever on December 26, 2011, 05:23:12 pm
0. textalign was renamed to contentalign
1.a. onselect event of a container is called on selecting an element of the container AFAIK.
1.b. if you have weapon name in a cvar (like normal hud does), you can set up a cvar-listener to it

-geever
Title: Re: A try at a wheel-intensive HUD
Post by: bayo on December 26, 2011, 05:49:53 pm
1.b. if you have weapon name in a cvar (like normal hud does), you can set up a cvar-listener to it
Are you sure? or somebody implement it? i know it is a feature request only.
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on December 26, 2011, 06:09:28 pm
1.b. I think I saw a cvarlistener in some .ufo file yesterday.

1.a. onSelect for shooting looks unusable because each time the user drags the item, onSelect is called.
The node (with a hole) over the weapon container is better.

0. Thanks, that makes me feel better (it does feel bit strange doing things not according to spec otherwise).
Title: Re: A try at a wheel-intensive HUD
Post by: MCR on December 26, 2011, 06:15:38 pm
Are you sure? or somebody implement it? i know it is a feature request only.

http://ufoai.git.sourceforge.net/git/gitweb.cgi?p=ufoai/ufoai;a=commit;h=decae72387c22c1fd4b5c3c86f3fdde5ff475d0a

Here in use:

http://ufoai.git.sourceforge.net/git/gitweb.cgi?p=ufoai/ufoai;a=blobdiff;f=base/ufos/ui/hud_mini.ufo;h=84337a4741f011517b384952bb097205449d94de;hp=6d54d0160ad20ee928965d424b8a46d8ace358d7;hb=f87abc419d8dbec26b21915f781e5476cc42321f;hpb=b063f7cb28a16c61c397d4fe3faea98b79aadce5
Title: Re: A try at a wheel-intensive HUD
Post by: MCR on December 26, 2011, 10:10:00 pm
Take a look @ hud_phone.ufo

There you can find something like this

Code: [Select]
panel actionselection_controls {
{
pos "0 0"
size "622 768"
ghost true
}

panel buttons {
{
pos "0 0"
size "122 768"
ghost true
layout LAYOUT_TOP_DOWN_FLOW
}
custombutton up {
size "122 148"
background "hudphone/sprites/button"
icon "hudphone/sprites/arrowup"
onClick {
*node:parent.parent.elements@viewpos = ( *node:parent.parent.elements@viewpos - 150 )
}
}
custombutton down {
size "122 148"
background "hudphone/sprites/button"
icon "hudphone/sprites/arrowdown"
onClick {
*node:parent.parent.elements@viewpos = ( *node:parent.parent.elements@viewpos + 150 )
}
}
custombutton cancel {
size "122 148"
background "hudphone/sprites/button"
icon "hudphone/sprites/cancel"
onClick {
*cvar:mn_controlaction_mode = ""
*cvar:mn_control_mode = ""
call *node:root.update_control_mode
// cancel the firemode aiming
cmd "hud_movemode"
}
}
}

panel elements {
{
pos "122 0"
size "500 768"
ghost true
layout LAYOUT_TOP_DOWN_FLOW
}

confunc hud_phone_actionlistener {
if (<1> eq "begin") {
call *node:parent@removeAllChild
// call *node:parent@createChild("cancel", "hud_phone_firemodeentry")
// call *node:parent.cancel.init_cancel
} elif (<1> eq "firemode") {
call *node:parent@createChild("<2>", "hud_phone_firemodeentry")
call *node:parent.<2>.init(<2>, <3>, <4>, <5>, <6>, <7>, <8>, <9>, <10>)
} elif (<1> eq "reaction") {
call *node:parent.<2>.init_reaction(<3>)
} elif (<1> eq "reload") {
call *node:parent@createChild("<2>", "hud_phone_firemodeentry")
call *node:parent.<2>.init_reload(<2>, <3>, <4>, <5>, <6>)
} elif (<1> eq "end") {
} else {
cmd "echo firemode_listener: unknown \"<1>\" command"
}
}

}
}

It does more or less what you need to get done (& several other things ;)) - the position of the panel elements is moved up/downwards by 150 point by clicking on the up/down buttons.

Another tip: Open the console and type "debug_ui 1" without quotes to enable the UI Debug mode. Could be very helpful :)
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on December 26, 2011, 10:20:27 pm
:) relocating things works now.

hopefully assigning child node properties will also work in components.
then it should be just a bit of typing, as far as i can see.
unless... well, whatever.
Title: Re: A try at a wheel-intensive HUD
Post by: geever on December 26, 2011, 10:48:19 pm
Are you sure? or somebody implement it? i know it is a feature request only.

CVAR listener was available in C code before and mattn did the UI binding a few days ago.

-geever
Title: Re: A try at a wheel-intensive HUD
Post by: geever on December 26, 2011, 10:53:49 pm
0. Thanks, that makes me feel better (it does feel bit strange doing things not according to spec otherwise).

My fault, I badly needed align functionality for images (in building preview window for 1x1 and 2x1 building images) so I've reused the textalign stuff and renamed to show it's not for text only anymore, but I missed the wiki documentation.... because... not even know where should I doc it, I don't get the system behind it and don't know if the auto-generated behaviour pages are really auto-generated, or generated by scripts a year ago or before...

-geever
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on December 27, 2011, 05:14:12 am
Another curiosity:
Code: [Select]
confunc updateLevelStatus
{
*node:parent.controls.level.scroll@left = ((*cvar:cl_worldlevel * 50) / (*cvar:cl_maxworldlevel + 1))
// when i increase level from 0 to 1, i get this (and a crash):
// UI_GetNodeAbsPos: Node 'hud_wheel.controls.level.scroll' position 12.500000,0.000000 is not integer
}
Quote
left    V_FLOAT    Left position of the node (see also pos)
If 'left' and 'top' can be set as floats, it seems like those could be used as a way to enter 'pos' safely even if they might not be integers (seems the other way round atm--a way to enter invalid 'pos').
Probably same about 'width' and 'height', but didn't try those yet.

Any way I could force it to be int in my scipt?
Title: Re: A try at a wheel-intensive HUD
Post by: bayo on December 27, 2011, 11:13:00 am
I dont remember a function to round the number

Title: Re: A try at a wheel-intensive HUD
Post by: bayo on December 27, 2011, 06:33:54 pm
[...] and don't know if the auto-generated behaviour pages are really auto-generated, or generated by scripts a year ago or before...
I update the documentation and add comment into the page to explain how to update it. I also can create a script to autoupdate it, but not sure it is need.
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on December 31, 2011, 05:08:38 pm
Code: [Select]
cmd "ui_addcvarlistener mn_rweapon_item testlistener;"Could not register change listener, cvar 'mn_rweapon_item' wasn't found

not that it would be the only way to do it.
Title: Re: A try at a wheel-intensive HUD
Post by: bayo on January 01, 2012, 09:45:23 am
everything is on the comment.

listener do not work when:
* cvar do not exist and created later
* cvar is deleted and created again
Title: Re: A try at a wheel-intensive HUD
Post by: MCR on January 02, 2012, 01:04:32 pm
homunculus, I already posted a link, where you can see how you can use the cvarlistener correctly, see above (second link in that post):

http://ufoai.ninex.info/forum/index.php/topic,6398.msg50074.html#msg50074
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on January 07, 2012, 06:04:24 am
@MCR: Actually this is the very text I copy pasted from, and replaced with my own variable names.
So, I slowed down a bit, and tried the exact example with the insides of listener confunc replaced with echo, no error message but nothing was echoed.
The game says the update is from Dec 30 and the cvarlistener should be earlier, so I don't have many ideas at the moment.
BTW in the wiki there is such thing as spec about unimplemented but planned cvarfunc that should have done the same thing.
You were right about this thing taking more time than it looked like, I guess I'll get to the cvarlistener thing (or else a workaround) after some time.

At the moment I am doing weapon hands for the n-th time.
With moving panel visual that indicates scroll position: cannot set 'left' as float.
With double bar: the bars updating asynchronously looks wobbly.
With scrollable viewpos like in phone HUD: wheel-scrolling does not update mouse-over unless the mouse is moved (common case is the opposite), and the click seems to happen at the item that had the last mouse-over.
With one node that gets updated from invisible firemode data nodes with one bar as the visual: the scrolling seemed hard to control and the bar hard to read behind the text.
And even a little bit with vscrollbar: such a short scrollbar has the minimum bar size too long to be of any use.
 :P 8) :-[ (lots of drama)

And now I finally think I have a good version (people like images, i guess, so i'll post a little image).
A panel with firemodes is shown when the mouse enters the weapon area, and disappears when the mouse leaves the (weapon area + the panel with firemodes).
Could also be used to trigger the classic firemode selection without the extra click, I guess.
I wonder if I should make the firemode selection wheel-scrollable at all, because move-and-click seems more comfy than scroll-and-click.
Title: Re: A try at a wheel-intensive HUD
Post by: MCR on January 07, 2012, 10:18:58 am
I think the cvarlistener confunc is just allowed to contain two parameters - oldValue of the cvar, and newValue of the cvar - maybe that is the problem, but I am not sure about that.

Again it seems I have to steal ;) some ideas from you - the MiniHUD has already "wheel-intensive" options integrated, but the weapon hand is not finished & final there either...

The only thing I can say about your other troubles is: There are always many roads, which lead to Rome, so if one thing does not work like intended there is another way that does for sure ;)

Other than that: Remember that this game is WIP as is the UI and you might find things that are not intended to work like they do, not only when scripting the UI.
So if you find obvious and reproducable bugs regarding UI script commands, please write a bugreport on our sourceforge tracker and let us know about it so it can be fixed...
Bayo, the master of the UIverse, usually fixes valid reported bugs with it quite quickly...

Bugtracker: http://sourceforge.net/tracker/?group_id=157793&atid=805242


Title: Re: A try at a wheel-intensive HUD
Post by: bayo on January 07, 2012, 06:43:13 pm
Quote
master of the UIverse
i would prefer prince of the UIverse; i love Queen, but not He-Man ;)
BTW it sounds like a bug
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on January 17, 2012, 09:29:50 pm
Trying to place the soldier selection near active soldier, either to the side or at the low edge of the screen below weapons and things, I unfortunately ended up making a few compromises in the intended placements, partially caused by the space reserved by the floor container (invisible in the shot as nothing is currently being d'n'd-d).
As for the looks of it, I think I am starting to like it, and hopefully the buttons might be ok in the grid as there are not too many, but that remains to be seen.

Well, here's something to entertain people a bit with:
Title: Re: A try at a wheel-intensive HUD
Post by: MCR on January 18, 2012, 02:47:55 pm
No compromises, please ;)

Nice  8)
Title: Re: A try at a wheel-intensive HUD
Post by: homunculus on January 20, 2012, 02:06:35 pm
No compromises, please ;)
You wish : )
I did spend more time on all this trial and error than I intended, and at last I started to think more in the lines of "time's up" and concentrated more on trying to make it playable rather than keeping it as a mockup while I have cut the time I spend on scripting it.
The compromises are certainly not for heck of it, but sometimes due to the extensive time it would take to improve those issues, or even more often, they are compromises between two evils, including the script getting messy with extensive band-aids.
And, I was finding some hints that the C code might be a little bit like a can of worms, like why are some confunc called twice, e.g. like hudselect?
Band-aided some of the clearer and simpler cases like hudselect, but not quite the more vague cases like reactionfire_updated.
And on top of that, it seems like the game would like reactionfire_updated to be in some opened windows, and on top of the top of that, I don't seem to be able to override firemode_listener in a subclass.
And the loopy confunc make me suspect those might be band-aid solutions to things that might be resolved with some analysis.
As for problems that originate from the C code, there's a few seconds of video about my attitude towards those: It's in the Code (http://youtu.be/JEmklTvAkbM?t=53s).

I have attached the playable version and a screenshot in the first post now (the green dots on the ground can be turned on and off by right clicking the mutant goggles/level button).
The cosmetic glitches do not seem to be disturbing, but I do think the reaction fire associated glitches should have higher priority than, say, the glitches that could be solved by using cvarlistener.
And, I would rather remove another click from the use case of removing an item from hand by arranging the hands as:

actions (mouseover, wheel, RMB for shooting)
-hand container (wheel, RMB for shooting)
-selected firemode label (ghost)

This is because, as I now understand, if mouse is over the hand container, then mouse is also over the node that contains the hand container.
And RMB is available for use on hand container, and a click does not really need to be a click, but it is actually a press.
So the RMB on belt/holster would be unnecessary for removing an item from hand, and there could perhaps be some space for a reload button in addition to reaction fire button.
On the other hand, I find clicking the reaction fire button inconvenient, and would prefer RMB anywhere instead.
And yet on the third hand, in combination with wheeling, RMB for shooting seems better, and it might be better to enforce that habit by removing the duplicate LMB for shooting.
As you can see, there is some unresolved design confusion.

The part that I rather like and might suggest to reuse is the team panel and active soldier, it seems to work fine and I didn't need to band-aid anything there.
Didn't test with 16 soldiers though, but I guess it would work (team panel will be re-sized upwards).
Title: Re: Lazy HUD
Post by: homunculus on August 31, 2012, 08:40:24 am
Now there is a fresh version of the HUD available for download in the first post of this thread.

It finally works like I intended it to.

I wonder if the belt and backpack borders display OK at different resolutions (those borders are images, and will get scaled to fit the resolution, and some edges might look less bright as a result).
Title: Re: Lazy battlescape HUD
Post by: Norby on January 28, 2017, 08:23:34 pm
This is a very useful addon, thank you! I like very much the additional functions including the intensive mouse wheel usage.

Of course I found some parts what I imagine in other way. Thanks to the well readable script, the wiki and a few weeks of trial and error I was able to improve it further up to all of my needs. This mean many new functions and bugfixes, the code is about two times longer now. If anybody is interested then please ask me.

I attached a screenshot about my space-saver layout. If somebody ask what are these new numbers here and there then I will explain. :)

You can download Lazy HUD v2 (http://ufoai.org/forum/index.php/topic,9093.0.html) in its own topic.