Strange Wood
Модератор: Jolly Roger
18.07.07
При запуске приложения выдает ошибку в SDL. ОШибка в SDL.dll по адресу 10019B02. Не понимаю, из-за чего. Надо попробовать сделать тестовый проект просто для обработки клавиатуры.
22.07.07
Не работает обработка событий клавиатуры в SDL. Не понимаю, почему. Вроде код правильный. Впечатление, что окно игры просто не получает событий от клавиатуры. Попробовать включить в проект флаг CONSOLE? Добавил. Теперь создается текстовое окно, в дополнение к окну SDL. Но клавиатура все равно не обрабатывается.
Начал писать редактор для предметов. Чтобы не лазить каждый раз в файл описания предметов. Попробовал включить существующие модули от игры в редактор. Не получилось. Модуль UItems довольно плотно завязан с остальными модулями. Это плохо. Получается, что между модулями довольно высокая связность.
Вопрос к сообществу: кто может поделиться работающим примером обработки клавиатуры средствами SDL (на Delphi)?
При запуске приложения выдает ошибку в SDL. ОШибка в SDL.dll по адресу 10019B02. Не понимаю, из-за чего. Надо попробовать сделать тестовый проект просто для обработки клавиатуры.
22.07.07
Не работает обработка событий клавиатуры в SDL. Не понимаю, почему. Вроде код правильный. Впечатление, что окно игры просто не получает событий от клавиатуры. Попробовать включить в проект флаг CONSOLE? Добавил. Теперь создается текстовое окно, в дополнение к окну SDL. Но клавиатура все равно не обрабатывается.
Начал писать редактор для предметов. Чтобы не лазить каждый раз в файл описания предметов. Попробовал включить существующие модули от игры в редактор. Не получилось. Модуль UItems довольно плотно завязан с остальными модулями. Это плохо. Получается, что между модулями довольно высокая связность.
Вопрос к сообществу: кто может поделиться работающим примером обработки клавиатуры средствами SDL (на Delphi)?
Первая заповедь фотолюбителя: Проявил себя - закрепи!
- Alchemist
- Мастер
- Сообщения: 203
- Зарегистрирован: 13 дек 2006, 09:15
- Откуда: Нижний Тагил, Иваново
- Контактная информация:
Dmiry писал(а): Вопрос к сообществу: кто может поделиться работающим примером обработки клавиатуры средствами SDL (на Delphi)?
Код: Выделить всё
procedure TMainWindowSDL.WndCreate(aWidth, aHeight: Integer);
begin
inherited WndCreate(aWidth, aHeight);
SDL_Init(SDL_INIT_VIDEO);
end;
procedure TMainWindowSDL.WndDestroy;
begin
SDL_QUIT;
inherited WndDestroy;
end;
procedure TMainWindowSDL.Run();
var
event: TSDL_Event;
function KeyboardStateToShiftState: TShiftState;
var
modifier: LongWord;
begin
Result := [];
modifier := event.key.keysym.modifier;
if (modifier and KMOD_LCTRL <> 0) or (modifier and KMOD_RCTRL <> 0)
then Include(Result, ssCtrl);
if (modifier and KMOD_LSHIFT <> 0) or (modifier and KMOD_RSHIFT <> 0)
then Include(Result, ssShift);
if (modifier and KMOD_LALT <> 0) or (modifier and KMOD_RALT <> 0)
then Include(Result, ssAlt);
end;
var
x, y: Integer;
key: Word;
Shift: TShiftState;
button: TMouseButton;
begin
try
AppCreate();
try
if (Cursor <> nil)
then SDL_ShowCursor(0);
while not(Terminate) do begin
while (SDL_PollEvent(@event) = 1) do begin
case event.type_ of
SDL_KEYDOWN: begin
key := event.key.keysym.sym;
Shift := KeyboardStateToShiftState();
KeyDown(key, Shift);
end;
SDL_KEYUP: begin
key := event.key.keysym.sym;
Shift := KeyboardStateToShiftState();
KeyUp(key, Shift);
end;
SDL_MOUSEMOTION: begin
x := event.motion.x;
y := event.motion.y;
Shift := [];
if (event.motion.state = SDL_BUTTON_LEFT) then Include(Shift, ssLeft);
if (event.motion.state = SDL_BUTTON_MIDDLE) then Include(Shift, ssMiddle);
if (event.motion.state = SDL_BUTTON_RIGHT) then Include(Shift, ssRight);
MouseMove(Shift, x, y);
end;
SDL_MOUSEBUTTONDOWN: begin
x := event.button.x;
y := event.button.y;
Shift := [];
if (event.button.button = SDL_BUTTON_LEFT) then button := mbLeft;
if (event.button.button = SDL_BUTTON_MIDDLE) then button := mbMiddle;
if (event.button.button = SDL_BUTTON_RIGHT) then button := mbRight;
MouseDown(button, Shift, x, y);
end;
SDL_MOUSEBUTTONUP: begin
x := event.button.x;
y := event.button.y;
Shift := [];
if (event.button.button = SDL_BUTTON_LEFT) then button := mbLeft;
if (event.button.button = SDL_BUTTON_MIDDLE) then button := mbMiddle;
if (event.button.button = SDL_BUTTON_RIGHT) then button := mbRight;
MouseUp(button, Shift, x, y);
end;
SDL_QUITEV: Terminate := True;
SDL_VIDEOEXPOSE: Paint();
end;
end;
end;
finally
AppDestroy();
end;
except
on E: Exception do LogWrite('MainWindow.Run(): ' + E.Message);
end;
end;
procedure TMainWindowSDL.SetCaption(const Value: string);
begin
inherited SetCaption(Value);
SDL_WM_SetCaption(PChar(Value), nil);
end;
28.07.07
Обработка клавиатуры работает. Дополнительно слегка изменил вывод на экран, вынеся Flip в отдельный метод. Заметно ускорился вывод на экран.
Поскольку с текстами пока затык, решил начать делать монстров и НПС. Насчет вывода текста на экран - надо разобраться с модулем SDL_sfont. Вроде он делает все, что мне надо.
Есть еще одна идея для игры, но надо подумать. Заменить просто голод и жажду более широкими потребностями. Точнее, голод по разным продуктам. То есть например, на хлебе и воде долго не протянешь. Смысл - чтобы на зиму заготавливать не только копченое мясо или гречку. Через полгода питания одной гречкой человека станет тошнить только от ее вида. Тут надо подумать, как лучше это реализовать? Включить в описание каждого продукта перечень составных элементов? Или заменить состав продукта перечнем вкусов? В общих чертах - заменяем для каждого продукта один параметр (питательность) несколькими (для простоты - питательность А, Б, В и т.д.). И отдельно просчитывать голод по каждому параметру. Если например не хватает элемента А, и его больше всего в огурцах - выводить сообщение "Персонаж хочет огурцов". Если поесть других продуктов, в которых этого элемента тоже много - можно голод по этому параметру удовлетворить. Но зато можно получить пресыщение по другому элементу Б, что тоже нехорошо - теперь персонажа какое-то время будет тошнить от продуктов, содержащих этот элемент в некотором кол-ве, превышающем определенный уровень. В общем, это надо попробовать реализовать и посмотреть, что будет.
Обработка клавиатуры работает. Дополнительно слегка изменил вывод на экран, вынеся Flip в отдельный метод. Заметно ускорился вывод на экран.
Поскольку с текстами пока затык, решил начать делать монстров и НПС. Насчет вывода текста на экран - надо разобраться с модулем SDL_sfont. Вроде он делает все, что мне надо.
Есть еще одна идея для игры, но надо подумать. Заменить просто голод и жажду более широкими потребностями. Точнее, голод по разным продуктам. То есть например, на хлебе и воде долго не протянешь. Смысл - чтобы на зиму заготавливать не только копченое мясо или гречку. Через полгода питания одной гречкой человека станет тошнить только от ее вида. Тут надо подумать, как лучше это реализовать? Включить в описание каждого продукта перечень составных элементов? Или заменить состав продукта перечнем вкусов? В общих чертах - заменяем для каждого продукта один параметр (питательность) несколькими (для простоты - питательность А, Б, В и т.д.). И отдельно просчитывать голод по каждому параметру. Если например не хватает элемента А, и его больше всего в огурцах - выводить сообщение "Персонаж хочет огурцов". Если поесть других продуктов, в которых этого элемента тоже много - можно голод по этому параметру удовлетворить. Но зато можно получить пресыщение по другому элементу Б, что тоже нехорошо - теперь персонажа какое-то время будет тошнить от продуктов, содержащих этот элемент в некотором кол-ве, превышающем определенный уровень. В общем, это надо попробовать реализовать и посмотреть, что будет.
Первая заповедь фотолюбителя: Проявил себя - закрепи!
30.07.07
Попробовал включить прозрачность для спрайтов. Теперь вроде они рисуются с прозрачным цветом, но при первичной отрисовке для всех предметов фон черный. После прокрутки - нормально. Кроме того, после вставания героя поверх предмета и ухода с этой клетки изображение героя остается на предмете. Наверное, ошибка в последовательности отрисовки предметов. Другой вариант - надо добавить Flip после отрисовки карты. И вообще, вынести рисование предметов в отдельный метод.
31.07.07
Вместо монстров начну делать LOS. Сначала - отрисовка карты с видимыми и невидимыми тайлами, затем - пометка виденных тайлов и их отрисовка.
Пока отказался от рисования посещенных тайлов. Сначала разобраться с рисованием видимых тайлов. Для простоты возьмем квадрат 7х7 клеток, герой в центре. Требуется отрисовать все тайлы карты в этом квадрате. А также все предметы, если они там есть.
Сделал такое рисование. Но пока почему-то не работает корректно вывод. Неправильность в следующем: запаздывает рисование вновь видимых тайлов, и не стираются те, которые уже невидимы. Попробую сделать сейчас следующее: при вызове Hero.SetPosition все ранее видимые тайлы становятся невидимыми. Плюс перенести DoFOV после установки новой позиции.
Перенес. Теперь работает правильно. Отрисовка ранее посещенных тайлов осталась. При прокрутке рисует не вполне правильно. Вообще, получилось зрелище не для слабонервных. Еще и с учетом неправильно рисуемых предметов.
Попробовал включить прозрачность для спрайтов. Теперь вроде они рисуются с прозрачным цветом, но при первичной отрисовке для всех предметов фон черный. После прокрутки - нормально. Кроме того, после вставания героя поверх предмета и ухода с этой клетки изображение героя остается на предмете. Наверное, ошибка в последовательности отрисовки предметов. Другой вариант - надо добавить Flip после отрисовки карты. И вообще, вынести рисование предметов в отдельный метод.
31.07.07
Вместо монстров начну делать LOS. Сначала - отрисовка карты с видимыми и невидимыми тайлами, затем - пометка виденных тайлов и их отрисовка.
Пока отказался от рисования посещенных тайлов. Сначала разобраться с рисованием видимых тайлов. Для простоты возьмем квадрат 7х7 клеток, герой в центре. Требуется отрисовать все тайлы карты в этом квадрате. А также все предметы, если они там есть.
Сделал такое рисование. Но пока почему-то не работает корректно вывод. Неправильность в следующем: запаздывает рисование вновь видимых тайлов, и не стираются те, которые уже невидимы. Попробую сделать сейчас следующее: при вызове Hero.SetPosition все ранее видимые тайлы становятся невидимыми. Плюс перенести DoFOV после установки новой позиции.
Перенес. Теперь работает правильно. Отрисовка ранее посещенных тайлов осталась. При прокрутке рисует не вполне правильно. Вообще, получилось зрелище не для слабонервных. Еще и с учетом неправильно рисуемых предметов.
Первая заповедь фотолюбителя: Проявил себя - закрепи!
- Максим Кич
- Администратор
- Сообщения: 1642
- Зарегистрирован: 03 дек 2006, 20:17
- Откуда: Витебск, Беларусь
- Контактная информация:
Эх, ты меня опередил. Но у меня эта фишка возникла из общей концепции отказа от хитпойнтов: там ещё для того, чтобы нормально шла прокачка, нужно правильно питаться. Но пока колеблюсь — боюсь прибить геймплей.Dmiry писал(а):28.07.07
Есть еще одна идея для игры, но надо подумать. Заменить просто голод и жажду более широкими потребностями. Точнее, голод по разным продуктам. То есть например, на хлебе и воде долго не протянешь. Смысл - чтобы на зиму заготавливать не только копченое мясо или гречку. Через полгода питания одной гречкой человека станет тошнить только от ее вида. Тут надо подумать, как лучше это реализовать? Включить в описание каждого продукта перечень составных элементов? Или заменить состав продукта перечнем вкусов? В общих чертах - заменяем для каждого продукта один параметр (питательность) несколькими (для простоты - питательность А, Б, В и т.д.). И отдельно просчитывать голод по каждому параметру. Если например не хватает элемента А, и его больше всего в огурцах - выводить сообщение "Персонаж хочет огурцов". Если поесть других продуктов, в которых этого элемента тоже много - можно голод по этому параметру удовлетворить. Но зато можно получить пресыщение по другому элементу Б, что тоже нехорошо - теперь персонажа какое-то время будет тошнить от продуктов, содержащих этот элемент в некотором кол-ве, превышающем определенный уровень. В общем, это надо попробовать реализовать и посмотреть, что будет.
Dump the screen? [y/n]
- Sanja
- Администратор
- Сообщения: 791
- Зарегистрирован: 24 ноя 2006, 12:25
- Откуда: Новосибирск
- Контактная информация:
Максим Кич
Dmiry
Твоя фишка с едой смещает акцент с боя и тактики (что есть рогалик) на какой-то симулятор робинзона крузо. Короче и посоветовать нечего, т.к. не понятно что за рогалик ты делаешь.
И прибьёшь. Симс это ужасно.боюсь прибить геймплей.
Dmiry
Да можно и не пробовать. И так ясно. С Maelstrom-ом согласен.В общем, это надо попробовать реализовать и посмотреть, что будет.
Твоя фишка с едой смещает акцент с боя и тактики (что есть рогалик) на какой-то симулятор робинзона крузо. Короче и посоветовать нечего, т.к. не понятно что за рогалик ты делаешь.
Да... не стоит... Точнее - геймплей не прибьешь, просто странно это. В рогалике герой - Герой! Настоящий мужик. Сражается с ордами гоблинов. Переносит голод, холод и непогоду. Он должен уметь питаться тухлыми крысами. А не воротить нос от батона только потому, что на него не положили кусок колбасы с сыром. Лучше пига добавь. Вот без пига никакой герой точно долго не протянет.
Вот ответ:Короче и посоветовать нечего, т.к. не понятно что за рогалик ты делаешь.
аналог unreal world - т.е. симулятор чукчи-оленепаса
Если имеется в виду пиво, то со временем появится медовуха со всеми вытекающими последствиями.Лучше пига добавь. Вот без пига никакой герой точно долго не протянет.
Собственно, регулярно прокручиваю в голове те фишки, которые были в UrW, и пытаюсь представить, что можно сделать иначе. Например, ххочется иметь свободное строительство, не ограниченное тремя предопределенными постройками. Мясо или рыбу не только жарить, солить или сушить, а еще в леднике хранить. Зерно в амбаре (от мышей защищать), мед в ульях (от медведей), пиво в бочках (от проходимцев-приключенцев).
Для воды колодец выкопать (а не только снегом питаться).
Потерял серп - пошел в кузницу и новый выковал (насколько умения хватит).
Зимой ноги мерзнут - летом овцу постриг и носки связал (а их моль сожрала).
Первая заповедь фотолюбителя: Проявил себя - закрепи!
После перерыва продолжаю.
21.08.07
Начал делать систему тайм-менеджмента. За основу взял статью с Roguebasin, но переделываю на классы вместо использования процедурных типов.
Поменял картинки тайлов, взял готовые, перевел на размер 32х32. Выглядит симпатичнее. Глюк с неправильной отрисовкой при скролле карты остался. Пока нет идей, откуда это может возникать. Предположение - сначала надо очистить старое изображение.
Сегодня размышлял, как лучше сделать систему производства. Два варианта: либо выбирать использование скилла, либо использование станка. И в том, и в другом случае выбором будет определяться перечень возможных действий. Стоит ли включать использование схем/чертежей? Например, при старте персонаж умеет делать только несколько базовых вещей, которые он изучил во время детства/взросления, а остальное - надо узнавать у соответствующих мастеров. Например, сделать шалаш может любой, а вот построить дом или баню - только тот, кто учился у плотника. Можно включить возможность самостоятельного изучения - например, имея топор, любой сможет вытесать гладкое бревно после сотни запорченных деревьев. Другое дело, что при обучении у плотника число запорченных деревьев будет исчисляться в худшем случае одним-двумя десятками.
23.08.07
Сделал тестовый пример для проверки, как работает тайм-менеджер. В дельфях пример заработал. ОСталось приспособить его к своему проекту, плюс определиться, какое действие сколько времени занимать будет.
Сейчас задумался - как реализовать прерывание действия при наступлении какого-то события. Например, в UrW персонаж мог бросить свое занятие, если получал рану, обморожение, или по команде с клавиатуры. Как вариант: выделить отдельное событие - действие персонажа. Если идет команда с клавиатуры - это действие прекращается и удаляется из очереди (после подтверждения). Надо подумать - прерванные действия как потом предолжить? Ведь если прерваться на середине тесания бревна - потом надо будет не тесать заново, а начать уже с середины. С другой стороны, некоторые действия нельзя прерывать. Точнее, можно прервать безболезненно (рыбалка), или при прерывании действия результат будет утрачен. Тогда удастся избежать ситуации "наполовину натянутый арбалет".
21.08.07
Начал делать систему тайм-менеджмента. За основу взял статью с Roguebasin, но переделываю на классы вместо использования процедурных типов.
Поменял картинки тайлов, взял готовые, перевел на размер 32х32. Выглядит симпатичнее. Глюк с неправильной отрисовкой при скролле карты остался. Пока нет идей, откуда это может возникать. Предположение - сначала надо очистить старое изображение.
Сегодня размышлял, как лучше сделать систему производства. Два варианта: либо выбирать использование скилла, либо использование станка. И в том, и в другом случае выбором будет определяться перечень возможных действий. Стоит ли включать использование схем/чертежей? Например, при старте персонаж умеет делать только несколько базовых вещей, которые он изучил во время детства/взросления, а остальное - надо узнавать у соответствующих мастеров. Например, сделать шалаш может любой, а вот построить дом или баню - только тот, кто учился у плотника. Можно включить возможность самостоятельного изучения - например, имея топор, любой сможет вытесать гладкое бревно после сотни запорченных деревьев. Другое дело, что при обучении у плотника число запорченных деревьев будет исчисляться в худшем случае одним-двумя десятками.
23.08.07
Сделал тестовый пример для проверки, как работает тайм-менеджер. В дельфях пример заработал. ОСталось приспособить его к своему проекту, плюс определиться, какое действие сколько времени занимать будет.
Сейчас задумался - как реализовать прерывание действия при наступлении какого-то события. Например, в UrW персонаж мог бросить свое занятие, если получал рану, обморожение, или по команде с клавиатуры. Как вариант: выделить отдельное событие - действие персонажа. Если идет команда с клавиатуры - это действие прекращается и удаляется из очереди (после подтверждения). Надо подумать - прерванные действия как потом предолжить? Ведь если прерваться на середине тесания бревна - потом надо будет не тесать заново, а начать уже с середины. С другой стороны, некоторые действия нельзя прерывать. Точнее, можно прервать безболезненно (рыбалка), или при прерывании действия результат будет утрачен. Тогда удастся избежать ситуации "наполовину натянутый арбалет".
Первая заповедь фотолюбителя: Проявил себя - закрепи!
25.08.07
Сейчас задумался - надо почти полностью переделывать систему обработки событий в игре. При новой системе исчезает процедура NextTurn. Остается система учета времени (и времен года). Какие могут возникнуть ситуации: регулярное уменьшение значения сытости, при нахождении на холоде наступает обморожение. Календарь в любом случае остается постоянно. Это понадобится для учета времени суток и времен года. Надо ли делать изменение длины дня в зависимости от времени года? В UrW это вроде бы есть.
26.08.07
Попробовал продумать, какие действия могут быть в системе учета времени. Получилось примерно следующее перечисление:
- кратковременные и длительные
- прерываемые и не прерываемые
- с продолжением действия и без продолжения
- без потери ресурсов, с частичной потерей, с полной потерей
Примеры получились следующие:
1) кратковременное, не прерываемое: шаг, удар оружием
2) длительное, не прерываемое игроком, с продолжением: сон
3) длительное, прерываемое, без продолжения, с полной потерей ресурсов: приготовление мяса или рыбы
4) длительное, прерываемое, без продолжения, без потери ресурсов: рыбалка, рубка леса(?)
5) длительное, прерываемое, с продолжением, без потери ресурсов: постройка дома
6) длительное, прерываемое, с продолжением, с частичной потерей ресурсов: ???
7) длительное, прерываемое, с продолжением, с полной потерей ресурсов: ?не бывает?
Задумался над необходимостью введения разделения на длительные и прерываемые действия. Получается, что если действие короткое, то оно не прерываемое, если длинное - прерываемое. Надо над этим еще подумать. Пока надо продумать механизм прерывания действия. Это может происходить как по команде с клавиатуры, так и по наступлению некоторых других событий. Например, при обморожении надо выдать запрос - остановить зимнюю рыбалку или продолжить. Или во время сна услышать шорох и проснуться.
Сейчас задумался - надо почти полностью переделывать систему обработки событий в игре. При новой системе исчезает процедура NextTurn. Остается система учета времени (и времен года). Какие могут возникнуть ситуации: регулярное уменьшение значения сытости, при нахождении на холоде наступает обморожение. Календарь в любом случае остается постоянно. Это понадобится для учета времени суток и времен года. Надо ли делать изменение длины дня в зависимости от времени года? В UrW это вроде бы есть.
26.08.07
Попробовал продумать, какие действия могут быть в системе учета времени. Получилось примерно следующее перечисление:
- кратковременные и длительные
- прерываемые и не прерываемые
- с продолжением действия и без продолжения
- без потери ресурсов, с частичной потерей, с полной потерей
Примеры получились следующие:
1) кратковременное, не прерываемое: шаг, удар оружием
2) длительное, не прерываемое игроком, с продолжением: сон
3) длительное, прерываемое, без продолжения, с полной потерей ресурсов: приготовление мяса или рыбы
4) длительное, прерываемое, без продолжения, без потери ресурсов: рыбалка, рубка леса(?)
5) длительное, прерываемое, с продолжением, без потери ресурсов: постройка дома
6) длительное, прерываемое, с продолжением, с частичной потерей ресурсов: ???
7) длительное, прерываемое, с продолжением, с полной потерей ресурсов: ?не бывает?
Задумался над необходимостью введения разделения на длительные и прерываемые действия. Получается, что если действие короткое, то оно не прерываемое, если длинное - прерываемое. Надо над этим еще подумать. Пока надо продумать механизм прерывания действия. Это может происходить как по команде с клавиатуры, так и по наступлению некоторых других событий. Например, при обморожении надо выдать запрос - остановить зимнюю рыбалку или продолжить. Или во время сна услышать шорох и проснуться.
Первая заповедь фотолюбителя: Проявил себя - закрепи!
12.09.07
Все еще затыкаюсь с отрисовкой карты на экране. Попробовал вывести в дамп содержимое клеток карты (видимость и известность). В памяти все правильно, а вот отрисовка происходит неправильно. Надо разбираться с SDL. Кажется, проблема именно в этом.
Переделываю систему тайм-менеджмента. Для отладки и разборки завел отдельный проект. Частично перевел на классы. Осталось оформить само событие в виде отдельного класса, плюс разобраться как эти события будут работать параллельно. Сейчас фактически работает только одно событие - обновление календаря. Надо бы добавить еще парочку событий работающих параллельно, и проверить их работу.
Решил разделить событие на две части: первая - это то, что хранится в списке событий, второе - какие действия выполняются при наступлении события. То есть вместо одного класса TimeEntity появляются два: TimeEntity и TimeAction.
Все еще затыкаюсь с отрисовкой карты на экране. Попробовал вывести в дамп содержимое клеток карты (видимость и известность). В памяти все правильно, а вот отрисовка происходит неправильно. Надо разбираться с SDL. Кажется, проблема именно в этом.
Переделываю систему тайм-менеджмента. Для отладки и разборки завел отдельный проект. Частично перевел на классы. Осталось оформить само событие в виде отдельного класса, плюс разобраться как эти события будут работать параллельно. Сейчас фактически работает только одно событие - обновление календаря. Надо бы добавить еще парочку событий работающих параллельно, и проверить их работу.
Решил разделить событие на две части: первая - это то, что хранится в списке событий, второе - какие действия выполняются при наступлении события. То есть вместо одного класса TimeEntity появляются два: TimeEntity и TimeAction.
Первая заповедь фотолюбителя: Проявил себя - закрепи!
Использовать станки - идея удачная. Тогда инфа о завершенности действия может храниться в самом станке. Строящийся дом или подрубленное дерево, например - это тоже станок. Только нужно оговориться. Например, если куешь меч и прервался - в следующий раз нужно снова раздуть мехи и тд. А арбалет - это просто итем, натянуть его наполовину нельзя.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 48 гостей