АвторСообщение
хитрый латышский койот




Сообщение: 290
Зарегистрирован: 14.06.05
ссылка на сообщение  Отправлено: 18.06.08 14:51. Заголовок: AkUrq2


AkUrq 2.12 beta 8
Потихоньку пишется новая акурка2, основанная на идее Sfeli и содержащая не малую долю его кода. Возможности пока довольно скромные, но это вопрос времени.
требует только IE5 (Windows 98+)

Что мы имеем:
 цитата:
Операторы:
;комментарий
:(локация)
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_(предмет)



Краткое описание языка (Выборочно использовалась помощь от Корвина) Скрытый текст



очень короткий FAQ:
 цитата:
В1: Тут слишком мало возможностей для моих извращённых идей :) где синусы, вычисление корня, тысячи картинок, xbtn, и вообще где первая акурка? (привет Суд :)
О1: Думаю первая акурка дорабатываться больше не будет. Новые операторы в квотерое появятся со временем, но не так как они появлялись в первой акурке: операторы будут появляться только после того как их синтаксис утвердят большенство метров, к которым я отношу: Евгения, Сфели, Виктора, Корвина.
Уважаемый Борщевский разумеется тоже метр, но поскольку он ненавидит урку, я боюсь его спрашивать :)

В2: Где инвентарь? Месяц найти не могу уже. (привет Хлом :)
О2: Клавиши I и F6 открывают инвентарь.

В3: Как теперь закрыть инвентарь? (привет Гор )
О3: Теми же клавишами.

В4: Как закрыть текущий квест и начать новый?
О4: F2 выводит в меню.

В5: Что можно настроить в ини файле?
О5: Можно изменить шрифт (Goraph) и включить/отключить управление кнопками на цифрах. Если результат вас не устроит, а как было вы не запомнили х) то удалите ини файл



Ну и выражаю благодарность Sfeli который написал добрую половину функций. Их легко вычислить - если чтото в квотерое работает без проблем - это писал Сфели) Если глючит - то Акела)

Сообщения в этой теме буду периодически удалять

Колокола сегодня звонят особенно громко...Спасибо: 0 
ПрофильЦитатаОтветить
Ответов - 73 , стр: 1 2 3 4 All [только новые]





Сообщение: 4
Зарегистрирован: 10.05.08
ссылка на сообщение  Отправлено: 20.06.08 10:13. Заголовок: :sm36: ..




Спасибо: 0 
ПрофильЦитатаОтветить
хитрый латышский койот




Сообщение: 293
Зарегистрирован: 14.06.05
ссылка на сообщение  Отправлено: 29.06.08 17:38. Заголовок: 2.12 beta 8 (первый ..


2.12 beta 8 (первый пост обновлён)

 цитата:
*поправлен оператор input (Goraph)
*можно уменьшать и увеличивать шрифт [+ -] (Евгений)
*по умолчанию убраны цифры с кнопок (Евгений) (можно сменить в ини файле)
*по умолчанию подсвечивается первая кнопка (Goraph)
*добавлена системная переменная inv_<предмет>
*подправлен интерфейс
*добавлена поддержка дос кодировки (Goraph)
*вернул возможность шифровать файлы
*invkill [предмет]
*переменная music=
previous_loc
current_loc
last_btn_caption
*==
*_перенос



в ней даже работает кукла х)

Колокола сегодня звонят особенно громко...Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 27
Зарегистрирован: 05.03.08
ссылка на сообщение  Отправлено: 30.06.08 16:33. Заголовок: Шикарно. Проверил на..


Шикарно. Проверил на паре квестов, работает без глюков. )

Спасибо: 0 
ПрофильЦитатаОтветить
хитрый латышский койот




Сообщение: 295
Зарегистрирован: 14.06.05
ссылка на сообщение  Отправлено: 30.06.08 20:39. Заголовок: м... ну у меня иногд..


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

Колокола сегодня звонят особенно громко...Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 29
Зарегистрирован: 05.03.08
ссылка на сообщение  Отправлено: 01.07.08 00:20. Заголовок: Приятно что вернули ..


Приятно что вернули шифрование, теперь не будет больше прохождения игр в блокноте. )

Спасибо: 0 
ПрофильЦитатаОтветить
хитрый латышский койот




Сообщение: 296
Зарегистрирован: 14.06.05
ссылка на сообщение  Отправлено: 01.07.08 12:30. Заголовок: написал небольшое оп..


написал небольшое описание по urql (только те операторы которые поддерживают на данный момент и досурка и акурка2, с комментариями)
(в первом посте нажмите на "Скрытый текст")

Колокола сегодня звонят особенно громко...Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 69
Зарегистрирован: 20.01.07
ссылка на сообщение  Отправлено: 01.07.08 16:02. Заголовок: (задумчиво) Хм. Може..


(задумчиво)
Хм. Может, для урки еще не все потеряно...

Тон.Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 197
Зарегистрирован: 20.12.05
ссылка на сообщение  Отправлено: 01.07.08 23:03. Заголовок: Ура! С новой жизнью ..


Ура! С новой жизнью и избавлением от richtx'а!=))
Толком пока не играл ни во что (как раз, наверно, опробую на игре Platov'а), но первые впечатления от тестовых запусков в целом положительные.
Есть пока две сравнительно несложно реализуемых (надеюсь)) просьбы: вернуть инвентарь по правой кнопке (потому что в лом тянуться до клавиатуры каждый раз) и сделать, помимо досуркиных, ргбшные настройки для цветов фона и текста. И не забудь сделать urq_type=2 =)
Вива Квотерой=))!


Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 404
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 09.07.08 15:00. Заголовок: чиет (xbtn) хоца... ..


Platov пишет:

 цитата:
Приятно что вернули шифрование, теперь не будет больше прохождения игр в блокноте. )



Не в этом счастье... поверь мне дружище...

чиет (xbtn) хоца... а по рукам!!! по рукам!!! А все равно хоца...

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 405
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 10.07.08 06:59. Заголовок: Бумеранг-Урка (Урка ..


Бумеранг-Урка (Урка возвращается)=BURQ - оно же расшифровывается как вторая попытка (A(эй) - первая, B(би) - вторая.

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

Порадовало очень, что справился с шифровкой .qs2 - свои же Крылья запустил. Но с проблемами - там у меня часы есть, так квотерой выдает

Время 7:
0
5

А надо разумеется Время 7:05

Еще - при попадании в локацию, где есть btn - пустышка а других btn нет - Квотерой вылетает. :(

А так - отличная программа! Жду развития совместимости в первую очередь.

Спасибо: 0 
ПрофильЦитатаОтветить
хитрый латышский койот




Сообщение: 302
Зарегистрирован: 14.06.05
ссылка на сообщение  Отправлено: 10.07.08 08:24. Заголовок: Korwin пишет: Еще -..


Korwin пишет:

 цитата:
Еще - при попадании в локацию, где есть btn - пустышка а других btn нет - Квотерой вылетает. :(


подробнее?..

Колокола сегодня звонят особенно громко...Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 39
Зарегистрирован: 05.03.08
ссылка на сообщение  Отправлено: 10.07.08 10:37. Заголовок: Korwin пишет: Не ..


Korwin пишет:

 цитата:


Не в этом счастье... поверь мне дружище...

чиет (xbtn) хоца... а по рукам!!! по рукам!!! А все равно хоца...



Та верю Корв, верю. А почему все так против xbtn? Ну да, несовместимость со старыми версиями. Но если будет хорошая новая версия, все ведь перейдут на неё? Отпадёт проблема с поиском нужного интерпритатора, и xbtn будет.

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 406
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 11.07.08 05:23. Заголовок: О синтаксисе урки и xbtn


"Все против" это сильно сказано. Просто есть проблема синтаксиса, доставшаяся нам в наследство от первого автора. Это определение оператора в URQ. Оператор состоит из собственно оператора и параметров, отделенных запятыми. Концом оператора является или конец строки, или '&'. Отсюда проблема - каким образом интерпретатор определит, что закончился составной оператор xbtn? Та реализация, которая есть в первой AkURQ, насколько я помню, выглядит не по-урковски.

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 85
Зарегистрирован: 19.11.07
ссылка на сообщение  Отправлено: 11.07.08 09:17. Заголовок: А почему бы Вам не с..


А почему бы Вам не сделать xbtn не совсем так, как задумано было. т.е. не переход и выполнение, а просто выполнение кода. А запятые и & можно будет экранировать ##$?

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 407
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 11.07.08 10:57. Заголовок: Александр Граф пишет..


Александр Граф пишет:

 цитата:
А почему бы Вам не сделать xbtn не совсем так, как задумано было. т.е. не переход и выполнение, а просто выполнение кода. А запятые и & можно будет экранировать ##$?



Какой синтаксис предлагаешь? А то мы в свое время голову сломали - ветка до сих пор на форуме висит. Свой пример, пожалуйста:

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 86
Зарегистрирован: 19.11.07
ссылка на сообщение  Отправлено: 11.07.08 22:29. Заголовок: xbtn (код),(имя) Пр..


xbtn (код),(имя)

Примеры:

xbtn goto abcd,hhh
xbtn goto abcd##28$p здесь у нас текст##44$ даже с запятой, а тут у нас название кнопки

или даже

xbtn (метка), (код), (имя)

Примеры:

xbtn abcd, p здесь у нас текст##44$ даже с запятой, а тут у нас название кнопки

Правда я не помню как заменяются ##$ по-моему уже при выводе, а не при парсинге, но для xbtn можно свое правило создать. Только запутаться можно жестоко.

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 409
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 11.07.08 23:17. Заголовок: А если в этом коде еще и вставка содержимого текстовой переменной? Да тоже с запятыми?


Не все так легко, Граф. Код может иметь вставки в виде других операторов с запятыми, те же кнопки, да и #%строковая переменная$ тоже штука непредсказуемая. В свое время я предлагал xbtn метка, название, где метка это имя proc, но не понравилось

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 87
Зарегистрирован: 19.11.07
ссылка на сообщение  Отправлено: 11.07.08 23:28. Заголовок: А если запятые в кон..


А если запятые в конструкции #%$, то они там и должны оставаться, не может быть такого, чтобы конструкция начиналась и не заканчивалась, т.е. запятые в таких конструкциях должны автоматически игнорироваться, а не то будет ошибка.

xbtn goto abcd##28$p здесь у нас текст##44$ даже с запятой #%asd,$ а тут у нас название кнопки

Тут будет ошибка, от того, что "goto abcd##28$p здесь у нас текст##44$ даже с запятой #%asd,$ а тут у нас название кнопки" воспринимается одной строкой(должна быть по идее).
А если в самой переменной(не в названии) содержатся запятые и &, опять же можно создать правило, что они все в xbtn заменяются на конструкции ##$.

Хотя получается слишком много правил.

Спасибо: 0 
ПрофильЦитатаОтветить
неизвестный человек




Сообщение: 138
Зарегистрирован: 08.06.07
ссылка на сообщение  Отправлено: 12.07.08 08:04. Заголовок: Акела, может стоило ..


Акела, может стоило из пре 1 и пре 6 сделать стабильную 1.3, а потом заниматься второй акуркой? И второй вопрос:в чем отличие 1 и 2 акурки?

А что насчет тебя? Ты бы смог убить животное? Человеческое животное...Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 88
Зарегистрирован: 19.11.07
ссылка на сообщение  Отправлено: 12.07.08 08:09. Заголовок: Кажется, я сглупил: ..


Кажется, я сглупил: при таком подходе не возможны вложенные xbtn. Придумал другое: создать конструкцию, которая заменяется на текст конструкции. т.е. #@abc$ заменяется на abc. Причем, замена происходит только на первом уровне. Вот:

xbtn #@goto ass&proc xyz$,назв.

#@goto ass&proc xyz$ должно замениться на goto ass&proc xyz и выполниться. По идее.

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 77
Зарегистрирован: 03.07.07
ссылка на сообщение  Отправлено: 12.07.08 08:42. Заголовок: о, какие страшные ко..


о, какие страшные конструкции.

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 72
Зарегистрирован: 20.01.07
ссылка на сообщение  Отправлено: 12.07.08 10:07. Заголовок: Идиотизм, по-моему. ..


Идиотизм, по-моему.
URQL ущербен, по определению. Синтаксис языка не продуман совершенно. Поэтому постоянно приходится подставлять костыли...

Тон.Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 89
Зарегистрирован: 19.11.07
ссылка на сообщение  Отправлено: 12.07.08 10:10. Заголовок: Знаю... зато можно б..


Знаю... зато можно будет в метках локаций использовать запятые и & :)

Они хотя-бы похожи на конструкции URQL...

Спасибо: 0 
ПрофильЦитатаОтветить
неизвестный человек




Сообщение: 141
Зарегистрирован: 08.06.07
ссылка на сообщение  Отправлено: 21.07.08 16:24. Заголовок: Chicago1920 пишет: ..


Chicago1920 пишет:

 цитата:
Акела, может стоило из пре 1 и пре 6 сделать стабильную 1.3, а потом заниматься второй акуркой? И второй вопрос:в чем отличие 1 и 2 акурки?



Chicago1920 пишет, но никто не отвечает)

А что насчет тебя? Ты бы смог убить животное? Человеческое животное...Спасибо: 0 
ПрофильЦитатаОтветить
хитрый латышский койот




Сообщение: 304
Зарегистрирован: 14.06.05
ссылка на сообщение  Отправлено: 21.07.08 16:49. Заголовок: как никто не отвечае..


как никто не отвечает) я каждый день заглядываю на форум и стараюсь отвечать даже на лс) мне просто страшно читать эту тему х)
акурк2 на хтмл, первая на рич, основное отличие в этом
Nex пишет:

 цитата:
о, какие страшные конструкции.


+1)

Колокола сегодня звонят особенно громко...Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 415
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 21.07.08 18:22. Заголовок: Акела пишет: Nex пи..


Акела пишет:

 цитата:
Nex пишет:
цитата:
о, какие страшные конструкции.
+1)



А что если все же как я предлагал?

:лока1
...
xbtn метка_проц,Название кнопки
...
end

:метка_проц
операторы
end

Мне кажется не слишком уродливо и сочетается с принципами URQL Какая разница - внутри локи операторы лежат или рядом?



Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 1
Зарегистрирован: 05.08.08
ссылка на сообщение  Отправлено: 05.08.08 15:36. Заголовок: frodo


А может так?

:лока1
...
xbtn метка_проц,лока2,Название кнопки
...
end

:метка_проц
операторы
end

где лока2 -- локация, выполняемая после :метка_проц, т.е. xbtn выполняет proc метка_проц&goto лока2

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 420
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 06.08.08 07:00. Заголовок: frodo пишет: :лока1..


frodo пишет:

 цитата:
:лока1
...
xbtn метка_проц,лока2,Название кнопки
...
end

:метка_проц
операторы
end

где лока2 -- локация, выполняемая после :метка_проц, т.е. xbtn выполняет proc метка_проц&goto лока2



Тогда надо оставить возможность пустой метки

xbtn метка_проц,,Название кнопки


Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 1
Зарегистрирован: 10.07.08
ссылка на сообщение  Отправлено: 09.08.08 11:51. Заголовок: Просьба


2Akela: Не мог бы ты ввести в Акурку (опционально) отображение названия текущей локации?

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 1
Зарегистрирован: 10.08.08
ссылка на сообщение  Отправлено: 10.08.08 04:43. Заголовок: Начинается :)


Могут быть проблемы при переходах в локацию по goto. Может лучше сделать системную переменную для отображения заголовка окна? Или ничего не делать?

Спасибо: 0 
ПрофильЦитатаОтветить
хитрый латышский койот




Сообщение: 307
Зарегистрирован: 14.06.05
ссылка на сообщение  Отправлено: 10.08.08 06:58. Заголовок: Системные переменные..


Системные переменные:
previous_loc - Содержит имя предыдущей локации
current_loc - Содержит имя текущей локации

Колокола сегодня звонят особенно громко...Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 421
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 11.08.08 08:25. Заголовок: Акела пишет: Систем..


Акела пишет:

 цитата:
Системные переменные:
previous_loc - Содержит имя предыдущей локации
current_loc - Содержит имя текущей локации



Это понятно. Речь шла об отображении в заголовке окна не названия программы, а имени локации. Т.е. например системная переменная
instr win_capture="" - отображается имя программы интерпретатора,
instr win_capture=current_loc - - отображается название текущей локации.
instr win_capture="Дом" - заданное название окна.


Лично я не уверен, что это надо делать.

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 3
Зарегистрирован: 28.07.08
ссылка на сообщение  Отправлено: 11.08.08 10:08. Заголовок: MixeratoR пишет: 2A..


MixeratoR пишет:

 цитата:
2Akela: Не мог бы ты ввести в Акурку (опционально) отображение названия текущей локации?


Корв чтото ты мудришь, тут ничего такого я не нашёл. ну делать в любом случае не стану.

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 422
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 11.08.08 13:44. Заголовок: Акела(w) пишет: Кор..


Акела(w) пишет:

 цитата:
Корв чтото ты мудришь, тут ничего такого я не нашёл.


Может это я неправильно понял? MixeraroR, поясни свою мысль?


Акела(w) пишет:

 цитата:
ну делать в любом случае не стану


Ну, меня ты не расстроил. :)


Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 2
Зарегистрирован: 10.07.08
ссылка на сообщение  Отправлено: 13.08.08 00:32. Заголовок: Korwin, ты всё прави..


Korwin, ты всё правильно понял.

Да, это в принципе не сильно нужная функция :
pln Название Локации
pln
Только придётся сделать вывод названия в виде отдельной метки, чтобы отображать ТОЛЬКО при переходе с другой локации.

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 206
Зарегистрирован: 20.12.05
ссылка на сообщение  Отправлено: 13.08.08 01:43. Заголовок: Ну, это не такая бол..


Ну, это не такая большая жертва. Можно, кстати, и без отдельной метки сделать. Только не нужно
Согласен, что функция слишком специфическая, чтобы добавлять ее в ближайшие несколько десятков акурок.

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 5
Зарегистрирован: 05.08.08
ссылка на сообщение  Отправлено: 14.08.08 16:52. Заголовок: А вот что меня интер..


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

Я не люблю Толкиена и ролевые игры!Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 9
Зарегистрирован: 27.08.08
ссылка на сообщение  Отправлено: 11.10.08 15:47. Заголовок: К слову, а как на не..


К слову, а как на ней вставлять картинки?

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 191
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 11.10.08 23:24. Заголовок: 1) Korwin, frodo - м..


1)
Korwin, frodo - молодца!

xbtn локация_процедуры, локация_перехода, название_кнопки

идеально!
2)
xbtn метка_проц,,Название кнопки
- совершенно излишне.
разве не лучше:
xbtn метка_проц,текущая_локация,Название кнопки
?
ведь после выполнения чего-угодно хорошо бы отобразить чё-то на экране,
а не так, что юзер жмёт чего-то и ничего не меняется...
или ты, Корв другое имел ввиду?

p.s.
только сегодня серьёзно взялся за куспель, так нате- урка возвращается!
прямо издевательство какое-то :)

просто сядь и напиши квест на URQСпасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 437
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 12.10.08 05:25. Заголовок: noname пишет: 1) K..


noname пишет:

 цитата:
1)
Korwin, frodo - молодца!

xbtn локация_процедуры, локация_перехода, название_кнопки

идеально!
2)
xbtn метка_проц,,Название кнопки
- совершенно излишне.
разве не лучше:
xbtn метка_проц,текущая_локация,Название кнопки
?
ведь после выполнения чего-угодно хорошо бы отобразить чё-то на экране,
а не так, что юзер жмёт чего-то и ничего не меняется...
или ты, Корв другое имел ввиду?



Ну, можно и так (с) И.Сталин

Ты прав... только кто же это будет реализовывать в интерпретатор?



Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 11
Зарегистрирован: 27.08.08
ссылка на сообщение  Отправлено: 13.10.08 07:29. Заголовок: Картинки 2-я акурка ..


Вам мо квешн плиз обана:
Картинки 2-я акурка поддерживает?

Так сложно ответить?
Да / Нет / Не понял вопроса

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 114
Зарегистрирован: 03.07.07
ссылка на сообщение  Отправлено: 13.10.08 09:46. Заголовок: Можно скачать и пров..


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

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 13
Зарегистрирован: 27.08.08
ссылка на сообщение  Отправлено: 13.10.08 11:01. Заголовок: Ну, у меня не получи..


Nex пишет:

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


А здесь проверял?
http://urq.plut.info/soft
Если хочешь пришлю 2-ю.

Но у меня не получилось применить к 2-й версии акурки ни один из картинковых методов 1-ой...
А списке операторов в самом верхнем посте вобще ничего такого нет.
Наверное всё-таки 2-я идёт без картинок. Не успелось...

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 192
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 14.10.08 18:46. Заголовок: hi пишет: Вам мо к..


hi пишет:

 цитата:

Вам мо квешн плиз обана:
Картинки 2-я акурка поддерживает?

Так сложно ответить?
Да / Нет / Не понял вопроса


лично я ничего про картинки во 2-й акурке ничего не знаю.
а про саму эту 2-ю акурку узнал только на днях-
тогда же и сообщение в эту тему написал.

просто сядь и напиши квест на URQСпасибо: 0 
ПрофильЦитатаОтветить
администратор


Сообщение: 285
Зарегистрирован: 17.05.05
ссылка на сообщение  Отправлено: 18.10.08 01:27. Заголовок: Nex пишет: Можно ск..


Nex пишет:

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

Обновил ссылки в закрепленном посте "urq_dos, Akurka, текущие версии".

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 1
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 10.12.08 12:23. Заголовок: xbtn локация_процеду..



 цитата:
xbtn локация_процедуры, локация_перехода, название_кнопки

идеально!



Бред.

чем это лучче конструкции в стандартной УРКе:

btn локация_процедуры, название_кнопки
end

:локация_процедуры
goto локация_перехода
end
????

Гениальное изобретение велосипеда, в котором руль приколочен прям к колесу, для удобства
Ну, то есть, нафига придумывать команду, вызывающую последовательно две (три, насколько) локаций, если это преспокойно решается стандартными методами языка?

Вообще, потребность в xBtn возникла из-за того, что обычный btn является всего лишь модификацией оператора goto и не способен передать ПАРАМЕТР в целевую локацию, что и не позволяло вешать на кнопку какой-то обработчик событий, кроме собственно перехода.

Либо как сейчас в АкУРКе, (хотя точно не помню место для указания фигурных скобок): xBtn {переменная=значение}, Локация, Кнопка (), чтобы потом переменную обработать в локации. Причем достаточно только такой, жесткой конструкции (одна_переменная=одно_значение), а далее можно творить чудеса. Например, передать в переменной целый список значений (и разбить его с помощью token), или с помощью #$ передать кусок кода.

либо что то вроде

xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр] //[] - значит, что применение опционально опционально
end

:Локация [Параметр]
Параметр = Параметр+Параметр.... и т.д.
end

Но второй вариант более принципиально изменяет концепцию языка URQL, по сути предусматривается возможность задания параметра/списка параметров для метки, которая в данном случае приближается по функциональности к процедуре

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник


Сообщение: 463
Зарегистрирован: 25.05.05
ссылка на сообщение  Отправлено: 10.12.08 15:38. Заголовок: xBtn Локация, Кнопка..



 цитата:
xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр]



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

xbtn локация перехода,{параметр(ы)},название кнопки, в котором могут быть запятые

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 2
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 10.12.08 16:23. Заголовок: ну да, ну да. Второй..


ну да, ну да.
Второй вариант это конечно уже не 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 Вычисляемое_Выражение, Локация_Перехода, Название кнопки

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 116
Зарегистрирован: 20.01.07
ссылка на сообщение  Отправлено: 10.12.08 17:54. Заголовок: :Answer pln Мой отве..


:Answer 
pln Мой ответ #xBtn_VAR$
p Это
if xBtn_VAR = 4 then p правильный else p неправильный
pln ответ
end


Фигню ты написал. Кнопок может быть переменное количество, отдельные кнопки могут определяться в proc-ах и локации-счетчике. И как следить за этим зоопарком чтобы вычислить нужную кнопку? Самой правильной xbtn будет xbtn вообще без локации. Только название и список операторов. А переход можно сделать и с помощью goto. Правда тогда начинается гимор с системными переменными, но можно отслеживать goto внутри xbtn...

Тон.Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 3
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 10.12.08 18:06. Заголовок: ghoest пишет: Фигню..


fireton пишет:

 цитата:
Фигню ты написал



НЕА.

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

ЗЫ

 цитата:
И как следить за этим зоопарком чтобы вычислить нужную кнопку?



Я так думаю - раз уж мы ГДЕ-ТО вставляем кнопку, то именно там-то мы ее и обозначим. опять же - ОДНОЙ переменной. Ибо (опять же, абстрактно) - ОДНА кнопка = ОДНО событие, пусть даже следствием этого события будет изменение миллиона переменных и выполнение миллиона строк кода:)

Важен принцип - переменная, в отличие от метки, НЕ СТАТИЧНА, она не определяется (как метка) при написании кода, она может изменяться - а это главное.


 цитата:
Только название и список операторов. А переход можно сделать и с помощью goto


И все это внутри фигурных скобок? Хммда... Будет весело смотреть на такой код...

Вообще, конечно, если бы изначально в URQL был бы реализован такой принцип - то есть изначально btn выполнял бы список операторов, а не goto-переход, то это да, такой подход являлся более правильным, тут я согласен. Но URQL сейчас именно такой, какой он уже есть. Я всего лишь предложил НАИБОЛЕЕ МИНИМАЛИСТСКИЙ способ решения проблемы ограниченности Btn, согласующийся с уже существующей идеологией языка.

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 250
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 11.12.08 20:37. Заголовок: ghoest пишет: Вообщ..


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.

DosURQ- рулез!Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 4
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 11.12.08 22:49. Заголовок: noname пишет: НО вв..


noname пишет:

 цитата:
НО введя конструкцию xbtn локация_процедуры, локация_перехода, название_кнопки мы заведомо делаем язык более универсальным.



Да, если [локация_процедуры] станет именно ПРОЦЕДУРОЙ, новым типом в языке, а не просто локацией, меткой, как сейчас. Если же под [локация_процедуры] имеется в виду обычная URQL-овская метка (пусть и вызываемая как бы через proc), то ничего не меняется.

Но сделать такую новую локацию-процедуру - это более жестокое изменение URQL (Кстати, в первом посте я и предлагал что то вроде (гипотетически) возможности описывать метку с возможность опционального указания у нее ПАРАМЕТРА, то есть метка становится как бы процедурой. Извращение еще то, конечно, но весь URQL весьма похож на извращение (не бить - это добрая шутка)



Поясню смысл моего xBtn c переменной. Существующий механизм Btn предполагает в описании кнопки указание жестко и заранее известной метки, уже прописанной в код. То есть тут затруднено использование динамически создаваемых кнопок, плюс к тому, для того чтобы различать нажатие разных кнопок, необходимо указание в разных операторах btn разных меток.

xBtn в моем варианте позволяет при указании одной и той же метки в разных операторах xBtn все же различать их, как раз путем установления значения переменной. И этого уже хватит для того чтобы построить обработку этих различий В ОДНОЙ локации
Вариант же с подвешиванием на Btn (или xBtn) целого списка операторов, вообще каких то действий - принципиально БОЛЕЕ ПРАВИЛЬНЫЙ, но URQL изначально не пошел по этому пути, и теперь уже трудно что то сделать без принципиального изменения языка.

Теперь конкретно, как передать ПАРАМЕТР+ГЛАГОЛ в моем примере:
(Динамически создаваемая кнопка) (не уверен насчет корректности оператора конкатенации строк, но пусть будет пока так)
Instr РАЗДЕЛИТЕЛЬ = #$ [пробел или запятая или еще какой нить разделитель]
Параметр1, Параметр2 - ранее рассчитанные выраженрия
If <условие> then instr ПАРАМЕТР = Параметр1 + РАЗДЕЛИТЕЛЬ+ Параметр2 & xBtn ПАРАМЕТР, ОБРАБОТЧИК, Название кнопки


Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 5
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 11.12.08 23:14. Заголовок: ghoest пишет: в про..


noname пишет:

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



Блин . Я все пытаюсь додолбиться, и чувствую, что просто плохо объясняю... Дизлексия блин...

В общем, как бы коротко....

На Btn должен висеть КОНЕЧНО же обработчик событий, где можно делать все что угодно. Но он НЕ ВИСИТ. И не будет висеть, по крайней мере в рамках концепции современного URQL. В URQL нет процедур, а есть только куски кода, обозначенные метками.

Вариант, когда в xBtn запихивается кусок кода - безусловно РАБОЧИЙ вариант, но просто очень неудобно запихнуть сколько нибудь значительный набор операторов в часть строки, заключенную в фигурные скобки.

Само собой напрашивается вариант - вынести эти операторы куда то отдельно, пометить их меткой и обратиться к этой метки из xBtn... Гениально? да нет, ибо мы тут неявно, но вернулись к ОБЫЧНОМУ Btn, просто вместо одной метки в этом операторе указали две... вдумайтесь в это. Ну и что что первая метка в этом наборе является как бы процедурой и мы там можем выполнить различные операторы - все равно метка этой процедуры, предполагаемого обработчика, ЖЕСТКО указывается в xBtn, и соответственно, в ней будет выполняться ТОЛЬКО ОДИН вариант обработки.

В моем же варианте xBtn реально позволяет при указании одной и той же метки-обработчика в разных xBtn разграничить эти разные xBtn разными переменными, и выполнить РАЗНЫЕ (в зависимости от значения переменных) варианты кода в ОДНОЙ локации-обработчике.



Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 6
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 12.12.08 02:42. Заголовок: Проще один раз показ..


--

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 7
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 12.12.08 02:42. Заголовок: Проще один раз показ..


БОЖИЙ СУД :)

Проще один раз показать, чем нудно описывать.

Вот вам пример кода, ИМИТИРУЮЩИЙ конструкцию 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 Локация_Процедуры}, Название кнопки )

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 251
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 12.12.08 22:07. Заголовок: ghoest пишет: Да, е..


ghoest пишет:

 цитата:
Да, если [локация_процедуры] станет именно ПРОЦЕДУРОЙ, новым типом в языке, а не просто локацией, меткой, как сейчас.


ёперный бабай! локация_процедуры - просто локация. при вызове xbtn локация_процедуры, локация_перехода, название_кнопки делаем:
1) переход, аналогичный переходу по urq- овской команде proc на локацию локация_процедуры
2) выполняем всё что там автор понаписал, включая переходы на другие локации и любые другие хитрости до первого end - аналогично урковскому proc
3) встретив end выполняем переход на локация_перехода аналогично урковскому обычному баттону.
4) вот и всё. просто и хорошо.

p.s.
осталось ответить на два возражения:
1)

 цитата:
Само собой напрашивается вариант - вынести эти операторы куда то отдельно, пометить их меткой и обратиться к этой метки из xBtn... Гениально? да нет, ибо мы тут неявно, но вернулись к ОБЫЧНОМУ Btn, просто вместо одной метки в этом операторе указали две... вдумайтесь в это. Ну и что что первая метка в этом наборе является как бы процедурой и мы там можем выполнить различные операторы - все равно метка этой процедуры, предполагаемого обработчика, ЖЕСТКО указывается в xBtn, и соответственно, в ней будет выполняться ТОЛЬКО ОДИН вариант обработки


и
2) - последний пост ghoest. щазз попробую объяснить...

DosURQ- рулез!Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 252
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 12.12.08 22:22. Заголовок: итак, отвечаю на воз..


итак, отвечаю на возражение первое:

не знаю, было ли для ghoest существование в urq proc новостью, но вот фразы о том, что в кахих-то urq-шных командах чего-то ЖЁСТКО указывается не соответствуют действительности однозначно. рекомендую перечитать учебник по urq под редакцией Korwin-а, особенно про #такие$ и #%вот_такие$ вставки. возможно, это сразу снимет все вопросы и разногласия.

в урке возможна такая конструкция:

 цитата:
:#%переменная_1$
pln urq рулит!
btn #%переменная_2$, жми сюда, неверный
end


где в текстовых переменных переменная_1 и переменная_2 указаны соотв имена локаций. никто специально такую конструкцию не придумывал- в урке многое возможно просто исходя из логики языка.

возможно, я просто не понял суть твоего возражения. тогда- поясни. ИМХО это как раз тот случай, когда добавляя в кнопку название ещё всего одной локации получаем на одну бесконечность возможностей больше. делать xxbtn с бОльшим числом параметров уже будет незачем.

DosURQ- рулез!Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 253
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 12.12.08 22:41. Заголовок: отвечаю на возражени..


отвечаю на возражение второе:

действительно, замечательная конструкция сделана в Акурке. не пишу на ней т к мне нравится дос-окно. пробовал как-то под настроение, но добили отличия от синтаксиса досурки.

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

с xBtn Локация_Процедуры, Локация_Перехода, Название кнопки будет всё тоже самое, только вместо {xBtnVAR=#I$} будет стоять имя локации, в которой это присвоение будет выполнено.

твоим методом, т е с помощью xbtn, реализованного в соответствии с твоим предложением ИМХО возможно реализовать любой алгоритм, который можно реализовать с помощью xbtn сделанным по другим принципам, НО в некоторых случаях это будет гемор страшный. вот например, любой массив можно впихнуть в одномерный, НО представь, что ты пишешь игру, которая начинается в центре мира, а затем может постепенно дописываться во все стороны (вполне разумный вариант!). делаем координаты первой локации (0,0,0) на всякий случай (вдруг мы потом ещё подвал или башню где-нить поставим). и растим тихонечко мир во все стороны -> в одни стороны с "+" координатами, в противоположные- с "-". впихнуть всё это в одномерный массив ВОЗМОЖНО, но геморно. и это далеко не единственный случай (бывает нужно ещё списки предметов в карманах персонажей хранить, а для предметов- списки свойств). так же и с твоим xbtn всё возможно, но можно составить случай, когда это будет геморно.

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

DosURQ- рулез!Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 117
Зарегистрирован: 20.01.07
ссылка на сообщение  Отправлено: 13.12.08 14:30. Заголовок: А хотите так: :лока..


А хотите так:

:локация
...
btn кноплок(10, 15), Вот такая вот кнопень
end

...

:кноплок
if (кноплок_пар1 = 10) then ...
...


Можно реализовать. Довольно нетрудно.

Тон.Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 8
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 13.12.08 19:48. Заголовок: noname пишет: ёперн..


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, к каковым переменным мы и будем (при необходимости) обращаться в локации обработчике.


Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 119
Зарегистрирован: 20.01.07
ссылка на сообщение  Отправлено: 13.12.08 21:25. Заголовок: Не, парсить названия..


Не, парсить названия параметров и присваивать - это гимор. :)

Пусть лучше будет так. При нажатии на кнопку, определенную как

btn локация(зн1, зн2), Текст кнопки


произойдет переход на локацию "локация". При этом переменной локация_пар1 будет присвоено значение зн1, переменной локация_пар2 - значение зн1 и т.п.

Количество значений-параметров - не ограничено. Так нормально?

(а чего мы делаем в теме про акурку?)

Тон.Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 9
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 13.12.08 21:56. Заголовок: fireton! Абсолютно ..


fireton!

Абсолютно согласен!

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

Повторяю - я не настаиваю на использовании ТОЛЬКО ОДНОЙ переменной, передаваемой как параметр. Это самоограничение родилось исключительно от мысли, что реализация подобная вашей окажется сложной и несогласующейся с парадигмой URQL.

Суть моих рассуждений можно свести только к одному - НЕ ИСПОЛЬЗОВАТЬ предлагаемый здесь (и возникший явно в запарке) формат xBtn Лока_Проц, Лока_Переход, Кнопа. НЕ ИСПОЛЬЗОВАТЬ потому, что функционал этого формата гораздо беднее существующего сейчас в Акурке. Не все это понимают, но это именно так.

А обсуждаю в этой теме, потому что такое предложение (по формату) возникло именно здесь.

Авторы Акурки справедливо отметили неудобность нынешнего формата xBtn {} (Хотя эта неудобность - исключительно неудобность чтения кода человеком. С машинной точки зрения нынешний xBtn идеален) - и, не совсем подумав, предложили в качестве замены набора произвольных операторов в фигурных скобках использовать ссылку на локацию, содержащую этот набор. С первой точки зрения кажется, что это абсолютно равноценная замена, однако это не так, что я и пытаюсь объяснить.

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

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 145
Зарегистрирован: 03.07.07
ссылка на сообщение  Отправлено: 13.12.08 22:12. Заголовок: БОЖИЙ СУД, ААА :sm1..


БОЖИЙ СУД, ААА

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 10
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 13.12.08 22:16. Заголовок: ну блин, или иначе п..


ну блин, или иначе поединок, дуэль, брошенная перчатка, вызов.

БОЖИИМ СУДОМ в средние века называлась крайняя степень разбирательства, когда анализ аргументов сторон заходил в тупик и невозможно было иначе доказать/опровергнуть чью-то правоту. Поскольку я видимо страдаю формой дизлексии, а именно, неспособностью выражать свои мысли в форме, понятной оппонентам, я предлагаю произвести доказательство практическими действиями.

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 120
Зарегистрирован: 20.01.07
ссылка на сообщение  Отправлено: 13.12.08 22:20. Заголовок: Единственное - при в..



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


Если будет ситуация, когда понадобится передавать нефиксированное количество параметров, передавай первым параметром их количество. :)

Тон.Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 254
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 13.12.08 22:23. Заголовок: fireton пишет: (а ч..


fireton пишет:

 цитата:
(а чего мы делаем в теме про акурку?)


эта тема- про акурку-2, автор которой ещё не определился с синтаксисом xbtn в этом языке (я так понял).

пишет:

 цитата:
btn локация(зн1, зн2), Текст кнопки


ОК! мне это нравится больше любого из предложенных до этого вариантов. а, например, локация_парN будет хранить кол-во передаваемых параметров.

to ghoest: кажись, я тебя понял. понял, что неверно тебя понимал, но ты и сам выражался не больно-то ясно. теперь- порядок! НО остался ещё один малюсенький момент: xbtn локация_процедуры, локация_перехода, имя кнопки, работающая так, как я описывал, математически ровно настолько же функциональна, как и твой xbtn.

минутку, щазз поясню...

DosURQ- рулез!Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 11
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 13.12.08 22:24. Заголовок: ghoest пишет: Если ..


fireton пишет:

 цитата:
Если будет ситуация, когда понадобится передавать нефиксированное количество параметров, передавай первым параметром их количество. :)



ААААААААААААААААААААААААААААААЯТОРМОЗ

Вот это действительно, гениально

ЗЫ (чет на форуме цитирование хреново работает - вместо автора цитаты вставляется мое имя, приходится править

UPD
noname

Извините, что не жду вашего объяснения. Для начала уточню: я понимаю механизм действия формата xBtn Лока_Проц, Лока_Переход, Кнопа как ПОЛНОСТЬЮ эквивалентный нынешнему оператору xBtn Лока_Переход, {proc Лока_Проц}, Кнопа. Если я неверно вас понял, смоделируте то, как вы видите этот формат использую нынешний формат xBtn, если это невозможно - то объясните его действие подробнее. Если же я верно понял - то обещаю, конечно, сильно подумать над вашим разъяснением, однако чувствую, что все-таки прав я, однако объяснить не могу - не хватает мощности преобразовать мысль в текст :)

Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 255
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 13.12.08 22:37. Заголовок: ghoest пишет: я пон..


ghoest пишет:

 цитата:
я понимаю механизм действия формата xBtn Лока_Проц, Лока_Переход, Кнопа как ПОЛНОСТЬЮ эквивалентный нынешнему оператору xBtn Лока_Переход, {proc Лока_Проц}, Кнопа.


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

UPD

АГА! понял окончательно и бесповоротно! действительно, ТЫ ПРАВ! суть в чём: предложенный в этой теме xbtn (в споре с тобой нагло названный мной 'моим') был значительно более удобен старого btn и давал возможность обойтись значительно меньшим числом локаций там, где с btn пришлось бы использовать переменное либо очень большое кол-во локаций. на форуме мне не раз говорили, что без xbtn можно обойтись, и я не раз приводил контрпримеры.

на этот раз Вы(раз уж Вы на Вы, но вроде бы в нете принято на ты?) предложили ещё более удобный и простой вариант, а я проявил узость и не гибкость мышления, и продолжил отстаивать предыдущий. СПАСИБО за проявленное терпение и подробные разъяснения. мне было сложно врубиться, так как не мог использовать xbtn на практике- в досурке его, к сожалению, нет.

p.s.
под занавес хочу ещё раз поддержать вариант, предложенный fireton-ом.

DosURQ- рулез!Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 256
Зарегистрирован: 17.03.08
ссылка на сообщение  Отправлено: 13.12.08 23:11. Заголовок: НО есть одно НО, смо..


НО есть одно НО, смотрим тему сначала:

Korwin пишет:

 цитата:
Не все так легко, Граф. Код может иметь вставки в виде других операторов с запятыми, те же кнопки, да и #%строковая переменная$ тоже штука непредсказуемая. В свое время я предлагал xbtn метка, название, где метка это имя proc, но не понравилось


другими словами, нехорошо, что в предложенном fireton-ом xbtn разделяются запятой название кнопки(которое может содержать запятые) и передаваемые параметры(разделённые запятыми). на этом мозг отключается. иду спать.

