search arcs

[USSAmerica]

Thanks for your hard work on this and so many other issues, Michael. [:)]

Question for you.  Why would there be a case where the allocation should be going counter-clockwise?  It seems to me easier for everyone to keep track of if it is always allocated clockwise.

Also, have you been able to tell if this affects ASW arcs as well?

[michaelm75au]

Yes it would affect ASW.

If i set a search for 090 to 270, which half of the circle do I patrol? The top or the bottom?

If I set a search for 090 to 310, do I really mean to patrol the 220 degree sector? Or I am really after the 140 degree sector?

Plane allocation always begins from the first patrol arc.

I really think that a direction would correct this issue as even with my change to the code, it is still possible to get the direction wrong especially if the difference between the two angles is more than 180 degrees.

[Jones944]

I like the idea of being able to set the direction. It would allow me to control where the AM and PM portions of the arc occur when using two squadrons to patrol from the same base.

[witpqs]

Thanks Michael.

If you made the direction always be clockwise instead of adding that to the interface, that would be fine with me as that was understood as the intention anyway.

[Bullwinkle58]

ORIGINAL: michaelm

Yes it would affect ASW.

If i set a search for 090 to 270, which half of the circle do I patrol? The top or the bottom?

If I set a search for 090 to 310, do I really mean to patrol the 220 degree sector? Or I am really after the 140 degree sector?

Plane allocation always begins from the first patrol arc.

I really think that a direction would correct this issue as even with my change to the code, it is still possible to get the direction wrong especially if the difference between the two angles is more than 180 degrees.

A suggestion, may not matter to most people, but I have a very color-intensive memory and real-time perception. It's far weaker for text and numbers, but very strong for visuals, especially color and polygons. I've exposed this several times in the forum in not "seeing" certain things in the various interface screens that other players immediately notice.

To me, the two colors chosen for the AM and PM arcs are not memorable, or meaningful. They're too close to each other in hue, and don't tie to any mnemonic. If you change the search arc displays to reflect what the code is doing, might I suggest two different colors? I don't know what colors reflect morning and night, or if that would be culturally consistent across all of the nations AE players come from, but just something strikingly diferent would help me.

As for ensuring players can tell which part of the circle is being patrolled after they set their arcs, could you do a "negative" patrol area, where the un-patrolled arc is also shown in color? So, AM maybe red (sunrise), PM maybe navy blue (afternoon sky) and the unpatrolled remainder black/white/orange/etc., either with pie slices or not?

Just a suggestion. I don't recall all of which colors are already claimed by aircraft ranges and the like, so I may be off in my suggestions. But allowing the full 360 degrees to show might resolve some of the clockwise/counterclockwise dilemma.

[Alfred]

ORIGINAL: Bullwinkle58

To me, the two colors chosen for the AM and PM arcs are not memorable, or meaningful. They're too close to each other in hue, and don't tie to any mnemonic. If you change the search arc displays to reflect what the code is doing, might I suggest two different colors? I don't know what colors reflect morning and night, or if that would be culturally consistent across all of the nations AE players come from, but just something strikingly diferent would help me.

+1. I particularly find it hard to distinguish when you have "surplus" afternoon searchers who double up on the morning searchers. Whilst we're at it, a better colour distinction between naval and ASW searching would be appreciated.[;)]

Alfred

[Saburo Kurusu]

Thanks very much for solving that issue, dear Michael! I'm playing my first campaign ever right now, and wondered if I might be silly or dumb because I couldn't get a handful of sightings, even on short distance from the Home Islands...... 
[:)]

[&o]

[Lifer]

Can someone help me out here...

1106g
Flight 1-27 is incorrect.
Flight 28-54 is incorrect.
Flight 55-72 is correct.
Flight 73-80 is incorrect.

1107
Flight 1-27 is correct.
Flight 28-54 is correct.
Flight 55-72 is incorrect.
Flight 73-80 is correct.

I'm not missing something here, am I. Everything I've understood about search arcs starts at the lower number and goes clockwise. 90-270 starts at 90 and goes clockwise. If you set the arcs onscreen, right click starts the beginning of the search. left click marks the end going clockwise.

Greg

[michaelm75au]

ORIGINAL: Lifer

Can someone help me out here...

1106g
Flight 1-27 is incorrect.
Flight 28-54 is incorrect.
Flight 55-72 is correct.
Flight 73-80 is incorrect.

1107
Flight 1-27 is correct.
Flight 28-54 is correct.
Flight 55-72 is incorrect.
Flight 73-80 is correct.

I'm not missing something here, am I. Everything I've understood about search arcs starts at the lower number and goes clockwise. 90-270 starts at 90 and goes clockwise. If you set the arcs onscreen, right click starts the beginning of the search. left click marks the end going clockwise.

