Motion Scanners

[Zombie]

So, seven blips, with no blip, that makes eight possible blip types on the scanner.

I shall concur that there are 7 blip types. But 8? That means that there is a bigger blip than the 7 tiles traversed. It looked very close to the HWP's blips but I could have been mistaken. I'll test out where a soldier moves 7 tiles and 8 tiles to see if the blip size changes any.

 

*Rushes off to test the new info*

[NKF]

Hang on, hang on, sorry, I meant that the very first blip is the no-blip blip. i.e. the one you get when you haven't moved enough to register on the scanner. So with the 7 different sized blip for picking up movement, you have 8 possible states on the scanner.

 

- NKF

[BladeFireLight]

Hang on, hang on, sorry, I meant that the very first blip is the no-blip blip. i.e. the one you get when you haven't moved enough to register on the scanner. So with the 7 different sized blip for picking up movement, you have 8 possible states on the scanner.

 

- NKF

no-blip? you mean transperent right?

 

-Blade FireLight

[Bomb Bloke]

He means that there are eight different ways a unit can appear on the scanner.

 

I got the impression that if a large unit moved a long way, the scanner drew multiple blips. I may have been mistaking but if that is true, then the blip sizes wouldn't be limited by what's in detblob.

[NKF]

Oh for a large unit, yes, it draws a blip for each quarter.

 

Would've been nice if the blips were dynamic and are drawn on the spot rather than stored as a bunch of fixed sized images. But I guess that was the fastest and easiest solution back then.

 

- NKF

[Bomb Bloke]

I was looking around my unitref notes this morning, when I solved another value (always a good thing! ).

 

You remember how I said value 62 was a counter of how many TU's had been spent moving a unit? And then we found that tanks made this counter go up by much bigger leaps?

 

Well, it seems offset 61 dictates how much offset 62 will go up by whenever the unit moves.

 

I've seen it show values of 4, 30, and once even 3 (for a rather dead Sectoid).

 

I dunno if there's any real use there, just thought I'd point that out. I suppose you could make all units cause large blips all the time if you so chose, or perhaps even create stealth units which didn't show up at all... Or something.

[Jman4117]

stealth Chrysalids.....evil....

[Bomb Bloke]

[Jman4117]

I SO did not see it there..... *Flees in mortal terror*

[Bomb Bloke]

I added most of the aliens quite a while back.

[Zombie]

Ha! I remembered where the discussion on motion scanners was.

 

Anyhow, thanks to NKF and Bomb Bloke, I have been looking at the unitref file very carefully in the past couple of days. My first focus was unitref[061] and unitref[062]. Unitref[061] is a constant. For 1x1 aliens/soldiers, the value is 4. For 2x2 terrorists/HWP's the value is 30. For every tile a unit moves, Unitref[062] is increased by this amount. Since Bomb Bloke asked about the values unitref[062] can have, I did some tests.

 

First, I started with a normal soldier (initial TU: 81) on the ground. I moved that soldier 1 tile (4 TU), saved the game, then checked the unitref[062] value. I continued to do this until the soldier ran out of time units:

 

# Tiles     TU     [062] Value
   0        81          0
   1        77          4
   2        73          8
   3        69         12
   4        65         16
   5        61         20
   6        57         24
   7        53         28
   8        49         32
   9        45         36
  10        41         40
  11        37         44
  12        33         48
  13        29         52
  14        25         56
  15        21         60
  16        17         64
  17        13         68
  18         9         72
  19         5         76
  20         1         80

Blips on a motion scanner continued to increase in size up to 7 tiles traversed. More movement after this did nothing to increase the size displayed.

 

If a solder traversed a tile diagonally (corner to corner) he used up 6 TU on normal terrain, but the unitref[062] value only went up by 4, not 6.

 

HWP's are a bit different. Because tanks get 30 per tile instead of 4, the unitref[062] value increases very fast. For this test, I used a normal tank (70 TU) and moved it to tiles which cost 4 TU each:

 

# Tiles     TU     [062] Value
   0        70         000
   1        66         030
   2        62         060
   3        58         090
   4        54         120
   5        50         150
   6        46         180
   7        42         210
   8        38         240
   9        34         014
  10        30         044
  11        26         074
  12        22         104
  13        18         134
  14        14         164
  15        10         194
  16         6         224
  17         2         254

In fact, if a tank moves 9 tiles, it flips the unitref[062] value back around 0. This does nothing to change the size of the blip produced on a Motion Scanner. If a tank moves one tile, the blip produced is the largest possible. Any additional movement does nothing to increase the size. Case in point: traversing 17 tiles with a HWP (a unitref[062] value of 254) has the same size blip as a 1 tile movement (a unitref[062] value of 030). Interesting.

 

If anyone thinks of something else I should test in conjunction with Motion Scanners, let me know.

 

- Zombie

[Bomb Bloke]

Sectoids have an incremental value of 3. I haven't checked all the different units yet, though.

 

I suppose the most exact way to test things out would be to hack a unit so that it has 255 TUs, and a Unitref[061] of 1. It'd be more tedious to test that way, but it would be the fastest way to find the exact behaviour of the scanner... I think.

[Zombie]

I just spent some time testing out the Motion Scanner today. First of all, I pulled the blip sizes out of ufograph\detblob.dat:

 

         Blip               Size

        XXX
        XXX                 3x3
        XXX

        XXX
       XXXXX
       XXXXX                5x5
       XXXXX
        XXX

        XXX
       XXXXX
      XXXXXXX
      XXXXXXX               7x7
      XXXXXXX
       XXXXX
        XXX

       XXXXX
      XXXXXXX
     XXXXXXXXX
     XXXXXXXXX
     XXXXXXXXX              9x9
     XXXXXXXXX
     XXXXXXXXX
      XXXXXXX
       XXXXX

       XXXXX
      XXXXXXX
     XXXXXXXXX
    XXXXXXXXXXX
    XXXXXXXXXXX
    XXXXXXXXXXX            11x11
    XXXXXXXXXXX
    XXXXXXXXXXX
     XXXXXXXXX
      XXXXXXX
       XXXXX

       XXXXX
      XXXXXXX
     XXXXXXXXX
    XXXXXXXXXXX
   XXXXXXXXXXXXX
   XXXXXXXXXXXXX
   XXXXXXXXXXXXX           13x13
   XXXXXXXXXXXXX
   XXXXXXXXXXXXX
    XXXXXXXXXXX
     XXXXXXXXX
      XXXXXXX
       XXXXX

       XXXXX
     XXXXXXXXX
    XXXXXXXXXXX
   XXXXXXXXXXXXX
   XXXXXXXXXXXXX
  XXXXXXXXXXXXXXX
  XXXXXXXXXXXXXXX
  XXXXXXXXXXXXXXX          15x15
  XXXXXXXXXXXXXXX
  XXXXXXXXXXXXXXX
   XXXXXXXXXXXXX
   XXXXXXXXXXXXX
    XXXXXXXXXXX
     XXXXXXXXX
       XXXXX

With that out of the way, I set about to do some more stringent experiments with the Motion Scanner. If I edited a soldier to have a unitref[062] value of 255, he produced the 15x15 blip. Pretty easy to see that.

 

Now I edited a soldier to have 255 TU and a unitref[061] value of 1. The "1" is the value added to unitref[062] for every tile a unit moves. No blip was produced with tile movements of 1-4. But when the soldier moved 5 tiles, he suddenly produced the smallest blip on the scanner (3x3). After moving 10 tiles, the soldier produced the next larger blip (5x5). Ah ha! The scanner must produce a blip only when a unitref[062] value of 5 or more is reached due to movement.

 

Building on this data, I edited the soldiers unitref[061] to have a value of 5. Theoretically, one tile traversed should now be enough to produce the smallest blip. Spot on! Exactly as predicted. But wait, it gets better. The largest blip size (15x15) should require a unitref[062] value of 35 or more. What this means is that a tank (unitref[061] of 30) cannot produce the largest blip with only one movement. To verify this, I edited one soldier to have a unitref[061] of 30, and a second soldier to have a unitref[061] of 35, then moved them both one tile straight ahead. It was tough, but there was a small difference in the blip sizes.

 

Because soldiers have a unitref[061] of 4, they will not register on the motion scanner after one movement. But after 2 movements (unitref[062] of 8) the scanner will pick him up since 8>=5. So now we can finally produce an accurate table describing soldier movement on the motion scanner:

 

           X-COM Soldier
Tiles     unitref[062]     Size
 0             0            0
 1             4            0
 2             8           3x3
 3            12           5x5
 4            16           7x7
 5            20           9x9
 6            24           9x9
 7            28          11x11
 8            32          13x13
 9            36          15x15
10            40          15x15
11            44          15x15

Therefore a normal soldier needs to traverse 9 tiles to produce the biggest blip on the motion scanner. A Sectoid on the other hand, has a unitref[061] value of 3. Its movement table would look like this:

 

             Sectoid
Tiles     unitref[062]     Size
 0             0            0
 1             3            0
 2             6           3x3
 3             9           3x3
 4            12           5x5
 5            15           7x7
 6            18           7x7
 7            21           9x9
 8            24           9x9
 9            27          11x11
10            30          13x13
11            33          13x13
12            36          15x15
13            39          15x15

Hmm... a Sectoid needs to move 12 tiles to produce the maximum blip size. Since a normal tile costs 4 TU to cross, and a beginner level Sectoid has 54 TU, that means it will use up 48/54 = 89% of its TU to produce the 15x15 pattern.

 

I had a chance to test out a few other aliens and their unitref[061] values. Floaters, Mutons, Silacoids, Celatids, and civilians all have a value of 4. Sectoids have a value of 3. Cyberdiscs and Reapers have a value of 4 too. That's strange. Though, when I moved them, they appeared to max out the blip size after only 1 or 2 tiles traversed. Something still must not be understood with the 2x2 units because if we assume a total of 16 units per tile, that still falls well short of a tank with 30. Oh well. At least we now have a better understanding of the mechanics involved.

 

