dsh

@Kirgudu, выглядит вроде нормально, только я бы вместо вот этого изменения - pk:w_stringZ(val:getString()) --/< from helpers + if val:useStringRaw() then + pk:w_stringZ(val:getStringRaw()) --/< from helpers + else + pk:w_stringZ(val:getString()) --/< from helpers + end эту проверку бы делал в getString() function custom_data:getString() return self:useStringRaw() and self:getStringRaw() or _fill_custom_data(self.data) --/> end Мне кажется, что это внутреннее дело custom_data и другим знать об этом не обязательно.

@Kirgudu, да, что-то такое мне и виделось. Другой вариант, это хранить в свойствах сырую строку и в нетпакет всегда записывать ее, а getString() и getTable() бы ее парсили налету и возвращали бы результат, как это есть сейчас. setString() и setTable() бы делали обратную операцию и меняли бы сохраненную сырую строку. Этот вариант мне кажется хоть и более красивым, но более сложным, а значит и более вероятно появление новых граблей, по которым кому-то придется пройти и исправить. Т.ч. я за более простой вариант.

@Kirgudu, это не то. Когда я писал, то имел ввиду, что для некоторых случаев может понадобиться доступ к сырой строке. Ну вот как в моем примере, все в ini, а для контейнеров используется свой формат. Эта же опция переключает поведение глобально. По хорошему, там бы добавить методы :getStringRaw() и :setStringRaw() или что-то вроде того.

@Graff46, вопрос не понятен. Что если логика?

@Graff46, в совершенно любом. К примеру, в соляночных (в старой солянке) контейнерах артефактов все данные хранятся одной строкой. Просто строкой, секции артефактов через запятую.

Я не говорю, что сложно. Просто человеку, который только собирается использовать m_netpk, лучше об этом знать заранее, а то захочет прочитать custom data, в которой данные не в формате ini, и будет голову ломать, чего же ему :getString() возвращает пустую строку.

По моим ощущениям, m_netpk сделан, как минимум, с учетом скрипта от xstream. Много похожего.

@Graff46,соглашусь. m_netpk работает. Я использовал и m_net_utils и еще какой-то скрипт от xstream. В принципе все работают. Сейчас использую m_netpk. Единственное, если ты иногда захочешь в custom data писать данные не в формате ini, то m_netpk на это не рассчитан. Но в этом случае я бы посоветовал пересмотреть свои желания.

в string.format() был передан формат с двумя плейсхолдерами, а последующий аргумент был передан только один. Даже могу точно сказать, что второй плейсхолдер был "%s".

Ну не знаю. У меня работает и не в одном месте. А у тебя неработа выражается в чем? Это были примеры для размышлений, а не для копи-пасты. На твоем компьютере, кроме тебя, это никто отладить не сможет. Ну, из самого очевидного, есть ли у тебя get_netpk() и ASSERT()?

Вот рабочий пример local obj = dsh.create_free_npc( "mil_trader_gavr", vector():set( 25.325489, -8.35158157, -17.512226425 ), 330707, 1587 ) alife():assign_story_id( nil, nil, obj.id, 9623 ) Ну элементарно же, какие там примеры. Ну вот, например: local sobj = dsh.create_free_mob( "gar_stalker_flame_quest23", vector():set( 24.86, 0.40, 209.75 ), 198510, 359 ) local pk = get_netpk( sobj, 1 ) ASSERT( pk:isOk(), "can't read netpacket of %s", sobj:name() ) local data = pk:get() data.custom_data:setString( "[smart_terrains]\n" .. "none = true\n" .. "[logic]\n" .. "active = walker\ncombat_ignore = combat_ignore\n" .. "[walker]\n" .. "path_walk = garb_tambovski_path\npath_look = garb_tambovski_look\non_info = {+find_815} nil\ncombat_ignore_cond = {=dist_to_enemy_ge(15)}\n" ) data.story_id = story_ids.gar_stalker_flame_quest23 pk:set( data ) level.map_add_object_spot_ser( sobj.id, "green_location", "Лёха Тамбовский" ) Вот это вот "data.story_id" - оно самое.

И через нетпакет можно, и соотв. методом, если используется x-ray extensions. Хотя с тем методом есть свои подводные камни, на которые я наступал. Через нетпакет надежней как-то.

@TIGER_VLAD, ну естественно скорость зависит от фпс, т.е. от частоты выполнения апдейта. Ведь ты же на каждом апдейте меняешь позицию. Умножай дельту на кол-во секунд, прошедших с прошлого апдейта, что-ли. Текущее время в миллисекундах возвращает time_global(). На каждом апдейте его сохрани, вычти из него предыдущее значение, раздели на кол-во миллисекунд в секунде и умножь на дельту. В этом случае, дельтой будет задаваться скорость в секунду реального времени. Как-то так.

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

Это у тебя ошибка ОП-2, которая была признана на официальном форуме, как не существующая. Аж целый консилиум такое решение вынес. А если серьезно, то сними с пояса детектор артефактов и всегда его снимай в подземках, во избежании этого вылета.

@Тишь, это устаревшая информация. Актуальная вот тут вот: https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/config/weapons/weapons.ltx в самом начале k_pierce - это не бронебойность. Это коэффициент пробития препятствий, т.е. стен, деревьев, ворот и т.п.

@Marafon6540, квиксейв не взлетит. Он там делается консольной командой ogse_quicksave, если я правильно помню написание.

@Graff46, вот тут вот https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/scripts/xrs_battle_ai.script скриптовое поведение неписей во время боя из OGSE. Покопайся, найдешь что-то для себя. За стрельбу, в частности, там заведует функция set_weapon_fire(), а заставляет стрелять она с помощью такой вот функции (пример) npc:set_item( object.fire1, wpn, 5, 200 )

@Graff46, в state_mgr_direction.script посмотри использование set_sight()

@Kondr48, как мне кажется, гораздо более нужным сначала найти ответ на вопрос "а зачем?". Ответы "что бы было" или "потому, что могу" - не самые лучшие для игры, как мне кажется.

А. Читал, что вроде так в ЧН и ЗП сделано. В ТЧ-то все по настоящему, препятствие есть препятствие. Так это просто пример был. Хотя в OGSE, например, именно в bip01_head целятся в основном. У меня рандомно, но в основном в грудь, с запоминанием кости для прицеливания и сменой ее через 10 секунд. Если только в грудь заставлять неписей стрелять, то слишком читерно будет. Актор-то, когда из укрытия стреляет, как раз грудь имеет защищеной укрытием, а вот голова всегда на виду, он через нее целится. Т.ч. в голову тоже нужно стрелять.

Не знаю, кто там с плеча косит, а я и через оптику-то не сразу попадаю. Но тут надо добавить, что у меня и оптика не такая, как в некоторых других модах. Кратности другие, хоть и написано, что 4-x кратное. Но по настоящему 4-х кратное для этих расстояние слишком много. В каком смысле работает? В этом случае неписям в единственный высунувшийся глаз трудно попасть. Они в основном в препятствие попадают. Тут надо понимать, как происходит попадание. Возьмем движковую стрельбу. Косость неписей задается несколькими параметрами, но все они - углы. Отсюда получаем этакий конус, внутри которого летят пульки. А чем дальше актор, тем конус получается шире и на больших расстояниях неписи могут попасть уже только чудом. Если стоять на пригорке у ДН и ждать, когда попадут военные от блокпоста, то можно и не дождаться. Если эти коэффициент покрутить, то можно добить попаданий, на опять-таки, на этом расстоянии, а если дальше, то начинай сначала. Да и в этом случае на меньшем расстоянии будет просто туши свет. Будет уже чудом, если промажут. Если неписи стреляют по приказу скрипта, который их нацелил, тут уже может быть по другому. Например в огсешной системе, косость неписей задается радиусом от точки прицеливания. И это не зависит от расстояния, будь то 5 метров или 500, непись промажет от 0 до, скажем, 20 сантиметров, как рандом выпадет. В OGSE правда именно эта часть не работает, т.к. поломана, но починить не сложно. Т.ч. если отвечать на вопрос буквально, то неписи всегда рандомом попадают. А как еще? Тут либо абсолютная точность, нацелили в bip01_head, значит в хэд и попадет, либо рандом. Что тут третье может быть?

Не в курсе. Тогда глазкам будет больно. Я же все равно буду пытаться стрелять с максимального расстояния. И попаду, рано или поздно. Ты так пишешь, как будто СВД прямо таки обязана быть. Я вообще, к примеру, считаю, что эта Зона не для снайперских винтовок и ПП. Она исключительно для штурмовых винтовок, по совокупности качеств.

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

switch_distance никак не связан с дальность зрения неписей и их реакций. Это расстояние их выхода в онлайн и обратно, плюс-минус немножко. При этом ничто им не мешает видеть на 150 метров или вообще на 300, если там, в онлайне, будет то, на что им нужно реагировать. Одно не связано с другим. Скорость пули отдельно, расстояние, на котором пуля еще просчитывается движком - отдельно. Я не о том. В игре невозможно заметить разницу между 9x18 и 9x19, если не выпячивать эту разницу преувеличенно, как ты написал, на 30%. Но зачем? Пусть между ними и не будет разницы. Зачем что-то искусственно гипертрофировать.