Author Topic: Suggestion for small change in wayPointAction  (Read 1446 times)

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 605
    • View Profile
Suggestion for small change in wayPointAction
« on: November 08, 2022, 10:35:51 am »
Code: [Select]
if (CollidesWith > V_EMPTY && CollidesWith < V_UNIT)
{
_attackAction.waypoints.push_back(LastPosition);
LastWayPoint = LastPosition;
}
else if (CollidesWith == V_UNIT)
{
BattleUnit* target = _save->getTile(CurrentPosition)->getOverlappingUnit(_save);
if (target == _aggroTarget)
{
_attackAction.waypoints.push_back(CurrentPosition);
LastWayPoint = CurrentPosition;
}
                                else if(target.getFaction() == _unit.getFaction()
                                {
        _attackAction.waypoints.push_back(LastPosition);
        LastWayPoint = LastPosition;
                                }
}
The new code being this part:
Code: [Select]
                                else if(target.getFaction() == _unit.getFaction()
                                {
        _attackAction.waypoints.push_back(LastPosition);
        LastWayPoint = LastPosition;
                                }
The purpose of that is to make blaster-launching aliens more careful about not nuking their own friends by being at least as careful around them as they are about hitting objects on the way.
The code is still highly risk-taking and often fails to hit the intended target. But I guess for the regular AI that's fine. In my test save it just prevents clearing up an entire room full of aliens.

But in the end it depends on what the goal is gameplay-wise. If it is intended for aliens to have a really high chance to nuke each other, then I guess it's fine as it is.

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 605
    • View Profile
Re: Suggestion for small change in wayPointAction
« Reply #1 on: November 09, 2022, 01:53:00 pm »
In my own implementation I changed it so that it uses a way-point at every directional change the path would make.

That is a much, much safer way of doing it. Of course the negative effect is that it requires more way-points and thus sometimes exceeds the limit and thus doesn't fire the missile at all, where a clean-shot is possible.

I also found issues with the BAM_MISSILE-movement type itself when it comes to the path-finding in the first-place. It vastly changes how the path-finding works with some really unexpected results like making the path much longer (as it doesn't have to care about TUs) and flying through tiles with massive overlap like diagonal walls. In the sense of: Yes, it is theorethically possible the missile can pass through there, if it stays 100% on course. But the slightest deviation and it collides with something and goes boom way before reaching the target.

Using BAM_NORMAL with a MissileTarget-parameter and just changing that the missile-target itself is a valid tile in path-finding lead to much more desirable results in that regard. Basically returning a path wide enough for people to also take.

So having more restictions to how the waypoints for the blaster is set sounds like it would lead to fewer blaster-usages. And partially that is true as some shots are dismissed for requiring too many waypoints. But over the course of a mission more blasters were fired simply because the Aliens didn't blow each other up so much!

Offline Yankes

  • Commander
  • *****
  • Posts: 3207
    • View Profile
Re: Suggestion for small change in wayPointAction
« Reply #2 on: November 09, 2022, 10:42:13 pm »
I do not think that changing BAM_MISSILE is good idea, how many maps you check with it?
Another thing is is not BAM_NORMAL only allow walking? This mean you could not move over gap with it.

Offline Xilmi

  • Moderator
  • Commander
  • ***
  • Posts: 605
    • View Profile
Re: Suggestion for small change in wayPointAction
« Reply #3 on: November 09, 2022, 11:05:28 pm »
Well, I'm just reporting the results of my experiments with and without it. I could make a video where I showcase the differences.
Note that I did all of this with Dijkstra's algorithm. Running the regular (calculate) pathfinding but with 10000 TU's to spare is probably the main reason for the quirky results.

Another thing is is not BAM_NORMAL only allow walking? This mean you could not move over gap with it.
Nope. As long as you have a missileTarget-pointer set, it'll use MT_FLY. Look at the code for getMovementType:
Code: [Select]
/**
 * Gets movement type of unit or movement of missile.
 * @param unit Unit we check path for.
 * @param missileTarget Target of missile in case of `BAM_MISSILE
 * @return `MT_FLY` if we have `missileTarget` other wise `unit` move type.
 */
MovementType Pathfinding::getMovementType(const BattleUnit *unit, const BattleUnit *missileTarget, BattleActionMove bam) const
{
if (missileTarget)
{
return MT_FLY;
}
else
{
if (bam == BAM_SNEAK)
{
return MT_WALK;
}
else
{
return unit->getMovementType();
}
}
}