Another option could be to do something like slightly desaturate the color of sprites which are visible only due to X-ray vision. That would require a small server change but as of 0.11.0 we now have room in the map view packet for more graphical flags.

I tested to undo the xray grey logic in client. Then using RoGT is lightning all up and let allow look behind walls, if you are close. Looks like lite preparation is done server sided?

Looking server sited, with xray on, server is unblocking nearby blocked positions in

los_update()
if (QUERY_FLAG(who, FLAG_XRAYS))
{
 for (j = 1; j <= 24; j++)
 {
  ax = pl->socket.mapx_2 + LosX[j],
  ay = pl->socket.mapy_2 + LosY[j];
  pl->los_array[ax][ay] &= ~LOS_FLAG_BLOCKED;
 }
}

and adjust visible to 100 in view_map.c draw_client_map2() for the titles <=0.

if (d <= 0) /* tile is not normal visible */
{
 /* (xray) or (infravision with entity on a tile)? */
 if (xrays ||
  (infra &&
  (msp->flags & (MSP_FLAG_PLAYER | MSP_FLAG_MONSTER))))
 {
  d = 100; /* make spot visible again */
 }
...

If i understand this correct, we send all visible items with the correct brightness to client, where all non visible items where tuned to 100?

So client sided there must be an additionally light adjustment to show all tiles same brightness?

Implementing another flag could be an idea, but wouldn't help on the brightness. Mainly we need to send 0 brightness tiles to client, instead of 100, but with the los "hack" above we get problems on the brightness behind walls. We need to adjust these hacked tiles also to 0 brightness.

If we can change server code this way, that we send all map tiles we want to show in xray mode and additionally send clean brightness infos (0 for dark normally not visible spots) client could do some magic, with desaturate in relation to brightness.

I dunno if this is worth the time to code that. I describe the final view, so we can think of, if its worth to code that. Xray would mean then:

At day light we have full colors.
When spots go darker and darker, we go more and more to grey effect instead of darker.
When spots are fully dark, by light or because behind walls, the xray effect shows pure grey tiles.
Running around with torches our other lightsources would remove the grey effect around us, in relation to the power of the light sources.

This is wild. We have mainly a pointer for 4 different unstretched sprites.
blt_sprite = sprite->bitmap;
blt_sprite = sprite->fog_of_war;
blt_sprite = sprite->red;
blt_sprite = sprite->grey;

where bitmap is the original bitmap and 3 other were calulated when we need this, by using a loop manipulating each pixel.

Behind this, we have the cached stretched bitmaps, stored in a cachetable. The calulcation for this is mainly done with sdl intern logic for streching and alpha changes. So a little faster.

Sdl has no intern desaturation logics, so we would need to calc each desaturation effect with the loop and pixel by pixel. This would slow down client, but with the cache could still be fast enough.

So when the normal darkness derives from this original bitmap, a desaturation would need to calc desaturation and stretch effect. Normally we need 7 more caching pointers for possible 7 different desaturation effects. We could add an extra array, like desaturate_filter[] equivalent to the darkness_filter[] array.

But to kill everything, we have a nice hashtable logic, I tried to understand several hours now. 

Finding the comment in head is a small help, but ...
/*
The cache is implemented using a hash chain technique.  The incoming pointer
and the stretch number is converted to a reasonably(?) unique key and hashed.
The cache entries also has a double linked list to maintain a LRU method where
a successful fetch will place the entry at the head. When the table gets full
the tail end is recycled.
Limitations: I don't expect more than 64K-1 cache entries so the entries
are 16 bit. The key is currently reduced to 8 bit since I don't expect the hash
table to be very big.  Just change the CalcHash routine if you want a larger key.
*/

static Uint16 CalcHash(const SDL_Surface * src,Uint32 stretch, Uint32 darkness)
{
Uint16 sum;

// dunno, why we calculate key with old high word, low word split logic?
// very strange, also darkness (0-7) is always 0 on high word, so unnecessary code
// stretch is 0 or = bottom+(left<<8)+(right<<16)+(top<<24);
// so 8 bits for each direction

// typecast around const SDL_Surface *src pointer is wild
// we build the sum from high/lo word
// this means address 0x00010001 is leading to same key than address 0x00000002

// looking on stretch, bottom 1 would lead to same key value than right 1

// a stretch bottom 1 darkness 0 would lead to same result as bottom 0 darkness 1

// then we could overflow because sum is uint16

// and in final step this uint16 is interpreted in high byte and low byte,
// where both where added, only to typecast the sum to uint8

// so with all this knowledge its still wild how the key is generated here
// building an index for the hashtable with below logic looks chaotic
 
// its very easy to produce same keys for different situations.

sum=
(Uint16)((Uint32)src >> 16) +
(Uint16)((Uint32)src) + // unnecessary typecast to Unit32
(Uint16)((Uint32)stretch >> 16) +
(Uint16)stretch +
(Uint16)((Uint32)darkness>> 16) + // always 0
(Uint16)darkness; // 0-7

sum=(Uint8)(sum>>8)+(Uint8)sum; /* Limits the hash head table to 256 entries */

return HASH_MOD(sum);
}
... I really tried it, but I refuse to build a new xray logic, above this hashtable logic. Perhaps I try a 50% desaturation effect, instead of the pure grey effect as a temporary solution.

I commented this here, so we have this for later. I spend several days now, looking in this logics, between other things. I stop this atm, and change my focus back to other things.