Kirgudu

Прекрасная смесь, употребляю постоянно! Равно как и селёдку с молоком. Сегодня как раз ждёт в холодильнике и то и другое.

Тема открыта.

@Kober(BRUC), table.insert(t_tbl, dd)

@AndrewMor, например так: function GetMaxLevelVertexId(idLevel) local gg, idLvMax, levelChecked, i, idLv = game_graph(), 0, false, 0, nil while i < 65536 do if gg:valid_vertex_id(i) and gg:vertex(i):level_id() == idLevel then idLv = gg:vertex(i):level_vertex_id() if idLvMax < idLv then idLvMax = idLv end if not levelChecked then levelChecked = true end elseif levelChecked then break end i = i + 1 end return idLvMax end -- пример вызова для текущей локации: idLvMax = GetMaxLevelVertexId(alife():level_id())

При вызове random(2) не может - только целое число. @KitkaT.Net, рекомендую в вышеупомянутое ветвление добавить ещё одну ветку вида «elseif FILTERS_PLACE==2 then ...» и перенести туда то, что сейчас находится в ветке «else». А в else для проверки сделать вместо этого вывод в лог. Если выполнение зайдёт именно туда - скорее всего, значение переменной равно начальному нулю, и присвоение случайного числа просто напросто не запускается из-за специфики скрипта.

Коллеги, вы все не обратили внимание на один момент. Оставив в стороне то, как написана сама функция, видим это: ИМХО, ошибка где-то в другом месте того модуля, где функция располагалась первоначально. И несмотря на то, что чекер ошибок не даёт, что-то мешает движку прочесть все элементы этого модуля. UPD: Если только функция сначала была не в bind_stalker.script.

@Winsor, трудно сказать, я с таким не сталкивался. Собственно, в netpk до сих пор могут быть баги. Artos до момента своего исчезновения сам периодически находил в своих модулях и правил ошибки, да и последняя версия модулей, что лежит в «Сборочном цехе», тоже подверглась небольшим исправлениям по сравнению с оригиналом автора. Не исключено, что ты столкнулся с ещё не обнаруженной до сих пор ошибкой.

@Winsor, а почему ты думаешь, что данные там битые? В зависимости от значения num_items наполнение нет-пакета может меняться. Подробнее, например, здесь.

@Kober(BRUC), 1. "local cly = 25" и т. п., если не ошибаюсь, видно только в пределах своей ветки if ... else. Следует объявить переменную до if, а внутри только задавать значение. 2. math.randomseed результат не возвращает, а только задаёт случайное смещение для последующего math.random. Присваивание переменной в данном случае лишнее. 3. Выбор фразы для печати ты делаешь в одной из веток внутри if, а не за пределами оного. Конкретно, печать у тебя происходит только в случае опции "random". 4. Судя по всему, навыки чтения кода у тебя не очень высокие. В этом случае, чтобы делать меньше ошибок, будет хорошей практикой использовать отступ для вложенных элементов.

От меня до южного внутримкадья 6 километров - хоть бы одна капля упала, не говоря уже о деревьях.

@Kober(BRUC), потому что сейчас это не массив, а не пойми что. Каждый буквенный элемент следует заключить в кавычки.

А при чём тут биндер? Речь-то изначально шла о том, как отловить факт перехода на другую локацию перед этим самым переходом. А это происходит уж точно тогда, когда актор полностью инициализирован в процессе предыдущей загрузки. И значит можно сохранить текущую позицию, например id локации, один раз, в момент инициализации актора. @Romz, попробуй в on_item_drop проверять позицию не клиентского объекта, как ты это делаешь сейчас, а серверного. Примерно так: local sObj = alife():object(db.actor:id()) local vPos,idLv,idGv = sObj.position, sObj.m_level_vertex_id, sObj.m_game_vertex_id -- дальше можно вычислить id локации и сравнить с запомненным if idGv and game_graph():valid_vertex_id(idGv) then local oVertex = game_graph():vertex(idGv) if oVertex then local idLevel = oVertex:level_id() end end Засим из дискуссии удаляюсь по причине катастрофической нехватки времени. Удачи в поисках решения!

@Romz, позицию берёшь, надеюсь, серверного объекта?

Имхо, поскольку смена локации происходит одновременно с сохранением/загрузкой, достаточно сохранить параметры текущей локации всего один раз, скажем в actor_binder:__init. Делать это пусть даже на медленном апдейте избыточно.

@Romz, если я правильно помню, при переходе на другую локацию перед сохранением актору прописывается новая позиция (координаты и/или id вертексов или даже id новой локации). Используя известные методы по работе с графом, легко сравнить эту новую позицию с параметрами текущей локации и при несовпадении делать или не делать то, что требуется. Расписать подробно не могу, так как забежал сюда буквально на минутку. Но ты уже давно не новичок, сообразишь. Если я прав, конечно.

Удаляется, вестимо. Надо смотреть, что идёт перед добавленным куском кода. Причём не только в скрипте, но и, например, в секции on_death логики НПС, если обработка логики в мотиваторе идёт перед своим кодом. В общем, надо внимательно проинспектировать свои правки.

@Kondr48, прежде чем советовать, неплохо бы самому подучить матчасть. Очевидно, что sobj = nil, а не результат вызова серверного метода. И проверка нужна такая: local sobj = alife():object(self.object:id()) if sobj ~= nil then ... end @Wlad777, если серверный объект не найден, значит и спавнить негде. Так что такая проверка вполне подойдёт. Поищи здесь информацию по CUIListWnd и CUIListItem (CUIListItemEx). На элементы списка можно будет повесить коллбек ui_events.LIST_ITEM_CLICKED - вот и возможное решение искомой задачи.

@ZeeK, local tbl = { ["wpn_knife"] = true, ["wpn_torch"] = true, ["wpn_pm"] = true } ... if not tbl[item:section()] then ... end

@ZeeK, не изымается оно там, ибо кусок в оригинале закомментирован. Только деньги отдаются. А если есть желание изъятие восстановить, то ничто не мешает сделать нужный фильтр. Например, в функцию get_actor_inv добавить проверку на класс и в список для изъятия помещать только удовлетворяющие условиям предметы. Или сделать то же самое уже после, при переборе списка. Весь нужный код там уже практически есть, надо только доработать напильником согласно своим требованиям.

Чисто ради интереса: помутнение в глазах во время каждой выпивки с Карданом, привнесённое ещё в первой версии одновременно с опьянением, исправлял?

Тема открыта. Успехов в разработке.

@Danko13, релиз от 25.07.13 уже включает в себя обязательный фикс. Других отличий от дистрибутива с оф. сайта нет.

Согласовать «прятки» при выбросах и активную войну группировок ЧН с её целями, заданиями и т. п. довольно сложно. Велик риск нарушить всю симуляцию ВГ. Поэтому поведение НПС при выбросе в моде сознательно оставили оригинальным.

Разве? Насколько я помню, при разработке мы включали его после перехода на Кордон, то есть после завершения «болотной» сюжетной линии.

@vampirnik77, выполнится.