I am writing a game in MPL and want to have a loop to run several procedures while the player is not entering a key command. I thought the KeyPressed function would be great for this.

It looks like once a key is entered KeyPressed returns true and the program exits the loop, this is good, but how do you reset KeyPressed to false?

It doesn't make sense that you can only check the status of KeyPressed once, there must be a way to reset it to false. KeyPressed := false does not work.

Thanks

National Incident Alerts
telnet://niabbs.com
www.nationalincidentalerts.com

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: NIA BBS (21:2/108)

On 01/02/18, NIA01 said the following...

I am writing a game in MPL and want to have a loop to run several procedures while the player is not entering a key command. I thought the KeyPressed function would be great for this.

It looks like once a key is entered KeyPressed returns true and the program exits the loop, this is good, but how do you reset KeyPressed to false?

It doesn't make sense that you can only check the status of KeyPressed once, there must be a way to reset it to false. KeyPressed := false does not work.

If Keypressed is true, in order to reset it, you have to read a key from the buffer. Once it's read from the buffer, Keypressed is reset to false.

I have an example of how to use Keypress in the way you want, in the MRC_CLIENT.MPS script from MRC.

While Ch = #13 Or Ch = #32 Do Begin
While Not Keypressed Do Begin
ReadChatFiles
Delay(100)
Loop:=Loop+1
If Loop > 10000 Then Loop:=1
If Loop % 2345 = 0 Then Begin
SendToServer('IAMHERE')
End
End
Ch:=ReadKey
End

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: Cyberia BBS | cyberia.darktech.org | San Jose, CA (21:1/120)

If Keypressed is true, in order to reset it, you have to read a key from the buffer. Once it's read from the buffer, Keypressed is reset to
false.

That makes sense, let me try that. Thanks for your help.

Ray

National Incident Alerts
telnet://niabbs.com
www.nationalincidentalerts.com

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: NIA BBS (21:2/108)

It looks like once a key is entered KeyPressed returns true and the program exits the loop, this is good, but how do you reset KeyPressed to false?

Its true if there is a key waiting, false if not. Its not something you'd ever need to reset its more of a "current state" variable.

It doesn't make sense that you can only check the status of KeyPressed once, there must be a way to reset it to false. KeyPressed := false does not work.

You can check it as many times as you want. It'll be true if a key is waiting to be read or false if there isn't one waiting. It sounds like maybe you're wanting to do something like this?

While KeyPressed Do
ReadKey;

Or

If KeyPressed Then Begin
Ch := ReadKey;

WriteLn ('You entered: ' + Ch);
End;

--- Mystic BBS v1.12 A38 2018/01/01 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Its true if there is a key waiting, false if not. Its not something
you'd ever need to reset its more of a "current state" variable.

Thanks g00r00 but this is more of what I am trying to do. The first time I
call the procedure it works, but the second time I call it, it does not work.

procedure idleloop()
var cc : char = 'B';
begin
while cc = 'B' do begin
while not keypressed do
begin
endTime := timer;
if endTime - startTime > 1 then
begin
writeln('Hello');
startTime := endTime;
end;
end;
cc := readkey;
end;
end;

begin
repeat
ch := readkey;
ch := upper(ch);
case ch of
'B' : begin
idleloop();
end;
'Q' : begin
done := true;
end;
end;
until done;
end;

National Incident Alerts
telnet://niabbs.com
www.nationalincidentalerts.com

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: NIA BBS (21:2/108)

Thanks g00r00 but this is more of what I am trying to do. The first time
I call the procedure it works, but the second time I call it, it does
not work.

The code you have looks fine.

Have you tried testing it from a telnet connection or on any other OS? It seems to me like there is possibly an input bug within localmode on Windows only. Actual connected users should work fine and so should other platforms.

I have more testing to do but I'll get that issue fixed up and I think you'll be good to go for the first A39 prealpha build. In the meantime, you might
be forced to telnet into your BBS via localhost and test/develop it that way for it to work.

--- Mystic BBS v1.12 A38 2018/01/01 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Have you tried testing it from a telnet connection or on any other OS?
It seems to me like there is possibly an input bug within localmode on Windows only. Actual connected users should work fine and so should
other platforms.

You are right, it works fine when I telnet. I should have tried that before contacting you. Goes to show you, a bug can show up in the strangest ways.

Thanks for your help.

National Incident Alerts
telnet://niabbs.com
www.nationalincidentalerts.com

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: NIA BBS (21:2/108)

You are right, it works fine when I telnet. I should have tried that before contacting you. Goes to show you, a bug can show up in the strangest ways.

Yep it can! At least you aren't totally screwed until the next build so you can still develop your program and users can still use it.

It may take a little longer than it has been for me to get the next pre-alpha build out because I am doing some data file changes and things like that.

--- Mystic BBS v1.12 A38 2018/01/01 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 01/04/18, g00r00 said the following...

It may take a little longer than it has been for me to get the next pre-alpha build out because I am doing some data file changes and things like that.

i noticed the records for 1.12 have not changed but what data files did
A27/A38 change since last?

|08 .|05ú|13ù|15Dr|07e|08am Ma|07st|15er|13ù|05ú|08.
|08 øù|05ú|13ùø |13øù|05ú|08ùø
|11 DoRE|03!|11ACiDiC|03!|11Demonic |08[|15dreamland|09.|15darktech|09.|15org|08]

