Zander_driver

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

Ну так про-контролируй исполнение каждого шага, того что ты делаешь, в логи. Это же азы, элементарщина. Делаешь что-то, в чем не уверен/не знаешь точно, сработает ли/не факт что сработает. Значит добавь рапорт в лог на каждом действии, каждом шаге. И смотри по логу, до какого места все шло по плану, в каком месте запнулось. Там уже разберешься что пошло не так. А без ведения логов, гаданиями можно сколько угодно заниматься безрезультатно. Таких нет. Просто ты либо знаешь что делаешь, и знаешь как можно проверить, что получилось и сработало всё так как было задумано. Либо нет.

С днем победы! Всех присутствующих. ЗЫ. Побед у нас много. И это хорошо.

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

Я вам больше скажу. Будет БОЛЬШЕ багов! Во сто крат! Ведь не может быть иначе, это всем известно. Остается лишь вопрос, раз вам все это известно заранее, то зачем вы вообще сюда пишете? Можно же спокойно посыпать голову пеплом и тихо ползти куда-нибудь. Здесь ВАМ ловить нечего.

Это исправлено еще при царе горохе. Как и прочее что вы упоминаете. В нынешней СЗ тестеры не встречают подобных проблем.

Кот мимонапрудил? Значит огорчили его чем-то.

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

В разработке. Где ж ему еще быть-то Если по теме, в патче вас совершенно точно поджидают некоторые квестово-сюжетные сюрпризы. Подробностей раскрывать не буду. Но это НЕ обещание, просто информирую о том что сделано уже.

Когда в Главном Меню начинаете Новую Игру, то перед ее началом вам предоставляется возможность установить настройки, с которыми всю игру будете проходить. Изменить их где-то потом нельзя, они только на старте устанавливаются. Среди прочего там есть и шанс выпадения оружия с нпс, скорее всего у вас было поставлено в 0. Потому и не выпадает, и не выпадет независимо от группировки убиенных нпс. Будьте внимательнее. Не нужно игнорировать настройки, кроме вас самих никто их под ваш вкус не настроит.

Это описания эффектов, а не эффекты. Поэтому и xrGame\ui\ui_af_params.cpp отвечает только за отображение описания эффектов. Больше он ничего не делает и ни на что не влияет. (Что явно следует и из самого файла и его расположения).

Опять 25. Ну у тебя же уже есть рабочий пример сохранения в xvars. (Я уж молчу о том что он и в OGSR-Wiki как был так и есть). Зачем опять эти костыли, да еще прости-господи, нет-пакеты? Сохрани свою переменную в xvars и не парься.

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

Ну например в гугл вбить... Указал он платформу. S.T.A.L.K.E.R. Anomaly вполне себе платформа, не знать о существовании которой - грех.

Возможно ее какая-то аномалия сломала. А здесь еще не успела.

Уже давно не только это... Просто тут форум специфический. Что-то кроме сталкача сюда крайне плохо заходит.

А там что, чувство юмора ампутируют теперь? Как хорошо что я ее пропустил почти. ("Скипнул" по-вашему)

А вы простите, у костра или в суде?

И сколько же?

Хорошо что не прокураторы. ЗЫ. Кстати занятно... Прокураторов (по нынешнему прокуроров, обвинителей) изобрели аж в Древнем Риме, более 2000 лет назад. А адвокатов придумали только лет 400-500 назад. Это вы представьте, каково было всяческим обвиняемым в чем-нибудь на протяжении полутора тыщ лет?!

Истинная правда, так оно и есть. Но людям бывает очень страшно к движку даже подойти, и в это наше C++ окунуться. Боятся, понимаешь... А если по теме. Люди, не надо бояться движка. Он не кусается. Уж тем более теперь, когда все доведено до ума.

Ох, Ёлки зеленые, кучерявые... @666Ian , дружище, по порядку. Это очень хорошо. На нем есть как минимум 4 варианта, как сделать то что ты хочешь. 0) Нетпакеты сразу забудь. Вообще. Оно тебе не надо, совсем, тем более если на ogsr. 1) Переспавн секций (по условию, скриптом, с заранее-прописанными свойствами в километровых полотнищах конфигов) - это метод топорный, тупой, негибкий, НО! - простой понятный как бревно и рабочий вообще везде. И в том же ogsr прекрасно можно этим заниматься, если не осилить все остальное. 2) Можно писать свои свойства в кастом-дату серверного объекта. В ogsr она доступна по адресу sobj.custom_data , причем доступна как для чтения, так и для записи. Туда можно записать свои сериализованные свойства (конкретно для ДАННОГО объекта), и применять их при net_spawn в биндере. Недостаток тут есть - custom_data иногда все же используется/перезаписывается всякими другими скриптами, и не так уж много данных в нее влезет. Но рамки использования достаточно широкие, и в принципе это может быть удобная и гибкая система кастомизации свойств объектов, хоть и не всех. 3) Можно писать свои свойства в script_vars_storage (см. ogsr-wiki), Записывая туда также id объекта, для которого это записано. И соответственно опять же применять их при net_spawn в биндере. Немножко больше мороки, но зато этот метод лишен минусов варианта с кастом-датой. Записывать можно - сколько душе угодно, и чего угодно, не опасаясь что какие-то посторонние скрипты туда зачем-то полезут. Все выше-перечисленные методы реализуются на ogsr сугубо одними скриптами, вообще без залезания в движок. Ну и... 4) Метод самый простой и удобный. Но в каком-то смысле и "непростой"... Берешь исходники движка. И пишешь туда сохранение всех тех свойств которые ты желаешь сохранять, в серверный объект(ы). В классы серверных объектов. Я лично делал именно так, заготовив сохраняемых параметров с запасом и на вырост, чтоб по ходу доработок добавлять сохраняемых свойств и не требовать НИ при этом. Единственный минус этого метода - надо знать C++ и уметь собирать движок. В остальном одни плюсы... Неа. Все что штатно движок грузит из конфига - если ты хочешь чтоб оно грузилось из кастом-даты / script_vars_storage / серверного объекта, то надо это делать ручками. "Само" оно только из конфига будет загружаться. Но вообще, по хорошему... Такое делать надо через движок. Чтобы не вязнуть в скриптовой мороке и пардон, тормозах. Движок это всё шустрее обработает.

Если "онлайновый" = клиентский, то никак В общем случае, самый удобный способ получения клиентских/серверных объектов - это получать их по id. local obj = level.object_by_id(id) -- Получаем клиентский объект, зная его ID local obj_id = obj:id() -- Узнаем ID клиентского объекта, если он у нас есть local sobj = alife():object(id) -- Получаем серверный объект, зная его ID local sobj_id = sobj.id -- Узнаем ID серверного объекта, если он (объект) у нас есть. --ID серверных и клиентских объектов всегда совпадают. Так что, выяснив id одного из них (например клиентского), можно зная id получить серверный, и наоборот. --У некоторых специфических объектов игры (например: Болт). Существует только клиентский объект, а серверного нет.