Форум » » AkUrq2 » Ответить

AkUrq2

Акела: AkUrq 2.12 beta 8 Потихоньку пишется новая акурка2, основанная на идее Sfeli и содержащая не малую долю его кода. Возможности пока довольно скромные, но это вопрос времени. требует только IE5 (Windows 98+) Что мы имеем:[quote]Операторы: ;комментарий :(локация) p (текст без кавычек) pln (текст без кавычек) goto (локация) proc (локация) btn (локация),(описание) (оператор)&(оператор) cls instr (переменная)=(текст без кавычек) (переменная)=(значение) if (условие) then (оператор) [else (оператор)] inv+ [число,]предмет inv- [число,]предмет invkill [предмет] perkill play (имя_файла)[.wav] input (переменная) end _ (продолжение предыдущей строки) (<= >= <> > < = - + * / ==) Системные метки: :Сommon[_номер] :use_(предмет)[_действие] Конструкции: #/$ ##(код символа)$ #%(имя переменной)$ #(имя переменной)$ Системные переменные: previous_loc current_loc last_btn_caption common music count_(метка) rnd[число] inv_(предмет) [/quote] Краткое описание языка (Выборочно использовалась помощь от Корвина) [more][quote]Операторы: ;комментарий - Помогает разработчику не запутаться в своём коде. Всё после ; игнорируется интерпретатором (до конца строки) Пример: pln Это будет напечатано.;А этот комментарий - до конца строки, напечатан не будет. :(локация) - Оператор обозначения меток. Пример: :локация Отличие от досурки - в метках поддерживаются конструкции #$, #%$, ##$. Если вы хотите сохранить совместимость с dos_urq не используйте в метках такие символы х) p (текст без кавычек) - Выводит на экран текст. pln (текст без кавычек) - Выводит на экран текст и переносит строку. goto (локация) - Переходит на указанную локацию. Если метки не существует, - оператор игнорируется. Пример: goto tower proc (локация) - Передает управление на указанную метку, но когда встречается end, - возвращает управление обратно, оператору, следующему за proc. Допустима вложенность. Если метки не существует, - оператор игнорируется. Пример: proc tower btn (локация),(описание) - Создает кнопку для выбора вариантов действия с надписью на ней (описание), при клике на ней будет осуществлен proc на системную метку Common (если такая есть), затем переход на (локация). Пример: btn tower,Взобраться на башню (оператор)&(оператор) - объединение нескольких операторов. Пример: cls&pln Текст&btn tower,Взобраться на башню cls - Очищает экран instr (переменная)=(текст без кавычек) - Устаревший оператор. Присваивает переменной текстовое значение. Всё что после "=" заносится в переменную (переменная), поэтому писать следует без кавычек. Пример: instr time=время - 17:42 (Альтернатива time="время - 17:42") (переменная)=(значение) - Присваивает переменной (значение). Пример: time="время - 17:42" min=42 В первом случае присвоили строку, во втором число. Для совместимости с досуркой, которая некорректно понимает кавычки, крайне не рекомендуется присваивать строки таким способом, желательно использовать для этих целей устаревший оператор instr. if (условие) then (оператор) [else (оператор)] - Оператор условия. Можно делать сложную конструкцию, используя &, and, or, not и скобки. Допустимость любой степени вложенности if'ов сохраняется, else всегда соответствует последнему if'у. Пример: if inv_Спичек>=50 then btn buildHouse, Построить домик из спичек inv+ [число,]предмет - Добавляет в инвентарь предмет(ы). Если [число,] не указано, добавляется 1 предмет. Пример: inv+ Жемчужина inv+ 5,Жемчужина В первом случае добавится одна Жемчужина, во втором пять. inv- [число,]предмет - Удаляет предмет(ы) из инвентаря. Если [число,] не указано, удалится 1 предмет. Пример: inv- Жемчужина inv- 5,Жемчужина Количество предметов не может быть отрицательным. invkill [предмет] - Без параметров - удаляет все предметы из инвентаря, Если [предмет] указан, то удаляет только предметы типа [предмет]. Пример: invkill invkill Жемчужина В первом случае удаляются все предметы, во втором только все жемчужины. perkill - Очищает все ранее присвоенные переменные. play (имя_файла)[.wav] - Однократно проигрывает из папки квеста указанный файл. Если расширение явно не указано, то по умолчанию ищется .wav файл. Пример: play 05 - Forsaken.mp3 play 05 - Forsaken В первом случае проиграется файл "05 - Forsaken.mp3", во втором - "05 - Forsaken.wav" input (переменная) - Просит пользователя ввести строку, значение которой будет присвоено указанной переменной. Пример: input x Для совместимости с досуркой, которая некорректно понимает присвоенные в input строки, перед воодом строки следует делать так: instr x= input x end - Оператор конца локации. На этом месте выполнение квеста обычно прерывается для ожидания дальнейших действий игрока (например нажатие на кнопку). Или же происходит возврат к следующему после proc`а оператору, если до этого встречался proc (смотри подробнее proc). _ (продолжение предыдущей строки) - Оператор склеивает строку с предыдущей. Пример: pln Текст в этой строке слишком длинный, поэтому мож _ет следует перенести его сюда? (<= >= <> > < = - + * / ==) - Используются в операторе if и операторе присваивания. Подробнее о ==: == Дает истину при сравнении строковой переменной со строкой по правилам сравнения регулярных выражений, т.е.: Пример: if "aBBBa"=="a*a" then ;Верно if "F"=="[A-Z]" then ;Верно. if "F"=="[!A-Z]" then ;Неверно. if "a2a"=="a#a" then ;Верно. if "aM5b"=="a[L-P]#[!c-e]" then ;Верно. if "BAT123khg"=="B?T*" then ;Верно. if "CAT123khg"=="B?T*" then ;Неверно. Верно значит что условие даст истину и выполнится then Неверно - условия ложно, и выполнится else (если он есть). На самом деле это несложно. Описание: ? Любой одиночный символ * Ноль или более символов # Любая одиночная цифра (0-9). [charlist] Любой одиночный символ в классе символов (списке) [!charlist] Любой одиночный символ не принадлежащий классу символов Примечание: в Досурке этот оператор работает по другому. За подробностями к Виктору. Системные метки: :Сommon[_номер] - Локация вызывается после каждого нажатия на кнопку. Зависит от системной переменной common, (при common=0 вызывается "common", при common=12 уже "common_12", и так далее) Пример: :Сommon pln Если вставить этот кусок кода в большой квест, то к его концу всем точно надоест эта надпись х) end :use_(предмет)[_действие] - Системная локация, если она существует, то с предметом можно совершать действия. Если действие опущено, то по умолчанию оно будет "Осмотреть". Таких локаций может быть несколько, но они не должны называться одинаково. Конструкции: Конструкции которые заменяются при выполнении кода значением. #/$ - Заменяется на перенос строки. ##(код символа)$ - Заменяется на аски символ с указанным кодом. Обычно используется для вывода служебных символов (";", "$"..) #%(имя переменной)$ - Устаревшая конструкция. Используется вывода строковых переменных в досурке. #(имя переменной)$ - Оператор для вывода переменных. В досурке - только числовых. Для совместимости всегда выводите строки с помощью #%(имя переменной)$ пустые конструкции типа #$ заменяются на пробел Системные переменные: previous_loc - Содержит имя предыдущей локации current_loc - Содержит имя текущей локации last_btn_caption - Содержит описание последней нажатой кнопки. common - Переменная управляющая работой системной локации Сommon (смотри подробнее "системная локация Сommon") Пример: common=1 music - зацикленно проигрывает из папки квеста указанный файл. Если расширение явно не указано, то по умолчанию ищется .mid файл. Пример: music=5 music="5.mid" instr music=5.mid Во всех случаях проигается файл "5.mid" count_(метка) - Переменная хранит в себе число заходов на метку. rnd[число] - Если число опущено, то при обращение генерирует случайное число от 0 до 1. Если обозначено, то случайное целое число от 1 до число. inv_(предмет) - Системная переменная для управления инвентарём. Пример: inv_жемчужина=50 if inv_жемчужина<5 then pln Что-то у тебя мало жемчужин! Возьми-ка ещё одну!&inv+ Жемчужина В первом случае, сколько бы у вас не было жемчужин, их станет 50, во втором - если жемчужин меньше пяти, то выводится текст и в инвентарь добавляется ещё одна жемчужина. Существует устаревший вариант проверки вещей в инвентаре, для совместимости с RipUrq: Пример: if 2 жемчужина then pln Хмм, у тебя есть две жемчужины (или даже больше)! Ладно проходи! if Жемчужина then pln Хмм, у тебя есть жемчужина! Ладно проходи! В первом случае проверяется есть ли у игрока две жемчужины. Проверка пройдет успешно если у игрока две или больше жемчужин. Альтернатива if inv_жемчужина>=2 then .... В втором случае проверяется есть ли у игрока предмет жемчужина. Проверка пройдет успешно если у игрока одна или больше жемчужин. Альтернатива if inv_жемчужина>=1 then .... Дополнения приветсвуются.[/quote][/more] очень короткий FAQ:[quote]В1: Тут слишком мало возможностей для моих извращённых идей :) где синусы, вычисление корня, тысячи картинок, xbtn, и вообще где первая акурка? (привет Суд :) О1: Думаю первая акурка дорабатываться больше не будет. Новые операторы в квотерое появятся со временем, но не так как они появлялись в первой акурке: операторы будут появляться только после того как их синтаксис утвердят большенство метров, к которым я отношу: Евгения, Сфели, Виктора, Корвина. Уважаемый Борщевский разумеется тоже метр, но поскольку он ненавидит урку, я боюсь его спрашивать :) В2: Где инвентарь? Месяц найти не могу уже. (привет Хлом :) О2: Клавиши I и F6 открывают инвентарь. В3: Как теперь закрыть инвентарь? (привет Гор ) О3: Теми же клавишами. В4: Как закрыть текущий квест и начать новый? О4: F2 выводит в меню. В5: Что можно настроить в ини файле? О5: Можно изменить шрифт (Goraph) и включить/отключить управление кнопками на цифрах. Если результат вас не устроит, а как было вы не запомнили х) то удалите ини файл[/quote] Ну и выражаю благодарность Sfeli который написал добрую половину функций. Их легко вычислить - если чтото в квотерое работает без проблем - это писал Сфели) Если глючит - то Акела) Сообщения в этой теме буду периодически удалять

