dsh

@Х_и_м_и_к, попробуй так, грубо, без подробностей. Берешь клиентский объект каждого непися, берешь его физическую оболочку и прикладываешь к ней нужную тебе силу, в нужном направлении. Или, если нужно их как-то кувырком раскидать, берешь нужную кость и так же прикладываешь силу. Физическая оболочка получается вот так: obj:get_physics_shell() Кость, к которой можно силу приложить, получается вот так: obj:get_physic_shell():get_element_by_bone_name( "bip01_head" ) Сила прилагается вот так :apply_force( x, y, z ) Это метод полученной оболочки или элемента кости. Параметры - сила по соотв. оси.

@HellRatz, я в исходниках не докопался, по какому признаку определяется, какой предмет подбирать, а какой нет. Все, что понял, что подбираться будет инвентарный предмет и чем дороже, тем вероятнее. Еще эту схему можно разрешать и запрещать, как любую другую схему поведения. В некоторых скриптах это делается, в xr_wounded к примеру и в state_mgr.

Я наверное слоупок. Узнал, что сталкеры могут подбирать то, что плохо лежит, не только под управлением watcher_act.script, но и под движковым управлением. Есть там соответствующая схема поведения. Да еще как подбирать, со свистом. Кто играл в Солянку, могут вспомнить гаусс-пистолет в ТД. Естественно, никакие скриптовые исключения на это дело не действуют. Я нашел единственный способ, как уберечь предмет от этих хапуг. В его нетпакете нужно сбросить флаг flUsefulForAI: function clear_useful_for_ai( sobj ) local pk = get_netpk( sobj, 1 ) ASSERT( ( pk and pk:isOk() ), "can't read netpacket of %s", sobj:name() ) local data = pk:get() data.object_flags = bit_and( data.object_flags, bit_not( object_flags.UsefulForAI ) ) pk:set( data ) end И делать это нужно до того, как предмет выйдет в онлайн, т.к. этот флаг копируется в клиентский объект.

В OGSE есть одна ошибочка смешная в боевом скрипте. Найди в xrs_battle_ai.script вот эту функцию:

@ed_rez, вот поправленная логика Павлика: https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/config/dsh/logic/mil_freedom_member0001.ltx Сейчас пишу по памяти. Здесь добавлено "После того, как Ара скажет "посмотрим, что ты нам ; принес", становится врагом." несмотря на то, видел Павлик актора или не видел. Далее, раз у нас Павлик предатель, то будет не просто становиться врагом для актора, но менять группировку на наемники. Ну и что касается функции killactor(), которая используется в этой логике, что бы сделать непися врагом для актора. У меня в game_relations.ltx вот такие константы для этого дела: goodwill_enemy = -9000 goodwill_neutal = 0 goodwill_friend = 2000 Что бы уж если враг, так точно враг. К этому еще полезно вот такое иметь [action_points] personal_goodwill_limits = -9000, 9000 community_goodwill_limits = -9000, 5000 что бы отношение группировки никогда не перевешивало персональное отношение. А то с теми параметрами, что там были до этого, Павлик станет нейтралом в лучшем случае или так и останется другом, т.к. на тот момент никто не поручится, что у актора не заработано отношение со Свободой тысяч так 4 или 5.

@Dennis_Chikin, в процессе отладки у меня сложилось стойкое впечатление, что это движок его туда-сюда пинал, почему-то. Вот нутром чую, никто его скриптово не отвлекал. И даже если бы кто-то и мешал и отвлекал, почему две добавленных строчки его тут же в чувство привели? Ответа я наверное не найду.

Почему не сможет? Там ничего особенного. К примеру, я этот момент выправил без труда. Доберусь до компьютера, покажу.

Кто разбирается в патрульных путях, расскажите пожалуйста. Вот есть непись, есть у него путь из четырех точек. Бежит он значит от точки 0 к точке 1. И тут бац, на пол-пути разворачивается и бежит обратно к точке 0. Добежал, разворачивается и снова бежит к точке 1. И тут бац... Ну в общем вы поняли. И так до бесконечности. В округе ни одной аномалии нет. Лезу в move_mgr.script и вставляют отладочный вывод в extrapolate_callback(). Вижу, что он разворачивается и бежит обратно сразу после срабатывания этого коллбека. Бежит к точке 1, срабатывает на полпути коллбек, в нем self.object:get_current_point_index() возвращает 0. Ладно, непонятно. Но не в первый раз. Добавляю в этот коллбек вот такие две строчки self.object:set_start_point(self.current_point_index) self.object:set_patrol_path(self.path_walk, patrol.next, patrol.continue, true) и все чудеса исчезают. Непись бежит, как положено. Нигде не останавливается и никуда не разворачивается. Исправно добежал до конца пути и продолжил свою логику. Вопрос. Вот это я фигню какую-то добавил или нормальный костыль?

@Dennis_Chikin, ты какими-то загадками говоришь или с кем-то другим. У меня тоже есть такая картинка: https://yadi.sk/i/bGpoGx2u3Ehscv И что в ней такого?

@losiara, так закомментируй set_character_community() и будет он у тебя оставаться в своей группировке

