Исходник Софт конвертер moon 025 >> 026

[asdzxcjqwe]

тестирую конвертер скомпилированных LuaJIT скриптов из 2.0 в 2.1 и пока что вроде справляется хорошо, но мне нужно проверить больше скриптов на совместимость. возможно кто-то хотел перевести какой-то скрипт на lj 2.1, так вот теперь вы можете это сделать и более того помочь мне пофиксить ошибки, если они появятся. если скрипт-результат крашится на муне 026 или есть другие ошибки, то пожалуйста сообщите об этом мне (+ссылку на тему/сайт скрипта и лог)

web версия: https://luajit.ru/conv

upd: добавил lua версию
использование: поставить мун 026, кинуть луа файл в папку moonloader, после чего можно кидать 025 скрипты в папку moonloader, они будут конвертированы автоматически при входе в игру
осторожно, заменяет старые 2.0 скрипты в папке moonloader на новые конвертированные в 2.1

 

[Azller Lollison]

пиздец а мы в конфе там такие костыли с дллкой обсуждали ору

 

[asdzxcjqwe]

пиздец а мы в конфе там такие костыли с дллкой обсуждали ору

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

как я говорил, скрипты лужи 2.0 спокойно работают на муне 0.26 (но с lua51.dll версии 2.0), можно было бы сделать проверку на версию в самом moonloader.asi и в папке держать две длл-ки
или нет, мне похуй

 

[Azller Lollison]

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

как я говорил, скрипты лужи 2.0 спокойно работают на муне 0.26 (но с lua51.dll версии 2.0), можно было бы сделать проверку на версию в самом moonloader.asi и в папке держать две длл-ки
или нет, мне похуй

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

 

[asdzxcjqwe]

иногда некоторые проблемы с совместимостью есть

fix

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

возможно, но думаю пофиг с этим, есть идея сделать луа скрипт, который будет сканировать папку мунлодера и портировать 2.0 скрипты в 2.1

 

[FYP]

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

в luajit 2.1-beta3 добавили полную совместимость исключений, без которой полноценная обработка ошибок была невозможной. в .025 и ниже для уместной обработки ошибок мне пришлось нагородить немало костылей, а часть ошибок обработать вообще было нельзя.
перед релизом я думал о реализации совместимости каким-нибудь способом, но скриптов тогда было не так уж и много и я понадеялся, что авторы без проблем перекомпилируют их под новую версию и все забудут про .025, только вместо этого разработчики скриптов стали компилировать под обе версии по просьбам пользователей, из-за чего .025 до сих пор актуальна.
конвертер - это как раз то, что нужно в сложившейся ситуации. автоматическое преобразование на самом деле не так уж необходимо, надо лишь обеспечить единичный переход на .026. а если байткод сменится опять, я прикручу обратную совместимость, учтя прошлую ошибку.

довести конвертер до идеала можно таким путём: берёшь много исходников, компилируешь их через lj 2.0, компилируешь их через lj 2.1, конвертируешь первые и делаешь бинарное сравнение со вторыми - будут видны все артефакты конвертации и их можно будет устранить.

 

[asdzxcjqwe]

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

уверен, из-за того, что есть немало скомпилированных скриптов под lj 2.0, авторы которых испарились и перевести на 2.1 уже некому, а играть без них не хочется / неудобно
по крайней мере я видел пару тем здесь с просьбой о переводе луаков на 2.1

довести конвертер до идеала можно таким путём: берёшь много исходников, компилируешь их через lj 2.0, компилируешь их через lj 2.1, конвертируешь первые и делаешь бинарное сравнение со вторыми - будут видны все артефакты конвертации и их можно будет устранить.

логично, так и делал
сначала я сравнивал v2.0 и v2.1 по исходнику lj_bc.h, и как я понял, кроме новых четырех опкодов в байткоде ничего не изменилось (возможно?)
поэтому я тупо смещаю байты: ins > 60 : ins + 4, ins > 56 : ins + 3, ins > 15 : ins + 2 (где ins это номер опкода)
через luajit -blg пробовал сравнить байткод 2.0 и преобразованный 2.1 нескольких скриптов, включая некоторые большие как mvd helper - никаких отличий между опкодами, думаю конвертер готов к работе
во всяком случае проверю еще больше скриптов, чтобы убедиться точно

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

это верно, но на мой взгляд для обычных пользователей лежащий файлик конвертера в папке moonloader это как-то проще и удобнее что ли? не знаю даже, но как я успел заметить, не все понимают, что за ошибка can't load incompatible bytecode в логе (это уже тупость пользователей, авторы обычно указывают версию муна для своих скриптов)
скрипт и так бы переводил все luac файлы в папке с концом (одноразово) и завершал свою работу (переписать на луа за 20 минут можно)

 

