Класс объектов

Конструкторы объектов широко использовались в STEAD2. В STEAD3 obj/dlg/room реализованы как классы объектов. Класс объектов удобно создавать для тех случаев, когда поведение создаваемого объекта не укладывается в стандартные объекты obj/room/dlg и вы хотите поменять методы класса. Изменив метод класса, например, вы можете вообще изменить то, как выглядит предмет в сцене. В качестве примера, рассмотрим создание класса "контейнер". Контейнер может хранить в себе другие объекты, быть закрытым и открытым.

-- create own class container
cont = std.class({ -- создаем класс cont
    display = function(s) -- переопределяем метод показа предмета
	local d = std.obj.display(s)
	if s:closed() or #s.obj == 0 then
	    return d
	end
	local c = s.cont or 'Внутри: ' -- описатель содержимого
	local empty = true
	for i = 1, #s.obj do
	    local o = s.obj[i]
	    if o:visible() then
		empty = false
		if i > 1 then c = c .. ', ' end
		c = c..'{'..std.nameof(o)..'|'..std.dispof(o)..'}'
	    end
	end
	if empty then
	    return d
	end
	c = c .. '.'
	return std.par(std.space_delim, d, c)
    end;
}, std.obj) -- мы наследуемся от стандартного объекта

После этого, вы можете создавать контейнеры так:

cont {
    nam = 'ящик';
    dsc = [[Тут есть {ящик}.]];
    cont = 'В ящике: ';
}: with {
    'яблоко', 'груша';
}

Когда контейнер будет открыт, вы увидите описание ящика, а также содержимое ящика в виде строки ссылок: В ящике: яблоко, груша. dsc объектов яблоко и груша будут скрыты.

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

Частый вопрос, это -- как делать переводы строк в конце dsc/decor и прочих методов?
В STEAD3 все начальные и конечные переводы строк (^) -- режутся принудительно. Так как в 99% случаях, наличие дополнительных ^ это ошибка. Например, pn() в конце обработчика. Если вам действительно нужно контролировать вывод настолько глубоко, вы можете:

1) Написать в init() функции std.strip_call = false и тем самым отключить механизм вырезания лишних ^.
2) Использовать подстановки $, например, таким образом:

obj {
   nam = '$',
   act = function(s, w)
      return w
   end,
}

obj {
    nam = 'a';
    dsc = '- 1{$|^}';
}

obj {
    nam = 'b';
    dsc = '- 2{$|^}';
}

obj {
    nam = 'c';
    dsc = '- 3{$|^}';
}

room {
   nam = 'main';
   obj = { 'a', 'b', 'c' };
}

Ссылка на постоянно растущий FAQ будет здесь: http://club.syscall.ru/_faq
Я буду добавлять в него интересные сообщения.

Прочитал всю документацию про переменные типа global, и все места, где упоминаются переменные. Возможно я недопонимаю, так как раньше работал только с процедурными языками, а не с ООП. Вопрос в следующем. Я в самом начале задаю некие глобальные переменные

global {
hot = 100; -- тепло, главный показатель ГГ
power = 100; -- бодрость, главный показатель ГГ
reason = 99; -- рассудок, способность принимать решения, вниманимательность, адекватность
}

Эти переменные используются для свёрнутого описания статуса ГГ, чтобы они появлялись на экране только при двойном клике на объект инвентаря "статус", таки образом

obj { -- описание объекта "статуc ГГ"
nam = 'статус';
dsc = 'Это {статус}, просмотр статуса возможен при двойном клике на надписи "статус"';
tak = 'Просмотр статуса возможен при двойном клике на надписи "статус"';
inv = function(s)
p (hot, '% - тепло^');
p (power, '% - бодрость, способность действовать^');
p (reason, '% - рассудок^');
end
} -- конец описания объекта "статуc ГГ"

И это работает. Однако, часто возникает необходимость, при попадании в какую-либо локацию (room), изменить значения этих переменных. По условию, или принудительно без всяких условий. Я не понял как это делается. Простая запись, типа