- Zombie

[Danial]

So every 5, the blip goes up by 1 size? Is that right?

 

Awesome work as usual by the way!!

[Zombie]

Correct. So an imaginary unit with a unitref[061] value of 5 would have a movement table which looks like this:

 

         Imaginary unit 
Tiles     unitref[062]     Size
  0             0            0
  1             5           3x3
  2            10           5x5
  3            15           7x7
  4            20           9x9
  5            25          11x11
  6            30          13x13
  7            35          15x15
  8            40          15x15

This is the data which I used to base all the other assumptions off of. It works perfectly for 1x1 units. I think I should look at the unitref[062] of the Cyberdisc or Reaper to see how much that goes up by for one tile traversed. That should uncover some more info. *Zombie crosses his fingers*

 

- Zombie

[Zombie]

I think I should look at the unitref[062] of the Cyberdisc or Reaper to see how much that goes up by for one tile traversed. That should uncover some more info. *Zombie crosses his fingers*

Remember when I said that if a 2x2 terror unit moved one tile it produced the largest blip possible on the Motion Scanner? This shouldn't be possible since the unitref[061] value is 4. Well, I just did a thorough test of the Cyberdisc. The first movement did not increment the unitref[062] counter to 4 like it should. Instead, the value is 128! That's why 2x2 aliens produce such large initial blips - the first movement somehow adds 128 to the counter!

 

But where does the unitref[061] value of 4 come into play? You guessed it; subsequent movements beyond the first one add only 4 now!

 

I still don't understand how the value of 128 is found though. If we assume that each quarter of a 2x2 unit adds 4 to the counter, then unitref[062] should come out to 16. Lets see... 128 = 2^7 and 16 = 2^4. 7-4 = 3 so therefore we are off by a factor of 2^3 = 8 somewhere. *Zombie gets a really sour look on his face* Guys, we are so close to fully understanding the Motion Scanner that I can smell the answer. What am I missing? Perhaps another unitref value is behind the confusion.

 

[Edit, Zombie: I split this off the AI thread.]

 

- Zombie

[Gungadin]

Interesting isn't it? X-Com can manufacture plasma blasters and laser cannons from Alien technology, can brainwash aliens with psi-technology and can fly to Mars in a spaceship but they can't make a motion detecter or thermal imaging device worth a damn. Somebody in X-COm R&D is obviously slacking off.

[Bomb Bloke]

I'm thinking your data got corrupted there - I just ran a quick test of my own, and Cyberdiscs boosted the meter by 4 points per movement, regardless as to whether it was the first one or not.

 

On the other hand, the way you speak makes it sound like you mind controlled the 'Discs, and moved them manually. I just let them float around on their own.

[Zombie]

Well, that explains it then. I was indeed mind controlling the Cyberdisc. I guess that makes a difference, but why so large? A jump from 4 to 128 is pretty big.

 

[Edit: Controllong 1 section of a Cyberdisc resulted in a unitref[062] value of 152. 2 segments = 176. 3 segments = 192. 4 segments = 196. It's not jumping up by a constant amount per segment. It might have to do with which parts I controlled.]

 

- Zombie

[NKF]

What results are you getting with your own tanks?

 

- NKF

[Zombie]

Tanks are not a problem for a couple of reasons. First, they are always under permanent X-COM control. Second, they have a very high unitref[061] value of 30. It is because of these reasons why the unitref[062] counter goes up by the predicted 30/tile.

 

- Zombie

[Danial]

On the scanner, the blip oscillates. Do you know if it goes up in size, or down when oscillating?

 

Also, I can't seem to get the 3x3 blip no matter what I do. The smallest I could get (after 2 tiles) was a 5x5 (oscillating to 7x7). I saved the game and checked the file, and my guy had a unitref[62] of 8, which, according to your table, should have made a 3x3 blip. I'm confused

[Zombie]

On the scanner, the blip oscillates. Do you know if it goes up in size, or down when oscillating?

It oscillates up. The standard size is the smaller of the two.

 

Also, I can't seem to get the 3x3 blip no matter what I do. The smallest I could get (after 2 tiles) was a 5x5 (oscillating to 7x7). I saved the game and checked the file, and my guy had a unitref[62] of 8, which, according to your table, should have made a 3x3 blip. I'm confused

Yes, but you have to understand that the game has a 3x3 square blip in detblob.dat. The smallest blip on the scanner is a circle. Obviously, the game has to add some information to convert squares to perfect circles. That's the reason behind why it appears bigger. What you see on the scanner is a depiction of the image shown in detblob.

 

- Zombie

[Danial]

I just added the detblob graphics onto the wiki, and I can honestly say I never get the smallest blip, I've had from 5x5 up to 15x15, but I never get the 3x3 "square"... Can you show me a screenshot of one of your's, Zombie?

[Zombie]

I never saw the tiny square blip either, Danial. That graphic might just be used for the "null" movement type. So for instance, if your soldier moves one tile it will get the square designation, but the scanner will produce nothing. Other than that, maybe it is unused? Who knows. At this point any theories could be correct.

 

- Zombie