Restricted-arc weapons and Spring's aiming code.

Argh · Post by **Argh** » 17 Dec 2006, 12:35

Well, it's still borked, basically, and since I'm working on something where it'd be darn nice if it worked, I thought I'd bring it up again.

Units with restricted arcs still won't turn towards their Weapon1's arc, nor attempt to get a valid arc until it's waaaaay too late to matter. From what it appears, they don't search outside their cones except for maybe every second or so.

This is not ideal. I think that units need to have a "weapon" of some kind (call it "weapon0") that always, always ALWAYS causes the unit to try and face the in the direction of the nearest enemy. That's all it needs to do. I don't care if it makes the unit move in that direction- I just want them to not just ignore things that aren't in their defined arcs. The arcs were meant to allow us to have physically-correct aiming behaviors, not make our units blind

Not doing so causes far more problems than it solves.

I am working on a project involving a lot of infantry, and while I can get them to work, technically... the results leave much to be desired. My guys, if facing the wrong way, frequently just stand there with their thumbs up their bums when being attacked from a quarter on which they don't have an arc, and this frequently leads to very bad gameplay

And yes, if anybody has a reliable solution for this issue, I'm listening. My attempts to find one have not thus far been successful.

Argh · Post by **Argh** » 18 Dec 2006, 01:37

Smoth stated that ILMTitan wrote a patch that addressed this issue, but it was not accepted. Anybody still have that sourcecode?

Post by **ILMTitan** » 18 Dec 2006, 03:13

I wrote a patch, and it was accepted, iirc. It may just be not working. I even wrote a bug fix for it. I may need to tie it into update and not slow update or something. Fixing it is #2 on my to do list, right behind making units not slow down approaching way points. After the holidays, I hope to have some time.

Argh · Post by **Argh** » 18 Dec 2006, 04:06

Okie doke. Please let me know where things are going on this- my project is probably going to need to wait until this is repaired to balance and release, but I am sure it will not be done before January 1st anyhow.

KDR_11k · Post by **KDR_11k** » 18 Dec 2006, 08:30

It seems to work in Dozerz, the enemy has to be in range of the first weapon I think.

Argh · Post by **Argh** » 18 Dec 2006, 10:12

Ah, so it's Weapon1? You're sure? <experiments>

Argh · Post by **Argh** » 18 Dec 2006, 10:34

Thus far, no banana. I'm going to take a look at Dozerz, which I have been meaning to see anyhow, and see what, if anything is different, or if the gameplay is just slow enough that this problem isn't as readily apparent. Right now, if I face the infantry away from enemies, they will just sit there getting slaughtered, but are just fine if facing in their appropriate arc. Coding up a Weapon1, assigning NOWEAPON to it, and putting a blank script and a point this "weapon" should reference for aiming didn't seem to solve this.

Argh · Post by **Argh** » 18 Dec 2006, 10:47

Nope. Adopting your settings did not result in correct behavior. They will stand there with their backs to the enemy, and will only start turning when enemies reach the edge of their restricted arc.

Gonna try another experiment... maybe a weapon2 with a "restricted" arc that's explicitly given, but is really a 360...

Argh · Post by **Argh** » 18 Dec 2006, 11:10

AHA!

Ok, it's at least... kind've solved. Not perfectly, but meh, I'll take anything that's even slightly better than the default.

First off, KDR, you were basically right. Weapon1 is the key.

Therefore... Weapon1 looks like this:

Code: Select all

	Weapon1=NOWEAPON;
	OnlyTargetCategory1=GROUND;
	WeaponMainDir1=0 0 1;
	MaxAngleDif1=360;

Weapon1 is just a proxy- NOWEAPON is a silent, invisible weapon without FX. The Dir is important, too- setting it to anything other than 0 0 1 does not result in good behavior.

This provides a signal whenever Weapon1 triggers, that at least makes the unit want to turn.

It isn't perfect- the search seems to be a lot slower than the default search, or runs less frequently (probably because it's more expensive code, duh). But now whenever it runs, it gets a "hit" and responds. Which is a lot cooler than having my poor infantry ignore the guys slaughtering their squad right behind them