--- Mystic BBS v1.12 A38 2018/01/01 (Windows/64)
* Origin: |08--[|15!|07dreamland BBS dreamland.darktech.org (21:1/163)

i noticed the records for 1.12 have not changed but what data files did A27/A38 change since last?

A38 changed the scan records for each message and file base. (.scn)

A39 will change a lot of records. So far I have made changes to users.dat, mbases.dat, and fbases.dat. DOS date format has been converted to Unix or Julian day in many places. servers.dat will likely change. You'll no longer be able to access user passwords in any form, neither via data file or even view it as a SysOp. It will all be in the whatsnew for A39.

I am also leaning very much towards adding in the Mystic 2 theme system in as well, which means that themes.dat would go away entirely and the directory structure would change slightly. This may not be A39 though because its a huge change.

I really want to remove the "message base path" from each message area as
well, but some people seem to be OCD and like to move their data files all
over the place for their message bases --- so I've been undecided on this.

In general, I would much prefer Mystic 1 used a directory structure more similar to the last Mystic2demo.

--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 01/04/18, g00r00 pondered and said...

I am also leaning very much towards adding in the Mystic 2 theme system
in as well, which means that themes.dat would go away entirely and the directory structure would change slightly. This may not be A39 though because its a huge change.

I think this is a direction you have wanted to go for some time and suggest
you follow your gut and do it for Mystic 1

I really want to remove the "message base path" from each message area as well, but some people seem to be OCD and like to move their data files
all over the place for their message bases --- so I've been undecided on this.

The trick is in allowing people to store their data files on drives/dirs they want. Often this is to assist them in backing up stuff or just allocating storage resource (I'll run the BBS on C but store my data on D). So when it comes to messages / files I can see why people may want to have this control.

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

--- Mystic BBS v1.12 A38 2018/01/01 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Hello Avon!

I really want to remove the "message base path" from each message
area as well, but some people seem to be OCD and like to move
their data files all over the place for their message bases ---
so I've been undecided on this.

I wouldn't have a problem with all the message areas being located in a single message base path. But it would good if the base path could be specified.

The trick is in allowing people to store their data files on
drives/dirs they want. Often this is to assist them in backing up
stuff or just allocating storage resource (I'll run the BBS on C but
store my data on D). So when it comes to messages / files I can see
why people may want to have this control.

Both on the Mystic and BBBS machine here I have a SSD boot drive with
seperate SATA HD's for /home/ and for /files/ and use Rsync to backup
the necessary drives/directories


Jeff


--- GoldED+/LNX 1.1.5-b20170303 / Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: The Ouijaboard II - Anoka, MN (21:1/128)

On 01/04/18, g00r00 said the following...

i noticed the records for 1.12 have not changed but what data files d A27/A38 change since last?

A38 changed the scan records for each message and file base. (.scn)
A39 will change a lot of records. So far I have made changes to users.dat, mbases.dat, and fbases.dat. DOS date format has been
converted to Unix or Julian day in many places. servers.dat will likely change. You'll no longer be able to access user passwords in any form,

since there are no more dos versions and 32b and 64b system are more efficient that way?

I am also leaning very much towards adding in the Mystic 2 theme system
in as well, which means that themes.dat would go away entirely and the directory structure would change slightly. This may not be A39 though

would the themes merge with the mystic.dat?

|08 .|05ú|13ù|15Dr|07e|08am Ma|07st|15er|13ù|05ú|08.
|08 øù|05ú|13ùø |13øù|05ú|08ùø
|11 DoRE|03!|11ACiDiC|03!|11Demonic |08[|15dreamland|09.|15darktech|09.|15org|08]

--- Mystic BBS v1.12 A38 2018/01/01 (Windows/64)
* Origin: |08--[|15!|07dreamland BBS dreamland.darktech.org (21:1/163)

On 01/05/18, Avon said the following...

I think this is a direction you have wanted to go for some time and suggest you follow your gut and do it for Mystic 1

I just might. :) There are several pros to doing it...

There are lots of times when I don't add something someone requests into Mystic specifically because I would have to add or change prompts. Some people seem to struggle with keeping those prompts updated. This new system only requires them to be updated if a prompt they've personally customized changes... which means they should have an idea where the prompt is and how to do it because they've already done it once.

People who use the default prompt wouldn't have to do anything to upgrade, as opposed to add new prompts or replacing existing prompts in the .txt files as it works now.

It'll also allow new themes to be created more easily, and for people to
easily just "drop" a theme folder under \mystic\themes\ and it will show up
in their BBS instantly without any configuration...

This will promote people creating and sharing themes, and I would probably do a handful of themes just to mimic some of the more historically popular BBSes like WildCat, Searchlight, Remote Access, Renegade, etc.

The same could work for themes that are used for other languages, too. Want to add a Spanish theme? Download it and drop the "spanish" folder into \mystic\themes and thats all you have to do.

The trick is in allowing people to store their data files on drives/dirs they want. Often this is to assist them in backing up stuff or just allocating storage resource (I'll run the BBS on C but store my data on D). So when it comes to messages / files I can see why people may want
to have this control.

You would still define the base message base path in System Configuration, but the change would be that all of the JAM bases would be in the same directory. It would no longer be configurable per-message-base.

I think the push-back I was getting is that people wanted to have certain message base data files in different directories. Like to split them up by network, although I don't know why that really matters.

--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

I wouldn't have a problem with all the message areas being located in a single message base path. But it would good if the base path could be specified.

Yep that is how it would work. If I remove it from message bases and add the updated theme system for Mystic 2, then we'll be able to simply copy Mystic to different directories and not have to reconfigure anything except file base paths. (Or copy it from Windows to Linux to OSX without reconfiguring anything)

--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 01/04/18, g00r00 pondered and said...

I think this is a direction you have wanted to go for some time and suggest you follow your gut and do it for Mystic 1

I just might. :) There are several pros to doing it...

[snip]

It'll also allow new themes to be created more easily, and for people to easily just "drop" a theme folder under \mystic\themes\ and it will show up in their BBS instantly without any configuration...

This will promote people creating and sharing themes, and I would
probably do a handful of themes just to mimic some of the more historically popular BBSes like WildCat, Searchlight, Remote Access, Renegade, etc.

I think this is a great reason to standardize things. I gives everyone a
common understanding of the platform and as you suggest could well spark some innovate sharing / creation of themes - a good thing!

The same could work for themes that are used for other languages, too. Want to add a Spanish theme? Download it and drop the "spanish" folder into \mystic\themes and thats all you have to do.

I'd love to see a theme that was friendly to non-sighted readers i.e text-to-speech systems. Have been wanting to play in that space for a while
now but keeping up with all things BBS has kept me busy of late :)

You would still define the base message base path in System
Configuration, but the change would be that all of the JAM bases would
be in the same directory. It would no longer be configurable per-message-base.

That seems fine to me. So long as you can decide a drive/path for all message JAM bases it's all good.

I think the push-back I was getting is that people wanted to have certain message base data files in different directories. Like to split them up by network, although I don't know why that really matters.

It does not IMHO so I think your idea above is good to proceed with.

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

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

users.dat, mbases.dat, and fbases.dat. DOS date format has been converted to Unix or Julian day in many places. servers.dat will lik

since there are no more dos versions and 32b and 64b system are more efficient that way?

It is more efficient to use Unix time stamps when converting between time zones, so yes I suppose in a way it is more efficient.

But mostly just because DOS is old, and modern languages have lots of code either built in or available online for dealing with Unix timestamps and
Julian day. The same isn't true for the old DOS packed time format.

The DOS packed date only can store 2 digit years and even number seconds, so it has a bunch of limitations too. Using Unix we're good until 2038 or if I ditch WinXP support we're good until pretty much eternity as far as dates go.

--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

I think that's great. I'd love to customize my bbs to look more like an older bbs with mystic under the hood.

I also think that if out spend the time meticulously updating prompts, then
you should keep a backup, and understand that IF you upgrade you may have to change prompts. This has always been an issue on bbsing.

I don't change my prompts for that very reason, except the menu prompt. I
know many folks do, and they have super customized systems. I suspect those users have to understand that the more customization, then all
The more chance an upgrade and mess up your customization. Put it in the upgrade.txt and don't stifle development of great ideas due to some people extremely modding their boards.

~Sorry guys who change prompts, you will have more work than others~

On 17:14 04/01 , g00r00 wrote:

On 01/05/18, Avon said the following...

I think this is a direction you have wanted to go for some time and suggest you follow your gut and do it for Mystic 1

I just might. :) There are several pros to doing it...

