Перейти в начало страницы

Здравствуйте, гость ( Авторизация | Регистрация )

Gameru.net останавливает работу в связи с вторжением армии РФ в Украину. Следите за дальнейшими анонсами.
Support Gameru!

> Помощь по разделу

Сайт S.T.A.L.K.E.R. Inside / [ЗП] Параметры командной строки / Распаковщик ресурсов

> Редактирование движка
RayTwitty
сообщение 22.01.2016, 17:18
Сообщение #2261


Игровой Бог
**********************

Репутация:   648  
Группа: Участник
Сообщений: 5354
Регистрация: 24.09.2010




Вставить ник Цитировать выделенное в форуму быстрого ответа



Редактирование собранного движка
Проект X-Ray extensions и его вики
Lua-перехватчик от alpet
xrLuaFix от RvP
xrLuaFix в редакции от Artos
xrLuaFix в редакции от svarog2741
LuaXML библиотека парсинга xml-файлов из скриптов (подключается при помощи функции require, которая есть в xrLuaFix)
NoProtect 1.0006 исполнительные файлы из Steam-версии без защиты
Документация к X-Ray (11.10.2004)
Файл заголовков от отладочного 6 патча
Cut X-Ray
Цель проекта - создание отдельных изменений движка игры с их последующей комбинацией с другими правками.
Авторы: SkyLoader, _призрак_
Для платформ: ТЧ 1.0004 и 1.0006, ЧН 1.5.10, ЗП 1.6.02
Адрес проекта на Google Code: https://code.google.com/p/cut-x-ray-project/
Страница на Moddb: http://www.moddb.com/mods/cut-x-ray-project-soc-cs-cop
Пак 1
1. Исправление вылета "can't find rank" для оружий.

2. Смерть от первого лица.
Видео: https://www.youtube.com/watch?v=c-4dNyvizxY

3. Collide
Возвращена коллизия мертвых тел с неписями и актором, как она сделана в старой физике билдов.
Видео: https://www.youtube.com/watch?v=1xNn04f3djc

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

5. Исправление вида от 3-го лица.
Изменено положение камеры от 3-го лица (1). Стрельба идет по перекрестью, а не по направлению актора. Если включить вид от 3-го лица (1) и удерживать Shift, то ГГ будет автоматически целиться в ближайшего непися или монстра.
Проблемы: Стрельба по перекрестью идет также при виде от 3-го лица (2). Если при автоматическом нацеливании непись/монстр удалится или перейдет в оффлайн, будет движковый безлоговый вылет. Я думал вырезать это нацеливание, но решил оставить.
Пак 2
1. Luminosity progress (только ТЧ)
Возвращение шкалы освещения вместо шкалы "заметности" ГГ, как в билдах.

2. Запрет на доставание оружия в машине (только ТЧ и ЧН) и на лестнице (ТЧ, ЧН, ЗП).

3. Руки на руле в машине. (только ТЧ и ЧН)
Видео: https://www.youtube.com/watch?v=nYrnrfGkO7Y

4. Отсутствие распознавания неписей перекрестием:
При наведении на непися перекрестье имеет дефолтный цвет. Также не показывает информацию о неписе, если смотреть на него.

5. Bind_object:
Возможность использовать скрипты в мультиплеере.

6. Из оружия на классе бинокля можно стрелять (только ТЧ)
Пак 3
1. Включение некоторых команд без использования ярлыка. Можно патчить по отдельности. Команды: -smap_4096 (максимально улучшенные карты теней), -mblur (включение блюра).

2. Измененная анимация безоружного гг.

3. Увеличение дистанции диалога с неписями (для создания сценок на расстоянии)

4. Исправление вылета при использовании предметов из трупов неписей.
В отличии от версии Kolmogor'а, здесь отключено само меню использования.

5. Возможность поднимать болты как обычные инвентарные предметы (комбинировать с модом Charsi "Заканчивающиеся болты")
Скачать все паки
Правки от RayTwitty aka Shadows
Geometry LOD fix (CS 1.5.10) – расширение диапазона консольной команды r__geometry_lod
Camblu crosshair for build 1865 – замена перекрестия прицела на кружок в билде 1865
Vertex buffer fix for NC Project – исправление вылета по переполнению буфера в NC Project
NO 100 sovetov fix (COP 1.6.02) – убирает надписи "100 советов" с экрана загрузки
Demo Record fix (SOC 1.0006) – убирает красные надписи в режиме demo_record
Weapon Bobbing Beta (SOC 1.0006) – раскачка оружия при ходьбе (бета-версия)
Build Loadscreen (SOC 1.0006) – билдовский экран загрузки со статичным изображением
Detail Density fix (SOC 1.0006) – расширение диапазона консольной команды r__detail_density
Mipbias fix (SOC 1.0006) – расширение диапазона консольных команд r1_tf_mipbias и r2_tf_mipbias
No Quick Use fix (SOC 1.0006) – запрет на использование аптечек и бинтов по быстрым клавишам
Sun Near fix (SOC 1.0006) – расширение диапазона консольной команды r2_sun_near
Target Font (SOC 1.0006) – замена шрифта под перекрестием прицела на шрифт DI
Unload Magazine fix (SOC 1.0006) – фикс скриптовой функции unload_magazine - теперь патроны разряжаются в инвентарь
PNG Screenshots (SOC 1.0006) – игра теперь делает качественные скриншоты в формате png

