Wake of Gods Forum | Форум Во Имя Богов - Плагин: воспроизведение видео в формате BIK (2022)

Pages: 1 2 3 4 5

(19.09.2022 15:37)myoffice91 Wrote: [ -> ]1)Обновлён Binkw32a.dll с 1.8g (15.12.2005 год) до 1.8x (7.09.2016 год)

На этой версии стало наооборот: звук работает, а картинка не воспроизводится - показывает чёрный экран.

(19.09.2022 16:10)XEPOMAHT Wrote: [ -> ]
(19.09.2022 15:37)myoffice91 Wrote: [ -> ]1)Обновлён Binkw32a.dll с 1.8g (15.12.2005 год) до 1.8x (7.09.2016 год)

На этой версии стало наооборот: звук работает, а картинка не воспроизводится - показывает чёрный экран.

Забыл, что binkw32a.dll версия 1.9а. Сейчас сделал перезалито архив https://disk.yandex.ru/d/42QE3o1bGY6SpA . Спасибо!

XEPOMAHT, можно удалить binkw32a.dll, переименование binkw32a++++.dll на binkw32a.dll из "Heroes III ERA\Mods\Video playback in BIK format"

(19.09.2022 16:26)myoffice91 Wrote: [ -> ]Забыл, что binkw32a.dll версия 1.9а. Сейчас сделал перезалито архив https://disk.yandex.ru/d/42QE3o1bGY6SpA . Спасибо!

Из этого архива опять не работает звук, проигрывается только картинка. Более старая версия Binkw32a.dll (1.6b) воспроизводит и видео, и звук.

Hi myoffice91, thanks for the updates.

I wonder if it is still possible to resovle the issue of Tavern Videos I reported about the compatibility OpenGL. It looks like the same issue is still there with the latest TavvidVideosBIKv4_O_HD (1 May 2022).

Spoiler (Click to View)

(02.10.2022 07:32)Archer30 Wrote: [ -> ]Hi myoffice91, thanks for the updates.

I wonder if it is still possible to resovle the issue of Tavern Videos I reported about the compatibility OpenGL. It looks like the same issue is still there with the latest TavvidVideosBIKv4_O_HD (1 May 2022).

Spoiler (Click to View)

Здравствуй!

Тоже такой "GDI+" видеорежим.

Интересно, почему город "Замок", "Болото", и "Сопряжение" - нет артефактов в видео, кроме в других фракциях. Думаю - надо перекодировка, либо в настройке повысить значение буфера для выделения памяти.

(23.08.2022 17:26)XEPOMAHT Wrote: [ -> ]Мод на стартовые видеоролики из ERA+ обновлён:

1. Русская озвучка теперь синхронизирована с видео. Теперь о чём баба говорит, то и показывают.
2. Качество видео от перекодирования из старого bik в новый теперь практически не изменилось. Получилось снизить на минимум влияние формата mpeg на перекодировку.

Скачать: https://vk.com/s/v1/doc/3w2yuWKsNQHMDA8c...KHpXcco6tQ

Скачал из архива...

H3X1intro.bik - альфа-версия формат BIK
H3INTRO.BIK - версия 1.05 формат BIK, но кодировка 8 бит моно звук.

(19.09.2022 17:07)XEPOMAHT Wrote: [ -> ]
(19.09.2022 16:26)myoffice91 Wrote: [ -> ]Забыл, что binkw32a.dll версия 1.9а. Сейчас сделал перезалито архив https://disk.yandex.ru/d/42QE3o1bGY6SpA . Спасибо!

Из этого архива опять не работает звук, проигрывается только картинка. Более старая версия Binkw32a.dll (1.6b) воспроизводит и видео, и звук.

Посмотрел Windows 7 с binkw32a.dll (1.8x) действительно H3INTRO.BIK без звука из-за 8 бит\моно звук, а если bik -> avi, затем avi -> bik (16 бит\стрео звук), теперь воспроизводит.

Значит 1.8x - WaveOut не поддерживает звук 8 бит. В Miles тоже проблема - дребезжание звука.

---
Искал версию 1.8d, на сайте нет, кроме как в скаченной игре выпущенного 2005 году. Скачал игру, затем распаковал архив, нашел библиотеку 1.8d и скопировал себе. Удалил архив и игру.

