• Re: InterBBS oneliners?

    From Avon@21:1/101 to g00r00 on Thu Jan 31 17:36:07 2019
    On 29 Jan 2019, Fireball pondered and said...

    It's called IBOL (InterBBS One Liners) and the latest is v4. Get GY-IBOL4.ZIP here at Cyberia (check the origin for address) or maybe any site that carries FSX Mystic Apps file echo.


    Perfect! Thank you! I haven't been in fsx long enough for them to hatch out cool stuff like this. lol! I'll login and grab it. Thanks again!

    Hi g00r00, just something for the wishlist, having the ability to schedule periodic hatching of files from a list supplied. This would allow HUBs to automate stuff being sent out from time to time. For nodes that have the
    files they would be replaced like for like, for new nodes that did not they would get the files. At present unless I manually hatch stuff out from time
    to time new nodes miss out and I confess I suck at doing this in my busy life :)

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Thu Jan 31 03:17:54 2019
    Hi g00r00, just something for the wishlist, having the ability to
    schedule periodic hatching of files from a list supplied. This would
    allow HUBs to automate stuff being sent out from time to time. For nodes that have the files they would be replaced like for like, for new nodes that did not they would get the files. At present unless I manually
    hatch stuff out from time to time new nodes miss out and I confess I
    suck at doing this in my busy life :)

    Ahh yes I remember we were having quite a bit of discussion around this in
    the past but I never ended up getting things done. I agree we need a way to
    at least hatch from command line or from MUTIL so you can set up an event.

    We just need to sort out the details of how we want it to work and I will
    get it done.

    Another issue that I have been dreading messing with is that I completely forgot to have the TIC system honor the BUSY files, so that needs to be done probably before anything else. I need to get that added in and then remove
    the busylog.

    --- Mystic BBS v1.12 A42 2019/01/25 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Fri Feb 1 17:32:48 2019
    On 30 Jan 2019, g00r00 pondered and said...

    Ahh yes I remember we were having quite a bit of discussion around this
    in the past but I never ended up getting things done. I agree we need a way to at least hatch from command line or from MUTIL so you can set up
    an event.

    Yep. That would be super helpful. The command line should allow for a file
    base id, file name to be hatched/rehatche, a switch for 'replace' verb, an option of specifying the name of the file to be replaced if so desired else
    use name of file being hatched.

    A variation on the above would be to also have a switch that points to a .txt file containing a list of files, each on a single line, with some agreed
    syntax on each line that allows the above info to be specified per file..
    them MUTIL processes the .txt file and hatches/rehatches assorted files to assorted bases.

    Last thought, perhaps also consider allowing wildcard options so a sysop
    could say hatch/rehatch files with name mys112_a4*.* or similar.. or fuel*.*
    if say we wanted to rehatch all the fuel artpacks out etc..

    Just some thoughts.

    We just need to sort out the details of how we want it to work and I will get it done.

    ..and agreed, another yep.


    Another issue that I have been dreading messing with is that I completely forgot to have the TIC system honor the BUSY files, so that needs to be done probably before anything else. I need to get that added in and
    then remove the busylog.

    Yeah this is an interesting one. What I am seeing is the need for something
    to be put in place so that if a bunch of files are hatched out that may take some time to send to each node, that some rule can be so whereby even if fidopoll is crashing traffic to a node and the filebox for that node is set
    to 'yes', .. that the files are not sent crash but rather sit on hold until
    the node polls... some setting like filebox autohold if file size > x Kb

    But if you do opt to create this, create it as a per echonode setting, as for echondes that are hubs pushing stuff to each other you would want a way to ensure those systems did crash any/all messages/files if the echonode was so set to do so.

    Does that make sense? I think that would be helpful and speed up processing
    of messages at hubs that are otherwise tied up for a long time when a
    fidopoll session is running polling 50 nodes and sending them 5 large files each that take approx 3-5 mins per echonode.

    In an ideal world Fidopoll (or if it's in the future baked back into MIS)
    would be able to poll and push traffic to multiple nodes at the same time. I think the linear nature of Fidopoll can be an issue for getting traffic sent out quicker when the echonode count goes up.

    But hey, I am talking from a wishlist point of view :)

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Fri Feb 1 02:21:43 2019
    A variation on the above would be to also have a switch that points to a .txt file containing a list of files, each on a single line, with some agreed syntax on each line that allows the above info to be specified
    per file.. them MUTIL processes the .txt file and hatches/rehatches assorted files to assorted bases.

    So do you think there should be an [AutoHatch] stanza in MUTIL? Or should it be more accessible by command line like "mis hatch FSX_INFO fsxpack.zip replace"

    Last thought, perhaps also consider allowing wildcard options so a sysop could say hatch/rehatch files with name mys112_a4*.* or similar.. or fuel*.* if say we wanted to rehatch all the fuel artpacks out etc..

    I am a little hesitant on this one just because of someone accidentally wildcarding and hatching 1000 files without realizing it, particularly if
    we're going to put it into MUTIL.

    Yeah this is an interesting one. What I am seeing is the need for something to be put in place so that if a bunch of files are hatched out that may take some time to send to each node, that some rule can be so whereby even if fidopoll is crashing traffic to a node and the filebox
    for that node is set to 'yes', .. that the files are not sent crash but rather sit on hold until the node polls... some setting like filebox autohold if file size > x Kb

    I've actually added this already its just not showing in the configuration because I've never tested it. I am going to enable this now and it will be in the next build but probably still untested by me.

    Also the next build has a minor change in the function that receives data during BINKP transfers. It seems to be working fine for me on my BBS but I just wanted to mention it so you are in the loop. Obviously binkp actually working is a big deal for you. :)

    I'll go ahead and make a new build now for you.

    But if you do opt to create this, create it as a per echonode setting,
    as for echondes that are hubs pushing stuff to each other you would want
    a way to ensure those systems did crash any/all messages/files if the echonode was so set to do so.

    It should allow you to limit per echomail node based as granular as 1 kilobyte up to about 10 gigabytes.

    --- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Fri Feb 1 20:55:02 2019
    On 31 Jan 2019, g00r00 pondered and said...

    So do you think there should be an [AutoHatch] stanza in MUTIL? Or
    should it be more accessible by command line like "mis hatch FSX_INFO fsxpack.zip replace"

    I think both but in order of effort I would do MUTIL first as most are
    familiar with it. But I know you want to roll things into MIS so it's worth doing so down the track.

    I am a little hesitant on this one just because of someone accidentally wildcarding and hatching 1000 files without realizing it, particularly if we're going to put it into MUTIL.

    I'm understanding of that. Yep best to park. If the sysop can load stuff to a text file and MUTIL honours that then that would be fine.

    rather sit on hold until the node polls... some setting like filebox autohold if file size > x Kb

    I've actually added this already its just not showing in the
    configuration because I've never tested it. I am going to enable this
    now and it will be in the next build but probably still untested by me.

    Heh good to know I'm not the only one pondering this. :)

    Also the next build has a minor change in the function that receives data during BINKP transfers. It seems to be working fine for me on my BBS
    but I just wanted to mention it so you are in the loop. Obviously binkp actually working is a big deal for you. :)

    It is thanks, I'll pull it down and check things out tonight when I get home.

    I'll go ahead and make a new build now for you.


    Thank you.

    a way to ensure those systems did crash any/all messages/files if the echonode was so set to do so.

    It should allow you to limit per echomail node based as granular as 1 kilobyte up to about 10 gigabytes.

    Then that's sounding ideal - thanks!

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Fri Feb 1 11:50:41 2019
    I think both but in order of effort I would do MUTIL first as most are familiar with it. But I know you want to roll things into MIS so it's worth doing so down the track.

    Sounds good I will look into adding this into MUTIL first.

    I really need to get those BSY files into the TIC processor though because if a file is in mid-transmission and mutil is executed, it will toss a partial file. It doesn't happen often but a few people have reported this happening in the past. Instances of this will only increase as we build out more features!

    rather sit on hold until the node polls... some setting like fil autohold if file size > x Kb

    I've actually added this already its just not showing in the configuration because I've never tested it. I am going to enable thi now and it will be in the next build but probably still untested by m

    Heh good to know I'm not the only one pondering this. :)

    Nope this was all your idea! You had mentioned it to me some time ago and I thought it was a great idea, so you get all the credit! :)

    It should allow you to limit per echomail node based as granular as 1 kilobyte up to about 10 gigabytes.

    Then that's sounding ideal - thanks!

    Now we just have to get that global echomail node editor in there!

    --- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From g00r00@21:1/108 to Avon on Fri Feb 1 12:47:05 2019
    So do you think there should be an [AutoHatch] stanza in MUTIL? Or should it be more accessible by command line like "mis hatch FSX_INFO fsxpack.zip replace"

    I think both but in order of effort I would do MUTIL first as most are familiar with it. But I know you want to roll things into MIS so it's

    There are some things to work through before I add this feature. To hatch a file as it stands now, it must already exist in the file area and Mystic hatches based on that data. The main reason that Mystic does this is so that it can track the status of a file (if its been hatched before) but it also pulls the file description from there too.

    Do we want Mystic to hatch without the requirement of having to have a file in the base? Should it upload it to the base if it doesn't exist and then hatch, or should it just require that it already exists before it will hatch?

    My thoughts are that if you're going to hatch a file it should require it to actually be in the file listing for that file echo otherwise you can hatch files out that don't even exists in the hub's file base.

    Here is what I am thinking as far as what it'd look like in MUTIL

    [AutoHatch]

    ; List of files to hatch automatically when executed
    ; Format: Area ID or echotag, filename, replaces filename (optional)
    ; All fields are separated by a pipe character |

    file = fsx_info | fsxinfo.zip | fsxinfo.zip
    file = 10 | fsxnode.zip | fsxnode.zip

    --- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Avon@21:1/101 to g00r00 on Sat Feb 2 12:43:15 2019

    On 01 Feb 2019, g00r00 pondered and said...

    Do we want Mystic to hatch without the requirement of having to have a file in the base? Should it upload it to the base if it doesn't exist
    and then hatch, or should it just require that it already exists before
    it will hatch?

    For what we are talking about with the AutoHatch function, yes I agree with
    you and think the latter option.

    My thoughts are that if you're going to hatch a file it should require
    it to actually be in the file listing for that file echo otherwise you
    can hatch files out that don't even exists in the hub's file base.

    I also agree with this for using the AutoHatch feature but...when you are a
    HUB and just wanting to import new files into the system and get them hatched as quickly and easily as possible I think it's a good idea for us to find an acceptable way to do this also.

    Here's what I need to do at the moment if I wish to use Mystic for hatching a file.

    I opted to follow the process of finding a new file, dropping it in to
    fsx_utls file directory on the local HDD, logging into the HUB, and running
    the mass upload option from the file menu for the fsx_utils base.

    [snip]

    2019.02.02 07:10:05 Avon logged in
    2019.02.02 07:10:05 First login today, setting time to 999
    2019.02.02 07:10:05 Set time left 999 TE=1429
    2019.02.02 07:10:05 Setting time left to 999
    2019.02.02 07:10:37 Mass upload
    2019.02.02 07:10:45 Added xsdl2crt.zip to BBS Utils, Tools, Networking etc. 2019.02.02 07:10:45 Executing: unzip -oqqjC "c:\mystfsx\files\fsx_utls\xsdl2crt.zip" "file_id.*" -d c:\mystfsx\temp1\ 2019.02.02 07:10:45 Execution complete: 0
    2019.02.02 07:11:28 User logged off
    2019.02.02 07:11:28 Shutting down

    [snip]

    Then I confirmed calling the filetoss stanza did nothing at this point to
    send it on to the 50+ echonodes linked to the base... and it didn't, which is to be expected.

    [snip]

    ----------------- MUTIL v1.12 A42 2018/12/30 Sat, Feb 02 2019 (loglevel 3)
    + Feb 02 07:11:55 Startup using mailin.ini
    - Feb 02 07:11:55 EXEC ImportEchoMail
    - Feb 02 07:11:55 EXEC FileToss
    + Feb 02 07:11:55 Process: Toss FDN/TIC Files
    + Feb 02 07:11:55 Scanning Hatches
    + Feb 02 07:11:55 Results: 0 import, 0 toss, 0 hatch, 0 bad in 0.02s

    [snip]

    and then reconfirming what I already knew, that to hatch from mystic I'd need login to the HUB, head to the file menu, select the correct file base, go in
    to file list editor option, find the file, choose H to hatch, step through
    the hatch options manually to confirm the hatch, logout, then call the
    filetoss stanza to get the files on their way to nodes.

    And to be honest that's a pain to do for one or more files, which is why at
    the moment when I hatch things I use an external TIC generation tool to
    create something for Mystic to ingest that handles both import into the file base and tossing and hatching to connected nodes all in one hit... much
    easier.

    So I'd like to ask for an option one also- Mystic to upload to the base and hatch. But this should be something separate from what we're
    brainstorming as a AutoHatch function in MUTIL.

    I'm wondering perhaps it can be something added to the MassUpload function so there's a hatch switch?

    ; Hatch files to FileEcho exports? 1=yes

    hatch_file_echo_exports = 1


    Or if this is seen to be too risky for a mass file bombing run (and I accept there's risk) then finding someway that a HUB operator can run a mystic
    command or switch to make possible what at present requires a bit of a kludge to achieve. I hope that all makes sense.. sing out if it does not :)

    [AutoHatch]

    ; List of files to hatch automatically when executed
    ; Format: Area ID or echotag, filename, replaces filename (optional)
    ; All fields are separated by a pipe character |

    file = fsx_info | fsxinfo.zip | fsxinfo.zip
    file = 10 | fsxnode.zip | fsxnode.zip

    Yep like this, just add a comment about case of file names, I'm presuming if the sysop put in FSXinfo.zip or FSXINFO.ZIP then Mystic would still hatch the correct file? I wonder if some default treatment of file names being hatched should be enabled?

    ; Convert filenames to lower case for hatched files?
    ; True or 1 for yes, false or 0 for no

    lowercase_filename = true

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Fri Feb 1 20:46:22 2019
    And to be honest that's a pain to do for one or more files, which is why at the moment when I hatch things I use an external TIC generation tool
    to create something for Mystic to ingest that handles both import into
    the file base and tossing and hatching to connected nodes all in one hit... much easier.

    This is my process for hatching a bunch of brand new files now:

    If you have 5 files to hatch into an area you copy them into the folder, login to the BBS, type /U on the file menu, then do a newscan of the base. The 5 new files will show up, with the first one already highlighted. Press E to edit, then select hatch press ] to go to the next file, then select hatch, ] hatch ] hatch. It should only take about a minute or two to hatch those files.

    From a command line you'll still have to type:

    mutil hatch fsx_info c:\mystic\myfiles\file1.zip replace file1.zip
    mutil hatch fsx_info c:\mystic\myfiles\file2.zip replace file2.zip
    mutil hatch fsx_info c:\mystic\myfiles\file3.zip replace file3.zip
    mutil hatch fsx_info c:\mystic\myfiles\file4.zip replace file4.zip
    mutil hatch fsx_info c:\mystic\myfiles\file5.zip replace file5.zip

    I am not disagreeing that there should be a better way, just thinking out loud I guess about whether or not its really that much faster.

    The TIC workaround you're already doing is very clever, and I am wondering if maybe Mystic shouldn't just do the same thing? So if you hatch from command line all it'd really do is copy it to your inbound and create a .TIC for it, then MUTIL will import it to you BBS and toss it to the downlinks.

    So I'd like to ask for an option one also- Mystic to upload to the base and hatch. But this should be something separate from what we're brainstorming as a AutoHatch function in MUTIL.

    Okay so we could have AutoHatch in MUTIL only work if the file exists, but then a separate command line option that would copy it into the file base, upload it, and then hatch it (or if the file exists, it'd just update the existing record and still hatch it). Sounds reasonable to me!

    I'm wondering perhaps it can be something added to the MassUpload
    function so there's a hatch switch?

    Maybe it could even be a flag on a file base "Auto hatch" which automatically hatches any new files that are mass uploaded into that base. But it would not hatch files that are uploaded into the base by a BBS user.

    I do worry a little bit that someone could accidentally toggle the flag ON and end up hatching a bunch of files out somewhere. Even if it seems far fetched people really do seem to sometimes find ways to do some far fetched things :)

    Well I think now we have even more possible options on the table with all of this discussion haha! I am not sure which approach to take. Out of all of these ideas which do you think would be the most useful combination of
    options for you?

    --- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
    * Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
  • From Black Panther@21:1/186 to g00r00 on Fri Feb 1 21:06:21 2019
    On 01 Feb 2019, g00r00 said the following...

    My thoughts are that if you're going to hatch a file it should require
    it to actually be in the file listing for that file echo otherwise you
    can hatch files out that don't even exists in the hub's file base.

    I know this was Paul's suggestion to add, but I'm gonna jump in and give my 2 cents. :)

    I would think, it would be easy enough to have the file imported into
    Mystic's filebase, and then hatch it from there. It would just be a matter of having separate events to complete the process.

    Again, just my 2 cents... :)


    ---

    Black Panther(RCS)
    a.k.a. Dan Richter
    Sysop - Castle Rock BBS
    telnet://bbs.castlerockbbs.com
    http://www.castlerockbbs.com
    The sparrows are flying again....

    --- Mystic BBS v1.12 A42 2019/01/31 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Black Panther@21:1/186 to Avon on Fri Feb 1 21:21:01 2019
    On 02 Feb 2019, Avon said the following...

    I opted to follow the process of finding a new file, dropping it in to fsx_utls file directory on the local HDD, logging into the HUB, and running the mass upload option from the file menu for the fsx_utils base.

    Hi Paul,

    Wouldn't it be easier to just use the mutil.ini stanza [MassUpload]?

    Perhaps if something could be added to that stanza, which allows imported
    files to be auto hatched...

    snip<=-

    [MassUpload]

    uploader_name = fsxNet's Mystic Guy
    import_fileid = 1
    no_description = No Description
    ignore = files.bbs

    ; List of files to hatch automatically when executed
    ; Format: Area ID or echotag, filename, replaces filename (optional
    ; All fields are separated by a pipe character |

    file = fsx_info | fsxinfo.zip | fsxinfo.zip
    file = fsx_node | fsxnode.zip | fsxnode.zip

    snip<=-

    Just a thought, as I play devil's advocate... :)


    ---

    Black Panther(RCS)
    a.k.a. Dan Richter
    Sysop - Castle Rock BBS
    telnet://bbs.castlerockbbs.com
    http://www.castlerockbbs.com
    The sparrows are flying again....

    --- Mystic BBS v1.12 A42 2019/01/31 (Linux/64)
    * Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)
  • From Andrew Leary@21:4/105 to g00r00 on Fri Feb 1 23:15:27 2019
    Hello g00r00!

    01 Feb 19 15:46, you wrote to Avon:

    The TIC workaround you're already doing is very clever, and I am
    wondering if maybe Mystic shouldn't just do the same thing? So if you hatch from command line all it'd really do is copy it to your inbound
    and create a .TIC for it, then MUTIL will import it to you BBS and
    toss it to the downlinks.

    This is how hatching works in MBSE. The hatch script creates a .tic in the inbound, which mbfido processes to add the file to the BBS filebase and forward it to any downlinks.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (21:4/105)
  • From Avon@21:1/101 to Black Panther on Sun Feb 3 03:06:55 2019
    On 01 Feb 2019 at 04:21p, Black Panther pondered and said...

    Wouldn't it be easier to just use the mutil.ini stanza [MassUpload]?

    Perhaps if something could be added to that stanza, which allows imported files to be auto hatched...

    I think you'll find I suggested that as one option in my original reply :) So yeah, great minds thinking alike.

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Sun Feb 3 03:09:49 2019
    On 01 Feb 2019 at 03:46p, g00r00 pondered and said...

    This is my process for hatching a bunch of brand new files now:

    It's got late here and my brain is fried for the night, so will read this one more closely tomorrow and reply then :)

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Sun Feb 3 03:25:37 2019
    On 01 Feb 2019 at 06:50a, g00r00 pondered and said...

    rather sit on hold until the node polls... some setting lik autohold if file size > x Kb

    I've actually added this already its just not showing in the configuration because I've never tested it. I am going to enabl now and it will be in the next build but probably still untested

    Heh good to know I'm not the only one pondering this. :)

    Nope this was all your idea! You had mentioned it to me some time ago
    and I thought it was a great idea, so you get all the credit! :)

    [snip]

    + New option for each Echomail node: Crash Limiter. When FidoPoll sends
    files via BINKP it will skip queueing any files for sending larger than
    this value. The value is defined in kilobytes.

    [snip]

    Thank you for adding this. As we both probably realise adding this setting
    for 50+ nodes without a global echonode editor will take some time. So what I thought of was this.

    Do you think you could add a Crash Limiter global setting somewhere? Perhaps
    it would be most appropriate in the Configuration > General Settings section

    The idea being a sysop could set this value here and it would apply to all echonodes that had no setting applied (echonode value = 0) and if the sysop wanted to override this s/he could just set a specific value for a given echonode that would override the global setting. If the global setting was
    also set to 0 then no global action would be applied to all echonodes.

    Just a thought..

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Avon@21:1/101 to g00r00 on Mon Feb 4 18:15:57 2019
    On 01 Feb 2019 at 03:46p, g00r00 pondered and said...

    This is my process for hatching a bunch of brand new files now:

    highlighted. Press E to edit, then select hatch press ] to go to the
    next file, then select hatch, ] hatch ] hatch. It should only take
    about a minute or two to hatch those files.

    From a command line you'll still have to type:
    mutil hatch fsx_info c:\mystic\myfiles\file1.zip replace file1.zip
    mutil hatch fsx_info c:\mystic\myfiles\file2.zip replace file2.zip

    I am not disagreeing that there should be a better way, just thinking
    out loud I guess about whether or not its really that much faster.

    I think it's more a case of how can things be run from a batch file or
    command line or similar and not having to do this from within a logged in
    state within Mystic. The non-logged in option(s) - whatever we come up with -
    I think will speed up the process and be useful, certainly from a HUB operations POV :)

    The TIC workaround you're already doing is very clever, and I am
    wondering if maybe Mystic shouldn't just do the same thing? So if you hatch from command line all it'd really do is copy it to your inbound
    and create a .TIC for it, then MUTIL will import it to you BBS and toss
    it to the downlinks.

    Works for me, so long as Mystic can tell it's a valid TIC etc. as at present
    to do this trick I have to create an echonode record for the system sending
    in the TIC.

    So I'd like to ask for an option one also- Mystic to upload to the ba and hatch. But this should be something separate from what we're brainstorming as a AutoHatch function in MUTIL.

    Okay so we could have AutoHatch in MUTIL only work if the file exists,
    but then a separate command line option that would copy it into the file base, upload it, and then hatch it (or if the file exists, it'd just update the existing record and still hatch it). Sounds reasonable to me!

    Yes exactly.

    I'm wondering perhaps it can be something added to the MassUpload function so there's a hatch switch?

    Maybe it could even be a flag on a file base "Auto hatch" which automatically hatches any new files that are mass uploaded into that
    base. But it would not hatch files that are uploaded into the base by a BBS user.

    I do worry a little bit that someone could accidentally toggle the flag
    ON and end up hatching a bunch of files out somewhere. Even if it seems far fetched people really do seem to sometimes find ways to do some far fetched things :)

    Yes I agree with the worry... and I am not sure about the mass upload options being discussed as a good idea or not, for the same concerns. I think the earlier command line option that will upload and hatch in one smooth sequence speaks to the same feature being kicked around for [massupload] so perhaps
    best to start with that and then refine things from there is there is a need
    or something else that becomes apparent?

    Well I think now we have even more possible options on the table with
    all of this discussion haha! I am not sure which approach to take. Out of all of these ideas which do you think would be the most useful combination of options for you?

    For hatching new files I like the idea of a command line that will create a
    TIC and set up Mystic to import the file into the file base and at the same time hatch it out to nodes connected to the file base. So essentially what I
    am doing now.

    For re-hatching files already in situ in a Mystic file base(s) I like what we have been discussing about a function in MUTIL that enables the sysop to
    state file bases and file names etc. to re-hatch and MUTIL works through the states list and does the business.. that would enable me to be able to resend files out to nodes from time to time and new nodes would then get them while older nodes would just ensure they had the latest copy of a file.

    I can't recall with the MUTIL re-hatch stanza if you were looking to make a provision for an external TXT file to be able to be stipulated as the source list of files to be re-hatched? But if you could include it as an option that would be helpful too.

    [related question]

    Do you know if there is a TIC verb that would allow a HUB to issue a remove command. So if a hatched file wanted to be recalled and removed from nodes it has been sent to, that the HUB could send a TIC to a node and instead of replacing a file, it would delete it instead?

    There are occasions where I have hatched files using a certain naming schema (supplied by the file author) then later on a new version is supplied but with a different naming schema, making replacing older files trickier if I miss
    this fact out when hatching stuff.

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From g00r00@21:1/108 to Avon on Mon Feb 4 14:53:11 2019
    Works for me, so long as Mystic can tell it's a valid TIC etc. as at present to do this trick I have to create an echonode record for the system sending in the TIC.

    Yeah good point! I haven't really looked at the code to see how that would behave but it may not be worth the effort of changing the TIC processor to allow it.

    I am leaning more towards having it do the import and hatch itself, and then the next time the file tosser runs it will toss it. So it'd be a "real" hatch not a kludge using a .TIC.

    I can't recall with the MUTIL re-hatch stanza if you were looking to
    make a provision for an external TXT file to be able to be stipulated as the source list of files to be re-hatched? But if you could include it
    as an option that would be helpful too.

    You did mention this but to be honest I probably wasn't going to do it. Do you already have a list of files somewhere that you don't want to put into the AutoHatch stanza? I just want to get a feel of how you'd use it and the benefit of it being in an external file instead of having it defined in the stanza itself. I was planning just to do it like:

    [AutoHatch]
    file=fsx_info|fsxinfo.zip|fsxinfo.zip

    The first column would be the ID or echotag, the second would be the location and filename, the third would be optional "replace"

    --- Mystic BBS v1.12 A42 2019/02/01 (Linux/64)
    * Origin: Sector 7 (21:1/108)
  • From Avon@21:1/101 to g00r00 on Wed Feb 6 00:12:20 2019
    On 04 Feb 2019 at 09:53a, g00r00 pondered and said...

    I am leaning more towards having it do the import and hatch itself, and then the next time the file tosser runs it will toss it. So it'd be a "real" hatch not a kludge using a .TIC.

    I agree

    I can't recall with the MUTIL re-hatch stanza if you were looking to make a provision for an external TXT file to be able to be stipulated the source list of files to be re-hatched? But if you could include i as an option that would be helpful too.

    You did mention this but to be honest I probably wasn't going to do it.
    Do you already have a list of files somewhere that you don't want to put into the AutoHatch stanza? I just want to get a feel of how you'd use
    it and the benefit of it being in an external file instead of having it defined in the stanza itself. I was planning just to do it like:

    Upon reflection I'd say just go with what you're thinking there is no real
    need for an external file to point to in this case. Loading things into an
    .ini file will do just fine :)

    Best, Paul

    --- E:avon@bbs.nz ------ W:bbs.nz ---
    --- K:keybase.io/avon --------------

    --- Mystic BBS v1.12 A42 2019/02/01 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)