Скачать все правки
Правки от K.D.
xrPatch v0.8 – патчер для увеличения радиуса прорисовки травы
detail radius+density fix [SOC 1.0006] – добавляет регулировку радиуса отрисовки травы через консольную команду и расширяет диапазон регулировки плотности травы до 0.02
Правки от macron
Исправленный экзешник для SoC 1.0006
Доработанный и исправленный экзешник для ТЧ 1.0006 (на основе Steam-версии без защиты)
Включает в себя исправления вылетов, а также очистку лога игры от засоряющих сообщений. Более подробное описание внутри архива.

Ссылка: https://yadi.sk/d/At9Tw0ueSaDyS
X-Ray extensions portable
Портативная версия расширений движка "X-Ray extensions"
Платформы: ТЧ 1.0006, ЧН 1.5.10, ЗП 1.6.02
Эта версия имеет все нужные библиотеки и патчеры, а также настроенные bat-файлы для успешной компиляции. Более подробное описание внутри архива.

Ссылка: https://yadi.sk/d/OLYPbDXWjyEkH
Правки от Kolmogor
Правленный xrGame для SoC 1.0004
Изменения:
1. Добавлена консольная команда fov [5.0, 180.0] - изменяет глобальный FOV камеры.
2. Добавлена консольная команда k_ammo_on_belt [on\off] - включает\выключает использование патронов с пояса.
3. Артефакты работают из рюкзака, а пояс служит контейнером.

Ссылка: http://rusfolder.com/42636653
Правки от Kontro-zzz
Изменение значения hud_fov
Правки фиксированных значений параметра hud_fov - 0.37 либо 0.53, для CS 1.5.10 и для билда 3120.
Должно работать на GOG версии и no DVD.
Редактирование исходников
Скачать все исходники отсюда или с оригинальных постов SoC 1.0007rc1 SoC и CS CoP X-Ray 2
Репозитории

[SoC]
() Alpet & KD / оригинальное репо [Архивная ценность]
() xrDev [Архивная ценность]
() CleanXR [Архивная ценность]
() KRoddin [Архивная ценность][/b]
() Lost Alpha old [Архивная ценность]
() Репозиторий OGSE | Самый актуальный форк (KRoddin) | Версия от Abramcumner с небольшими исправлениями
() 1exx [Архивная ценность]
() Shkiper2012 [Архивная ценность]
() Morrey (dx10) [Архивная ценность]
() OP Engine (Winsor)
() Kondr48 [Архивная ценность]

[CS]
() RedPython [Архивная ценность]
() xrDev [Архивная ценность]
() OpenXRay [Архивная ценность]
() Charsi82 [Архивная ценность]
() Abramcumner | drksnc (MP) [Архивная ценность]
() RainbowZerg [Архивная ценность]

[CoP]
() Forser
() OpenXRay
() CoC | Demosfen | Last Day
() Abramcumner
() Im-Dex [Архивная ценность]
() xrDev [Архивная ценность]
() Tron [Архивная ценность]
() mrmnwar [Архивная ценность]
() Avo [Архивная ценность]
() vincent-t [Архивная ценность] | Старый репозиторий
() Shoкer
() Morrey CS-COP [Архивная ценность]
() Morrey [Архивная ценность]

[2.0]
() Saas
() xrOxy
Компиляторы x64: SoC CS CoP
NDA GSC
Оригинальные версии движков
Могут понадобиться для восстановления оригинальных библиотек.
SoC SoC ENG CS CoP
GOG version [1.0006, 1.5.10, 1.6.02]
Multi-patch version [1.0006, 1.5.10, 1.6.02]
Официальный мультиплеерный (невышедший) патч для SoC 1.0007rc1.
Уроки
Изменение плотности травы и создание патча через IDA Pro
Автор: _призрак_
edited by: RayTwitty aka Shadows

Для редактирования нам понадобится программа IDA Pro.

1. Запускаем IDA Pro.
2. Загружаем бинарник рендера xrRender_R1.dll или xrRender_R2.dll.
3. Теперь необходимо найти, где регистрируется консольная команда. Жмем Ctrl+T и вводим r__detail_density.
4. Находим функцию и тщательно ее разбираем (я ее полностью разбирать не буду, только укажу, где задаются параметры:
Код регистрации консольной команды
Код
fld ds:flt_10064400 -- нижнее ограничение равное 0.6
or dword_1007CACC, 8
sub esp, 8
fstp [esp+30h+var_2C]
mov ecx, offset unk_1007CA9C
fld ds:flt_10064380 -- верхнее ограничение равное 0.2
fstp [esp+30h+var_30]
push offset aSs; "ЪЩЩ>"
push offset aR__detail_dens; "r__detail_density"
call ds:??0CCC_Float@@QAE@PBDPAMMM@Z; CCC_Float::CCC_Float(char const *,float *,float,float)
push offset sub_1005E080; void (__cdecl *)()
call _atexit
add esp, 4
Если вы заметили, чтобы трава стала плотней нужно уменьшить параметр, а чтобы травы стало меньше, нужно параметр увеличить
5. Нам нужно увеличить плотность травы: следовательно нужно изменить верхнее ограничение. Как это сделать? Есть три варианта:

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

Второй: взять другую, уже существующую переменную с подходящим значением. Хороший вариант которым я и воспользовался. Но и тут есть недостаток - переменных в бинарнике не так уж и много и можно просто не найти нужную.

Третий: создать переменную. Отличный вариант. Единственный минус - я не знаю как это сделать smile.gif

Я пошел по второму пути. Два раза щелкнув на ds:flt_10064380, IDA отправила меня в дебри под названием .rdata. Там я нашел переменную, которая называлась - flt_1006452C и которая имела значение 0.0720999.
Насколько я понял, flt_1006452C - не является названием переменной, это сборка из двух показателей - (тип числа)_(смещение). В нашем случае это число типа float, которое находится по адресу 1006452C. Ну что же, приступим к редактированию!
6. Отправляемся в самое начало файла. Как? Сверху есть что-то типа статус-бара - строка состоящая из синего, серого, черного цвета. Нажимаем там в любом месте мышкой и ведем влево до конца.
7. Опять ищем r__detail_density. Находим в этой функции строку fld ds:flt_10064338. Дальше самое интересное - жмем на вкладку Hex View и там у нас выделяются какие-то цифры. Это наша переменная 10064338, только написано наоборот. Сравните:
Код
38 43 06 10
10 06 43 38
Похоже, не правда ли? smile.gif
8. Начинаем редактировать. Нам нужно поменять 4338 на 452C (т.е. заменить ссылку с одной переменной на другую). Жмем правой кнопкой мыши на этих цифрах и выбираем пункт Edit. Меняем 38 43 на 2С 45. Дальше жмем где-нибудь в коде (это нужно сделать обязательно!).
9. После этого жмем правой кнопкой мыши и выбираем commit changes. Таким образом, мы поменяли ссылку на переменную и теперь верхнее ограничение будет равно значению из другой переменной.
Но IDA не меняет исходный файл. В нашем случае мы можем только создать файл изменений. Делается это так: File -> Produce file -> Create DIF file. Назовем его test. Этот файл можно открыть при помощи блокнота и посмотреть, что получилось.
10. Теперь необходимо внести изменения из этого файла в движок. Это можно сделать при помощи патчера bpatch. Качаем, смотрим и запускаем bpatch.cmd. Я думаю, что батник вы сможете изменить самостоятельно (настроить пути файлов и т.п.) - там все элементарно.
11. Все! Изменения внесены в движок, можно тестировать smile.gif

Огромное спасибо Kolmogor'у и malandrinus'у. Если бы не они, я бы ничего не сделал. Спасибо вам еще раз.
Спасибо и Rolan'у, с которым я очень много беседовал и тоже узнал много чего smile.gif




Сообщение отредактировал RayTwitty - 27.08.2021, 00:15
Перейти в начало страницы
 
242 страниц V  « < 112 113 114 115 116 > »   
Начать новую тему
Ответов
mortan
сообщение 18.01.2017, 14:30
Сообщение #2262


Продвинутый геймер
********

Репутация:   16  
Группа: Участник
Сообщений: 222
Награды: 3
Регистрация: 28.06.2016




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата(SkyLoader @ 18.01.2017, 00:31) *
Цитата(mortan @ 17.01.2017, 23:39) *
Вопрос - можно ли сделать их как бы одним целым, дабы при анимках ничего не дёргалось?

В ТЧ, насколько я помню, аттаченные предметы не отставали и не дергались. В ЗП такая проблема есть. Можно глянуть отличия ЗП от ТЧ в расчетах позиции предметов, может там отставание на один кадр есть.

понял, спасибо, надо глянуть. Как вариант хочу попробовать отключение коллизии у отдельной кости ( не знаю реально ли такое сделать)
Перейти в начало страницы
 
GermanAizek
сообщение 18.01.2017, 19:25
Сообщение #2263


Игрок
***

Репутация:   0  
Группа: Участник
Сообщений: 36
Награды: 1
Регистрация: 10.01.2017




Вставить ник Цитировать выделенное в форуму быстрого ответа


Не подскажете, а при компиляции Level Editor какие библиотеки надо подключать? Хотя всех редакторов тоже. Чекал статьи про сборки движков, но написаны либы только для самого движка или я слепой?
Перейти в начало страницы
 
AndreySol
сообщение 21.01.2017, 21:53
Сообщение #2264


Опытный Геймер
*******

Репутация:   3  
Группа: Участник
Сообщений: 150
Награды: 3
Регистрация: 16.02.2014




Вставить ник Цитировать выделенное в форуму быстрого ответа


Требуется добавить новый класс в xrGame. Он должен сохранять\загружать значения нескольких своих переменных(при сохранении\загрузке сейвов) + иметь возможность менять значения переменных с течением игрового времени(типа CEntityCondition::UpdateConditionTime()\CEntityCondition::UpdateCondition()) + класс будет использован как один из родительских для некоторых инвентарных объектов. Подскажите, как правильно сделать ? Создать его с нуля, без наследования от какого либо родительского, или все-же наследовать от CGameObject ? Или от какого-то другого ?

Сообщение отредактировал AndreySol - 21.01.2017, 21:53
Перейти в начало страницы
 
Карлан
сообщение 21.01.2017, 22:52
Сообщение #2265


Геймер
******

Репутация:   9  
Группа: Участник
Сообщений: 110
Награды: 2
Регистрация: 21.09.2014




Вставить ник Цитировать выделенное в форуму быстрого ответа


Свой вопрос закрываю. Решил параллельной дллкой и парой скриптовых приблуд.


--------------------
Перейти в начало страницы
 
Winsor
сообщение 23.01.2017, 13:32
Сообщение #2266


Геймер
******

Репутация:   4  
Группа: Участник
Сообщений: 108
Награды: 3
Регистрация: 02.02.2016




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата(AndreySol @ 21.01.2017, 21:51) *
Создать его с нуля, без наследования от какого либо родительского, или все-же наследовать от CGameObject ? Или от какого-то другого ?

наверное подойдет CInventoryItem, или, если надо поддерживать "физические" свойства - CInventoryItemObject. например, CEatableItem наследуется от CInventoryItem, а вот уже CCustomOutfit - от CInventoryItemObject. переопределяя методы save/load можете сохранять свои значения после inherited::*.
Перейти в начало страницы
 
AndreySol
сообщение 23.01.2017, 18:32
Сообщение #2267


Опытный Геймер
*******

Репутация:   3  
Группа: Участник
Сообщений: 150
Награды: 3
Регистрация: 16.02.2014




Вставить ник Цитировать выделенное в форуму быстрого ответа


А что насчет Update-ф-ций ? У CInventoryItemObject есть ф-ция "UpdateCL", проверил - действительно какой-то апдейт. Его можно использовать аналогично UpdateCondition из CEntityCondition ?
Перейти в начало страницы
 
Winsor
сообщение 24.01.2017, 09:55
Сообщение #2268


Геймер
******

Репутация:   4  
Группа: Участник
Сообщений: 108
Награды: 3
Регистрация: 02.02.2016




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата(AndreySol @ 23.01.2017, 18:30) *
А что насчет Update-ф-ций ? У CInventoryItemObject есть ф-ция "UpdateCL", проверил - действительно какой-то апдейт. Его можно использовать аналогично UpdateCondition из CEntityCondition ?
чесно - не знаю, smile.gif их апдейты я не изучал smile.gif это на совести дебага. я думаю, банальный вывод в лог покажет насколько часто и когда они обновляются.
===
посмотрел.
В основном UpdateCondition выполняется на главном апдейте CEntityAlive::shedule_Update. т.е. для Вашего класса , если Вы хотите использовать shedule_Update - Вам необходимо свой класс наследовать от CInventoryItemObject. CInventoryItem не имеет в предках CObject и не подходит для Вашей задачи.

Сообщение отредактировал Winsor - 24.01.2017, 10:06
Перейти в начало страницы
 
serg101188
сообщение 27.01.2017, 02:35
Сообщение #2269


Почти Игрок
**

Репутация:   1  
Группа: Участник
Сообщений: 28
Награды: 1
Регистрация: 31.05.2014




Вставить ник Цитировать выделенное в форуму быстрого ответа


кто в курсе или в чем проблема вот с такой ошипки

Loading DLL: xrGameSpy.dll
! cant find corresponding [id] for action_name
! cant find corresponding [id] for action_name
! cant find corresponding [id] for action_name
! cant find corresponding [id] for action_name
! cant find corresponding [id] for action_name
! cant find corresponding [id] for action_name
! cant find corresponding [id] for action_name
! cant find corresponding [id] for action_name
! cant find corresponding [id] for action_name
Перейти в начало страницы
 
AndreySol
сообщение 28.01.2017, 14:23
Сообщение #2270


Опытный Геймер
*******

Репутация:   3  
Группа: Участник
Сообщений: 150
Награды: 3
Регистрация: 16.02.2014




Вставить ник Цитировать выделенное в форуму быстрого ответа


serg101188
Если я правильно понял по содержимому файла(xrGame\xr_level_controller.cpp), то проблемы с дефолтным назначением действий на клавиши в настройках клавиатуры. Там из таблицы "actions" такого вида:
actions[] = {
{ "left", kLEFT ,_both},
{ "right", kRIGHT ,_both},
...........
происходит выборка значения по строковому названию. Указанные тобой сообщения выводятся, если в таблице не найдено соответствующее поле. Если в ф-ции
_action* action_name_to_ptr(LPCSTR _name)
исправить вывод сообщения как-то так:
Msg ("! cant find corresponding [id] for action_name=%S", _name);
то можно будет увидеть конкретные команды, которым не назначены клавиши по дефолту.
Перейти в начало страницы
 
ForserX
сообщение 29.01.2017, 22:08
Сообщение #2271


Почти Игроман
*********

Репутация:   91  
Группа: Модератор
Сообщений: 516
Награды: 4
Регистрация: 19.07.2015




Вставить ник Цитировать выделенное в форуму быстрого ответа


Пролистал подфорум, никакого поиска в команду не нашёл, а может и просто не заметил, поэтому пишу сюда:

В проект "Тайна Станции «Дуга»" требуется программист. На данный момент проект базируется на Open X-Ray. Если кому-то интересно, пишете мне в личку.

Скажу сразу:
1. Проект не мой
2. Участвую в нём косвенно (подсказываю, когда допекут в лс)
3. Работа в проекте (любом) на данный момент мне не интересна, в связи с чем не помогаю им.


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

В армии по 01.07.2020.
Перейти в начало страницы
 
SkyLoader
сообщение 30.01.2017, 00:47
Сообщение #2272


Почти Игроман
*********

Репутация:   153  
Группа: Участник
Сообщений: 614
Награды: 4
Регистрация: 03.05.2012




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата(Forser @ 29.01.2017, 22:06) *
В проект "Тайна Станции «Дуга»" требуется программист.

Мы это уже проходили
Перейти в начало страницы
 
ForserX
сообщение 30.01.2017, 08:55
Сообщение #2273


Почти Игроман
*********

Репутация:   91  
Группа: Модератор
Сообщений: 516
Награды: 4
Регистрация: 19.07.2015




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата(SkyLoader @ 30.01.2017, 00:45) *
Мы это уже проходили

Жалко мне его.


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

В армии по 01.07.2020.
Перейти в начало страницы
 
AndreySol
сообщение 02.02.2017, 22:57
Сообщение #2274


Опытный Геймер
*******

Репутация:   3  
Группа: Участник
Сообщений: 150
Награды: 3
Регистрация: 16.02.2014




Вставить ник Цитировать выделенное в форуму быстрого ответа


Непонятка у меня с методами UPDATE_Read\UPDATE_Write, прошу раъяснения. Собственно дело в чем: для фонарика прописал в CSE_ALifeItemTorch новую переменную. В конструкторе класса инициализирую ее дефолтным значением. После создания объекта, у него первым вызывается метод CSE_ALifeItemTorch::UPDATE_Write, и там эта переменная записывается в нет-пакет, и следовательно она в дальнейшем имеет дефолтное значение. Добавил по такому-же принципу переменную в CSE_ALifeObjectHangingLamp, но там почему-то все оказалось наоборот: первым, после создания объекта вызывается CSE_ALifeObjectHangingLamp::UPDATE_Read, соответственно из нет-пакета читается пустое значение, которое затирает дефолтное значение переменной. Оно понятно, что фонарик объект инвентарный, а лампа - физический, но почему-же так наоборот-то все ? И как сделать тогда для ламп инит\сохранение переменной на подобии как у фонарика ?
Перейти в начало страницы
 
Shoкer
сообщение 03.02.2017, 02:25
Сообщение #2275


Кандидат Игровых Наук
******************

Репутация:   2153  
Группа: Участник
Сообщений: 3488
Награды: 4
Регистрация: 27.07.2009




Вставить ник Цитировать выделенное в форуму быстрого ответа


Ну начнём с того что сохранять и загружать переменные требуется в STATE_Read\STATE_Write.
Они вызываются при загрузке\сохранении объекта или при его переходе в онлайн\оффлайн.

Как только клиентский объект создался, его серверный вызывает у себя функцию STATE_Read, а та в свою очередь приводит к вызову net_Spawn у клиентcкого. Тут ты и должен загружать сохранённые данные в клиентский объект.

UPDATE_ же используется для синхронизации - постоянного обмена данными между серверной и клиентской версией объекта (в частности для сетевой игры) и вызывается после STATE_-ов.

У клиентского объекта это соответственно net_Import и net_Export.

То-есть для загрузки твои действия такие:

1) В серверном объекте в конструкторе указываешь дефолтное значение своей переменной.
2) В серверном объекте в STATE_Read ты его считываешь из сейва\спавна. Если это первое создание объекта, то скорее всего там будет тоже-самое дефолтное значение из конструктора, если это загрузка уже существующего объекта, то получишь своё сохранённое значение.
3) В клиентском объекте в функции net_Spawn ты вытаскиваешь свою переменную в клиент. (вызывается ОДИН РАЗ в момент каждого перехода объекта в онлайн)

Для сохранения на сервере пихай свою переменную в net_Export у клиента. (только не забывай что она вызывается достаточно часто) Нет-пакет, созданный в net_Export, будет считан серверным в UPDATE_Read.

net_Import в сингле вроде как не работает (по крайнем мере я не словил его вызовов), в МП же он будет вызываться достаточно часто. (для синхронизации данных между игроками и сервером)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ещё есть один трюк, который облегчит тебе жизнь, но скорее всего он не совместим с МП.
Забудь про серверные классы, в клиентских у объектов есть функции save() \ load().
Точно также работают с нет-пакетами, и эти данные даже записываются в серверный объект (там есть под них выделенное место, custom_data кажется, не путать с той что из конфигов)

Единственное что, эти данные могут стираться, если игрок например сменит уровень, а объект останется на старом.
Чтобы такое избежать, достаточно переопределить в клиентском классе функцию keep_saved_data_anyway() чтобы возвращала true. Поищи поиском примеры в движке, там всё просто.

К слову это всё ровно те же самые функции, которые экспортированы в Lua.

Сообщение отредактировал Shoкer - 03.02.2017, 02:28


--------------------
Мне просто нравятся синие буквы под сообщением.
Перейти в начало страницы
 
AndreySol
сообщение 03.02.2017, 07:04
Сообщение #2276


Опытный Геймер
*******

Репутация:   3  
Группа: Участник
Сообщений: 150
Награды: 3
Регистрация: 16.02.2014




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата(Shoкer @ 03.02.2017, 03:23) *
что сохранять и загружать переменные требуется в STATE_Read\STATE_Write.
Я пока не очень разобрался в движке, по-этому действую пока по принципу "сделай аналогично":
для фонарика, перечисление EStats с флагами состояния:
тык
void CSE_ALifeItemTorch::STATE_Read(NET_Packet &tNetPacket, u16 size)
{
if (m_wVersion > 20)
inherited::STATE_Read(tNetPacket,size);
}

void CSE_ALifeItemTorch::STATE_Write(NET_Packet &tNetPacket)
{
inherited::STATE_Write(tNetPacket);
}

void CSE_ALifeItemTorch::UPDATE_Read(NET_Packet &tNetPacket)
{
inherited::UPDATE_Read(tNetPacket);

BYTE F = tNetPacket.r_u8();
m_active = !!(F & eTorchActive);
m_nightvision_active = !!(F & eNightVisionActive);
m_attached = !!(F & eAttached);
m_enable = !!(F & eTorchEnable);

m_fValue = tNetPacket.r_float(); // добавлено мной
}

void CSE_ALifeItemTorch::UPDATE_Write(NET_Packet &tNetPacket)
{
inherited::UPDATE_Write(tNetPacket);

BYTE F = 0;
F |= (m_active ? eTorchActive : 0);
F |= (m_nightvision_active ? eNightVisionActive : 0);
F |= (m_attached ? eAttached : 0);
F |= (m_enable ? eTorchEnable : 0);
tNetPacket.w_u8(F);

tNetPacket.w_float(m_fValue ); // добавлено мной
}
в клиентском классе:
BOOL CTorch::net_Spawn(CSE_Abstract* DC)
{
CSE_Abstract *e = (CSE_Abstract*)(DC);
CSE_ALifeItemTorch *torch = smart_cast<CSE_ALifeItemTorch*>(e);
R_ASSERT (torch);
............
............
m_Value = torch->m_fValue; // читаем мою переменную

Switch(torch->m_active);// здесь клиент читает один из флагов состояния
...........
return(TRUE);
}

void CTorch::net_Export(NET_Packet& P)
{
inherited::net_Export(P);

BYTE F = 0;
F |= (m_switched_on ? eTorchActive : 0);
F |= (m_bNightVisionOn ? eNightVisionActive : 0);
const CActor *pA = smart_cast<const CActor *>(H_Parent());
if (pA)
{
if (pA->attached(this))
F |= eAttached;
}
F |= (m_bTorchState ? eTorchEnable : 0);
P.w_u8(F);

P.w_float(m_Value);
}

Все вроде как Вы написали, за исключением STATE_Read\STATE_Write - как видим здесь как-раз все в UPDATE-... сделано. И работает.
Цитата(Shoкer @ 03.02.2017, 03:23) *
В серверном объекте в STATE_Read ты его считываешь из сейва\спавна. Если это первое создание объекта, то скорее всего там будет тоже-самое дефолтное значение из конструктора

У программистов слова "скорее всего" - верный путь к багам cool.gif К примеру после НИ, как мы прочитаем из нет-пакета значение которого там еще нет ? Логично, что все-таки сначала надо его туда записать, а уж потом читать... Я расставил проверки в STATE и UPDATE методы - в логе вижу, что для фонарика первым вызывается всегда Write на серверной части.
Я наверное опять чего-то не понял ?
Перейти в начало страницы
 
Shoкer
сообщение 03.02.2017, 14:53
Сообщение #2277


Кандидат Игровых Наук
******************

Репутация:   2153  
Группа: Участник
Сообщений: 3488
Награды: 4
Регистрация: 27.07.2009




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата
К примеру после НИ, как мы прочитаем из нет-пакета значение которого там еще нет ?

А оно будет. Движок сталкера в этом плане устроен очень интересно.

Во первых если объект был создан через all.spawn, то при создании новой игры STATE_Read будет считывать твой объект из него, поскольку .spawn файлы это по сути огромный нет-пакет. (поэтому если ты в STATE_ функциях меняешь порядок чтения\записи переменных, то можешь сломать оригинальный all.spawn. Чтобы это избежать нужно проверку на версию спавна делать - в ЗП версия текущего спавна хранится в переменной CSE_Abstract -> m_wVersion, а изменить её на новую можно в xrServer_Objects.h - SPAWN_VERSION)

Во вторых если объект был создан скриптом через alife():create() то там ровно тоже самое. Движок сперва создаёт фейковый серверный объект на стороне клиента, нигде его не регистрируя. ( у него вроде как даже ID нету ) В этот момент можно ему свойства любые поменять. А дальше он "отправляет" его на сервер, где данные этого объекта опять же считываются в STATE_Read и создаётся "настоящий" объект, таким образом ты STATE_-функции никак не пропустишь.

Возможно тут есть какие то особенности, ибо разбираться во всём этом себе дороже, но по примерам GSC и моему опыту всё именно так и работает. Если интересно, то вот я тоже сделал логирование в CSE_ALifeInventoryItem, и в момент загрузки игры (не НИ) у меня вот такое вышло.

Лог 1
// Создаются какие то пустышки (не обязательно от нашего объекта, у них ID нету)
[65535] STATE_Read
[65535] UPDATE_Read
// Первой вызывается STATE_Read - считывает либо данные из сейва, либо из all.spawn, либо из фейкового объекта
[7151] STATE_Read
// Далее UPDATE_Read, аналогично STATE_Read, т.к эти данные тоже в сейве\спавне сохраняются
[7151] UPDATE_Read
// Дальше идёт вызов функций записи в нет_Пакет, не знаю точно для чего это нужно, но данные там не меняются
[7151] STATE_Write
[7151] UPDATE_Write
[7151] STATE_Write
[7151] UPDATE_Write
// Тут снова идёт считывание из нет_Пакета
[7151] STATE_Read
[7151] UPDATE_Read
// И наконец наш серверный объект с загруженными данными попадает к клиентскому
[7151] net_Spawn
// И в дальнейшем эти функции вызываются на апдейте
[7151] net_Export
[7151] UPDATE_Read


Как видно, при загрузке игры первым всегда идёт вызов STATE_Read. А UPDATE_Read вызывается, поскольку его данные тоже в сохранение идут. (я об этом успел подзабыть

Для новой игры:
Лог 2

[6538] STATE_Write
[6538] UPDATE_Write
[6538] STATE_Write
[6538] UPDATE_Write
[6538] STATE_Read
[6538] UPDATE_Read
[6538] net_Spawn


Наоборот сперва идёт UPDATE_Write - почему так происходит? А ПЫС его знает %)


А вот лог для предмета, который я заспавнил скриптом:

Лог 3

[16109] STATE_Write // Запишет в нет_Пакет дефолты из конструктора
[16109] STATE_Read
[16109] STATE_Write
[16109] STATE_Write
[16109] STATE_Read
[16109] net_Spawn


Для него UPDATE_ функции даже ни разу не вызвались в момент создания.

А вот что происходит в момент сохранения игры:

Лог 4

[16109] net_Export // Шлём данные из клиента в серверный объекта
[16109] UPDATE_Read // Считываем их там
[16109] STATE_Write // Сохраняем STATE_ в сейв
[16109] UPDATE_Write // Сохраняем UPDATE_ в сейв


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

- - - - - - - - - - - - - - - - - - - -
По поводу твоего кода:
1) Добавь чтение своей переменной в net_Import (если тебе не наплевать на МП, иначе игра там вылетит\сломается)
2) В xrServer_Objects.h измени версию спавна на единичку.
3) В UPDATE_Read добавь перед m_fValue проверку на версию (if (m_wVersion > "старая_версия")).

Либо если тебя интересует только сингл (или эти данные не критичны для МП) - откати все свои правки и юзай save()\load() у клиента.

Цитата
Добавил по такому-же принципу переменную в CSE_ALifeObjectHangingLamp, но там почему-то все оказалось наоборот: первым, после создания объекта вызывается CSE_ALifeObjectHangingLamp::UPDATE_Read, соответственно из нет-пакета читается пустое значение, которое затирает дефолтное значение переменной.


Посмотри на Лог 1\Лог 2 и поймёшь почему так происходит. Если это новая игра, то сперва будет вызываться UPDATE_Write (почему хз, наверно это так спавн парсится или объект пустышка гонит в нет-пакет свои данные), если это загрузка сейва то наоборот UPDATE_Read. Добавь проверку на версию (пункт 3) и в фонарик, и в лампу - и, теоретически, твоя проблема должна исчезнуть.

- - - - - - - - - - - - - - - -
Небольшая заметка

UPDATE_ и net_Export следует использовать только для передачи небольших переменных. Если тебе надо сохранить на сервере какую-нибудь строку (например длинную строку со списком апгрейдов), то следует использовать STATE_Write.
Пример можешь глянуть в inventory_item_upgradge.cpp -> add_upgrade() и в xrServer_process_event.cpp -> GE_INSTALL_UPGRADE.

Но если тебе всё равно на МП, то можешь прям из клиентского объекта напрямую изменять переменные серверного объекта.


Сообщение отредактировал Shoкer - 03.02.2017, 15:09


--------------------
Мне просто нравятся синие буквы под сообщением.
Перейти в начало страницы
 
GermanAizek
сообщение 04.02.2017, 18:14
Сообщение #2278


Игрок
***

Репутация:   0  
Группа: Участник
Сообщений: 36
Награды: 1
Регистрация: 10.01.2017




Вставить ник Цитировать выделенное в форуму быстрого ответа


Простите, но я встал в тупик при компиляции Level Editor, да и вообще всех editors, к примеру при компиляции проекта отдельно le (исходники ЗП оригинал) он просит хэдеры "stdafx.h" и "fastmath.h". Я вбил в поиск fastmath и не нашел, а stdafx много. Вопрос какой инклюд надо подключать к проекту если нет этой fastmath.h? Может я что-то упустил от Шокера в инструкции по сборке? biggrin.gif
Перейти в начало страницы
 
GermanAizek
сообщение 04.02.2017, 20:24
Сообщение #2279


Игрок
***

Репутация:   0  
Группа: Участник
Сообщений: 36
Награды: 1
Регистрация: 10.01.2017




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата(GermanAizek @ 04.02.2017, 18:12) *
Простите, но я встал в тупик при компиляции Level Editor, да и вообще всех editors, к примеру при компиляции проекта отдельно le (исходники ЗП оригинал) он просит хэдеры "stdafx.h" и "fastmath.h". Я вбил в поиск fastmath и не нашел, а stdafx много. Вопрос какой инклюд надо подключать к проекту если нет этой fastmath.h? Может я что-то упустил от Шокера в инструкции по сборке? biggrin.gif


Стойте, а есть же готовые исходники в репозиториях? Я бы не парился делая то, что кто-то сделал. И если есть, то посоветуйте репозиторий и как понять какую использовать мне visual studio для сборки без бубна исходников из репозитория?
Перейти в начало страницы
 
abramcumner
сообщение 04.02.2017, 20:31
Сообщение #2280


Игровое Воплощение
*********************

Репутация:   394  
Группа: Участник
Сообщений: 4791
Награды: 4
Регистрация: 27.04.2011




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата(GermanAizek @ 04.02.2017, 20:22) *
и как понять какую использовать мне visual studio для сборки без бубна исходников из репозитория?

В описании репозитория будет написано, какая студия нужна для сборки.

Только level Editor собирается не в студии, а в C++ Builder. Шестой версии вроде.
Перейти в начало страницы
 
GermanAizek
сообщение 04.02.2017, 22:34
Сообщение #2281


Игрок
***

Репутация:   0  
Группа: Участник
Сообщений: 36
Награды: 1
Регистрация: 10.01.2017




Вставить ник Цитировать выделенное в форуму быстрого ответа


Цитата(abramcumner @ 04.02.2017, 20:29) *
Цитата(GermanAizek @ 04.02.2017, 20:22) *
и как понять какую использовать мне visual studio для сборки без бубна исходников из репозитория?

В описании репозитория будет написано, какая студия нужна для сборки.

Только level Editor собирается не в студии, а в C++ Builder. Шестой версии вроде.


Вот насчет левел эдитора неожиданный поворот, спасибо за информацию. Ну вот к примеру есть репозиторий xrDev там есть исходники фиксенные ЗП, но я не могу найти какая студия года, пытался открыть 2008,2010 пока тщетно.
Перейти в начало страницы
 

242 страниц V  « < 112 113 114 115 116 > » 
Ответить в данную темуНачать новую тему
6 чел. читают эту тему (гостей: 6, скрытых пользователей: 0)
Пользователей: 0

 



Текстовая версия Сейчас: 27.04.2024, 17:58