hot = 83; -- тепло изменилось со 100 на 83
power = 79; -- бодрость изменилась со 100 на 79
reason = 51; -- рассудок изменился с 99 на 51

Instead3 не выдает ошибки, но и не меняет значения переменных при попадании в эту комнату. Двойной клик на объект инвентаря "статус" выдает на экран первичное значение переменных. Друзья, подскажите, что я делаю не так.

>>Instead3 не выдает ошибки, но и не меняет значения переменных при попадании в эту комнату. Двойной клик на объект инвентаря "статус" выдает на экран первичное значение переменных.>>

Бился пол ночи, смотрел коды игр из репозитория. Решил проблему созданием фиктивного описания сцены

dsc = function(s)
hot=72;
power=89;
reason=51;
end;

Из документации:

Основное отличие атрибутов от обработчиков событий состоит в том, что обработчики событий могут менять состояние игрового мира, а атрибуты нет. Поэтому, если вы оформляете атрибут (например, 'dsc') в виде функции, помните, что задача атрибута это возврат значения, а не изменение состояния игры! Дело в том, что движок обращается к атрибутам в те моменты времени, которые обычно четко не определены, и не связаны явно с какими-то игровыми процессами!

Если при входе в комнату нужно выполнить какой-то код, оформи его в виде enter или onenter обработчика.

room {
    onenter = function()
        A = 10
    end;
    dsc = ....
}

В документации эти обработчики описаны тут: https://github.com/instead-hub/instead/blob/master/doc/stead3.md#Переходы-между-сценами

Пётр, большое спасибо за пояснения. Это очень помогло. Продолжаю читать документацию.

Начал писать здесь: https://github.com/gl00my/stead3/blob/master/doc/modules3.md
Можно следить за тем, как она наполняется и задавать вопросы. :)

Вопрос. Но пока пояснение. Как правило, в играх на Instead динамическая часть сцены расположена на экране выше, чем основное описание сцены (dsc, decor). То есть при появлении вообщений в динамической части - текст decor смещается вниз, чтобы освободить место для появившейся надписи курсивом.

Как поменять их местами и возможно ли это? Можно ли при помощи кода игры, модулей или настройки темы (голубая сталь, стандартная и т.п.) сделать, чтобы динамическая часть сцены, точнее сообщения в ней, выводились всегда ниже, чем статичный блок описания сцены decor (и, разумеется, ниже блока описания об'ектов)?

p.s. если быть точнее, то вопрос связан именно с выводом реакций игры (движка) в виде текста курсивом. Прочёсывая документацию, увидел, что динамическая часть сцены неоднозначное понятие. Я знаю что есть статическая часть (декорации, некоторые даже активные) и динамическая (объекты , которые пока лежат, стоят и т.д, но они могут быть взяты в инвентарь, убраны вообще или видоизменены). Но помимо этих двух частей есть область вывода реакций игры - "вы взяли карандаш", "карандаш, как карандаш" и т.п. Вот эти надписи я хочу попытаться переместить, чтобы они появлялись внизу экрана, а не вверху. Но пока не понял как.

p.s. повлияет ли на то, что я описал ранее, изменение вот этой функции в плане последовательности расположения этих областей игрового экрана (глава 21 документации по Inst3 "ФОРМАТИРОВАНИЕ И ОФОРМЛЕНИЕ ВЫВОДА") ?

game.display = function(s, state)
local r, l, av, pv
local reaction = s:reaction() or nil -- реакция
r = std.here()
if state then -- такт игры?
reaction = iface:em(reaction) -- курсив
av, pv = s:events()
av = iface:em(av) -- вывод ”важных” life
pv = iface:em(pv) -- вывод фоновых life
l = s.player:look() -- objects [and scene] -- объекты и сцена
end
l = std.par(std.scene_delim,
reaction or false, av or false, l or false,
pv or false) or ’’
return l
end;

Да, display отвечает за вывод. Но все-таки, я бы не советовал менять его в своей первой игре. Ведь эта логика -- результат мыслей. Там же многие вещи созданы не просто так -- а взаимо-завязаны в плане идейной стройности.

А так, смотри сам. При вставке кода используй 4 символа =, примерно так:

l = std.par(std.scene_delim, reaction or false, av or false, l or false, pv or false) or ’’
заменить на:
l = std.par(std.scene_delim,  l or false, av or false, reaction or false, pv or false) or ’’

Большое спасибо. Да, я неоднократно встречал этот посыл о ненужности вмешательства в дела вывода, он проходит белой нитью. И полностью согласен, за тем я с большим трудом и пришел к Instead, чтобы облегчить себе написание содержательной части игр. В оправдание могу лишь сказать, что в данном случае этого требует игра, другого об'яснения у меня нет))) Все остальные твои замечания в документации по поводу нестандартных требований к платформе, типа разные размеры текста в одном экране и т.п. разделяю.

Я не против экспериментов. Просто лучше всего их делать, когда уже есть понимание как работают стандартные вещи.
Поэтому я обычно советую хотя бы первую игру делать в рамках "стандартного" инстеда.
А так, все на твое усмотрение, конечно.

Подумай вот о чем.
Мы берем яблоко.
Яблоко пропадает со сцены.
Описание сцены -- ситуация.
В твоем варианте, мы прочитаем сначала описание новой ситуации (без яблока), а только потом, узнаем что мы взяли яблоко.

Типа:

На столе больше нет яблока.
Вы взяли яблоко.

Разве это не настораживает? ;)

