SPON LOS v0.1.0 (DO NOT SUBMIT)

[Spooner]

SPON LOS v0.1.0
- Released: 2008-08-19
- SQF function in a single file

Description:
Although this script is an implementation of line of sight, it is probably interesting as a demonstration for people who want to use the intersect and boundingBox commands. Note that this function calculates what object, if any, is directly in the centre of the player's screen, not a general line of sight or line of fire (though the function could be modified to provide these things).

This is quite a basic implementation and lacks full documentation, but I thought people might like to play with it sooner, rather than later. I'll come back later and optimise it and spruce it up a bit. It was developed for the completely re-written version of SPON Recognise, which should be available soon...ish.

intersect is a command that is barely ever used by anyone. Those that try to use it, generally can't get it to work. This mission is a demonstration that shows one way in which it could be used, though showing its limited use when applied to objects other than people.

boundingBox is sometimes used by scripters, but it is not always obvious what it is or how it relates to the object itself. This demonstration clearly marks the bounding box around each object.

Changelog:
  0.1.0 First release.

[Gnat]

.... extraordinary functions this ArmA has 
This game engine strikes me as capably of many "non-war" things .... but I'm short of ideas right now.

Nice work again Spooner

[Spooner]

Only last night, I was only considering making an ArmA bowling game, throwing HMMWVs at radar towers along the airport runway Daft ideas are easy to come by!

[i0n0s]

Really nice demo!
I used weapon-dir and failed

But thanks to your demo I retried it, and it works! (But is a little sensible)

Edit:
Bowling? But where is the gravity gun you promised? 

[Spooner]

The problem with weapon-dir is that you have no idea where the weapon's barrel actually is, unless you are aiming, in which case you can use the camera origin. Probably doesn't matter for things which are very close, but won't be accurate for anything a decent distance away. Of course, you can force the player into zoom mode with a weapon (either in config or via a script), then I think it would be OK. I suppose when aiming at bounding-boxes, this should be accurate enough, but not for selection-detection on infantry.

I'll add a way to get firing LOS as well as sight LOS when I get around to it, even if the firing angle might be a bit inaccurate (I'll see how much I can workaround this).

I just wish I knew why intersect didn't pick up all the vehicle selections Did ask about it here, but didn't get anywhere.

Gravity gun? Well...I'll do it after I've finished the other 10 scripts I have on the go

[Mr.Peanut]

I tried to crack a similar nut(ow!) when I first discovered the boundingBox and weaponDir commands. I truly wish that BI had included a weaponMuzzlePos command that returned the muzzle mouth position of a unit's weapon relative to the unit's model.

Some people want a LOS for AI, for which camera commands will not work.

[TheCaptain]

I did a bit of pilfering of SPON_LOS to adapt it to checking if one object is in the line of sight of another, ignoring the camera completely.

I'm using it for an armor script I wrote which checks if an armored vehicle within a short range of a projectile is in the path of the projectile as it flies, so I can do a terminal armor/penetration/angle calculation and delete the original projectile. (Nevermind that as it stands it's horribly performance dependent, it works pretty well as long as you're not on x2 or x4 time...)

For the time being I'm using the model's bounding box, but I intend to write "manual" bounding boxes in object coordinates for armored vehicles (so the 'hitboxes' are much more accurate).

I also have not written the code to check which facing of the box the intersectPosition is in, but that should be some simple trig.

Code: [Select]

//fObjInLOS
//by The Captain
//last edited 9/20/2008
//Based on SPON_LOS by Spooner
//Given two objects, determines if the second is in LOS of the first's orientation vector.
//Calls fAddVector and fScaleVector to perform vector operations.

private ["_originObject", "_checkedObject", "_step","_canSee", "_box", "_maxBound", "_distance", "_originCheckPosition",
"_intersectPosition", "_modelPos", "_viewableDistance ", "_i"];

_originObject = _this select 0;
_checkedObject = _this select 1;

_step = 0.5;

_viewableDistance = 100;

_canSee = [false,0,[0,0,0]];// true or false, distance, position

_box = boundingBox _checkedObject;

// Check that the maximum distance the bounding box can be from the
// centre of the model. Multiply by 1.75 to allow for corners being
// further out.
_maxBound = (((_box select 0) select 0) max
((_box select 1) select 0) max
((_box select 0) select 1) max
((_box select 1) select 1) max
((_box select 0) select 2) max
((_box select 1) select 2)) * 1.75;

_distance = _originObject distance _checkedObject;

_originCheckPosition = [position _originObject,[vectorDir _originObject,_distance] call fScaleVector] call fAddVector;