Greg

Yep that is the discrepancy I have been referring to. Because it is up to the code to determine which direction the search goes in, it is sometimes correct [:)].
My current feeling is to let the player say which direction to go in and that will stop the code from putting search planes in the wrong sector of the arcs.
The direction would apply independently to both Naval and ASW.
Keep in mind that the search planes start from the first arc and go in the direction of the second arc. It may well be that you might want to reverse the order of the first/last arcs. With the direction control you can ensure that the search pattern will follow the intended path.

[michaelm75au]

ORIGINAL: Alfred

ORIGINAL: Bullwinkle58

To me, the two colors chosen for the AM and PM arcs are not memorable, or meaningful. They're too close to each other in hue, and don't tie to any mnemonic. If you change the search arc displays to reflect what the code is doing, might I suggest two different colors? I don't know what colors reflect morning and night, or if that would be culturally consistent across all of the nations AE players come from, but just something strikingly diferent would help me.

+1. I particularly find it hard to distinguish when you have "surplus" afternoon searchers who double up on the morning searchers. Whilst we're at it, a better colour distinction between naval and ASW searching would be appreciated.[;)]

Alfred

Over-lapping search sectors are a bit confusing. I had one case where the first 6 arcs where colored GREEN (PM), followed by 4 BLUE (AM) and followed by another 5 GREEN (PM) ones - I had all 27 planes on search.
The initial arcs were BLUE and then the PM kicked in and changed them to GREEN.
I am in two minds on whether to leave the color as it originally is or change the overlapping arcs to say BLACK.
Even changing it could just mean all the arcs are BLACK if there is enough planes to cover the arcs in one phase.

[michaelm75au]

ORIGINAL: michaelm

It looks like the arcs are being created in reverse - searches that go in clockwise direction are getting build in the anti-clockwise.
I thought that this was something that was fixed in an earlier patch, but it looks like it has reverted back to the older code.

This could be the crux why search arc don't seem to be working.

I think that because the code is deciding which direction to go in, the code I originally thought I changed, COULD have been changed because we found a bunch of cases where the search arcs I looked at where wrong - ie acting backwards. So I changed the code.

Now the opposite set of cases are kicking in. They probably were right under the very original code. Even the simple 4 searches that I tested with (and they were just randomly selected by just clicking on the map without too much real thought), 3 out of 4 were wrong in one version and right in the other, with the odd one being right and then wrong.

More reason to have this direction ability to lock in the true sector being searched.

[Bullwinkle58]

ORIGINAL: michaelm

Over-lapping search sectors are a bit confusing. I had one case where the first 6 arcs where colored GREEN (PM), followed by 4 BLUE (AM) and followed by another 5 GREEN (PM) ones - I had all 27 planes on search.
The initial arcs were BLUE and then the PM kicked in and changed them to GREEN.
I am in two minds on whether to leave the color as it originally is or change the overlapping arcs to say BLACK.
Even changing it could just mean all the arcs are BLACK if there is enough planes to cover the arcs in one phase.

Thanks for taking so much time to look into this.

On colors, the colors of the search arcs are important to me, but that's probably my brain structure, so I can live with whatever you decide. But I think color could be very useful to all players, even those who think primarily in numerical terms as many who post here seem to.

Visual feedback from the game to the player is paramount to playing the game. Providing a directional control seems to me to be "fiddly", but OK, if that works for the code you should go that way. BUT, I think that a color-based final feedback showing exactly what arcs will be flown based on final code understanding should be given to the player. This should be a 360-degree representation, so there's no quesiton of clockwise or counterclockiwise. Simply Color-1 for AM, Color-2 for PM (even if they overlap) and Color-3 for everything that will not be flown/searched. Eliminate any questions of the code "taking the long way around" and flying everything but the colored areas. I don't now how you code that, obviously, but I think a final visual display of exactly what area will be covered, and which area will not be, is needed to eliminate confusion. If the Color-3 (black?) area, due to clockwise-decisionmaking by the code, doesn't cover the area the player wants patrolled, he then knows to try again, maybe by changing the new directional control.

Bottom line though, is SHOW the player what the code "knows" and plans to do. Don't just give the player a new directional radio button and still display only the AM and PM colored arc areas.

[Pascal_slith]

ORIGINAL: michaelm

It looks like the arcs are being created in reverse - searches that go in clockwise direction are getting build in the anti-clockwise.
I thought that this was something that was fixed in an earlier patch, but it looks like it has reverted back to the older code.

This could be the crux why search arc don't seem to be working.

