Свой скриптовый движок с шахматами и поэтессами.

[inv 858]

Как мы все знаем, во всех lua скриптовых движках для XPlane имеется фатальный недостаток: референсная имплементация lua медленная, потому все используют luajit, который имеет серьезную проблему с выделением памяти на 64-х битных системах и будущее его весьма сомнительно (за 3 года толком ничего не добавили, а версии 3, похоже, нету даже в проекте).

 

В итоге я написал just for fun свой велосипед, использующий JavaScript.

 

Почему JS?

0. Модно, стильно, молодёжно.

1. Широко используемый, развивающийся язык.

2. Много постоянно развивающихся интерпретаторов (v8, SpiderMonkey)

3. Возможность тестировать свои наработки как в бразузере, так и прямо онлайен на том же jsfiddle.

4*. Отладчик (хотя для lua тоже есть отладчики, но тем не менее я его таки прикрутил

 

Вдруг кому-то надо:

https://github.com/invy/xpjs

 

TODO: собрать и протестировать под виндой/маком, дописать фичи (потому что пока только запись/чтение датарефов), починить баги

Пример скрипта:

xplog('plugin started at: ' +new Date())
 
// data ref definition
var axisValues = requestDRef('sim/joystick/joystick_axis_values');
var hstabElev = requestDRef('sim/flightmodel2/wing/elevator1_deg');
var ail1 = requestDRef('sim/flightmodel2/wing/aileron1_deg');
var overrideSurfaces = requestDRef('sim/operation/override/override_control_surfaces');
 
set(overrideSurfaces, 1);

function update() {
 var pitch = getAt(axisValues, 1);
 var roll = getAt(axisValues, 0);
 setAt(hstabElev, 8, -(pitch-0.5)*30);
 setAt(hstabElev, 9,-(pitch-0.5)*30);
 setAt(ail1, 0, (roll-0.5)*30);
 setAt(ail1, 1, -(roll-0.5)*30);
}

Более крупный пример (fbw а-ля airbus): https://github.com/invy/xpjs/blob/master/examples/fbw/avionics.js

 

На картинке справа - отладчик/консоль (jrdb из проекта jsrdb). Можно как выполнять скрипт пошагово, так и вызывать различные функции, что иногда бывает удобным.

[Maxxe 540]

Клево-клево. А можно в двух словах про проблему с памятью luajit x64?

[inv 858]

Клево-клево. А можно в двух словах про проблему с памятью luajit x64?

Одним словом - там дикие костыли.

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

Разработчики XPlane и lua-плагинов придумали костыль: XPlane при загрузке резервирует место в первых двух гигабайтах, и выделяет плагинам, использующим lua по их требованию.

Но это еще не всё. По какой-то причине разработчики luajit решили убрать из API возможность указывать luajit'у allocator, в итоге для работы вышеописанных костылей нужна еще и патченая версия luajit'a.

 

Подробнее тут: http://hacksoflife.blogspot.de/2012/12/integrating-luajit-with-x-plane-64-bit.html

 

Ну и да, у меня почему-то ВСЕ версии sasl'а (само-собранная, проприетарная, те, которые были раньше),  вешают XPlane намертво, почему - не ясно и ковыряться как-то не сильно хотелось, интереснее было написать велосипед.

[Maxxe 540]

Да уж, дичь еще та. А оригинальный луа сильно медленней джита?

[inv 858]

Да уж, дичь еще та. А оригинальный луа сильно медленней джита?

Судя по тестам с luajit'а довольно большая разница: http://luajit.org/performance_x86.html

[Ghost-V 198]

Больше скриптов хороших и разных! :pioneer:

Как мы все знаем, во всех lua скриптовых движках для XPlane имеется фатальный недостаток: референсная имплементация lua медленная

Слова lua и X-Plane в этом предложении лишние ;) Интерпретатор, даже с байт-кодом, переубедить таки сложно :sarcastic:, что тесты по приведенной ссылке хорошо иллюстрируют

