I am simply choosing between different ops & it's switching between high and moderate.

I'm talking about I'm selecting (in this order):

"esponiage" -> moderate
"spy alliances" -> high
"esponiage" -> high

I looked at the ajax & it's clearly an issue on the server side. ( Possibly caching issue? )

For developer:
REQUEST -> GET https://earthempires.com/...eck?cnum=39&spytype=8
RESPONSE -> Moderate

REQUEST -> GET https://earthempires.com/...eck?cnum=39&spytype=8
RESPONSE -> High

I don't think it's a bug. It's because spy ops are random.

If you go back to espionage it will show high or moderate. It's not based on the op type. If you are getting that it means you are right between high and moderate. cheers.

what I suspect it does is it runs the code for spy ops and sees how many succeed in like X ops with these stats(without adding up spy DR) between the countries. It will come out 16/20, 15/20 and 14/20 all because of randomness and that could be the difference between high and moderate.

The success rate shouldnt be determined on a single op. Hell that would mean someone with 1 spy vs 1 million spy could potentially show "HIGH" success if it were done that way.

What would make more sense is to create an array of tries and based on the percentage of successes it would show LOW, MODERATE, HIGH.

[] => no tries
[1,1,1,1,1,1,1,0,1,1,1] => High
[0,1,0,1,0,1,0,1,0,1,0] => Moderate
[0,0,0,0,0,0,1,0,0,1,0] => Low

These are simple examples but you'd have maybe 1000 sized attempts into an array and based on the average, ie 0.93 would indicate your next attempt would be high.

Doing a single op to determine probability of success is flawed.

I believe what the code does is in fact creating an array of tries without simulating the turns(just the one op over and over again). Thereby, except for extreme conditions that can only be created artificially on alphaffa more or less you can't actually run the same op with the same conditions over and over again to test it.

Two clues:
1. The code is slow, you can see it takes time to run it after the page is loaded. We could perhaps draw some conclusion from this but we might not agree.
2. It actually changes back and forth as you said. This means its not running like 1k or more simulations. It's 3-50 or something such, otherwise the results would have been fixed in such a vast majority of cases that it would be very rare to observe this phenomena. Its not rare, tho.

Given that spy ops often take time to perform I will suggest (and you might not agree) that the code doing intel ops is one of the slower ones in the game. Which could also be why we are only allowed to do 10 ops at a time. This could be why we are seeing a great variation in the results of this feature, because if the code was fast there would be no reason not to run 1000+ simulations on it as you suggest.

That is why I have come to the conclusion I have.

So you are closer to the truth with your 10 sized vectors than with 1000 attempts.

There's no way it creates an array.

This describes what it is doing and what it should be doing:

https://jsfiddle.net/g8jh5mop/

class Country {
  constructor(dr){
       this.dr = dr;
       this.spy_dr = dr/40;
  }
  
  randomFactor(){ 
  	const max = 1;
	const min = 0;
	return Math.random() * (max - min) + min;
  }
  
  getRate(){
  	return this.randomFactor() > this.spy_dr;
  }
}

const celphi = new Country(20);

// current implementation (i suspect)
console.log(`Success use single lookup: ${celphi.getRate()}`);

// what it should do...
const arr = Array.from({length: 1000}, () => celphi.getRate());

console.log(arr);
const total = arr.filter(x => x).length;
console.log(total/1000);

This by no way describes spal ect., but focuses on the concept where you can see a single return that states "FALSE" but then the % on array is like 0.75 (when you set it to DR 10).

The TRUE/FALSE describes whether an op is successful or not.

Nor does it make sense why it takes so long to switch. Something is clearly programmed poorly. Or the database is missing some indexes.

Implementation of that feature is pretty buggy from what I've seen.

I highly doubt Gerd knows more than Celphi about coding...

Will pass this along.

There is a small random factor added to the spy op success chance value before "low", "moderate", or "high" is displayed to the end user. You can see it alternate between moderate and high if you are near the boundary value. I'm not sure why it was designed this way.

Are you still experiencing the performance issue?

Yeah, I wouldn't expect that to have a random factor given it is a premium benefit.