Advanced HUD Tools

[InfectiousFight]

Use the line tool and just set it up yourself. Its just simple trig.

a) Lines are small, hard to see
b) Would only clearly show roll, not pitch.

[Hurricaaane]

Excuse me, but I've read the entire thread, and I still don't know why my advanced HUD doesn't appear when I'm sitting on a linked chair. Show in my HUD is disabled, I want only it to show when I'm in the vehicle, and I used a reload on the Advanced HUD pole once, then reload on the chair to link it. Just to check, I tried the same with the pole then a prop, and I see the error message, indicating that the double reload was the right operation.
When I check "Show in my HUD", I see it in the place I want it to appear.

I think I described all the information so you may help me. Could you? Thanks.

[moggie100]

a) Lines are small, hard to see
b) Would only clearly show roll, not pitch.

a) Depends on resolution
b) Depends on the style really...

But either way, that's rather a complex item to draw manually, so using a texture or two would be ideal, but I'm still having issues with them.

Stuff will be added, but I've had to slow development for the moment, being at uni an all.

Excuse me, but I've read the entire thread, and I still don't know why my advanced HUD doesn't appear when I'm sitting on a linked chair. Show in my HUD is disabled, I want only it to show when I'm in the vehicle, and I used a reload on the Advanced HUD pole once, then reload on the chair to link it. Just to check, I tried the same with the pole then a prop, and I see the error message, indicating that the double reload was the right operation.
When I check "Show in my HUD", I see it in the place I want it to appear.

I think I described all the information so you may help me. Could you? Thanks.

I need more details:

Which style of indicator?
Which position mode?
Any other settings you've set?

[Hurricaaane]

I need more details:

Which style of indicator?
Which position mode?
Any other settings you've set?

I tried with both a Square to Corner with World Coordinates, and a basic horizontal fill bar with Screen Position.
If I check "Show in my HUD" checkbox, I can see them in the right place, but I want them to show up for any player when in a vehicle, but It doesn't even show up for me on the chair.

Thanks already.

[Urablahblah]

So assuming you haven't stopped working on this Moggie, I thought of another idea. An ellipse indicator. Give it XYZ (Or ScreenXY accordingly) and a width and height (and possibly rotation). You could use it for all sorts of applications such as artificial horizons, gauges, and whatever else. Just a thought.

[InfectiousFight]

Any word on if you'll make a hi-speed version in the vein of a console screen? I.E., one device, lots of addresses, regularly spaced addresses for each unit. Difference being, here, it's not pixels, it's HUD overlays.
Perhaps, the most user-friendly way, would be to define up to, say, 64 (or any convenient number) different indicators using the STool (selecting them with a drop-down box, obviously), and setting up their settings and stuff, but those 64 indicators taking their values and positions and whatnot, from a set of hi-speed memory addresses, e.g.:
0 - On/off
1 - Value
2 - X-coord
3 - Y-coord
4 - Z-coord (if applicable)
Repeat, 5-6-7-8-9, 10-11-12-13-14, etc.
This way, people good with a CPU, could use a whole bunch of different indicators without crowding their contraption with entities, sapping both space and processor power for the physics calculations.

Still, I love this little device and if I have to pack 18 of them into Plane v3, so be it.

[moggie100]

I LIVE!

Sorry for the delays guys, 'tis the season after all... that season being coursework season at uni!

My time as of late has been rather limited, but that should change fairly soon, as I've only got 4 weeks of term left, then its the holidays again (woo!) so I'll have time then, if not sooner.

Ok... to the questions...

I tried with both a Square to Corner with World Coordinates, and a basic horizontal fill bar with Screen Position.
If I check "Show in my HUD" checkbox, I can see them in the right place, but I want them to show up for any player when in a vehicle, but It doesn't even show up for me on the chair.

Hmm... this looks to be a kind of desynchronisation issue... the serverside component hasn't sent stuff before the state change so the clientside rendering doesn't happen... I'll look into this (might require a good bit of rewriting... but I might do that anyhow).

As a workaround for now, if you want to have an indicator in a chair, spawn it with the settings you want, hit it again as if you were changing them, then link it. That seemed to work for me.

So assuming you haven't stopped working on this Moggie, I thought of another idea. An ellipse indicator. Give it XYZ (Or ScreenXY accordingly) and a width and height (and possibly rotation). You could use it for all sorts of applications such as artificial horizons, gauges, and whatever else. Just a thought.

