In A46 I can thinking about changing the TEMP directory system and I wanted to mention it before I do it because it could affect a some people who have doors setup using those paths hardcoded into their scripts, or maybe some custom MPL programs.

The current system is that temp directories are made in the root directory of Mystic (ie: C:\MYSTIC\TEMP1, C:\MYSTIC\TEMP2). I did it this way just because Renegade did it that way and it would be familiar, but secretly I think its sloppy and it bothers me.

What I would like to do is have it create a single TEMP (or maybe WORK) directory and then subdirectories off of that, so you only end up with one folder off the root Mystic directory. IE:

C:\MYSTIC\TEMP\1\
C:\MYSTIC\TEMP\2\

There is no real reason to change it other than to neaten up the directory structure, so if people oppose it then its highly probable that I won't do it.

--- Mystic BBS v1.12 A45 2020/02/15 (Windows/64)
* Origin: Sector 7 (21:1/108)

I "Personally" would rather it stay the same as it is...

Since it relates only to the number of "Nodes" being run as well as where
Drop Files are placed for doors, most people don't run a ton of Nodes on their BBS. I've maxed mine out to 8, but Rarely ever get more than 2 people on at any given time so the structure is not messy for my preferences...

You can do what you want... My personal preference would be to keep it as-is, but as I said... it's your call.

Gary Crunk
Another F-ing BBS
Quazar BBS Door Game Server
300 F-ing Baud BBS

Gary Crunk - Another F-ing BBS : anotherbbs.dynu.net Port 23
Quazar BBS Door Game Server: quazarbbs.dynu.net Port 2323
300 F-ing Baud BBS: 300baud.dynu.net Port 2525

--- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
* Origin: Another F-ing BBS (21:4/126)

Re: A46 discussion: Mystic's TEMP path
By: g00r00 to All on Mon Feb 17 2020 10:28 pm

The current system is that temp directories are made in the root directory of Mystic (ie: C:\MYSTIC\TEMP1, C:\MYSTIC\TEMP2). I did it this way just because Renegade did it that way and it would be familiar, but secretly I think its sloppy and it bothers me.

I no longer run Mystic, but my 2c worth is that I agree and there is a better way.

What I would like to do is have it create a single TEMP (or maybe WORK) directory and then subdirectories off of that, so you only end up with one folder off the root Mystic directory. IE:

C:\MYSTIC\TEMP\1\

I think this is much better - that way, C:\MYSTIC\TEMP could be a mount to a "temp" filesystem - which for Windows might night be C:. For unix, it could be a ramdrive, etc.

For those running Mystic on a Pi, it definately makes sense that "temp" is a ramdrive, not the SD card..
...deon


... I'm going to make a prediction - it could go either way.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

You can do what you want... My personal preference would be to keep it as-is, but as I said... it's your call.

I appreciate the feedback, this is exactly what I am looking for :)

Since it relates only to the number of "Nodes" being run as well as where Drop Files are placed for doors, most people don't run a ton of Nodes on their BBS. I've maxed mine out to 8, but Rarely ever get more than 2 people on at any given time so the structure is not messy for my preferences...

Maybe part of my problem is that I do load tests where I will have 25 node BBS that gets hit with 25 connections per second type of thing, so I end up with TEMP0-25 plus all of the other TEMP directories used by other functions which end up being like 30 TEMP subdirectories.

I agree most BBSes aren't active enough to have those types of numbers, and even if they did its mostly just "cosmetic".

As far as drop files, there is a door MCI code that translates to the path that is the location of the drop files. Any doors set up using that (I think its %P) will not require any changes if the directories changed. Its only those who did not use %P and hard coded the node number into batch files that would see an issue with configurations.

Thank you again for the feedback. So far its one vote to leave it alone and
I will do so unless someone else responds otherwise.

--- Mystic BBS v1.12 A45 2020/02/17 (Windows/64)
* Origin: Sector 7 (21:1/108)

There is no real reason to change it other than to neaten up the
directory structure, so if people oppose it then its highly probable
that I won't do it.

I would have to redo 8x node settings on 60x doorgames. My vote is no, simply because it would add work for me, but I'm indifferent otherwise.

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: monterey bbs (21:1/168)

