Готика 2: НВ Gothic Modernized: Modern Input (Union) 1.1.1

[Хедин]

ща напишу комбинации

 

[Хедин]

L1-R3(кнопка правого джойстика) - вызов такого меню


Там можно выбрать кучу всего, включая плагин быстрого доступа. Но быстрый доступ, можно тажке вызвать на L3 (нажатие левого джойстика)
Появится окно



Там можно нажимаешь на то что написано, появится возможность добавить предметы или собрать наборы.
Пример

Видео

Использование с хотбара написано на подсказках
1 предмет "DPadLeft",
2 предмет "DPadUp",
3 предмет "DPadRight",
4 предмет "DPadDown",
5 предмет "FaceDown+DPadLeft",
6 предмет "FaceDown+DPadUp",
7 предмет "FaceDown+DPadRight",
8 предмет "FaceDown+DPadDown",

Остальные предметы из меню. По мне получилось быстро и удобно. ))

В инвентаре кстати такие комбинации
Union / Юнион - Списочный инвентарь для Готики 2 - Обновления

 

[Хедин]

Тоесть там как-то так, выбираешь область, попадаешь в свой список предметов, наживаешь добавить и он добавляется в выбранную слева ячейку

 

[иван иван]

@Хедин, спасибо за пояснения.Как сделать камеру помедленей в каких настройках какие пораметры

 

[Хедин]

@Хедин, спасибо за пояснения.Как сделать камеру помедленей в каких настройках какие пораметры

удали эти два файла, они для любителей мышек и клавиатур

 

[Dreamtrust]

А UnionAPI.dll не должна сидеть в Autorun - у Патрикса на гитхабе указано, что она должна сидеть в System, там она у меня и сидит.

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

Парни, разрешите немного подушить?) Я сейчас буду делать то, за что меня не любят на работе мои коллеги:

Разберем каким образом вся эта муть работает, чтобы выстроилось правильное понимание:

Ядро Union (Shw32.dll) распаковывает .dll из /Autorun vdf-тома на диск в Data\$Templates$\ и загружает их оттуда.
То есть, если UnionAPI.dll лежит в /Autorun vdf-тома, то Union распаковывает его в Data\$Templates$\ и
после этого UnionAPI.dll — настоящий файл на диске и/или уже загруженный модуль, так что импорт плагина разрешается.
Если в /Autorun vdf-тома его нет, а лежит он в /System vdf-тома, то Union его не распаковывает и он остаётся внутри vdf-тома, Windows на диске физически его не находит, и плагин падает с "0x00000006, Неверный дескриптор"
Но почему тогда плагин работает, если положить UnionAPI.dll в /system самой игры?
Вопрос интересный и он связан с спецификой работы Винды:
.dll загружает загрузчик Windows (LoadLibrary). VDF он не видит, для него существуют только настоящие файлы на диске. Когда загружается .dll плагина, Windows ищет её зависимость UnionAPI.dll по обычному порядку поиска:

1. Модуль с таким именем уже загружен в процесс? Тогда берётся он, по имени.
2. Папка в которой находится exe. У Gothic это <игра>\System\, где лежит Gothic2.exe.
3. System32, папка Windows. (SysWOW64 для 32-битных программ)

То есть из /system игры все читается не потому, что такова архитектура Union, а только благодаря гибкости Windows.
Если, допустим, я ложу UnionAPI.dll в Windows\SysWOW64 и у меня все работает, значит ли это что надо теперь всем говорить, что правильно ложить UnionAPI.dll в Windows\SysWOW64?) Почему бы и нет, работает ведь.
А наш знаменитый "Патрикс на гитхабе", который рекомендовал, что "она должна сидеть в System" уже год не может починить свой GFA-фриаим.
Сорян, за духоту..

 

[Хедин]

@Dreamtrust, там проблема в том, что все что в авторан, пробует загрузить сам юнион как плагин, что негативно сказывается. Я с таким сталкивался когда пихал zUnionAdapter.dll, таже ситуация и с UnionAPI.dll, поэтому лучше так не делать в релизе. В тестовых можно оставить, тем более по ошибке у патрика он пихается в vdf прямо в авторан.

 

[Dreamtrust]

тем более по ошибке у патрика он пихается в vdf прямо в авторан

У Патрика беда в том, что он ложит mds-скрипт и asc.исходники, которые zModelProtoExtender начинает автоматически компилировать при запуске игры и вся эта каша работает только на первом запуске игры.

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

Это да, ядро Union при старте грузит каждую .dll, но у Unionapi нет никаких «плагинных» функций, это всего лишь библиотеки. Код инициализации UnionAPI.dll (DllMain, создание общей памяти хуков) выполнится в любом случае, хоть его загрузит ядро, хоть Windows как зависимость плагина.
А с zUnionAdapter.dll, ты прав. Это костыль для zFont потому, что zFont написан на старом SDK и сам ставить хуки union-api не умеет. Через zUnionAdapter.dll он ставит один partial-хук на zCView:: Print (0x007A9A40). И внутри него тоже лежит Unionapi.dll, причем старой версии, вшит статистически, один в один как у нашего любимого Union_Freeaim. Если он лежит в System, то подгружается по запросу zFont, если лежит в Autorun, то подгружается всегда и без разницы установлен zFont или нет.
И поэтому, если ложить zUnionAdapter.dll в Autorun, то есть риск что его unionapi.dll загрузится раньше, чем unionapi.dll других плагинов. И общую память хуков и обработчик загрузки .dll будет держать его старый Unionapi.dll и все плагины на union-api будет работать через него, и если они писались на более свежей сборке, то будут проблемы.

 

[Хедин]

Это костыль для zFont потому, что zFont написан на старом SDK

Это не костыль для zFont, а вроде будущая фича для нового юнион, если он когда-нибудь зарелизится. Он нужен для улучшения совместимости старых хуков и новых. Но не факт что это дело допилят, как и релиз фремйоркапи, на котором ты пишешь. ))
А в zFont я в своей ветке его использовал да, только для частичного хука на принт, ибо это единственный способ был попасть гарантировано в конец принта))

 

[Dreamtrust]

Но не факт что это дело допилят, как и релиз фремйоркапи

Не зарелизят и пофиг, в текущем виде работает и ладно)