Well the
upgrade from 1.10 to 1.11a1 went flawless. VR# correct, script all
works as expected. You already know that quoting messages with ANS is a no-g o.Other thing that i've noticed is that when I had multi.ini
import a massupload of the weekly filebase, it found all of
the files, including themystic_1.11 files. But, it it NOT i
mport any file_id.diz for them. When Iremotely connected and
[V]iew file it would show them all so usual. The DIZ wasthe
re! Hitting [E]dit on the file showed me the normal mystic file edito
r but[I]mport DIZ looked like it tried and failed. Plus [!]
Discription edit alsofailed to edit the NO Discription with
the file editor either. So I camnolonger import DIZ or edit
any discription in 1.11.1 Also if I edit thismessages 3 time
s because the spelling errors, I get 3 Origin: lines added.O
ne for each time i saves the same message. Then I need to edit out th
e dupeorigin: lines ;)Skuz d
A FlupHy Squirrel ate my nuts...
. ▄▄▓▒▀▐▄▌ ▐▄▄ ▄▓▐▓▄▄ ▄▌ ░▄ ▌ 09! @
b7 member board▐▓▄▄▄ ▐▓ ▄▐▓▌ ▐▓▌▐
▌▐▓▌░▄▄▓▌ ▄▄▐▓▌ ▀▀▓▄▓▌▀█▄▓▌▐▓▌▀▀ ▐▓▌▐▓▌▓▌@
http://bbsnexus.com/fluph --- Mysti
c BBS v1.11 A1 (Windows) * Origin: fluph.darktech.org
(46:1/102)
--- FastEcho 1.46a
* Origin: flupH - fluph.darktech.org (46:1/102)

One other thing to note when importing file areas, aka new via MULTI seems to fail now and always expect FILEBONE.NA outside the name provided in the
config.

--- Mystic BBS v1.11 A1 (Windows)
* Origin: Twinkle BBS [Albuquerque, NM] (46:1/167)

I also noticed that if the echo area had allow ANSI turn on like my last report. My GoldEd show the post with embedded ANSI code. So iI turned it off for AGN_DEV ;)

|15S|07kuz |18|00 dA |16|02 FlupHy|16|15 S|07quirrel ate my nuts|15.|07..|08. |05 ▄▄▓▒▀▐▄▌ ▐▄▄ ▄▓▐▓▄▄ ▄▌ ░▄ ▌ |0709! |15@ |18|00 b7 |16|07 member board |05▐▓▄▄▄ ▐▓ ▄▐▓▌ ▐▓▌▐▌▐▓▌░▄▄▓▌ ▄▄
|05▐▓▌ ▀▀▓▄▓▌▀█▄▓▌▐▓▌▀▀ ▐▓▌▐▓▌▓▌|15@ |18|00 http://bbsnexus.com/fluph |16

--- Mystic BBS v1.11 A1 (Windows)
* Origin: fluph.darktech.org (46:1/102)

17 Oct 15 02:01, you wrote to Skuz:

One other thing to note when importing file areas, aka new via MULTI
seems to fail now and always expect FILEBONE.NA outside the name
provided in the config.

Dang.. you where just a couple of hours late on those details. hehe.. to make the Alpha 2 release. No worries, sounds like a quick fix, if James can locate it.. nice call. Good thing all my filebone.na have been done already.

--- GoldED+/W32-MSVC 1.1.5-b20150715
* Origin: flupH - fluph.darktech.org (46:1/102)

Well the upgrade from 1.10 to 1.11a1 went flawless. VR# correct, script al works as expected. You already know that quoting messages with ANS is a no Other thing that i've noticed is that when I had multi.ini import a mass upload of the weekly filebase, it found all of the files, including the mystic_1.11 files. But, it it NOT import any file_id.diz for them. When I

There has been no change to MUTIL at all. Can you capture a debug loglevel
of MUTIL running where its not importing?

messages 3 times because the spelling errors, I get 3 Origin: lines added. One for each time i saves the same message. Then I need to edit out the du origin: lines ;)

You should notice a bunch of little quirks like that fixed in A2! :)

--- Mystic BBS v1.11 A2 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

I also noticed that if the echo area had allow ANSI turn on like my last report. My GoldEd show the post with embedded ANSI code. So iI turned it off for AGN_DEV ;)

I am not sure I am following you here! :) Are you saying it displays correctly in GoldEd or that it doesn't display?

ANSI messages will likely not work in most other BBSes or readers so I would be suprised if it worked correctly with GoldEd.

--- Mystic BBS v1.11 A2 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

--- Mystic BBS v1.11 A1 (Windows)
* Origin: fluph.darktech.org (46:1/102)
--- FastEcho 1.46a
* Origin: flupH - fluph.darktech.org (46:1/102)