In A46 I can thinking about changing the TEMP directory system and I wanted to mention it before I do it because it could affect a some
people who have doors setup using those paths hardcoded into their scripts, or maybe some custom MPL programs.

My vote, for whatever it is worth ... yes. Please do -- or perhaps save it
for a "2.0" major release. Also, can we do something about file base data in the /data directory? Maybe handle them similar to the way message bases are done? That would tidy things up too.

-roovis

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: w0pr.win (21:4/165)

I would have to redo 8x node settings on 60x doorgames. My vote is no, simply because it would add work for me, but I'm indifferent otherwise.

I'm going to have to agree with ryan here, I have a shit load of dos door
games running under dosemu with the node path mapped to the temp folder structure for door.sys files.

It would be a pain, but doable to move if need be.

|15frank |08// |15netsurge
|07disksh0p|08!|07bbs |08% |07bbs.diskshop.ca |08% |07mystic goodness |11SciNet |03ftn hq |08% |07https://scinet-ftn.org

--- Mystic BBS v1.12 A45 2020/02/12 (Linux/64)
* Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (21:4/154)

I appreciate the feedback, this is exactly what I am looking for :)

Anytime...

Bottom Line is we will all deal with whatever method you choose. It's your call and it's not a big issue either way.

You rock!

Gary

Gary Crunk - Another F-ing BBS : anotherbbs.dynu.net Port 23
Quazar BBS Door Game Server: quazarbbs.dynu.net Port 2323
300 F-ing Baud BBS: 300baud.dynu.net Port 2525

--- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
* Origin: Another F-ing BBS (21:4/126)

Hello g00r00!

On 17 Feb 2020, g00r00 said the following...

What I would like to do is have it create a single TEMP (or maybe WORK) directory and then subdirectories off of that, so you only end up with
one folder off the root Mystic directory. IE:

Sounds great, I think!

On my machine, I keep config files and as much as possible on a network
share (except for the binaries). And I'd love to be able to point the "root" temp directory either to the network share or to a tmpfs file system, which would be really easy then.

Best regards
Zip

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

I would have to redo 8x node settings on 60x doorgames. My vote is no, simply because it would add work for me, but I'm indifferent otherwise.

I am guessing you don't use %P for the path to the door file? ;)

--- Mystic BBS v1.12 A45 2020/02/17 (Windows/64)
* Origin: Sector 7 (21:1/108)

My vote, for whatever it is worth ... yes. Please do -- or perhaps save
it for a "2.0" major release. Also, can we do something about file base data in the /data directory? Maybe handle them similar to the way
message bases are done? That would tidy things up too.

Maybe but if I did change it, it would probably not be like the message bases. The path in each message base is a pain point that prevents Mystic from being able to be copied between Windows and Linux without changing every single message base and potentially other configurations too. I want it gone but others wanted me to keep it.

The Mystic 2 demo you could rename your root Mystic BBS without any configuration updates and it just worked, and you could also copy it freely between Windows, Pi, Linux, whatever, and you didn't have to change any configuration. I wanted to do that for 1.x too but it involves minimizing the configurable paths like removing the per-base path.

What I wanted to do a while back was to have:

\MYSTIC\DATA All of the existing data files except msg/file bases \MYSTIC\DATA\FDB All of the file base data files
\MYSTIC\DATA\MDB All of the message base data files

But people really didn't want me to remove the "path" setting for each base even after I pointed out that we've never been able to set a path for file bases and no one has cared!

I think people are weary of changes at times though and once its done its not a big deal. I held back on the new theme system more than once because of general consensus before ultimately deciding to do it anyway, and everyone seems okay with it now that its done.

In general though, I do try to take direction on things like this from the "popular opinion" since I want people to ultimately be happy. So lets see if anyone else has an opinion here.

--- Mystic BBS v1.12 A45 2020/02/17 (Windows/64)
* Origin: Sector 7 (21:1/108)

I'm going to have to agree with ryan here, I have a shit load of dos door games running under dosemu with the node path mapped to the temp folder structure for door.sys files.

There are plenty of you who feel like it'd be a lot of rework so I will not be changing it!

There is a %P code that returns the path to the drop files that can eliminate much of the hardcode path stuff but I don't know how many people actually use it.

Along those lines I also want to add in "door profiles" at some point, but I think no one will actually use them since they'd have to redo their doors to
do it.

--- Mystic BBS v1.12 A45 2020/02/17 (Windows/64)
* Origin: Sector 7 (21:1/108)

Sounds great, I think! Zi>
On my machine, I keep config files and as much as possible on a network share (except for the binaries). And I'd love to be able to point the "root" temp directory either to the network share or to a tmpfs file system, which would be really easy then.

I am going to hold off on the change for now. It seems like people are kind of split as to whether or not I should do it.

Because the door drop files are created in those temp directories it can be a pain for people who already have a lot of doors set up.

I am thinking maybe in the future I will do a "door profile" system and as people start using that more, it would be a better time to make the TEMP directory change.

Thank you for the feedback!

--- Mystic BBS v1.12 A45 2020/02/17 (Windows/64)
* Origin: Sector 7 (21:1/108)

There is a %P code that returns the path to the drop files that can eliminate much of the hardcode path stuff but I don't know how many
people actually use it.

I do use it, the issue lies in all of the batch files that we use in dosemu, where a path needs to be lrdir's in dosemu. That is where all of the changes would need to happen. Can't use %P for that.

|15frank |08// |15netsurge
|07disksh0p|08!|07bbs |08% |07bbs.diskshop.ca |08% |07mystic goodness |11SciNet |03ftn hq |08% |07https://scinet-ftn.org

--- Mystic BBS v1.12 A45 2020/02/12 (Linux/64)
* Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (21:4/154)

What I wanted to do a while back was to have:

\MYSTIC\DATA All of the existing data files except msg/file bases \MYSTIC\DATA\FDB All of the file base data files
\MYSTIC\DATA\MDB All of the message base data files

This sounds really good. Like I said before, maybe save this kind of restructuring for "Mystic 2.0" and encourage people to start using dynamic variables in all of their door scripts/batch files. Maybe take a system and just copy it to a new Windows install, or a new Linux system and see what
edges crop up and see if all of that can become smoother to the point where
it almost (as much as Mystic can help it) is just a self-contained folder
that can be dropped and launched and still stay sane.

For those who would like a head start, maybe announce the "next step" so
people can start getting ready now -- how they can migrate to better paths
and maybe an extended testing period before 2.0 drops so SysOps can switch easier.

-roovis

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: w0pr.win (21:4/165)

I would have to redo 8x node settings on 60x doorgames. My vote is no simply because it would add work for me, but I'm indifferent otherwis

I am guessing you don't use %P for the path to the door file? ;)

A lot of games require specific config files for multinode setup. You certainly can't use %P in the dos config menus.

I have always operated under the impression the %P was only going to render on the first call out to the batch/shell script but I haven't tested this.

I too don't mind the proposed folder structure but would have 20-30 or so
doors that would all need reconfiguring. Some can be changed in the calling batch file, some require running the door games config utility, and some require editing a file like SRDOOR.1,SRDOOR.2 etc.

|07E|10m|07b|10a|07l|10m|07e|10d |12-----------------------------------------------------
|09Black Lodge Research BBS |11blacklodgeresearch.org:4022
|11fsx|08Net: |0721:4/166 |11sci|08Net: |0777:1/133

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: Black Lodge Research BBS (21:4/166)

There is a %P code that returns the path to the drop files that can eliminate much of the hardcode path stuff but I don't know how many people actually use it.

I do use it, the issue lies in all of the batch files that we use in dosemu, where a path needs to be lrdir's in dosemu. That is where all of the changes would need to happen. Can't use %P for that.

Ah yes, this too. I remember trying to use it on a Dosenu game and it pointed to /opt/mystic/temp1 and it needed D:/temp1

|07E|10m|07b|10a|07l|10m|07e|10d |12-----------------------------------------------------
|09Black Lodge Research BBS |11blacklodgeresearch.org:4022
|11fsx|08Net: |0721:4/166 |11sci|08Net: |0777:1/133

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: Black Lodge Research BBS (21:4/166)