There are lots of times when I don't add something someone requests into Mystic
specifically because I would have to add or change prompts. Some people seem >to struggle with keeping those prompts updated. This new system only requires >them to be updated if a prompt they've personally customized changes... which >means they should have an idea where the prompt is and how to do it because >they've already done it once.

People who use the default prompt wouldn't have to do anything to upgrade, as >opposed to add new prompts or replacing existing prompts in the .txt files as >it works now.

It'll also allow new themes to be created more easily, and for people to >easily just "drop" a theme folder under \mystic\themes\ and it will show up >in their BBS instantly without any configuration...

This will promote people creating and sharing themes, and I would probably

do a

handful of themes just to mimic some of the more historically popular BBSes >like WildCat, Searchlight, Remote Access, Renegade, etc.

The same could work for themes that are used for other languages, too. Want to
add a Spanish theme? Download it and drop the "spanish" folder into >\mystic\themes and thats all you have to do.

The trick is in allowing people to store their data files on drives/dirs they want. Often this is to assist them in backing up stuff or just allocating storage resource (I'll run the BBS on C but store my data on D). So when it comes to messages / files I can see why people may want
to have this control.

You would still define the base message base path in System Configuration, but >the change would be that all of the JAM bases would be in the same directory. >It would no longer be configurable per-message-base.

I think the push-back I was getting is that people wanted to have certain >message base data files in different directories. Like to split them up by >network, although I don't know why that really matters.

--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

I understand the reasoning about file paths. I'm going to put my 2 cents in:

I enjoy putting all my other nets in different directories and am a little
anal about where things go, this makes me feel I have a hand on my system.

I have no care in the world to move my system to another OS, and if I did, I understand that those file areas paths will change.

I think worrying about OS transfer is the least of your worries, g00r00 but
I'm not trying to tell you how to develop. Out of all
Of us, how many people move back and forth between Linux windows and pi? If
in Mystic we can just reinstalll, drop data files and change paths. Or
Just areafix the messages and move
Files and mass upload with text dir.

I personally like being able to dictate where I store things. Things gives me control of my board. I hope you don't go take away my control to make a
mystic just do it all. It might be fine, but I like to create my own data directories.

I think it comes down to : who do you want to cater Mystic to? Experienced
bbs users or newbies? And I understand there might be things I'm not aware
of. I like the way it is.

On 17:16 04/01 , g00r00 wrote:

I wouldn't have a problem with all the message areas being located in a single message base path. But it would good if the base path could be specified.

Yep that is how it would work. If I remove it from message bases and add the >updated theme system for Mystic 2, then we'll be able to simply copy Mystic to >different directories and not have to reconfigure anything except file base >paths. (Or copy it from Windows to Linux to OSX without reconfiguring anything)

--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

G00r00,

I know I buck the system and propose things others don't. And I don't always agree. That's because I like and do some things differently, and it works
very well for me. I want to make sure my views are heard as others are.

I don't feel your current system is broken, and I feel it works great. Unless you have something you wish to add (besides moving to other platforms and
such) I see no reason to change.

If it's not broken why change or fix l. I might have missed a message on
this, so if I did I apologize


On 01:54 05/01 , Nugax wrote:

I understand the reasoning about file paths. I'm going to put my 2 cents in:

I enjoy putting all my other nets in different directories and am a little >anal about where things go, this makes me feel I have a hand on my system.

I have no care in the world to move my system to another OS, and if I did, I >understand that those file areas paths will change.

I think worrying about OS transfer is the least of your worries, g00r00 but >I'm not trying to tell you how to develop. Out of all
Of us, how many people move back and forth between Linux windows and pi? If >in Mystic we can just reinstalll, drop data files and change paths. Or
Just areafix the messages and move
Files and mass upload with text dir.