Тестировал с 1.8d (06-24-2005) - ура! H3INTRO.BIK есть звук.
Попробовал поставить старую версию плагина "Воспроизведение видео в формате BIK" с 1.4 на 1.3 (с WaveOut, на Miles).
Теперь видео таверна работает хорошо.

Однако, процедура не найдено "_AIL_set_sample_volume_pan@12" из MSS32.DLL, ничего страшного нет =).

---
binkw32 с версией 1.8d, а выше чем 1.8d - не поддерживает старую версию библиотеки MSS32.dll - см.ниже

Начиная с 1.8e (09-14-2005) изменение:
Added support for Miles 7 on Windows (you can now do 5.1 on Windows)! The Miles example shows how to do 5.1 with just a few code changes.

-----------------------------------

Spoiler (Click to View)

-------------------------------------------

Скачать плагин "Воспроизведение видео в формате BIK" 1.5 + программу RADVideo 1.8x : https://disk.yandex.ru/d/upaGK_CNqiLPtQ

ИСТОРИЯ ИЗМЕНЕНИЙ ВЕРСИЙ

1)Заменена Binkw32a.dll с 1.8x (7.09.2016 год) до 1.8d (06-24-2005)
2)Заменена WaveOut на Miles. Можете обратно поменять WaveOut, только через heroes3.ini, секция Settings, ключ BinkSoundType=1
3)Добавлена поддержка "LOOP" для смены видео.

Например видео: первый TVCC.BIK
Для смены видео, нужно писать TVCC_LOOP.BIK

https://youtu.be/_UIaytS8KI4

4)Исправлен баг: в моде "ERA+" в таверне видео формата SMK при клике на портрет было моргание видео.

https://disk.yandex.ru/d/upaGK_CNqiLPtQ

myoffice91, спасибо за обновление. Плагин очень полезный!
Даже в оригинале Complete многие ролики в bik присутствуют в ресурсах игры, но не воспроизводятся - вместо них используются менее качественные smk.
Этот плагин полностью решает проблему, да еще и позволяет собственные bik делать.

Спасибо за обновление. У меня всё работает.

(06.10.2022 11:30)myoffice91 Wrote: [ -> ]H3X1intro.bik - альфа-версия формат BIK
H3INTRO.BIK - версия 1.05 формат BIK, но кодировка 8 бит моно звук.

В H3X1intro.bik отсутствует языковая озвучка, поэтому он оставлен без изменений. Для H3INTRO.BIK русская озвучка взята из SMK, где 8-битный моно-звук. Делать 16-битное стерео смысла нет, т.к. качество при этом не изменится, а размер звуковой дорожки станет заметно больше.

Плагин вылетает на последней Эре (буквально стало на 3.9.15), но причину с ходу не вижу.
Последняя dll Эры:
https://dropmefiles.com/wMjRO

(25.07.2024 11:46)XEPOMAHT Wrote: [ -> ]Вчерашняя версия era.dll 3.9.15 портит (или не даёт записывать) структуру видеоролика по адресу 694D00h из-за чего становится невозможно воспроизведение вступительных роликов перед главным меню (т.к. исходных кодов от плагина Video playback in BIK format.dll у меня нет, чтобы исправить конфликт хуков с era.dll). В общем опять ERA+ остётся на era.dll версии 3.9.14.

Причина: автор ЭРА решил оптимизировать хук в экзешнике, а плагин BIK не сталкивался с разновидностью ассемблера из era.dll и не переписывает закрытый вызов API из era.dll =). А в версиях 3.9.14 и 3.9.15 в процедуре Hook_OpenBik - без изменений в ассемблере, кроме в 3.0.

Было:

Code:

Core.Hook(Ptr($44D270), Core.HOOKTYPE_BRIDGE, @Hook_OpenBik);

https://github.com/ethernidee/b2/blob/7c...e.pas#L440

Стало: ЭРА начиная с версий 3.9.15 (24.07.2024)

Code:

ApiJack.HookCode(Ptr($44D270), @Hook_OpenBik);

https://github.com/ethernidee/b2/blob/ma...k.pas#L347

В ассемблере:

Code:

05D03FF8   | 60                     | pushad          

05D03FF9   | 54                     | push esp      

05D03FFA   | B8 98B81505            | mov eax,era.515B898       

