Hey all,

I'm having a couple issues with InterBBS Last Callers from xqtr.

Everything is installed correctly and any user log in data is being pushed
out to the correct echonode.

When I try to run the wall it's throwing up the following Python error:

"for ibbs in bbses: TypeError; 'NoneType' object is not iterable"

the error is in line 307.

Does this sounds familiar to anyone?

Cheers!

... It's all about the subculture, man!

--- Mystic BBS v1.12 A48 (Windows/64)
* Origin: Retro32 BBS (21:1/215)

"for ibbs in bbses: TypeError;
'NoneType' object is not iterable"

the error is in line 307.

Does this sounds familiar to
anyone?

I don't use this mod myself, but I seem to remember something about it not liking when messages are missing a field. If I remember right, there's no error checking so the whole thing blows up when it comes a cross a message that doesn't have all fields filled in.

Checking my last callers, there's a a few from the past week that are missing the BBS address field. That might be what's doing it.

Someone more familiar with the exact mod might be able to help with a fix. (Possibly just throwing a try/catch around it and skipping any failed messages...)

Hope this helps!


--- NE BBS v1.10 (linux; x64)
* Origin: NE BBS - nebbs.servehttp.com:9223 (21:3/193)

Someone more familiar with the exact mod might be able to help with a fix. (Possibly just throwing a try/catch around it and skipping any failed messages...)

Handling the exceptions, is not always the preferred way. If you catch that exception then no one, will know that a BBS is "injecting" wrong or even corrupted data packets into the feed/echomail, perhaps multiple BBSes. If this continues for some time and more and more BBSes don't report correctly, then the mod would be useless.

Another solution, would be to create a log, but i don't think that many people would look into that. :)

It's preferred to check the FSX_DAT or any other echonet area that handles the data packets (for FSX, is FSX_DAT) for corrupted messages or a wrong set up BBSes and report to the BBS sysop or a FSX admin.

To bypass the problem, just delete the FSX_DAT.* files, which will erase all messages, along with the corrupted ones ;) The echonet, will be re-created when it receives new messages.

.
:: XQTR :: Another Droid BBS :: andr01d.zapto.org:9999 :: xqtr@gmx.com

--- Mystic BBS v1.12 A47 2020/11/23 (Raspberry Pi/32)
* Origin: Another Droid BBS # andr01d.zapto.org:9999 (21:1/111)

Re: Re: InterBBS Last Callers
By: xqtr to slacker on Tue Jul 15 2025 03:45 pm

Another solution, would be to create a log, but i don't think that many people would look into that. :)

You underestimate sysops. Plenty know to check logs for errors, and do.

It's preferred to check the FSX_DAT or any other echonet area that handles the data packets (for FSX, is FSX_DAT) for corrupted messages or a wrong set up BBSes and report to the BBS sysop or a FSX admin.

No disrespect, but no. It's not fsxNet's fault that the script is failing to process a message. The script should be more fault-tolerant of unexpected scenarios like the one described here, and handle it gracefully.

To bypass the problem, just delete the FSX_DAT.* files, which will erase all messages, along with the corrupted ones ;) The echonet, will be re-created when it receives new messages.

This gets around the current problem at hand, sure. But only until it re-surfaces. Then the sysop (in fact, all sysops who use this script) will inevitably find themselves in the same situation again.

The script needs to be fault-tolerant.

|15 þ ù ú codefenix ú ù ú ConstructiveChaos BBS ú ú ù þ þ
|08 þ þ ù (https/telnet/ssh)://conchaos.synchro.net ú ù þ
|07
--- SBBSecho 3.28-Win32
* Origin: -=[conchaos.synchro.net | ConstructiveChaos BBS]=- (21:4/141)

You underestimate sysops. Plenty know to check logs for errors, and do.

I don't under/over estimate no one. It's not about if they know, which i think it's obvious they do, cause setting a BBS in a Linux/Windows machine, is not for an amature... but if they do or have the time and will to do, to debug something.

Personal speaking, i am not even logging to my BBS daily, about once per two-three days and even then, i don't check logs, unless something went wrong.

No disrespect, but no. It's not fsxNet's fault that the script is faili cess a message. The script should be more fault-tolerant of unexpected sce
like the one described here, and handle it gracefully.

I never said that. For the second time in the same post you imply things that i haven't said... don't try to tell others, what i think. Just tell your opinion on the subject.

Of course it's not the fsx/zero/arak net error. The mod uses an echoarea just for data transfer. The "obligation" for the data to be correct is of the sysop that sets it up, to his BBS. And even then, we can't accuse anyone, that did something deliberately. Something may was misunderstood or was setup by mistake... mistakes happen.

This gets around the current problem at hand, sure. But only until it r
s. Then the sysop (in fact, all sysops who use this script) will inevitabl
themselves in the same situation again.|07

Yes and when it happen again, anyone will know and contact the BBS that "caused" it and will be fixed immediately, cause it affects the mod and data transfer for it ;)

The script needs to be fault-tolerant.

I explained my self earlier. "Hiding" network errors, meaning the corrupt or wrong packet messges, will just delay or not correct the problem at all.

Feel free to make a fork and apply any changes to the original mod/script. All of my mods are under GPL3 lic. and anyone is free to alter them in the way they think.

.
:: XQTR :: Another Droid BBS :: andr01d.zapto.org:9999 :: xqtr@gmx.com

--- Mystic BBS v1.12 A47 2020/11/23 (Raspberry Pi/32)
* Origin: Another Droid BBS # andr01d.zapto.org:9999 (21:1/111)

xqtr wrote to Codefenix <=-

You underestimate sysops. Plenty know to check logs for errors, and do.

I don't under/over estimate no one. It's not about if they know, which
i think it's obvious they do, cause setting a BBS in a Linux/Windows machine, is not for an amature... but if they do or have the time and
will to do, to debug something.

Personal speaking, i am not even logging to my BBS daily, about once
per two-three days and even then, i don't check logs, unless something went wrong.

But.... how would you know if anything went wrong, without checking
logs? I check mine multiple times per day, and have caught problems
early because of following logs. Stuff like a netmail stuck in an
endless loop or something.

IMHO any sysop should be checking things at least daily.



... All the easy problems have been solved.
=== MultiMail/Linux v0.52
--- SBBSecho 3.28-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (21:2/138)

Hey slacker,

Thanks for responding.

I don't use this mod myself, but I seem to remember something about it
not liking when messages are missing a field.

I had another play around with it (after your response) and I did notice a missing quotation in one of the scripts and one of the other scripts hadn't copied to the server properly, so it was never going to work. :)

I still have a couple of queries, so I'll lay them out here.

I have the xq-ilc_send running at login and this is exporting fine. The main prog script is set up at the main menu but I'm unsure where to call the xq-ilc_get script. The docs lack a little clarity here, as it says the "get" script needs to be called before executing the main script but doesn't
exactly state where it goes.

Thanks.

... is this thing on??

--- Mystic BBS v1.12 A48 (Windows/64)
* Origin: Retro32 BBS (21:1/215)

Just to jump in again on this....

The initial issues I was having with the mod, was basically down to me installing v2.0 then somehow coming back to it and adding files from an earlier version? How the hell I managed this, I do not know. :/

Anyhoo, I wiped everything out and started again. So far the mod is sending
out user log in info to FSX-DAT correctly but it's totally locking up the BBS when I try to run it from the menu. I emailed xqtr about this and he made a few sugesstions but I'm still trying to locate the issue. I'm not getting
any error messages in the logs, apart from the forced shutdown when the BBS crashes.

There is something in the script that my Win version of Mystic isn't liking
but my Python installation and file paths are fine, so it must be something else.

Any other Win Mystic based Sysops in here running the iBBS Last Callers mod?

Cheers!

... Alert!!! No tagline detected...

--- Mystic BBS v1.12 A48 (Windows/64)
* Origin: Retro32 BBS (21:1/215)

I have the xq-ilc_send running at login and this is exporting fine. The ma prog script is set up at the main menu but I'm unsure where to call the xq-ilc_get script. The docs lack a little clarity here, as it says the "ge script needs to be called before executing the main script but doesn't exactly state where it goes.

This is an older version, the newest/currect is 2.0 and is written in MPY.

.
:: XQTR :: Another Droid BBS :: andr01d.zapto.org:9999 :: xqtr@gmx.com

--- Mystic BBS v1.12 A47 2020/11/23 (Raspberry Pi/32)
* Origin: Another Droid BBS # andr01d.zapto.org:9999 (21:1/111)

But.... how would you know if anything went wrong, without checking
logs? I check mine multiple times per day, and have caught problems

There are logs, the ones Mystic uses which will inform you about something went wrong.

The thing is... this mod, will crash for two reasons. The first one is corrupted message base and the second, is a wrong packet? perhaps... i haven't encountered something like that. In all cases, i have encountered, the script was crashing, the message base, because it was corrupted.

This means, that at the end, you have to delete, reindex, echofix that message base, cause you will experience also, other problems/crashes, if they didn't happen all ready.

The mod, is based on the message base to be healthy. If it doesn't, logging or not the problem, will not fix anything and the script can't say exactly if the message base is corrupted. You will only see a line of string, saying, error processing message no xxxxx.

It's nothing for me to put some exception handling around the code, but i don't think it will have the results you expect. You will see the mod working, actually not crashing... but the data wont populate, as it wouldn't read new packets, because of the message base corruption.

.
:: XQTR :: Another Droid BBS :: andr01d.zapto.org:9999 :: xqtr@gmx.com

--- Mystic BBS v1.12 A47 2020/11/23 (Raspberry Pi/32)
* Origin: Another Droid BBS # andr01d.zapto.org:9999 (21:1/111)