Ответов - 73, стр: 1 2 3 4 All

hi: Вам мо квешн плиз обана: Картинки 2-я акурка поддерживает? Так сложно ответить? Да / Нет / Не понял вопроса

Nex: Можно скачать и проверить. Было б где скачать, а то ссылка в верхнем посте, по доброй урковской традиции, ведёт в никуда.

hi: Nex пишет: Можно скачать и проверить. Было б где скачать, а то ссылка в верхнем посте, по доброй урковской традиции, ведёт в никуда. А здесь проверял? http://urq.plut.info/soft Если хочешь пришлю 2-ю. Но у меня не получилось применить к 2-й версии акурки ни один из картинковых методов 1-ой... А списке операторов в самом верхнем посте вобще ничего такого нет. Наверное всё-таки 2-я идёт без картинок. Не успелось...


noname: hi пишет: Вам мо квешн плиз обана: Картинки 2-я акурка поддерживает? Так сложно ответить? Да / Нет / Не понял вопроса лично я ничего про картинки во 2-й акурке ничего не знаю. а про саму эту 2-ю акурку узнал только на днях- тогда же и сообщение в эту тему написал.

Victor: Nex пишет: Можно скачать и проверить. Было б где скачать, а то ссылка в верхнем посте, по доброй урковской традиции, ведёт в никуда.Обновил ссылки в закрепленном посте "urq_dos, Akurka, текущие версии".