@Капрал Хикс, там просто переопределяются "cond" смартов из all.spawn. Ты можешь сделать это в all.spawn и получится тоже самое. Смысл большинство переопределений в том, что бы в определенные моменты выключать/включать определенные смарты, что бы одновременно на локации находилось меньше народа. Когда они все там - начинается лагодром. А некоторые смарты, большинство wave к примеру, вообще выключаются после первого прохода по локации, т.к. далее они бессмысленны. Ну какой смысл во всей этой толпе, которая бесконечно сидит на крышах и стреляет. Другие смарты с помощью проверок в cond включаются попеременно. Т.е. если на входе у нас имеются сталкеры, значит за углом не будет монолитовцев и наоборот и т.д. Ну и отдельно у меня рейды выключены для этих смартов, когда те же сталкеры в начале локации ломятся вперед, снова и снова. Ну не в петле времени же они живут. Да и нехорошо это. Я иду за ними и подбираю лут. Двойная выгода, и лут наберу на продажу и врагов они всех выкосят. Нехорошо.

@Капрал Хикс, ну вот глянь, что у меня там изменено: https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/config/dsh/l11_pripyat.ltx По названиям думаю разберешься и cond-ишены поймешь. Сразу другое дело, а не бессмысленно и беспощадно.

@Dennis_Chikin, правильно не веришь. 0.3 от центра - это все тот же вертекс, т.ч. туда ни одного не посадить. Тем более, что в случае костра он накрыт аномалией костра, в которую сталкерам низя. Да и про 0.3 - это ты написал. Я на числах не зациклен и мне нужно, что бы сталкеры сидели около костра равномерно, не слишком близко и не слишком далеко. А будет это от центра 1.5, 2 или 2.5 - не имеет значения.

@Romann, я же не зря написал про голову. Приложить голову - это означает переделать xr_kamp. Но для нормальной рассадки пути не обязательны. Собственно говоря, пути - это всего-лишь еще один способ расчета вертексов, куда посадить сталкеров. Можно для каждого костра сделать конфиг и там, через запятую написать вертексы. Это будет тоже самое. А можно просто рассчитать. И это даст такой же результат, но будет гибче. В том, что у тебя, оригинальный расчет, который так себе. Вот тут переделанный расчет: https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/scripts/xr_kamp.script

Избавление от лютого и бешеного поиска по карманам особого смысла не имеет. Я вчера замерял - это примерно 20 микросекунд на одного сталкера. Не стоит эта овчинка выделки. Если только из любви к искусству. И кстати, то, что ты вот тут понаписал, тоже особого смысла не имеет. Рассадить сталкеров вокруг костра - это не рокет сайнс. Все там нормально рассаживается и все там нормально сидят, если голову приложить.

@UriZzz, ничего странного, x-ray extentions - это бинарные врезки в движок, а 1.0007 - это модифицированные исходники. Во втором случае все проще, чем в первом. Про ПДА ничего сказать не могу.

@UriZzz, насколько я в курсе, в x-ray extensions равноценные оружейные слоты не реализованы. Это можно и сделано кое-где скриптово, с использованием возможностей x-ray extensions.

@ed_rez, это в рамках x-ray extensions сделано. Т.ч. патч движок и используй настоящую кратность. Ну или возьми целиком из OGSE bin.

Тоже самое хотел пару дней назад написать, да как обычно подумал: а кому это надо. По этой причине все эти модульные системы я считаю бессмысленными. Фичи ради фич. Воздух только процессором нагружать, да увеличивать энтропию вселенной.

@AndrewMor, подойдут, чего же не подойти. Это если какие-нибудь проверки делать, типа а существует-ли такой левел вертекс, который есть у этого обьекта на другой локации.

@AndrewMor, имей ввиду, что если эти функции перебирают game vertex-ы и для каждого из них берут level vertex-ы, то они не весь диапазон level vertex-ов посчитают.

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

В x-ray extensions есть функция для получения вертекса из позиции на текущей локации. Если правильно помню, level.vertex_id(). Аргумент только ей передается нестандартно. Вот, добрался до компьютера: -- возвращает level_vertex_id по позиции на уровне function level.vertex_id_by_pos( position ) db.actor:set_vector_global_arg_1( position ) return level.vertex_id() end

@Dennis_Chikin, вообще, у этого бага есть и не читерская сторона. Если в подствольнике был второй тип гранат, то после загрузки сейва он превратится в первый тип, если заряжены патроны первого типа. Это обидно. Впрочем, я нашел способ, как это компенсировать без лишней нагрузки. Желающие могут посмотреть тут: https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/scripts/dsh_wpn.script в биндере оружия внизу и выше, где вызывается функция этого биндера, для обработки одного из вариантов этой проблемы. @aromatizer, тут дело не в том, оправдано несколько типов патронов или нет. Это второй вопрос. Движок - это основа. И если он позволяет иметь несколько типов патронов, то он обязан это правильно обрабатывать во всех случаях.

@Карлан, ну так приоткрой тайну, как основываясь на информации в том посте, поставить метку на произвольную позицию? Что из тебя вытягивать нужно. Хотел помочь, пиши полезную информацию. Или тебе покрасоваться в очередной раз?