Zeantar vs Байт
newsash:
Остаётся только надеяться, что следующая версия и описание синтаксиса от Байта будут довольно скоро.
Наивный чукотский юноша.
Байт забил на платформу.
Zeantar,
не надо. Прошу тебя.
Zeantar,
Что, то есть совсем? Вообще? Полностью?
Prophet,
прошу большого внимания не обращать. Зинтар недоволен тем, что Байт давно ничего не делал для QSP.
Байт давно должен был выпустить новую версию классического плеера, и AeroQSP, в том числе исправить баги AeroQSP, а также я просил внести некоторые назревшие изменения в библиотеку. Ещё, перенести код библиотеки на Git-репозиторий. Но до сих пор движений в этом направлении не видно, увы. Хотя напоминали неоднократно.
Это не значит, что Байт “забил”. Слово “забил” означает окончательный отказ от участия, такого не было. Есть только долговременное простаивание дел по развитию. Да, сейчас он этим не занимается. Видимо нагружен работой, или просто лень. По себе знаю, что замотивировать к продолжению может интерес к платформе.
Пишите ему письма. Есть два адреса, nporep@mail.ru и hzdbyte@gmail.com . Какой из них рабочий, не помню уже, пишите, наверное, на оба сразу.
Да, Байта нет. Хлюп-хлюп. И какой будет интерес к платформе, если у самого автора платформы к ней интереса нет? Должен быть король, без короля всё гниёт и запустевает. (((((((((((
Развели флуд и панику((
Не знаю. Я даже немного рад, что пока всё стоит на месте. Первый раз я наткнулся на кусп второй версии, точно не скажу. Всё было чёрное с зелёным. И начал что-то кривенько писать для него. Интернета тогда у меня не было, а когда появился, и я наткнулся сразу на “5.6.с копейками” я просто в ужас пришёл. Так отстать от жизни! Да и сейчас у меня постоянное ощущение, что я не успеваю за платформой. Даже по 5.7.0 и то постоянно узнаю что-то новое. Что же будет дальше? Страшновато.
Ничего себе, открываю форум посмотреть новости и вижу такую шикарную тему! Я уж думал, это я по пьяни устроил дуэль с Байтом. Надеюсь, все понимают, что мои недоволства не имют права на существование, поскольку я написал всего одну игру. Да, дело даже не в том: Байт господин своей судьбы и поступает так, как считает нужным; глупо и нетактично (хотя, когда мне это мешало?) чего-либо требовать, он и так сделал гораздо больше, чем некоторые. Так что прошу прощения у публики за очередную клоунаду.
Zeantar:
Так что прошу прощения у публики за очередную клоунаду.
Клоунаду устроил не ты, а все остальные. :)
Хочу Байта обрааааааатно!!!!! Хочуууууу!!!!!! Верните Баааайта!!!!!!
Хлюп, хлюп, хлюп…
А зачем вообще новые версии классического плеера?
Flashback:
А зачем вообще новые версии классического плеера?
После версии 5.7.0 синтаксис QSP несколько поменялся. Сейчас есть три плеера с различающимся синтаксисом (например, команды ADDQST, ADDLIB, INCLIB) - классический, AeroQSP и Quest Navigator. Привести их все к 5.7.0 невозможно из-за того, что удобный интерфейс взаимодействия у библиотеки появился тоже после 5.7.0. Выход следующей версии уравняет хотя бы два плеера.
А ещё в следующей версии будут такие фишки, как циклы (не через jump, а нормальные), локальные переменные, ну и ещё несколько вкусностей.
newsash:
А ещё в следующей версии будут такие фишки, как циклы (не через jump, а нормальные)
А в чем разница? Если “нормальные” циклы будут лучше для производительности (?), то от этого есть какой-то прок… Хотя я даже представить не могу представить практически необходимый для игры код c использованием jump, способный вызвать ощутимое торможение в стандартном плеере. Иначе, не вижу какой толк от инструмента, дублирующего существующий. В qsp и так есть команды, которые непонятно зачем нужны. function и gosub, к примеру, по сути своей делают одно и то же. А вместо if strcomp(…)=-1 удобнее использовать if strfind(…)!’’ А вот локальные переменные - неплохая идея, у меня несколько раз ошибки были из-за того, что забывал обнулить x и y после обработки одной локации и перехода в другую где работа с ними должна начинаться с нулевых значений. Лично мне еще бы хотелось четвертый аргумент в replace - то, что единственная функция совершающая изменение *обрабатываемой* строки по умолчанию заменяет ВСЕ вхождения заменяемого фрагмента - не очень удобно. replace($a,$b,$c,x) где x - заменять первые x вхождений $b. Ну или хотя бы x=1 или ноль, при 1 - только первое вхождение, при 0 (или нет аргумента) - все. Это конечно не такая уж большая проблема, но в отдельных случаях просто на ушах плясать приходится, комбинируя различные функции работы со строками для решения проблемы.
А, чуть не забыл. Еще было бы очень здорово, если бы была возможность прицеплять строки кода к действиям из контекстного меню. Ну или хотя бы аргументы для args. В текущем виде это самое меню не позволяет делать ничего кроме переходов на локации (без передачи на них каких-либо данных). На редкость слабый инструмент, словом - гиперссылки в этом плане для решения связанных с интерфейсом задач подходят куда лучше.
Stag_Beetle:
Иначе, не вижу какой толк от инструмента, дублирующего существующий.
Про производительность не знаю. Есть ещё такая вещь, как читаемость кода. Цикл заданный явно более понятен, чем сварганенный на jump.
Stag_Beetle:
function и gosub
Я тоже за объединение. Только для этого придётся убрать возможность вывода в главное окно просто текста в коде (без *P, *PL, *NL).
Stag_Beetle:
if strfind(…)!’’
Скорее strfind(…)!$исх_строка. Но я не уверен на 100%. Точно не ’’.
Stag_Beetle:
четвертый аргумент в replace
Напиши Байту. Думаю, ему будет приятно, что есть люди, которым не всё равно.
Stag_Beetle:
В текущем виде это самое меню не позволяет делать ничего кроме переходов на локации (без передачи на них каких-либо данных).
Номер выбранного пункта меню передаётся в args[0]. Нумерация с 1. Это позволяет однозначно определять выбранный пункт меню.
Stag_Beetle:
А вот локальные переменные - неплохая идея, у меня несколько раз ошибки были из-за того, что забывал обнулить x и y после обработки одной локации и перехода в другую где работа с ними должна начинаться с нулевых значений.
Можно использовать массив ARGS для работы с локальными переменными.
Stag_Beetle:
Еще было бы очень здорово, если бы была возможность прицеплять строки кода к действиям из контекстного меню. Ну или хотя бы аргументы для args. В текущем виде это самое меню не позволяет делать ничего кроме переходов на локации (без передачи на них каких-либо данных). На редкость слабый инструмент
Все эти проблемы решает “Модуль для работы с меню” — там и строки кода к действиям, и параметры к вызываемому коду/локации.
Olegus t.Gl.:
Все эти проблемы решает “Модуль для работы с меню” — там и строки кода к действиям, и параметры к вызываемому коду/локации.
Уже отыскал) Показалось довольно сложным, но ответ я все-таки нашел. Не знал, индекс выбранного пункта меню передается в аргс… Я голову сломал пытаясь придумать как можно получить данные о том, какой пункт выбран и пришел к тому, что это невозможно, а оказывается что это уже существует само по себе. Меню мне все равно не по душе, некрасивые они какие-то. Но теперь смогу их использовать для чего угодно, если уж совсем припрет. Что-то вроде:
Меню_1[0]=Действие_1:обработка
...
Меню_1[n]=Действие_n:обработка
'<a href="EXEC:$code=''#1#строка_кода_1#2#строка_кода_2...#n#строка_кода_n'' & menu''Меню_1''">Вызвать меню!</a>
обработка (локация)
dynamic '<<strfind($code,"#<<args[0]>>#([^#+])#",1)>>'
Если действия подобны, то можно только передачей переменных обойтись, без строк кода. Ну а названия пунктов меню вообще кучей способов менять можно. В общем, все путем)
Или даже так:
'<a href="EXEC:$name=''0:1/1:2/.../x:n'' & $code=''#1#строка_кода_1#2#строка_кода_2...#n#строка_кода_n'' & gt ''build_menu''">Вызвать меню!</a>
локация build_menu
killvar 'Меню_1' & killvar 'x'
:loop
Меню_1[x]=$База_названий_пунктов_меню['<<strfind($name,"<<x>>:(\d+)",1)>>']+':обработка'
if Меню_1[x]=':обработка' : Меню_1[x]='' & menu 'Меню_1' else x=x+1 & jump 'loop'
А если сделать $name и $code массивами и изменять строки в них по мере необходимости в ходе игры, то вообще что угодно можно делать. Меню не так уж и плохи как я думал вначале.
з.ы. Спасибо всем, пока все что мне нужно я уяснил.
з.з.ы вроде была пара ошибок в коде, поправил.