ghoest: xbtn локация_процедуры, локация_перехода, название_кнопки идеально! Бред. чем это лучче конструкции в стандартной УРКе: btn локация_процедуры, название_кнопки end :локация_процедуры goto локация_перехода end ???? Гениальное изобретение велосипеда, в котором руль приколочен прям к колесу, для удобства Ну, то есть, нафига придумывать команду, вызывающую последовательно две (три, насколько) локаций, если это преспокойно решается стандартными методами языка? Вообще, потребность в xBtn возникла из-за того, что обычный btn является всего лишь модификацией оператора goto и не способен передать ПАРАМЕТР в целевую локацию, что и не позволяло вешать на кнопку какой-то обработчик событий, кроме собственно перехода. Либо как сейчас в АкУРКе, (хотя точно не помню место для указания фигурных скобок): xBtn {переменная=значение}, Локация, Кнопка (), чтобы потом переменную обработать в локации. Причем достаточно только такой, жесткой конструкции (одна_переменная=одно_значение), а далее можно творить чудеса. Например, передать в переменной целый список значений (и разбить его с помощью token), или с помощью #$ передать кусок кода. либо что то вроде xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр] //[] - значит, что применение опционально опционально end :Локация [Параметр] Параметр = Параметр+Параметр.... и т.д. end Но второй вариант более принципиально изменяет концепцию языка URQL, по сути предусматривается возможность задания параметра/списка параметров для метки, которая в данном случае приближается по функциональности к процедуре

Korwin: xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр] Номер не пройдет, так как по синтаксису языка URQL только в последнем параметре оператора может быть несколько запятых. Название кнопки должно быть последним, следовательно, только: xbtn локация перехода,{параметр(ы)},название кнопки, в котором могут быть запятые

