Why do that when a simple ring cipher would work?

1=3 2=1 3=9 etc...

sector 123 is sent as sector 319 on ss

I could easily use one of the many 2-way encryption algorithms available to me and already in use in other areas of the software to provide an encrypted message. But I'd prefer to have some cost associated with it, and as we know, scripters and tool authors can circumvent any cost and just communicate outside ss. So it seems kind of pointless.

It took me about 20 minutes to implement the ss scanner delay. And actually, I do have time to tinker with small features like this while I'm waiting for more testing of the combat sync. I don't want to tackle anything major until this release is out, and I'm not going to release until that's well tested.

The rule is, the first time you send a message, there is no delay. Then for every change after that, the delay increases in a sequence of 1, 2, 5, 10, 20, 45, 90, 180 and 300 seconds, with 300 seconds (5 minutes) between changes after the 10th. If the SubSpace goes unchanged for 20 minutes, it falls back to 0 and the sequence starts again. I hope this will make the feature virtually transparent to anyone using it as it was intended, but make it impossible to scan more than a few hundred channels per day. Scanning is still possible, but the risk of being found on subspace is more like it was originally intended to be. I'm satisfied with this solution. I don't like private subspace channels at all.

Grin, I'm even lazier than you, was thinking of ROTXX to encrypt, write the ss to file when <'> keyed, rotate it after ^M, then send it.