Project Reality Forums

OK here's something that I'm 99% sure has not been suggested before and Is a neat little idea that I've cooked up that applies some interesting aspects of BF2 code to work. The only reason I'm, suggesting this here and not making it myself is it would require python to make it work (hint hint DB).


OK so picture you have an APC like the ones we normally have in PR. Basically the barrel of the gun is mounted on a branch of two seperate things called "rotation bundles" that the gunner controls to make the barrel move. He controls the yaw bundle with left and right mouse and controls the pitch bundle with up and down on the mouse.

First thing is I want you to imagine is that we remove the pitch bundle so basically the turret only moves along the horizon (no up and down). The next thing we do is put an extra rotation bundle at the end of the gun barrel and place the drivers camera on it. This means that as the gunner turns the turret left and right, the drivers camera gets moved around in a circle. Because the camera is placed on an extra rotation bundle, we can give the driver complete control of his camera...(up down left right) but we will put a limit on his range of motion so he can only look beneath the horizon (similar to the targeting pod in CA).

OK now things get a bit wacky... We make the APC into a stationary vehicle (like a machine gun) and place the APC at the center of the map with the back facing the our main. We the Streeeeeeeeeeeeeeetch the APC so the entrance on the back is right next to the commander trailer. next we make the height of the turret REALLY TALL (on the order of 400-800 m plus), so that barrel is now very high in the air. Next we extend that barrel to be about 1/4 - 1/3 the length of the map so that the camera is extended out in one direction on the end of the barrel. Now if you've understood everything so far you should realize that as you turn the turret the camera will move around in a GIANT circle around the map about 400 - 800 meters in the air and with a radius about 1/4 - 1/3 the length of the map.

Now remove the geometry of the vehicle and add a UAV geometry to the bundle that the camera is mounted on. Finally add a heat object (the thing people lock onto) right next to the driver camera. Now what we do is have the gunners position controlled via python so the turret is constantly spinning at such a rate that the drivers camera will be moving at the speed a UAV flies at. Next we add an armor component where the UAV has a lot of health and has a critical damage point that is also very high (basically when you get hit you have about 15 seconds to bail out before the vehicle blows up) so that the commander would have a warning to get out so he doesn't die w/ the vehicle. The commanders camera would have all the zoom functions it normally has in a FLIR Pod so it could operate more or less as a realistic UAV with a free look with High magnification.

I understand this may be a bit complicated for your average forum goer but its really geared for a few people on the Dev team... Sorry .

Pros:

~UAV can get shot down
~Camera has a warning to bail out before he dies
~UAV has free mounted rotating camera as is in real life
~Commander does not have to worry about controling the UAV (less of a chance of some idiot doing something stupid with it)
~Even though the commander is "inside" of the vehicle he is able to enter and exit from the main
~The commander is able to enter and exit whenever he likes until the vehicle is shot down

Cons:

~Big vehicle might have red spawn issues
~Cannot change flight path
~Dying would possibly look awkward (you could have smoke and such but no real object falls to the ground with out more python coding)
~People in the center of the map would be typically harder to see.
~The cake is a lie.

(As you guys think of more pros and cons I can add to this list)

Con: Anyone in the center of the map would be safe from the UAV

Eh it sounds like my latest project, But I already got stuff cooking in the making

wait, is the camera stuck at the end of the barrel, or can it move up and down the length of the barrell?

Basically, it would act like an extremely large crane with a camera at the end that was continually swinging.

Of course the entire crane would span the entire map, but wouldn't actually exist at all, it's just an imaginary visual aid for understanding how it works.

I'm wondering if it would be possible to do the same thing except once again as a missile. It should be possible to set it on a "path" by restricting it's pitch, yaw, and roll to certain values. The only thing that I want to know is whether or not you could get a free camera on a missile if doesn't need to guide it.

McLuv wrote:I'm wondering if it would be possible to do the same thing except once again as a missile. It should be possible to set it on a "path" by restricting it's pitch, yaw, and roll to certain values. The only thing that I want to know is whether or not you could get a free camera on a missile if doesn't need to guide it.

Possibly but the commander wouldn't be able to enter and exit the vehicle from the main like he could with this idea.

Its a good idea, but it needs some work

