• Hatching Questions

    From Avon@21:1/101 to g00r00 on Sat Feb 8 21:37:43 2020
    Hi g00r00

    [snip]

    [AutoHatch]

    ; Files will be automatically hatched to connceted downlinks
    ; Each file must already exist in the file base. The format
    ; file=<base ID or echotag> | filename | replaces filename (optional)

    ;file=nodelist | nodelist.z99 |nodelist.z99
    ;file=3 | nodelist.z98

    [snip]

    When I generate a nodelist it is created as a compressed file with a syntax FSXNET.Z?? where ?? will be a two digit number. Inside is the nodelist text file called FSXNET.??? where ??? is a three digit number representing the day-of-year of the Friday publication date.

    I'm trying to think of a way of automating importing and file hatching using Mystic when dealing with a changing filename like this? At present the way I
    am doing this relies on a 3rd party tool to create a TIC and I toss the file
    in to the HUB and in doing so also toss it on to other nodes.

    The current hatching function in MUTIL is determinant on having the file imported into the Mystic filebase before it can be hatched out using the
    stanza syntax above. The sysop also needs to state the exact file name for hatching which when dealing with a changing filename extension such as a nodelist makes things a bit tricky.

    So I was wondering..

    1) Could the function syntax allow for file extension wildcards such as .* ?

    e.g. file=fsx_node | fsxnet.* | fsxnet.*

    2) Could provision be made to allow for the importing of a file in to Mystic and its hatching when this MUTIL function is called?

    e.g file=fsx_door | c:\path\to\nodelist\fsxnet.* | fsxnet.*

    3) If 2 is a pain to do could some way be found to get Mystic to generate a
    TIC for a specified file and file base?

    This feature would ideally allowing for wildcards in the filename and or filename extension. The feature would place a copy of the file and it's TIC into the echomail\in of the BBS and then Mystic could then import the file
    and toss it to nodes connected to the file area using the [FileToss] function.

    Something like:

    mis -tictoss [filename to import] [filename to replace (optional) [filebase id or echotag to import file to]

    e.g.

    mis -tictoss c:\nodelist\fsxnet.* fsxnet.* fsx_node

    would import fsxnet.z54 into fsx_node and create a TIC containing the
    REPLACES keyword of fsxnet.*

    mis -tictoss c:\doorgames\gdy*.* gdy*.* fsx_door

    would import both gdynwin.zip and gdynsrc.zip into fsx_door and create TICs with the REPLACES keyword in each of gdynwin.* and gdynsrc.* respectively.

    All just ideas... but I'm searching for ways to drop some 3rd party tools I
    use at present to be able to hatch out dynamically changing files like nodelists... and also just being cheeky thinking about ways of making command line hatching of files with similar names possible vs having to state each
    file explicitly.

    Thanks for pondering this :)

    Best, Paul

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Sat Feb 8 12:38:18 2020
    I'm trying to think of a way of automating importing and file hatching using Mystic when dealing with a changing filename like this? At present

    1) Could the function syntax allow for file extension wildcards such as
    .* ?

    I think this could be added.

    My thoughts are that I don't want someone to put a AutoHatch * in there and hatch 2390490283 files, so that might have been why I didn't allow it to begin with.

    But since you have a good reason for it, I think its time to reconsider :)

    2) Could provision be made to allow for the importing of a file in to Mystic and its hatching when this MUTIL function is called?

    Mass Upload should cover this part, right? If you run them both in the same MUTIL process, MUTIL will always try to mass upload files before it hatches.

    --- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Avon@21:1/101 to g00r00 on Sun Feb 9 10:33:30 2020
    On 08 Feb 2020 at 12:38p, g00r00 pondered and said...

    My thoughts are that I don't want someone to put a AutoHatch * in there and hatch 2390490283 files, so that might have been why I didn't allow
    it to begin with.

    I agree and figured this was the rationale.

    But since you have a good reason for it, I think its time to reconsider
    :)

    Thank you.

    2) Could provision be made to allow for the importing of a file in to Mystic and its hatching when this MUTIL function is called?

    Mass Upload should cover this part, right? If you run them both in the same MUTIL process, MUTIL will always try to mass upload files before it hatches.

    Yes I guess so. How would a file like a compressed nodelist be handled
    though? The situation being that you only want the one copy of the file in
    the file base and it replaces the last copy and filename in the base. With a TIC import the REPLACES verb can take care of that as part of the
    import/hatch process... but with Mass Upload I'm picking it may not?

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Sat Feb 8 22:35:25 2020
    Yes I guess so. How would a file like a compressed nodelist be handled though? The situation being that you only want the one copy of the file
    in the file base and it replaces the last copy and filename in the base. With a TIC import the REPLACES verb can take care of that as part of the import/hatch process... but with Mass Upload I'm picking it may not?

    In that case you're right it wouldn't replace it. I think the hatch would still work because any previous file would have already been hatched and flagged as hatched so only the new file would actually hatch.

    The issue then would only be that it'd still have the old nodelists in your file database.

    I'm still conflicted on how to best implement this, considering the auto hatch function does require a file base, and there is nothing that provides the actual file location outside of the file base itself. So changing this is going to rewrite a full rewrite of the functions and break existing setups.

    --- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Avon@21:1/101 to g00r00 on Sun Feb 9 19:30:14 2020
    On 08 Feb 2020 at 10:35p, g00r00 pondered and said...

    In that case you're right it wouldn't replace it. I think the hatch
    would still work because any previous file would have already been
    hatched and flagged as hatched so only the new file would actually hatch.

    I have not honestly tried using mass upload to do a hatching, but I'm also wondering how a new file would be hatched with the replaces verb set?

    I'd best try a test or two. Golly got a few tests to do at the moment. Got a time machine I can borrow :)

    The issue then would only be that it'd still have the old nodelists in your file database.

    If the newly uploaded file to the HUB didn't get sent with a replaces verb
    then the same would start to hold true for nodes..

    I'm still conflicted on how to best implement this, considering the auto hatch function does require a file base, and there is nothing that provides the actual file location outside of the file base itself. So changing this is going to rewrite a full rewrite of the functions and break existing setups.

    You're not the only one. I don't want to make anything unnecessarily complicated as the whole thing should be minimalist in implementation and execution I feel. Hmm.

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Sun Feb 9 20:30:23 2020
    Yes I guess so. How would a file like a compressed nodelist be handle though? The situation being that you only want the one copy of the fi in the file base and it replaces the last copy and filename in the ba With a TIC import the REPLACES verb can take care of that as part of import/hatch process... but with Mass Upload I'm picking it may not?

    In that case you're right it wouldn't replace it. I think the hatch
    would still work because any previous file would have already been
    hatched and flagged as hatched so only the new file would actually hatch.

    My first test was to place a new file in a HUB file directory (I choose FSX_DOOR) that was brand new and not in Mystic. This file echo is set to
    export to 65 nodes

    Base Name │ BBS Doors, Games etc.
    FTP Name │ fsx-door
    Echo Tag │ FSX_DOOR
    Net Address │ 21:1/100 (fsxnet)
    Export To │ 65 node(s)

    The Mass Upload ran and pulled the file in.

    - Feb 09 19:53:08 EXEC MassUpload
    + Feb 09 19:53:08 Process: Mass Upload Files

    [snip]

    + Feb 09 19:53:08 BBS Doors, Games etc.
    + Feb 09 19:53:08 Allocating 288
    + Feb 09 19:53:08 Add: DRK200.ZIP To: BBS Doors, Games etc.
    + Feb 09 19:53:08 Free 288
    + Feb 09 19:53:08 ANSI Art - Groups, Individuals etc.
    + Feb 09 19:53:08 Allocating 1,280
    + Feb 09 19:53:08 Free 1,280

    [snip]

    + Feb 09 19:53:08 Results: Uploaded 1 file(s) in 0.08s
    + Feb 09 19:53:08 Shutdown Normal (0)

    The I ran the mailin.ini that calls the FileToss function. Nothing was exported.

    - Feb 09 19:53:41 EXEC ImportEchoMail
    - Feb 09 19:53:41 EXEC FileToss
    + Feb 09 19:53:41 Process: Toss FDN/TIC Files
    + Feb 09 19:53:41 Waiting for BUSY nodes
    + Feb 09 19:53:41 Scanning Hatches
    + Feb 09 19:53:41 Results: 0 import, 0 toss, 0 hatch, 0 bad in 0.06s
    + Feb 09 19:53:41 Process: Importing EchoMail
    + Feb 09 19:53:41 Waiting for BUSY nodes
    - Feb 09 19:53:42 LINKS:
    - Feb 09 19:53:42 Node 14 21:1/112@fsxnet

    [snip]

    - Feb 09 19:53:42 Node 123 21:1/205@fsxnet
    ! Feb 09 19:53:42 Import from c:\mystfsx\echomail\in\
    ! Feb 09 19:53:42 Import from c:\mystfsx\echomail\in\unsec\
    + Feb 09 19:53:42 Results: 0 echo, 0 net, 0 dupes, 0 tossed in 0.16s
    + Feb 09 19:53:42 Shutdown Normal (0)

    ..and this kinda makes sense to me as there is no TIC to process so nothing
    is being hatched that way. And the only way I can see at present to trigger
    the hatching of DRK200.ZIP is to login to the HUB, go to the file base, press
    E to edit the file, press H to hatch it, chose if it's to replace a file or not, then confirm the hatching. Then re-run mailin.ini..

    So it's nothing really friendly to enable what I'm looking for nodelists
    with changing extensions or static file names like an info pack to be
    uploaded / hatched out from an automation point of view.

    So if this file was the infopack FSXNET.ZIP and it had been imported into the base. If I drop another file of the same name in the same directory over the top of the current file I'm picking Mystic should see the file as new (size will have changed) and the Mass Upload will act on it?? Let's find out. But I am going to stick with the DRK200.ZIP file in this test but will add a
    note.txt to the zip to alter it's file size first.

    [time passes]

    Nope... changed the file by adding a 1kb text file then zipped it up with the same file name as the original, dropped it into the FSX_DOOR directory in the HUB, then ran Mass Upload and nothing new was found to pull in.

    + Feb 09 20:09:03 BBS Doors, Games etc.
    + Feb 09 20:09:03 Allocating 296
    + Feb 09 20:09:03 Free 296
    + Feb 09 20:09:03 ANSI Art - Groups, Individuals etc.
    + Feb 09 20:09:03 Allocating 1,280

    [snip]

    + Feb 09 20:09:03 Results: Uploaded 0 file(s) in 0.02s

    So next I figured let's ask Mystic to run a file base pack process. A couple
    of things happened here. One expected the other not.

    It did pick up the expected change in file size DRK200.ZIP compared to the
    one I first pulled in using Mass Upload. But it also seemed to want to delete the two single files I have (one in each base) for the nodelist and infopack.

    - Feb 09 20:18:35 EXEC PackFileBases
    - Feb 09 20:18:35 SKIP FileSort
    - Feb 09 20:18:35 SKIP PurgeUserBase
    - Feb 09 20:18:35 SKIP PackUserBase
    - Feb 09 20:18:35 SKIP Export_FILEBONE.NA
    - Feb 09 20:18:35 SKIP AutoHatch
    + Feb 09 20:18:35 Process: Pack File Bases
    + Feb 09 20:18:35 fsxNet Uploads
    + Feb 09 20:18:35 fsxNet Nodelist
    + Feb 09 20:18:35 Removing entry FSXNET.Z45
    + Feb 09 20:18:35 fsxNet Infopack
    + Feb 09 20:18:35 Removing entry fsxinfo.zip
    + Feb 09 20:18:35 Mystic BBS Software
    + Feb 09 20:18:35 Mystic BBS Utils, Mods etc.
    + Feb 09 20:18:35 BBS Utils, Tools, Networking etc.
    + Feb 09 20:18:35 BBS Software (Current + Legacy)
    + Feb 09 20:18:35 BBS Doors, Games etc.
    + Feb 09 20:18:35 Adjust size 497,572 DRK200.ZIP
    + Feb 09 20:18:35 ANSI Art - Groups, Individuals etc.
    + Feb 09 20:18:35 Text Files (Various)
    + Feb 09 20:18:35 Image Files (Various)
    + Feb 09 20:18:35 Results: Removed 2 records, 1604 bytes in 0.30s

    Don't know why the deletions. In any regard they didn't delete as the .ini I ran was set to

    [PackFileBases]

    check_files = true
    remove_missing = false

    Now I need to know if I run this again if it will try to do the same thing?

    Humm.. well no attempted deletions but another attempt to update the file
    size of the test file.. and yet I had not changed / touched it since last
    time I ran the file packing function.

    + Feb 09 20:27:06 Process: Pack File Bases
    + Feb 09 20:27:06 fsxNet Uploads
    + Feb 09 20:27:06 fsxNet Nodelist
    + Feb 09 20:27:06 fsxNet Infopack
    + Feb 09 20:27:06 Mystic BBS Software
    + Feb 09 20:27:06 Mystic BBS Utils, Mods etc.
    + Feb 09 20:27:06 BBS Utils, Tools, Networking etc.
    + Feb 09 20:27:06 BBS Software (Current + Legacy)
    + Feb 09 20:27:06 BBS Doors, Games etc.
    + Feb 09 20:27:06 Adjust size 497,572 DRK200.ZIP
    + Feb 09 20:27:06 ANSI Art - Groups, Individuals etc.
    + Feb 09 20:27:06 Text Files (Various)
    + Feb 09 20:27:06 Image Files (Various)
    + Feb 09 20:27:06 Results: Removed 0 records, 0 bytes in 0.09s
    + Feb 09 20:27:06 Shutdown Normal (0)

    I'm going to stop now :) Kinda went down a rabbit hole. But suffice to say
    that just using Mass Upload then running FileToss on it's own is not going to be enough for what I'm hoping to do within Mystic.

    Hope this info helps.

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Sun Feb 9 03:27:07 2020
    I'm going to stop now :) Kinda went down a rabbit hole. But suffice to
    say that just using Mass Upload then running FileToss on it's own is not going to be enough for what I'm hoping to do within Mystic.

    It won't hatch it until we enable autohatch wildcards. The situation I was referring to was assuming we had an autohatch that ignored the extension or allowed wildcards. Then it would work like this:

    1. Batch generates nodelist and copies zip to your fsx nodelist filebase
    2. Run MUTIL:
    Mass upload uploads into fsx nodelist file base
    Auto hatch finds the new fsxnode.* file and tosses it (with replace)

    The end result is it gets generated and hatched automatically, but you'll end up with the old nodelists in your fsx nodelist base because mass upload won't do a replace. The older nodelists won't autohatch because they'll already be flagged as hatched.

    Having thought through it a little more, I can make the autohatch add the file to the Mystic database and replace the old one during the hatch (without breaking existing configurations) BUT it will require that the file is copied to the file area's directory first.

    The problem with that approach is that if/when mass upload runs first it will find it then upload it when we don't want it to. In order for the whole thing to work smoothly it'd require the Sysop to put autohatch filenames into the "Ignore" section of the mass upload stanza. OR mass upload itself could be changed to have a "replace" function.

    Either would work for full automation but it wouldn't be as straight forward as I like to make things. I'll review the config for autohatch tomorrow and
    come up with something better.

    (On a side note the "remove" you saw when file packing is what MUTIL logs
    when it is removing a deleted record thats left over in the database).

    --- Mystic BBS v1.12 A45 2020/02/09 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Al@21:4/106 to g00r00 on Sun Feb 9 01:09:26 2020
    Hello g00r00,

    The end result is it gets generated and hatched automatically, but
    you'll end up with the old nodelists in your fsx nodelist base because mass upload won't do a replace. The older nodelists won't autohatch because they'll already be flagged as hatched.

    Having thought through it a little more, I can make the autohatch add
    the file to the Mystic database and replace the old one during the
    hatch (without breaking existing configurations) BUT it will require
    that the file is copied to the file area's directory first.

    Since Mystic (or mutil) has all the functions needed built in it sounds to me like we just need to put the file in the inbound with a bare bones tic file and
    let it go..

    Maybe a simple hatch utility could do that with "Replaces" and the like if needed.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Vk3jed@21:1/109 to Al on Sun Feb 9 21:18:00 2020
    On 02-09-20 01:09, Al wrote to g00r00 <=-

    Maybe a simple hatch utility could do that with "Replaces" and the like
    if needed.

    Sounds like what my "hatch" script does. :)


    ... So easy, a child could do it. Child sold separately.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From g00r00@21:1/108 to Al on Sun Feb 9 12:54:16 2020
    Since Mystic (or mutil) has all the functions needed built in it sounds
    to me like we just need to put the file in the inbound with a bare bones tic file and let it go..

    Maybe a simple hatch utility could do that with "Replaces" and the like
    if needed.

    Yes, that would work too. If you just created your own .TIC to go along with it and copied it with the file, then Mystic would just process it as if it received the file from somewhere else. Autohatch would then pick it up once I enable wildcard hatching.

    Thats probably the easiest solution if someone knows how to make the barebone .TIC file.

    --- Mystic BBS v1.12 A45 2020/02/09 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Al@21:4/106 to g00r00 on Sun Feb 9 12:17:08 2020
    Hello g00r00,

    Thats probably the easiest solution if someone knows how to make the barebone .TIC file.

    Yep, in spite of the fact I hatch files regularly I forget what a barebones tic
    looks like or needs.. ;)

    A small utility or script would be welcome by a few of us so we can get that done as quickly and easily as possible.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Black Panther@21:1/186 to Al on Sun Feb 9 13:57:58 2020
    On 09 Feb 2020, Al said the following...

    Yep, in spite of the fact I hatch files regularly I forget what a barebones tic looks like or needs.. ;)

    A small utility or script would be welcome by a few of us so we can get that done as quickly and easily as possible.

    I'm not sure if it will help or not, but I do have a text file here that explains all of the keywords for a tic file. I've dropped it into Paul's filebox, in case he would like to hatch it out.

    I've never written a tic file, as I let HTick do that for me, but the
    keywords are pretty straight-forward.


    ---

    Black Panther(RCS)
    Castle Rock BBS

    --- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Avon@21:1/101 to Black Panther on Mon Feb 10 12:51:30 2020
    On 09 Feb 2020 at 01:57p, Black Panther pondered and said...

    I'm not sure if it will help or not, but I do have a text file here that explains all of the keywords for a tic file. I've dropped it into Paul's filebox, in case he would like to hatch it out.

    I've never written a tic file, as I let HTick do that for me, but the keywords are pretty straight-forward.

    In the early days when I was hatching stuff out I was using an edited TIC per Mystic release for each OS to fudge this hatching process. It was time consuming editing each by hand and updating file sizes etc. for the files I wanted to pass to Mystic to toss and hatch :(

    More recently I assigned the task to HTick to get me halfway there by
    creating the TIC for each file then passed that to Mystic.

    I agree with Al. If there was a tool to create the TIC then I could just use that in lieu of Htick. While it replaces one tool for another it does not really make the overall functionality of trying to hatch files outside of the logged in Mystic UI any easier...

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Al@21:4/106 to Avon on Sun Feb 9 16:51:20 2020
    Hello Avon,

    I agree with Al. If there was a tool to create the TIC then I could
    just use that in lieu of Htick. While it replaces one tool for another
    it does not really make the overall functionality of trying to hatch
    files outside of the logged in Mystic UI any easier...

    I wonder if a .mps could do this?

    That way nodes who want to hatch files could add it to a menu. It would need to
    be able to calculate the md5sum of the file and insert the needed keywords like "Replaces" if needed for any file being hatched.

    Hmm..

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Black Panther@21:1/186 to Avon on Sun Feb 9 18:14:04 2020
    On 10 Feb 2020, Avon said the following...

    In the early days when I was hatching stuff out I was using an edited
    TIC per Mystic release for each OS to fudge this hatching process. It
    was time consuming editing each by hand and updating file sizes etc. for the files I wanted to pass to Mystic to toss and hatch :(

    It should be simple enough to put together a script to generate the tic file. Perhaps even just have a generic tic file, that you would just change the filename, description, filesize and crc, and have it import/hatch...

    I'd try to throw one together, but I'm already juggling three different projects... :(


    ---

    Black Panther(RCS)
    Castle Rock BBS

    --- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From g00r00@21:1/108 to Avon on Sun Feb 9 23:09:16 2020
    I agree with Al. If there was a tool to create the TIC then I could just use that in lieu of Htick. While it replaces one tool for another it
    does not really make the overall functionality of trying to hatch files outside of the logged in Mystic UI any easier...

    I worry about the statistical tracking though, because when it is found as a TIC Mystic isn't going to count it as a hatched file.

    I think I may just rewrite the autohatch function instead of trying to
    bandaid something like we've been discussing.

    --- Mystic BBS v1.12 A45 2020/02/09 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From StackFault@21:1/172 to Al on Mon Feb 10 07:11:06 2020
    I wonder if a .mps could do this?

    That way nodes who want to hatch files could add it to a menu. It would need to be able to calculate the md5sum of the file and insert the
    needed keywords like "Replaces" if needed for any file being hatched.

    Well, if an MPS can't, an MPY can most likely work. If I was not so swamped with work these days, I'd give it a shot just for fun. Unfortunately my time
    is extremely rare at the moment :(

    Cheers!

    |15 ▀ ▐ |15StackFault |08<|03.|11.|15P|11h|03EN|11o|15M|11.|03.|08>
    |11 ▌ ▀ |11The Bottomless Abyss BBS
    |03 ▀ ▌▀ |03ssh|08.|072222 |08/ |03telnet|08.|072023 |08/ |03https
    |08 ▄■▐ |08bbs|07.|08bottomlessabyss|07.|08net

    --- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
    * Origin: The Bottomless Abyss BBS * bbs.bottomlessabyss.net (21:1/172)
  • From StackFault@21:1/172 to Black Panther on Mon Feb 10 07:14:15 2020
    It should be simple enough to put together a script to generate the tic file. Perhaps even just have a generic tic file, that you would just change the filename, description, filesize and crc, and have it import/hatch...

    I'd try to throw one together, but I'm already juggling three different projects... :(

    Back in the days I made a TIC processor to sort thru the satellite feed I was getting. It was receiving at 19.2kbps 24/7 so I had to sort thru stuff quickly and decide what I was keeping and what I was dropping, if I remember, I had like 500Mb of storage at the time. It was working surprisingly well and have been for many years until that satellite feed was no longer providing.

    Good'ol memories... :)

    Cheers!

    |15 ▀ ▐ |15StackFault |08<|03.|11.|15P|11h|03EN|11o|15M|11.|03.|08>
    |11 ▌ ▀ |11The Bottomless Abyss BBS
    |03 ▀ ▌▀ |03ssh|08.|072222 |08/ |03telnet|08.|072023 |08/ |03https
    |08 ▄■▐ |08bbs|07.|08bottomlessabyss|07.|08net

    --- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
    * Origin: The Bottomless Abyss BBS * bbs.bottomlessabyss.net (21:1/172)
  • From Avon@21:1/101 to g00r00 on Tue Feb 11 08:33:18 2020
    On 09 Feb 2020 at 11:09p, g00r00 pondered and said...

    I think I may just rewrite the autohatch function instead of trying to bandaid something like we've been discussing.

    If you can stand the pain of doing so I am inclined to agree with you.


    I worry about the statistical tracking though, because when it is found
    as a TIC Mystic isn't going to count it as a hatched file.

    Yep...

    Now I am late to getting the info re stats reports to you. Went to a Queen concert last night, in bed at 1am and up at 7am and just starting work. I'll try to sort stuff tonight if I don't fall asleep first :)

    --- Mystic BBS v1.12 A44 2020/02/04 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Vk3jed@21:1/109 to Al on Tue Feb 11 10:21:00 2020
    On 02-09-20 12:17, Al wrote to g00r00 <=-

    Hello g00r00,

    Thats probably the easiest solution if someone knows how to make the barebone .TIC file.

    Yep, in spite of the fact I hatch files regularly I forget what a barebones tic
    looks like or needs.. ;)

    A small utility or script would be welcome by a few of us so we can get that done as quickly and easily as possible.

    Would you like a copy of my "hatch" utility that I've been using for ages to hatch files on VKRadio and other nets? It builds a TIC file, as part of the hatching process.


    ... When you learn the answers, they change the questions.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Vk3jed@21:1/109 to Black Panther on Tue Feb 11 10:22:00 2020
    On 02-09-20 13:57, Black Panther wrote to Al <=-

    I've never written a tic file, as I let HTick do that for me, but the keywords are pretty straight-forward.

    I have a BASH script that writes TIC files. Al's welcome to a copy.


    ... TagLine support contract for renewal. Ignore this if you've already paid. === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Vk3jed@21:1/109 to Avon on Tue Feb 11 10:26:00 2020
    On 02-10-20 12:51, Avon wrote to Black Panther <=-

    In the early days when I was hatching stuff out I was using an edited
    TIC per Mystic release for each OS to fudge this hatching process. It
    was time consuming editing each by hand and updating file sizes etc.
    for the files I wanted to pass to Mystic to toss and hatch :(

    I let BASH do all the donkey work, because manually doing that sort of thing for me is highly problematic. I depend on automation in many areas of life. :)
    That was the basis of the "hatch" script that I offered a while back.

    And I found a public domain implementation of the CRC32 algorithm that TIC uses, so I could include a CRC in my TIC files.


    ... What did the cannibal call two hunters in a jeep? Meals on wheels!
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Vk3jed@21:1/109 to Black Panther on Tue Feb 11 10:44:00 2020
    On 02-09-20 18:14, Black Panther wrote to Avon <=-

    On 10 Feb 2020, Avon said the following...

    In the early days when I was hatching stuff out I was using an edited
    TIC per Mystic release for each OS to fudge this hatching process. It
    was time consuming editing each by hand and updating file sizes etc. for the files I wanted to pass to Mystic to toss and hatch :(

    It should be simple enough to put together a script to generate the tic file. Perhaps even just have a generic tic file, that you would just change the filename, description, filesize and crc, and have it import/hatch...

    I'd try to throw one together, but I'm already juggling three different projects... :(

    Save reinventing the wheel, I'll check my file areas...

    Got it. You can download it from my BBS at the following URL:

    ftp://freeway.vkradio.com/main/BBS/hatch01a.zip

    Anonymous FTP is enabled, you don't need to log in.


    ... Bad Day: When the bird outside your window is a buzzard.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Al@21:4/106 to Vk3jed on Mon Feb 10 16:12:02 2020
    Hello Vk3jed,

    A small utility or script would be welcome by a few of us so we
    can get that done as quickly and easily as possible.

    Would you like a copy of my "hatch" utility that I've been using for
    ages to hatch files on VKRadio and other nets? It builds a TIC file,
    as part of the hatching process.

    I also use htick but I'm curious how your script works, so I'm to grab it here in a few minutes here.

    Are you feeding files and tics to Mystic?

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Al@21:4/106 to StackFault on Mon Feb 10 16:15:38 2020
    Hello StackFault,

    Well, if an MPS can't, an MPY can most likely work.

    Yep, I think so. I think g00r00 is rethinking how it all works so it may not be
    needed.

    If I was not so swamped with work these days, I'd give it a shot just
    for fun. Unfortunately my time is extremely rare at the moment :(

    I know what you mean, I've been "catching" up the message areas lately because there is so little free time these days.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)
  • From Analog@21:2/123 to Vk3jed on Mon Feb 10 17:34:38 2020
    Would you like a copy of my "hatch" utility that I've been using for
    ages to hatch files on VKRadio and other nets? It builds a TIC file, as part of the hatching process.

    If you don't mind, I'd also like it.

    Cheers,

    |20|15┌─|16|08┤ |08De|07ad|15be|07a|08tz b|07b|15s
    |08└─┘├─┐ |08:>.|07A|08rk |0710|08:|07101|08/|0714|08.
    |04■ |08└|20|15─|16|08┘ |08:>.|10A|02gn |1046|08:|101|08/|10123|08.
    |04A|07n|15al|07o|08g |08:>.|12F|04sx |1221|08:|122|08/|12123|08. |15.|04p|07HENOM|15. |08:>.|15S|07ci |1577|08:|151|08/|15131|08. |04░▒░|08▒██▄▌|08:>.|11T|03qw |111337|08:|113|08/|1113|08.

    --- Mystic BBS v1.12 A45 2020/02/09 (Linux/64)
    * Origin: deadbeatz.org (21:2/123)
  • From Vk3jed@21:1/109 to Al on Tue Feb 11 14:09:00 2020
    On 02-10-20 16:12, Al wrote to Vk3jed <=-

    I also use htick but I'm curious how your script works, so I'm to grab
    it here in a few minutes here.

    Cool, I saw you downloaded it. :)

    Are you feeding files and tics to Mystic?

    Yep, the script drops TICs and the associted files into Mystic's inbound.


    ... The worst thing about censorship is ██████████.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From Vk3jed@21:1/109 to Analog on Tue Feb 11 14:11:00 2020
    On 02-10-20 17:34, Analog wrote to Vk3jed <=-

    Would you like a copy of my "hatch" utility that I've been using for
    ages to hatch files on VKRadio and other nets? It builds a TIC file, as part of the hatching process.

    If you don't mind, I'd also like it.

    Feel free to FTP it from the URL I gave. You don't need a login, my file areas are generally available for anonymous download.


    ... It is not enough to succeed. Others must fail.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)