Как мы все знаем, во всех lua скриптовых движках для XPlane имеется фатальный недостаток: референсная имплементация lua медленная, потому все используют luajit, который имеет серьезную проблему с выделением памяти на 64-х битных системах и будущее его весьма сомнительно (за 3 года толком ничего не добавили, а версии 3, похоже, нету даже в проекте).
В итоге я написал just for fun свой велосипед, использующий JavaScript.
Почему JS?
0. Модно, стильно, молодёжно.
1. Широко используемый, развивающийся язык.
2. Много постоянно развивающихся интерпретаторов (v8, SpiderMonkey)
3. Возможность тестировать свои наработки как в бразузере, так и прямо онлайен на том же jsfiddle.
4*. Отладчик (хотя для lua тоже есть отладчики, но тем не менее я его таки прикрутил 
Вдруг кому-то надо:
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/i…fbw/avionics.js
На картинке справа — отладчик/консоль (jrdb из проекта jsrdb). Можно как выполнять скрипт пошагово, так и вызывать различные функции, что иногда бывает удобным.
Сообщение отредактировано inv: 06 January 2016 — 14:29
Как мы все знаем, во всех 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/i…fbw/avionics.js
На картинке справа — отладчик/консоль (jrdb из проекта jsrdb). Можно как выполнять скрипт пошагово, так и вызывать различные функции, что иногда бывает удобным.
Сообщение отредактировано inv: 06 January 2016 — 14:29
Клево-клево. А можно в двух словах про проблему с памятью luajit x64?
Клево-клево. А можно в двух словах про проблему с памятью luajit x64?
Одним словом — там дикие костыли.
В двух словах: luajit может выделять память только в первых двух гигабайтах аддресного пространства (почему так написан — не ясно), что приводило к проблемам (Когда XPlane загрузит сценариев и объектов, в первых двуг гигабайтах места совсем не остается).
Разработчики XPlane и lua-плагинов придумали костыль: XPlane при загрузке резервирует место в первых двух гигабайтах, и выделяет плагинам, использующим lua по их требованию.
Но это еще не всё. По какой-то причине разработчики luajit решили убрать из API возможность указывать luajit’у allocator, в итоге для работы вышеописанных костылей нужна еще и патченая версия luajit’a.
Подробнее тут: http://hacksoflife.b…ane-64-bit.html
Ну и да, у меня почему-то ВСЕ версии sasl’а (само-собранная, проприетарная, те, которые были раньше), вешают XPlane намертво, почему — не ясно и ковыряться как-то не сильно хотелось, интереснее было написать велосипед.
Сообщение отредактировано inv: 05 January 2016 — 17:41
Одним словом — там дикие костыли.
В двух словах: luajit может выделять память только в первых двух гигабайтах аддресного пространства (почему так написан — не ясно), что приводило к проблемам (Когда XPlane загрузит сценариев и объектов, в первых двуг гигабайтах места совсем не остается).
Разработчики XPlane и lua-плагинов придумали костыль: XPlane при загрузке резервирует место в первых двух гигабайтах, и выделяет плагинам, использующим lua по их требованию.
Но это еще не всё. По какой-то причине разработчики luajit решили убрать из API возможность указывать luajit’у allocator, в итоге для работы вышеописанных костылей нужна еще и патченая версия luajit’a.
Подробнее тут: http://hacksoflife.b…ane-64-bit.html
Ну и да, у меня почему-то ВСЕ версии sasl’а (само-собранная, проприетарная, те, которые были раньше), вешают XPlane намертво, почему — не ясно и ковыряться как-то не сильно хотелось, интереснее было написать велосипед.
Сообщение отредактировано inv: 05 January 2016 — 17:41
Да уж, дичь еще та. А оригинальный луа сильно медленней джита?
Да уж, дичь еще та. А оригинальный луа сильно медленней джита?
Судя по тестам с luajit’а довольно большая разница: http://luajit.org/performance_x86.html
Судя по тестам с luajit’а довольно большая разница: http://luajit.org/performance_x86.html
Слова lua и X-Plane в этом предложении лишние
Интерпретатор, даже с байт-кодом, переубедить таки сложно 
, что тесты по приведенной ссылке хорошо иллюстрируют
Слова lua и X-Plane в этом предложении лишние
Интерпретатор, даже с байт-кодом, переубедить таки сложно 
, что тесты по приведенной ссылке хорошо иллюстрируют
В общем, да, для серьезных моделей оно всё не очень подходит, но для мелочей и экспериментов скрипты удобны.
В общем, да, для серьезных моделей оно всё не очень подходит, но для мелочей и экспериментов скрипты удобны.
Как средство прототипирования — почти идеально. Вот хоть С скриптовый запихивай, чтобы потом не переписывать заново
Как средство прототипирования — почти идеально. Вот хоть С скриптовый запихивай, чтобы потом не переписывать заново
Добавил пример: fbw а-ля airbus. (Пока автотрим без протекшнов)
https://github.com/i…fbw/avionics.js
Тестировал на модельке dc9-30 (бесплатная с орга), летает как по рэльсам.
Добавил пример: fbw а-ля airbus. (Пока автотрим без протекшнов)
https://github.com/i…fbw/avionics.js
Тестировал на модельке dc9-30 (бесплатная с орга), летает как по рэльсам.
Интеграл бы только ограничить, на всякий случАй. Имеет свойство иногда феерично гадить
Интеграл бы только ограничить, на всякий случАй. Имеет свойство иногда феерично гадить
По хорошему, сначала надо настроить адекватную скорость отклонения плоскостей, а потом уже настраивать регуляторы и всё остальное
Но совет учту
Сообщение отредактировано inv: 06 January 2016 — 15:34
По хорошему, сначала надо настроить адекватную скорость отклонения плоскостей, а потом уже настраивать регуляторы и всё остальное
Но совет учту
Сообщение отредактировано inv: 06 January 2016 — 15:34
А эта бяка может как раз таки мешать настройке. В реальности, если уж используется именно PID, то интеграл(не коэффициент при ∫ !) цЫнично ограничивается в росте.
Сообщение отредактировано Ghost-V: 06 January 2016 — 15:35
А эта бяка может как раз таки мешать настройке. В реальности, если уж используется именно PID, то интеграл(не коэффициент при ∫ !) цЫнично ограничивается в росте.
Сообщение отредактировано Ghost-V: 06 January 2016 — 15:35
Речь об integral windup, я правильно понимаю?
Речь об integral windup, я правильно понимаю?
Это если глобально. А так — вот про это:
Хочется ему приделать что-то вроде
Сообщение отредактировано Ghost-V: 06 January 2016 — 15:59
Это если глобально. А так — вот про это:
Хочется ему приделать что-то вроде
Сообщение отредактировано Ghost-V: 06 January 2016 — 15:59
Ну да, значит я правильно понял (и таки приделал, между делом).
Сообщение отредактировано inv: 06 January 2016 — 16:25
Ну да, значит я правильно понял (и таки приделал, между делом).
Сообщение отредактировано inv: 06 January 2016 — 16:25
javascript это очень круто, дальше развивать планируете?
javascript это очень круто, дальше развивать планируете?
С большой вероятностью я что-то еще буду дописывать. Как вариант, есть мысль, выкинуть из sasl’а lua и прикрутить javascript, переписав два десятка врапперов. Одна из проблем JS — подгрузка других скриптов (типа import/include). Конечно можно навелосипедить, но эта «фича» заявлена в новом стандарте и скоро должна появиться в движках. Потому подожду, т.к. велосипедить будет впустую.
ps а еще import можно подсмотреть в gjs
Сообщение отредактировано inv: 07 January 2016 — 02:47
С большой вероятностью я что-то еще буду дописывать. Как вариант, есть мысль, выкинуть из sasl’а lua и прикрутить javascript, переписав два десятка врапперов. Одна из проблем JS — подгрузка других скриптов (типа import/include). Конечно можно навелосипедить, но эта «фича» заявлена в новом стандарте и скоро должна появиться в движках. Потому подожду, т.к. велосипедить будет впустую.
ps а еще import можно подсмотреть в gjs
Сообщение отредактировано inv: 07 January 2016 — 02:47
Улучшил вывод информации об ошибках в скрипте (а то я недавно сильно мучался чтобы найти поставленную по привычке ‘f’ после числа)
Улучшил вывод информации об ошибках в скрипте (а то я недавно сильно мучался чтобы найти поставленную по привычке ‘f’ после числа)
Прикольно. Но будут ли какие то особые фитчи, которых нет в САСЛ изкаропки?
Логика систем имхо пофиг на каком скрипте. Она по сути сводится к взял из датарефа, перемножил на что то и запихнул в другой датареф.
Ну из фич вот что-нибудь аля отрисовка кастомных
порнофильмовприборов отдельно от сима (можно и браузер, но свое окно кошерней).И что бы это было понятно простым быдло-скрипто-кодерам типа меня
Сообщение отредактировано skyteacher: 08 January 2016 — 13:17
Прикольно. Но будут ли какие то особые фитчи, которых нет в САСЛ изкаропки?
Логика систем имхо пофиг на каком скрипте. Она по сути сводится к взял из датарефа, перемножил на что то и запихнул в другой датареф.
Ну из фич вот что-нибудь аля отрисовка кастомных
порнофильмовприборов отдельно от сима (можно и браузер, но свое окно кошерней).И что бы это было понятно простым быдло-скрипто-кодерам типа меня
Сообщение отредактировано skyteacher: 08 January 2016 — 13:17
Не думаю, что какие-то особые фичи в обозримом будущем предвидятся. Основной моей целью было заменить sasl (и другие lua-движки) из-за связанных с ними проблемами. (в планах было управлять частотой вызова flight loop callback, а то каждый кадр дергать скрипты далеко не всегда надо и удобно).
На данный момент есть две фичи, которых нету(прямо так искаропки) в lua-плагинах:
1) Отладчик
2) Возможность взять кусок кода и поиграться с ним на jsfiddle, примерно так: http://jsfiddle.net/71dnfkbm/4/
Сообщение отредактировано inv: 08 January 2016 — 15:06
Не думаю, что какие-то особые фичи в обозримом будущем предвидятся. Основной моей целью было заменить sasl (и другие lua-движки) из-за связанных с ними проблемами. (в планах было управлять частотой вызова flight loop callback, а то каждый кадр дергать скрипты далеко не всегда надо и удобно).
На данный момент есть две фичи, которых нету(прямо так искаропки) в lua-плагинах:
1) Отладчик
2) Возможность взять кусок кода и поиграться с ним на jsfiddle, примерно так: http://jsfiddle.net/71dnfkbm/4/
Сообщение отредактировано inv: 08 January 2016 — 15:06
По поводу семпла с FBW. Насколько я помню, то если проставить override control surfaces то нужно полностью писать свою логику отклонения поверхностей. И по-моему это относится и к закрылкам/спойлерам в том числе. А в примере я их не вижу. Это просто тестовая версия, или в случае оверрайда закрылки и спойлеры таки управляются плейном?
Естественно это просто пример и баловство. Ни закрылок, ни РН там нету. Там только аватотрим с удержанием положения. Я так потихоньку балуюсь, закрылки дописал, переключение режимов ground/flight/flare сделал. Но то такое, сами режимы надо же тоже написать.
Особенно много вопросов вызывает ‘load factor demand’. Принцип понятен, но не работает как я хочу.
Сообщение отредактировано inv: 08 January 2016 — 15:30
Тогда понятно. А то я как-то написал простой констрэйнт на угол атаки, а потом понял что для того чтобы он работал, надо собственно переписать логику управления ВСЕГО с учетом систем, временем отклика и т.д. Вобщем пока пришлось забить.
Ну там не так и много всего остальнго. Тем более если не нужна какая-то хитрая логика.
Для закрылок грубо говоря такие костыли я изобразил (не претендую на элегантность и правильность)
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); } } }Сообщение отредактировано inv: 08 January 2016 — 18:22
В первом приближении да. Но это ведь надо для всех поверхностей. С учетом времени отклика. Да еще завести логику по гидравлике, наличию питания. А потом с этим всем попытаться взлететь
У меня по ощущениям на отладку скриптов уходит чуть ли не в два раза больше времени чем написание 
Ну это уже выходит за рамки использования override. Потому что XPlane с гидравликой тоже не сильно помогает.
Хе-хе, таки небольшой апдейт сего велосипеда, если вдруг кому-то еще интересно
прибил (гвоздями) ‘importer’ от gjs, так что теперь можно кошерненько импортировать другие скрипты конструкцией типа:
Подробнее:
https://github.com/i…es/advanced-fbw
Правда сам fbw кривой и не работает.
importer после моих надругательств неплохо бы таки привести еще в порядок.
Наверное, следующее, что я буду прикручивать, будет возможность рисовать (opengl и текстурки).
Сообщение отредактировано inv: 21 February 2016 — 17:16
прилепил возможность самому задавать свои колбэки, с возможностью указывать интервал времени между вызовами (как в XPlane SDK), т.к. далеко не всегда надо вызывать колбэки на каждом цикле обработки флайт модели.
update = function(elapsedSinceLastCall, elapsedSinceLastFlightLoop, counter) { fcc.update(elapsedSinceLastCall); return 0.066; } const updId = regFLCallback(update, 0.066);флайт модели или на каждом кадре?
Сообщение отредактировано skyteacher: 01 March 2016 — 08:10
В самом начале написано, что именно речь о флайт моделе.
Хотя в паре мест в доке используется слово cycle и тут же рядом frame как синоним.
http://www.xsquawkbo…:XPLMProcessing
И да, привет sasl’у. Они даже рисуют некоторые вещи на каждом цикле флайт модели
Сообщение отредактировано inv: 01 March 2016 — 16:32
И да, еще пример колбэка, в стиле «ООП»
)
FlightLoop = function(freq) { var freq = freq; var T = 1/freq; var prevtSinceFl = 0; this.update = function(dtLastCall, tSinceFl, counter) { dt = tSinceFl - prevtSinceFl; fcc.update(dt); prevtSinceFl = tSinceFl; return T; } var updId = regFLCallback(this.update, T); // register callback, which is called approx. only 15 times per second } var fl = new FlightLoop(15);К сожалению XPlane не hard realtime система и время до вызова следующего колбэка — это не дэдлайн, а наоборот
А жаль.
Сообщение отредактировано inv: 01 March 2016 — 17:13
Вот тут как раз радоваться надо, что не. По многим причинам
Ну ок, перефразирую. Хотелось бы таки API, которое бы гарантировало вызов моего колбэка в неком интервале времени
Разве что самому костылять, увеличивая частоту вызовов.
А вообще не вижу проблемы, если риалтайм относительно времени внутри симулятора, XPlane и так время любит тормозить, если не укладывается.
Сообщение отредактировано inv: 01 March 2016 — 18:24
Ну, можно к таймеру прицепиться. Но череповато разбеганием галактик
Дык, вот он сообразно этому рИалу и работает. Не стреляйте в пианиста©
Кстати, тогда у меня тут вопрос возникает попутно. Какое время я получаю в параметрах sinceLastCall и sinceLastFlightLoop?
Это время внутри симулятора или вне симулятора?
Сообщение отредактировано inv: 01 March 2016 — 18:56
По логике — модельное. В противном случае невозможна реализация внешних автопилотов, флаев-по-верёвкам и прочих артификал стабильностей. Другое дело, что это время в нормальных условиях отличается от реального чисто символически
Ну, хотелось бы, чтобы всё кошерненько было и не лопатить при этом апдейты на каждом цикле обработки флайт модели.
При требуемых 0.0667 оно мне выдает вот такое чудо.
Действия: старт сима. переключение вида, переключение окна, зум, манипуляции с джойстиком.
Есть подозрение, что автопилот при таком разбросе будет не всегда адекватно себя вести.
Сообщение отредактировано inv: 01 March 2016 — 23:30
Так вот тут-то и проблема. Это время плавает (и я бы не сказал, что символически)… Грубо говоря на примере выше (обновления 15 раз в секунду). Вид из кабины — 0.076с, переключил на внешний — 0.066с, т.е. 15%, что мягко говоря, дофига. Потому есть все основания предполагать, что это таки не модельное время.
upd: Таки да. То, что я получаю/задаю в колбэках — это реальное время.
http://www.xsquawkbo…/Simulated_Time
Так что вот я и говорю — проблема в том, что я не могу привязать колбэк к времени в симуляторе. И не могу потребовать (и получить гарантию) его выполнения каждые t секунд модельного времени.
Сообщение отредактировано inv: 01 March 2016 — 21:44
Что, в принципе, не сильно портит картину при наличии sim/time/sim_speed
(слегка поразмыслив) А так ли уж оно надо? Если sim_speed≈1, то особой проблемы нет. КМК писатели плагинов не сильно заморачиваются отклонениями от такого состояния
Живописьненько…
Не исключено. Хотя… инерция немного спасёт.