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 have started to hatch a few more out to the FSX_ARTS file base.
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 :)
telnet://bbs.roonsbbs.hu:1212 <<=-
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? ;)
28 Mar 24 10:59, you wrote to All:
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.
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.
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.
telnet://bbs.roonsbbs.hu:1212 <<=-
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.
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.
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.
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'.
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.
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. ;)
On 01 Apr 2024 at 09:46a, Roon pondered and said...
the optimal would be that Avon scripts the filenames to the 8.3 sizesso
we don't need to write 3 or more different scripts on different partsof
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 ;-)
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??
:)
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? :)
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??
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.
| Sysop: | altere |
|---|---|
| Location: | Houston, TX |
| Users: | 66 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 11:20:52 |
| Calls: | 728 |
| Calls today: | 1 |
| Files: | 7,667 |
| Messages: | 295,546 |