I was wondering why my Dauntlesses were detecting TFs outside of their defined arc area....

As the unit was covering a 180 deg. range it looks like what was displayed as the search arc (I check this each time I set the start and end limits) is not the same as what is actually being covered.

[Pascal_slith]

ORIGINAL: michaelm

However I think that there is a problem in that the allocation function is trying to apply the split using a clockwise motion.
Though sometimes it should be going in the other direction.
One of the 4 search patterns above is actually showing the reverse of what I expected. In 1106g it was correct, but is now wrong in 1107.

To simplify, I am going to add an item to the group arc screen that will allow you to say whether the patrol should be a clockwise or counter-clockwise spread. By default it will be clockwise.

Hey michaelm, in which report can I see the level of detail you showed in the 1106 and 1107 report? Or is this only from an internal coders report?

[Pascal_slith]

ORIGINAL: michaelm

ORIGINAL: Alfred

ORIGINAL: Bullwinkle58

To me, the two colors chosen for the AM and PM arcs are not memorable, or meaningful. They're too close to each other in hue, and don't tie to any mnemonic. If you change the search arc displays to reflect what the code is doing, might I suggest two different colors? I don't know what colors reflect morning and night, or if that would be culturally consistent across all of the nations AE players come from, but just something strikingly diferent would help me.

+1. I particularly find it hard to distinguish when you have "surplus" afternoon searchers who double up on the morning searchers. Whilst we're at it, a better colour distinction between naval and ASW searching would be appreciated.[;)]

Alfred

Over-lapping search sectors are a bit confusing. I had one case where the first 6 arcs where colored GREEN (PM), followed by 4 BLUE (AM) and followed by another 5 GREEN (PM) ones - I had all 27 planes on search.
The initial arcs were BLUE and then the PM kicked in and changed them to GREEN.
I am in two minds on whether to leave the color as it originally is or change the overlapping arcs to say BLACK.
Even changing it could just mean all the arcs are BLACK if there is enough planes to cover the arcs in one phase.

Would it be difficult to codify to use 3 colors? One for AM, one for PM and one for those with both AM and PM searches? Say Orange for AM, Blue for PM and Green for the combo?

[michaelm75au]

ORIGINAL: Pascal

ORIGINAL: michaelm

However I think that there is a problem in that the allocation function is trying to apply the split using a clockwise motion.
Though sometimes it should be going in the other direction.
One of the 4 search patterns above is actually showing the reverse of what I expected. In 1106g it was correct, but is now wrong in 1107.

To simplify, I am going to add an item to the group arc screen that will allow you to say whether the patrol should be a clockwise or counter-clockwise spread. By default it will be clockwise.

Hey michaelm, in which report can I see the level of detail you showed in the 1106 and 1107 report? Or is this only from an internal coders report?

It is a programing trace used internally.
It generates huge files each turn.

[herwin]

ORIGINAL: michaelm

ORIGINAL: michaelm

It looks like the arcs are being created in reverse - searches that go in clockwise direction are getting build in the anti-clockwise.
I thought that this was something that was fixed in an earlier patch, but it looks like it has reverted back to the older code.

This could be the crux why search arc don't seem to be working.

I think that because the code is deciding which direction to go in, the code I originally thought I changed, COULD have been changed because we found a bunch of cases where the search arcs I looked at where wrong - ie acting backwards. So I changed the code.

Now the opposite set of cases are kicking in. They probably were right under the very original code. Even the simple 4 searches that I tested with (and they were just randomly selected by just clicking on the map without too much real thought), 3 out of 4 were wrong in one version and right in the other, with the odd one being right and then wrong.

More reason to have this direction ability to lock in the true sector being searched.

I have a suspicion this won't work reliably. Explicitly set the left hand and right hand ends of the search arc. If the right hand end is less than the left hand end, add 360 degrees to the right hand end. Compute the available search sorties for am and pm. Loop from left to right (repeating as necessary) assigning sorties to search sectors. If the left hand end equals the right hand end, do this randomly, else sequentially clockwise from the left hand end. Then for each sortie, if a vector is greater than 360 degrees, subtract 360. Sacrifice a chicken; run your test cases; and God willing, the code will work.

[Mistmatz]

Do I understand that correctly that this might be fixed in a future (to be announced) patch and for now players should refrain from using the search arcs to get, maybe not best, but most stable results?

[tigercub]

i no longer use them and its works fine Mistmatz...

[Sardaukar]

ORIGINAL: Mistmatz

Do I understand that correctly that this might be fixed in a future (to be announced) patch and for now players should refrain from using the search arcs to get, maybe not best, but most stable results?

That is correct (as far as I know). Should be fixed in next patch.