There is a %P code that returns the path to the drop files that can eliminate much of the hardcode path stuff but I don't know how many people actually use it.

I do use it, the issue lies in all of the batch files that we use in dosemu, where a path needs to be lrdir's in dosemu. That is where all of the changes would need to happen. Can't use %P for that.

I see thank you for the clarification. Part of what I would like to do with having door profiles is to simplify stuff like that so Mystic can just generate whatever it needs to without having to create scripts.

I need to brush up on DOSEMU though its been many years since I set up a door using DOSEMU.

--- Mystic BBS v1.12 A45 2020/02/17 (Windows/64)
* Origin: Sector 7 (21:1/108)

\MYSTIC\DATA All of the existing data files except msg/file \MYSTIC\DATA\FDB All of the file base data files
\MYSTIC\DATA\MDB All of the message base data files

I like that idea for the FDB. I have wished the FDB was in it's own
place.

I think the message area config works great as it is. It's good in some
cases to have a separate directory per net. It works well when you have
like named areas (say, WINDOWS) in different nets.

I think a single directory could work if folks are sure to prefix
filenames, something like fsx-fsx_gen. Perhaps a directory per net in the
base config of each net so all messages for that net use \MYSTIC\DATA\MDB\FSXNET, or something similar.

I also like the TEMP directory change you presented. Although it will be
some work for existing setups, it may be the right thing to do going
forward.

Mystic is already quite simple to get online and maintain. It really
shines in this area so I have to support anything that builds on that.



Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

The current system is that temp directories are made in the root
directory of Mystic (ie: C:\MYSTIC\TEMP1, C:\MYSTIC\TEMP2). I did it
this way just because Renegade did it that way and it would be familiar, but secretly I think its sloppy and it bothers me.

What I would like to do is have it create a single TEMP (or maybe WORK) directory and then subdirectories off of that, so you only end up with
one folder off the root Mystic directory. IE:

C:\MYSTIC\TEMP\1\
C:\MYSTIC\TEMP\2\

A lot of my doors I configure in their setup where the door.sys files are located and I pass in batch file \mystic\temp%1 and would now require to
change them all to \mystic\temp\%1 Other than that I have no problem

On a different note, I for a while have been having a problem with mutil replacing dupe files even if I have it set to true. I changed in mystic cfg
in file base settings on Upload Dupe to Currrent and that didn't work so changed it to none. It. curiously happens to those files named
pasndlist.045 or pasnlist.z45 and stndlist.z45 (the number changes with each update. Log tells me it is a dupe as the only error.

Ruben Figueroa aka Zazz
Mystic Prison Board Sysop
telnet://pbmystic.rdfig.net:24
Web: www.rdfig.net

--- Mystic BBS v1.12 A45 2020/02/09 (Windows/32)
* Origin: Mystic Prison Board BBS*Mesquite Tx (21:1/134)

On a different note, I for a while have been having a problem with
mutil replacing dupe files even if I have it set to true. I
changed in mystic cfg in file base settings on Upload Dupe to
Currrent and that didn't work so changed it to none. It.
curiously happens to those files named pasndlist.045 or
pasnlist.z45 and stndlist.z45 (the number changes with each
update. Log tells me it is a dupe as the only error.

I don't have a solution but I am curious, do those tics have a line like "Replaces pasnlist.z45"?

Ttyl :-),
Al

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

On 18 Feb 2020, garycrunk said the following...

I "Personally" would rather it stay the same as it is...

I tend to agree with Gary. Mainly because of using hard-coded cfg files in doors.

-=>Richard Miles<=-
-=>Captain Obvious<=-
-=>bbs.shadowscope.com<=-

--- Mystic BBS v1.12 A45 2020/02/16 (Windows/32)
* Origin: Shadowscope BBS | bbs.shadowscope.com | Temple, GA (21:1/157)

On 17 Feb 2020, g00r00 said the following...

In A46 I can thinking about changing the TEMP directory system and I wanted to mention it before I do it because it could affect a some

How hard would it be to make that a configurable path?

-=>Richard Miles<=-
-=>Captain Obvious<=-
-=>bbs.shadowscope.com<=-

--- Mystic BBS v1.12 A45 2020/02/16 (Windows/32)
* Origin: Shadowscope BBS | bbs.shadowscope.com | Temple, GA (21:1/157)

On 18 Feb 2020, g00r00 said the following...

I am guessing you don't use %P for the path to the door file? ;)

A lot of older DOS stuff requires hard coded paths in the cfg files.

-=>Richard Miles<=-
-=>Captain Obvious<=-
-=>bbs.shadowscope.com<=-

--- Mystic BBS v1.12 A45 2020/02/16 (Windows/32)
* Origin: Shadowscope BBS | bbs.shadowscope.com | Temple, GA (21:1/157)

I am guessing you don't use %P for the path to the door file? ;)

A lot of older DOS stuff requires hard coded paths in the cfg files.

Yeah I know what you mean. I thin LORD worked that way where you had to physically go in and create a configuration for each node and hardcode a path to the drop files in it. It was really annoying if you were setting up like
a 12 node BBS or something.

--- Mystic BBS v1.12 A45 2020/02/17 (Windows/64)
* Origin: Sector 7 (21:1/108)

On 18 Feb 2020, Zip said the following...

On my machine, I keep config files and as much as possible on a network share (except for the binaries). And I'd love to be able to point the "root" temp directory either to the network share or to a tmpfs file system, which would be really easy then.

If there were a temp dir config option and the subfolder naming scheme
remained the same it could be done in a backwards compatible manner.
eg: /home/mystic/temp/temp1
For backwards compatibility just point it at the mystic directory itself and
it should behave as it already does.

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

path to the drop files in it. It was really annoying if you were
setting up like a 12 node BBS or something.

This (and other door games like it) is why i changed my mystic config from 20 connections to 5. Also I'm pretty sure I'll never have 20 people on at once either haha :)