[inv 858]

Больше скриптов хороших и разных! :pioneer:

Слова lua и X-Plane в этом предложении лишние ;) Интерпретатор, даже с байт-кодом, переубедить таки сложно :sarcastic:, что тесты по приведенной ссылке хорошо иллюстрируют

В общем, да, для серьезных моделей оно всё не очень подходит, но для мелочей и экспериментов скрипты удобны.

[Ghost-V 198]

В общем, да, для серьезных моделей оно всё не очень подходит, но для мелочей и экспериментов скрипты удобны.

Как средство прототипирования - почти идеально. Вот хоть С скриптовый запихивай, чтобы потом не переписывать заново ;)

[inv 858]

Добавил пример: fbw а-ля airbus. (Пока автотрим без протекшнов)

https://github.com/invy/xpjs/blob/master/examples/fbw/avionics.js

 

Тестировал на модельке dc9-30 (бесплатная с орга), летает как по рэльсам.

[Ghost-V 198]

Добавил пример: fbw а-ля airbus. (Пока автотрим без протекшнов)

Интеграл бы только ограничить, на всякий случАй. Имеет свойство иногда феерично гадить :yes:

[inv 858]

Интеграл бы только ограничить, на всякий случАй. Имеет свойство иногда феерично гадить :yes:

По хорошему, сначала надо настроить адекватную скорость отклонения плоскостей, а потом уже настраивать регуляторы и всё остальное

 

Но совет учту

[Ghost-V 198]

По хорошему, сначала надо настроить адекватную скорость отклонения плоскостей, а потом уже настраивать регуляторы и всё остальное

А эта бяка может как раз таки мешать настройке. В реальности, если уж используется именно PID, то интеграл(не коэффициент при ∫ !) цЫнично ограничивается в росте.

[inv 858]

А эта бяка может как раз таки мешать настройке. В реальности, если уж используется именно PID, то интеграл(не коэффициент при ∫ !) цЫнично ограничивается в росте.

Речь об integral windup, я правильно понимаю?

[Ghost-V 198]

Речь об integral windup, я правильно понимаю?

Это если глобально. А так - вот про это:

this.intgral += error*dt;

Хочется ему приделать что-то вроде

this.intgral = limit(this.intgral, value);

[inv 858]

 

Это если глобально. А так - вот про это:

this.intgral += error*dt;

Хочется ему приделать что-то вроде

this.intgral = limit(this.intgral, value);

Ну да, значит я правильно понял (и таки приделал, между делом).

[Romchique 332]

javascript это очень круто, дальше развивать планируете?

[inv 858]

javascript это очень круто, дальше развивать планируете?

С большой вероятностью я что-то еще буду дописывать. Как вариант, есть мысль, выкинуть из sasl'а lua и прикрутить javascript, переписав два десятка врапперов. Одна из проблем JS - подгрузка других скриптов (типа import/include). Конечно можно навелосипедить, но эта "фича" заявлена в новом стандарте и скоро должна появиться в движках. Потому подожду, т.к. велосипедить будет впустую.

 

ps а еще import можно подсмотреть в gjs

[inv 858]

Улучшил вывод информации об ошибках в скрипте (а то я недавно сильно мучался чтобы найти поставленную по привычке 'f' после числа)

 

XPJS: [161] /media/igor/sg250trash/XPlane/XP10/Aircraft/Heavy Metal/DC9-32/avionics.js: 92:34
                SyntaxError: identifier starts immediately after numeric literal
                          at: 0.5f) < this.neutralZone &&

[atcstagervip 3578]

Прикольно. Но будут ли какие то особые фитчи, которых нет в САСЛ изкаропки?
Логика систем имхо пофиг на каком скрипте. Она по сути сводится к взял из датарефа, перемножил на что то и запихнул в другой датареф.

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

 

[inv 858]

Прикольно. Но будут ли какие то особые фитчи, которых нет в САСЛ изкаропки?

