Zander_driver

Работает. Он выходит из тела анонимной функции. Вот этой: А iterate_inventory или его аналоги, запускает задание на циклический вызов указанной функции. И для отмены/прерывания задания, метода нету. Но, а зачем он нужен? Можно же сделать что-то в таком духе: local i=0 local ido = true db.actor:iterate_inventory(function(item) if ido then -- Здесь наши действия если перебор продолжается i=i+1 if item then ido = false end else -- Здесь - если нет return end end) log("iter="..i) Кстати, я тоже. Все равно какая-то вариация на тему, по образу и подобию... не все ли равно?)

В общем, наверное назрело. Сейчас будет большой-пребольшой пост, с целью в порядке ликбеза расставить все точки над i. И над ё. Не перепутав, кому сколько точек причитается. И заодно дать ответ на ряд вопросов, явно или подспудно прозвучавших в этой и соседней темах... (То, что как бы и оффтоп, но не совсем) итак, поехали. Начну отсюда, пожалуй. Может не 10, но назову. Не так давно видел на форуме высказывание в духе "творческие люди они такие - тащат в рот всякую гадость без разбору". И сказано это было вроде про меня, в связи с тогдашними анимешными аватарками Часть вторая. ... Продолжим... Мы все еще не расставили точки над i. И ё. Тут совершенно верно. И - те кто может быть, играет только в СЗ или только в сталкер, могут подумать будто идеи появляются из ниоткуда... но это конечно заблуждение. А тут... я, может быть, кого-то шокирую - но спрошу - За что?) Развивая мысль...

Вообще, я тут подумал. Лучше не надо) Лучше я на оружие, магазины и патроны, символическую маркировку добавлю. Наподобие как в Mass Effect было. (НЕ недавнее переиздание имею в виду) Снаряжение разнотипными - точно нескоро... скорее всего, совсем не скоро. Но когда-нибудь, вероятно, да.

Вот если бы за месяц предупредил, то может быть... А так, патчи по мановению волшебной палочки, не изготавливаются. Зашел тут к Бармену, посмотреть что-почем: И опциональность к интерфейсу добывания трофеев, приделал. Теперь вот это выковыривание трофеев из мутантов, через QTE с кнопками, можно включить, можно выключить. Но, только при старте НИ

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

Естественно, родитель для наследования должен быть виден там, где ты его наследуешь. Если ты хочешь, чтобы все выше-объявленные секции конфига были видны для твоей, то и подключай его к system.ltx, и доступ получай через system_ini(). Файлы, доступ к которым получается через ini_file(), подключаются как отдельная система конфига, независимая и несвязанная с system_ini. К ним может быть тоже что-то подключено через #include, но это все равно будет обособленная система. Есть такая идея... local ltx = system_ini() function found_line(section, line) local lc = ltx:line_count(section) local a = 1 while a < lc do local key = '' local value = '' local r = ltx:r_line(section, a, key, value) if r and key == line then return true end a = a + 1 end return false end Методы line_count и r_line точно есть в OGSR (Это не я добавил). Есть ли они в оригинальном ТЧ, честно говоря не помню. Если есть, то должно сработать. Если же нету, то боюсь, не существует способа узнать то что тебе нужно из скриптов.

Потому, что это надо делать как-то так: local kn_ini = ini_file([[weapons\\upgrade.ltx]]) А думается неправильно. Наследовать секции в файлах, подключаемых таким образом, можно так же как и в обычных конфигах.

