hover=1 units with turret = 1 weapons are broken

[smoth]

viewtopic.php?f=14&t=14660

we detailed it in this thread. I even posted a video. Relevant findings are on page 2.

in essense the hover =1 aka brawler type aircraft when given a turreted weapon will forget it's target when told to attack a unit.

video of failing brawlers

[FLOZi]

what? hover=1 should have abso-f'ing-lutely nothing to do with brawlers.

[smoth]

hoverattack.. come on man.

[KDR_11k]

Those tags are confusing.

BTW, I'm for killing the stupid canHover and floater tags since all they do is spam crap into the infolog since it uses the movetype instead and there uses that stupid name logic instead of proper tags.

[smoth]

Bumping to know if this was looked into yet?

[imbaczek]

in short, no.

the behaviour is definitely a bug, but I've got absolutely no idea what causes it.

[Argh]

I found it was tied to weapon ranges, and that different weapon types operated differently- for example, Cannon weapons work pretty well.

Maybe it's an issue with how these units are trying to get into range?

[smoth]

nope because they will land not 5 feet from a target.

[Argh]

It's probably also tied to that mandatory angle they use, to evaluate whether they can target stuff- they probably don't see the target most of the time, like other units with restricted fire-arcs can. That should get removed, imo, and Spring should go ahead and force the older mods to give those weapons fire-arcs, to replicate the old behavior.

[smoth]

IIRC, it doesn't have an arc restriction as it was a flying unit.

[Argh]

From CTAAirMoveType::UpdateFlying():

Code: Select all

case FLY_ATTACKING:{
                                if (owner->unitDef->airStrafe) {
                                        float3 relPos = pos - circlingPos;
                                        if (relPos.x < 0.0001f && relPos.x > -0.0001f)
                                                relPos.x = 0.0001f;
                                        relPos.y = 0;
                                        relPos.Normalize();
                                        CMatrix44f rot;
                                        if (gs->randFloat() > 0.5f)
                                                rot.RotateY(0.6f + gs->randFloat() * 0.6f);
                                        else
                                                rot.RotateY(-(0.6f + gs->randFloat() * 0.6f));
                                        float3 newPos = rot.Mul(relPos);
                                        newPos = newPos.Normalize() * goalDistance;

                                        // Go there in a straight line
					goalPos = circlingPos + newPos;
                                }
                                break;

It angles without taking into consideration the weapon used.

[KDR_11k]

Um, why are you quoting the "move around the target in a circle" code for that comment?

[Argh]

Well, my theory is that the Unit's not checking either LOS or against the ray-tests for the weapons correctly, or that it's not getting a new instruction to move to the target... part of the problems I saw, when I looked into this, is that you can build things that think they're in range, at the MoveType level, but whose weapons won't actually fire- i.e., they'll hover around a target forever.

[KDR_11k]

What?

[Argh]

Here, lemme break it down. We have multiple issues here that I saw in testing:

1. Units do not evaluate available targets and generate new Attack orders. That's the primary cause of Smoth's complaint. I dunno whether they're not updating LOS correctly, or whether it has something to do with:

Code: Select all

 // If we are close to our goal, we should go slow enough to be able to break in time
	// new additional rule: if in attack mode or if we have more move orders then this is
	// an intermediate waypoint, don't slow down (FIXME)

        /// if (flyState != FLY_ATTACKING && dist < breakDistance && !owner->commandAI->HasMoreMoveCommands()) {
	if (flyState != FLY_ATTACKING && dist < breakDistance) {
                realMax = dist / (speed.Length2D() + 0.01f) * decRate;
        }

2. Even if the Unit is in an Attack state, it can frequently fail to fire its weapons. This seems to be tied to range, and suggests that it's not moving close enough to targets, because it doesn't take the weapon's real range into consideration properly.

[Fanger]

Well, my theory is that...

Ah I dont think we want to have a theoretical discussion on what the code might do.. I think smoth would like someone to READ the code and tell him what is exactly going on, and then fix it so its not happening in the way he has specified..

theory doesnt really help in this situation..

[Argh]

I wish it was that simple, Fanger, but it ain't. Try reading the source sometime, it'll be educational. The amount of stuff tied to other stuff in Spring makes it hard to pin stuff down. Sometimes, theory about what should happen tells us where things are actually broken.

Ok, now I've read through a bit more... maybe the problem is in AirCAI.cpp:

Code: Select all

if(commandQue.empty()){
                if(myPlane->aircraftState == AAirMoveType::AIRCRAFT_FLYING
                        && !owner->unitDef->DontLand() && myPlane->autoLand){
                        StopMove();
//			myPlane->SetState(AAirMoveType::AIRCRAFT_LANDING);
		}

                if(owner->unitDef->canAttack && owner->fireState>=2
                                && owner->moveState != 0 && owner->maxRange > 0){
                        if(myPlane->IsFighter()){
                                float testRad=1000 * owner->moveState;
                                CUnit* enemy=helper->GetClosestEnemyAircraft(
                                        owner->pos + (owner->speed * 10), testRad, owner->allyteam);
                                if(IsValidTarget(enemy)) {
                                        Command nc;
                                        nc.id = CMD_ATTACK;
                                        nc.params.push_back(enemy->id);
                                        nc.options = 0;
                                        commandQue.push_front(nc);
                                        inCommand = false;
                                        return;
                                }
                        }
                        float testRad = 500 * owner->moveState;
                        CUnit* enemy = helper->GetClosestEnemyUnit(
                                owner->pos + (owner->speed * 20), testRad, owner->allyteam);
                        if(IsValidTarget(enemy)) {
                                Command nc;
                                nc.id = CMD_ATTACK;
                                nc.params.push_back(enemy->id);
                                nc.options = 0;
                                commandQue.push_front(nc);
                                inCommand = false;
                                return;
                        }
                }
                return;
        }

Maybe this line is the problem:

Code: Select all

CUnit* enemy = helper->GetClosestEnemyUnit(
                                owner->pos + (owner->speed * 20), testRad, owner->allyteam);

Because it's setting the size of the search radius too small, when speed is really low (I'm not sure if it even has a speed, when circling)? So, we need to use a search radius the size of the longest-range weapon instead? Or just the sight radius?

[lurker]

You misread a bit, argh. The first parameter is (position + extrapolated movement) and the radius, testRad, is 500 times the following:
int moveState; //0=hold pos,1=maneuvre,2=roam
So while that probably should be changed, 500+ elmos is plenty. This code only runs when the unit has no command, so if this problem only shows up when it's on hold position, then it could be dropping the attack when it shouldn't be.

[Argh]

Hmm.

What about this, in MobileAI?

Code: Select all

     // if our target is dead or we lost it then stop attacking
	// NOTE: unit should actually just continue to target area!
	if (targetDied || (c.params.size() == 1 && UpdateTargetLostTimer(int(c.params[0])) == 0)) {
                // cancel keeppointingto
		StopMove();
                FinishCommand();
                return;

[Forboding Angel]

Ya know guys, argh is actually trying to help, and so far he seems to be the only one looking into the source trying to figure it out, so maybe you should try being thankful for him at least trying.