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
Like the example given here (http://knucklecracker.com/forums/index.php?topic=942.0), I've made another screenshot to prove blasters do not always target the closest creeper:
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=4045.0;attach=950;image)
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.
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).
Quote from: Karsten75 on July 23, 2010, 01:02:14 PM
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).
Here is another example of how blasters fire effect a map. In Dream (http://knucklecracker.com/creeperworld/mapcomments.php?id=2654&page=), 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).
Quote from: UpperKEES on July 23, 2010, 01:10:16 PM
Quote from: Karsten75 on July 23, 2010, 01:02:14 PM
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.
Quote from: Fisherck on July 23, 2010, 01:39:42 PM
Here is another example of how blasters fire effect a map. In Dream (http://knucklecracker.com/creeperworld/mapcomments.php?id=2654&page=), 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.
Quote from: Karsten75 on July 23, 2010, 02:09:41 PM
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.
Quote from: UpperKEES on July 23, 2010, 02:28:19 PM
Quote from: Karsten75 on July 23, 2010, 02:09:41 PM
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 90o or 180o for instance are actually closer than creeper at 45o, 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
Quote from: mthw2vc on July 23, 2010, 02:56:33 PM
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.
Quote from: UpperKEES on July 23, 2010, 02:28:19 PM
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:
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=4045.0;attach=960;image)
It almost seems like the blaster gets locked onto its target and won't let go....
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.
Quote from: virgilw on July 23, 2010, 07:31:16 PM
. interesting enough that I might write a blog posting about it.
Yea, about that... it has been quite a while...
Quote from: virgilw on July 23, 2010, 07:31:16 PM
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! :)
Quote from: UpperKEES on July 23, 2010, 08:27:37 PM
Quote from: virgilw on July 23, 2010, 07:31:16 PM
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.
Quote from: Karsten75 on July 23, 2010, 07:45:48 PM
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....
Quote from: Karsten75 on July 23, 2010, 08:56:12 PM
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.
You can partially thank Adobe for the delay over the last month.... I won't release the final patch till they get AIR sorted out. That should happen in the next 2-3 weeks. The reason for this is that I have to update the exe and dmg file that people can download, and I want to bundle the improved version of AIR 2 with that.
But I will have the final patch in beta soon... as in I plan to work on it this weekend and see how much progress I can make. It'll take a few days away from game 2 work, but it is something I have to do....
Quote from: virgilw on July 23, 2010, 10:11:17 PM
Quote from: Karsten75 on July 23, 2010, 08:56:12 PM
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.
You can partially thank Adobe for the delay over the last month.... I won't release the final patch till they get AIR sorted out. That should happen in the next 2-3 weeks. The reason for this is that I have to update the exe and dmg file that people can download, and I want to bundle the improved version of AIR 2 with that.
But I will have the final patch in beta soon... as in I plan to work on it this weekend and see how much progress I can make. It'll take a few days away from game 2 work, but it is something I have to do....
So long as you get it done, take all the time you need.
Quote from: virgilw on July 23, 2010, 10:11:17 PM
Quote from: Karsten75 on July 23, 2010, 08:56:12 PM
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.
You can partially thank Adobe for the delay over the last month.... I won't release the final patch till they get AIR sorted out. That should happen in the next 2-3 weeks. The reason for this is that I have to update the exe and dmg file that people can download, and I want to bundle the improved version of AIR 2 with that.
But I will have the final patch in beta soon... as in I plan to work on it this weekend and see how much progress I can make. It'll take a few days away from game 2 work, but it is something I have to do....
I was kidding you more than anything. I'd *much* rather see you put the effort into CW2 than a patch for CW. But, as always, it's your call and perhaps a break from CW2 will be nice?