A. Getting a pitch/roll meter when in a dropship?
Absolutely possible. To do this we would expose the pitch and roll values to kismet. There are a few ways to represent this visually, and probably it make less sense to use the bar material, but we could have some sort of gauge with a dial or us a rolley ball thingy (I'm sure there is a more scientific name). This probably means we would need to represent it with a 3D Skeletal Mesh and dynamically position it based on numerical inputs. Driving Mesh animations with dynamic values (as opposed to material) is not something we've fully scoped out yet, but I think we could do it using animation trees and blending between end point 'poses'. In the case of a dial the poses would be a single keyframe animation for the max and the min values (and the blend an 0 to 1 value that finds the exact value).

B. Dropship pointing
I don't have a lot of familiarity with the inner workings of vehicles. Maybe another dev can jump in? But I'd wager this is something that is tune-able.

C. What. no C?

D. Speedometer
We could do a dial or digital speedometer (or a bar). This would require getting a speed value change in kismet. This would be something that may have a performance issue because velocity could change very often. If it was a problem we could set the events to minimum delay time between successive fires (this is built into Unreal), but we would have to make sure it is not jerky--probably not, but it may be something that forces our hand to choose a Digital display over a Dial.

Hey CCP MC Peanut, I have a few questions about vehicles, and especially dropships.
Is there a possibility of,
A. Getting a pitch/roll meter when in a dropship?
B. Dropships in general but especially assault dropships need to point at a much lower angle when *scooped*. The current zoom feature does very little good, sense you are forced to pitch down to shoot anything low than you in that view mode, and because pitching forward causes you to move forward, you get a pretty small window of opportunity.
D. A speedometer across the board for vehicles would be really nice.

This is one of my classic rants, but I donGÇÖt think I have posted it in here yet.

Each squad member should have a number on their dot on the mini map which corresponds to their position in the Squad list. This number should also display above their heads when you look at them.

This will facilitate the communication, as you will be able to quickly identify someone by their number and relay information to them. The classic example is GÇ£Hey Dot 4, you got a shotgun on your 6!GÇ¥

When working closely with a squad I often see things I need to warn other squad members about, but I have no way of identifying which squad member I am addressing. A lot of times in DUST, I would not know how to pronounce someone's name, even if I could see it well enough to read it. A number would work fine as long as the HUD makes it clear to each person what number they are. A number would also be easier to display and easier to read than a name.


Edit: For team deploy we could have two numbers. The first represents which squad you are in, and the second represents your position on the squad list. Alternatively, since there will not be a lot of squads, we could use just the squad list number and color code it according to which squad you are in. So you might be Green 3, or Black 5, or Orange 6, depending on which squad you are in (color) and your position in the squad (number).

MC Peanut, when I watched the clip of the compass, I noticed that (to me at least) the rotation of the compass feels unnatural and counter intuitive. Having the compass act static and behave as if the user is looking inside a circle would be better in my opinion. What i mean by that is to have the compass rotate the opposite way of which the user turns.n++

Combine this sort of tactical viability through information gathering with a grid-map on the actual overhead and you've given the guys on the ground everything they need to effectively communicate in the same way that we would in the military. Can play into a whole new meta for effective squad leaders/commanders who can accurately read into the battlefield and provide that information effectively to their team. Congratulations, you just achieved everything Field Command leaders have been asking for.

EDIT: Oh, right - on that note - if we do get a grid-layout for the map... Any chance you could include what grid we're in on our HUD? Just something simple, off in the corner or next to the compass to signify that I'm in G6 or where-ever. That way someone can tell me that "Enemy is at H7" and I know exactly where I need to be / how close they are, instantly

Here's an example of what I'm trying to illustrate:
http://i.imgur.com/ScbP8SX.png
http://i.imgur.com/k4m9amb.jpg

ANOTHER EDIT: Albeit in retrospect that may be rather difficult to accomplish. Your call though.

I know they previously looked into a grid overlay on the overview map before, but they ran into issues with the terrain being in 3D and the UI being done in 2D Postprocess--this doesn't work well because the terrain has depth and the grid overlay is flat and above the terrain--it will not line up properly.

It can be achieved if the grid is done in 3D. There is one shader technique where you can draw pixels only at the intersection points of polygons. I attempted a small prototype by adding some polygons that intersected with the terrain (they are huge), but the thickness of the 'line' changes too much with slope and distance, so we would still need to figure out a way to improve this (and there are ways). Another way this could be done is by building it into the material on the terrain and use WorldSpace mapping coordinates (basically you can use the x,y value as a texture coordinate). This seems better and I'm leaning more towards it (although the first technique would be useful if we wanted to show a scan effect going across the landscape). Still there is a roadblock in figuring out how to apply this grid material--we don't want to it as part of the terrain material all the time--some of the starmap work is requiring something similar, so I'm hopeful we can learn from that.

If we can make certain our overlay map is placed mathematically correct, then it shouldn't be too hard to display what quadrant you are in. In fact, this could be completely done on the content side if the terrains always align to the same world space point (which I believe is true). In the material for the grid coordinate we just look up the world space coordinate and convert it to a grid coordinate--then we have a texture with each coordinate label in a grid (like a texture atlas), and we shift our mapping coordinates appropriately. Probably not too bad, but I'm simplifying the steps and might be missing something.