Логика систем имхо пофиг на каком скрипте. Она по сути сводится к взял из датарефа, перемножил на что то и запихнул в другой датареф.

 

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

И что бы это было понятно простым быдло-скрипто-кодерам типа меня

Не думаю, что какие-то особые фичи в обозримом будущем предвидятся. Основной моей целью было заменить sasl (и другие lua-движки) из-за связанных с ними проблемами. (в планах было управлять частотой вызова flight loop callback, а то каждый кадр дергать скрипты далеко не всегда надо и удобно).

 

На данный момент есть две фичи, которых нету(прямо так искаропки) в lua-плагинах:

1) Отладчик

2) Возможность взять кусок кода и поиграться с ним на jsfiddle, примерно так: http://jsfiddle.net/71dnfkbm/4/

[Maxxe 540]

По поводу семпла с FBW. Насколько я помню, то если проставить override control surfaces то нужно полностью писать свою логику отклонения поверхностей. И по-моему это относится и к закрылкам/спойлерам в том числе. А в примере я их не вижу. Это просто тестовая версия, или в случае оверрайда закрылки и спойлеры таки управляются плейном?

[inv 858]

По поводу семпла с FBW. Насколько я помню, то если проставить override control surfaces то нужно полностью писать свою логику отклонения поверхностей. И по-моему это относится и к закрылкам/спойлерам в том числе. А в примере я их не вижу. Это просто тестовая версия, или в случае оверрайда закрылки и спойлеры таки управляются плейном?

Естественно это просто пример и баловство. Ни закрылок, ни РН там нету. Там только аватотрим с удержанием положения. Я так потихоньку балуюсь, закрылки дописал, переключение режимов ground/flight/flare сделал. Но то такое, сами режимы надо же тоже написать.

 

Особенно много вопросов вызывает 'load factor demand'. Принцип понятен, но не работает как я хочу.

[Maxxe 540]

Тогда понятно. А то я как-то  написал простой констрэйнт на угол атаки, а потом понял что для того чтобы он работал, надо собственно переписать логику управления ВСЕГО с учетом систем, временем отклика и т.д. Вобщем пока пришлось забить.

[inv 858]

Тогда понятно. А то я как-то  написал простой констрэйнт на угол атаки, а потом понял что для того чтобы он работал, надо собственно переписать логику управления ВСЕГО с учетом систем, временем отклика и т.д. Вобщем пока пришлось забить.

Ну там не так и много всего остальнго. Тем более если не нужна какая-то хитрая логика.

Для закрылок грубо говоря такие костыли я изобразил (не претендую на элегантность и правильность) 

  var Flaps = function Flaps() {
    this.isCleanConfig = function() {
      if(get(flapsDeployRatioDRef) == 0.0)
        return true;
      return false;
    }
    this.update = function() {
      const hdr = get(flapsHandleDeployRatio);
      set(flapsDeployRatioDRef, hdr);
      set(lWingFlapsAngle, hdr*40);
      set(rWingFlapsAngle, hdr*40);
    }
  }
  var Slats = function Slats() {
    this.isCleanConfig = function() {
      if(get(flapsDeployRatioDRef) == 0.0)
        return true;
      return false;
    }
    this.update = function(dt) {
      const slatPos = get(slatsRat);
      if(get(flapsHandleDeployRatio) > 0 && slatPos < 1) {
        var newPos = Math.min(slatPos+0.3*dt, 1); 
        set(slatsRat, newPos);
      }
      else if(get(flapsHandleDeployRatio) == 0 && slatPos > 0) {
        var newPos = Math.max(slatPos-0.3*dt, 0); 
        set(slatsRat, newPos);
      }
    }
  }

[Maxxe 540]

В первом приближении да. Но это ведь надо для всех поверхностей. С учетом времени отклика. Да еще завести логику по гидравлике, наличию питания. А потом с этим всем попытаться взлететь У меня по ощущениям на отладку скриптов уходит чуть ли не в два раза больше времени чем написание