Argh · Post by **Argh** » 18 Dec 2006, 11:49

Ah... now this is really fascinating.

Setting up the null-gun so that it has a range greater than the actual gun results in borked behaviors. You can actually make the units just sit there, never getting closer to each other, forever, because they think they're "in range". However, they will face the right way.

Setting up the null-gun so that it has a range less than the actual gun results in borked behaviors. The null-gun doesn't activate enough to actually get the unit going in the right direction.

So, it needs to have the actual range of the gun being called. Which means that until the search runs and finds a valid target, the unit will just stand there, but it might respond quickly enough to avoid getting completely wasted without firing a shot.

In case I haven't made this clear- what I'm doing is a hackish workaround, and I still want this fixed if at all possible

Argh · Post by **Argh** » 18 Dec 2006, 12:13

Yup... definitely THERE now. After setting up all of my weapons like this:

Code: Select all

[FLAMETHROWER]
	{
///////////////////////WEAPON DEFINITION STUFF
	name=Flame Thrower;
	rendertype=5;
	lineofsight=1;
	turret=1;

////////////////GAME BALANCE
	range=125;
	reloadtime=2.5;
	weaponVelocity=188;
	areaofeffect=32;
	Tolerance=1000;
//////////BURST
	burst=25;
	burstrate=0.04;
	sprayangle=2000;
///////////SPECIAL
	FireStarter=100;
	GroundBounce=1;
	NoSelfDamage=1;
	AvoidFriendly=0;
	CollideFriendly=0;
	explosiongenerator=custom:FLAMETHROWER_FX;

////////////////GRAPHICS
	ColorMap=1.0 1.0 1.0 0.01   1.0 1.0 0.5 0.01   1.0 1.0 0.3 0.01   1.0 1.0 0.3 0.01   1.0 0.5 0.15 0.01   1.0 0.5 0.15 0.01   0.025 0.01 0.01  0 0 0 0.01;
	texture1=flame;
	FlameGfxTime=1.10;
	size=1;
	sizegrowth=0.5;

////////////////SOUND
	SoundStart=Flamhvy1;
	SoundStartVolume=10;

////////////////RESERVED STUFF
	ImpulseFactor=0;
	ImpulseBoost=0;
	CraterMult=0;
	CraterBoost=0;

	[DAMAGE]
		{
		default=5;
		infantry=11;	
		}
}

[FLAMETHROWER_NULLGUN]
	{
	rendertype=4;
	texture1=null_texture;
	lineofsight=1;
	turret=1;
	range=125;
	weaponvelocity=1000;
	reloadtime=0.25;
	impulsefactor=0;
	impulseBoost=0; 
	craterMult=0; 
	craterBoost=0;
	areaofeffect=1;
	AvoidFriendly=0;
	CollideFriendly=0;
	Tolerance=100;
	ExplosionSpeed=128;
	NoSelfDamage=1;
	explosiongenerator=custom:NULL_FX;	
	[DAMAGE]
		{
		default=00000.1;
		}
	}

And then setting up my FBI like this:

Code: Select all

///////////////////WEAPONS

	Weapon1=FLAMETHROWER_NULLGUN;
	OnlyTargetCategory1=GROUND;
	WeaponMainDir1=0 0 1;
	MaxAngleDif1=360;

	Weapon2=FLAMETHROWER;
	OnlyTargetCategory2=GROUND;
	WeaponMainDir2= 0.667 0 1;
	MaxAngleDif2=120;

And, finally, setting up my aiming code like this:

Code: Select all

AimWeapon2(heading, pitch)
{
	signal SIG_AIM;
	set-signal-mask SIG_AIM;	
 	heading_01 = heading;
 	if ( heading_01 <= 32768 )
 	{
 		turn torso to y-axis heading speed <150.0>;
 	}
 	if ( heading_01 > 32768 )
 	{
 		turn torso to y-axis 0 - heading speed <150.0>;
 	}
	wait-for-turn torso around y-axis;
	start-script RestoreAfterDelay();
	return (1);
}

You get almost perfect behavior.

Now, to see if I can drop the reload time on that null weapon to something ridiculous... I am going to be wasting CPU cycles "aiming" it, and I don't want to occur very often.