I personally like being able to dictate where I store things. Things gives me >control of my board. I hope you don't go take away my control to make a >mystic just do it all. It might be fine, but I like to create my own data >directories.

I think it comes down to : who do you want to cater Mystic to? Experienced >bbs users or newbies? And I understand there might be things I'm not aware >of. I like the way it is.

On 17:16 04/01 , g00r00 wrote:

I wouldn't have a problem with all the message areas being located in a >> JS> single message base path. But it would good if the base path could be
specified.

Yep that is how it would work. If I remove it from message bases and add the >>updated theme system for Mystic 2, then we'll be able to simply copy Mystic to
different directories and not have to reconfigure anything except file base >>paths. (Or copy it from Windows to Linux to OSX without reconfiguring >anything)

--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

My question is why in the world would I be copying an active mystic base all around a file system or multiple systems and oses without changing the paths myself?

This sounds like you catering to folks who play with mystic vs serious users who run Mystic for hub/live/production reasons. I've had a mystic bbs up for many years - up 24/7 and enjoy the control.

How often is this even an issue?? Makes no sense to me.



On 17:16 04/01 , g00r00 wrote:

I wouldn't have a problem with all the message areas being located in a single message base path. But it would good if the base path could be specified.

Yep that is how it would work. If I remove it from message bases and add the >updated theme system for Mystic 2, then we'll be able to simply copy Mystic to >different directories and not have to reconfigure anything except file base >paths. (Or copy it from Windows to Linux to OSX without reconfiguring anything)

--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

How about you give the user the option to contain all files in one area OR dictate paths as always. Wouldn't that solve this?? Maybe you can't.

On 02:03 05/01 , Nugax wrote:

My question is why in the world would I be copying an active mystic base all >around a file system or multiple systems and oses without changing the paths >myself?

This sounds like you catering to folks who play with mystic vs serious users >who run Mystic for hub/live/production reasons. I've had a mystic bbs up for >many years - up 24/7 and enjoy the control.

How often is this even an issue?? Makes no sense to me.

On 17:16 04/01 , g00r00 wrote:

I wouldn't have a problem with all the message areas being located in a >> JS> single message base path. But it would good if the base path could be
specified.

Yep that is how it would work. If I remove it from message bases and add the >>updated theme system for Mystic 2, then we'll be able to simply copy Mystic to
different directories and not have to reconfigure anything except file base >>paths. (Or copy it from Windows to Linux to OSX without reconfiguring >anything)

--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

A39 will change a lot of records. So far I have made changes to users.dat, mbases.dat, and fbases.dat. DOS date format has been
converted to Unix or Julian day in many places. servers.dat will likely change. You'll no longer be able to access user passwords in any form, neither via data file or even view it as a SysOp. It will all be in the whatsnew for A39.

The thing about Passwords is understandable and a good choice... but why
change records like users.dat, fbases.dat and mbases.dat or the DOS time format? I am sure you have your reasons, but from my point of view is a lot of work to correct "crashed" MPL scripts, which with the new records will not function and even crash, while executing them.

I remember when i first installed Mystic that, even i found a lot of scripts from others, they didn't work at all, because in the newer versions, changes have been made, to functions or other stuff and those scripts were unusable, except if someone wrote a newer version for them, which it didn't happened.

I think, the same thing is going to happen again and even more changes to Themes, Prompts, MPL etc. will make Mystic "a lot of waisted time" thing, specially for those who got into the trouble to make many customizations to their systems. Maybe, this kind of "big stuff alterations" should be done or left for ver. 2? and keep 1.1x clean and simple as it is? Or keep 1.1x as it
is a increase its stability and stuff and throw all the new stuff to ver 2.

.----- --- -- -
| Another Droid BBS
: Telnet : andr01d.zapto.org:9999 [UTC 11:00 - 20:00]
. Contact : xqtr.xqtr@gmail.com

--- Mystic BBS v1.12 A38 2018/01/01 (Raspberry Pi/32)
* Origin: Another Droid BBS (21:1/111)

It may take a little longer than it has been for me to get the next pre-alpha build out because I am doing some data file changes and things like that.

Not a problem, now that I know, it's just a minor inconvenience.

Ray

National Incident Alerts
telnet://niabbs.com
www.nationalincidentalerts.com

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: NIA BBS (21:2/108)

I think that's great. I'd love to customize my bbs to look more like an older bbs with mystic under the hood.

Well you can already do that stuff, there wouldn't be really any functional change to the themes. Its just easier to build, update, and share them.

--- Mystic BBS v1.12 A39 2018/01/05 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

I enjoy putting all my other nets in different directories and am a
little anal about where things go, this makes me feel I have a hand on
my system.

Okay, let me pick your brain: Do you not feel the need to have file base data in their own directories per file base like you do message bases? If it is a concern why have you not pushed to have each file base datafile configurable to its own directory?

On a side note, I want to add a configurable directory for file base instead of lumping it into \data so you would gain some too. :) The proposed default:

\mystic\data\ < General data files
\mystic\data\mbase < JAM message base files
\mystic\data\fbase < filearea databases

There are other changes from Mystic2 that I would like to put into Mystic1 someday too:

All of the files you are allowed to edit (blacklists, default new user messages, etc) would all be moved to a control directory: \mystic\control\. This is so that everything you might edit is separated from the data files that you should NEVER touch.

In Mystic 2 there is also a single "work" directory and the node temp directories, semaphores, etc, all fall under it. Overall the structure is very very clean:

\mystic\work\1\
\mystic\work\semaphore\

When you do a directory of Mystic 2 you see a super clean directory
and file structure that I would love to see in Mystic 1:

mystic.exe
mystic.ini
\data
\themes
\control
\work
\logs

I know that is a lot of information, but ultimately, that is where I would
like to see things go.

I think worrying about OS transfer is the least of your worries, g00r00 but I'm not trying to tell you how to develop. Out of all
Of us, how many people move back and forth between Linux windows and pi? If in Mystic we can just reinstalll, drop data files and change paths. Or

