Malandrinus

@abramcumner, @Дизель, Полагаю потому, что тоже сочли потенциал его развития исчерпанным в его нынешнем виде. Впрочем, идея "переписать всё с нуля" на мой взгляд тоже неправильная. Это никогда не заканчивалось хорошо =) Так не о том и речь, а о возможности развития или хотя бы разумной модернизации. Я считаю, что в нынешнем виде - это инертная "несдвигаемая" глыба. Там подколупать, здесь поскоблить - это можно, а куда-то сдвинуть - нет. Про очереди сообщений и нетпакеты могу добавить ещё немного лирики. Я насчитал в движке что-то около четырёх или пяти очередей сообщений разного типа и бесчисленное множество разномастных самопальных систем для организации колбеков. Это к разговору об организации полноценной многоагентной системы и всего такого прочего. В первую очередь нужна унификация обмена информацией. Если уж использовать асинхронный обмен сообщениями, то на основе строго одного механизма (и это ни коем случае не должно быть уродство в духе нетпакетов!). Тоже самое касается системы колбеков (делегатов/ивентов/событий).

Предлагаю поговорить на общую тему, которую можно сформулировать примерно так: "каким должен быть движок X-Ray". Или возможно так: "Что бы я там изменил/возможное направление для развития". Для затравки предлагаю мысль. В текущем состоянии движок развитию не подлежит. Там что-то можно подкрутить, что-то поменять, но реально продвинуться невозможно. Тому есть несколько причин. Если попытаться их перечислить, то мне на ум приходят такие (уверен, что список далеко не полный): сетевая архитектура движка разные среды разработки (и в сущности разные языки) самого движка и SDK архитектура, основанная на dll, а не на статических библиотеках разные версии рендера абсолютная недокументированность кода Соответственно, любые перспективы хоть какого-то развития на мой взгляд подразумевают в первую очередь искоренение указанных причин. Ну вот начать хотя бы с сетевой архитектуры. Сколько из-за неё бед! Клиент-серверное взаимодействие создаёт только проблемы: по паре объектов на каждый реальный игровой, асинхронное взаимодействие со всеми последствиями, использование нетпакетов для загрузки/сохранения и для передачи сообщений, масса кода, который реально ничего не делает в сингле, но засоряет почти каждый модуль. В качестве наглядного примера последствий можно привести последовательность загрузки/создания игры. В сущности концептуально простая последовательность действий - загрузить уровень, загрузить алайф, загрузить в него спавн/сейв, вывести в онлайн объекты уровня - превращается в предельно мистическое действо из пересылки кучи сообщений с сервера на клиент и обратно, выполнением по шажку за раз с пересылкой подтверждения туда-сюда, ожиданием ответа на каждой стороне и т.п. При этом в сингле масса кода, который задействован в сетевой игре, не работает, но понять, что работает, а что нет, нереально. Отладку этого дела невозможно описать цензурными словами. Или использование нетпакетов для передачи сообщений. Понятно, что это исходно была сеть, и пакеты были собственно сетевыми пакетами. Но в сингле то сети нет, а пакеты остались, просто ходят через всякие очереди в памяти или даже во многих случаях (в частности от клиента к серверу) просто вызывается функция посылки сообщения, ей передаётся нетпакет с аргументами, этот нетпакет тут-же безо всяких очередей распаковывается и вызывается функция, которой эти аргументы передаются. Можно было бы для сингла просто вызвать оконечную функцию и передать ей эти аргументы, при этом было бы невозможно ошибиться с порядком распаковки. Даже для асинхронной передачи сообщений (как например от сервера к клиенту) в сингле можно было бы использовать нормальные очереди сообщений с типизированными параметрами. Это просто пара моментов, а их можно назвать ещё много. В общем, предлагаю высказаться на эту тему.

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

@KitkaT.Net, Делаю тест. В модуле test.script пишу такой сокращённый код: FILTERS_PLACE=nil function souls_died_armors_give_quest() FILTERS_PLACE = 1 end function searchingHeliJupiter() printf("FILTERS_PLACE= %s", FILTERS_PLACE) end Затем выполняю обе функции: test.souls_died_armors_give_quest() test.searchingHeliJupiter() В логе печатается "1", т.е. переменная прекрасно меняется. Только она не глобальная, а в модуле test.script.

Это какая-то ерунда. Приведи свой код.

Это файлы из разных проектов. xr_ioc_cmd.cpp из проекта экзешника, а actor.h - из xrGame. У проектов совершенно разные настройки по поиску включаемых файлов, да и вообще такое включение выглядит бессмыслицей, поскольку в проекте экзешника ничего и никому не известно о классах игровых объектов. Там максимум известны объекты сервера, клиента, ГУИ и т.п.

Это вопрос? Если вопрос, то ответ на него простой: а зачем? Есть уже реализованный способ, зачем делать что-то ещё? Геометрия худа принципиально не может взаимодействовать с геометрией уровня или объектами уровня. Это просто картинка, рисуемая на фоне всего остального. И возвращаясь к началу, а зачем это всё надо, если уже есть готовый способ нанесения хита? вот и было бы два класса: колёсная техника и гусеничная. Но ведь не надо при этом делать по отдельному классу на Запорожец, Ниву, БТР и т.д., не так ли? Вот с машинами разрабы сделали грамотно, создали общий класс, где есть в том числе и оружие, которое можно при необходимости заблокировать для конкретной секции. Эти завязки есть потому, что разрабы их сделали. При небольшом усилии вполне можно было бы сделать гибкую настройку, когда анимации вписываются конфигами произвольно, ненужные отключаются, ненужные фичи отключаются и т.д. Как например сделано с аддонами. Есть класс CWeaponMagazined для оружия без подствольника, но он совершенно не нужен. Можно взять класс CWeaponMagazinedWGrenade и заблокировать установку подствольника конфигом. Снайперскую винтовку вполне можно сделать на ровно том же классе CWeaponMagazinedWGrenade, попросту отключив все аддоны и отключив стрельбу очередями. Даже пистолет можно сделать на этом же классе, если не нужна затворная задержка. А потрудились бы разрабы сделать её опциональной у CWeaponMagazinedWGrenade, и вся линейка класса пистолета была бы не нужна. Дробовик тоже по-сути несложно было бы объединить со всем остальным, включая и стрельбу из двух стволов. Конечно, тогда можно было бы конфигами делать мутантов типа двустволки с прицелом и гранатомётом и стрельбой очередями, но это было бы уже на совести настройщика конкретного ствола. У меня есть стойкое ощущение, что ряд частей движка поручали людям по остаточному принципу. Вот оружие и GUI явно относятся к этой категории.

Хороший вопрос. Ответ на него: совершенно незачем иметь столько классов для оружия. Как минимум всё стреляющее обычными пулями можно было бы сделать на одном классе, слегка кастомизируемом конфигами (типа наличия затворной задержки или режима автоматического огня). Соответственно останется ещё пара-тройка классов для многоствольных агрегатов и всякой экзотики. А может и вовсе стоило бы сделать один универсальный класс с настройкой под конкретные параметры чисто конфигами. Проблема в том, что разрабы не делали платформу для разработки, а просто делали игру под свои нужды, поэтому вопросами оптимальности не затруднялись. Наверное стоило бы этим заняться, но для начала надо создать проект с собираемым движком и разобраться со многими другими сопутствующими проблемами. Я так понимаю, что если кто что и сделал, то застрял на втором этапе, так что до оружия руки не доходят =) Не совсем понимаю, что ты имеешь в виду, но вполне можно как минимум все автоматы перевести на один класс, скажем от АК, а на остальные забить. Пистолеты не получится, поскольку у автоматов нет затворной задержки. Нож внутри использует специальную пулю для нанесения хита. В этом есть свой смысл, поскольку не нужно отлаживать альтернативный механизм.

в XE есть функция для получения собеседника level.get_second_talker(). Но всё равно перед её использованием надо проверять, что идёт разговор.

На ТЧ нет функции use_ai_locations для установки, только для получения значения. Надо использовать нетпакеты. X-Ray extensions

@CRAZY_STALKER666, проблема при назначении SID нетпакетом в том, что он при этом не вписывается в глобальный реестр SIDов и соответственно не будет искаться функциями получения по SID и не будет работать в логике. В XE для прописывания SIDа была специальная функция, которая одновременно с назначением и регистрировала SID в реестре, а на ванильном движке вписанный скриптом SID не заработает до перезагрузки сейва.

Надо сразу после создания объекта и до выхода его в онлайн обнулить флаг серверного объекта use_ai_location.

@Nazgool, с точки зрения стандарта Lua запись nil в поле эквивалентно его удалению. Детали реализации могут отличаться, но это уже поведение стандартом никак не регламентируемое.

@IQDDD, На мой взгляд шейдеры здесь вообще ни при чём. Простой баланс фонового освещения и яркости солнца / источников света. Если убрать амбиент, который управляется из погоды + глобальная настройка из консоли, то как раз и будет абсолютно контрастная картинка: яркие пятна на совершенно чёрном фоне.

@Mr_God, по ссылке из шапки лежит книга «Программирование на языке Lua». Она на русском, и это не мануал, а именно что учебник, где всё разжёвано до предела. Читай эту книгу. Ничего лучше нет. Если есть конкретные вопросы, попробуй задать их здесь.

Что именно не читаемо и не понимаемо?

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

Используй консольную команду hud_fov. Обычно стоит 0.4. Если увеличиваешь общий fov (команда cam_fov или из конфигуратора), то hud_fov надо уменьшать. Тогда руки не будут вылезать. Не знаю, где ты здесь увидел "luxury" движок, и в упор не понимаю, каким образом анимации рук (неважно нравятся они тебе или нет) превращают игру в пошаговый квест.

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

Большинство неписей получают логику из гулага. Бандиты на АТП очевидно в гулаге.

Скрипты вполне стандартные. Просто поле death в хранилище непися появляется только если в логике присутствует секция on_death и соответственно срабатывает схема xr_death. В остальных случаях этого поля нет. pstor - это не альтернатива хранилищу непися. Это просто разные вещи для разных нужд. Хранилище (storage) хранит данные во время игры. В pstor мы записываем данные для сохранения в сейве и оттуда их извлекаем при загрузке (и возможно пишем в хранилище, чтобы дальше использовать в игре).

Наверное таки придётся. Добавить пару строчек в колбеке биндера и не забыть это сохранить в pstor непися.

@gameshark, без правок вряд ли выйдет. Переспавном в принципе можно сменить ствол (хотя это в целом весьма геморройно), но ещё остаётся проблема бинда клавиши. Да и даже если предположить, что удастся повесить операцию на клавишу. Переспавн ствола - это значит он будет исчезать по нажатию, появляться в руках заново после паузы. И это каждый раз всего лишь при необходимости сменить тип прицеливания.

Вертолёт вообще-то и должен быть инерционным. Даже ствол пулемёта мгновенно не развернуть, а уж многотонную машину и подавно. Ты в авиасимуляторы играл? Был у меня в бытность мою преподом в Питере один студент, который ваял программы под винду на ассемблере. Именно что целиком, а не просто вставочки в СИ-код. Я видел, как это выглядело в его исполнении. Куча макросов для вызовов API, фактически СИ-образный код (из-за обилия макросов), отладка в средневековом стиле. Это было конечно интересно, но крайне непродуктивно. Неужели действительно настолько сложно освоить С/С++ ? Это повысит производительность разработки на порядок. Любые временные вложения в обучение окупятся многократно.

@Fagot., на чистом движке это проблематично. С правками можно. Там есть функция для получения предмета с пояса и также колбек на появление предмета на поясе.