Multiple Guns on Ground Vehicles

[DBR_ONIX 0]

Been fiddling. Tried Philcommandos idea of using autocenter=0 in the model properties and config (Not sure which one did it, but both didn't hurt).

It worked to a degree, but it ceased to work when you went up/down hills (The problem from the beginning, no setbank/setpitch function). I tried a bunch of things, no luck. Meh. So I took the dog for a walk.

Then came up with a new idea..

The vehicle changes it's pitch fine.. How? The LandContact Lod.. What does the MG not have? LandContact Lod.. Hmm

Basicly, give the MG a Land Contact lod, like the "real" vehicle (The one that will carry the multiple guns), and in the same coords the second gun would be, put the MG there.

So basicly you have an invisble car with a gun.

Then, setdir it the same as the proper vehicle, and setvelocity it the same (Setpos wont work, as it will reset the bank/pitch again).

Problems : If it has a geolod, the two things will boucn away from each other (They can't collide), but without it, it wont have weight?

And if it has no geolod, will it react to explosions?

Then you could get hit by a grenade, and proded out the way a bit, but the "gun-car" wont, so your secondary gunner would be over-there somewhere..

Not tried this yet (To late ), but maybe setpos-ing it and creating a bullet at it (Place a vehicle on a rock with roadway lod, it'll levitate till you shot it, as it reenables the "phsyics" on it ). This'll look messy, but you never know, it might sort it's bank/pitch out when it's setpos'ed

Just an idea, hopefully someone can suggest, if this wont work, how to make it work

Oh, the vehicle I was trying was the new PUKF Landie, since it has the two MGs modeled, just one static

If this is possible, there are lots of things that are possible, and another line scored of the "OFP-Limitations List"

- Ben

[uscg pilot 12 37]

that does osund liek tid work and yes thereyd be a problem with explosions but if u put a seperate one liek the main vehicles explosion itd work perfectly

[eestikas88 0]

a long time ago when i was a newbie in ofp (actually not so long time ago) is saw a newspost over ofp.info,where a guy had made a script.on the pic there was a 5t truck and soldiers in the cargo could shoot out of the truck.

didn't read fully the first post so sorry if offtopic a bit.

just looked at the title

[philcommando 0]

1. What makes an ofp vehicle goes uphill and downhill?

The land contact lod determines it

2. What makes two ofp vheicle goes uphill and downhill?

The land contact lod of each vehicle

3. Why does a motorbike goes uphill earlier than a bus when placed side by side starting together?

The size of the motorbike is smaller in geo lod and land contact than the bus

4. If motobike is 'attached'( as a script attached) to bus, will motobike follow bus going uphill alignment?

No..because the 'attached' motobike's geo and landcontact lod do not match bus, so will be out of sync visually.

5. So how does the motobike follows the bus motion uphill?

Make the motobike geo and land contact lod same with bus.

Hopes that may lead u to methodical logical reasoning to find a solution to z axis of attached vehicles. Unfortunately, not many see logic and reason, only emotion of rage.

[philcommando 0]

1. What causes a vehicle to explode or damage?

The firelod, and in its absence, the geolod

2. What causes a vehicle to deflect rounds

The geolod

3. Can the lods be seen?

No

4. Would it then be necessary to make the vehicle/gun the same amount of vertices as resolution lod?

No. a simple box that will not obstruct other objects will do.

--------------------------------------

1. What makes an ofp car speed moves?

The geolod with weight

2. What makes an ofp gun speed move?

Ofp gun dont speed move. it is static

3. If gun is static, do we need geolod with weight for it?

No.

4. If gun is attached to moving vehicle, do we need weights for gun?

No, the gun is only attached, not a moving speed object, no need for geolod weight.

5. If gun geolod no weights, can it deflect ammo or explode?

Workaround: Gun is small, penetrating shots cant be seen, but with a firelod that does not obstruct other objects, it will be destructable.

[Wachtmeester 0]

And you could make the geolod-box only on the important parts, so it won't never hit the 'leading' vehicle.

Sounds like the final solution to this engine limitation.

[colonel_klink 0]

From extensive testing I have found that the Fire geo lod is what deflects rounds. Geo lod is for collisions.

I would suggest that the secondary model has a geo lod with mass but DO NOT NAME COMPONENTS, as when these are named the model will colide and bounce with the first model. I would set a script so that when the first model is destroyed the killed EH sets off a script that destroys the second model. You could then delete the second vehicle or leave it with the first.

I think the ground contact area for the second would have to be the same as the first model. Aslo the center of the second model must align with the first. Setpos is a mongrel when it comes to doing this exactly and as mentioned will upset all positioning as far as pitch and bank is concerned.

If damage is the only concern apart from positioning the geolod is only needed for the mass not the components. The fire lod should still work as normal. The weight/mass is necessary for determining armor and to prevent the model bounding off into the distance.

If the use of proxies could be used to accuratel place secondary models then all problems would be solved. While they can be used to attach static non interactive models, proxies become unusable apart from the usual things such as drivers.. missiles etc on vehicles that use them. Attaching secondary models to proxies would be the answer as the proxy will bank, roll, pitch in tune with the parent model.

[philcommando 0]

good point there, Col.

1. But what is actually ofp's proxy and how are they attached to the vehicle?

My guess:- Its only a setpos script.

a. The allocation of the proxie is affixed at resolution lod - just for looks

b. The allocation of the proxie is also affixed at firelod - to calcalute the impact point

c. The allocation of the proxie is affixed at geolod - to determine collision

d. The allocation...at view geometry - for ai to target

Summary:- the proxie takes into account its place in the overall size and position of the object.

i.) difference between ours and Bis attachment =

a.engine codes of which we have no idea..only what is avaliable and pioneered by talented scriptwriters.

b.ours comes with multiple 360 degrees firing capabilities

ii) will ours work just as well? - it can be done.

[SWIFT88 0]

tell me this... ive got a script installed, It goes up+down but when it takes corners it Makes a massive radius around the bonnet.... any suggestions?

[philcommando 0]

Swift:-

Check the attached object's location to the overall size of the main object in 02, eg:- gun as the attach object and vehicle as the main object.

- If in the config  autocenter = 1, it would mean the gun will turn on its own ofp engine axis.

- If in the config autocenter = 0, and you took into account the gun's location to that of the vehicle in 02, when u turn the vehicle, the gun's turn radius will be from the vehicle

Edit:-This will work provided you had constructed the gun with the invisible geolod and land contact similar to that of the vehicle.

[colonel_klink 0]

@swift88

That will be in your setpos command based on xyz or xzy depending on the syntax you use.

xy or xz are dependant upon the position you set the attached object away from the center of the parent vehicle. To get his to turn exactly in the same position each time you have to determine the xy (xz) with trigonmetry. using Cos and Sin. Here's a snippet I use to set a light on a moving boat:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_direction = 270

_distance = -1.5

#repeat

~0.001

_dir = (getdir _boat -_direction)

_velo = (velocity _Boat)

_bluelight1 setvelocity _velo

_posx = (getpos  _Boat select 0)+(_distance * cos _dir)

_posy = (getpos _Boat select 1) -(_distance * sin _dir)

_posz = (getpos _Boat select 2)+5.5

_bluelight1 setpos [_posx,_posy,_posz]

goto "repeat"

_direction  is the angle in degrees the position is in relation to the parent object

_boat is parent object

_bluelight1 is secondary object

_distance is the position from the parent's center

I think that is about it. Of course there is other code like checking the  parent is alive and flashing the lights animations as well.

Or what Philcommando has suggested above

[SWIFT88 0]

id be lying if i said i hadnt cracked it.....

BTW the proxy isnt showing up....

[hardrock 1]

Nice idea, I tried this some time ago, exactly as you said. I made the tank and the MG separately, both had exactly the same LandContact Lod, the MG was always forced to its right position on the tank. I also left the vertices of the Geo Lod, but deleted all faces, so that the mass distribution stays correct. Unfortunately it didn't work though as the MG pitch wasn't set correctly according to the ground though the LandContact LOD was available. Thus I guess OFP just doesn't manage to set the pitch correctly when set posing an object with a high frequency.

[philcommando 0]

I wish i could do a test right now, but unfortunately i am thousands of miles away from my home computer and unlikely to be touching it for a year or more.

One more thing that i had not test with regards to multiple guns object for different terrains is the centre of gravity of attach object. Rotation reference point is in the cg mass in geolod. Perhaps the attach object's cg must match that of the main object too, beside the land contacts??

Although i would not place much credence on cg, i suspect the setpos loop timing must be set higher inorder that each nanosecond the vehicle moves, the attach object must be fast enough to synchronise itself to the main object.

Edit:- A research note-

When i made my 18th century ship, the 1st time i used an attached script, my attach ship and the main object conflicted and jumped alot. After testing i realized the geolod of the attach object was conflicting with the geolod of the main object.

My solution:- maintain the attach ship's resolutionlod, but deny it mass for geolod with not even a named component. No more shuddering.

[DBR_ONIX 0]

Hmm.

Since my trig knowlege is.. limited

Using the bank/pitch functions (here), is it possible to get the pitch of a vehicle, and using the distance the MG is from the center of the vehicle, get the height the MG should be at? Theres still the problem of setting the gun's pitch/angle though)..

hardrock : Thats one of the problems I mentioned in the first post, setpos-ing resets the bank/pitch.

I dont know (I'll try later) how bad it would look setposing it, and imeditely after creating a bullet to sort the phsyics of the gun

Philcommando : I tried the autocenter=0, it half-worked (Nice find ), I started on trying it with the land-contact lod, like I said, I'll try more with this later

Quote[/b] ]Attaching secondary models to proxies would be the answer as the proxy will bank, roll, pitch in tune with the parent model.

I don't think it's possible to get the position of a proxy. Unless I missed something, they will follow the parent model, but it's still impossible to attach a gun (That can be used) either to a proxy (Via setpos type stuff), or attach it AS a proxy..

Other idea, animating the gun (Via config defined animations), so it can rotate 360*, then you can use the animate command, and numbers from 0-360 would be 0 to 1.

So turn the pitch 180*, you'd use : this animate ["gunPitch2",0.5]

Problems : I don't think you can animate proxys (The only thing that seems to do this is the SCUD Launcher). Also not sure if you can animate the same object twice (For bank and pitch).

Not very neat at all, and not sure the gunner proxy could be moved (Could use typeOf and create a dummy unit to fill the gunner-proxy in the parent model, I suppose), and hide the real gunner wouldn't be visible, then use a getout eventhandler to delete the fake-gunner. Messy as hell, but if it works...

Anyway, just me thinking out loud. Maybe something usefull will come out of this.. Maaybe

- Ben

[philcommando 0]

good job there, DBR,Swift, hardrock and my master -Col Klink. My own research and developement insights ended with simple moving multiple gun ships on flat surfaces. Thank heavens there's still folks like you guys who are willing to experiment further. Your results will bode well for the future of ofp and for other addonmakers as well. Keep it up!

[h - 169]

Quote[/b] ]I don't think it's possible to get the position of a proxy.

Make it a cargo proxy, moveInCargo a gamelogic in it and getPos it...

[offtime 0]

create MG as soldier class (dumb without own will, without ability to move) (or just make MG as standard proxie), place him in first cargo proxie, in second place dude wich will become gunner.

find way of giving cargo ability to fire by script and by script spawn bullets...

main bug in this idea is moving MG barrel up and down....

[UNN 0]

Quote[/b] ]I tried the autocenter=0, it half-worked (Nice find ), I started on trying it with the land-contact lod, like I said, I'll try more with this later

I tried autocenter=0 and autocenter=1, there did not seem to be any difference. I think it was because the objects mass has been modeled to always be off centre. So in this case autocentre moves it's mass closer (or further away from) the centre of the object, but never directly above it. When the mass is offset from the centre, it seems to align itself better with the terrain. But that causes the object to move away from the vehicle on steep slopes.

Edit:

My mistake, autocentre does not effect how an object aligns with the terrain. But it does mean you can easily define it's centre point, so excess movment is kept a minimum.

Absolutely no luck with land contact points or geometry LOD's I tried all the combinations suggested.

Quote[/b] ]I don't think it's possible to get the position of a proxy. Unless I missed something, they will follow the parent model, but it's still impossible to attach a gun (That can be used) either to a proxy (Via setpos type stuff), or attach it AS a proxy..

If you use a cargo proxy and move a game logic into it's position, you can. Just use GetPos on the logic the way you would on a regular crew member.

Quote[/b] ]Other idea, animating the gun (Via config defined animations), so it can rotate 360*, then you can use the animate command, and numbers from 0-360 would be 0 to 1.

So turn the pitch 180*, you'd use : this animate ["gunPitch2",0.5]

Problems : I don't think you can animate proxys (The only thing that seems to do this is the SCUD Launcher). Also not sure if you can animate the same object twice (For bank and pitch).

Your right on both counts about animating proxies, I don't think they can be done.

My idea was to create a soldier that looks like a turret (for example). You can setpos this guy alongside a cargo proxy, only he wont pitch or bank with the vehicle, but he will turn and fire at targets. Then create an animation (rtm) that simulates him pitching and banking, then link that animation up with the vehicles pitch and bank using scripts.

Been toying with this idea for a while (simulated AI turrets) just started messing with OFP Anim, so it will be a while before I try anything that complex.

P.S

Swift88, I will send you what I have so far. I tried the land contact points last night, with some strange effects. Perhaps you can make a better go of than me.

[philcommando 0]

Any outcomes from DBR and Swift?

[DBR_ONIX 0]

Not yet, got a portfolio to complete today, so after that I'll work more on it. Just now I need to re-config the MG model (Was just using static object to test idea).

I think swift is getting there (There was a thread in scripting help, would link to it, but I can't find it ).

In said thread, UNN (I think) posted code that used a camera created on the vehicles position, and used setCamRelPos or something to set the gun's position. Not tried this yet, but if it takes into account bank/pitch (I seem to remeber cameras being able to bank etc for some reason).. hm..

Anyway, I'll start fiddling again in next 2 days. Then of to Canada for 2 weeks on 8ths, and hopefully if noones managed by then, someone will have managed by the time I return...

Good luck everyone

- Ben

[SWIFT88 0]

Any outcomes from DBR and Swift?

getting there

[UNN 0]

Hi,

Quote[/b] ]In said thread, UNN (I think) posted code that used a camera created on the vehicles position, and used setCamRelPos or something to set the gun's position. Not tried this yet, but if it takes into account bank/pitch (I seem to remeber cameras being able to bank etc for some reason).. hm..

Yeah, I nicked that from the Mi28 (? The russian heavy chopper) cargo scripts. It's a convinient way of cutting out some heavy maths. But it only works on pitch ideal for anything that does not bank to much like boats, and heli's in some cases. Not so good with cars and planes, depends what you want to do.

[Big Dawg KS 6]

Well all I have to say is that everything allways seems sound untill you actualy test it, and thats where the problems start to emerge.

[philcommando 0]

This is a discussion board afterall. While not many may have answers, but in time the answers will be forthcomming. If you dont bring out the problems, no one will bother to share.