home bbs files messages ]

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