Часть элементов движковых интерфейсов строится по принципу if (uiXml.NavigateToNode("какая-то нода xml", 0)) { Т.е. если их удалить из xml-конфига, элемент исчезает без вылета. Вернуть на место - появляется. Другие элементы требуются без проверок и их удаление из конфигов вызовет вылет. Но в любом случае, и те и другие спрашивает движок. Чтобы эта "какая-то нода" была прочитана, движок должен ее запросить. В дефолтном ТЧ, емнип, чтением xml-конфигов любых в принципе, только движок и занимается.

Оно как раз вот туда и нацелено и так. После 0.8.0.10 - будет скорее всего уже сразу 0.8.1. А в нем будет и то и другое.

Почитал тут между прочим... По-размышлял... и пожалуй, цинки патронов в продажу вернутся. Вот прямо в ближайшем патче.

Конечно, есть. Берешь и пишешь.

Астрал тоже?

Патч 0.8.0.10, который многие ждут, задерживается. Причина: Баг с улетающими и проваливающимися артефактами, который как предполагалось, был исправлен. Оказался таки не исправлен. Патч выйдет тогда, когда эта проблема будет решена.

OGSR - не ТЧ ? Сделано же. Искать: lc_silent_mode

FatBoy Slim - Push the tempo

Судьба Зоны : Известные проблемы. В этом посте постараюсь поддерживать в актуальном состоянии, информацию по известным вылетам и багам мода Судьба Зоны. Сюда НЕ включены те баги и вылеты, с которыми имеют дело тестеры в ЗБТ. Вылеты: Баги: Если вы заметили баг, не упомянутый здесь, обязательно напишите о нем.

Да ладно. "Идеалов" много видимо. https://www.cyberforum.ru

Смотрим: green_location - это какую мы метку используем. какие они вообще бывают, можно в gamedata/config/ui/map_spots.xml посмотреть. Можно что-нибудь из этого попробовать: blue_location, red_location, eliminate_lager_location, level_changer - вроде они небольшие, если не путаю.

Об этом лучше @KRodin спросить, в дискорде OGSR. У @Опричник-а в подписи есть)

Можно как-нибудь так: function mark_all_restrictors() local a = 1 while a < 65535 do local sobj = alife():object(a) if sobj and sobj:section_name() == 'space_restrictor' then level.map_add_object_spot_ser(a, "green_location", sobj:name()) end a = a + 1 end end Эта функция отметит на карте все рестрикторы в игре. И можно будет посмотреть, не находится ли какой-нибудь из них близко к тому месту, куда ставишь NPC. Если находится, то переставить подальше. Черт его знает) Некоторые вполне можно безболезненно удалить. Сперва узнать бы, что за рестриктор, и та ли это вообще причина.

Не совсем так) Оно будет применяться к карте локации, для того чтобы наделить смысловой нагрузкой, понятной для NPC, объекты на ней. Такие как здания и т.д. Потому что сейчас в сталкере, NPC понятия не имеют о зданиях. Им мододелы вручную ставят пути, "стоять вот тут", "идти туда", "смотреть туда". Теперь же NPC сами смогут определять, где у них лагерь, где его границы, которые они берутся охранять от мутантов, и где у этого лагеря входы и выходы, чтобы поставить там охрану. Это будут такие же пути валкеров и кемперов, но поставленные (и переставляемые при необходимости) самим движком, а не человеком-мододелом. В одно окно смотрели двое. Один увидел дождь и грязь. Другой — листвы зелёной вязь, весну и небо голубое. В одно окно смотрели двое.

@Earth2Space Ковыряние скриптов вообще - куда более широкое понятие, чем работа с заселением. Это во-первых. Во-вторых, ты выдрал фразу из контекста. Там еще смайлики были В третьих мне порядком поднадоело объяснять очевидно-понятные каждому вещи. Которые одному тебе почему-то не ясны. А в четвертых, кстати... Мне вот к примеру, интересно: каким по-твоему, образом, технология способствующая сокращению человеко-часов на заселение, способствует сокращению потенциального числа ковыряльщиков (которое и так равно нулю) - не подскажешь? Разве что... путем устранения нужды в них. Ковыряния по заселению стали не нужны - ковыряльщиков стало меньше. Ну да... капитан очевидность, блин

@Earth2Space, немного запоздал. Лет эдак на несколько. Меня уже давным давно это не удивляет. Это если кто-то забыл. Не о чем сожалеть. Там где ранее требовалось много-много человеко-часов на то чтобы заселить локации, теперь не потребуется ничего. Просто, после завершения этой технологии будет: Движок СЗ + пустая локация = заселенная локация. Вмешательство человека нужно лишь там, где надо создать какие-то уникальности. Это не мне надо сожалеть о том, что эту платформу не используют. А тем, кто от этих возможностей отказался. P.S. И, да. После завершения этой технологии, СЗ станет НЕпривязана к своему пакету локаций. И сможет добавлять в свой состав, любые новые локации в любой момент, и благодаря системе компрессии - в любом количестве.

Поддержу. Если это ачивочное безобразие, технически возможно перерисовать и переименовать в более подходящие (амк-форуму) изображения и тексты, то следует это сделать, а не оставлять их в том внешнем виде, как есть.