|UIFLOOD is very similar to UITRACE, but with a major difference.
UIFLOOD and UITRACE both use an SSID which is decremented, and keep a CRC packet payload log to keep from acting upon the same packet twice.
The difference between UIFLOOD and UITRACE is that UIFLOOD inserts it's callsign before the path being acted upon like UITRACE, but if there's a callsign already inserted, UIFLOOD overwrites that callsign. UITRACE will insert its callsign each time it acts upon a packet.
UIFLOOD can also be configured to not insert its callsign as well. In the Kantronics line (where it was developed and implemented first), the command syntax is as such:
In the new-N Paradigm, UIFLOOD is used to set up the capability for statewide digipeating. It will support up to 7 hops, but because the digipeater aliases used in each state are different, the packets do not propagate across into neighboring areas. This is to facilitate getting packets of local importance distributed in the local area, without flooding out into adjacent areas. The standard implementation is as such:
UIFLOOD SS,30,ID where SS is the two letter state abbreviation.
For Florida, UIFLOOD FL,30,ID would be used to configure for SSn-N flood digipeating.
would be handled thusly by a digipeater:
With NOID enable, the digipeater callsigns would not be inserted, and only the SSn-N would be decremented until complete thusly:
This is different from the APRSISCE/32 implementation of UITRACE, which would mark up the packets in this manner:
The DIGIFORM rules will insert the callsign each time it is called. The ! is used to suppress callsign insertion and/or the @ is used to drop the entire used portion of the path.
APRSISCE/32 supports a fourth variant of ID and/or Path replacement which is to not insert the callsign, but still preserve the previously used path. This would be done with just a ! (no ID) in the <DigiXForm>, although I really can't imagine this being used in the field.