Hurricane Search Pattern

Obsolete · Post by **Obsolete** » Sun Jan 01, 2012 7:15 am

I thought Hurricanes were supposed to search in a 5x5 pattern, if there is nothing in the hex designated.

I tried to attack CLOSE terrain. Turns out there was no unit in there, but there was an 8Rad 2 tiles away. But for some reason the hurricane still decided to just attack the empty hex only.

Wondering is this expected in certain cases?

Post by **pipfromslitherine** » Sun Jan 01, 2012 8:25 pm

Looking at the script, I think it's a 5 tile radius, so it is possible that it was outside the 'circle' even though it would be within a 5x5 grid.

Cheers

Pip

Obsolete · Post by **Obsolete** » Sun Jan 01, 2012 9:00 pm

Position of Target hex & 8-Rad hex.

Obsolete · Post by **Obsolete** » Sun Jan 01, 2012 9:18 pm

Alright, it just happened AGAIN in my next trial. This time my opponent put his 8-rad in the entrance to the fort, exactly adjacant to the center flag building. And yet my Hurricane once again avoids hitting the 8-rad, and instead straffs three totally empty tiles.

Obsolete · Post by **Obsolete** » Tue Jan 03, 2012 5:30 am

Grrr, I'm still just not (getting it).

I targeted a light fortification (hill). Turns out there was nothing in it, but there was a PzIII 2 tiles away. Yet my Hurricane again totally ignores going after it, and simply shoots blanks instead on the hill to give me that 3-tile vision run.

Merr · Post by **Merr** » Tue Jan 03, 2012 6:07 am

Obsolete,

Whats the name of the scenario?

I did find a bug in the function FindAirTarget ... The x/y for the check "IsValidTile" is transposed where the parameter x is swapped with y.

If I knew the map, I can check (in the editor) the x/y location that you're attacking and see if what the transposed x/y location is on the map ... in which case, it would get screwed up.

This is the condition in question in the FindAirTarget ...
Note that x=j and y=i ... but the condition is swapping i and j for "IsValidTile" ;

Code: Select all

if( (IsValidTile(i,j)==1) && ( j>=0) && (j<GetMapWidth()) && (i>=0) && (i<GetMapHeight()))

Here's the entire function ;

Code: Select all

FUNCTION FindAirTarget(x, y, width, side)
{
int i ;
int j ;
int best ;
int dist ;
int bestX ;
int bestY ;
int ret ;
	
	best = 9999 ;

	for(i=y-width;i<=y+width;i++)
	{
		for(j=x-width;j<=x+width;j++)
		{
			if( (IsValidTile(i,j)==1) && ( j>=0) && (j<GetMapWidth()) && (i>=0) && (i<GetMapHeight()))
			{
				dist = GetUnitOnTile( j, i ) ;
				
				if( dist != -1 )
				{
					if( (GetUnitSide( dist ) == side ) && (IsUnitValid(dist) == 1) )
					{
						dist = GetDistanceBetweenTiles( x, y, j, i ) ;
						
						if( dist < best )
						{
							best = dist ;
							bestX = j ;
							bestY = i ;
						}
					}
				}

			}
		}
	}
	
	if( best != 9999 )
	{
		ret = bestX ;
		ret = ret << 12 ;
		ret = ret | bestY ;
	}
	
	return ret ;
}

If it thinks the tile isn't valid then it won't work correctly?

-Merr

Obsolete · Post by **Obsolete** » Tue Jan 03, 2012 6:15 am

Merr, I've been trying to experiment different openings on the DESERT FORT scenario as of late.

So these are where most the anomalies occur in my games. Hopefully you found (the glitch), because I still can't make sense a lot of times from what I see.

Merr · Post by **Merr** » Tue Jan 03, 2012 7:16 am

Obsolete wrote:Merr, I've been trying to experiment different openings on the DESERT FORT scenario as of late.

So these are where most the anomalies occur in my games. Hopefully you found (the glitch), because I still can't make sense a lot of times from what I see.

Yes ... I just tested the change ... it works!!

The "IsValidTile( i, j)" should read "IsValidTile( j, i )" .

Again, the bug only appears on maps that aren't exactly square. I tested a rectangle map and made sure the target tile (when inversed) was off the playing area ... The hurricane didn't find the target that was within 5 tiles. After the change, it found the target!!!

Nice spot Obsolete ...

I checked the scenario "Desert Fort" .... The fort's center building x/y is 23,32 ... the inverse is 32,23 which is off the playing area!

Merr · Post by **Merr** » Tue Jan 03, 2012 7:37 am

Also, to make it clear ... It's not the original target tile that's the problem ... it's the search tiles.

So, with the Desert Fort map ... the forts center building is the beginning point that the scripts think it's an invalid tile.
Any tile to the right of that building (towards the German side) is INVALID, as far as the script reads it, and it won't consider those tiles to search.

- Merr

Post by **pipfromslitherine** » Tue Jan 03, 2012 9:19 pm

Wow - that is a good spot Merr. I'm gonna blame that one on Iain, mainly because I think he's still on holiday

.

I'll fix it now, and hopefully it will be in the SL release.

Thanks guys.

Cheers

Pip

Grimnirsson · Post by **Grimnirsson** » Tue Jan 03, 2012 10:11 pm

When is SL supposed to be out Pip?

Post by **pipfromslitherine** » Wed Jan 04, 2012 6:58 pm

As soon as we can! We are aiming to get it done and finally done in the next week or so.

Cheers

Pip

Post by **IainMcNeil** » Thu Jan 05, 2012 10:01 am

Hmmm, I did the search pattern code for an airstrike....?

Well at least its fixed!

Obsolete · Post by **Obsolete** » Fri Jan 06, 2012 3:48 am

Good, not only did we stomp a bug, but I feel more sane now.

Now if we can just PLEASE, PLEASE, PLEASE prevent the GUI from LYING to the user, and actually show the true count of ammo remaining?

It makes absolutely no sense that I have to keep tracking this by pen & paper because the extra defensive shot doesn't register on the GUI.

We've all been burned by this and I just don't get why it won't be fixed, especially since it's such a simple thing to repair. It's not like you are giving away trade secrets here, everyone knows the defending units get the extra shot, so why do you have to make this so damn bloody painful to the player?

My memory isn't getting as good as it used to, so I don't see myself giving up excel charting in my maps any time soon.