Gun code in FBI.

[Argh]

Very simple, guys... the Wiki refers to a pair of new features...

WeaponMainDir<1-16> is a vector and defines the center direction of a cone in which the weapon can aim. Default WeaponMainDir = 0 0 1; (forward)

Ok... um... so is backwards 0 0 -1, right is 1 0 0, and left is -1 0 0? And what is this "cone in which the weapon can aim", and how do I define the parameters of that cone? Am I the only one who is confused by this one, or who wants to know how to control it?

WeaponSlaveTo<x>=y this will force the weapon x to use the same target as weapon y (y must be a lower numbered weapon than x). Might be usefull for say a mech like unit with many different weapons that should target in the same direction.

I tried this with the following syntax:

WeaponSlaveTo2=1

... it didn't work. I was trying to slave some weapons to a single "null gun" that I built. The "null gun", with zero damage and a visual effect that I put in so that I could verify operation... works just fine. Soooo... is this broken, did it ever get added, or this there a COB side to this that I'm missing? This ain't just idle curiousity- I have a number of weapon ideas where using "null guns" to control other things would be an important part of controlling them, so if there's a way to make this work, I'd love to hear about it.

[FLOZi]

Ask Spiked about the first thing, I haven't messed with it much, WeaponSlaveTo<X> works though, certainly. Be difficult to break it with the script, but not impossible.

[Argh]

Hmm, I wonder where I went wrong? Do the AimWeapon1, 2, 3 etc. script-sections have to all basically match each other?

Reason why I'm asking is simple- I want to build some weapons that fire shots in several vectors at once (really, they'd be more than one gun, but nm that, it's how it would look) but use a common aiming point to determine when they all fire.

[FLOZi]

They all have to be able to aim at the target of the master weapon to be able to fire. i.e. you can't force a gun with say, 30degree offset to one side to fire at a target at 0 degrees if it is not within its cone.

That is a terrible explanation. Sorry.

[Gnomre]

The cone is defined with "MaxAngleDif1=Degrees;" so if you wanted the weapon to only fire in a 60 degree arc, you'd put MaxAngleDif1=60;. This also affects vertical aiming with the exact same restrictions, that's why it's a cone instead of an arc. Obviously the number after Dif matches the desired weapon you want to arc.

The direction the arc is facing (WeaponMainDir) is... somewhat more complex. Cadyr made a decent post covering it in the Help forum a long while back, it was in one of Arch's topics. It basically works like the sun direction stuff in SMDs work, but I'm not sure the values for unit/sun direction match exactly. The main dir is the height of the cone (using the cone as explained above in conjunction with the range), in mathematical terms.

Like FLOZi said, slaving doesn't work if both weapons can't aim at the same target. Also, you didn't make this error but I should point out that the slave must ALWAYS have a higher weapon number than the master (you can slave weapon2 to weapon1, but you CANNOT slave weapon1 to weapon2).

[Argh]

Ok, that's making some sense, the cone makes sense- great, now I can make HTH 'bots.

Drat and bother about the slave thing, though- I want to make weapons that very deliberately do not aim properly and aren't just random, which is harder to do in Spring than it was in OTA.

[Archangel of Death]

Woo! After so many months, I finally figured out how to get the angles I want in WeaponMainDir! It defines the position of a point that the engine gets the vector of from the weapon origin, like so:
o---->o
First o is the weapon origin, defined in the query function of your script. The second is defined by the coordinates of WeaponMainDir. So, to figure out your numbers (still using o's as the two points):
Draw a triangle

Code: Select all

DistanceX OR DistanceY
 o _____________
   \            |
     \          |
       \        |
         \      | DistanceZ
           \    |
             \  | <--- This is your desired angle. 
               \| 
                o <--- Weapon origin

Ignore the DistanceY for now.

Lets say you want your gun to aim in a forward facing, 12 degree cone. Well, the degrees in MaxAngleDif start at the vector, and go around clockwise (for X/Z, not certain about Y/Z, but I think it is counter-clockwise) from there, so the default value of straight forward, 0 0 1, will aim straight forward and 12 degrees to the unit's right). Looking like so: (0 to 12 degrees)
__
|/
You need to have that vector be 6 degrees to the left so the cone is actually centered on 0: (-6 to 6 degrees)
__
\|/

Now, if you're comfortable with trigonometry, you can look at the big diagram above and see that the distance you need is opposite the angle/ adjacent the angle = TAN(of the angle). Pull out your handy dandy scientific calculator (or change the one in windows to scientific mode) and plug in TAN(6), getting 0.105104.... Now start trying out fractions of X/Z using the "guess then narrow it down" method (thats the first number and last number of the three defined in MaxAngleDif), to try to get them close (3rd or 4th decimal place should be close enough accuracy) to that decimal number. They have to be whole numbers! (Why? Because I'm not testing it) If your a trig wizz, which I am not, you may have picked the best numbers just by looking at it. You should find 2/19 produces a good value of 0.105264... Check your values by doing arctan(X/Z) (may be tan(superscript)-1 on your calculator, not to be confused with 1/tan, so don't try that if you can't find it). This should give a number very close to your angle, if you went to the 3rd decimal place in accuracy when picking your X/Z, then the value will be about that accurate as well. In our case, arctan(2/19)=6.009006...

Booya!

If you want that 12 degree cone to be centered around 90 degrees left of the unit, you'd take your 6 degree angle, and at it to 90, so you'd do that process on 96 degrees. You'll find tan(96) comes out negative, thats because your Z value is going to be negative. Go ahead and graph it on a piece of paper if you don't see why its negative.