I think its a lot more people than you expect. It was literally the first question I had to put into the FAQ on the Wiki because it was the number one asked question asked at the time.

I think the reason it was asked so much is because the ability to rent server space or to spend $35 on a Pi to run a BBS was a newer concept, and lots of people were experimenting with moving to one of those solutions over using their Desktop computers.

It isn't just about moving between OSes but also renaming directories. If you want to move your BBS from c:\mystic to c:\mybbs or c:\Users\home then you have to reconfigure every single path, theme, message base, file base, etc.

I personally like being able to dictate where I store things. Things
gives me control of my board. I hope you don't go take away my control
to make a mystic just do it all. It might be fine, but I like to create
my own data directories.

Well you don't really lose the ability to dictate where to store things, you lose the ability to define *per message base* where that particular message base data file is stored. Keep in mind that this is for data files that you should never see or touch...

I think it comes down to : who do you want to cater Mystic to?
Experienced bbs users or newbies? And I understand there might be things I'm not aware of. I like the way it is.

I would disagree that this is catering to newbies or power users. Power users are exactly who will be moving their BBS around, experimenting with Mystic on new OSes, etc. Newbies will do it less often, but will have a much easier path when they do. It benefits everyone from the newbie, to the power user, to the developers who need to test their mods on different platforms and move around often.

I would say that probably most BBS softwares don't allow you to define this per-message-base like Mystic does. Synchronet doesn't. WWIV doesn't. Wildcat doesn't. Renegade doesn't. VABBS doesn't. BBBS doesn't. PCBoard doesn't, etc. I don't think I ever saw anyone complaining that they can't do it.

Anyway I'll probably leave it alone for now because I have bigger fish to fry, but thanks for giving me your feedback. I do take everything into consideration! :)

--- Mystic BBS v1.12 A39 2018/01/05 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 01/05/18, g00r00 said the following...

I enjoy putting all my other nets in different directories and am a little anal about where things go, this makes me feel I have a hand o my system.

Okay, let me pick your brain: Do you not feel the need to have file base data in their own directories per file base like you do message bases?
If it is a concern why have you not pushed to have each file base
datafile configurable to its own directory?

On a side note, I want to add a configurable directory for file base instead of lumping it into \data so you would gain some too. :) The proposed default:

\mystic\data\ < General data files
\mystic\data\mbase < JAM message base files
\mystic\data\fbase < filearea databases

Been hopeful for this for those of us with mass amounts of either really this will help us de-clutter the data folder a little more. I made a new folder /mystic/data/lang which is where my current languages are held for example.

In Mystic 2 there is also a single "work" directory and the node temp directories, semaphores, etc, all fall under it. Overall the structure
is very very clean:

\mystic\work\1\
\mystic\work\semaphore\

I actually changed the name and location of these to /mystic/data/sema. :)

I would like to be able to customize these even if there is a set field in
the future so the structure I did setup is not unused or gets placed differently then how I am used to having it.

Cheers!
Pequito

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: Twinkle BBS # (21:1/126)

The thing about Passwords is understandable and a good choice... but why change records like users.dat, fbases.dat and mbases.dat or the DOS time format? I am sure you have your reasons, but from my point of view is a lot of work to correct "crashed" MPL scripts, which with the new records will not function and even crash, while executing them.

Can you elaborate and tell me about the "lots of work" you have to keep doing to maintain MPL code? Can you explain to me why/which MPL will no longer work if I make record changes (of which I've done hundreds of times in Mystic's 20 year history and 3 times already in 1.12)?

To illustrate a point, I just copied the MPL from Mystic 1.10 alpha from 2011 into 1.12 A39 from today. I ran bulletins, blackjack, and usage graph and all are running fine in 1.12 straight from 1.10 (7 years old MPL code untouched)

Properly written MPL will work for the life of the engine with little to no changes. If you write poor MPL code, do things wrong, or do things you really shouldn't then thats on you. Or if you run someone else's code that falls into that category its on them. It's not a fault of Mystic or MPL.

I remember when i first installed Mystic that, even i found a lot of scripts from others, they didn't work at all, because in the newer versions, changes have been made, to functions or other stuff and those

There were two iterations of MPL: One from 1998 and then a revision in 2011. If you downloaded code from 1998 and try to use it with MPL from 2011 then yes, it will not compile (without mostly minor, well documented changes to syntax).

Do you also send e-mail to Microsoft because Windows 98 won't run Windows 10 apps? Do you download Windows 3.1 apps and complain because they don't run in Windows 7? That would be an equivalent timeline to what you're doing here. :P

I think, the same thing is going to happen again and even more changes to Themes, Prompts, MPL etc. will make Mystic "a lot of waisted time" thing, specially for those who got into the trouble to make many customizations to their systems. Maybe, this kind of "big stuff alterations" should be done or left for ver. 2? and keep 1.1x clean and simple as it is? Or
keep 1.1x as it is a increase its stability and stuff and throw all the

So let me take this and apply it to what is going on now:

You're suggesting that I no longer develop Mystic BBS features and instead you think I should consider developing two BBS packages now instead of one.

Rather than have IPV6, 4 year dates, seconds in timestamps, better timezone conversions, country information accessible in the BBS, an Echomail security system, built in E-mail validation/password reset, Internet e-mail integration, web server, and Python servers... you think that I should have scrapped all of it and feature locked Mystic because adding fields to a data file/changing a few fields to a new date format was too risky.

You are suggesting that a change to the theme system from Mystic 2 that *allows themes to be automatically updated and shared* while *requiring no configuration* will be way too much work for you to update and configure (lol).

If you seriously feel that Mystic is "a lot of wasted time" or heading in that direction, then I encourage you to find something else to use that doesn't change. Mystic has (and will continue) to change as seen fit. If you want something stale and stagnant then you are on the wrong train, sir! :)

