I've hatched a couple of more recent art packs to FSX_ARTS file base today.

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)