There seems to be a problem with localnodes sometimes being overridden by
data from external PC92 data. Usually (but not always) data for local
PC19 nodes being overridden by data from other PC92 with the same node
connected.
Also put in a frig for the sysop announce problem.
This should stop pc93 conversions which are sent out a) being redisplayed
and b) as SYSOP. It may also stop all these strange chat messages to
unlikely chat group names.
Also rewritten chat import routines for new regime.
Also use a big enough past age limit to cope with inactive nodes
that only output a config record and nowt much else, so that they
don't time out.
Add an 'id too far in the future' compared with current systime
check.
Add a set/wantpc9x (default = on) command. It is likely
that (apart from mistakes) you will want to unset it mostly.
If either this flag == 0 or the node is isolated then pc9x
will not be offered on the PC18 and PC9x's will be ignored.
This involves making sure that all the external nodes get fixed
up even though their parent node does not yet exist (because no
config record has come in. It is safe to create these, in
anticipation of the C record coming in somewhen.
In the process of this, obscount reseting now happens much more
frequently (which I hope means correctly).
Allow Route::findroutes to find routes to these disconnected
nodes that are in the routing table but have no parent that is
yet anchored to a dxchan. Simply remember the dxchan that that
C record came in on. It doesn't matter if it gets overwritten by
another node, if it came in that way, there must be a route.
In any case, chances are, the first dxchan to get the C record
is the best and the deduping will (mostly) prevent it being
overwritten. When the linking C record comes in, it is all
irrelevant anyway...
This is an attempt to cut down on the number PC92Cs that are flying
around. It does this be storing the last PC92C and only sending
it (which should be ignored by other people if broadcast) and
a PC92A. It does mean that the PC92C could be quite out of date
but a fresher will be along soon(ish)
I have also increase the pc92 update time to one hour and
randomised it to one hour - upto 1/4 of the update time.
It will also do each node separately, rather than all together in
one big gob.
