Исходник [1.4.5] moonly / MoonLoader project manager

[Musaigen]

При сборке проекта можно вышить в него библиотеки, другие ресурсы. При первом запуске скрипта библиотеки и ресурсы распаковываются в moonloader. Если ты уже используешь при разработке новой версии скрипта новую обновлённую библиотеку, или новую папку с ресурсами (шрифты, картинки и т.п) то обновленный скрипт будет использовать старые ресурсы и старые баблиотеки, потому что скрипт при каждом запуске проверяет файлы и смотрит, существует ли такой файл, или такой ресурс, и если существует - он его использует, если нет - распаковывает.

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

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

добавлю в чек-лист для реализации

 

[Musaigen]

Preview обновление CLI V3.0.0! Скачать: клик
PR от @DZONE:
0. Исправлена компиляция с g++ (GCC) 15.2.1 20260103
0.1. Исправлена проблема с бандлингом текстовых файлов: если тот содержал ]], это могло сломать выполнение сгенерированного Lua кода. Подробнее: клик

1. Переход на glob паттерны.
2. Бандлер был переделан под Base64 стандарт кодирования. Новый алгоритм в 3 раза эффективнее по весу, как пример: бандлинг с cimguidx9.dll раньше выдавал файл размером ~3.58мБ, теперь всего ~750-800КБ. Также значительное ускорение по скорости распаковки, особенно заметный на слабых машинах. Тот же cimguidx9.dll: буквально от секунд 10 и выше, до пару десятков миллисекунд. (цифры не сильно точные)
3. Исправлена работа с null-константами.

Как и написано, это preview обновление, здесь нет всего запланированного функционала и оно может содержать баги, говнокод и etc... Ниже прикрепляю простенький тест-проект, который показывает работу glob паттернов и новый алгоритм бандлинга файлов.

 

[Орк]

Тупой вопрос. То есть с помощью этого менеджера можно создать один луа, в котором будут уже встроенные библиотеки и они не будут требоваться в папке moonloader\lib? Не очень понимаю смысл этого менеджера. Это как сборка .exe в питоне (других яп)?

 

[Musaigen]

То есть с помощью этого менеджера можно создать один луа, в котором будут уже встроенные библиотеки и они не будут требоваться в папке moonloader\lib

Будут любые библиотеки, которые ты добавишь, и при этом они будут приоритетнее встроенных библиотек в moonloader/lib*

Не очень понимаю смысл этого менеджера. Это как сборка .exe в питоне (других яп)?

Если ты писал только под moonloader, то будет сложно понять.
Например, https://github.com/chaposcripts/gta-sa-plants-vs-zombies написан с помощью moonly. Благодаря moonly, chapo смог разделить функционал мода между файлами (модулями). Во время разработки запускать его как обычный MoonLoader-скрипт, а при публикации на BlastHack, воспользоваться бандлером и объединить весь мод в один файл. Без moonly у него будет несколько путей:
1. Писать весь код мода в одном файле в папке moonloader, при этом в дереве файлов твоего редактора кода будут твои Moonloader-скрипты, ресурсы (шрифты, иконки и прочее говно)
2. Писать весь код мода в папке moonloader , но разделив его на отдельные файлы (moonloader/pvz/%файлы_мода%), при этом также в дереве файлов твоего редактора кода будут твои Moonloader-скрипты, ресурсы (шрифты, иконки и прочее говно).
3. Писать весь код мода в отдельной папке, разделив его на отдельные файлы, при этом нужно будет писать утилиту, которая:
А. "Скомпилирует" все файлы в один, потом переместит его в moonloader, и только тогда уже можно тестировать мод,
Б. Просто переместит все файлы мода в папку moonloader (moonloader/pvz.lua как загрузчик, главный скрипт; moonloader/pvz-resources/%файлы_мода%)
либо вариант В. Перемещать все файлы ручками.
Я лично пользовался 1 вариантом, как и, наверное, большинство, меня это заебало и я создал moonly.

 

[Орк]

Отличная вещь, но итоговый файл у меня получается 5мб(текущее состояние) с либами mimgui, hooks, fontawesome7
Я же правильно понял на текущий момент (Preview обновление CLI V3.0.0) .Lua из библиотек не распаковываются в папку lib и используются изнутри, а dll распаковываются? Заметил это на mimgui и upmimgui.

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

добавлю в чек-лист для реализации

Было бы замечательно
Можно ещё, наверное, поступить сложно и каким либо образом запрашивать подтверждение на использование имеющейся библиотеки или подгрузить библиотеку из скрипта (например сохранить её в resource), хотя как сделать чтобы скрипт это понимал пока не знаю. Вручную это прописывать чтоль.

 

[The Spark]

Отличная вещь, но итоговый файл у меня получается 5мб(текущее состояние) с либами mimgui, hooks, fontawesome7
Я же правильно понял на текущий момент (Preview обновление CLI V3.0.0) .Lua из библиотек не распаковываются в папку lib и используются изнутри, а dll распаковываются? Заметил это на mimgui и upmimgui.

