Does anyone know how to remove the vision that scanner sweep gives?

I'm looking for it to be removed when scan is used at certain locations, again it's the vision not just the sprite that i want removed.

Other than the player who is sweeping not having vision of himself, there is nothing else I know of.

you can remove the scanner sweep (I think), but vision is updated every 100 frames, so you're looking at 4 seconds of vision max.

You also can't detect scanner sweep with bring. It would be interesting to see what would happen if you mod a unit to become a scanner sweep while in game and what triggers worked with it then...

Since you can't know where the scanner sweep is, the point is moot.

Found a solution, the map i'm using this on has 2 computers one allied to each force of 3 humans. I just placed revealers for each computer in places where i wanted each force to have vision, turned vision on to the humans for their computer ally, turned vision off of self and allies for each player in human forces, turned vision on to the computer of their human allies. This way only the computer can see where their allies scanner sweep reveals which is all i needed as i was doing this to prevent players from spying on other bases.

I'm guessing if there were a solution with eud's or eup's that you would still be left with the 4 seconds of vision. Or would it be possible to update the frame rate of vision from 100 frames to something more frequent using an eup method?

No, it wouldn't be possible with EUPs (by any means I would know). Flipping the vision bits with EUDs/EUPs would have the same effect as setting them with the AI Script. You might be able to work something out with EUD Actions (as far as physically controlling the local player's vision), but I wouldn't know the means or success of doing so.

Highly unlikely, although I don't know of addresses that time vision, it's very doubtful they would be in a good spot to target with EUPs (between the death and unit tables), in addition we'd only be able to reliably increase the frames between updates, if super lucky and the constant the vision timer uses is target-able, a single byte, and has non-crashing units to boot, you could circle round to single digits for frame updates using a few hundred extended units.

---

I actually thought this a mildly interesting probability problem, forgive my rambling, so I spent a few minuets butchering stats:

The probability that you can edit a random desired address
= (isTargetable) * (isOnUsefulByte) * (hasNonCrashingUnits) * 100%
= (65156/3146700) * (1/4) * (1/10) * 100%
= .0518%

Honestly, though, I'm confused how your method is going to work now. You disabled vision for the player who is scanner sweeping, so that way they can not sweep areas of the map they are not supposed to, but, without vision of themselves, how is a scanner sweep in an area they are allowed to sweep at beneficial to them? Can they see anything from that?

Edit:

Those are some nice odds! I suppose probability speaking you only have to try out 200 combinations to reach a probability of 1.

Post has been edited 2 time(s), last time on Jan 1 2013, 12:00 pm by Leeroy_Jenkins.

No, they just need their allied computer to see cloaked units with the scanner sweep.

You could never reach 1, only become arbitrarily close to it. Unfortunately, probability is logical but not always so intuitive, as .0518% is a very small chance. Suppose we were to choose 200 randomly desired addresses and, using jjf28's probability (.0518% = .000518) that each given one is editable (assuming they are Bernoulli trials so we can talk about them using the Binomial Distribution), calculate the probability that at least one of the 200 is editable. The odds are still fairly low:
1 - .000518 = .999482 (probability that a randomly desired address is not editable)
.999482^200 = .901562 (rounded to 6 decimals, the probability that each of the 200 addresses is not editable)
1 - .901562 = .098439 (probability that at least one is editable)

This is still roughly 9.8%, which isn't much.

Let's suppose that we want to set our goal at a 50% of at least one of x randomly desired addresses being used.
.999482^x = .50
x = log(.50) / log(.999482)
x = 1337.78 (rounded to six decimal places so you can see the 1337 lulz)

We would need to try 1338 (rounded because we cannot have a fractional address and rounded up because 1337 would put the odds just under 50%) randomly desired addresses just to have a 50% chance of one being editable. Pretty grim odds.

Ah yeah I suppose I was just trying to understand probability intuitively... I've never actually learned about statistics that much. Even worse than I thought!

I don't even know where you got 200 from. 200*.05 = 10 (which is ironically pretty close to the actual 10% needed).

Simple (incorrect) logic says that you'd need 2000*.05 to get 100%. As Moose pointed out, it's actually 1338 for 50%, so my guess is it's 3000 to get 95%. Regardless, the (IsOnUsefulByte) is the first thing you should check. If it's stored as a word (2 bytes) or a byte and not a dword (4 bytes) there's a good chance that it's going to be impossible. if it's theoretically possible to write to the address, then the 2nd part comes in.

Well I think we were both wrong. Note that it is .05%, not 5%, so it does not equal the number .05, it equals .0005

Yeah rockz wasn't consistent with the % - sign, but if you add it where it belongs his numbers are correct. If you want to call him wrong for that, so be it.

Well, he wondered where I got 200 from, and said I should have gotten 2000 using my logic. I was pointing out that we both made the same mistake and that we both meant 200000

Post has been edited 1 time(s), last time on Jan 28 2013, 9:50 am by Leeroy_Jenkins.

No he didn't. As I said, he just left out the % which is lazy and technically wrong, but his numbers do check out:
200*.05% = 10%
2000*.05% to get 100%

And where do you take 200,000 from now?