dsh

@naxac, точно, это я невнимательно АЕК проверял. Великого ума был человек, наверное, который такое написал в движке. ...ть, ...ть, ...ть привычно ответило эхо. Я уже сел костылик написать, компенсирующий такое поведение, но в процессе его отладки понял, что сделать одновременно быстро и надежно не получается. Либо быстро для самого очевидного случая, но тогда куча способов обойти, либо все случае предусмотреть, но это доп. нагрузка. Вешать проверку на апдейт оружия я не согласный. Лишние тормоза из-за каких-то читеров мне даром не сдались.

@naxac, у меня тоже с ними была проблема. Плюнул и изменил условие задачи, не стал эти методы использовать.

Может кто уже разбирался и расскажет. Такая ситуация. Беру SIG550, на классе AK74. Цепляю к нему подствольник M203. В ammo_class три вида патронов, в grenade_class - тоже три. Заряжаю первым типом патронов, простыми 5.56. Переключаю на подствольник, заряжаю вторым типом гранат. Оставляя активным полствольник, делаю save/load. Переключаюсь с подствольника обратно на патроны и сиг заряжен уже не первыми типов патронов, а вторым, как был заряжен подствольник. Если проделать тоже самое с АЕК-971, который на том же классе AK74, но подствольник у него ГП и гранаты ВОГи (два типа) - ничего необычного не происходит. Вопрос. Что такого волшебного в M203 или в гранатах к нему, что такое происходит с СИГом, но не происходит с АЕКом?

Как мне кажется, для конечного пользователя вообще без разницы, что эти циферки значат. Важно для него только их сравнение. Т.е. вот он смотрит на два артефакта и видит, что у одного +20 здоровья, а у другого +100 и ясно ему, что второе лучше, чем первое. А в каких единицах все это... Да кого это интересует.

@ed_rez, ну, если каждый лезет менять тайм фактор - это уже ни в какие рамки. Вот кто лезет, тут и пусть разгребает. Если на это закладываться, тогда действие артефактов нужно в реальном времени делать, а не в игровом. Правда тогда нужно будет специальным образом сон обрабатывать.

@Kondr48, если менять, то я бы поменял только способ задания скоростей восстановления и т.п. Что бы не в абсолютных величинах задавать, как сейчас, а в процентах от соотв. параметров актора. Это упростит настройку и поддержку, что бы при изменении параметров актора не нужно было пересчитывать все артефакты.

@Kondr48, а чем не устраивает текущее? +1% к скорости восстановления здоровья означает, что скорость восстановления здоровья увеличится на 1%. Вроде вполне понятная штука. А если немного отвлечься, то мне кажется, что в Зоне вообще должно быть поменьше понятного и конкретного. А то не Зона, а парк развлечений какой-то, прости господи. Нашел сталкер артефакт, а на нем нет бирки с составом, калорийностью и аллергенами.

@aas075, Вероятности, они не такие вероятности, как мы думаем. 80% вероятности не означает, что из десяти варок получится 8 артефактов и 2 булыжника. Это всего лишь означает, что если полученое случайное число от 1 до 100 будет меньше 80, то получится артефакт. А уж какое будет случайное число в этот раз - это, как повезет. Я вот последние несколько варок получал артефакты, а не булыжники.

Не могу удержаться. Уверен, что выскажу общее мнение. Мы все за тебя очень рады. Вот только полезной информации в том, что ты написал, 0. Для наглядности напишу буквами: ноль. А в остальном, жжош, пиши ишчо.

@pc-2, вот между двумя этими строчками alife():create("kurevo", db.actor:position(), db.actor:level_vertex_id(), db.actor:game_vertex_id(), db.actor:id()) db.actor:object("kurevo") kurevo в инвентаре еще не появится. Оно появится позже, когда твой код завершит работу и управление вернется движку. Прежде, чем его есть, нужно дождаться, когда оно появится. Вот так, к примеру level.client_spawn_manager():add( sobj.id, -1, function( id, obj ) db.actor:eat( obj ) end )

Я точно помню, в ОП-1 проблем с этим не было. Возможно, оно работало "на соплях", только за счет того, что дальность зрения была ниже, чем в ОП-2. Просто предположение. Я еще до туда не дошел.

@McSon, те, кто посмотрят, где они находятся, легко их и достанут. Всяких камер-телепортов и т.п. навалом.

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

Какой еще фриз? Уборщик работает в net_spawn-е актора и на фоне времени, затрачиваемого на выход в онлайн всех текстур, моделей и звуков - это пшик.