ghoest: ну да, ну да. Второй вариант это конечно уже не URQL, а более другой язык :) Однако, вопрос о том, КАКИМ быть xBtn, кажется, по прежнему открыт? То что БЫТЬ должен - это однозначно, так как Btn, как простого перехода, явно не хватает. Однако xBtn в текущем варианте АкУРКи 1: xBtn {Произвольный_код}, Локация, Название кнопки действительно выглядит не по УРКовски. Но: кто сказал, что ОБЯЗАТЕЛЬНО нужен _произвольный код_? Поверьте, вполне достаточно определить значение какой либо переменной, а там уже творчески подключать мозги и делать с ней (переменной) все что угодно. Например, так: xBtn_VAR - системная переменная, устанавливаемая при нажатии кнопки xBtn. синтаксис xBtn : xBtn Значение, Локация_Перехода, Название кнопки //где Значение (или указывать здесь переменную?) как раз и устанавливается в xBtn_VAR. Пример :question pln 2х2=? xBtn 3, Answer, Три xBtn 4, Answer, Четыре xBtn До фига, Answer, Пять btn NoAnswer, Не знаю end :NoAnswer pln Я не знаю end :Answer pln Мой ответ #xBtn_VAR$ p Это if xBtn_VAR = 4 then p правильный else p неправильный pln ответ end Сие более по УРКовски - дешево и сердито. Естественно, это черновой вариант ЗЫ. Подумалось, что уже сейчас можно реализовывать _что-то вроде_ этого, ибо доступна переменная LastButtonCaption, однако это не совсемь есть гут, потому что Caption у Button относится уже к внешним элементам квеста и не очень хорошо приспособлена для внутрикодовых нужд. ЗЗЫ Не. все таки, если быть совсе точным, то синтиксис должен быть таким: xBtn Вычисляемое_Выражение, Локация_Перехода, Название кнопки

fireton: [pre]:Answer pln Мой ответ #xBtn_VAR$ p Это if xBtn_VAR = 4 then p правильный else p неправильный pln ответ end [/pre] Фигню ты написал. Кнопок может быть переменное количество, отдельные кнопки могут определяться в proc-ах и локации-счетчике. И как следить за этим зоопарком чтобы вычислить нужную кнопку? Самой правильной xbtn будет xbtn вообще без локации. Только название и список операторов. А переход можно сделать и с помощью goto. Правда тогда начинается гимор с системными переменными, но можно отслеживать goto внутри xbtn...

ghoest: fireton пишет: Фигню ты написал НЕА. Сие как раз задумывалось для ДИНАМИЧЕСКОЙ генерации кнопок. Поверьте, ОДНОЙ ПЕРЕМЕННОЙ запросто хватит, для того, чтобы обработать все возможные излишества :). Честно-честно. Приведенный пример, конечно не показатель, но поверьте, мне приходилось с СУЩЕСТВУЮЩИМ xBtn обходиться всего-навсего одним оператором в фигурных скобках {переменная=значение} До этого можно дойти чисто абстрактно, без приведения примеров. Введение даже единственной ПЕРЕМЕННОЙ в xBtn УЖЕ убирает жесткую статичность, присущую указанию метки перехода в обычном Btn, и этого достаточно(!) ДОСТАТОЧНО - в том смысле, конечно, что можно и огороду нагородить с более сложными конструкциями, что (возможно) будет и несколько удобнее, но уже не так принципиально. В принципе, самый правильный xBtn возможен и без локации ВООБЩЕ, с одной только переменной :-D (точнее, нужна предопределенная локация типа Common) - но тут уже да, будет пахнуть извращениями ЗЫ И как следить за этим зоопарком чтобы вычислить нужную кнопку? Я так думаю - раз уж мы ГДЕ-ТО вставляем кнопку, то именно там-то мы ее и обозначим. опять же - ОДНОЙ переменной. Ибо (опять же, абстрактно) - ОДНА кнопка = ОДНО событие, пусть даже следствием этого события будет изменение миллиона переменных и выполнение миллиона строк кода:) Важен принцип - переменная, в отличие от метки, НЕ СТАТИЧНА, она не определяется (как метка) при написании кода, она может изменяться - а это главное. Только название и список операторов. А переход можно сделать и с помощью goto И все это внутри фигурных скобок? Хммда... Будет весело смотреть на такой код... Вообще, конечно, если бы изначально в URQL был бы реализован такой принцип - то есть изначально btn выполнял бы список операторов, а не goto-переход, то это да, такой подход являлся более правильным, тут я согласен. Но URQL сейчас именно такой, какой он уже есть. Я всего лишь предложил НАИБОЛЕЕ МИНИМАЛИСТСКИЙ способ решения проблемы ограниченности Btn, согласующийся с уже существующей идеологией языка.