Some of these the files are so basic you could probably just create the files on the fly in the batch file pointed at the proper directories but I was too lazy to set that up. Lord in particular uses those weird DAT files so that would be a pain, but some of the others just use a text file with the
dropfile location changed and everything else the same.

|07E|10m|07b|10a|07l|10m|07e|10d |12-----------------------------------------------------
|09Black Lodge Research BBS |11blacklodgeresearch.org:4022
|11fsx|08Net: |0721:4/166 |11sci|08Net: |0777:1/133

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: Black Lodge Research BBS (21:4/166)

On 02-17-20 22:28, g00r00 wrote to All <=-

In A46 I can thinking about changing the TEMP directory system and I wanted to mention it before I do it because it could affect a some
people who have doors setup using those paths hardcoded into their scripts, or maybe some custom MPL programs.

I currently don't do anything that would be affected, so I'm easy.


... If the polls are so accurate, why are there so many polling companies?
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 02-18-20 19:37, alter ego wrote to g00r00 <=-

I think this is much better - that way, C:\MYSTIC\TEMP could be a mount
to a "temp" filesystem - which for Windows might night be C:. For unix,
it could be a ramdrive, etc.

For those running Mystic on a Pi, it definately makes sense that "temp"
is a ramdrive, not the SD card..

Some good points which are swaying me in favour of the change.


... Maybe the dingo ate your avatar.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 02-18-20 11:48, Embalmed wrote to g00r00 <=-

I have always operated under the impression the %P was only going to render on the first call out to the batch/shell script but I haven't tested this.

That's easy to work around if that is the case, simply set a variable in the batch file with the value of %P. I always write my scripts to minimise the amount of manual configuration changes. Ideal is 0 (get from an external source or work it out on the fly - often possible with Linux shell scripts), next best is 1 - only have to change one variable and everything else falls into line.

I too don't mind the proposed folder structure but would have 20-30 or
so doors that would all need reconfiguring. Some can be changed in the calling batch file, some require running the door games config utility, and some require editing a file like SRDOOR.1,SRDOOR.2 etc.

I currently don't have any doors, and if I did, I'm sure I'd be able to sort it in my DOSBox or Qemu config.


... Remember to finish what you
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 02-18-20 12:22, Al wrote to g00r00 <=-

\MYSTIC\DATA All of the existing data files except msg/file \MYSTIC\DATA\FDB All of the file base data files
\MYSTIC\DATA\MDB All of the message base data files

