Re: Air Strike PriorityTarget - Crews
 

...and Andy already addressed that issue yesterday.

Re: Air Strike PriorityTarget - Crews
 

I did say "seems".
While no doubt they're not as Andy stated the results I see make it "seem" they are.
As I mentioned in another thread perhaps the random number generator code used by this laptop is faulty and generates an abnormal amount of low results.
I totally agree with you I seem to experience an unusual amount of low odds results (recall the abysmal results of test of FC on aircraft a couple weeks ago).
All I can (and do) do is report the results I get.

Re: Air Strike PriorityTarget - Crews
 

The random number generator code is not dependent on your computer in quite the way you assume. Unless the Software engineer has goofed in a cosmically screwed up way. Which is unlikely since after "Hello World!" and "Hello John/Jane", "Hello Random" is like the 3rd (possibly 4th maybe 5th or 6th depending on flow control and variable assignment but right up there in top 10 things to do) thing described with examples in any programming language.

Please hit me with a dead fish as I put this subject to bed...

The Random Number Generator (henceforth RNG) takes as input the current Tick (1000th of a second) Count of the CPU Clock. Which is a Long Unsigned Integer counting number of Ticks since the System was Booted (some archaic systems used unsigned shorts and even more ancient systems used unsigned bytes).

The RNG takes this Tick Count does a bunch of math to it involving things like prime numbers and various digits of PI plus often a constant seed (the signature often being the a value similar to known values of the author aka his nickname) and spits out a pseudo-random number.

If the author of the software spitting out the Random Number is a total idiot he would declare the RNG Function as a Global Stored Constant. In other words this value is known to all other bits of Code and is Saved upon program exit. So that each consecutive call of RNG() yields the same sequence from A to Z no matter if the call is made from canIHitIt() or canISeeIt() with exiting and restarting the program making no difference. We know this isn't the case because restarting a save game will result in differences based on the RNG().

Since we assume that the Engineer is not foolish (properly that Don and Andy are not idiots :D no matter how much we vehemently disagree with them on some aspects of this game) it is understood that RNG() is a Local Unstored Function. Every single individual call to RNG() is a unique state (every request asks for the current tick count and does the magical math dance at the time of request), not dependent on saved status or the function calling for it.

So that... in earlier examples in this thread, it was described that varying the location of AirStrikes around a known identified point would probably create a whole different set of results.


:deadhorse: :hammer: :clap:

*scJazz ducks down in the HMG Foxhole Pit waiting for the totally ineffectual waterborne incoming*

Re: Air Strike PriorityTarget - Crews
 

Without going into techweenie detail that will make most forum readers skip this post cause they were lost after "The Random Number Generator (henceforth RNG) takes as input the current Tick (1000th of a second) Count of the CPU Clock."

Not all RNGs are created equal, and some do have flaws. Also depending on the exact code WinSPMBT uses to access a random number minor (but significant) bias can be introduced.
One reason the gambling industry took a looooooog time to adopt electronic slot machines.

Now I'll put this specific issue to rest as well.

Re: Air Strike PriorityTarget - Crews
 

OK but... yer computer is not it... and neither is the code in SPMBT... unless... well...

shifting the airstrikes from the 1 known datum to alternates nearby would generate different spotting and firing results in a 1 known datum plus nearby assumed situation.

It is like Andy telegraphed the algorithm... there is no way that anything VISIBLE could be ignored if it is in the same or very close hex of an airstrike. The big catch here is that the new visible unit is a crew that almost certainly didn't have the smoke cover available that the original firing arty did. There is no whoops we blew it up check. The check for crew while last in priority also fails since it is right in the same hex ( a failure in logic ). Only possible approach is the one Andy suggested... without FO with LOS spotting spread them out. Who knows... they might ignore that crew?

Re: Air Strike PriorityTarget - Crews
 

Foos call planes in SP - but have nothing to do with what the target selects, just the drift for the "impact" hex which it will then search around if the FOO is in LOS to that hex.

Planes then make their own individual target decision, on what they knew about before the pass, what they spotted in the pass before firing, and also they can "magically" reveal previously unspotted units (by the original game designers design).

The target decision is based on priority by class and also nearness to the "impact" hex, random factors etc.

Andy

Re: Air Strike PriorityTarget - Crews
 

Thank you Andy.
It helps a lot to know FOOs have no effect on target selection. And explains why aircraft will sometimes ignore what your FOOs can actually see and wants blown up for some other target in the general vicinity.