I can imagine the huge amount of bugs and fixes that would be needed, plus the fact that its just not worth it if there is already a simple solution already avaliable.

Only major thing that needs to be done to the UAV is a visual UAV flying around that can be shot down, and a simple zoom for those maps like Fools and Kozelsk.

Con: Planes would crash into invisible "barrel". Or maybe its possible to take away the collision mesh, what do i know..

I would much rather control the flight path and be able to look reliably anywhere I want, instead of just a big circle..I think.

Another con; if you stopped the rotation your "UAV" would be essentially hovering in place. Add to that the corners of the map and the center would be unviewable.

[quote=""'[R-DEV"]LeadMagnet;1179012']Another con; if you stopped the rotation your "UAV" would be essentially hovering in place. Add to that the corners of the map and the center would be unviewable.[/quote]

Well, the whole point of the concept is that the rotation is constant...

[quote="Sniper_dog14""]Now what we do is have the gunners position controlled via python so the turret is constantly spinning at such a rate that the drivers camera will be moving at the speed a UAV flies at.[/quote]


Otherwise, theoretically using the basic Pythagorean equation, with Kashan as our base map and supposing our new UAV has a flight pattern of 700 meters, we can sub 1000 meters (the view distance) for our hypotenuse, and 700 meters for one length of our rectangular triangle.

a^2 = c^2 - b^2
a^2 = 1000^2 - 700^2
a^2 = 1000000 - 490000
a^2 = 510000
a = 714 m



So the maximum our UAV could view of the groun would be 714 m in all directions, meaning that in order to view the center of the map it would require the UAV be within 714 meters at all time, limiting it to a view of 1428 m radius.



Up the map's view distance to a measly 1500 meters, however, and it's all reversed.

a^2 = c^2 - b^2
a^2 = 1500^2 - 700^2
a^2 = 2250000 - 490000
a^2 = 1760000
a = 1327 m



Meaning that the UAV can go as far out as 1327 meters from the center and still see it. Also meaning that the UAV can now cover a radius of 2654 meters, and the furthest corners of the map are 2828 meters away, so there isn't anything out of the UAV's vision if it goes a full loop around.

Personally I believe this idea to be better in practice currently, but if UAVs can be given a ctrl freelook function (which we're not certain it can), then that would probably be the better option.

You don't need python you can set the object to auto-rotate upon entry.

Every map having a different main base location and elevation would seriously hinder this idea, at least how I understand it...

You'd need a unique "apc" for each map to have the correct enter location and map size rotation, etc

The enter locations and vary size problems would remain but you could solve the elevation problem by putting the "apc" in the air at a standard altitude.

Of course another solution would be to simulate the UAV by having the commander actually get in one and fly around then land it.

Test it out in CA? I'm quite happy with the UAV as is but would do anything to have a missle of sorts on it.

Solid Knight wrote:The enter locations and vary size problems would remain but you could solve the elevation problem by putting the "apc" in the air at a standard altitude.

Of course another solution would be to simulate the UAV by having the commander actually get in one and fly around then land it.

Then if it dies then the commander shouldn't also die.

couldnt it just be coded so then when the "vehicle" UAV dies that the pilot within it would be allowed to respawn immediately with a slight penalty?

that way we can have the UAV set up as an actual vehichle that the commander can pilot and have all the zoom functions and all. i dont know anything about the coding so it's just a thought

A little ironic that we're suggesting manning the unmanned vehicle to make it work realistically.

I think that having an actual commander flown UAV would be a mistake, but its an idea. However, having the commander dead for flying a UAV is just foolish, so if that can't be dealt with its really not workable. Plus, the commander needs to be able to command while flying the UAV, but without flying himself into the ground. This doesn't seem likely to be possible either, unless there is some way of locking the UAV to an altitude that I don't know about. Manual control will inevitably end up with a lot of comms splattered on the ground. Also, the whole UAV concept would have to be different, as I don't think you can control the amount of fuel a plane has, or how long a plane can exist in the world.

However, if the UAV ever does get a model that can be shot at, can i suggest the Global Hawk? I realize the predator would be more realistic, but nowhere near as cool. Seriously, the cool factor on that thing is out of this world.

richyrich55 wrote:Test it out in CA?

I don't think so.