Home   Help Search Login Register  

Author Topic: Reason for the Azimuth question:  (Read 1343 times)

0 Members and 1 Guest are viewing this topic.

jamie_psx

  • Guest
Reason for the Azimuth question:
« on: 15 Sep 2002, 18:20:06 »
The original question was about how to determinge the direction a tank's gunner, turret, or gun barrel is pointing.

The problem was that neither the GetDir nor the Direction commands would give you the correct return value.

Either they'd return FFFFFFFEF hexadecimal or they would return the direction of the gunner before he got in the tank.
I know OFP knows how to get the direction, because that's how the game is able to display the Compass correctly.


The reason for the question, in the first place was a thread on the DKM Mod forum (interesting read, only 6 posts long):
http://www.dkm-mod.mkdi.net/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=1;t=000104

about making real indirect fire artillery models, rather than just artillery that acts like (direct-fire) tanks.

Apparently they have an artillery piece just about ready, but can't figure out how to locate the azimuth of the gunner (in order to land the shell correctly).

Maybe someone here has some ideas.

To Moderator:
I'm not a member of DKM staff and I don't know how to make models. So please don't think I'm trying to raid this forum for ideas. I just think the more ideas the sooner the model might be released.

I just hate to see a good model not released because of a minor coding difficulty.
Also AFAIK there hasn't been a true/accurate indirect fire weapon released for OFP.

Offline Dinger

  • Contributing Member
  • **
  • where's the ultra-theoretical mega-scripting forum
Re:Reason for the Azimuth question:
« Reply #1 on: 15 Sep 2002, 20:34:59 »
Well here's my take:
I'm working on realistic artillery for a mod as well(www.thechainofcommand.net), and I don't mind discussing what I'm doing or sharing what I've got here.
Here are the problems as I see them:
A.  There is the "Direct Fire Artillery" script posted around here that's worthb looking at. I don't know how they do it, but it works up to about 3000m.

B.  If the gunner would target a point automatically, you wouldn't have to get his position; you could just set the virtual target in the direction you want to fire, tell the gunner to fire at that target, and voila`! trajectory.  The problem is, the gunner likes to move away from that point, and the results are disappointingly inaccurate.

C. Even if you get that fire problem solved, tank shells expire after 20 seconds, and they have the longest life span of any OFP ammo simulations.

D. The current version of my (realistic FO simulation) artillery script (It was up on OFPEC before the "change"; if they can give me 300 kb of space, I'll put it up again.  In the meantime, I'll stick it on the CoC site starting this afternoon) simulates shells in just the manner you describe: it camcreates a shell above the target, and lets it fall in to hit the target or fuze above the target.  There is a limitation to this method: Field Artillery is usually a low-angle weapon; dropping the shell straight in means you don't get the same kind of terrain and obstacle interaction.

E. The solution I'm working on now involves very simple mods )(ripoff shell descriptions, give them a "shotmissile" simulation) to camcreate shells with trajectories.  Currently I have working versions of shells that come in at 20.5 degrees (low-angle) and 60.5 degrees (high-angle); by controlling exactly where I camcreate it, I can get air- and ground- bursts with reasonable precision (PERange of 3 and 1 meters for Low and High-Angle respectively).  Plus you can set up on a hill above the target aloing the GT line, call in fire, hear the shells whizz over your head then watch them splash below.

F. For the DKM mod people, the way I'd recommend they do it is:
  1. When the paladin fires with the player as gunner or with the AI firing at targets, have it fire in whatever direct-fire mode it has.  If you're really desperate, I've got a scanner script that picks up and tracks shells when they're fired from a given unit.  You could pick up the shell, read its outbound trajectory, calculate its inbound trajectory and where it should impact, then spawn a shell with an acceptable inbound trajectory to cover the last ten seconds before target.
  2.  Have a scripted fire mode when there player calls for fire (either simulate an FDC or just adapt my Artillery scripts or something like them).  Set up a config.cpp "dud round" -- a non-explosive shell that does no damage, but creates a report.  Have it fire, then set up the splash, along with the appropriate effects (Fuzes/Shells).
  3. Or just tell them to release what they've got, and I'll make it work right ;)
Dinger/Cfit

jamie_psx

  • Guest