noname: ghoest пишет: Вообще, потребность в xBtn возникла из-за того, что обычный btn является всего лишь модификацией оператора goto и не способен передать ПАРАМЕТР в целевую локацию, что и не позволяло вешать на кнопку какой-то обработчик событий, кроме собственно перехода. это один из вариантов xbtn локация_процедуры, локация_перехода, название_кнопки идеально! в процедуре можно и соотв переменной значение присвоить, если тебя именно это волнует, а можно и любые другие операторы использовать. т е это- наиболее универсальный вариант. чем это лучче конструкции в стандартной УРКе: btn локация_процедуры, название_кнопки end :локация_процедуры goto локация_перехода end ???? а вот этим: xbtn #%локация_процедуры_ПАРАМЕТР$, #%локация_перехода_ГЛАГОЛ$, #% составное_название_кнопки$ т е ДО перехода передаются значения аргументов через соотв переменные (арг1, арг2, арг3, ... ) в соотв процедуре. ПОСЛЕ выполнения процедуры выполняем переход на локацию- обработчик. в случае 6-ти глаголов и 20-ти предметов при такой организации достаточно всего 6-ть локаций-обработчиков, обрабатывающих переданные аргументы, а не 120. т е, как ты верно заметил, потребность в xbtn возникла из-за потребности в передаче параметров. НО введя конструкцию xbtn локация_процедуры, локация_перехода, название_кнопки мы заведомо делаем язык более универсальным. не вижу никакого смысла специально ограничивать себя ТОЛЬКО передачей параметров. предложенная конструкция поможет решить и насущные и будущие проблемы, и даёт дополнительные, ещё неисследованные возможности. p.s. поясню различие ещё раз: чем это лучче конструкции в стандартной УРКе: btn локация_процедуры, название_кнопки end :локация_процедуры goto локация_перехода end ???? здесь локация перехода жёстко привязана именно к этой локации процедуры. бывает же необходимость передачи одного из возможных параметров одной из доступных локаций-обработчиков. независимых параметров может быть и более одного, но все эти случаи с составлением и передачей наборов параметров можно решить в процедуре. важно, чтоб выполняемая ДО перехода процедура НЕ была жёстко привязана к конкретной локации перехода. иначе- действително, можно было бы обойтись и без xbtn.