Еще пример. Допустим, есть волк. С методом life. Он убивает гг. При этом идет переход на сцену конец игры.

И вот мы видим:

Конец игры.
Волк бросается на вас.

Вместо: Волк бросается на вас.
Конец игры.

Таких примеров можно еще привести. Вот попытался пояснить мысль. :)

Ну и для полноты картины. При входе в комнату вызывается событие onenter. Пусть в нем будет что то вроде: мы вошли в зал.

В твоем варианте будет:

Вы оказались в большом зале!
Вы вошли в зал.

Ты все еще думаешь, что смена display хорошая идея? :)

Дисплей можно менять, но тогда надо менять подход везде. Например, делать ленту вывода (как в мп) или что то еще.

То есть, логика стандартного поведения:
Что ты сделал -> что получилось

Если нужна другая логика, надо ее сначала продумать. Просто смена вывода не поможет. Нужна концепция. В самом твоем вопросе есть подмена. Реакция не добавляется. Каждый новый экран -- это абсолютно новый такт времени.

В качестве компромиссного решения можно назвать такое.
dsc
Реакция
decor/объекты

Такое поведение было в stead2. Оно имеет противоречия, но если условиться что dsc не меняется, можно его сделать. Если это нужно, могу помочь. Надо look вызов в display разбить на два.

Пётр, я сделал, как того хотел. Твои доводы убедительны, но, как часто бывает, убедить может только свой опыт))) Посмотрел, как это выглядит - хуже, чем я представлял. Тут еще играет роль устройство внимания человека. Когда шапка не меняется, а внизу под неизменным текстом что-то появляется/меняется, взгляд очень неохотно переходит вниз экрана. Мы, как правило, держим внимание вверху экрана, так как там самая важная информация. Да, хорошо, что текст decor отскакивает вниз/прыгает, есть есть некая живость "картинки", хотя добавляется всего 1-2 строчки реакции вверху. В общем, остаюсь на базовых настройках))) Большое спасибо за примеры и пояснения. Продолжаю медленно, но верно работать над игрой.

Чем больше делаешь, тем больше вопросов. Я уже читал о порядке работы интерпетатора, и могу работать с предметами и активными декорациями в пределах одной сцены. Тем более есть хорошая тестовая игра/учебник, которая прилагается к Inst3. Однако, пришлось залезать и в новую и в старую документацию, чтобы прочитать о теоретических вопросах. Это было вступление)))

Вопрос в следующем. Могу ли я НЕ внутри описания некой конкретной сцены room {.....} принудительно добавлять и убирать об'екты на эту или иную сцену (room) при помощи или без помощи инвентаря, а одними лишь функциями обработчиков самих об'ектов и декораций?