I already put in more than 40 hours a week on Mystic and support on top of my own "real" 40+ hour a week full time job, so a second BBS package isn't realistic (although I have considered it).

You could always just not upgrade too.

--- Mystic BBS v1.12 A39 2018/01/05 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

I guess I really don't have any answer. You are right that filebases are all together.

The only thing i can think of, would be if my bbs crashed and I wanted to restore specific networks, the way inhave mine setup it would be easier than all in one area.

But I suppose nothing you said i have any counter point or don't agree with. And I do like the simplistic file structure. And you are right, I don't mess with the data files much so I doubt I'd probably even notice.

Either way, Mystic is getting better and I'm sure whatever you do will be thoughtfully done.


On 07:13 05/01 , g00r00 wrote:

I enjoy putting all my other nets in different directories and am a little anal about where things go, this makes me feel I have a hand on
my system.

Okay, let me pick your brain: Do you not feel the need to have file base data >in their own directories per file base like you do message bases? If it is a >concern why have you not pushed to have each file base datafile configurable to
its own directory?

On a side note, I want to add a configurable directory for file base instead of
lumping it into \data so you would gain some too. :) The proposed default:

\mystic\data\ < General data files
\mystic\data\mbase < JAM message base files
\mystic\data\fbase < filearea databases

There are other changes from Mystic2 that I would like to put into Mystic1 >someday too:

All of the files you are allowed to edit (blacklists, default new user >messages, etc) would all be moved to a control directory: \mystic\control\. >This is so that everything you might edit is separated from the data files that
you should NEVER touch.

In Mystic 2 there is also a single "work" directory and the node temp >directories, semaphores, etc, all fall under it. Overall the structure is very
very clean:

\mystic\work\1\
\mystic\work\semaphore\

When you do a directory of Mystic 2 you see a super clean directory
and file structure that I would love to see in Mystic 1:

mystic.exe
mystic.ini
\data
\themes
\control
\work
\logs

I know that is a lot of information, but ultimately, that is where I would >like to see things go.

I think worrying about OS transfer is the least of your worries, g00r00 but I'm not trying to tell you how to develop. Out of all
Of us, how many people move back and forth between Linux windows and pi? If in Mystic we can just reinstalll, drop data files and change paths. Or

I think its a lot more people than you expect. It was literally the first >question I had to put into the FAQ on the Wiki because it was the number one >asked question asked at the time.

I think the reason it was asked so much is because the ability to rent server >space or to spend $35 on a Pi to run a BBS was a newer concept, and lots of >people were experimenting with moving to one of those solutions over using >their Desktop computers.

It isn't just about moving between OSes but also renaming directories. If you >want to move your BBS from c:\mystic to c:\mybbs or c:\Users\home then you have
to reconfigure every single path, theme, message base, file base, etc.

I personally like being able to dictate where I store things. Things gives me control of my board. I hope you don't go take away my control
to make a mystic just do it all. It might be fine, but I like to create my own data directories.

Well you don't really lose the ability to dictate where to store things, you >lose the ability to define *per message base* where that particular message >base data file is stored. Keep in mind that this is for data files that you >should never see or touch...

I think it comes down to : who do you want to cater Mystic to? Experienced bbs users or newbies? And I understand there might be things I'm not aware of. I like the way it is.

I would disagree that this is catering to newbies or power users. Power users >are exactly who will be moving their BBS around, experimenting with Mystic on >new OSes, etc. Newbies will do it less often, but will have a much easier path
when they do. It benefits everyone from the newbie, to the power user, to the >developers who need to test their mods on different platforms and move around >often.

I would say that probably most BBS softwares don't allow you to define this >per-message-base like Mystic does. Synchronet doesn't. WWIV doesn't. Wildcat >doesn't. Renegade doesn't. VABBS doesn't. BBBS doesn't. PCBoard doesn't,

etc. I

don't think I ever saw anyone complaining that they can't do it.

Anyway I'll probably leave it alone for now because I have bigger fish to fry, >but thanks for giving me your feedback. I do take everything into >consideration! :)

--- Mystic BBS v1.12 A39 2018/01/05 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

I agree-> declutter data. I'm getting more onboard the more I think about it.

Change is hard! :)

On 11:20 05/01 , Pequito wrote:

On 01/05/18, g00r00 said the following...

I enjoy putting all my other nets in different directories and am a little anal about where things go, this makes me feel I have a

hand o

my system.

Okay, let me pick your brain: Do you not feel the need to have file base data in their own directories per file base like you do message bases? If it is a concern why have you not pushed to have each file base datafile configurable to its own directory?

On a side note, I want to add a configurable directory for file base instead of lumping it into \data so you would gain some too. :) The proposed default:

\mystic\data\ < General data files
\mystic\data\mbase < JAM message base files
\mystic\data\fbase < filearea databases

Been hopeful for this for those of us with mass amounts of either really this >will help us de-clutter the data folder a little more. I made a new folder >/mystic/data/lang which is where my current languages are held for example.

In Mystic 2 there is also a single "work" directory and the node temp directories, semaphores, etc, all fall under it. Overall the structure is very very clean:

\mystic\work\1\
\mystic\work\semaphore\

I actually changed the name and location of these to /mystic/data/sema. :)

I would like to be able to customize these even if there is a set field in >the future so the structure I did setup is not unused or gets placed >differently then how I am used to having it.

Cheers!
Pequito

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: Twinkle BBS # (21:1/126)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

On 01/05/18, g00r00 said the following...

\mystic\data\ < General data files
\mystic\data\mbase < JAM message base files
\mystic\data\fbase < filearea databases

I can get behind this. Occasionally you need to manipulate data files by hand and it's much easier to see what you have at a glance or find exactly which one you're looking for if it's at least organized into functions like this.

The main thing I like having a fine-grained directory structure for is the files in the file areas themselves, since the organization makes it easier to write scripts that operate on them or share them between different software packages without needing redundant copies.