I like that idea for the FDB. I have wished the FDB was in it's own
place.

I like this layout as well.

I think the message area config works great as it is. It's good in some cases to have a separate directory per net. It works well when you have like named areas (say, WINDOWS) in different nets.

I think a single directory could work if folks are sure to prefix filenames, something like fsx-fsx_gen. Perhaps a directory per net in
the base config of each net so all messages for that net use \MYSTIC\DATA\MDB\FSXNET, or something similar.

Have a configurable per-net prefix, like Synchronet does for its message (and file) groups. The prefix would then be pre-pended to the filenames for each messagebase. Problem solved. :)

I also like the TEMP directory change you presented. Although it will
be some work for existing setups, it may be the right thing to do going forward.

It is a better layout, and I sould consider mounting /mystic/temp on a RAMdisk.

Mystic is already quite simple to get online and maintain. It really shines in this area so I have to support anything that builds on that.

Agree.



... Opportunity: A favourable occasion for grasping a disappointment.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 18 Feb 2020, g00r00 said the following...

Maybe part of my problem is that I do load tests where I will have 25
node BBS that gets hit with 25 connections per second type of thing, so
I end up with TEMP0-25 plus all of the other TEMP directories used by other functions which end up being like 30 TEMP subdirectories.

I agree most BBSes aren't active enough to have those types of numbers, and even if they did its mostly just "cosmetic".

Here on CRBBS, I have it set for 10 nodes. Rarely do I think I ever need more than 3, but there have been times. :)

It is a cosmetic change, that would make sense, as it would clean up the directory structure.

As far as drop files, there is a door MCI code that translates to the
path that is the location of the drop files. Any doors set up using
that (I think its %P) will not require any changes if the directories changed. Its only those who did not use %P and hard coded the node
number into batch files that would see an issue with configurations.

I fall into both camps on doors. I have some that are using the %P and some that are hard coded into the batch files. :)

As for my vote, I would say it's up to you. I wouldn't be upset if you didn't change the /temp directories, and if you do, I can get off my butt and change the doors that are hard coded. :)

I know, not much help... ;)


---

Black Panther(RCS)
Castle Rock BBS

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)

On 18 Feb 2020, g00r00 said the following...

Yeah I know what you mean. I thin LORD worked that way where you had to physically go in and create a configuration for each node and hardcode a

Heh. I literally just finished setting LORD up for ten nodes not five minutes ago. Probably could get away with 2 or 3 at the most but I prefer to keep my board on port 23 so at times it's entirely possible to be logged into a
higher node.

-=>Richard Miles<=-
-=>Captain Obvious<=-
-=>bbs.shadowscope.com<=-

--- Mystic BBS v1.12 A45 2020/02/16 (Windows/32)
* Origin: Shadowscope BBS | bbs.shadowscope.com | Temple, GA (21:1/157)

Hello Static (& g00r00)!

On 18 Feb 2020, Static said the following...

If there were a temp dir config option and the subfolder naming scheme remained the same it could be done in a backwards compatible manner.
eg: /home/mystic/temp/temp1
For backwards compatibility just point it at the mystic directory itself and it should behave as it already does.

I agree! Sounds like a good solution that would keep everyone happy! =)

Best regards
Zip

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

I am guessing you don't use %P for the path to the door file? ;)

A lot of doors need it hardcoded in their configs. Additionally I run most doors in dosemu, with E:\ mapped to my mystic dir, do most doors have a hardcoded node 1 = E:\TEMP1\DOOR.SYS type thing.

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: monterey bbs (21:1/168)

pasnlist.z45 and stndlist.z45 (the number changes with each
update. Log tells me it is a dupe as the only error.

I don't have a solution but I am curious, do those tics have a line like "Replaces pasnlist.z45"?

Ttyl :-),
Al

I did check that and the word replaces is in the tic file

Ruben Figueroa aka Zazz
Mystic Prison Board Sysop
telnet://pbmystic.rdfig.net:24
Web: www.rdfig.net

--- Mystic BBS v1.12 A45 2020/02/09 (Windows/32)
* Origin: Mystic Prison Board BBS*Mesquite Tx (21:1/134)