[FYP]

в алгоритмах чтения/записи байткода (lj_bcread.c, lj_bcwrite.c) тоже были изменения, но не знаю, повлияли ли они на байткод.

это верно, но на мой взгляд для обычных пользователей лежащий файлик конвертера в папке moonloader это как-то проще и удобнее что ли? не знаю даже, но как я успел заметить, не все понимают, что за ошибка can't load incompatible bytecode в логе (это уже тупость пользователей, авторы обычно указывают версию муна для своих скриптов)
скрипт и так бы переводил все luac файлы в папке с концом (одноразово) и завершал свою работу (переписать на луа за 20 минут можно)

го. уж точно не помешает.

 

[hnnssy]

а я думал кроме меня никто на бх ничего полезного не делает, красава

 

[asdzxcjqwe]

в алгоритмах чтения/записи байткода (lj_bcread.c, lj_bcwrite.c) тоже были изменения, но не знаю, повлияли ли они на байткод.

повлияли ровно так же, как описано в lj_bc.h, в остальном не должны были, иначе лужа крашилась бы вместе с игрой

го. уж точно не помешает.

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

upd 2: тупанул наверное, подгружая скрипт в таблицу до проверки на версию. исправил

осторожно: заменяет конвертированные скрипты

 

[FYP]

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

в луа строки константны, так что вариант с таблицами оптимален, если не прибегать к использованию ffi. только в некоторых местах лучше применить table.concat для преобразования таблицы в строку.

 

[™ ChipFamily]

upd: добавил lua версию, потестите тоже плз кому интересно и не лень

Потестил, и по конвертировал полностью всё скрипты 0.25 из разделов "Читы/Модификации", во время выполнение конвертации скриптов не было ни одной ошибки/краша, всё работает как нужно.
Не в падлу? вообще нет.

 

[asdzxcjqwe]

Потестил, и поконвертировал полностью все скрипты 0.25 из разделов "Читы/Модификации", во время выполнения конвертации скриптов не было ни одной ошибки/краша, всё работает как нужно.
Не в падлу? вообще нет.

это же сто страниц спасибо, значит теперь можно оформлять тему нормально // upd: хотя не, не оч идея была делать это на луа, надо пилить asi или sf плагин, чтобы можно было хукать load и loadstring, но при этом не снижать скорость работы. И нужно хукать их на уровень выше, чтобы антихуки и антиджойны не реагировали. Не хотелось подключать ffi или другие библиотеки к луа скрипту, чтобы не делать его зависимым, т.е. чтобы работало у самого нуба из нубов, но видимо придется (либо плагин пилить)

в луа строки константны, так что вариант с таблицами оптимален, если не прибегать к использованию ffi. только в некоторых местах лучше применить table.concat для преобразования таблицы в строку.

concat и unpack с 800к+ байтами не проходит, а извлечение через for приводит к зависанию. как раз есть скрипты весом более 800 кб
ну да ладно, for+fwrite работает быстро, думаю это самый подходящий вариант здесь без ffi

upd: забыл, что скомпилированные 2.0 чанки через load и loadstring грузиться не будут.

 

[Kuharz]

Ляяяяяяя, вот это годнотища, просто лучший.

Что касается багов, заметил 1 баг при переводе Little Hud v5.0 с 0.25 на 0.26, при использовании стиля Hyper, Classic, Short (стили худа) к количеству денег дописывается позиция худа по оси X (скрины ниже будут).

При использовании стиля Short полоска с хп (если хп больше 100) чуток сдвинута.

Получится фиксануть проблему из сообщения выше?)

 

[asdzxcjqwe]

Получится фиксануть проблему из сообщения выше?)

не знаю, гляну чуть позже как появится время

Что касается багов, заметил 1 баг при переводе Little Hud v5.0 с 0.25 на 0.26, при использовании стиля Hyper, Classic, Short (стили худа) к количеству денег дописывается позиция худа по оси X (скрины ниже будут).

дело не в конвертере, код на разных версиях работает по-разному
(уверен если автор запустит исходник на lj 2.1, то получит тот же эффект)

я сделал листинг байткода скриптов 2.0 и 2.1 версий и получил два полностью идентичных файла,
также декомпилировал их разными декомп-ами, получил одинаковый код, т.е. конвертер нигде не промахнулся

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

При использовании стиля Short полоска с хп (если хп больше 100) чуток сдвинута.

вот тут у меня все ок, проблему воспроизвести не удалось, в чем прикол тоже не знаю