QSP-плеер: вопросы и предложения

Предложения с объектами просто не рассматриваются хД

Перетаскивание предметов делается и сейчас легко:
$локация[’Стул’]=$curloc
$локация[’Стул’]=‘игрок’

Otus7:

Реализация перетаскивания объекта из локации в локации с возможностью бросить и оставить объект в любой локации - это тот еще гемморой

Никакой это не геморой. Легко и просто решается использованием двумерных массивов. Я добился сброса и сохранения предметов на любой локации, с последующей возможностью их поднять.

aleksversus,
Непонятно, зачем двумерные массивы, если можно обойтись одномерными.

Logger:

Да, но при исскуственном цикле всегда возможны перерывы в музыке на доли секунды, что будет несколько портить впечатление. Или нужно слишком часто проверять (порядка 5-10 раз в секунду)

Думаю, можно обойтись без постоянной проверки, зная продолжительность воспроизводимого трека. Перерывов можно избежать. Правда музыку добавлять я еще не пытался, но в скором времени дойду и до этого.

Nex:

aleksversus,
Непонятно, зачем двумерные массивы, если можно обойтись одномерными.

Хочу такой код.

aleksversus,
см. сообщение Байта(#18), прямо перед твоим первым сообщением в этой теме.

Nex,
Это годится только когда предметов небольшое количество. Как я понимаю, подъем в данном случае осуществляется путем создания действий “поднять” в зависимости от состояния переменной. Т.е. на локации, где сброшен предмет, выполняется такой код: if $локация[’стул’]=$curloc: act ‘взять стул’. Но в случае, когда требуется перетаскивать большое количество предметов, а локаций, на которых их можно сбрасывать, еще больше, прописывать каждый раз для каждого предмета такую гору строк - нерационально. Может я где-то что-то пропустил, и можно обойтись одномерными массивами, но простая задача: возможность сбрасывать сто предметов на ста локациях - дает нам десять тысяч возможных вариантов, и делать десять тысяч проверок нереально.

aleksversus,
а зачем в каждой локации писать?
достаточно прописать код один раз в служебной локации, и вызывать его при заходе в локацию ($ONNEWLOC).

Т.о. в “обычных” локациях писать ничего не придется, описания и действия с предметами будут добавляться автоматически.

Непонятно, зачем проверять каждый предмет отдельным условием. Составляем список предметов и потом в цикле, на $ONNEWLOC, проверяем, какие предметы находятся на текущей локации.

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

Это и сейчас делается очень просто.

Byte,
Просто? Что же, достаточно просто создавать новые переменные для каждого действия, но я говорю об облегчении “участи”.

Зачем для каждого действия? :)

AntiPod,
это у тебя просто от незнания языка. Напиши в теме “Как сделать?”, или создай новую тему, в которой опиши свои трудности, мы расскажем, как все реализовывается существующими операторами.