05D03FFF   | FFD0                   | call eax        

05D04001   | 85C0                   | test eax,eax                  

05D04003   | 74 10                  | je 5D04015   

05D04005   | 61                     | popad                     

05D04006   | 83C4 04                | add esp,4        

05D04009   | 55                     | push ebp             

05D0400A   | 8BEC                   | mov ebp,esp       

05D0400C   | 83EC 28                | sub esp,28           

05D0400F   | 68 75D24400            | push h3era hd.44D275      

05D04014   | C3                     | ret          

05D04015   | 61                     | popad  

05D04016   | C3                     | ret

Новая версия ЭРА 3.9.15

Code:

05933CB0   | 60                   | pushad              

05933CB1   | 54                   | push esp                                    

05933CB2   | E8 69BC31FF          | call era.4C4F920           

05933CB7   | 85C0                 | test eax,eax                            

05933CB9   | 0F84 0F000000        | je 5933CCE                   

05933CBF   | 61                   | popad                                

05933CC0   | 83C4 04              | add esp,4                              

05933CC3   | 55                   | push ebp                               

05933CC4   | 8BEC                 | mov ebp,esp                  

05933CC6   | 83EC 28              | sub esp,28                        

05933CC9   | E9 A895B1FA          | jmp h3era hd.44D276               

05933CCE   | 61                   | popad                

05933CCF   | C3                   | ret

В будущем, вдруг кто-то захочет улучшить оптимизацию хука назовёт ApiJack.HookCodeNoReturnResult
push ecx
push esp
call era.4C4F920
pop ecx
push ebp
mov ebp,esp
sub esp,28
jmp 44D275

А затем захочет убрать лишние push esp.
push ecx
call 0x04C4F920
pop ecx
push ebp
mov ebp,esp
sub esp,28
jmp h3era hd.44D276

В плагине BIK 1.6.2 уже добавил совместимость см.выше, предусмотрено на будущее, на всякий случай =).

Скачать плагин "Воспроизведение видео в формате BIK" 1.6.2 :

ИСТОРИЯ ИЗМЕНЕНИЙ ВЕРСИЙ

Версия 1.6.2
7.08.2024
1)Исправлен мой баг: не воспроизводить видео формата ".smk", типа: кампания, конец игры... (причина: в плагине BIK начиная с 1.6 оптимизирована строка ".smk" в ассемблере. Поэтому ЭРА видит чужеродный адрес в строке из плагина xD!.)
2)Изменение исходных кодов в ассемблере: сохранить файл ANSI на UTF8.
Импорт процедуры с заменой MessageBoxA на MessageBoxW.
3)Добавлена совместимость, на всякий случай, если кто в будущем будет оптимизировать хук в экзешнике, например, появится ЭРА версии 4.Х =).

Версия 1.6
07.08.2024

1)Добавлена поддержка Эры начиная с версии 3.9.15.

Причина несовместимости:
У ЭРЫ в новой версии оптимизирован хук
было mov eax,era.4E7B7AC, call eax
стало call era.4C3F82C

2)Реализовал проверку в экзешнике на не совпадение байтов. Если не совпадает, то всплывается диалог "Плагин не совместим" и затем вызвает сбой!.

Нельзя писать внутрь моста/переходника хука. Для установки перехвата можно использовать HiHook патчера patcher_x86.dll или API из Эры:

function Splice (OrigFunc, HandlerFunc: pointer; CallingConv: integer; NumArgs: integer; {n} CustomParam: pinteger; {n} AppliedPatch: ppointer): pointer; stdcall;

Original function address (OpenBik first command address)
Your handler address
Calling convention of OpenBik function:

// Left-to-right
    CONV_PASCAL = CONV_LAST,

    // Left-to-right, first three arguments in EAX, EDX, ECX
    CONV_REGISTER = -102,

    // Right-to-left, caller clean-up
    CONV_CDECL = -103,

    // Right-to-left
    CONV_STDCALL = -104,

    // Right-to-left, first argument in ECX
    CONV_THISCALL = -105,

    // Right-to-left, first two arguments in ECX, EDX
    CONV_FASTCALL = -106,

Number of original function arguments, including those in registers
Two NULL arguments

Your handler must have STDCALL convention and accept void* OrigFunc argument + all other arguments in the same way, as original function would accept