On 01/05/18, NuSkooler said the following...

I enjoy putting all my other nets in different directories and am a little anal about where things go, this makes me feel I have a hand on my system.

I suppose that even though coordinators are careful there's always some risk of an echo name collision between networks if you have no segmentation.

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

On 01/05/18, g00r00 said the following...

I think worrying about OS transfer is the least of your worries, g00r but I'm not trying to tell you how to develop. Out of all
Of us, how many people move back and forth between Linux windows and If in Mystic we can just reinstalll, drop data files and change paths

I think its a lot more people than you expect. It was literally the
first question I had to put into the FAQ on the Wiki because it was the number one asked question asked at the time.

So much truth to this.

Sysops are tinkerers. Quite a few, including myself, have at least once moved their BBS setup from Linux to Windows, or Windows to Linux, or either of
those to a Raspberry Pi, etc.

Regards,
Nick

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

I am getting the feeling, that somehow i insult you or/and your work on
Mystic. That was not my intention. So, sorry for that. I am just expressing my concerns about Mystic and nothing more. I thought that this section/area of fsxnet is about that.

You sure are correct in what you are saying, but like i misunderstood you, you also misunderstood me and got it the wrong way. So i am not going to reply, cause i don't want to do things worse. Its your software, you can do as you please.

You're suggesting that I no longer develop Mystic BBS features and
instead you think I should consider developing two BBS packages now instead of one.

I thought that you are doing exactly that. Now and then i am reading about
a version 2, with lots of changes and stuff... :( confused again.

.----- --- -- -
| Another Droid BBS
: Telnet : andr01d.zapto.org:9999 [UTC 11:00 - 20:00]
. Contact : xqtr.xqtr@gmail.com

--- Mystic BBS v1.12 A38 2018/01/01 (Raspberry Pi/32)
* Origin: Another Droid BBS (21:1/111)

Hello g00r00!

04 Jan 18 23:16, you wrote to me:

Yep that is how it would work. If I remove it from message bases and
add the updated theme system for Mystic 2, then we'll be able to
simply copy Mystic to different directories and not have to
reconfigure anything except file base paths. (Or copy it from Windows
to Linux to OSX without reconfiguring anything)

Yeah, I have moved both Mystic and BBBS from one one OS based PC to another before and can be a task to change all the differant paths. Not long ago I moved Mystic from one Lin64 PC to another Lin64 PC. The only real change was the
root path change from /home/bbs/mystic to /home/mystic. That change involved more work as Mystic install aborts if the root mystic directory already exists. I hade to install Mystic to /home/mystic before adding "Mystic" as a Linux user.
It would be usefull to some if Mystic install would allow the use of a pre-existing
and occupied mystic directory and require confirmation to use the existing directory and upon confirmation only overwrite existing executables.

An alternative would be to allow the manual extraction of just the executables so
that an existing Mystic install can be updated.

I understand and realize that this these possibilities can have negative results
if misused. But alas, a sysop can screw things up regardless of how bullet proof
an install process is. And I certainly include myself in that group. :-)

Jeff


--- GoldED+/LNX 1.1.5-b20170303 / Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: The Ouijaboard II - Anoka, MN (21:1/128)

Hello g00r00!

On a side note, I want to add a configurable directory for file base

instead of lumping it into \data so you would gain some too. :) The proposed default:

\mystic\data\ < General data files
\mystic\data\mbase < JAM message base files
\mystic\data\fbase < filearea databases

I like the idea of keeping things separate.

All of the files you are allowed to edit (blacklists, default new user messages, etc) would all be moved to a control directory: \mystic\control\. This is so that everything you might edit is
separated from the data files that you should NEVER touch.

I initially spent some time when first installing Mystic to see where files were located and what their specific purpose was. AND what was editable by me.

Having things separate helps us with knowing where things are and what not touch.

In Mystic 2 there is also a single "work" directory and the node temp directories, semaphores, etc, all fall under it. Overall the
structure is very very clean:

\mystic\work\1\
\mystic\work\semaphore\

mystic.exe
mystic.ini
\data
\themes
\control
\work
\logs

That is an arangement that I have already gotten used to and one that
I prefer.

I think the reason it was asked so much is because the ability to rent server space or to spend $35 on a Pi to run a BBS was a newer concept,
and lots of people were experimenting with moving to one of those solutions over using their Desktop computers.

I have always prefered in-house PC's. At one time I had Mystic installed
on four PC's using Linux64, Win32/64, and Pi3. I have since scaled back
to just Lin64 and Pi3 installs of Mystic. As will as a Lin64 install of
BBBS.

It isn't just about moving between OSes but also renaming directories.
If you want to move your BBS from c:\mystic to c:\mybbs or
c:\Users\home then you have to reconfigure every single path, theme, message base, file base, etc.

Been there and done that several times. Where possible I like to write
bash scripts to change/move files and paths whenever possible. That is why recently inquired about some changes to the Mystic install process.

I would disagree that this is catering to newbies or power users.
Power users are exactly who will be moving their BBS around,
experimenting with Mystic on new OSes, etc. Newbies will do it less often, but will have a much easier path when they do. It benefits everyone from the newbie, to the power user, to the developers who
need to test their mods on different platforms and move around often.

I think it is a good idea to make the install process simple and straight forward for the first time installer. But at the same time make available options for the experienced installer who needs/wishes to install Mystic
their way.

Anyway I'll probably leave it alone for now because I have bigger fish
to fry, but thanks for giving me your feedback. I do take everything
into consideration! :)

That's all that we can ask. :-)

Jeff


--- GoldED+/LNX 1.1.5-b20170303 / Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: The Ouijaboard II - Anoka, MN (21:1/128)

The main thing I like having a fine-grained directory structure for is
the files in the file areas themselves, since the organization makes it

This will remain the same so you should have no worries there.

--- Mystic BBS v1.12 A39 2018/01/06 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

