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)

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)

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)

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)