It looks like FastEcho can't handle the ANSI either and is readding a tear/origin. I'll have to think about how I can fix this.

--- Mystic BBS v1.11 A2 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

17 Oct 15 15:23, you wrote to me:

it found all of the files, including the mystic_1.11 files. But,
it it NOT import any file_id.diz for them. When I

There has been no change to MUTIL at all. Can you capture a debug loglevel of MUTIL running where its not importing?

; ========================================================================== [MassUpload]
; this function searches all configured file directories for new
; files and will upload them into the BBS. It will attempt to
; import FILE_ID.DIZ using the configured archivers if the option
; is enabled.
; Name to save has the uploader
uploader_name = Mystic BBS
; Import FILE_ID.DIZ? 1=yes
import_fileid = 1
; No description string used when no FILE_ID.DIZ is imported.
no_description = No Description
; Ignore list one file mask per line (allows * and ? wildcards)
ignore = files.bbs
ignore = index.*
ignore = *.exe
ignore = *.fix
ignore = *.qwk
; ==========================================================================

----------------- MUTIL Sun, Oct 18 2015 (loglevel 3)
+ Oct 18 01:12:15 Startup using mutil.ini
- Oct 18 01:12:15 EXEC MassUpload
- Oct 18 01:12:15 EXEC GenerateAllFiles
+ Oct 18 01:12:15 Process: Mass Upload Files
+ Oct 18 01:12:24 Add: mystic_111a2_lnx.rar To: BBS Mystic
+ Oct 18 01:12:24 Add: mystic_111a2_w32.rar To: BBS Mystic
+ Oct 18 01:14:49 Add: AP151017.ZIP To: NASA: Earth & Space Science
+ Oct 18 01:14:50 NASA: National Geographic Pic
+ Oct 18 01:16:17 Results: Uploaded 3 file(s)
+ Oct 18 01:16:17 Process: Generating AllFiles List
+ Oct 18 01:16:22 Results: Added 59261 file(s)
+ Oct 18 01:16:22 Shutdown

--- GoldED+/W32-MSVC 1.1.5-b20150715
* Origin: flupH - fluph.darktech.org (46:1/102)

17 Oct 15 15:27, you wrote to me:

I also noticed that if the echo area had allow ANSI turn on like
my last report. My GoldEd show the post with embedded ANSI code.
So iI turned it off for AGN_DEV ;)

I am not sure I am following you here! :) Are you saying it displays correctly in GoldEd or that it doesn't display?

hehe I'm saying that I had mystic -cfg for AGN_DEV enabled to Allow ANSI and I had to go turn it off (change it from YES to NO). Becuse after I posted on the bbs with mystic.. then logged out. I happened to read it again with GoldEd. Not
so good when it look like a bunch of ANSi code on the left and right hand sides
and writing in between ;) Anyway all good now. So, I understand why you added that option in 1.10 to mystic before I understand what is was meant for.
weEoOo .. Hence, 1.11 in my face. LOL

--- GoldED+/W32-MSVC 1.1.5-b20150715
* Origin: flupH - fluph.darktech.org (46:1/102)

17 Oct 15 15:30, you wrote to me:

--- Mystic BBS v1.11 A1 (Windows)
* Origin: fluph.darktech.org (46:1/102)
--- FastEcho 1.46a
* Origin: flupH - fluph.darktech.org (46:1/102)

It looks like FastEcho can't handle the ANSI either and is readding a tear/origin. I'll have to think about how I can fix this.

Well, I have not change anything different in FE since 1.10. The FE custom tear/origin was anyways turned off and still is. It would seem that 1.11 has a different why of dealing with that, then 1.10 did before. This might be a good time to depart from 3rd party software. But that idea, at the same time would change the Mystic 3rd party concept of working with or without other software. Hummm..

--- GoldED+/W32-MSVC 1.1.5-b20150715
* Origin: flupH - fluph.darktech.org (46:1/102)

There has been no change to MUTIL at all. Can you capture a debug loglevel of MUTIL running where its not importing?

Bah! Thank you Skuz but I made a mistake...

I thought debug logging would show us the command line being executed to extract the .DIZ but it appears I didn't add that in for mass upload.

I will add the logging into A3 so we can get a better idea of what is going
on. Thanks for taking the time to collect the logs!

--- Mystic BBS v1.11 A3 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

Well, I have not change anything different in FE since 1.10. The FE
custom tear/origin was anyways turned off and still is. It would seem
that 1.11 has a different why of dealing with that, then 1.10 did

Yep its more of an effect of the ANSI stuff, I don't think it will happen unless you edit and ANSI-embedded message.