I am getting the feeling, that somehow i insult you or/and your work on Mystic. That was not my intention. So, sorry for that. I am just

Some of it I found a bit insulting at the time, but I still think I probably owe you an apologize for my response. I had gotten a few different responses criticizing some things yesterday and I admit I was a bit annoyed before I even started to read your message. I haven't gone back and read it but there is no doubt that it showed through and I apologize for that.

--- Mystic BBS v1.12 A39 2018/01/06 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Been there and done that several times. Where possible I like to write bash scripts to change/move files and paths whenever possible. That is
why recently inquired about some changes to the Mystic install process.

Yep, sorry I know I haven't given you a good response yet and I know you've mentioned it a few times...

Rest assured I do hear you and I am planning to do something from the command line that will do a copy-over using the installation program. Something like:

./install replace /mystic/

And it will replace all of the binaries with the newer binaries. I am hesitant to use the word "upgrade" here because it will then make people think they can just run that and be done with it.

But once that is done I want to keep moving closer and closer to fully automated upgrades. I have a hit list in mind to do that eventually but
there are certain things I really need to change first.

--- Mystic BBS v1.12 A39 2018/01/06 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Hello g00r00!

That is why recently inquired about some changes to the
Mystic install process.

Rest assured I do hear you and I am planning to do something from the command line that will do a copy-over using the installation program. Something like:

./install replace /mystic/

That would be way cool. I realize that this situation seemed more important during the rather frequent updates that we were having for a time. But I
still think it is a usefull ability of the install program.

But once that is done I want to keep moving closer and closer to fully automated upgrades. I have a hit list in mind to do that eventually
but there are certain things I really need to change first.

And I certainly understand that there are more important items that need attention first. I appreciate your willingness to listen and consider the little things.

When I first installed Mystic I did so with no particular intent keep it
around for too long. But based on what I have seen in Mystic AND your
your willingness and ability to listen and respond to the users of your software. I see myself staying with Mystic for some time to come.


Jeff


--- GoldED+/LNX 1.1.5-b20170303 / Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: The Ouijaboard II - Anoka, MN (21:1/128)

./install replace /mystic/

That would be way cool. I realize that this situation seemed more important during the rather frequent updates that we were having for a time. But I still think it is a usefull ability of the install program.

One of the EXTREMELY annoying things is that Windows seems to do something with install.exe that is preventing command line options from being passed to it.

This is the reason you don't have this feature right now.

I have it working in Linux, so maybe I'll just include it in A39 anyway even though Windows users will likely not be able to use it.

--- Mystic BBS v1.12 A39 2018/01/06 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Hello g00r00!

One of the EXTREMELY annoying things is that Windows seems to do
something with install.exe that is preventing command line options
from being passed to it.

Having used both for some time I can say that there are things that I like
and things that are annoying about both. Annoying things aside I prefer
Linux.

This is the reason you don't have this feature right now.

I understand the idea of keeping a level playing field.

I have it working in Linux, so maybe I'll just include it in A39
anyway even though Windows users will likely not be able to use it.

I would then reluctantly use it. :-)


Jeff


--- GoldED+/LNX 1.1.5-b20170303 / Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: The Ouijaboard II - Anoka, MN (21:1/128)

I'll use it

On 02:17 07/01 , Jeff Smith wrote:

Hello g00r00!

One of the EXTREMELY annoying things is that Windows seems to do something with install.exe that is preventing command line options
from being passed to it.

Having used both for some time I can say that there are things that I like >and things that are annoying about both. Annoying things aside I prefer >Linux.

This is the reason you don't have this feature right now.

I understand the idea of keeping a level playing field.

I have it working in Linux, so maybe I'll just include it in A39
anyway even though Windows users will likely not be able to use it.

I would then reluctantly use it. :-)

Jeff

--- GoldED+/LNX 1.1.5-b20170303 / Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: The Ouijaboard II - Anoka, MN (21:1/128)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A38 2018/01/01 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

g00r00 wrote to Jeff Smith <=-

Been there and done that several times. Where possible I like to write bash scripts to change/move files and paths whenever possible. That is
why recently inquired about some changes to the Mystic install process.

Yep, sorry I know I haven't given you a good response yet and I know you've mentioned it a few times...

Rest assured I do hear you and I am planning to do something from the command line that will do a copy-over using the installation program. Something like:

./install replace /mystic/

Hmm, looks like some changes to my "upgrade" script coming, because the script also manages the auto restart and backups. :)


... Red-shifted: The only way to travel ...
___ MultiMail/Win32 v0.49

--- Mystic BBS/QWK v1.12 A36 2017/12/04 (Raspberry Pi/32)
* Origin: The Bridge - bridge.vkradio.com (21:1/143)

On 01/04/18, g00r00 said the following...

I think the push-back I was getting is that people wanted to have certain message base data files in different directories. Like to split them up by network, although I don't know why that really matters.

There is also the issue of disk format. There are limits to the number of
files in one directory. This was worse in the past, but fat32 is still with
us and has limits. Some people have thousands of news groups and they won't
fit in one directory. Standards could still be set, but there may have to be
a way to split them up somehow (which could be automatic based on disk
format).

--- Mystic BBS v1.12 A38 2018/01/01 (Raspberry Pi/32)
* Origin: Mystic Pi BBS bcw142.zapto.org (21:1/145)

I think the push-back I was getting is that people wanted to have cer message base data files in different directories. Like to split them by network, although I don't know why that really matters.

There is also the issue of disk format. There are limits to the number of files in one directory. This was worse in the past, but fat32 is still

There is a limit of 65,535 files in FAT32, but outside of USB thumbdrives, no operating system really uses FAT32.

NTFS and ext3+ do not have these issues, only a limit to how many files you
can have on the disk itself (I think its 4 billion).

So I think we'll be safe with both Windows and Linux. Not sure what OSX uses really, but its probably ext3 or something that will also not have an issue.

--- Mystic BBS v1.12 A39 2018/01/08 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)