Blasters fires only up and left .

[SPIFFEN]

Can someone move some posts to this Thread plz ,
the post that need to be moved are here ( its about 5 posts ) :
http://knucklecracker.com/forums/index.php?topic=1072.msg18717#msg18717

Oh maybe it should be in support ? =P

[UpperKEES]

Like the example given here, I've made another screenshot to prove blasters do not always target the closest creeper:



The blaster keeps firing at the creeper flowing down at the bottom of the ridge, so it wastes a lot of energy. When it would fire on top of the ridge (as it should, because it's closer), all creeper there would be gone in one shot. The mouse pointer was above the orange dot at the moment I made the screenshot.

Edit: now I think about it, the creeper to the right is also closer than the creeper currently targeted.

[Karsten75]

Here is a small map I made to demonstrate blaster behavior.

Doesn't cover the "not firing at closest creeper" but does show that it will ignore deeper creeper at the cost of firing in pre-determined directions.

If I was Virgil and I was writing CW2, I'd change the firing algorithm slightly in that I will have a directional memory to remember where it last looked for (and fired at) creeper and to resume it's search from that position onwards.

It is complicated, but it may mean that weapons that have multiple targeting options do not consistently target the same position (which may be sometime desired, though, so things as always get complicated).
 
 

[UpperKEES]

If I was Virgil and I was writing CW2, I'd change the firing algorithm slightly in that I will have a directional memory to remember where it last looked for (and fired at) creeper and to resume it's search from that position onwards.

Sounds good! An alternative could be firing at the deepest/thickest creeper when the creeper is just as close in multiple directions (to make the shots most effective).

It is indeed complicated and I assume some of the observed behaviour is due to optimization of the algorithm to speed up the game play (just like the 'through-the-wall-damage' is the result of not calling the line-of-sight function for every cell containing creeper).

[Fisherck]

Here is another example of how blasters fire effect a map. In Dream, as shown by the next images, I sent a blaster to each pit holding in the Creeper and armed them at the same time. Everything was the same (I did not use any of the mines to stop any irregularities) except one blaster was on the top and one on the bottom. But I got two different results. The Blaster on the top fired into the pit, saving the survivors (temporarily), But the one on the bottom fired on the much thinner Creeper in front of it (not saving the survivors).

[Karsten75]

If I was Virgil and I was writing CW2, I'd change the firing algorithm slightly in that I will have a directional memory to remember where it last looked for (and fired at) creeper and to resume it's search from that position onwards.

Sounds good! An alternative could be firing at the deepest/thickest creeper when the creeper is just as close in multiple directions (to make the shots most effective).

It is indeed complicated and I assume some of the observed behaviour is due to optimization of the algorithm to speed up the game play (just like the 'through-the-wall-damage' is the result of not calling the line-of-sight function for every cell containing creeper).

I think it is more complicated algorithm-wise rather than CPU intensive. You'd "simply" have to remember the last position fired from and select the next position to scan for creeper.

Here is another example of how blasters fire effect a map. In Dream, as shown by the next images, I sent a blaster to each pit holding in the Creeper and armed them at the same time. Everything was the same (I did not use any of the mines to stop any irregularities) except one blaster was on the top and one on the bottom. But I got two different results. The Blaster on the top fired into the pit, saving the survivors (temporarily), But the one on the bottom fired on the much thinner Creeper in front of it (not saving the survivors).

Looking at your images, I think you observe exactly what is reported here - both blasters are firing into the zone between 9- and 12-o'clock.

[UpperKEES]

I think it is more complicated algorithm-wise rather than CPU intensive. You'd "simply" have to remember the last position fired from and select the next position to scan for creeper.

Like you already describe yourself changing the algorithm probably isn't too hard (although Virgil is the only one who can really answer that).

A blaster still has to 'look around' and determine which cell contains the closest creeper (wherever it starts looking). A blaster has 16 neighboring cells (= blocks), like this:

CCCCC (C = cell, B = blaster)
CBBBC
CBBBC
CBBBC
CCCCC

My impression is that it currently starts looking for creeper at the cell indicated by C. When it finds creeper it shoots there and doesn't look any further, because other creeper can't be closer (it's the first ring around the blaster), which optimizes the game speed. When no creeper is found the blaster will continue looking for creeper in the second ring around the blaster, until the cells are out of range.

This would also (partly) explain why not always the closest creepers is targeted. Creeper at 90^o or 180^o for instance are actually closer than creeper at 45^o, but I think the algorithm just cycles around clockwise because that's faster. Virgil, please correct me when I'm wrong.

[mthw2vc]

I think it is more complicated algorithm-wise rather than CPU intensive. You'd "simply" have to remember the last position fired from and select the next position to scan for creeper.

Like you already describe yourself changing the algorithm probably isn't too hard (although Virgil is the only one who can really answer that).

A blaster still has to 'look around' and determine which cell contains the closest creeper (wherever it starts looking). A blaster has 16 neighboring cells (= blocks), like this:

CCCCC (C = cell, B = blaster)
CBBBC
CBBBC
CBBBC
CCCCC

My impression is that it currently starts looking for creeper at the cell indicated by C. When it finds creeper it shoots there and doesn't look any further, because other creeper can't be closer (it's the first ring around the blaster), which optimizes the game speed. When no creeper is found the blaster will continue looking for creeper in the second ring around the blaster, until the cells are out of range.

This would also (partly) explain why not always the closest creepers is targeted. Creeper at 90^o or 180^o for instance are actually closer than creeper at 45^o, but I think the algorithm just cycles around clockwise because that's faster. Virgil, please correct me when I'm wrong.

I suspect that it actually targets the top row first and checks each square according to its position in the grid, as can be seen in the following diagram. The squares with a B have the blaster.
10 11 12 13 14
15 B2 B3 B4 16
17 B5 B1 B6 18
19 B7 B8 B9 20
21 22 23 24 25

[UpperKEES]

I suspect that it actually targets the top row first and checks each square according to its position in the grid, as can be seen in the following diagram. The squares with a B have the blaster.
10 11 12 13 14
15 B2 B3 B4 16
17 B5 B1 B6 18
19 B7 B8 B9 20
21 22 23 24 25

Also very well possible (and more logical when processing an array), although I've never seen a blaster target cell 16 instead of 17 (or 18 instead of 19). Anyway, I still assume it's an optimization issue and I don't expect Virgil to use the new (faster) CW2 data structures for the final CW1 update, so I guess this will remain the same.

[UpperKEES]

This would also (partly) explain why not always the closest creepers is targeted.

I said 'partly', because blasters targeting creeper flowing down from a ridge still behave in an unexplained way. I was just testing a new map and noticed the same odd behaviour again:



It almost seems like the blaster gets locked onto its target and won't let go....

[knucracker]

You guys catch EVERYTHING :)

You found a small little error in the targeting logic.  I had actually already noticed this when I lifted the function and ported it to game 2.  In game 2 the creeper cells are smaller and more often obscured by the edges of un-dug ground... so there are situations where it became apparent more easily.

I just corrected this in the CW main source trunk so this one will definitely show up in the next patch.  As for the cause, there was a little optimization I had in place that made it favor up-left over lower-right when it searched for the nearest creeper.  This could prevent the blasters from searching half of the field about half of the time.  But, this was a premature optimization and totally not needed.... especially since it produces these artifacts in certain situations.

This is all apropos since I have just implemented a couple targeting algorithms in game 2.  The "find deepest creeper in range" algorithm was extra interesting because of the surrounding ground constraints... interesting enough that I might write a blog posting about it.

[Karsten75]

. interesting enough that I might write a blog posting about it.

Yea, about that... it has been quite a while...

[UpperKEES]

I just corrected this in the CW main source trunk so this one will definitely show up in the next patch.

This is great news! Thanks! :)

[Karsten75]

I just corrected this in the CW main source trunk so this one will definitely show up in the next patch.

This is great news! Thanks! :)

That "next patch" is becoming quite like Bigfoot. Often mentioned, but not often seen in the wild...   :P

7 Patches between January and February of 2010 and nothing since.

[knucracker]

Yea, about that... it has been quite a while...

There's a new blog posting up.  I'll probably chase it with a couple more articles about "Repulsors" and "Micro-Rifts" soon....