(08.08.2024 00:31)Berserker Wrote: [ -> ]Нельзя писать внутрь моста/переходника хука.

Тифон 3 в таком случае не лезет в код era.dll, а, или ставит собственный ассемлерный переходник-прокладку между кодом игры и хуком Патчера (по коду получается, что Патчер поставил хук непосредственно в код Тифона, где Тифон сам решает - выполнять чужой хук или нет, а не в СоД, правда сам Патчер об миграции собсвенных хуков естественно ничего не знает, как и не узнает era.dll, библиотеки HD-мода и плагины Игрика, с которыми требуется совместимость, а у Бараторча Тифон вообще "ворует" хуки, заставляя выполять полезные функции HD-мода прямо из Тифона, увы по-другому никак 105

), или целиком подменяет хуки, если они мешают работе кода ERA+, или полностью восстанавливает затёртый код бинарным патчем, благо в Патчере проверок на установленные хуки нет, или перехватывает критические для Тифона функции игры целиком, не позволяя в них вмешиваться сторонним dll. Но весь этот вандализм оправдан только для глобального моддинга (по-другому на платформе ЭРА увы никак), т.к. глобальный мод не может быть частью "конструктора" модов из-за правок всего и вся в игре. Уход на чистый SoD - очевидное решение проблемы совместимости, на ERA делают глобальники только психопаты.

(08.08.2024 00:31)Berserker Wrote: [ -> ]Для установки перехвата можно использовать HiHook патчера patcher_x86.dll или API из Эры

А оно под Ассемблер есть? Скорее всего готового исходного кода "из коробки", позволяющего использовать функционал patcher_x86.dll без костылей, нет и не будет - Бараторчу на это глубоко наплевать абсолютно (тема подмалась ещё во времена, когда Патчер только-только появился, так до сих в этом направлении пор глухо несмотря на то, что кто-то ещё пилит плагины на Ассемблере). Например, Тифон, чтобы просто сигнализировать Патчеру о своих хуках, использует диассемблированный кусок СИ-шного кода, в котором ничерта не понятно, оно просто как-то работает с неизвестными индексами/префиксами, подающимися на функции Патчера, что иногда сводит Патчер с ума, да и саму era.dll иногда тоже, из-за чего код era.dll может нопить в 2 раза больше кода (в итоге, приходится переносить в Тифон в 2 раза больше затёртого Эрой кода 148

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

XEPOMAHT, всё это чёрная магия к костылями )
Хуки делятся на 2 типа: call команда прямо в месте установки или jmp в начале функции.
Вторая — это высокоуровневая замена всей оригинальной функции.

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

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

Ассемблер здесь не помеха. Я скоро выпущу 3.9.16 с изменённым исправленным HookCode. Тебе двух функций HookCode/Splice хватило бы почти на все нужды, при том, что они умеют строить мосты и выполнять затёртый код. У меня такое ощущение, что автор плагина не знал, как это сделать корректно и потому влез внутрь поста splice-перехвата Эры. А нужно было всего-то установить другой Splice перехват поверх оригинального. В этом и высокоуровневость, что одну и ту же функцию, можно перехватить несчётное количество раз.

В общем, не стесняйтесь детально спрашивать, ибо костыли потом аукаются всем )

(08.08.2024 14:32)Berserker Wrote: [ -> ]всё это чёрная магия к костылями )

Да, увы. Приходится изгаляться, т.к. исходных кодов самой игры у моддеров нет.

(08.08.2024 14:32)Berserker Wrote: [ -> ]Хуки делятся на 2 типа: call команда прямо в месте установки или jmp в начале функции.

Да больше их, минимум раза в 2. Тифон может ставить хуки на любое место, где происходит переход:

1. Вызов функции
2. Длинный прыжок
3. Длинный прыжок с условиями (после проверок чего-либо) - только в Патчере-форке, который так и не выложили, т.к. пилили уже участники HotA Crew под себя, естественно в era.dll этого нет
4. Хук непосредственно на таблицу с адресами кейсов - подмена как конкретного адреса на функцию, так и всего кейса целиком - Бараторч не стал переносить это в Патчер, а выполняет средствами самого HD-мода. В era.dll такое извращение вряд ли появится, поэтому Тифон производит подобные хуки самостоятельно.

