нет камеру не двигал там вроде ищё чёта на до допиливать в исходниках

serg101188, смотри внимательно эти файлы - там зарыта камера.
Actor.cpp
ActorInput.cpp
actor_input_handler.cpp
Actor_Network.cpp
HUDCrosshair.cpp
Inventory.cpp
Weapon.cpp
weapon_dump_impl.cpp

jamakasi, согласен. но зачем нагружать сервер запросами если можно отключить у клиента ["sender.set_max_reports_per_day( 5 );"] - Breakpad, ресурсы не безграничные.

virus_ua, может найтись хитрая задница которая всеравно будет спамить.

jamakasi, ну это святое дело

jamakasi, поэтому предлагаю вообще не использовать. Всё равно спрос на движок в наше время весьма мал.

ну да ты прав перекинул камерубазу. появился худ оружия.. да и вопщем спасибо за ответ

Тут скорее не надо его вообще слать кудалибо а сейвить в папочку и по необходимости пользователь сам отправит дамп т.к. один фиг большая часть модоюзеров маломальски продвинута.
А вообще идеальный вариант такой:
1) Игра при краше выплевывает оконце как сейчас с инфой об ошибке. В нем краткая инфа и пометка был ли зафиксирован такой баг или нет и вариант открыть топик.
2) Есть некий форум\сайт где для каждого бага свой топик.
3) Каждый баг метится особым хэшом(вопрос на чьей стороне и по какому критерию).
4) Если пользователь нажал кнопку то открывается браузер с нужным топиком или страница создания такого топика.
5) В случае если баг уже есть то пользователь может почитать методы его решения, и инфу как он возникает. Сам пользователь может дописать последовательность действий при котором баг вылез.

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

Главное решить:
1) как маркировать схожие баги
2) Как приклеивать метаинфу(к примеру хэш геймдаты и бинарников) чтобы было понятно на какой версии он есть и была уверенности что это не юзверь буратино.

Не серьёзно. Зачем такой мод, если его надо править юзеру. А если юзер начнёт править, то к тому юзеру, еще десяток более поф.юзеров надо.


Невозможно. Разный код, разные лог-баги. Я уже пару лет пытаюсь объяснить, что по строке вылета нельзя идентифицировать ошибку. Строки везде разные.
Маркировать только в новом движке можно, прописывая заново идентификатор в исходники.

Всё, что сделано ранее - это не серьёзно и не правильно.

У нас тут речь о баг-репорте движка, а не моде.


У нас тут речь о баг-репорте движка, а не моде.

Forser, есть в движке безлоговые вылеты - вот ими и надо заниматься.

А в остальном - того достаточно, что есть.

Да что ты говоришь?

А сталкир умеет высчитывать crc для архивов .db?

Я пользуюсь июльским 2016 перехватчиком от alpet, ничего лучше в плане отлова ошибок я не встречал. Все эти баг-трапы и иже с ними - даже близко рядом с ним не стояли.
Одно плохо, его приспособить к движку непросто, требуется значительная переделка xrDebugNew.cpp и не только.

Zagolski, дебаггер студии ванлав.

Ошибки в скриптах тоже студией отлавливаешь?

Zagolski, со скриптами не работаю сейчас.

RedPython, ну... Собсна, crc32 высчитывать умеет. Если не умеет высчитывать для архивов, думаю, несложно будет прикрутить считалочку для архивов..

А что конкретно делает этот перехватчик? Отладчик скриптов у сталкера родной есть - xrScriptDbgIde. Функции для прямой работы с памятью в ЛУА это изврат.

Как что, ошибки показывает. Если скриптовые, то в каком скрипте в какой ф-ции или строке, а также всю предыдущую веретеницу вызовов, штук десять. А если движковая - то в каком срр на какой строке. Ну и в отдельной консоли всю работу отображает прямо на ходу, что очень удобно: в окне игру запустил, а рядом у тебя все процессы тут же отображаются. Я как-то после него багтрап использовал, когда с чистым ЗП двигом работал, так сразу остался как без рук и глаз...
Ну а более подробную информацию (как устроен и т.д.) может только сам alpet рассказать. Знаю только, что для его работы нужны в том числе .pdb и .map файлы движковых файлов.

Зачем alpet'а беспокоить, есть же исходники.
https://github.com/alpet83/Lua-Interceptor

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

jamakasi, нет моддинг форумов таких где можно было бы такое нормально организовать. единственное что можно сделать это либо отсылка в стиле "отправьте в наш топик", что на самом деле не удобно (директ деливери ту деверлопер - лучше), хотя и дискассы тоже нужны ибо юзеры иногда решают проблемы быстрее чем разрабы. А про хеш геймдаты мысль интересная [проверять я ее конечно не буду ] ибо это отсеит часть % вылетов, которые не относятся к основе проекта.

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

