• ANSI Art Packs

    From Avon@21:1/101 to All on Thu Mar 28 10:59:43 2024
    I have started to hatch a few more out to the FSX_ARTS file base.

    If your BBS is subbed via Filefix to this file area you should see a few new files land shortly :)

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From n2qfd@21:1/154 to Avon on Thu Mar 28 06:52:12 2024
    Just noticed them here at Queen City

    N2QFD

    --------------------------------
    ][ de N2QFD ][
    ][ Queen City BBS ][
    ][ queencitybbs.ddns.net:607 ][

    --- Mystic BBS v1.12 A48 (Raspberry Pi/32)
    * Origin: Queen City BBS (21:1/154)
  • From Shurato@21:2/148 to Avon on Thu Mar 28 15:19:00 2024

    I have started to hatch a few more out to the FSX_ARTS file base.

    If your BBS is subbed via Filefix to this file area you should see a few new files land shortly :)

    I got some that were long file names again and not automatically processed.
    I handled them manually, but it's hard to tell where they go when this
    happens.

    ---
    Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp)
    (ports 22, 23, 110, 21, 119) (ssh: login bbs password shsbbs)


    *** THE READER V4.50 [freeware]
    ---
    * Origin: Shurato's Heavenly Sphere telnet://shsbbs.net (21:2/148)
  • From NuSkooler@21:1/121 to Avon on Fri Mar 29 12:09:02 2024

    Avon around Friday, March 29th...
    I have started to hatch a few more out to the FSX_ARTS file base.

    yay!

    --
    |08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
    |08 ■ |03xibalba|08.|03vip |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
    |08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
    --- ENiGMA 1/2 v0.0.14-beta (linux; x64; 18.18.2)
    * Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)
  • From Roon@21:4/148 to Avon on Sun Mar 31 23:32:13 2024
    Hello Avon,

    28 Mar 24 10:59, you wrote to All:

    I have started to hatch a few more out to the FSX_ARTS file base.

    If your BBS is subbed via Filefix to this file area you should see a
    few new files land shortly :)

    great news, all arrived well! thanks!

    can the filenames be 8 characters long? ;)

    Regards,
    --
    dp

    telnet://bbs.roonsbbs.hu:1212 <<=-

    ... Uptime: 2d 8h 23m 36s
    --- GoldED/2 1.1.4.7+EMX
    * Origin: Roon's BBS - Budapest, HUNGARY (21:4/148)
  • From Shurato@21:2/148 to Roon on Sun Mar 31 20:01:00 2024

    Hello Avon,

    28 Mar 24 10:59, you wrote to All:

    I have started to hatch a few more out to the FSX_ARTS file base.

    If your BBS is subbed via Filefix to this file area you should see a few new files land shortly :)

    great news, all arrived well! thanks!

    can the filenames be 8 characters long? ;)

    Agreed, as my message said I had to handle them manually and guess which net they were from.

    ---
    Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp)
    (ports 22, 23, 110, 21, 119) (ssh: login bbs password shsbbs)


    *** THE READER V4.50 [freeware]
    ---
    * Origin: Shurato's Heavenly Sphere telnet://shsbbs.net (21:2/148)
  • From Avon@21:1/101 to All on Mon Apr 1 16:06:53 2024
    On 31 Mar 2024 at 08:01p, Shurato pondered and said...

    28 Mar 24 10:59, you wrote to All:
    great news, all arrived well! thanks!
    can the filenames be 8 characters long? ;)

    On 31 Mar 2024 at 08:01p, Shurato pondered and said...

    Agreed, as my message said I had to handle them manually and guess which net they were from.

    Sorry but no, don't have the time to manually rename things and if they are created by an author with a longer than 8.3 naming convention it's not really my place to be messing with the publishers naming convention.

    Totally understanding as to the hassles this creates for legacy 8.3 friendly software. Would point out other BBS software handles these longer names fine, but yeah.. this is going to be an ongoing mixed bag for folks I think.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From AKAcastor@21:1/162 to Avon on Sun Mar 31 21:11:46 2024
    Sorry but no, don't have the time to manually rename
    things and if they are created by an author with a
    longer than 8.3 naming convention it's not really my
    place to be messing with the publishers naming
    convention.

    Thank you for keeping files coming! (and the mail too!)

    I'm another 8.3 guy, though I agree it's not up to you to take the time to deal with this.

    Totally understanding as to the hassles this creates for
    legacy 8.3 friendly software. Would point out other BBS
    software handles these longer names fine, but yeah..
    this is going to be an ongoing mixed bag for folks I
    think.

    On my own system I will be able to solve this with some scripting. In my case, binkd receives the long filenames fine but then the DOS TIC processor can't handle the long filename - so I can script things on the Linux (binkd) side to zip the file into an 8.3 filename and edit the .tic before passing it to the DOS side. (thus far I've just renamed the .zip files manually but it's not optimal)

    Not sure how to best come up with an 8.3 filename. (even if the original filename does remain intact inside the .zip) So far I renamed files manually and inconsistently.


    Chris/akacastor

    --- Maximus 3.01
    * Origin: Another Millennium - Canada - another.tel (21:1/162)
  • From Roon@21:4/148 to AKAcastor on Mon Apr 1 09:46:02 2024
    Hello AKAcastor,

    31 Mar 24 21:11, you wrote to Avon:

    Totally understanding as to the hassles this creates for
    legacy 8.3 friendly software. Would point out other BBS
    software handles these longer names fine, but yeah..
    this is going to be an ongoing mixed bag for folks I
    think.

    On my own system I will be able to solve this with some scripting. In
    my case, binkd receives the long filenames fine but then the DOS TIC processor can't handle the long filename - so I can script things on
    the Linux (binkd) side to zip the file into an 8.3 filename and edit
    the .tic before passing it to the DOS side. (thus far I've just
    renamed the .zip files manually but it's not optimal)

    here NEF processes the tic files, but maximus can't handle long filenames :(

    Not sure how to best come up with an 8.3 filename. (even if the
    original filename does remain intact inside the .zip) So far I
    renamed files manually and inconsistently.

    the optimal would be that Avon scripts the filenames to the 8.3 sizes so we don't need to write 3 or more different scripts on different parts of the world, but i can understand that he don't have the time for this.

    Regards,
    --
    dp

    telnet://bbs.roonsbbs.hu:1212 <<=-

    ... Uptime: 2d 18h 55m 4s
    --- GoldED/2 1.1.4.7+EMX
    * Origin: Roon's BBS - Budapest, HUNGARY (21:4/148)
  • From Avon@21:1/101 to Roon on Mon Apr 1 21:55:03 2024
    On 01 Apr 2024 at 09:46a, Roon pondered and said...

    the optimal would be that Avon scripts the filenames to the 8.3 sizes so we don't need to write 3 or more different scripts on different parts of the world, but i can understand that he don't have the time for this.


    I concede this the better option, but as mentioned dont really want to mess with the original files.. if there was a suitable script available ideally it would allow me to tag nodes that wanted the 8.3 version and also include the original filename in whatever was created for completeness.

    The thought occurred to me of having a different file echo for just 8.3 files but that also seems a bit nutty. Tis a quandary but I think sending them out as per the way they wee created seems to be the best move for now.

    I'm always up for experimenting ;-)

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From apam@21:1/182 to Avon on Mon Apr 1 20:55:03 2024

    The thought occurred to me of having a different file echo for just 8.3 files
    but that also seems a bit nutty. Tis a quandary but I think sending them out as per the way they wee created seems to be the best move for now.

    Tic files do have an option for both short file names and long filenames (in the tic file), so while a file could be sent with an 8.3 filename, the tic file could have it's original name in the long filename field and the receiving tic processor could rename it to whichever is desired.

    As for how that would actually work in practice with various tic processors in use, i don't know. (heck I'm not even sure what I programmed postie to do in the situation).

    Of course, an issue might be coming up with the 8.3 filenames so they don't clash with other files that might have already been hatched, i guess you'd have to keep track of that.

    It sounds like a bit much hassle to me.. artpacks etc are nice to have and all, but perhaps if they're named in long filenames, people who use tic processors that only accept short filenames, can just filter them out and download the art packs themselves and add them to their bbses, it's not like these files being hatched are very hard to get by other means.

    Just some thoughts.

    Andrew

    --- Noddy git-4716e54
    * Origin: Smuggler's Cove - scove.talismanbbs.com:2323 (21:1/182)
  • From AKAcastor@21:1/162 to Apam on Mon Apr 1 11:36:18 2024
    Of course, an issue might be coming up with the 8.3
    filenames so they don't clash with other files that
    might have already been hatched, i guess you'd have to keep track of that.

    Since we're discussing ideas - does anyone have suggestions for how to automate creation of short filenames from long names? I'm sure there's no perfect solution, but maybe someone has something better than 'just take the first 8 letters of the filename'.

    I have some idea how to script the rest but "what name to give the files" has me a bit stumped.

    I'm partial to the idea of embedding the original, unmodified, zip with a long filename inside an 8.3 filename .zip, and copying the file_id.diz into the new zipfile. This keeps the original filename intact.

    Managing the 'replaces' line in the tic file will be another question. But I think in most cases, the files in question are added to collections rather than being updates to existing files, so I think 'replaces' is a less pressing issue.

    It sounds like a bit much hassle to me.. artpacks etc
    are nice to have and all, but perhaps if they're named
    in long filenames, people who use tic processors that
    only accept short filenames, can just filter them out
    and download the art packs themselves and add them to
    their bbses, it's not like these files being hatched are
    very hard to get by other means.

    I agree with this also, plus at least in my case I have to manually set a file description if I want something readable as most of the file_id.diz in artpacks are unreadable on my BBS.

    While I don't see this as a pressing issue, I am interested in finding possible ways to automate this - spending inordinate amounts of time on silly tech challenges is basically why I'm here. ;)


    Chris/akacastor

    --- Maximus 3.01
    * Origin: Another Millennium - Canada - another.tel (21:1/162)
  • From deon@21:2/116 to All on Tue Apr 2 08:12:56 2024
    Re: Re: ANSI Art Packs
    By: AKAcastor to Apam on Mon Apr 01 2024 11:36 am

    Howdy,

    Since we're discussing ideas - does anyone have suggestions for how to automate creation of short filenames from long names? I'm sure there's no perfect solution, but maybe someone has something better than 'just take the first 8 letters of the filename'.

    I've suggested this a couple of weeks ago now. I can implement a toggle in clrghouz, so that when long filenames come in, I can send them to downstream systems with an 8.3 name.

    What I can do is, generate a unique 8.3 name, where the 8 will be a filearea_id+file_id value in hex (to clrghouz), and the .3 will the extension chopped to 3 chars. eg: 0A0001F3.ZIP, and while the file area and description are left intact, outside of your BBS you'll have no idea what the file is.

    As apam suggested, the original name in the TIC file could be left intact as well.

    Determining the 8 from the original filename by chopping it would be (IMHO) dangerous since the probability that it clashes with another name would be high (the mystic updates comes to mind, where there 8 chars is the same for windows, linux, pi from memory).

    I also have a function that converts a date into 4 chars with 4 year precision, so I could take the first 4 chars, and make up the last 4 with that function - it might have some resemblence of a name, and be unique for at least 4 years. eg blndr2023d.zip might become blnd3F12.zip.

    I might play around with the later and see how it goes...


    ...δεσ∩
    --- SBBSecho 3.20-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From AKAcastor@21:1/162 to Deon on Mon Apr 1 14:23:42 2024
    What I can do is, generate a unique 8.3 name, where the
    8 will be a filearea_id+file_id value in hex (to
    clrghouz), and the .3 will the extension chopped to 3
    chars. eg: 0A0001F3.ZIP, and while the file area and
    description are left intact, outside of your BBS you'll
    have no idea what the file is.
    ...
    Determining the 8 from the original filename by chopping
    it would be (IMHO) dangerous since the probability that
    it clashes with another name would be high (the mystic
    updates comes to mind, where there 8 chars is the same
    for windows, linux, pi from memory).

    I also have a function that converts a date into 4 chars
    with 4 year precision, so I could take the first 4
    chars, and make up the last 4 with that function - it
    might have some resemblence of a name, and be unique for
    at least 4 years. eg blndr2023d.zip might become
    blnd3F12.zip.

    IMO the latter method you mention - keeping the first 4 chars of filename and a datestamp for the rest - is the most desirable so far. I don't prefer the entire filename being random (or rather based on an encoded area/fileid), ideally the filenames could remain somewhat recognizable IMO.


    Tempted to do 6 characters and ~1 and call it a day a la Microsoft. haha ;)


    Chris/akacastor

    --- Maximus 3.01
    * Origin: Another Millennium - Canada - another.tel (21:1/162)
  • From apam@21:1/182 to AKAcastor on Tue Apr 2 09:09:00 2024
    On Mon Apr 1 11:36:00 2024, AKAcastor wrote to Apam <=-

    While I don't see this as a pressing issue, I am interested in finding possible ways to automate this - spending inordinate amounts of time on silly tech challenges is basically why I'm here. ;)


    :) same. You could write a new tic processor? or is part of the challenge to work within the confines of period software??

    :)

    Andrew

    === TitanMail/netbsd v1.2.4

    --- Talisman v0.53-dev (FreeBSD/amd64)
    * Origin: Smuggler's Cove - scove.talismanbbs.com:2323 (21:1/182)
  • From Shurato@21:2/148 to Avon on Mon Apr 1 17:25:00 2024

    On 01 Apr 2024 at 09:46a, Roon pondered and said...

    the optimal would be that Avon scripts the filenames to the 8.3 sizes
    so
    we don't need to write 3 or more different scripts on different parts
    of
    the world, but i can understand that he don't have the time for this.


    I concede this the better option, but as mentioned dont really want to mess with the original files.. if there was a suitable script available ideally it would allow me to tag nodes that wanted the 8.3 version and also include the original filename in whatever was created for completeness.

    The thought occurred to me of having a different file echo for just 8.3 files but that also seems a bit nutty. Tis a quandary but I think
    sending them out as per the way they wee created seems to be the
    best move for now.

    I'm always up for experimenting ;-)

    As long as you post here that they're going out I can look for them and put them in the fsxnet ansi area.

    ---
    Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp)
    (ports 22, 23, 110, 21, 119) (ssh: login bbs password shsbbs)


    *** THE READER V4.50 [freeware]
    ---
    * Origin: Shurato's Heavenly Sphere telnet://shsbbs.net (21:2/148)
  • From Avon@21:1/101 to apam on Tue Apr 2 12:39:45 2024
    On 02 Apr 2024 at 09:09a, apam pondered and said...

    On Mon Apr 1 11:36:00 2024, AKAcastor wrote to Apam <=-

    While I don't see this as a pressing issue, I am interested in finding possible ways to automate this - spending inordinate amounts of time on silly tech challenges is basically why I'm here. ;)


    :) same. You could write a new tic processor? or is part of the
    challenge to work within the confines of period software??

    :)

    don't forget the trip to Disneyland to do research on this subject as well, or was it Paris? :)

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From apam@21:1/182 to Avon on Tue Apr 2 10:29:04 2024
    On 02 Apr 2024 at 09:09a, apam pondered and said...

    On Mon Apr 1 11:36:00 2024, AKAcastor wrote to Apam <=-

    While I don't see this as a pressing issue, I am interested in finding
    possible ways to automate this - spending inordinate amounts of time on
    silly tech challenges is basically why I'm here. ;)


    :) same. You could write a new tic processor? or is part of the challenge to work within the confines of period software??

    :)

    don't forget the trip to Disneyland to do research on this subject as well, or was it Paris? :)


    Isn't there a disneyland in paris??

    Andrew



    --- Noddy git-4716e54
    * Origin: Smuggler's Cove - scove.talismanbbs.com:2323 (21:1/182)
  • From AKAcastor@21:1/162 to Apam on Mon Apr 1 17:30:28 2024
    While I don't see this as a pressing issue, I am
    interested in finding possible ways to automate this -
    spending inordinate amounts of time on silly tech
    challenges is basically why I'm here. ;)

    :) same. You could write a new tic processor? or is part
    of the challenge to work within the confines of period
    software??

    Don't tempt me, I've considered writing a new one! haha I think a bit of tic pre-processing will do the trick and save re-implementing everything.

    I do find it interesting to work within the confines of period software, but I haven't been limiting myself to that - just making it up as I go, whatever seems fun.


    Chris/akacastor

    --- Maximus 3.01
    * Origin: Another Millennium - Canada - another.tel (21:1/162)
  • From Shurato@21:2/148 to AKAcastor on Mon Apr 1 18:57:00 2024

    While I don't see this as a pressing issue, I am
    interested in finding possible ways to automate this - spending inordinate amounts of time on silly tech challenges is basically
    why I'm here. ;)

    :) same. You could write a new tic processor? or is part of the challenge to work within the confines of period software??

    Don't tempt me, I've considered writing a new one! haha I think a bit of tic pre-processing will do the trick and save re-implementing everything.

    I do find it interesting to work within the confines of period software, but I haven't been limiting myself to that - just making it up as I go, whatever seems fun.

    If you could write something that I could use before allfix, that would be great!

    ---
    Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp)
    (ports 22, 23, 110, 21, 119) (ssh: login bbs password shsbbs)


    *** THE READER V4.50 [freeware]
    ---
    * Origin: Shurato's Heavenly Sphere telnet://shsbbs.net (21:2/148)