На редкость продуктивный день.
За сегодня удалось сделать несколько вещей, которые планировались на протяжении уже нескольких месяцев, но до которых никак руки не доходили внимательно разобраться.
[250x250]
Во-первых, накропал апдейт мирка [frpln mod] до версии 0.02. Исправил несколько малоприятных ошибок, дописал ещё некоторый функционал, на который, не смотря на очевидную нужность, хотя и явную редкость применения, исходные разработчики махнули рукой. Вообще разбираясь в формированиях их менюшек я долго ругал все на чем свет стоит - ибо нельзя так делать, садизм это откровенный. Да, смотрится красиво, но садизм.
Обидно только, мод изначально писал на базе исходной версии 1.1, а сейчас выложена 1.2. Но переносить количество внесенных мной изменений в исходную 1.2 - извращенство ещё большее. Надо попробовать как-нибудь на досуге диффы от оригинальной 1.2 к оригинальной же 1.1 сделать, посмотреть.
Во-вторых, подобрал каким-то образом пароль к своей старой БД на case.net.ru. Перекинув конфиг сайта с 10.4 на него пришел к неутешительному выводу, что kreon.net.ru тормозит только из-за связи с удаленными базами данных, а не сам по себе. И находись эти базы на локалхосте - все бы летало. И почти ничего ведь не сделаешь. Бедный сайт. :(
Но зато, самое главное, кажется, решил проблему спецсимволов в именах игроков IRC-викторины. Хвала небесам!! Это издевательство продолжалось буквально с самого перевода игры на MySQL - то есть, не много ни мало, с января 2006 года. И с тех пор сражение с компьютерной логикой шло с переменным успехом, под конец остановившись на дуболомных костылях в форме замены спецсимволов на комбинации вида ~1~, ~2~, ~3~, ~4~ и т.д. на вводе с декодированием обратно в }, {, [, ] и т.д. на выводе. И хотя так все и работало - но некрасивый это подход, ей-богу.
Прочитав всевозможную документацию по спецсимволам на Tcl'e; поняв несколько если не золотых, так серебряных правил про то, что никогда нельзя путать переменные в форме string и переменные в форме list, и какая дрянь может получиться, если их все же перепутать; просмотрев исходники дроповского модуля mysql.mod и познав тайну отличия Tcl_AppendElement и Tcl_AppendResult, и какой тип данных ими формируется; и что мы все-таки действительно получаем, и что должны получить на вводовыводе обращения к БД, я наконец таки разобрался, откуда в возвращаемых модулем запросах берутся лишние скобки и слэши, и как их сносить без риска для скобок и слэшей настоящих.
Итог вылился в дополнение скрипта игры функцией, возвращающей уже не невесть что, а точную строковую переменную без лишних скобок и экранирований:

code:
proc mysql_query_string {text} {return [join [string range [mysql_query $text] 1 end-2]]}

И всё.
Этой функции и правильного её применения в паре подпроцедур в tpub::users в течение полутора лет не хватало для нормальной работы без костылей.

...Хотелось подправить mysql.mod, чтобы он не рисовал лишние скобки на одностроковых резалтах, чтобы можно было обойтись и без этой небольшой подпорки. Когда базы возвращают с запроса строк больше одной - скобки, безусловно, нужны. Но когда меньше - простите. Набросал немного кода.

code:
...

  num_rows = mysql_num_rows(result);

  if (num_rows > 1) {

    while ((row = mysql_fetch_row(result)))

    {

      Tcl_AppendResult(irp, "{", NULL);

      for (x = 0; x < num_fields; x++) {

      	Tcl_AppendElement(irp, fields[x].name);

      	Tcl_AppendElement(irp, (row[x] ? row[x] : "{}"));

      }

      Tcl_AppendResult(irp, "} ", NULL);

    }

  } else {

    row = mysql_fetch_row(result);

    for (x = 0; x < num_fields; x++) {

       Tcl_AppendElement(irp, fields[x].name);

       Tcl_AppendElement(irp, (row[x] ? row[x] : "{}"));

    }

  }

...

Так эта зараза даже откомпилировалась безо всяких претензий, но при попытке запуска с одной из фунций вызывала обязательный сбой дропа. С вылетом. И причины лично мне непонятны.
Завтра надо будет продолжить эксперименты.