На сколько я знаю, если я пришел на сцену "лес", в которую при описании room {....} внутри фигурных скобок добавлены ранее сформированные obj "лежит {топор}" и obj "валяется {чурбак}", то я сейчас могу для каждого об'екта иметь возможность изменить динамическую часть сцены. Взять топор в инвентарь, он исчезнет со сцены. И порубать этим топором чурбак, он заменится на "поленья" и "щепки". Это штатно и понятно, и на других похожих случаях мной отработано.

Но если я уйду с этой сцены по way или @ walk, а потом вернусь обратно в нее же с уже другими сюжетными задачами, то снова обнаружу не только лежащий топор, но и неразрубленный чурбак. По этому я и спросил про принудительное управление об'ектами инвентаря и любой другой сцены (не только текущей), возможно ли оно. То есть я хочу не только изменить сцену своими действиями, но и вернувшись в нее, застать прошлые изменения и дополнить их новыми, к примеру я притащил еще и спички, которые где-то выменял на топор, которого не должно уже быть ни в этой сцене, ни в инвентаре, ни вообще в игровом мире.

Это я не к тому, что я хочу многого, просто проще заранее знать, если это невозможно штатными методами, я тогда изловчусь и попытаюсь написать игровую механику, чтобы она обеспечивала всю эту странную песочницу. Пока я могу ходить только в одномерном мире и строить сюжет без возможности вернуться на локации, ранее уже посещенные. Есть игра Шизофрения, где описанное мной реализовано (сохранение изменений в сцене при возвращении) , но я пока не смог разобраться как.

Конечно можно. Если я правильно понял вопрос.
Ты можешь класть/убирать любые объекты из/в любые другие объекты/комнаты просто кодом.
Если нужно это, то смотри "Другие функции стандартной библиотеки" и там тебе: place() например.
Ну или на примере кода задай вопрос, чтоб конкретней ответить.
Еще можно явно манипулировать списками obj и way: описано в "Атрибуты-списки". Например objs "лес":zap() -- убил все объекты

Ну а делать это можно, например, в onenter/enter/exit/onexit.
Код игры на stead3 -- это проводник и инстедоз 5. Можешь для примера изучать эти игры.

Спасибо. Теперь я понял, что такое атрибуты-списки. Чита-читал, но не мог понять саму суть и назначение этого. Похоже на динамически меняющиеся массивы, в моем ветхом процедурном лексиконе. В любом случае отчитаюсь с примерами, даже если получится и сцены заработают как надо. Уверен, наше осуждение будет полезно кому-то еще. "Проводник" посмотрю.

В процессе понял, что уверенных знаний в инстэд пока не хватает. Читаю сообщения об ошибках в сюжетах уже опубликованных инстэд-игр и просьбы к авторам поправить нестыковки. Хочу изначально, большую часть ключевых dsc и вообще текстовок связанных с room и obj вводить в виде переменных. А не в виде устойчивых (константных) dsc и decor. Просто, чтобы они были управляемы. Ну, к примеру, decor - "Вы пришли на заснеженную поляну и видите {домик}", потом он сгорает, чтобы не делать перетасовок, я лишь в определенный момент заменю значение строковой переменной и будет уже "....и видите {сгоревший домик}". А все движимые об'екты, да, придется тоже задавать заранее и вводить их при помощи кода (place и остальных конструкций). Пока я мыслю себе так.

Проще, все таки в инстед стиле:

obj {
    nam = 'домик';
    burned = false;
    dsc = function(s)
         if s.burned then
             p [[Вы видите, как дымится {дом}.]]
             return
         end
         p [[Вы видите уютный {домик}.]]
    end
}

Ну и все. Теперь в комнате:

room {
    nam = 'Поляна';
    obj = { 'домик' };
}

По-моему, так проще.

Спасибо. Пойду перечитывать про переменные, так как догадываюсь, что s.borned это хоть и переменная, но и одновременно некое "служебное слово" по отношению к borned. То есть понятно, что дело не в названии, а в том, как добавляется и интерпритируется инстэдом это s.****