Argh · Post by **Argh** » 18 Dec 2006, 12:30

And yes, that works just fine. Cool. Problem solved. It's not quite as perfect as it should be, and it's using a lot of CPU steps it shouldn't have to, but it works most of the time and isn't too terribly evil.

KDR_11k · Post by **KDR_11k** » 18 Dec 2006, 14:03

Hm, strange, my dozers always turned just enough that their target is in the weapon1 arc (not further, if it's in the arc they stop turning) and by narrowing that I could make them turn more than necessary (which makes them turn their shield enough to cover themselves from the target).

Is the limited arc necessary for gameplay or just the result of the limited range of movement of the human torso? In GINTA I opted for having infantry run "backwards" (turn their body by 180├é┬░ and play different running animation) when shooting at something behind them, prevents unnatural torso twists but still lets them shoot in any direction.

Argh · Post by **Argh** » 18 Dec 2006, 14:47

Both. Real people generally have to turn around to shoot backwards, and can't shoot accurately while running backwards, and I want the units to have to perform a full turn, basically. The final results of this work very well, although you will see the occasional bit where a unit hangs for fraction of a second... it's very minor, and looks natural. Just a pity that I had to do it this way at all.

As for the dozers... I dunno, honestly. Reading through your scripts, I am wondering why you're not having problems with the arcs- you aren't compensating for the angle correctly:

Weapon1=Shield;
WeaponMainDir1=0 0 1;
MaxAngleDif1=40;

Will result in an arc for that "weapon" that is 40 degrees starting at dead center +Z.

I dunno why you're not seeing fairly borked aiming behaviors, tbh, but I haven't actually played the mod and looked at how well it actually works.

<looks at mod>

Ah. You're getting away with that, because you're using the aiming arcs to validate firing conditions- you're not actually using the script to line up your weapons. I can't do it that way- I want physical accuracy. No shots coming out at odd angles.

Try keeping everything in the mod the same, except use a SpireRook, and make its weapon the Dozerz's laser. Keep the animation code intact for the gun, and I think you'll see what I've been griping about.

KDR_11k · Post by **KDR_11k** » 21 Dec 2006, 12:53

Argh wrote:As for the dozers... I dunno, honestly. Reading through your scripts, I am wondering why you're not having problems with the arcs- you aren't compensating for the angle correctly:

Weapon1=Shield;
WeaponMainDir1=0 0 1;
MaxAngleDif1=40;

Will result in an arc for that "weapon" that is 40 degrees starting at dead center +Z.

Actually no, I was suprised by that at first as well but when I was compensating for the angle (back then it was 90├é┬░) the aiming arc was offset to the side, the vector I gave it was used as the center of the arc instead of the side. I had the vector pointing 45├é┬░ to the side and a 90├é┬░ arc from there and the dozers could shoot anything 90├é┬░ to their left to right in front. When I turned the vector to aim at the front the behaviour was correct.

Pxtl · Post by **Pxtl** » 21 Dec 2006, 15:28

I would think most people can't shoot accurately when running forwards either (other than John Rambo). Personally, I'd go with KDR's approach, but slow them to a swift, hunched, walking pace when firing.

Argh · Post by **Argh** » 23 Dec 2006, 08:18

Making the unit go to a slower speed and use a different animation is trivial, but this mod is not that concerned with realism. The big problem was getting the darn things to see and engage targets that showed up behind them.

KDR_11k · Post by **KDR_11k** » 23 Dec 2006, 09:56

It's not about realism, it's about ease of control.

smoth · Post by **smoth** » 13 Jan 2007, 21:37

http://cs.selu.edu/~ssmith/spring/badfirearc.zip

coreprimeindustrial area and gundam 1.1 required.

This demo shows exactly the problem with fire arcs. Please view it.

KDR_11k · Post by **KDR_11k** » 13 Jan 2007, 21:49

I've tested it with Dozers now, when approached with hold fire they don't turn around either but after you open fire some turn around after a while. It's really strange

Spring RTS Engine

Restricted-arc weapons and Spring's aiming code.

Restricted-arc weapons and Spring's aiming code.

Well