Re:Reason for the Azimuth question:
« Reply #2 on: 15 Sep 2002, 21:45:58 »
1)  Thanks for your reply.
2)  How do you get the shells to travel at the (elevation/declination) angle and azimuth that you want?
I tried using the CamCreate on several missiles and rockets and they all started off horizontally (at the given height) and seemed to complete the "going-down" half of a parabolic trajectory.
But the problem was that they all travelled North. (This was before Resistance, so I don't know maybe you use some other command).
3) Did I understand correctly that your scanning-script can detect the azimuth (direction of flight) as well as the inclination/declination of the flight path with respect to the ground?
4) I'll pass your suggestions on to DKM.

Thanx again. :)

Personally I think indirect-fire (parabolic trajectory) units like the Paladin should be AI only, anyway.
Or at least the gunner's position should be AI.
What's the fun in shooting at something you can't see.
I mean nobody wants to shoot south from Everon Airport, and then scoot down to Morton or St.Pierre to see what damage was done.

Offline Dinger

  • Contributing Member
  • **
  • where's the ultra-theoretical mega-scripting forum
Re:Reason for the Azimuth question:
« Reply #3 on: 15 Sep 2002, 22:25:14 »
Yeah, the problem these mod folks have is they've created a cool 3D model, but it won't work in-game in the proper way.  The tank simulation of OFP is extremely basic as is, but for direct-fire combat you can sorta get away with it.  With indirect fire, it's much messier.  I mean, a real Paladin outfit will have tons of support units -- Tacfire, FDC, Meteorology, Survey, the FISTs -- to get the fire on target.
Then the ordnance fired is more varied.  You think the current tank models are bad with their "Shell" and "Heat" rounds, a 155 can fire HE, ICM, DPICM, FASCAM, ILLUM, SMOKE, CLGP rounds and other stuff (like those armor-seeking things) shells.  These can be fuzed to different environmental and target requirements (they don't all explode when they hit the ground).  so building a 3d model is a small part of the puzzle, you need to build a system.

3. Now, for picking up shells:

what you do is a run a script that monitors the ammo state of a given unit (@ unit ammo [type] < oldammo).  When that unit loses a round of the ammo you're tracking, scan a grid around that unit with 25 m spacing at 50m above ground, looking for a nearestobject with a speed above 400 kph (you can go faster if you like).
"format [""Shell%1 = Nearestobject _X"", ""Speed NearestObject _x > 400"" count [_x]] Foreach [_x]" Foreach [_scanarray]
where scan array is the array of x y z locations around the gun.
After this, variable Shell1 will indicate the projectile.  You can then track this over a half second or so -- get the two coords, then adjust for ASL (using an appropriate routine), and calculate from that all you need.
Easy, huh?


2. SetDir works on Camcreate
For example, here's the relevant part of my config.lines for a low-angle trajectory:
class HE155LA : ArtilleryShell
{
   simulation = shotmissile;
   hit = 100; indirecthit = 300;
   cost = 300;
   maxspeed = 250;
   thrusttime = 1.5;
   thrust = 200;
};
Artilleryshell is just a modification of default shell, nothing fancy there.
Anyway, find the spot 2416 meters from the target and 490 m above the height of burst (using ASL calcs), camcreate the shell there 10 seconds before you want it to splash, and setdir on it in the firing direction.

(hmm 490m in ten seconds :) )

This is for 20.5 degrees ingress.  For my purposes, one low- and one high-angle shells are sufficient.  I only care about the sound effects and what the shell hits on the last 100 meters.  Through some testing, you could create a whole bunch of shells for however many different angles of ingress you want.
in other words, no I can't make them start out traveling at a set elevation/declination; I can only make them end at one, and that is by varying the horizontal velocity as a result of the thrust/thrusttime settings. The vertical component of their vector at splash will always be 98 m/s unless you monkey with the "sideairvelocity" setting, which I don't recommend.
 I plan on writing a simple LOS calculator that will also calculate the intervening obstacles for HA/LA determinations.
Again, my bias is artillery simulation from the FO/FIST/ANGLICO point of view.  The trajectory's nice, but what really matters is that there's an explosion at the other end.  As you point out, it's no fun in an FPS to sit five miles behind the lines, loading shells and blasting at unseen quadrants.
Dinger/Cfit

jamie_psx

  • Guest
Re:Reason for the Azimuth question:
« Reply #4 on: 16 Sep 2002, 01:40:11 »
Well I think most problems are solved.

Your scanning script can give the barrel elevation and azimuth.

Those two points can be fitted in a parabolic motion-equation (curve fitting), and the impact point can be accurately calculated.

From there, either the CamCreate can be used to drop a shell like the Heat120, or it can be used to "whoosh" a rocket at the impact point from some distance away.

Can't go into details now, gotta go. Posted more at DKM.

Cheers!