То есть, да, я понял, что в dsc конкретного об'екта мы заносим все возможные формы существования этого об'екта, и уютный и сгоревший, и еще можем добавить другие состояния. Не понял пока куда и зачем вернет нас return.

Аааа. Прошу прощеня, забыл очевидную вещь)))) если убрать return, но отобразятся сразу оба состояния. А return вернет нас просто в room, где об'ект фигурирует. К сожалению не знал, что Инстэд может реализовывать return без парного отсылающего оператора (типа gosub и подобных). Теперь я еще продвинулся с твоей помощью, спасибо.

> Аааа. Прошу прощеня, забыл очевидную вещь)))) если убрать return, но отобразятся сразу оба состояния. А return вернет нас просто в room, где об'ект фигурирует.
Дело в том, что есть такое понятие как метод,
Вот dsc - это метод. Когда движку нужно описание, он вызывает метод dsc у всех объектов комнаты. return тут это не возврат в комнату, а выход из функции. Например (это не инстед, просто lua):

function test()
   return 10
end
print(test()) -- выведет 10

function test2()
   return
end
print() -- выведет пустоту

А в инстеде p -- это просто накопление текста, например:

p "hello"

это то же самое, что return "hello"

Или так:

p "hello"
p "world"

то же самое, что и return "hello world"

Теперь про пример:

if s.burned then
   p "сгорел"
end
p "не сгорел"

будет "сгорел не сгорел"

а так:

if s.burned then
   p "сгорел"
   return  -- мы вышли из функции
end
p "не сгорел"

только одно состояние

Еще вариант:

if s.burned then
   p "сгорел"
else
   p "не сгорел"
end

Надеюсь, помог.

Ну, собственно в этом и вопрос. У меня есть несколько служебных комнат, в которые нужен доступ из совершенно разных сцен. Как то - Статус (да, я знаю и научился делать статус в инвентаре), текущие задания для ГГ, меню разведения огня, меню сна и т.п. Я это делаю так (лирика сокращена для краткости)

room {-- место ночёвки
nam = 'loc1.episode1';
title = 'Блок радиоуправления';
way = { 'статус', 'задания' }; -- кнопки статус и задания
decor = [[Комната, где доступны статус и задания]];
}

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

room {
nam = 'задания';
title = 'задания';
decor = [[Текущие задания...{@ walkout()|назад}]];
}

Но оно не работает. Я пытался применять функцию from(), но так и не понял, как ее синтаксически прилепить к "@ walk". Помогите найти дорогу обратно из служебной комнаты в любую произвольную, из которой я пришел в эту служебную при помощи way.

Вот законченный пример (main3.lua). Он работает. :) Просто скопируй все в main3.lua и запусти. Если есть вопросы, оформляй в виде примеров - я исправлю.

xact.walkout = walkout -- сделали свою xact функцию walkout

room {
	nam = 'main';
        dsc = [[Я тут стою.]];
	way = { 'pribor' };
}

room {
	nam = 'pribor';
	dsc = '10:20';
	decor = [[{@ walkout|назад}]];
}

Спасибо, всё заработало!

Пётр, к тебе вопрос. Он может показаться банальным и даже странным. Мне это важно для продумывания дизайна игры и игровой механики. Пытаюсь не выходить из границ целей создания движка Instead (я читал манифест), с другой стороны мне важно как это будет выглядеть для игрока, ну и себе границы задать. Вопрос вот в чем. Какую игру (игры) на Instead (игры не твоего пера) ты считаешь, что они (она) больше всего и полнее реализуют заложенные тобой в движок идеи? Независимо от того, нравится ли тебе сама игра и сюжет или нет. Ну, есть такие, чтобы ты сказал не просто "качественная игра", а типа того, что "да, вот для таких игр я и создавал Instead, и хотелось бы таких игр видеть больше"?

Я могу назвать только свои любимые игры. Но они совсем разные и по механике, и по сюжету.
Я вообще, не могу сказать что мне так уж важна форма. Но я не люблю обычно COYA игры. А так, вот список игр, которые я так или иначе помню.

