Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    SYNC_SYSOPS    |    Synchronet Multinode BBS Software Suppor    |    33,243 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 32,967 of 33,243    |
|    Deucе to GitLab note in main/sbbs    |
|    The Clans InterBBS turnarounds are too q    |
|    01 Jan 26 09:43:50    |
      TZUTC: -0800       MSGID: 59108.sync_sys@1:103/705 2dbccf3a       PID: Synchronet 3.21a-Linux master/48922a15c Dec 17 2025 GCC 12.2.0       TID: SBBSecho 3.34-Linux master/8bb133aa7 Dec 30 2025 GCC 12.2.0       BBSID: VERT       CHRS: UTF-8 4       FORMAT: flowed       https://gitlab.synchro.net/main/sbbs/-/issues/1040#note_8051              One interesting question is how to do the delays... my initial thought was to       have a set amount of time that each message will take, so if you set it to one       hour, it wouldn't be processed by the other end until an hour has elapsed, so       an attack packet followed by an attack result packet would take two hours.              Where this gets interesting is in the packet processing... with it running       whenever someone logs into a door and when new packets are received, this       means that attacking/spying on a system that doesn't have active players would       take *much* longer since the packet would be initially ignored, then only       processed during nightly maintenance... so it would take up to 25 hours when       set to a one hour delay.              The more boring option is to have the entire delay applied to the result       packet, which would effectively make the turnaround a fixed period.              A third option would be to have a "distance" component... where travel time       to/from a village is based on some variable, the BBS ID perhaps (so villages       are a fixed travel time from each other), or how much a village has been       upgraded (representing better roads/infrastructure).              With the BBS ID style, it's likely desirable to have the villages "wrap       around" so the highest BBS ID is one distance away from the lowest BBS ID...       that means when a village is added, the distance between existing villages       will change, but at least it prevents the first few BBSs from having an       inherent advantage by being further away.              A final option would be an actual "real" map, and have travel time based on       that... possibly with some kind of ability to build roads and such (that would       increase production, but make it easier to attack a village). This is likely       "too hard" for what I want to do right now though.       --- SBBSecho 3.34-Linux        * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)       SEEN-BY: 1/19 100 16/0 19/37 103/13 705 105/81 106/201 123/130 124/5016       SEEN-BY: 128/187 129/14 142/104 153/757 7715 154/10 30 110 203/0 218/700       SEEN-BY: 221/0 1 6 226/30 227/114 229/110 112 134 206 275 317 400       SEEN-BY: 229/426 428 470 700 705 240/1120 5832 263/1 266/512 280/464       SEEN-BY: 280/5003 5006 291/111 292/8125 301/1 320/119 219 319 2119       SEEN-BY: 322/757 762 326/101 341/66 234 342/200 396/45 423/81 120       SEEN-BY: 460/58 633/280 712/848 770/1 902/26 5020/400 5075/35       PATH: 103/705 280/464 221/1 320/219 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca