Quest Navigator для Windows

Хотелось бы возможность управлять размерами окна через JS, чтобы при масштабировании экрана (JSFiddle scaling - если захочется встроить это в движок) убрать поля, которые появляются при нарушении пропорций.
А ещё я тут заметил, что ширина окна 804, высота окна во время InitAPI 617, во время игры 601 при установках 800 на 600.
Ещё во время вызова qspSkinOnInitAPI не проинициализирована переменная gameSkin.

Хотя всё кроме изменения размеров окна легко обходится на уровне game.js

И снова я…
А есть возможность зарезервировать все ключевые слова, которые не реализованы на уровне движка (типа переменных оформления), и загнать их в какую-нибудь JS переменную типа gameSkin? Или сложно?

newsash,
ты имеешь в виду, сделать частичную поддержку переменных оформления?
Да, это можно сделать, например в подключаемом QSP-модуле (дополнительный QSP-файл с обработкой этих переменных). Собственно я даже планировал сделать это, чтобы облегчить портирование AeroQSP-игр на QuestNavigator. Ну и соответствующий JS-код.

Суть в том, что это если и будет делаться, то только на уровне игры, скина оформления, а не на уровне плеера.

Я имел в виду уровень дополнительного QSP-файла переместить частично на уровень плеера, чтобы можно было делать портирование AeroQSP-игр просто подстановкой правильного скина (с последующей доработкой напильником стилей). Хотя твоя идея мне даже больше нравится.

newsash,
нет, в плеере не будет поддержки переменных AeroQSP. Подобные переменные оформления - это решение, которое оказалось ошибочным. Моё убеждение основано не просто на предположении, или логическом выводе. Я убедился в этом на практике, вследствие моего собственного опыта разработки коммерческих игр. Для игр приемлемого уровня качества этот способ не подходит.

Более того, за поддержку этого хозяйства на уровне плеера, остальным играм (не использующим переменные) придётся расплатиться быстродействием (критично на мобильниках), а также с гораздо большим трудом будет происходить разработка шаблонов оформления и самого Javascript-движка. Усложнится логика работы плеера, усложнится вёрстка, всё это отрицательно повлияет на разработку игр и плеера. Усложнение вёрстки означает не просто больше работы. К сожалению мобильные браузеры кишат багами, и чем сложнее вёрстка тем чаще на них натыкаешься - это я тоже проверил на практике. Оно того не стоит, проще перенести те игры что уже сделаны на AeroQSP на новый движок, благо их не так уж много.

Это не просто лень, или прихоть - для меня это взвешенный выбор, учитывая все “за” и “против”.

if instr(1,$Result,'"')>0:

Type mismatch.

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

newsash,
это изменение не в Навигаторе, а в библиотеке (интерпретаторе). В Навигаторе используется самая свежая версия библиотеки, а в классическом плеере и AeroQSP “старая”.

Игры в 99 из 100 случаев используют поиск в строке с 1 символа, это параметр по умолчанию. Точно так же как в твоём примере. В этом случае выражение должно быть записано так:

IF INSTR($Result, '"') > 0:

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

Nex:

В Навигаторе используется самая свежая версия библиотеки, а в классическом плеере и AeroQSP “старая”.

А где-нибудь есть этот список отличий, чтобы не выяснять такие вещи тестами?

newsash,
это у Байта надо спрашивать. Где-то он вёл блог по изменениям. Ну и в коммитах в репозитории можно посмотреть.

Спросил. Библиотека в состоянии переработки. Может стоит использовать версию 5.7.0 библиотеки, пока он сам не выпустит новую версию? А то информации по изменениям нет и не будет до того, как он переработает библиотеку. Авторы будут налетать на такие нюансы и это вряд ли пойдёт на пользу платформе.

newsash,
проблема в том, что изменился не только синтаксис, изменилось взаимодействие плеера и библиотеки. Просто “переключить версию библиотеки” не выйдет, нужно будет переделывать плеер для того чтобы он мог работать со старой библиотекой. А после выхода новой версии классического плеера (который ещё неизвестно в каком году состоится), придётся переделывать всё обратно. Я не считаю это целесообразным, к тому же для авторов там почти ничего не поменялось.

Nex:

изменился не только синтаксис, изменилось взаимодействие плеера и библиотеки

Ох…

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

1. В qspSetActsContent вместо:

   @@@@CODEBLOCK0@@@@

   стоило бы сделать

   @@@@CODEBLOCK1@@@@

2. Windows8/IE10 - во время работы игры периодически открываются страницы в браузере со ссылкой “http://wpad/wpad.dat" без особых закономерностей

3. Не реализован showInput. UPD: Решается - в qspUpdateSkin в api.js:

   @@@@CODEBLOCK2@@@@ заменит на

   @@@@CODEBLOCK3@@@@

4. Ширина окна 804, высота окна во время InitAPI 617, во время игры 601 при установках 800 на 600.

5. Во время вызова qspSkinOnInitAPI не проинициализирована переменная gameSkin. Мне тогда не понравилось, но сейчас я думаю, что это нормально.

6. Желательно получить возможность управлять размерами игрового окна. Лично мне это нужно, чтобы сохранять пропорции окна при масштабировании а-ля AeroQSP (в нём остаются чёрные поля, некрасиво).

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

8. У INSTR(,,) необязательный аргумент переставлен в конец. Могут быть и другие подобные отличия. Это произошло из-за того, что в Навигаторе используется более новая библиотека Байта. Документации по таким отличиям нет, придётся выяснять методом тыка. Вернуться на версию 5.7.0 не получится, т.к. поменялся интерфейс взаимодействия между плеером и интерпретатором.

9. Новое: пытаюсь запустить игру не из папки с Навигатором. Ошибка “Не удалось загрузить XML-структуру”. Удаляю config.xml - игра запускается. UPD: Баг сломался, я не могу его воспроизвести.

10. Новое2: INCLIB (ADDQST) требует путей относительно запускающего .cmd файла, а не относительно game.qsp, что очень неудобно

11. Новое2: В input-line не работает backspace

Мне нужны исправления по пунктам 1-3 и (6 или 9), чтобы доделать универсальный шаблон и тестить его на классических играх. Есть ещё вопрос с Куртуазной балладой, но тут я костыль вставлю по ALWAYS_SHOW_VIEW.

Несколько раз просматривал тему, решил попробовать.
Скачал из шапки. Установил. Что-то он меня спрашивал про обновления, я пропустил, теперь при запущенном QN периодически вылазит http://wpad/wpad.dat (см. резюме newsash).
Создал xml, прочитал в википедии, как выглядит корневой аргумент, как приписать ему атрибуты, написал. Сначала мне выводилась ошибка, дескать не могу прочитать структуру xml. Очевидно неправильно заполнил или вписал какие-то атрибуты. Убрал всё кроме ширины, высоты и title. QN запускается. Но чистый белый экран и ничего больше. Проверил на простейшем примере: вывод строки через *pl. Вопрос: игру нужно как-то допиливать, чтобы хоть что-нибудь рисовалось? Или всё-таки я что-то не так сделал?

Aleks Versus:

Или всё-таки я что-то не так сделал?

Там пока гораздо сложнее всё, чтобы игру запустить. Можешь посмотреть эту статью. А вообще лучше подождать версии, где будет баг с XML исправлен, а пока изучать HTML и CSS, т.к. всё оформление в Навигаторе делается на чистом HTML и CSS, разве что переменные оформления из классического плеера вроде поддерживаются.

Ох ты ж ёжик! Поковыряться, конечно, можно, но что-то лень. Надо бы как-то ссылками статьи относящиеся к “Создание игр на Quest Navigator” перекрестить, а то ведь пока в голову не стукнет, не догадаешься нажать на “все страницы”.