(08.08.2024 14:32)Berserker Wrote: [ -> ]Вторая — это высокоуровневая замена всей оригинальной функции.

Это как раз и ломает совместимость. Бараторч уж очень любит переносить функции целиком, в итоге - костыли, костыли и ещё раз костыли, чтобы Тифон мог поменять что-либо в перенесённых HD-модом функциях игры. Под ЭРУ такой вид перехвата кода - очевидное зло.

(08.08.2024 14:32)Berserker Wrote: [ -> ]Обработчики перехватов соответственно тоже бывают двух типов: первые получают указатель на контекст (регистры, адрес возврата на момент вызова хука) и возвращают флаг того, нужно ли выполнить затёртый код. Второй тип обработчиков — это новая реализация функции. У них stdcall соглашение и все те же аргументы, что и у оригинальной функции, но первый аргумент — адрес моста к оригинальной функции, то есть как бы адрес оригинальной функции, который можно использовать для её вызова.

В Тифоне каждый хук подгоняется вручную под конкретное место. То, что делает Патчер после хука, не контролируется моддером, я же привык знать то, превратится код в тыкву после установки хука или нет. Тем более Тифон должен иметь доступ ко всем данным в самом хуке - к стеку и регистрам БЕЗ каких-либо переходников, чтобы код в самом хуке выглядел бы 1 в 1 так же как если бы он находился в коде игры без хука.

(08.08.2024 14:32)Berserker Wrote: [ -> ]Тебе двух функций HookCode/Splice хватило бы почти на все нужды, при том, что они умеют строить мосты и выполнять затёртый код.

Вообще не хватит. Тифон иногда вообще выкидывает затёртый код, подменяя фрагметы содовского кода. Да что там. Есть содовские функции, у которых Тифон полностью убирает начало, есть функции, у которых Тифон деляет из 1 начала несколько разных начал (совпадают только концовки) и весь этот бепредел творится в содовском коде только ради того, чтобы не переписывать портянки ассемблерного кода. В коде Тифона тонна низкоуровневых извращений. А переписывать с 0 более 500 тифоновских хуков я точно не буду.

А самое главное - СКОРОСТЬ хуков Патчера. Хуки Тифона выполняются напрямую без посредников, ставятся максимально быстро, содержат в себе готовый затёртый код без необходимости его генерировать при каждом запуске игры и нопить код после хука (Тифон оставляет там нечитабельную кашу, т.к. этот мусор никогда не исполняется). Особенно критично в работе геройского ИИ, который на XXXL-картах сам по себе жутко тормозной. Те же участники HotA Crew делали форк Патчера для внутреннего использования с реализацией ускоренных хуков, но в свет эта инициатива так не вышла - Патчер как был медленным, так медленным и остаётся, особенно на моём старом ПК, где всё это очень заметно, несмотря на низкие системные требования оригинальной игры (имено поэтому Тифон подменяет/убирает кучу тормозящих игру воговских и эровских хуков во время игрового сражения на поле боя, чтобы не было 1-5 секундных задержек во время действий отрядов, т.к. комфорт от игрового процесса для меня важнее, чем сторонний функционал, который всё равно в ERA+ никак не используется - часть ERM-триггеров принесены в жертву ради производительности в ERA+, увы).

(08.08.2024 14:32)Berserker Wrote: [ -> ]У меня такое ощущение, что автор плагина не знал, как это сделать корректно и потому влез внутрь поста splice-перехвата Эры. А нужно было всего-то установить другой Splice перехват поверх оригинального. В этом и высокоуровневость, что одну и ту же функцию, можно перехватить несчётное количество раз.

Да, Тифон никогда не лезет в чужие splice-перехваты, т.к. это небезопасно - любое обновление может испортить код. Тифон действует по-разному, в зависимости от места splice-перехвата, часто Тифон просто выполяет свой код на 1 шаг в коде раньше или позже, чем запускается splice-перехват Патчера. Особенно печально бывает, когда кто-то перехватывает сразу первый байт функции, а сама функция вызывается плагинами - тут уже приходится применять костыли, включая перенос кода из самих плагинов непосредственно в Тифон, чтобы он исполнялся вместе с Тифоном, т.к. ассемлерного доступа к Патчеру на базе Тифона увы нет.