ghoest: noname пишет: НО введя конструкцию xbtn локация_процедуры, локация_перехода, название_кнопки мы заведомо делаем язык более универсальным. Да, если [локация_процедуры] станет именно ПРОЦЕДУРОЙ, новым типом в языке, а не просто локацией, меткой, как сейчас. Если же под [локация_процедуры] имеется в виду обычная URQL-овская метка (пусть и вызываемая как бы через proc), то ничего не меняется. Но сделать такую новую локацию-процедуру - это более жестокое изменение URQL (Кстати, в первом посте я и предлагал что то вроде (гипотетически) возможности описывать метку с возможность опционального указания у нее ПАРАМЕТРА, то есть метка становится как бы процедурой. Извращение еще то, конечно, но весь URQL весьма похож на извращение (не бить - это добрая шутка) Поясню смысл моего xBtn c переменной. Существующий механизм Btn предполагает в описании кнопки указание жестко и заранее известной метки, уже прописанной в код. То есть тут затруднено использование динамически создаваемых кнопок, плюс к тому, для того чтобы различать нажатие разных кнопок, необходимо указание в разных операторах btn разных меток. xBtn в моем варианте позволяет при указании одной и той же метки в разных операторах xBtn все же различать их, как раз путем установления значения переменной. И этого уже хватит для того чтобы построить обработку этих различий В ОДНОЙ локации Вариант же с подвешиванием на Btn (или xBtn) целого списка операторов, вообще каких то действий - принципиально БОЛЕЕ ПРАВИЛЬНЫЙ, но URQL изначально не пошел по этому пути, и теперь уже трудно что то сделать без принципиального изменения языка. Теперь конкретно, как передать ПАРАМЕТР+ГЛАГОЛ в моем примере: (Динамически создаваемая кнопка) (не уверен насчет корректности оператора конкатенации строк, но пусть будет пока так) Instr РАЗДЕЛИТЕЛЬ = #$ [пробел или запятая или еще какой нить разделитель] Параметр1, Параметр2 - ранее рассчитанные выраженрия If <условие> then instr ПАРАМЕТР = Параметр1 + РАЗДЕЛИТЕЛЬ+ Параметр2 & xBtn ПАРАМЕТР, ОБРАБОТЧИК, Название кнопки

ghoest: noname пишет: в процедуре можно и соотв переменной значение присвоить, если тебя именно это волнует, а можно и любые другие операторы использовать. т е это- наиболее универсальный вариант. Блин . Я все пытаюсь додолбиться, и чувствую, что просто плохо объясняю... Дизлексия блин... В общем, как бы коротко.... На Btn должен висеть КОНЕЧНО же обработчик событий, где можно делать все что угодно. Но он НЕ ВИСИТ. И не будет висеть, по крайней мере в рамках концепции современного URQL. В URQL нет процедур, а есть только куски кода, обозначенные метками. Вариант, когда в xBtn запихивается кусок кода - безусловно РАБОЧИЙ вариант, но просто очень неудобно запихнуть сколько нибудь значительный набор операторов в часть строки, заключенную в фигурные скобки. Само собой напрашивается вариант - вынести эти операторы куда то отдельно, пометить их меткой и обратиться к этой метки из xBtn... Гениально? да нет, ибо мы тут неявно, но вернулись к ОБЫЧНОМУ Btn, просто вместо одной метки в этом операторе указали две... вдумайтесь в это. Ну и что что первая метка в этом наборе является как бы процедурой и мы там можем выполнить различные операторы - все равно метка этой процедуры, предполагаемого обработчика, ЖЕСТКО указывается в xBtn, и соответственно, в ней будет выполняться ТОЛЬКО ОДИН вариант обработки. В моем же варианте xBtn реально позволяет при указании одной и той же метки-обработчика в разных xBtn разграничить эти разные xBtn разными переменными, и выполнить РАЗНЫЕ (в зависимости от значения переменных) варианты кода в ОДНОЙ локации-обработчике.

ghoest: --

ghoest: БОЖИЙ СУД :) Проще один раз показать, чем нудно описывать. Вот вам пример кода, ИМИТИРУЮЩИЙ конструкцию xBtn ВЫРАЖЕНИЕ, Локация_Обработчик, Название кнопки. Написан с использованием ТЕКУЩЕГО варианта xBtn, в AkURQ 1.28pre6 Кнопок может быть произвольное количество. Локация обработчик - одна. С использованием моего варианта xBtn следующая строка: xBtn Answer,{xBtnVAR=#I$},Answer N #I$ поменялась бы на: xBtn #I$, Answer, Answer N #I$ ------------------------------ :Start pln enetr quantity of buttons input Max I=0 :CycleBegin I=I+1 Array#I$=rnd xBtn Answer,{xBtnVAR=#I$},Answer N #I$ if I < Max Then Goto CycleBegin end :Answer pln It's a #Array#xBtnVAR$$ btn Start, Again end --------------------------- Описание - код генерит массив заданного пользователем размера, заполняет его случайными числами и формирует необходимое число кнопок, по нажатию на которую сообщается число, находящееся в массиве под выбранным (кнопкой) номером Не представляю, как записать подобный алгоритм с использованием конструкции xBtn Локация_Процедуры, Локация_Перехода, Название кнопки. Предлагаю 1. Записать мой алгоритм с использованием конструкции xBtn Локация_Процедуры, Локация_Перехода, Название кнопки. 2. составить какой нить алгоритм с использованием этой конструкции, который было бы НЕВОЗМОЖНО решить моим методом Для имитации, наверно, можно использовать следующую конструкцию с нынешним xBtn: xBtn Локация_Перехода, {proc Локация_Процедуры}, Название кнопки )

noname: ghoest пишет: Да, если [локация_процедуры] станет именно ПРОЦЕДУРОЙ, новым типом в языке, а не просто локацией, меткой, как сейчас. ёперный бабай! локация_процедуры - просто локация. при вызове xbtn локация_процедуры, локация_перехода, название_кнопки делаем: 1) переход, аналогичный переходу по urq- овской команде proc на локацию локация_процедуры 2) выполняем всё что там автор понаписал, включая переходы на другие локации и любые другие хитрости до первого end - аналогично урковскому proc 3) встретив end выполняем переход на локация_перехода аналогично урковскому обычному баттону. 4) вот и всё. просто и хорошо. p.s. осталось ответить на два возражения: 1) Само собой напрашивается вариант - вынести эти операторы куда то отдельно, пометить их меткой и обратиться к этой метки из xBtn... Гениально? да нет, ибо мы тут неявно, но вернулись к ОБЫЧНОМУ Btn, просто вместо одной метки в этом операторе указали две... вдумайтесь в это. Ну и что что первая метка в этом наборе является как бы процедурой и мы там можем выполнить различные операторы - все равно метка этой процедуры, предполагаемого обработчика, ЖЕСТКО указывается в xBtn, и соответственно, в ней будет выполняться ТОЛЬКО ОДИН вариант обработки и 2) - последний пост ghoest. щазз попробую объяснить...

noname: итак, отвечаю на возражение первое: не знаю, было ли для ghoest существование в urq proc новостью, но вот фразы о том, что в кахих-то urq-шных командах чего-то ЖЁСТКО указывается не соответствуют действительности однозначно. рекомендую перечитать учебник по urq под редакцией Korwin-а, особенно про #такие$ и #%вот_такие$ вставки. возможно, это сразу снимет все вопросы и разногласия. в урке возможна такая конструкция: :#%переменная_1$ pln urq рулит! btn #%переменная_2$, жми сюда, неверный end где в текстовых переменных переменная_1 и переменная_2 указаны соотв имена локаций. никто специально такую конструкцию не придумывал- в урке многое возможно просто исходя из логики языка. возможно, я просто не понял суть твоего возражения. тогда- поясни. ИМХО это как раз тот случай, когда добавляя в кнопку название ещё всего одной локации получаем на одну бесконечность возможностей больше. делать xxbtn с бОльшим числом параметров уже будет незачем.

