Restricted-arc weapons and Spring's aiming code.

Argh · Post by **Argh** » 13 Jan 2007, 22:54

It's not strange... just broken. That said, my solution works fairly well, most of the time. I see the occasional borked bit, due to how slowly the refresh occurs, but it's something I can live with.

smoth · Post by **smoth** » 13 Jan 2007, 23:22

that is all fine and good argh, but the rest of us do not want to use a null gun to point the unit right.

FLOZi · Post by **FLOZi** » 15 Jan 2007, 03:54

smoth wrote:that is all fine and good argh, but the rest of us do not want to use a null gun to point the unit right.

indeed. /me whipcracks at titan

Post by **ILMTitan** » 16 Jan 2007, 06:45

Committing a fix right now. It was actually a larger problem of units not checking for attackers and close enemy units correctly while idling, but was most obvious in restricted arc weapons due to the fact that the weapons would often attack the target on their own when in range. Revision #3181

Argh · Post by **Argh** » 16 Jan 2007, 06:56

Kick-ass. Will check it out immediately.

Argh · Post by **Argh** » 16 Jan 2007, 08:33

Ok, tested it.

On the one hand, it works very well, in terms of detecting targets. I'd say that that bug is fixed.

On the other hand... well, it's doing something funky still: whenever AimWeaponX() is being invoked (i.e., whenever an enemy enters LOS) restricted-arc weapons are doing this bizarre behavior where they constantly return to 0 on the Y-axis, instead of remaining aimed. This happens every frame or so, and looks quite bad.

This is specific to restricted-arc weapons- non-restricted ones don't show this behavior. It's almost like they are constantly being sent a 0 vector, instead following directions from the BOS, so they first turn due to the BOS, then are told to turn towards 0 Y, then spin further towards the target, etc. It effectively makes units lock up when aiming to the sides of a wide arc.

I've seen this problem since I first messed with restricted-arc weapons, but I got around it by using code like this:

Code: Select all

heading_01 = heading;
 	if ( heading_01 <= 32768 )
 	{
 		turn torso to y-axis heading speed <300.0>;
 	}
 	if ( heading_01 > 32768 )
 	{
 		turn torso to y-axis 0 - heading speed <300.0>;
 	}

This code basically told the Piece to either spin to the right or the left, depending on the vector to the target.

Well... this code no longer seems to help any. There's something very funky in the way that restricted-arc weapons are being aimed by Spring... it's almost like it's checking to see if they've passed their maximum-allowed angle, along with everything else- and if they have, instead of *stopping* their rotation, which is what they should do, they're attempting to rotate back to 0 Y

This is, obviously, not ideal.

So, I checked through the code...

Argh · Post by **Argh** » 16 Jan 2007, 09:12

...hmm... this is interesting, and might be where this odd behavior starts (from Weapon.cpp):

Code: Select all

short int heading=GetHeadingFromVector(wantedDir.x,wantedDir.z);
			short int pitch=(short int) (asin(wantedDir.dot(owner->updir))*(32768/PI));
			std::vector<int> args;
			args.push_back(short(heading-owner->heading));
			args.push_back(pitch);
			owner->cob->Call(COBFN_AimPrimary+weaponNum,args,ScriptCallback,this,0);

If I'm reading this right, then this argument, unlike OTA, will return a short, instead of a short int, which means that the number returned is frequently negative. So therefore, if I write my code like this:

Code: Select all

	heading_01 = heading;
 	if ( heading_01 < 0)
 	{
 		turn torso to y-axis heading speed <300.0>;
 	}
 	if ( heading_01 >= 0)
 	{
 		turn torso to y-axis 0 - heading speed <300.0>;
 	}

... it should work.

<tests>

Nope, the exact same problem is occurring- it keeps trying to return to 0 Y.

Argh · Post by **Argh** » 16 Jan 2007, 09:45

Hmm. Might this be happening because Heading and Pitch aren't being calculated the same way, and are returning very different values?

maybe it should be:

short int heading=(short int) (asin(wantedDir.dot(owner->frontdir))*(32768/PI));

Argh · Post by **Argh** » 23 Jan 2007, 19:16

This is still broken, please fix so that I can make pretty videos of my latest project

Post by **ILMTitan** » 23 Jan 2007, 19:31

It seemed to be working ok with Gundam. I think before I can fix what you want, I may need to learn a little more about modding. What unit are you testing with, anyway (I assume it is in nano-blobs)?

Argh · Post by **Argh** » 23 Jan 2007, 20:49

Funny thing happened- right after I got done with lunch, I went through the code and found that the problem is scripting, not with the code. Big fat nevermind- it's working properly, if the script behaves itself

Post by **ILMTitan** » 23 Jan 2007, 23:01

Good to know. Argh, thank you for being such an awesome tester.

Argh · Post by **Argh** » 24 Jan 2007, 00:29

LOL! "Awesome tester"... I should've caught my scripting error three weeks ago

Ah well, it's all fixed and works, which is all that really matters.

smoth · Post by **smoth** » 24 Jan 2007, 00:59

I was just psyched to see it getting looked at again, thanks guys.

Guessmyname · Post by **Guessmyname** » 24 Jan 2007, 19:38

So does arc-aiming work now?

Argh · Post by **Argh** » 24 Jan 2007, 21:32

Spring RTS Engine

Restricted-arc weapons and Spring's aiming code.