Пожелания, Предложения по развитию сюда Опции

[WKnight]

{ num_4 } в принципе неправильно преобразовывать в num_4 без скобок. но как выяснилось, даже гуру иногда нарушают правила, приходится делать исключения (IMG:style_emoticons/default/smile.gif)
а извлекать из { num_4 } лишние пробелы, при этом проверяя, чтоб ничего не нарушить, слишком затратно в плане быстродействия.


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

Сообщение отредактировал WKnight - 25.3.2012, 14:28

[DarkMaster]

Я не говорил, что она готовая. В общем хотел завтра но тем не менее.. Вопсчем у нас появилась вика. Беда в том, что у меня времени вообще нет. 2 переезда, переоформление квартир, отправка бабушки в другой город, в общем весело. Щас вытащу шаблончик, напишу пару строк.

[WKnight]

Поздравляю!

Там помоему говорилось что проблемы с преобразованием всяких спойлеров итд, но не суть, главное текст вроде был (IMG:style_emoticons/default/smile.gif), что вобщем тоже не суть, главное с чегото начать (IMG:style_emoticons/default/smile.gif)

Я про запарки со временем уже давно перестал сообщать, они то есть, то неожиданно кончаются, то внезапно появляются, так что даже сообщить некогда. Да и большинство всеравно не прочитает об этом, и будут долбиться и обижаться почему им не отвечают (IMG:style_emoticons/default/smile.gif)

[DarkMaster]

Кнайт, текста нет. Чтобы начинать писать текст, надо было сразу его форматировать. Форматировать у меня не получалось не по-дебильному. Когда получилось дестрашена поймал за язык про вику и двух недельное разбирательство со стилями, форматированием пошло коту под хвост и началось разбирательство с викой.

[WKnight]

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

[EL-GReeN]

Очень не хватает глобальных переменных, и проверок нажатых кнопок.
load_array работает медленно.

[DarkMaster]

и проверок нажатых кнопок.

Я бы даже сказал возможности создать эвент на нажатия клавиш. Именно внутри скрипта. Ну не нужно делать вагон вкладок только для того, чтобы сменить 1 переменную. До прозрачных хоткеев приходилось каждый раз при включении/выключенни скрипта включать и выключать хоткеи...

Сообщение отредактировал DarkMaster - 26.3.2012, 19:31

[EL-GReeN]

Я бы даже сказал возможности создать эвент на нажатия клавиш. Именно внутри скрипта.

В точку.

Получилось обойти отсутствие глобальных переменных, записью-чтением в память программы, но нагромождение кода не радует, и еще есть вероятность занять ячейки которые отвечают за что то критичное, любимые танцы с бубном (IMG:style_emoticons/default/laugh.gif)

[WKnight]

Очень не хватает глобальных переменных

Я периодически почитываю этот пункт в 2do, но както не придумывается как "глобальные" отличать от остальных?

Я бы даже сказал возможности создать эвент на нажатия клавиш. Именно внутри скрипта.

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

Ну не нужно делать вагон вкладок только для того, чтобы сменить 1 переменную.

Не массивные переменные достаточно просто меняются на панельке параметров персонажа. По идее скрипт даже приостанавливать не требуется.

[DarkMaster]

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

По сути да.
что-то вроде:
event <name> [bind]
код
end_event
Было бы так же интересно вызывать евент самим скриптом без клавиши(читай 2 зайцев).

Не массивные переменные достаточно просто меняются на панельке параметров персонажа.

Во время боя, тем более пвп это не прокатит.

както не придумывается как "глобальные" отличать от остальных?

Можно сделать вариант в стиле пилота #преременная.g, и как хранить сразу становится понятно.
Можно сделать дополнительный преффикс.
Можно просто объявить в начале, что она глобальная, оставив дальнейший синтаксис не измененным.

Сообщение отредактировал DarkMaster - 27.3.2012, 4:17

[DarkMaster]

примерно в тот же огород. когда-то шла речь о подвкладках, для создания проектов предполагающих несколько вкаладок без путаницы и проблем. возможно даже дерево... оно актуально до сих пор (IMG:style_emoticons/default/wink.gif)

[EL-GReeN]

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

Как пример из одного движка:

keyboard_check(key) Возвращает, если нажата клавиша с конкретным клавиатурным кодом.
keyboard_check_pressed(key) Возвращает, если клавиша с конкретным клавиатурным кодом была нажата с поры выполнения последнего шага.
keyboard_check_released(key) Возвращает, если клавиша с конкретным клавиатурным кодом была отпущена с поры выполнения последнего шага.
keyboard_check_direct(key) Возвращает, если нажата клавиша с конкретным клавиатурным кодом, проверяемая непосредственно аппаратные средства. Результат независим от того, какое приложение рассматривается.

Станут возможными такие условия:

Код

if keyboard_check(32) //код пробела
say Вы нажали пробел.
end_if

if keyboard_check(32) and keyboard_check(18) //код пробела и альта
say Вы нажали пробел и альт.
end_if

[Zeleax]

Ну тогда еще добавлю, что должна быть возможность "прозрачной" и "непрозрачной" проверки:
- прозрачная - код клавиши проверяется пилотом и в любом случае нажатие передается далее в рабочее окно (не убирается из очереди)
- непрозрачная - то же что и выше, но в случае если нажата указанная клавиша, то код клавиши удаляется из очереди и не передается в рабочее окно

[DarkMaster]

Как пример из одного движка:

А как именно идет проверка? Нажата ли в данный момент(создается именно такое впечатление)? Или все это какие-то хуки/дампы, очередь? Игра на перегонки скрпипта и быстрых пальчиков не лучший варинт, я бы даже сказал, что это провальное решение для наших целей.

[EL-GReeN]

Как именно там сделано я не знаю исходников нет.
Задача расчета успеет ли сработать условие на нажатие, зависит от пользователя, то есть (сработало условие)-->(обработка действий) если пока обрабатываются действия произошло нажатие то условие не сработает, что есть не хорошо.

что-то вроде:
event <name> [bind]
код
end_event
Было бы так же интересно вызывать евент самим скриптом без клавиши(читай 2 зайцев).

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

[Zeleax]

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

:event1 key(^S) parallel // вызов в параллельном потоке
return

procedure event2 key(^2) // вызов в потоке основной программы
end_proc

[DarkMaster]

мысль очень правильная.
Более того в случае запуска копии возникает интересный вопрос с переменными. В ходе работы нескольких эвентов может получиться так, что один изменит значения в расчетах другого(набор переменных то один). Для адекватной работы придется создавать локальные переменные для каждого эвента, делать функцию вывода результата, продумывать каким образом обращаться к переменным из основного скрипта(считывать при входе? - будут устаревшие данные; при обращении? - может исказиться копией эвента). Мороки много. Прорабатывать все эти тонкости имхо берд и сделать чем проще, тем лучше. Запуск нескольких экземпляров можно конечно сделать и в определенных случаях точно хуже не будет, но обращаться надо будет с ним хорошо подумав.

А вот ничего не делать при повторном запуске и очередь очень правильные варианты.

[EL-GReeN]

мысль очень правильная.
Более того в случае запуска копии возникает интересный вопрос с переменными. В ходе работы нескольких эвентов может получиться так, что один изменит значения в расчетах другого(набор переменных то один). Для адекватной работы придется создавать локальные переменные для каждого эвента, делать функцию вывода результата, продумывать каким образом обращаться к переменным из основного скрипта(считывать при входе? - будут устаревшие данные; при обращении? - может исказиться копией эвента). Мороки много. Прорабатывать все эти тонкости имхо берд и сделать чем проще, тем лучше. Запуск нескольких экземпляров можно конечно сделать и в определенных случаях точно хуже не будет, но обращаться надо будет с ним хорошо подумав.

А вот ничего не делать при повторном запуске и очередь очень правильные варианты.

Как вариант:
Пилот (глобальные переменные существующие до закрытия пилота, доступ из любого кода)
Запущенный Скрипт (локальные переменные существующие до остановки скрипта, доступ из ивентов такой же как из основного скрипта если совпадает имя)
Ивент (локальные переменные существующие до завершения ивента, без доступа, либо при вызове ивента он возвращает свой ID по которому можно обращаться к переменным)

[Zeleax]

Очень хочется иметь переменные для каждого скрипта, сохраняющие значения даже если скрипт остановлен, чтобы использовать их значения при повторном запуске того же скрипта. При необходимости можно им давать особые имена (##пример или $$пример).
Использование дополнительного скрипта в режиме "Пауза" только для хранения переменных предлагаю считать извращением ))

Сообщение отредактировал Zeleax - 4.4.2012, 16:23

[esqado]

Пропаганда и преумножение извращенцов )))
А для каких целей это нужно?