Explosively-Formed Projectile Script (TESTING)

[Luke]

Here's another script for you guys.

Creates a simulation of an Explosively-Formed Penetrator/projectile.

That is, it shoots a hunk of molten copper at the target.

Dammage to target & crew is simulated through "random" values.

Note that this NEVER misses its target if:

a). it is on level ground
b). there is no terrain in the way
c). there are no units in the way

I the EFP doesn't hit the target, the dammage isn't simulated.

Most of the other stuff is in the readme.

Let me know if you think it is under/overpowered, just right, cool, etc.

Luke

[Mandoble]

Please, add a description of what the script does in your first post. "Here is another script guys" gives little info about it.

[Manzilla]

Yes please, a little description would be appreciated. I didn't have any trouble knowing what "EFP" is in regards too, but you never know if someone may pass up your hard work because the titled didn't ring a bell.

Now it's not like one couldn't just DL this small file and read the ReadMe to get the info, but for those whom pay by the bandwidth used it may be useful.

Thanks for the new script. I'll give it a go when I get home later today.

[Spooner]

1) You put cutText command in the description.ext. If you are defining your own GUI classes to put into a cutRsc/titleRsc, then they need to go in that file, but if you want to use the simple cutText/titleText commands, or run any commands at the start of a mission, then just put them in your init.sqs/init.sqf file. Generally, though, I'd use a hint to give instructions for a demo mission, since you have more room to give a more detailed description and it stays visible a bit longer (I think).

2) I'm sure you could have a single script, instead of 3, with a parameter to determine scale of effect and damage. For example, each script does exactly the same thing using slightly different code, which is only going to get more different as you improve the scripts. This would make the script much more maintainable for you, reduce testing time and make it less likely that any single script gets new bugs over time.

3) Please warn people that the EFP videos you link to are combat examples with real people getting blown up, rather than just firing-range weapon-effect videos, which is what I assumed. Most people won't be bothered by that, but I am (no problem at all with having the links; just people need to be able to make an informed decision before they follow them).

4) I think you should not have a height parameter. If the mission-maker wants a higher device, then he can balance an object on a section of wall or something. Seems odd to require an object and then have the fire come from somewhere else. Alternatively, just require a position array rather than an object if you want an "abstract" device. That way, the mission-maker can use an object (getPos), marker (getMarkerPos) or calculate the position themselves.