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 :)
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.
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..
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.
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 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.
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.
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.
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.
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. :)
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!
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
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.
[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
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?
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 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<=-
snip<=-
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.
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...
This is my process for hatching a bunch of brand new files now:
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! :)
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.
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 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!
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?
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.
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.
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 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:
Sysop: | echicken |
---|---|
Location: | Toronto, Ontario |
Users: | 2,224 |
Nodes: | 6 (0 / 6) |
Uptime: | 206:39:27 |
Calls: | 14,142 |
Files: | 295 |
Messages: | 551,070 |