Kondr48

Исправление сохранения клиентских объектов. Фикс вертикальной синхронизации (r2) Добавление изменения переносимого веса в свойства артефактов.

Да, но если юзер пишет в сообщении своём "спасибо" и ещё пишет, что и как он сделал, что у него наконец заработало, например. Если объясняю непонятно, вопрос можно считать исчерпанным, не такая важная проблема, чтобы её обсуждать на половину страницы

Murarius, имелся ввиду чужой пост. Что-то в духе: "спасибо за помощь, сделал вот так и оно заработало". Не всегда это можно оценить кнопками полезно, нравится или согласен. Но это не то что бы сильная "хотелка", просто было бы неплохо.

Возможно, стоит добавить кнопку "пожалуйста"? Иногда она бы не помешало. Спасибо сообщениями не говорят, однако иногда вместе со спасибо сообщение содержит ещё что-то. Тогда кнопочка подошла бы, я думаю

Кто-то из форумчан Карлан упоминал, вспомнил вот. Ошибка-опечатка в оригинальном репозитории xp-dev в колбеке на before save (вызывается перед созданием сейва, насколько я понял), точно есть с r180 и до финальной так и осталось. script_game_object_script.cpp: находим: value("on_before_save", int(GameObject::ePostSave)), и заменяем на: value("on_before_save", int(GameObject::eBeforeSave)),

Ну явно не видос

Ну вот, судя по всему, игра не нашла tonnel.spawn вот и ругается Похожий, не уверен, что именно такой (REBUILD SPAWN! точно было) вылет происходит, если изменить all.spawn, а сейв, который мы загружем был сделан еще на старом спавне.

pc-2, я не знаю что у Вас там работает не так. Честно). Лично я бы сделал иначе. В колбеке на использование сигареты (на классе антирада) вызывал бы спавн худового объекта сигареты, затем в колбеке на взятие предмета уже ловил получение худ предмета, активировал его слот, запускал таймер равный длительности анимации, а по окончании очищал бы слот и выводил нужное сообщение. (Ну и заспавнить фейк-предмет который там даёт нужные бафы можно где-нибудь заранее, например вместе со спавном худ-сигареты, и съесть по окончании таймера) Конечно костыльно-заморочено, но без правок движка, в принципе, так оно и делается.

Что логично: db.actor:drop_item(oitem) --- А вообще, скорее всего, происходит так: у модели сигареты анимация только курения, при подборе слот активируется, вот анимация курева и проигрывается. Следовательно этот худовый предмет надо удалять.

abramcumner, вот это уже более понятно, значения приобретают какой-то смысл. Спасибо. Однако в ЗП я вроде бы не видел таких артефактов как в ТЧ прибавляющих +600% здоровья. Там как-то иначе сделано, или просто нет в ЗП таких?) P.S. стало понятно, почему у меня радиацию исправно показывает 0 чего бы я там не ставил, а я просто выставил в 0 скорость вывода радиации в actor.ltx, мда

А вот, самое интересное, это не так. (Хотя при просмотре кода вывода свойств артефакта и складывается такое впечатление, потому что зачем-то - ну а правда, зачем? - значение из конфига артефакта делится на похожее значение актора) На самом деле само применение свойств артефакта выглядит примерно так: conditions().ChangeBleeding(artefact->m_fBleedingRestoreSpeed*f_update_time); ChangeBleeding это функция которая прибавляет к текущему значению кровотечения указанное. Тут просто получается очень маленькое число, которое прибавляется раз в определенный момент времени который, если размотать цепочку приводит к m_fDeltaTime который, кстати, и от таймфактора зависит А вот если бы чётко было понятно как они высчитывали, вопрос бы не стоял, потому что пока мне кажется либо у них была какая-то программка которая вычисляла какие коэффициенты в конфиг вписать, либо это подбором на глаз делалось, в чем я сильно сомневаюсь. А как это работает в ЗП? Там же есть параметр magnitude, который как-то там влияет на то, что отображается в описании артефакта.

Ну не то чтобы иную, в целом именно её, хочется переписать расчёт артефактов так чтобы удобно было настраивать их модмейкеру и всё было более чем ясно для игрока. Там в движке вообще какая-то непонятная магия в свойствах артефактов на самом деле, вроде и на первый взгляд как-то логично, но сделано довольно странно. Свойства из конфига артефакта делятся на некие соответствующие у актора, потом это всё умножается на 100. Потом идут дальнейшие деления / умножения для конкретных свойств. Например кровотечение потом опять делится на 100, и выходит что цифра должна выводиться прямо из конфига?

Я никак не пойму, что значит перерасчет в конфигураторе.

Ну как минимум тем, что в конфигах там никакими процентами не пахнет, задаются абстрактные 0,0002 и т. п. Мб это только на исходниках так, но сейчас там при выведении свойств артефакта показатель просто умножается на 100, т. е. те же 0,0002 * 100 = 0,02% ~= 0% последнее и выводится. А там же не ноль, здоровье то будет восстанавливаться. А вот это уже интересно. Только не для всего сгодится. Например для выносливости, голода, жажды вполне годится (так скорее всего и сделаю) пси-здоровье то, наверное, со временем должно в форму приходить, так что ему тоже подойдет. а вот для здоровья как-то иначе придется делать. Потому что по факту скорость восстановления здоровья без всяких "улучшителей" вроде артефактов и медикаментов должна быть очень близкой к 0 . То же относится и к радиации, кровотечению. Тогда уж отключить вывод характеристики артефактов вообще, сделать разумно-рандомные свойства и вообще не ясно будет чего ждать от артефакта. Реалистично, может быть, но уже в ущерб играбельности по-моему. Конечно геймплейно-сюжетно можно сюда учёных приплести, для оценки свойств или девайс какой (сканер, анализатор) опять же связанный с базой данных ученых, тут уже насколько фантазии хватит.