(08.08.2024 14:32)Berserker Wrote: [ -> ]ибо костыли потом аукаются всем )

Да, конфликтые участки кода между разными dll часто решаются в одностороннем порядке. Т.к. ждать обновлений со стороны других авторов dll - слишком долго. Люди могут месяцами не выходить на связь, тот же Игрик, например, давно не появляется - его плагины в случае чего обновить будет некому.

Ох, Херомант, долго тебе писать. По моему мнению, не прав ты по всем пунктам. И скорость тоже меряешь явно на глаз. Хуки здесь не при чём, даже в ИИ коде. Скажу проще, лапшу из асм кода никто никогда править не будет. А хук из ЕРМ/Lua/плагинов поправить — пара байт или одна строка кода. По скорости быстрее Эровских хуков ничего не придумаешь. Глобальных переменных не использует, мосты лаконичные, адреса статичные (для предсказания переходов и спекулятивного выполнения).

Если кто-то перехватил функцию и переписал её код, есть два варианта:
1) Сделать свой перехват и полный свой функционал.
2) Сделать свой перехват, выполнить доп. команды и вызвать перехваченную функцию, возможно с другими аргументами (а та может вызвать до этого перехваченную и т.д).

Оба подхода работают без проблем.

Если нужна замена части функционала, то call-перехвата почти всегда хватает. Если он умный, сам определяет размер перезаписанных данных, сам создаёт мост и бережно клонирует затёртые команды с их изменением (адреса, типы прыжков). Ну, таблицу switch-case пропатчить можно, конечно, но это обычный патч на запись N байт адреса.

P.S. Некоторые люди сталкивались с микроподлагиваниями в бою, но пока так и не нашли причину. Думаю, если она и есть, то в одном конкретном месте.

(08.08.2024 17:55)Berserker Wrote: [ -> ]По моему мнению, не прав ты по всем пунктам.

Естественно, мои методы установки хуков в корне не верны по отношению к высокоуровневым языкам. На СИ и Дельфи извращались по-всякому до появления Патчера, включая сам WoG и HoA (оба мода в конце концов стали использовать Патчер, уйдя от самопальщины). Но куда деваться авторам плагинов, написаных на Ассемблере, хоть их можно пересчитать по пальцам одной ноги, но всё же они (пока ещё) есть, включая глобальный ERA+. В SDK ЭРЫ вроде бы есть готовый пример ассемблерного плагина на FASM, но... никаких готовых решений для использования эровской системы хуков в нём нет, так же как использование эровских инклюдов. Единственное, что у меня получилось получить "легальным" путём без костылей - адрес строки на GetVersion из era.dll, всё остальное, что ни пробовал - или просто не работает, или приводит к ошибкам. Та же эпопея с указанием ЭРЕ перемещённых данных через RedirectMemoryBlock обернулась полным провалом и потере времени, в итоге era.dll по-прежнему где-то может читать молоко вместе с ERA+. В общем, это мои личные проблемы по поводу того, что я совершенно не программист и не умею писать высокоуровевый код.

(08.08.2024 17:55)Berserker Wrote: [ -> ]Скажу проще, лапшу из асм кода никто никогда править не будет. А хук из ЕРМ/Lua/плагинов поправить — пара байт или одна строка кода.

Да, я тоже не хочу переписывать ассемлерный код в высокоуровневый вид. Там всё организовано по принципу: работает - не тройгай. Можно сравить с безконечной правкой багов и ошибок в Аметисте и Эмеральде, волынка с которыми тянется уже с 2013 года, если скляроз не изменяет несмотря на то, что Маячок - программист с большим опытом. В Тифоне такой херни нет. Возможно в будущем в ERA+ появятся lua, где все хуки будут организованы как надо, а Тифон больше изменяться не будет, но в данный момент под lua в ERA ничего нет. А ЕРМ по-прежнему не подходит для поддержки глобального модостроения, т.к. возможности этого языка ограничены его узкой специализацией под картоделов и читеров. Комляция кода на СИ по-прежнему не доступна для меня, т.к. я не понимаю сам СИ-шный код, как и исходные коды от ЭРЫ я на 90% не понимаю. Не программист я. Была надежда на lua, но пока что воз и ныне там...

Pages: 1 2 3 4 5