if ((_originCheckPosition distance (position _checkedObject)) <= _maxBound) then
{

for [{ _i = (_distance - _maxBound) },
{ _i <= ( _distance + _maxBound) },
{ _i = _i + _step }] do
{
_modelPos = _checkedObject worldToModel ([position _originObject,[vectorDir _originObject,_i] call fScaleVector] call fAddVector);

if (((_modelPos select 0) >= ((_box select 0) select 0)) and
((_modelPos select 0) <= ((_box select 1) select 0)) and
((_modelPos select 1) >= ((_box select 0) select 1)) and
((_modelPos select 1) <= ((_box select 1) select 1)) and
((_modelPos select 2) >= ((_box select 0) select 2)) and
((_modelPos select 2) <= ((_box select 1) select 2)) and
(_i <= _viewableDistance)) exitWith
{
_intersectPosition = [position _originObject,[vectorDir _originObject,_i] call fScaleVector] call fAddVector;
_canSee = [true,_i,_intersectPosition];
};
};
};

_canSee

Code: [Select]

//fAddvector
//by The Captain
//Last edited 09/20/2008
//adds two vectors together

_vector1 = _this select 0;
_vector2 = _this select 1;

_xvec1 = _vector1 select 0;
_yvec1 = _vector1 select 1;
_zvec1 = _vector1 select 2;
_xvec2 = _vector2 select 0;
_yvec2 = _vector2 select 1;
_zvec2 = _vector2 select 2;

_vector3 = [_xvec1+_xvec2,_yvec1+_yvec2,_zvec1+_zvec2];

_vector3

Code: [Select]

//fScalevector
//by The Captain
//Last Edited 09/19/2008
//scales a vector to a given length

_vector = _this select 0;
_newLength = _this select 1;

_xvec = _vector select 0;
_yvec = _vector select 1;
_zvec = _vector select 2;
_length = sqrt ((_xvec^2) + (_yvec^2) + (_zvec^2));
_xvecUnit = _xvec/_length;
_yvecUnit = _yvec/_length;
_zvecUnit = _zvec/_length;
_newVector = [_xvecUnit*_newLength,_yvecUnit*_newLength,_zvecUnit*_newLength];

_newVector
edit: deleted "viewabledistance" right before I pasted this... which breaks the script. Added it back in this snippet.

Maybe this would also be useful for someone.

And dang the modelers for not naming selections... this would be *much* easier if intersect actually worked. I spent quite a bit of time figuring out why intersect returned an empty array when the vector clearly intersected the tank...

[Spooner]

I did consider doing something similar to improve the ridiculous tank damage model we have at the moment. Like a lot of things I think about doing in ArmA, it never got done, so I look forward to your system ;P The main problem I saw is that even with this information, you can't selectively damage a tank. Although you can setDamage, you can't, say, just damage the tracks or turret or whatever, so you would actually have a less realistic system than is in place now. This is very annoying and, even if they don't want to implement a realistic armour damage model in ArmA 2, I hope at least they will give us the few commands that would make this possible for us to do!

[TheCaptain]

It's true, we're limited to just setdammage.

The original system I put in my mission (Which I'm writing this script for) does a setfuel 0 + setdamage dammage tank when the weapon's tracks are disabled and removeweapons of cannon type + setdammage damage tank when the gun gets knocked out. This prevents the crew jumping out when only the tracks are disabled, and makes a wounded tank more deadly. However, I quickly noticed that the damage was still too predictable: exactly four RPG's to kill an abrams, one RPG + waiting 5 seconds to kill a stryker, etc. And of course, the first RPG would almost always track an M1A1 (sometimes the second), making the big heavy tank effectively pretty weak.

Hence, why I'm writing an armor script which would shrug off RPG's if an abrams gets hit from the front, but also giving them a chance to cause minor damage if they penetrate from the top or rear. Meanwhile, BMP's and M113's should have slightly less explosion-inducing effects when hit in the tracks by a single RPG, possibly disabling the vehicle without simply cooking it off every time.

Combined with the armor script (which uses the LOS part above) which would do no damage if a shell/missile doesnt penetrate armor, as well as some other effects if a penetration happens like killing/injuring crew, setting tank on fire, or blowing ammo/fuel (for a critical hit), and figuring out based on coordinate defined hitboxes if the turret or hull is hit and thus which internal sections to cause 'damage' to... it should be somewhat realistic in terms of effects to the tank.

It's still setdammage with a few extra commands, but it should end up better than the silly hitpoints-damage calculations which as nonwonderdog pointed out on the official forums, getting hit anywhere on the tank pretty much damages every selection anyway.

[Spooner]

I hadn't thought of affecting fuel and ammo to simulate special hits! Yeah, everything is just too predictable at the moment, especially the predictable number of hits to take out an armoured vehicle. Good luck with you project