ed_rez, вот об этом и речь. Нужны разумные единицы влияния. Собственно по ним мне и нужны идеи. Какой показатель с течением времени как должен на ГГ действовать.

Не знаю, наверное это наиболее подходящая тема. Что можно придумать со свойствами артефактов?) Как-то хотелось бы показатели подправить. Привожу на примерах. health_restore_speed - это скорость восстановления здоровья. По идее логично считать в процентах. Мы же увеличиваем эту скорость. Следовательно, при ста процентах здоровье должно восполниться мгновенно. Ну и, соответственно, при -100 мгновенно убить ГГ. (кому бы оно надо было ) Но за какое время его восстанавливать? Этот процент, два или три? За секунду? Например, если у артефакта в свойствах написано: Восстановление здоровья: +1% Это будет значить, что за секунду добавляется процент к общему здоровью ГГ? radiation_restore_speed а это в чем лучше измерять? Также в процентах? Или какие-нибудь бэры, рады и прочее нарисовать? (ещё бы я в этом что-то понимал ) Собственно, сделав это будет нереально легко настраивать параметры для артефактов и, что самое главное, игрок когда посмотрит на все эти циферки будет понимать, чего от такого артефакта ждать. Но, если сделать проценты в секунду, то из практически мертвого состояния за ~100 секунд показатель полностью восстановится/обнулится. Это подходит далеко не для всех параметров, если при ношении артефакта ГГ получит полную шкалу радиации за ~ 1:40 секунд (причем не факт что он доживёт до момента заполнения этой шкалы.) это будет как минимум плохо. Это при том что 1% типа минимальная циферка после 0 а может быть и 3, и 5, и 10%. С технической точки зрения вопросов нет, благо есть исходники движка и подправить в нём коэффициенты труда не составит. Мне нужны Ваши идеи, как рассчитывать тот или иной показатель. Что бы это нравилось в первую очередь игроку. Ну или ткните куда-нибудь, если где-то это вменяемо оформлено.

Как можно определить количество знаков после запятой? Допустим, передать в функцию 0.0001, чтобы вернула она 4; 0.00006 - 5 и т. д.

Карлан, Сейчас бы в 2017 была возможность найти ссылки с 15 года. Всё-таки если есть какое-то желание делиться с комьюнити своими наработками где-то надо эти ссылки опубликовать. Либо в своем профиле, либо в какой-то теме. Там кроме описания правок что-то есть? Может я смотрю куда-то не туда, но вижу я там списки вроде: добавлено, исправлено и т.п. И какой-то список модов, где нет ссылок на скачивание или вроде того. Конечно, может там как-то по другому надо смотреть, но для "простых" пользователей ценность выложенного там материала, по-моему, стремится к 0.

m_TypesMap.insert (std::make_pair(item_sect, ITEM_TYPE())); Тут используется insert, т. е. это что-то вроде массива? Вот распарсить бы его и посмотреть что внутри. Основной вопрос как раз в том, почему у меня всегда выполняется условие: if(m_artefacts.m_ItemInfos.size()==0) return; m_TypesMap и m_artefacts.m_ItemInfos это одно и то же? Или разное? Если разное, то где формируется последний?

Раз это лист, как я понимаю список распознаваемых артефактов, можно его как то распарсить и посмотреть что в нем хранится? Причем очень желательно чтобы кто-то из тех, кто собирает сорцы Чн/ЗП поделились результатом для сравнения. Надо же как то понять, почему лист в итоге пуст. Мб я что-то упускаю.

Вот и именно здесь что-то идёт не так. Из метода load: shared_str item_sect = pSettings->r_string(sect,temp); Как я понял, здесь item_sect должен быть значением ключа af_class_1 и т.д. Ну то есть: af_class_1 = af_cristall Получается, item_sect == "af_cristall"? Если я выведу на этом моменте в лог это значение: Msg("Видимо секция: %s", item_sect); то в лог падают бессмысленные буквы (чаще всего "X" или "Y") Опытным путём выяснил, что наиболее вероятно shared_str это же не строка? (Ну да, с C++ у меня сильно не очень ) Потому некорректно выводится. Потому как LPCSTR item_sect = pSettings->r_string(sect,temp); Исправно выводит именно секцию. К чему я это всё, я не понимаю, почему оно у меня не работает? Я понимаю, что так с наскоку сказать скорее всего сложно, но мб я не вижу чего-то очевидного?

DoK74rus, обычно статику вырезают, а тот вон оно как)--- Кто разбирался с детекторами в ЗП/ЧН? if(m_artefacts.m_ItemInfos.size()==0) return; Вот где этот лист формируется и наполняется артефактами? Никак не могу понять.

UriZzz это нужно в исходниках поправить и снова собрать. Или в конфиге просто отодвинуть за пределы экрана куда-нибудь.

Сборка исходников и редактирование загрузочных экранов. Но, если нет желания сидеть на 7 патче, можете не заморачиваться. Исходники, которые Вы, возможно, соберете, это ни что иное, как 1.0007 RC