DosURQ- рулез!Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 12
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 13.12.08 23:20. Заголовок: noname пишет: редло..


noname пишет:

 цитата:
редложенный в этой теме xbtn ... был значительно более удобен старого btn и давал возможность обойтись значительно меньшим числом локаций там, где с btn пришлось бы использовать переменное либо очень большое кол-во локаций



АГА :).

И все таки лучший вариант предложил fireton (строго говоря, вариант предлагавшийся мной является лишь частным случаем варианта fireton'а) - с чем я и согласн.
Главное - то, что к лучшему для УРКи.


 цитата:
нехорошо, что в предложенном fireton-ом xbtn разделяются запятой название кнопки(которое может содержать запятые) и передаваемые параметры(разделённые запятыми). на этом мозг отключается. иду спать



1. fireton предлагает заключать список параметров в скобки
2. разделять можно точками с запятой
3. можно по прежнему использовать фигурные скобки, по любому оператор вида
xBtn {пар1; ...; парN},Лока, Кнопа
будет более стройным по построению и человекочитаемым, чем оператор
xBtn Лока, {pln Куча_текста; if Укуренное_Условие then; и_прочая_чертова_куча_операторов}, Кнопа
4. В конце концов можно все-таки склониться к минимализму, и обойтись ОДНОЙ переменной :-D

А теперь, раз опасный камень с предлагавшимся ранее нефункциональным форматом xBtn обойден (надеюсь) - просто соображение в порядке бреда.
Касательно использования метки вида :#%Переменная$.

Сейчас объявить такую метку невозможно (проверил лично на имеющихся у меня УРКах). Но если бы это было возможно (а почему бы и нет?) - то это, друзья, БОМБА.

Представьте, что действительно можно описать метку, составная часть имени которой является переменной и определяется на этапе выполнения кода. Это вполне реально - ведь URQL является интерпретируемым языком, и текст программы, с которым работает плеер вполне можно динамически обновлять.
Что мы имеем? А мы имеем неявно задаваемый параметр, который можно использовать при вызове метки! Проще объяснить на куске кода (он не рабочий, но мог бы работать):

:loca
input UsrData
btn Say#%UsrData$, Answer
end

:Say#%UsrData$
pln You said #%UsrData$
end

Данный пример, конечно мало показателен (он вполне может быть изменен с применением обычной метки - но важно следующее - мы смогли передать в вызываемую локацию некий параметр.

Если эту возможность реализовать, то URQL станет единственным претендентом на самый бредовый язык в мире :-D



Спасибо: 0 
ПрофильЦитатаОтветить
постоянный участник




Сообщение: 121
Зарегистрирован: 20.01.07
ссылка на сообщение  Отправлено: 13.12.08 23:24. Заголовок: ghoest пишет: Касат..


ghoest пишет:

 цитата:
Касательно использования метки вида :#%Переменная$.


Мой мозг отказывается это воспринимать. :(

Тон.Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 13
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 13.12.08 23:39. Заголовок: fireton пишет: ghoe..


fireton пишет:

 цитата:
ghoest пишет:
цитата:
Касательно использования метки вида :#%Переменная$.

Мой мозг отказывается это воспринимать. :(



Во-первых, такую метку употребил noname, см. в постах выше.
Во-вторых, это в порядке бреда, просто для разминки мозгов :).
В-третьих, это вполне в духе URQL :)

ЗЫ. Хотя размышлять над таким извращением трудно. (Для меня метка вида :loc#%VAR$ примерно то же самое, что файл c именем file*name.??? :-D) - но тем не менее, легкость, с какой noname применил эту конструкцию заставляет предположить, что она вполне ожидаема кодером (в духе URQL)

Спасибо: 0 
ПрофильЦитатаОтветить



Сообщение: 14
Зарегистрирован: 10.12.08
ссылка на сообщение  Отправлено: 14.12.08 01:58. Заголовок: Перечитал еще раз уч..


Перечитал еще раз участок ветки с моими рассуждениями - действительно, невнятно, и уводит от темы :(

Предлагаю резюмировать итоги обсуждения - чтобы не забивать голову как вновь пришедшим, так и людям, непосредственно причастных к созданию Акурки2 и в частности, к определению окончательного формата xBtn.

МАНИФЕСТ xBtn.

1. Необходимость введения оператора xBtn (либо расширения синтаксиса оператора Btn) признается и более не обсуждается.
[для противников xBtn предлагаю кусок кода из поста о Божием Суде - этот код написан с применением существующего варианта xBtn из 1-й Акурки и, смею утверждать, не может быть реализован с помощью стандартного Btn - ни более длинным/трудным способом, ни каким либо другим - вообще никак]
2. За основу синтаксиса для нового xBtn (либо для расширения синтаксиса Btn) принимается вариант firetona, записываемый в общем виде как
Оператор_Btn [список_выражений], Локация, Название кнопки - окончательный синтаксис следует в дальнейшем уточнить
Данный вариант xBtn понимается, как вариант, математически эквивалентный существующему формату xBtn из 1-й Акурки, а так же как вариант, математически эквивалентный вызову процедур в других языках программирования.
3. Вариант синтаксиса xBtn Л_Проц, Л_Перехода, Название кнопки (а также любой другой синтаксис, который использует в качестве операндов только метки) - признается неудовлетворительным с функциональной точки зрения и далее не обсуждается.

Спасибо: 0 
ПрофильЦитатаОтветить
Ответов - 73 , стр: 1 2 3 4 All [только новые]
Ответ:
1 2 3 4 5 6 7 8 9
видео с youtube.com картинка из интернета картинка с компьютера ссылка файл с компьютера русская клавиатура транслитератор  цитата  кавычки оффтопик свернутый текст

показывать это сообщение только модераторам
не делать ссылки активными
Имя, пароль:      зарегистрироваться    
Тему читают:
- участник сейчас на форуме
- участник вне форума
Все даты в формате GMT  3 час. Хитов сегодня: 1
Права: смайлы да, картинки да, шрифты нет, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет