Полтергейст

Ничто не мешает сделать эти функции под другими именами. Оставить оригинальный r_float, а добавить не вылетающий r_float_safe.

Для скриптовых вызовов это полезно, но что будет, если подобное произойдёт при чтении параметров движком из system.ltx?

Как мне кажется, просто сами себя переиграли. Вынесли class "gulag" отдельно, чтобы в него написать всё, что необходимо для работы одного type. Предполагалось, что smart_terrain : gulag - это один ко многим. Зачем-то стали писать алгоритмы распределения работ в этот самый xr_gulag.gulag (хотя надо было в сам smart_terrain), и в итоге намудрили так, что не осилили свою же начальную идею "многогулаговости". Вероятно, планировалось как-то так: но получилось то, что получилось.

Там большая часть с оригинала, соответственно, многие глюкобаги остались. Smart_terrain создавался для двух целей: во-первых, для назначения логики всем приходящим NPC во-вторых, для того, чтобы работало передвижение в оффлайне в соответствии с этой логикой. Без smart_terrain в оригинальном движке оно не работает совсем, а с ним - только частично (к первой точке пути). В оригинальном варианте, с одной стороны, много всего лишнего, а с другой - нет того, чего надо. Лишнее - это добавление рангов за посещение smart_terrain, обращения к sim_statistics при вызове (un)register_npc, чтение capacity из custom_data, сохранение npc_info, эксклюзивности и работ в самих объектах smart_terrain, всякий хлам вроде idle_after_death вместо нормального освобождения работ при вызове серверного колбека on_death. Тормозной алгоритм назначения смартов для эксклюзивных npc вместо обработки в функциях se_stalker/se_monster:update списка смартов, прописанных в customdata в секции smart_terrains. Какой-то совершенно непонятный критерий выбора смартов неэксклюзивными NPC, потенциально способный привести к слишком частой смене смартов. Не хватает изменяемого type (через запятую список секций, затем в каждой секции параметр-condlist), динамического списка разрешенных группировок (который можно реализовать через смену type), Также не помешало бы изменить способ хранения работ и соответствющих им объектов в таблице Job. Вместо Job[number] могло бы быть что-то вроде Job[section][number].

smart_terrain я пытался переписывать. Многократное заполнение npc_info, малопонятные алгоритмы распределения работ и сохранение работ не там, где надо - это только то, что на поверхности. Если копать глубже, там целый ворох проблем, связанных с особенностями передвижения NPC. Там и move_mgr придётся сильно дописывать, и xr_logic править, и много что ещё. Для полной синхронизации онлайн/оффлайн надо вообще в движок лезть. И по-хорошему, надо читать параметр type как несколько разделённых запятыми строк, а не как одну. Чтобы, как и задумывалось изначально, можно было не плодить дубли смартов (на подобии esc_fabrika_bandit и esc2_st_fabric), а просто при выдаче infoportion перейти от одного типа к другому. Это намного удобнее, чем все эти номерные состояния, работающие черте как. Ко всему прочему, для улучшения производительности при загрузке игры надо переписывать файлы gulag_***.script и делать склейку строк через table.concat.

В том же файле (stalker_movement_manager.cpp) есть строки, приводящие к вылету при недоступности пути. По-хорошему в этой ситуации лучше просто сбрасывать путь и вызывать скриптовый callback, оповещающий об этом. Что именно не доделано?

В файле stalker_movement_manager.cpp есть такие строки VERIFY ((m_target.m_mental_state != eMentalStateFree) || (m_target.m_body_state != eBodyStateCrouch)); ... VERIFY2 ((m_current.m_mental_state != eMentalStateFree) || m_current.m_body_state != eBodyStateCrouch,*object().cName()); они приводят к вылету, который возникает при попытке вызвать game_obj:set_mental_state(anim.free) game_obj:set_body_state(move.crouch) По идее, если их закомментировать, вылет может исчезнуть. Но вместо него могут появиться другие ошибки.

Конфиг нужен, но не отдельно для каждого тайника, а для описания вероятностей и условий выпадания вещей - распределение по уровням, группировкам, рангам и прочим параметрам. Ну и конечно же condlist'ы с проверками на глобальные infoportion'ы. И весь "менеджер" должен только считать всё это из конфига и проверять вероятности при каждом шмоне. Остальное - не нужно. Сохранение выданности/невыданности не нужно даже в оригинале, т.к. метка на объекте УЖЕ сохраняется. Достаточно проверить наличие отметки на карте - это и будет "выданностью". Если при "заглядывании" снимать метку всегда, то и второй параметр сохранять не нужно. А без них обоих и u16 вообще не нужен. Такая вот экономия.

Можно сделать постоянный вызов функции проверки на враждебность (типа enemy_callback) и сделать в ней проверку на combat_ignore (читать combat_ignore_cond из активной секции и секции логики) - так просто привычнее. Дополнительно к этому указывать группировку-владелец.

Если делать как следует, то все условия выдачи тайников лучше хранить в customdata самих тайников. И тогда можно хранить как в оригинале, только отвалится target за ненадобностью. Только работать это будет в тех случаях, когда и серверный и клиентский класс тайника экспортирован из движка. Параметры active и done дублируют друг друга с незначительными изменениями, можно оставить только один из них. А его уже определять по наличию метки (mapspot), чтобы не забивать сейвы ерундой.

Прямо так взять и вызвать on_death у "убиваемого" серверного объекта. Перед этим желательно установить ему здоровье в 0 через update-пакет, но вроде как не обязательно.

abramcumner, я уже разобрался. Работать будет, т.к. в этом же классе делается smart_cast из CObject в CInventoryItem напрямую. Вообще в клиентских классах приведение типов как-то странно используется. Например, в net_Spawn можно увидеть приведение типа к самому себе. Нашёл один баг, связанный с записью killer_id и game_death_time в серверные объекты. В существующем варианте она делается через клиентский класс CEntity, то есть только тогда, когда объект в онлайне. Если же серверный коллбек on_death вызывается в оффлайне, то ничего не записывается. Намного лучше было бы дописать такой метод и вырезать из класса CEntity целую кучу кода, которая отвечает за то же самое. Оставить можно разве что смену модели на corpse_visual, но если благодаря правкам будет (или уже) реализована смена модели из скрипта, то и это не имеет смысла.

Капрал Хикс, в se_monster.script надо убрать в can_switch_online (offline) зависимость от времени суток.

Zander_driver Всё это так ровно до тех пор, пока не заполнена правая часть (после знака равенства). Как только потребуется отличить infoportion от вызова функции - появятся спецсимволы. Когда надо будет передать параметры - спецсимволов станет больше. А ещё понадобятся логические операторы and, or, not - их тоже как-то надо будет записывать, и это тоже будут спецсимволы. А если нет, то легче писать прямо lua-кодом без квадратных скобок.Nazgool, от повторных проверок можно избавиться при помощи запоминания результатов в пределах одной проверки condlist'а. И для этого не надо менять синтаксис.

Раскопал в исходниках одну особенность. Для монстров можно индивидуально переопределить некоторые параметры, читаемые из их секций в system_ini. Делается это при помощи добавления секции "settings_overrides" в customdata. Можно добавлять следующие параметры: Они будут перекрывать те параметры, которые пишутся в секциях монстров. Возможно, подобное есть и для других типов объектов, но я пока не нашёл.

Возник вопрос насчёт использования smart_cast. Если ли заменить такую конструкцию CGameObject *GO = smart_cast CGameObject*(O); CInventoryItem *pIItem = smart_cast CInventoryItem*(GO);на CInventoryItem *pIItem = smart_cast CInventoryItem* (O);будет ли оно работать? Видно, что 2 строки идут подряд и существование объекта O не проверяется, и он дальше нигде не используется. Может это надо для самого smart_cast?Код взят из метода CBaseMonster::OnEvent. P.S. угловые скобки после smart_cast "съелись" форумным парсером.

Dennis_Chikin А что тогда читаемо? Нет, ну можно конечно прямо в spawn_ini вшивать Lua-код, а потом запускать через loadstring. Тоже вариант. Только чем-то надо заменять знак = и квадратные скобки, т.к. уже используются в синтаксисе ini-файлов, а также ввести дополнительные правила и ограничения. Но я просто не представляю, как всё это будет уживаться со старым вариантом.

Попытался найти в исходниках что-нибудь по этой проблеме http://www.amk-team.ru/forum/index.php?showtopic=6185&page=276#5505 но так и не понял, чем она может вызываться. transfer_enemy работает только между монстрами (причём это определяется явно не по строке species), а CHitMemoryManager я не вижу передачи информации о хитах другим игровым объектам. И куда тут копать?

abramcumner Квадратные скобки уже заняты. Не забываем про секции ini-файлов.

Не работают.

Не знаю что случилось, но теперь форум открывается с другим дизайном. В результате - невозможно перейти на произвольную страницу темы. Только на первую, а потом листать вперед по одной.

А как можно на неё попасть? На самом форуме ссылок не нашёл.

abramcumner Да. Оно-то так, только сделать с этим вряд ли что-то можно. Оставлять как есть - значит дублировать условия или писать костыли. Менять на мой вариант - не всем понятно будет. Делать что-то совсем иное - будет проблемы с совместимостью. Остаётся только вводить новые спецсимволы для группировки действий, но почти все и так уже заняты, а именно ({},@%=!~:|). Можно попробовать ввести #, $, *, & или ?. & и * по понятным причинам лучше не использовать. Из оставшихся больше подходит ?. Вот как-то так это будет выглядеть: Но опять же, может быть что-то непонятно тем, кто пишет логику - новый вариант будет непривычен, а также начнутся проблемы с копипастой новых конструкций в моды со старыми скриптами.

Тогда так [logic] active = sr_tip@1 [sr_tip@1] cond = {+ataka_start} single = true name = сюда подставляем имя tips, которое используется внутри функции arhara_dialog.ataka_sms on_signal = tip_sended| sr_tip@2 [sr_tip@2] single = true timeout = 6000 name = сюда подставляем имя tips, которое используется внутри функции arhara_dialog.ataka2_sms on_signal = tip_sended| nil %+ataka2_start%

abramcumner В чём выражается "нечёткость" однострочной формы записи? Это обычное if-then-elseif-else, просто записанное с использованием спец. символов - скобок, процентов, двоеточий и +-=. То, что реализация её разбора кривовата - это уже проблемы этой реализации, а не самой формы записи. И кстати, если писать всё в виде action1 = condition1 - всё равно спецсимволы никуда не денутся. Может их будет чуть меньше, но не намного. Ну и что, не одно - так другое. Намного проще избавиться от дублирования, один раз подправив реализацию разбора condlist'ов, чем по сто раз писать костыли, которые будут обходить её недостатки. Ну тогда так: {=gulag_inactive(esc_lager) -esc_infop1} section1, {=gulag_inactive(esc_lager) +esc_infop1} section2