I think the problem is that the message is saved in ANSI format, and FastEcho can't handle the ANSI to see that it has a Tear/Origin, so it thinks it needs to add its own (even though its already there).

--- Mystic BBS v1.11 A3 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

On 10/17/15, g00r00 said the following...

--- Mystic BBS v1.11 A1 (Windows)
* Origin: fluph.darktech.org (46:1/102)
--- FastEcho 1.46a
* Origin: flupH - fluph.darktech.org (46:1/102)

It looks like FastEcho can't handle the ANSI either and is readding a tear/origin. I'll have to think about how I can fix this.

i doubt it has anything to do with the ANSI codes... i'd check to make sure
the origin line is terminated properly (CRLF or LF i forget which)...

--- Mystic BBS v1.10 A57 (Windows)
* Origin: (46:1/132)

On 10/18/15, g00r00 said the following...

I think the problem is that the message is saved in ANSI format, and FastEcho can't handle the ANSI to see that it has a Tear/Origin, so it thinks it needs to add its own (even though its already there).

back in the day when i used to post some ANSI stuff, FE never had any problems... FE doesn't care about the message contents... it only looks at
the header, the control lines, the tear line and origin line... anything else is meat and taters...

--- Mystic BBS v1.10 A57 (Windows)
* Origin: (46:1/132)

i doubt it has anything to do with the ANSI codes... i'd check to make sure the origin line is terminated properly (CRLF or LF i forget
which)...

Its the definately because of the ANSI formatted message. FastEcho can't parse ANSI messages.

--- Mystic BBS v1.11 A3 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

back in the day when i used to post some ANSI stuff, FE never had any problems... FE doesn't care about the message contents... it only looks
at the header, the control lines, the tear line and origin line... anything else is meat and taters...

FastEcho can't translate ANSI in messages into something meaningful. If you have something like:

ESC[17;1H<ESC>[1;42m--- Test Tear Line
ESC[18;1H<ESC>[1;42m ! Some Origin goes here

FastEcho doesn't see it in a translated format.

--- Mystic BBS v1.11 A3 (Windows)
* Origin: Sector 7 [Mystic BBS WHQ] (46:1/127)

On 10/23/15, g00r00 said the following...

back in the day when i used to post some ANSI stuff, FE never had any problems... FE doesn't care about the message contents... it only loo at the header, the control lines, the tear line and origin line... anything else is meat and taters...

FastEcho can't translate ANSI in messages into something meaningful. If you have something like:

ESC[17;1H<ESC>[1;42m--- Test Tear Line
ESC[18;1H<ESC>[1;42m ! Some Origin goes here

FastEcho doesn't see it in a translated format.

of course it can't... no other tosser can, either... the format does not
allow for ANSI (or any other) stuff leading control lines... control lines are specifically identified by their sequence starting at column 0 ;)

--- Mystic BBS v1.10 A57 (Windows)
* Origin: (46:1/132)

ESC[17;1H<ESC>[1;42m--- Test Tear Line
ESC[18;1H<ESC>[1;42m ! Some Origin goes here

FastEcho doesn't see it in a translated format.

of course it can't... no other tosser can, either... the format does not allow for ANSI (or any other) stuff leading control lines... control
lines are specifically identified by their sequence starting at column 0

so mystic sets the standard for the future, and the other tossers add the feature. Would be nice to see gecho and fastecho updated, along with others..

|15[xtcbox.org] - |05T|08.|03N|08.|07A |15+ |03XTC

--- Mystic BBS v1.11 A2 (Windows)
* Origin: fluph.darktech.org (46:1/102)

On 10/24/15, mental block said the following...

ESC[17;1H<ESC>[1;42m--- Test Tear Line
ESC[18;1H<ESC>[1;42m ! Some Origin goes here

FastEcho doesn't see it in a translated format.

of course it can't... no other tosser can, either... the format does allow for ANSI (or any other) stuff leading control lines... control lines are specifically identified by their sequence starting at colum

so mystic sets the standard for the future, and the other tossers add the feature.

hahaha... nope... that won't happen... message body stuff is message body stuff... control lines are control lines... the two are separate entities but some may look like message body entities (eg: tear and origin lines)...
control lines should contain /only/ printable characters ;)

Would be nice to see gecho and fastecho updated, along with others..

it would be nice to see a new fastecho, yes... i don't know if toby can or is willing to do that though... his system still connects with my system numerous times a day ;)

gecho is, i think, owned by someone else now... if not, gerard is long gone
and hasn't been heard from since the last release of gecho... he dropped out
of or got booted from several mainstream beta groups due to undesirable behavoir (eg: attempting to hack other developer's code while implementing steps to protect his own from being hacked)...

--- Mystic BBS v1.10 A57 (Windows)
* Origin: (46:1/132)