Re: Проблемы STEAD API

Хотелось бы иметь возможность поставить вокруг тире неразрывные пробелы.

Разве ваш сценарий не в UTF-8? Можно было просто скопировать из таблицы символов.

Александр Яковлев, к вашим услугам.

Re: Проблемы STEAD API

Odyssey wrote:

Единственный момент -- немного беспокоит двойная проверка фразы на disabled -- и в dialog_look, и в phrase_look.

И пользуясь случаем, а что такое game.hinting?

Двойная проверка это если phrase_look будет (вдруг?) вызван не из dialog_look, но может и правда лишняя -- гляну, сейчас убегаю на работу...

game.hinting -- рудимент для консольной версии instead -- без ссылок.

Re: Проблемы STEAD API

Oreolek wrote:

Разве ваш сценарий не в UTF-8? Можно было просто скопировать из таблицы символов.

Да, в utf-8. Скопировать не проблема, просто те пробелы, которые мне нужно заменить на неразрывные, вставлял сам stead -- при выводе фразы диалога, между номером и текстом. И переопределить это было не слишком удобно. Теперь стало удобно smile

Re: Проблемы STEAD API

Предлагаю добавить в call обработку типа boolean. По крайней мере true сейчас нужно для того, чтобы при выходе из диалога текст последнего ответа не выводился в новой локации. Сейчас приходится назначать answer'у фразы функцию function() return true end, было бы здорово назначить просто true.

Re: Проблемы STEAD API

Принято. Проверь в svn plz.
Хотя что-то я засомневался. Все таки true это хак. А в твоем случае можно замыканием обойтись... Пока оставлю но нужно еще обдумать/обсудить. Хотя вроде хуже не стало...

А так, получается это нужно ТОЛЬКО для диалогов. Так как делать act = true бессмысленно, например. То есть мы возводим ках в стандарт....

Опять же -- вернуть false будет неверным.... Мнда...

P.S. Оставляем возможность вернуть true

Re: Проблемы STEAD API

Peter wrote:

Принято. Проверь в svn plz.

Ага, оно самое, спасибо.

Peter wrote:

Хотя что-то я засомневался. Все таки true это хак.
...
Пока оставлю но нужно еще обдумать/обсудить.

Согласен, если найдутся более удачные варианты -- готов обсудить.

Peter wrote:

А в твоем случае можно замыканием обойтись...
...
То есть мы возводим как в стандарт....

Проблема здесь, имхо, именно в единообразном подходе, точнее в его необходимости. Т.е. если здесь запретить true, то получится что в одном случае текст будет подавляться с помощью true, в другом случае с помощью замыкания, в третьем -- ещё как-нибудь. Я бы и рад избавиться от хака, но он получился довольно удачным.

Из конструктивных предложений у меня есть только одно: объявить "константу", что-нибудь типа stead.NO_TEXT, stead.EMPTY или т.п. и использовать её везде вместо true. Таким образом, что скрывается за этой константой, true или что-то ещё, должен будет знать только stead, а пользователь будет использовать в тексте программы более-менее осмысленное выражение.

Re: Проблемы STEAD API

Да, оставляем true на уровне стандарта.

Re: Проблемы STEAD API

Вообще, речь не о возврате true из функции, а о том, что обработчик это -- функция или строка. А тут мы ввели еще booleан, хотя для этого есть свой callbool. Про замыкание, я имел ввиду:
function _true()
return function()
   return true
  end
end

И пишем act = _true() где хотим....

Я не знаю, act = true ничего не ломает, но просто как то некрасиво выглядит. Это не похоже на обработчик события. Как-то так.... Короче, не знаю, как то корявенько. Сегодня еще подумаю.

То есть сам факт записи act = true мной воспринимается как хак, который не хочется ни документировать ни объяснять. Типа -- обработчик может быть boolean. Какое то смешение уровней абстракции. Строка -- да -- объект. Функция -- сама по себе реакция -- возвращает нечто. А boolean? Это уже что то идеальное smile))

Возвращение true из функции-обработчика воспринимается как особенность в контексте обработчика -- то есть все ок. Типа -- поработал, вернул true. smile  А вот act = false или true скорее воспринимается как включить или выключить. Конкретней объяснить не могу. smile Но нутром чувствую что-то не так.

Короче boolean стал обработчиком. Мндя. Дай еще подумать... smile

Хотя, учитывая что act=false воспринимается как отсутствие обработчика, а act=true -- как наличие но ничего-не делающего, можно пытаться это осмысливать и в архитектурно-верном русле. smile

34 (edited by Odyssey 2010-03-17 14:15:17)

Re: Проблемы STEAD API

Проблема в том, что act = nil или act = false -- означает не отсутствие обработчика, а обработчик по умолчанию. Поэтому нам уже в нескольких местах потребовалось явно указать, что обработчика нет, вообще, и не нужно выводить результат обработчика по умолчанию. Для этих целей сгодилось семантически ещё ничем не занятое true.