Было бы замечательно
Можно ещё, наверное, поступить сложно и каким либо образом запрашивать подтверждение на использование имеющейся библиотеки или подгрузить библиотеку из скрипта (например сохранить её в resource), хотя как сделать чтобы скрипт это понимал пока не знаю. Вручную это прописывать чтоль.

Очень просится peer dependencies для использования внешних библиотек и tree shaking для выкидывания неиспользуемого кода из тех же библиотек.
Вот только не представляю сколько нужно времени чтобы это реализовать.

 

[Musaigen]

Я же правильно понял на текущий момент (Preview обновление CLI V3.0.0) .Lua из библиотек не распаковываются в папку lib и используются изнутри, а dll распаковываются? Заметил это на mimgui и upmimgui.

Да. Любой не Lua файл будет распакован (бинарный будет закодирован через Base64, текстовые будут вставлены как есть), Lua файлы будут загружены через package.preload.

Было бы замечательно
Можно ещё, наверное, поступить сложно и каким либо образом запрашивать подтверждение на использование имеющейся библиотеки или подгрузить библиотеку из скрипта (например сохранить её в resource), хотя как сделать чтобы скрипт это понимал пока не знаю. Вручную это прописывать чтоль.

Сохранять все не Lua библиотеки в свою папку и оттуда их подгружать. В скрипте прописать пути к папке.

peer dependencies для использования внешних

Можно сделать, но не все либы в коде хранят свою версию.

tree shaking для выкидывания неиспользуемого кода из тех же библиотек.

Нужно добыть парсер Lua кода для таких манипуляций

 

[kyrtion]

Можно сделать, но не все либы в коде хранят свою версию.

Хэш суммы? SHA1 уже сделали в луа. MD5 пока не нашел.

Tags · kikito/sha1.lua

(Deprecated Repo) SHA-1 secure hash computation, and HMAC-SHA1 signature computation in Lua (5.1) - Tags · kikito/sha1.lua

github.com

проблема том что после создания файла, а подписи/сертификатов пропадает, антивирус будет детектить как особый опасный файл
тогда, архивы да распаковка?)

Было бы замечательно
Можно ещё, наверное, поступить сложно и каким либо образом запрашивать подтверждение на использование имеющейся библиотеки или подгрузить библиотеку из скрипта (например сохранить её в resource), хотя как сделать чтобы скрипт это понимал пока не знаю. Вручную это прописывать чтоль.

Ведь основные либы для разных скриптов лучше бы не трогали, для полноценной либов лучше б залезали в своей папке проекта что угодно хоть с мусором.
moonloader/YourTools/делай-что-хочешь-тут
затем в код src/init.lua:

    -- modify paths for users
    if not DEV then
        package.path = table.concat({
            string.format("%s\\lib\\?\\init.luac;", PATH_PROJECT_DIR),
            string.format("%s\\lib\\?.luac;", PATH_PROJECT_DIR),
            string.format("%s\\lib\\?\\init.lua;", PATH_PROJECT_DIR),
            string.format("%s\\lib\\?.lua;", PATH_PROJECT_DIR),
        }) .. package.path
        package.cpath = string.format("%s\\lib\\?.dll;", PATH_PROJECT_DIR) .. package.cpath
    end

    -- чтобы загружало сначала package.preload если есть, затем в папке проекта,
    -- если нету, то уже идет в moonloader/lib и тд

 

[Орк]

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

С другой стороны да, достаточно не грузить часто используемые либы(обычно уже предустановленные у пользователя), а затем уже будет достаточно сравнения версий/хэша, а уже если этого нет, то распаковка полной библиотеки в lib, а то сейчас как-то странно будет выглядеть .dll в lib, есть а остальной библиотеки нет.

@Musaigen а что будет если через CLI V3.0.0 собрать твой hook и затем уже вставить его в мой проект в lib? Вселенная не схлопнется? Просто пока нет возможности самому это протестировать :)

 

[Musaigen]

@Musaigen а что будет если через CLI V3.0.0 собрать твой hook и затем уже вставить его в мой проект в lib? Вселенная не схлопнется? Просто пока нет возможности самому это протестировать :)

Так лучше не делать, просто распакуй себе hook в lib как обычно. Бандлинг создан чтобы уже готовый проект объединить в один файл для использования в муне, а не чтобы либы бандлить для своих moonly проектов

Так лучше не делать, просто распакуй себе hook в lib как обычно. Бандлинг создан чтобы уже готовый проект объединить в один файл для использования в муне, а не чтобы либы бандлить для своих moonly проектов

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

 

[kyrtion]

Хэш суммы? SHA1 уже сделали в луа. MD5 пока не нашел.

Tags · kikito/sha1.lua

(Deprecated Repo) SHA-1 secure hash computation, and HMAC-SHA1 signature computation in Lua (5.1) - Tags · kikito/sha1.lua

github.com

проблема том что после создания файла, а подписи/сертификатов пропадает, антивирус будет детектить как особый опасный файл
тогда, архивы да распаковка?)

и правда, рабочий метод бандлер с base64, подписи и сертификаты полностью сохранились

короче, мечта сбылась. давно никто не смогли такое реализовать