Что там размазывать-то. Вся чистка [02/12/17 23:11:13] [ogse_signals]: 294133.28125, @d:\s.t.a.l.k.e.r\gamedata\scripts\sak_off_corpses.script микросекунд. Т.е. 0.3 секунды. Ну и смысл тут что-то усложнять и куда-то размазывать? Даже если можно оптимизировать и получить 0.03 секунды, затраченное на реализацию оптимизации время того не стоит.

@Dennis_Chikin, тот amk_offline_alife, который в Солянке, на мой взгляд, просто бессмысленен. Проще случайным образом убивать случайного непися в оффлайне. Результат будет такой же. Но самое главное, он бессмысленен для игрока, т.к. он его просто не увидит. Будут просто образовываться трупы. Что в этом интересного, я не знаю, кроме раздражения, когда игрок будет кого-то вооружать и переодевать, а потом придет, а этого самого вооруженного и переодетого терминатора загрызет тушкан, якобы. И будет бедняга вопрошать, ну что, что я сделал не так, как еще их надо перевооружать. Вообщем, в итоге я у себя оставил только подбор артефактов, ограбление нычек и оффлайновую торговлю. Твой вопрос сегодня натолкнул меня на одну мысль. Кто-нибудь имеет предположения, для чего в xr_gulag проверяется расстояние до точки работы, для определение, дошел моб до работы или еще не дошел? Моба на место работы ведет CALifeSmartTerrainTask, который приведет его на game vertex работы. Так зачем проверять расстояние до этого game vertex-а, вместо простого сравнения sobj.m_game_vertex_id == job.game_vertex_id?

@Dennis_Chikin, вероятно, это зависит от установленного типа пути. Если поставили ePathTypeGamePath, то, вероятно, моб пойдет по game vertex-ам. Если ты имеешь ввиду мобов, который идут в свой смарт, то, насколько я вижу, им как раз устанавливается movement().path_type (MovementManager::ePathTypeGamePath);

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

@AVIX, рецепты смотри. Это артефакты первого уровня модификации. Т.е. те, которые уже один раз модифицировались, относительно базового артефакта.

Не скажу, не знаю. Не знаю, есть или нет, я оригинал-то никогда изнутри и не видел, т.к. только с Солянкой дело имею. Но в любом случае, любую работу с нет пакетами лучше сразу переделывать на использование любого, готового модуля работы с нет пакетами, от Артоса например. Это xrLuaFix от RvP, если я правильно нашел полное название.

@MegaStalker, ogse_signals - самодостаточный. Автоматически инициализируется при первом использовании. Т.ч. просто бери ogse_signals.script и ogse_signals_addons_list.script с пустой таблицей, для начала, и добавь class "actor_binder" ( object_binder ) function actor_binder:__init( obj ) super( obj ) ... self.am = ogse_signals.get_mgr() self.am:call( "on_load_before_all" ) self.am:call( "on_init", obj ) ... end или на подобие этого. Все, менеджер готов и можешь добавлять куда тебе нужно вызовы сигналов. Возможно понадобятся какие-нибудь функции из _g.script, ну так скопируешь к себе. Еще, ogse_signals использует RvP, если я не ошибаюсь. Т.ч. как оно будет в СоС - не знаю.

@BoBaH_671, а, это я не внимательно посмотрел. Тогда предложу другую идею, которая сразу в голову пришла. Может причина более очевидна, но что в голову пришло первое, то и предлагаю. Раз ты его по сиду ищешь, он у тебя случаем не из all.spawn? А если из all.spawn, то не сброшен-ли у него флаг, разрешающий использовать флаги can_switch_(on|off)line()? Да и вообще, нет-ли там чего-нибудь странного в object_flags?

@BoBaH_671, про ЗП ничего не знаю, но в коде вижу странность. Если ты пытаешь перевести его в онлайн, значит он в оффлайне в этом момент. Раз он в оффлайне, то level_object_by_sid() не вернет ничего, если только в ЗП оно не работает как-то по другому.

@Graff46, не скажу с полной уверенностью, но подозреваю, что не обязательно. Даже когда инвентарь закрыт, методы возвращаемого окна работают. Т.е. можно, как минимум, проверить скрыто или показано окно. Т.ч. возможно и аттачить можно. Это всего-лишь предположение, т.к. в гуях я плохо разбираюсь.

Ты наверное имеешь ввиду level.get_inventory_wnd() которая возвращает окно, к которому уже можно аттачить нужное?