- Лифтер 1 и 2;
- Лидия, Переход;
- Материк (добротно сделано, но сюжет не пошел. игра в steam);
- Инстедоз 3;
- Инстедоз 5;
- Кайлет;
- Славный город Лудд (но очень маленькая);
- Зараженные (как пример просто добротной игры, хотя сюжет не особо близкий);
- Неизбежные вещи (как пример интересной находки в геймплее);
- Новогодняя сказка (не знаю почему, но нравится!, хоть короткая);

> Пытаюсь не выходить из границ целей создания движка Instead (я читал манифест), с другой стороны мне важно как это будет выглядеть для игрока, ну и себе границы задать.

Суть манифеста не в том. Если ты чувствуешь в себе силы -- ломай границы, но только тогда неси сам ответственность за это. Если ты перерос ограничения -- это нормально. Но чаще, это не так. :)
Есть много примеров, когда люди делали что-то совсем новое, и это было круто! Инстед для экспериментов. Но:

1) если ты вышел за рамки документации -- ты уже НЕ новичок. Начиная с этого момента: no warranty, no support.

2) не жди, что твоя замечательная идея автоматически понравится всем, тебе помогут только те, кому это интересно.

3) очень часто, люди ломают не потому, что переросли ограничения -- а просто не разобрались с текущим положением вещей. Грубо говоря, в 90% случаях человек делает COYA просто потому, что он ничего больше не видел (не хочет видеть) и потенциал инстеда оказывается невостребованным.

А так, полно примеров. когда люди экспериментировали, и получилось интересно.
МП, прокси-меню, спрайты и так далее - все это результат экспериментов.

Короче мой совет, напиши сначала несложную игру, освойся с инструментом. Почувствуй его. Потом все будет. ;)

Спасибо за пояснения. Посмотрев примеры игр из твоего списка (с комментариями) и уловив суть советов, решил делать так:
*выбрать только то (те способы), что уже знаю, и что спрашивал здесь на ветке.
*постараться сделать игру, пользуясь только знакомыми и отработанными способами, не пытаясь непомерно развивать технологии параллельно развитию сюжету. Делать ровно.
*сосредоточиться на самой игре, варьируя уже известными и отработанными ходами (в кодинге Instead).

В принципе, ты рассказал мне (здесь и в документации) некий минимум, чтобы я мог уже свободно ходить между локациями, менять декорации, брать и выкладывать предметы, заменять их в инвентаре на другие (замена яблока на огрызок при использовании и т.д.), работать с некоторыми функциями. Собственно, да... пора уже переходить к фазе разработки несложной, но законченой игры. Первой игры на Instead.

> Собственно, да... пора уже переходить к фазе разработки несложной, но законченой игры. Первой игры на Instead.
Удачи! Будем ждать. :)

Добрый день. Вопрос в следующем, как работать с функциями place, put или иными, если я не готов конкретно назвать имя комнаты куда хочу положить объект (переместить из инвентаря)? Что я имею - служебный объект инвентаря, который выполняет роль одного из действий (починить, сломать, говорить и т.п.) конкретно "выложить".

obj {-- служебный объект выложить, действие
nam = '-выложить';
pri = -99;
inv = [[Хелен может выкладывать предметы, которые пока ей не нужны.
Следует один раз кликнуть на действии "выложить",
и второй раз кликнуть на нужный предмет в инвентаре.]];
}

В него я специально не вписываю use/used, так как это все впишу в объекты-цели. Однако, вот есть условно 'кувалда', и нужно, чтобы ее used при соединении и 'выложить', помещал эту кувалду в ту комнату, где находится ГГ, независимо из какой комнаты эта конструкция вызывается.

obj {-- кувалда, физический объект
nam = 'кувалда';
used = function(s)
if s^'выложить' then
place (s, ???????????);
remove(s);
end;
}

То есть вопрос, как вписать в функцию отсылку к ТЕКУЩЕЙ комнате, название которое тоже есть функция?

> То есть вопрос, как вписать в функцию отсылку к ТЕКУЩЕЙ комнате, название которое тоже есть функция?
Если в place() 2й параметр не указан, то это будет текущая комната.
Но если нужна отсылка к этой текущей комнате еще для чегото, есть функция here() -- это и есть указатель на текущую комнату.