По-хорошему, наверное можно было бы разделить nil и false, используя одно из них для обработчика по умолчанию (наверное nil, потому что неопределённые обработчики = nil), а другое (false) -- для явного запрета на любой вывод. Но поскольку в stead изначально используется булевская проверка, с точки зрения которой nil и false оба эквивалентны false, такое изменение может обернуться переписыванием кусков stead, возможно со временной потерей стабильности (P.S. и совместимости, по крайней мере с твоими играми). Стоит оно того или нет, сказать сложно.

Хотя, учитывая что act=false воспринимается как отсутствие обработчика, а act=true -- как наличие но ничего-не делающего, можно пытаться это осмысливать и в архитектурно-верном русле. smile

На данный момент именно так оно и осмысливается smile Не совсем традиционно, но привыкнуть можно. При отсуствии обработчика (false/nil) вызывается обработчик по умолчанию, поэтому чтобы подавить этот обработчик мы ставим собственный пустой обрабтчик в виде затычки-true.

Re: Проблемы STEAD API

Odyssey wrote:

Проблема в том, что act = nil или act = false -- означает не отсутствие обработчика, а обработчик по умолчанию.

При отсуствии обработчика (false/nil) вызывается обработчик по умолчанию, поэтому чтобы подавить этот обработчик мы ставим собственный пустой обрабтчик в виде затычки-true.

Диалектика... smile Значит все правильно, оставляем....

Еще один вопрос перед релизом 1.1.5

input.click -> down, mb, x, y, [px py]
Не коряво ли проверять наличие px py (факт попадания клика в картинку) по if px например????

36 (edited by Odyssey 2010-03-17 18:52:11)

Re: Проблемы STEAD API

Peter wrote:

Диалектика... smile

big_smile Мда, бывает.. всё-таки запрет с помощью true я бессознательно воспринимаю проще, чем различное поведение nil и false smile К тому же если act -- функция, то return true/false явно информативнее чем return nil. А если значение act как переменной и значение как результат функции трактуется одинаково, это скорее хорошо чем плохо.

Единственное что осталось поправить -- это сообщение об ошибке в call, включив туда что-то типа "nor boolean".

Peter wrote:

Не коряво ли проверять наличие px py (факт попадания клика в картинку) по if px например????

Вообще, думаю, что немного коряво.. hmm В ближайшее время точно не планируется других элементов кроме единственной картинки сцены, для которых будут определены параметры x и y? Потому что если таких элементов станет хотя бы два, то такой способ, имхо, уже не годится.. Например, картинки вставленные в сцену с помощью img не будут определять эти координаты?

Если есть сомнения по поводу других таких элементов, возможно лучше подстраховаться введя ещё один параметр -- элемент. Хоть это уже обсуждали, но тут параметр может приобрести новый смысл, если не привязывать его к внутренностям instead. Вопрос только в том, каково будет его первое, и пока единственно возможное (кроме nil), значение.

Re: Проблемы STEAD API

Пока решил остановиться на том, что есть... Буду готовить сборку 1.1.5

Re: Проблемы STEAD API

В api 1.4.0 есть небольшая ошибка, которая приводит к следующему эффекту.

Если из use обработчика нет никакого вывода, то инстед считает действие пустым, то есть
use = function(s)
    goto 'newroom'
end
не сработает.

Но сработает, например:
use = function(s)
    goto 'newroom'
    p ""
end

Проявляется только на instead_version "1.4.0"

В 1.4.1 будет исправлена, но 1.4.1 будет выпущена не раньше чем через месяц.

Re: Проблемы STEAD API

Столкнулся со следующей проблемой.
Если в игре используется много life одновременно, и один из этих life переносит игрока в новую комнату, а другие life выводили какой-то текст, то после перехода текст будет добавлен уже на новую локацию.

Это даже не баг, но нежелательное поведение, затрудняющее в некоторых случаях написание игры с многими живыми объектами.

Воркэроунд есть, и если понадобится, я его напишу, но наверное я это исправлю как-то в будущих версиях.

В svn сейчас так, если идут

life1, life2 (goto), life3

То вывод life1 будет обнулен. Вывод life2 будет помещен сверху а вывод life3 уже как обычно, но в новой комнате.

В 1.4.5:

Весь вывод будет в новой комнате, но life2 будет сверху (как событие приведшее к переходу).
1.4.6 планирую через месяц.

Re: Проблемы STEAD API

Столкнулся с багом в 1.8.0.

Если использовать onact, то любой не нулевой вывод блокирует этот act. Так что сейчас, onact может использоваться только для блокирования действия или накопления статистики. В 1.8.1 будет исправлено.

В принципе, не критично, так как onact и задумывался для блокировки действий и статистики.