Oddly, (as I've pointed out before) there isn't a circle drawing command (that I have found, anyhow) so I'd have to write my own... which is easy, except slow, so this might be an oddly laggy thing to include :/

One option for this, however, is to draw it as a texture, but they have their own 'special' issues

I'll have a look once I've gotten more critical things done.

Any word on if you'll make a hi-speed version in the vein of a console screen? I.E., one device, lots of addresses, regularly spaced addresses for each unit. Difference being, here, it's not pixels, it's HUD overlays.
Perhaps, the most user-friendly way, would be to define up to, say, 64 (or any convenient number) different indicators using the STool (selecting them with a drop-down box, obviously), and setting up their settings and stuff, but those 64 indicators taking their values and positions and whatnot, from a set of hi-speed memory addresses, e.g.:
0 - On/off
1 - Value
2 - X-coord
3 - Y-coord
4 - Z-coord (if applicable)
Repeat, 5-6-7-8-9, 10-11-12-13-14, etc.
This way, people good with a CPU, could use a whole bunch of different indicators without crowding their contraption with entities, sapping both space and processor power for the physics calculations.

Still, I love this little device and if I have to pack 18 of them into Plane v3, so be it.

While I agree with this in principle wholeheartedly, its rather a big problem to solve...

The issue isn't with building the SENT such that it can accept the data and send it to the clientside component, nor is it with the clientside rendering it, but with the data transfer between the SENT and the clients.

As any given value could change at any given moment (or indeed, ALL settings could change) it could cause HUGE amounts of lag really easily.

This could be solved in several ways, none of them very good.


1 - The 'delta-send' solution.

With this, only the data that has changed is sent, presumably with some kind of table index to identify each value.

This way if a single value (or even a small group of values) change the total data to be sent is still small, and wouldn't cause any lag.

This breaks down, however, if large sections of the table were to change, A LOT of extra data would have to be sent, as each value changed would need a location in the table to change.

Assuming that (for the ease of calculation) we're using 1 byte for each value, and 1 byte to address it, thats 2 bytes per value, then if 10 values change we're sending 20 bytes :/

Even if I started doing sections of table to change (regarding it as a large array) it increases the processing time, where we're not actually rendering anything.

Plus, ignoring all other issues, the tables could get out of sync possibly causing totally unexpected behavior! This could be solved with a keyframe style sync message, but that itself would cause lag.


2 - The 'Whole-Entity' solution

This takes any entity (display element) that has had its data changed, and updates the whole entity, as a chunk.

If a single value is changing, we'd send the whole entity as insurance, but we're not having to address the entity, as the clientside can just replace its version with the newly updated version.

In this setup, as we're sending the whole entity on each change, the number of changes to that entity's data doesn't matter, as the whole lot is updated, so whereas in solution '1' if we moved an entity, and changed its value, it'd be 3 seperate deltas, in this one, it'd be 1 entity send.

This scales right up to changing -all- of an entities settings in one go, while still only sending 1 entity (one send operation).

This of course breaks down for large numbers of entities (again) as if each entity has only one variable change, we're sending lots of redundant data.


3 - The "Best Effort" solution

In this case, we do a combination of the above two methods, with a threshold for changes set, so if a single value is changed, we update just that, if half an entity is changed, we update the entire entity as one send.

But while this seems appealing, it has both sets of flaws, making large updates tricky.

For example, if we have 32 entities, and -all- of them update at the same time but only with 1 value, then there are 32, 2-byte sends to do, which isn't bad.

However, if we peak *just* over the threshold for changes, such that all 32 entities need to be completely updated (sending all their data) then its 32*[SizeOfEnt] which is rather alot of redundant data, again.



And I could go on... I've been pondering this for rather a while, as you can probably tell.

BUT! Hope is here! This is pretty much the same problem as my research project for this year at uni so I should get a good result once I get a good approach.



Thanks for still being interested though guys, I almost thought that no-one cared anymore

[Urablahblah]

Oddly, (as I've pointed out before) there isn't a circle drawing command (that I have found, anyhow) so I'd have to write my own... which is easy, except slow, so this might be an oddly laggy thing to include :/

One option for this, however, is to draw it as a texture, but they have their own 'special' issues

I'll have a look once I've gotten more critical things done.

Ah, now that I think of it I remember you saying that. Well shoot.

[moggie100]

If anyone knows how to make a texture render all the time, do say - its driving me up the wall...

I think its something to do with the texture rather than the code, in that the valve texture stuff has different render modes, and I just cant fathom them :/ So short of trying -every- possible combination (and there are alot, 32 flags and about 10 or so general modes...) I dont think I'll get anywhere

[emspike]

Here's a little background: for the past week, I have been working on an AA capable tank with an assisted targeting system (not auto-aiming) that utilizes Adv. HUD extensively, including for assisted railgun sniping and missile target selection. And so far, everything works perfectly. The problem is that the Adv. HUD entities don't dupe properly. For some reason, only the HUD type option dupes. Everything else resets to the defaults. This wouldn't be a huge issue, except for the fact that it means I have to rewire several (more than 3 is all I'm saying for now) Adv. HUD indicators every time I spawn my tank.
So anyway, why wouldn't Adv. HUD be able to dupe properly?