Now, that DistanceY I told you to ignore! Lets look at it now. You work it the same as for DistanceX. Lets just say when working out your numbers for X you were looking top-down at your unit, for Y your looking at the side. If your using X/Z already, you'll have to use that same value in your Y/Z. Well, at least it makes figuring out Y easier, just multiple the value from tan(angle) by Z. Problem is it will probably be a decimal that you can't round without it being horribly inaccurate. If it is (which is very likely), you might try finding your Y/Z values as when you found X/Z, then use "Least Common Denominators" to have equal Z values and still the desired accuracy on X and Y.

Ok, now where should I wiki this?

[Argh]

Well... this is not exactly ideal. I do not like the idea of sitting down with a calculator and doing 15 minutes of hasty trig, just to set up a simple test, when we could have a simpler method that wasn't mathematically mushy. Looks like I'm going to have to play with this awhile and do some simple tests to figure out angular constraints, until/if we ever have something a lot more intuitive. At least now I understand the rough relationships of the cone now.

What I'd like (and what I think most people would like) is something more like this:

Code: Select all

Weapon1StartAngleX=0;
Weapon1StartAngleY=45;
Weapon1StartAngleZ=0;
Weapon1MaxTraverseX=0;
Weapon1MinTraverseX=-15;
Weapon1MaxYTraverse=30;
Weapon1MinYTraverse=-30;
Weapon1MaxZTraverse=0;
Weapon1MinZTraverse=0;

The weapon described above, using TA's screwed-up and bass-ackwards coordinate system, would face to the left at a 45-degree angle, would be limited to an upwards pitch of 15 degrees, a side-to-side spin of 30 degrees to the right or left, and no twist in the Z axis, nor downwards pitch in the X axis (it can fire straight ahead, but not down).

Ok, so I had to use a lot more variables... but it all ends up being the same thing. And, unlike the way it was *actually* done, it doesn't require trig, frustration, and yet another big factor keeping ordinary, non-math-whiz types to get into Spring modding. Being a non-math-whiz type of person myself (I'm one of those art weirdoes, who programs out've sheer frustration more than anything else), and having done programming for a lot've non-math-whiz folks before... the way it was done is precisely how not to do it- it looks simple, but it's a lot more involved than it needs to be, and it's not really any more mathematically superior to the way I've broken it down, above. Without the explanation, above, I could've spent weeks figuring this out by experiments.

Sorry to whoever developed this- I am grateful that you put this feature in, I just wish it was a little easier to pick up and use right off the bat. It's not whether it works... it's how. I'll put this in as a feature-request when y'all are a little less neck-deep in bugs and integration challenges

[Archangel of Death]

Well the method you listed would have the added advantage of being able to have different pitch limits than heading limits.

And come on, that wasn't simple enough? I thought it was. You just plug in this number, then mess with fractions for a bit, then plug in that number to double check it.

[Argh]

Oh, now, don't fret- your explanation's just fine, and I truely appreciate the work you put into this, as well as the fact that the Spring devs put the feature in- I'm just whining because I hate math.

I'll work with what we've got, and a feature that's difficult to work with is better than none at all, I always say

[Argh]

Sorry to bring this up again, but I'm totally stumped, and more than a bit frustrated.

I just got done modeling that Spider for the modeling community, and I cannot, for the life of me, figure out how to get a forward-arc weapon that will cover 45 degrees (22.5 degrees from center). Please help, this is not working, period- the best I've been able to get this to do is shoot directly to the right or left

Devs, this should be fixed. It's a bloody nightmare to work with, and worst yet, the unit's AI will not turn the unit to the facing where it has an active gun angle, even if it's in range of a unit. In experiments with my unit firing to the right/left, it literally just sat there and got thrashed by units on the other side, even though it could've turned and killed them easily

[Das Bruce]

I've found they usually drive towards the target untill they by chance get the right firing angle.

[Argh]

I just want it to fire forwards. If it'll face the target, and fire, it's fine. Problem is, it just keeps firing to the sides, not forwards.

[Argh]

Hmm...

weapon1=SPIDERGUN;
WeaponMainDir1= 0.125 0 1;
MaxAngleDif1=45;

[Das Bruce]

Firstly thats 45 degrees either way, cut it in half.

[Argh]

AHA!!!

Guess what... I found a bug. It's really simple...


1. BOS script for turrets assumes a heading of +Y.
2. If the weapon cannot turn to the right (+Y) and get to the target, it will not ever complete the turn.
3. This is fixable with BOS, I think...

[Argh]

Basically, we need this BOS code (or a variant, taking into account the "native angle" of the weapon, for things facing sideways, etc., etc. for any weapons using this for limits on the Y. Weapons using this differential method will only aim to +Y otherwise!

Fixed that, fixed my crappy math on the cone-angle... and voila, it works. I am now the proud father of a killer death-spider thing

heading_01 = heading;
IF ( heading_01 <= 32768 )
{
turn gunaimer to y-axis heading speed <180.0>;
}
IF ( heading_01 > 32768 )
{
turn gunaimer to y-axis 0 - heading speed <180.0>;
}

And the final FBI notation:

weapon1=SPIDERGUN;
WeaponMainDir1= 0.5 0 1;
MaxAngleDif1=90;

[Gnomre]

I ended up doing something remarkably similar on the SWTA infantry for the next version. They had FBI arcs previously (and in the current public release), which was all fine and dandy until we played it a little more and realized that it completely ruins gameplay when you're playing on the retreat or trying to effectively use the higher ranges of certain infantry (such as stormtroopers vs droids). My solution was to take out the arc completely and script in a heading detection script, which makes units play a backwards walk animation if they're firing while retreating. I'm actually working on taking that a step further with a new unit by implementing side-stepping as well, but animation is such a pain :[

[Argh]

I have partially overcome the unit-AI problems, both with the scripting described above, and by equipping my units with a "null weapon" that turns much more slowly than the unit, forcing it to to turn. Seems to work fairly well.