Далее, тут не понятно:

used = function(s)
    if s^'выложить' then
    place (s, ???????????);
    remove(s);
end; 

Скорее всего ты хотел написать:

used = function(s, w) -- s -- это и будет кувалда, нас интересует w а не s
    if w^'выложить' then
        place (s); -- в текущую комнату
        remove(s);
    end
end; 

Еще настоятельно рекомендую использовать отступы! Понятней код и самому проще и другим. :)

Да еще. remove(s) тоже не нужен. place сам убирает объект из прошлого место-положения. Это put не удаляет, а place -- перемещает как бы объект в новое место.
Так что в твоем случае и remove не нужен (но я бы еще воткнул признак отсутствия реакции):

used = function(s, w) -- s -- это и будет кувалда, нас интересует w а не s
    if w^'выложить' then
        place (s); -- в текущую комнату
    else
        return false -- даем знать stead3, что ничего не сделали, тогда вызовется game.use
    end 
end

Wol4ik> Добрый день. Вопрос в следующем, как работать с функциями place, put или иными, если я не готов конкретно назвать имя комнаты куда хочу положить объект (переместить из инвентаря)? Что я имею - служебный объект инвентаря, который выполняет роль одного из действий (починить, сломать, говорить и т.п.) конкретно "выложить".

Wol4ik> obj {-- служебный объект выложить, действие
Wol4ik> nam = '-выложить';
Wol4ik> pri = -99;
Wol4ik> inv = [[Хелен может выкладывать предметы, которые пока ей не нужны.
Wol4ik> Следует один раз кликнуть на действии "выложить",
Wol4ik> и второй раз кликнуть на нужный предмет в инвентаре.]];
Wol4ik> }

Wol4ik> В него я специально не вписываю use/used, так как это все впишу в объекты-цели. Однако, вот есть условно 'кувалда', и нужно, чтобы ее used при соединении и 'выложить', помещал эту кувалду в ту комнату, где находится ГГ, независимо из какой комнаты эта конструкция вызывается.

Wol4ik> obj {-- кувалда, физический объект
Wol4ik> nam = 'кувалда';
Wol4ik> used = function(s)
Wol4ik> if s^'выложить' then
Wol4ik> place (s, ???????????);
Wol4ik> remove(s);
Wol4ik> end;
Wol4ik> }

Wol4ik> То есть вопрос, как вписать в функцию отсылку к ТЕКУЩЕЙ комнате, название которое тоже есть функция?

А почему не используешь drop()?

> А почему не используешь drop()?
В принципе, drop() в stead3 практически совпадает с place ;) drop создан для наглядности кода главным образом. А так да -- самое место ему тут быть используемым. :)

>> А почему не используешь drop()?
> В принципе, drop() в stead3 практически совпадает с place ;) drop создан для наглядности кода главным образом. А так да -- самое место ему тут быть используемым. :)

Упустил этот момент. У себя place использую для движения объетов между локациями, например.

Спасибо, друзья. С drop тоже проэкспериментирую. Спасибо Петру за наглядное пояснение, что есть s и w в функциях, а то я часто срисовывал как школьник с доски, без понимания.

Добрый день. При создании фатальных концовок возникла необходимость приведения игры к "нулевому состоянию", то есть перегенерации всего игрового мира, возвращения об'ектов на свои места, инициализации всех переменных и т.д. Прошу подсказать, как это сделать в теле описания сцены или иным образом. Может быть есть функция или команда, которая имитирует пункт с меню Stead3 "начать заново"?

Полный рестарт игры можно сделать: instead.restart(true)

Также можно только состояние мира заресетить. std:reset() -- но эту функцию нужно использовать с осторожностью. Проще instead.restart()

Спасибо, получилось. Создал спец.об'ект и поместил его в комнату одной из концовок:
--
obj { -- об'ект фатальной концовки, при активации перезапускает игру.
nam = 'bad1obj';
dsc = '{Начать заново...}';
act = function()
instead.restart(true);
end;
}
--