Which does the full restart of the BBS. It's a Pi3 so it's not as fast
as the current stuff which is why the 20 second sleep, It tended to fail if I did less waiting on my system. On my PC I can get away with sleep
10 there.

Wow, interesting. I have thought of creating a second node with a RPi. but it will have to wait till i get the main one built to what i want.

Thanks
- Gamecube Buddy

telnet --<{bbs.hive32.com:23333}>--

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Hive32 (21:4/129)

On 19 Apr 2021, gcubebuddy said the following...

Wow, interesting. I have thought of creating a second node with a RPi.
but it will have to wait till i get the main one built to what i want.

You'll find RPi raspbian to be almost the same as Ubuntu and others so you
can generally copy the file structure over and then install the RPi version
of the executables over that and it should be up and running. It's much the same as an upgrade between Mystic versions. That works both ways, you do the same to go from RPi to PC Linux. Windows takes more work, but much of the
paths and things are designed to be compatible within Mystic and many
commands are aliased within Mystic-DOS. I tend to further alias Windows, DOS and Linux commands in .bashrc and such so the shells are much the same as
well. You'll find many people do which is why Mystic-DOS is like that as well,

--- Mystic BBS v1.12 A47 2021/04/08 (Raspberry Pi/32)
* Origin: Mystic Pi BBS bcw142.zapto.org:23 (21:1/145)

You'll find RPi raspbian to be almost the same as Ubuntu and others so
you can generally copy the file structure over and then install the RPi version of the executables over that and it should be up and running.
It's much the same as an upgrade between Mystic versions. That works

wow cool! that would make it alot easyer to make a 2nd node with RPi. i will have to look more at that in the future, once i get the core of the BBS to my liking.

Thanks
- Gamecube Buddy

telnet --<{bbs.hive32.com:23333}>--

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Hive32 (21:4/129)

Your fine to wait for a real release. Your pretty new to Mystic so fighting through Alphas may not be for you. You'll notice even Avon doesn't update all or even most of the servers. I'm still having issues, but it's not the semaphores anymore, it's the Events. I'm likely doing something to hang the system in the Events. I have my Bot running via cron which is working fine
for now. That's always been my fall back in these positions.

I have a !I in the Message menu to force incoming messages to be processed
by anyone on the BBS. I've found !O isn't really needed - that works all the time (outgoing messages the semaphore handles fine).

So, bottom line - stick to releases for now. Alpha's aren't for everyone ;)

--- Mystic BBS v1.12 A47 2021/04/08 (Raspberry Pi/32)
* Origin: Mystic Pi BBS bcw142.zapto.org:23 (21:1/145)

doesn't update all or even most of the servers. I'm still having issues, but it's not the semaphores anymore, it's the Events. I'm likely doing something to hang the system in the Events. I have my Bot running via

Ya i have noticed something like that happening on my system. what is even weirder, is on my DEV system which is a complete VM clone on my PROD system,
i tried to disable the events so the DEV one wont keep polling the other
BBSs. however when i close down the mystic -cfg, and go back in, the events reappear as active again. so weird lol. for a while i was having issues in my PROD system not polling at all, but when i looked in the events, i saw it was trying to use the wrong / old script to poll with. i finally got that one fixed. it did take some tinkering with it though a few times. i noticed the same issue in my PROD system as well. after saveing and closing out of the modified event, when i return back in, the even reappears as it was
originally written before i modified it... i though i was maybe saving it
wrong or something....

Thanks
- Gamecube Buddy

telnet --<{bbs.hive32.com:23333}>--

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
* Origin: Hive32 (21:4/129)

Hello gcubebuddy!

On 16 Apr 2021, gcubebuddy said the following...

polling the other BBSs. however when i close down the mystic -cfg, and
go back in, the events reappear as active again. so weird lol. for a

I've also had this happen (kind of) -- modifying a command line of an event and then later finding out that the change had reverted itself. But it doesn't happen all the time so it's hard to pinpoint what could be causing it...

Best regards
Zip

--- Mystic BBS v1.12 A47 2021/04/08 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

On 16 Apr 2021, gcubebuddy said the following...

Ya i have noticed something like that happening on my system. what is
even weirder, is on my DEV system which is a complete VM clone on my
PROD system, i tried to disable the events so the DEV one wont keep polling the other BBSs. however when i close down the mystic -cfg, and
go back in, the events reappear as active again. so weird lol. for a
while i was having issues in my PROD system not polling at all, but when
i looked in the events, i saw it was trying to use the wrong / old
script to poll with. i finally got that one fixed. it did take some tinkering with it though a few times. i noticed the same issue in my
PROD system as well. after saveing and closing out of the modified
event, when i return back in, the even reappears as it was originally written before i modified it... i though i was maybe saving it wrong or something....

It may be we have to restart when we make changes to the Events, like we do
for the servers. It may be running the old setup till we restart. In my case with Raspbian I use:

#!/bin/bash
# restart mis
cd /mystic
sudo ./mis shutdown ; sleep 20 ; sudo ./mis daemon

Which does the full restart of the BBS. It's a Pi3 so it's not as fast as the current stuff which is why the 20 second sleep, It tended to fail if I did less waiting on my system. On my PC I can get away with sleep 10 there.

--- Mystic BBS v1.12 A47 2021/04/08 (Raspberry Pi/32)
* Origin: Mystic Pi BBS bcw142.zapto.org:23 (21:1/145)