noname: отвечаю на возражение второе: действительно, замечательная конструкция сделана в Акурке. не пишу на ней т к мне нравится дос-окно. пробовал как-то под настроение, но добили отличия от синтаксиса досурки. твоя задумка xbtn тоже неплоха, но заведомо тесна. не вижу смысла заранее ограничивать авторов в средствах. с xBtn Локация_Процедуры, Локация_Перехода, Название кнопки будет всё тоже самое, только вместо {xBtnVAR=#I$} будет стоять имя локации, в которой это присвоение будет выполнено. твоим методом, т е с помощью xbtn, реализованного в соответствии с твоим предложением ИМХО возможно реализовать любой алгоритм, который можно реализовать с помощью xbtn сделанным по другим принципам, НО в некоторых случаях это будет гемор страшный. вот например, любой массив можно впихнуть в одномерный, НО представь, что ты пишешь игру, которая начинается в центре мира, а затем может постепенно дописываться во все стороны (вполне разумный вариант!). делаем координаты первой локации (0,0,0) на всякий случай (вдруг мы потом ещё подвал или башню где-нить поставим). и растим тихонечко мир во все стороны -> в одни стороны с "+" координатами, в противоположные- с "-". впихнуть всё это в одномерный массив ВОЗМОЖНО, но геморно. и это далеко не единственный случай (бывает нужно ещё списки предметов в карманах персонажей хранить, а для предметов- списки свойств). так же и с твоим xbtn всё возможно, но можно составить случай, когда это будет геморно. мне даже в простом случае (когда надо передать всего два параметра: отркыть замок отмычкой) будет неприятно пользоваться твоим xbtn, так как он в этой ситуации предполагает использование каких-то выкрутасов. это нехорошо для читаемости и расширяемости кода. и просто нехорошо.

fireton: А хотите так: [pre] :локация ... btn кноплок(10, 15), Вот такая вот кнопень end ... :кноплок if (кноплок_пар1 = 10) then ... ... [/pre] Можно реализовать. Довольно нетрудно.

ghoest: noname пишет: ёперный бабай! локация_процедуры - просто локация. при вызове xbtn локация_процедуры, локация_перехода, название_кнопки делаем: Еперный бабай! А Я ЧТО ПЫТАЮСЬ СКАЗАТЬ? Вот вы сами и сказали о том, что конструкция xBtn Локация1, Локация2, Кнопка практически ЭКВИВАЛЕНТНА комбинации из стандартных Btn и Proc (Да, я знаю и что такое proc, и что такое #$ - удивительно блин.) Насчет #$ и ЖЕСТКОСТИ. Согласен, #$ позволяет делать вообще все что угодно. И у вас в коде, благодаря #$, могут появиться команды, которых вы сами никогда не писали. Но у вас НИКОГДА не появится МЕТКА, которую вы заранее, ручками, нее вбили в тело кода. Вот именно то обстоятельство, что любой оператор, имеющий в качестве своих операндов ИМЯ МЕТКИ, обязан обращаться к конечному набору заранее определенных меток, я и называю жесткостью. В моем формате xBtn есть имя метки - указание на локацию-обработчик - и это ЖЕСТКИЙ, ИНВАРИАНТНЫЙ* ОПЕРАНД, но там же присутствует и выражение, значение которого передается в переменную, а значение может при обработке кода оказаться любым - и это ВАРИАНТНЫЙ ОПЕРАНД. В защищаемом же вам формате xBtn- два ИНВАРИАНТНЫХ операнда и ни одного вариативного. Именно поэтому он менее функционален и не эквивалентен моему. *инвариант - программный объект, не изменяющийся в процессе выполнения. В данном случае я имею в виду, что операнд ссылается на такой инвариант - метку Поясню на примере (noname): :#%переменная_1$ pln urq рулит! btn #%переменная_2$, жми сюда, неверный end Насчет #%Переменная_2$ - здесь, конечно же, к моменту нажатия на кнопку мы можем получить РАЗНЫЕ значения выражения #Переменная_2% и соответственно перейти на различные метки - но эти значения ВСЕГДА должны соответствовать какой либо ЗАРАНЕЕ определенной метке, иначе возникнет ошибка. А вот насчет возможности указания метки в виде :#%Переменная_1$ не уверен (ни в AkURQ, ни в DOS_URQ эта хрень не работает ;), но если это и можно, то мы здесь имеем фактически одну и ту же метку с переменным именем. Поясните на каком нибудь рабочем примере практический смысл необходимости в переменном имени метки. Разумеется, этот пример не должен сколь-нибудь простым способом реализовываться БЕЗ переменного имени твоя задумка xbtn тоже неплоха, но заведомо тесна. не вижу смысла заранее ограничивать авторов в средствах. ХА-ХА! Я утверждаю ровно обратное - тесна задумка с ВАШИМ вариантом. Уж точно теснее моей, а соответственно, и нынешнего xBtn {} с xBtn Локация_Процедуры, Локация_Перехода, Название кнопки будет всё тоже самое, только вместо {xBtnVAR=#I$} будет стоять имя локации, в которой это присвоение будет выполнено. НЕ БУДЕТ! - посмотрите мой код в БОЖИЕМ СУДЕ и сделайте такой же Кстати, все, описанное ниже - действительно, описывает невероятный геморрой, с которым столкнется кодер, если вместо существующего xBtn {} будет иметь только xBtn Лока, лока, Кнопа. C моим же xBtn он столкнется только с необходимостью конкатенировать n-ное количество необходимых к передаче параметров в один и последующему разбору его снова на n-номе количество. По пунктам. Формат оператора xBtn, используемый сейчас в AkURQ, с указанием произвольных операторов в фигурных скобках - отличный оператор по функционалу, но неудобный. Раз уж возникают мысли сменить формат - хорошо, но НЕ НАДО ИСПОЛЬЗОВАТЬ ФОРМАТ xBtn Л_Проц, Л_Перехода, Кнопка. ЭТО УБЛЮДОЧНЫЙ ЭРЗАЦ. Да, он будет несколько функциональнее обычного Btn - тем, что при нажатии можно будет вызвать дополнительную локацию через proc, но он НИКОГДА не приблизится по функционалу к существующему сейчас стандарту xBtn. Говоря человеческим языком - он не позволит реализовать некоторое количество алгоритмов, реализованных с помощью существующего xBtn (с фигурными скобками). Это я доказал абстрактно выше, когда отметил, что данный формат не имеет ВАРИАНТНОГО операнда. Мой же вариант ЭКВИВАЛЕНТЕН существующему формату xBtn. То есть позволяет (возможно более длинным путем) полностью реализовать любой код, написанный с использованием существующего формата xBtn. Попробую и это доказать абстрактно. С точки зрения программы нажатие пользователем на кнопку является ОДНИМ и только одним СОБЫТИЕМ. Как следствие, конечно же, может генерироваться еще множество событий, но все они будут иметь источником одно-единственное событие - нажатие на кнопку. Следовательно, описать это событие можно одним-единственным изменением данных, которыми оперирует программа - и это изменение и происходит при присвоении какого-то значения одной и только одной переменной. предложение по БОЖИЕМУ СУДУ еще в силе. Могу дополнить условия вызова: вызываюсь привести любой код, написанный с использованием xBtn {произвольное количество произвольных операторов} к коду с использованием только xBtn {переменная=значение (один оператор)}, а оппонент пусть сделает то же самое то же самое, приведя код к использованию только xBtn {proc Локация} Как было написано выше, данные конструкции имитируют соответственно мой вариант формата xBtn, и формат xBtn Локация1, Локация2, Кнопка Имеющий мозги - ДА ВЪЕДЕТ, а не учит меня тому, что я и так знаю ------------------------------------------------------------------ Fireton! Обалденная вещь! Вы как раз и предлагаете ИМЕННО ТО, что я имел в виду высказывая (возможно, невнятно) следующее (в первом своем посте здесь): либо что то вроде xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр] //[] - значит, что применение опционально опционально end :Локация [Параметр] Параметр = Параметр+Параметр.... и т.д. end Но второй вариант более принципиально изменяет концепцию языка URQL, по сути предусматривается возможность задания параметра/списка параметров для метки, которая в данном случае приближается по функциональности к процедуре то есть, вызов локации, КАК ПРОЦЕДУРЫ С ПАРАМЕТРАМИ ;) И, раз уж вы говорите, что реализовать такой формат: xBtn (Пар1, ..., ПарN), Лока, Кнопа несложно, то я с радостью откажусь от ограничения на использование в xBtn ТОЛЬКО одной переменной (хотя и продолжу утверждать, что одной переменной достаточно - в математическом смысле этого слова) Тогда, как я понимаю, нужно будет предусмотреть в URQL следующее: Либо возможность описывать метку как процедуру, то есть после ее названия каким то образом перечислить все аргументы, которые могут быть переданы в метку как параметры ее вызова :Лока Арг1, ... АргN Либо предусотреть какое то глобальное хранилище для передачи параметров, к которым можно обрашаться в локации (вроде нынешнего глобального массива, который хранит части строки при разбиении ее на токены) То есть, при вызове xBtn (Пар1, ..., ПарN), Лока, Кнопа присваивается значение системной переменной КоличествоАргументов = N, а также набору типовых переменных Аргумент1 = Пар1...АргументN = ПарN, к каковым переменным мы и будем (при необходимости) обращаться в локации обработчике.



полная версия страницы