Лучше бы сделали условия для создания скелетной анимации траков (починить плагин, увеличить макс. кол-во костей до 100500, сделать так, чтобы двиг жрал модели по 50тыс поликов...). 2018 год на носу всё-таки, пора бы уже забыть про анимированные текстурки.

Чтобы видеокарта подавилась шейдерными регистрами при скиннинге


Если бы сталкеру это было необходимо, то давно бы сделали. А так, вряд ли кому-то это надо.

Зато каааак крууууто будет смотреться летящая по ухабам бмп
84 трака, хотя бы по одной кости на пару — и то нужно больше 64 костей в скелете...

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

100 костей потянет даже на dx9.


Мелко берешь. Нужен авианосец в пруду-охладителе около ЧАЭС.

А что если софтварный скиннинг использовать? Правда в ЧН/ЗП там что-то сломали, СДК тормозит.

Была ещё идея посадить кровососа на мотоцикл

Кто-нибудь бодался с date_time.cpp?
У меня пока черновой вариант такой: https://github.com/ForserX/FRay-Project/blo...e/date_time.cpp

С "data_time.cpp" не "бодался", но с некоторой скриптовой конвертацией "бодался"...
Скрипт, описание.

7.9, меня интересует чисто исходник по данной теме. Мой вариант не конечный, но читабельный, в отличие от варианта Ясеньева(или как там у Dima фамилия)

Вот это он и тормозит ))
Если без шуток, игра не взлетит с ним все-таки. СДК-то использует потому, что там забили нормальный рендеринг делать в какой-то момент.
А все эти ограничения по регистрам есть только на DX9 (да и то - куда больше 100 костей-то). На DX10+ есть константные буферы и нет проблем.

Forser, первое правило программиста - "работает - не трогай".

virus_ua, я не программист, так что: плевать я хотел.

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

Похоже некто реализовал линзу прицела в ТЧ:

Я имел ввиду по скорости. Ты в Баре сравни фпс при включении софтварного и хардварного скиннинга.


Это где такие модели в сталкире, что не хватает регистров? Есть ли реальный пример, а не "в принципе, предусмотрено"?

В Зове Припяти заспаунил 30 сталкеров, с r1_software_skinning 1 фпс 20-25, с r1_software_skinning 0 фпс 45-50.
Я думаю один танк должно потянуть в случае чего.


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

ФПС вдвое упал. Т.е., не взлетает.


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

Так это же сталкеры с 3-мя а то и 4-мя костями на вершину, с танком всё должно быть гораздо лучше.


Для vs_2_0 нужно минимум 256 регистров, а для vs_1_1 96. Первый рендер использует первую шейдерную модель, я напомню.

Разговор интересный, но вопрос такой: кто-то расширял лимит? Если да, в какой стороне смотреть?

КД же все написал. Регистры/шейдеры пока можно не трогать - их еще на пару десятков костей хватит и так.
Можно начать с маски видимости костей. Вот там действительно лимит 64. Поменять на какой-нибудь стд::битсет и тому подобное.

Ну и если что, модели пока не выбрали лимит и в 64 кости.

Вообще где-нибудь гусеницы на костях делаются? Это же тупо, тем более в 2017

У меня аниматору нужно 72 кости для нового скелета НПС.


Ладно, поищу.

Для игор других способов анимировать подобные вещи вроде как и нет. Вот в майе да, можно и голый меш анимировать, и симуляцию с любой физикой сделать (физикс, буллет/дмм)

Ну не знаю... Кости цепляешь к каткам, физикой обсчитываешь как они шевелятся, а траки наматываешь на них в шейдерах с натяжением/провисанием и прочим, что там у них бывает.

Слишком сложно, во всех играх делают в разы проще и красивее. Реализуют curves, по этим курвам пускают движение модели трака. Курву деформируют по привязке к "колесам" в гусенице снизу(часть которая касается к земле) а верхняя тупо по 1 кости с тяжестью. Чтобы лучше понять как это вылядит посмотри ролик ниже с 5:20

Да, нет. Делают еще проще: рисуют овал, а потом рисуют остальную часть гусеницы.

объясните плиз, или подскажите литературу дабы я смог сам понять - добавил я новое поле в Actor.h , сделал его публичным, далее мне нужно поменять его значение в actor_communication.cpp в функции bool CActor::OnReceiveInfo(shared_str info_id) const. Хеадер подключен, но насколько я понимаю у меня не получается ничего использовать из класса актора внутри CActor::OnReceiveInfo из-за того что в конце функции написано "const". Что мне в этом случае делать?)
В голову приходит только убрать const