Xdlic

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

Открывал цинки с .410 патронами, много кликал и наклика себе вылет

Во время рутинного сохранения игры локтем нажал enter, продолжая печатать название, и игра вылетела.

Такая же фигня...

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

В последнее время начали часто попадаться эти вылеты: Вылет в момент загрузки сохранения Вылет при загрузке сохранения/смене локации: Словил стабильный вылет. Иногда это происходит сразу, иногда через некоторое время, но все равно вылетает. >>>>> Сохранение <<<<< Еще пачка вылетов

Если много вещей торговцу в окно продажи напихать, а потом одну назад попытаться забрать, то я почти всегда ловлю вот такой вылет (лог после долгой игры)

Стабильный вылет в старых болотах, обнаружил уже после долгой игры. При приближении к объекту: При попытке сохраниться неподалеку: сейв

В общем, дошли руки до бага с Сидоровичем. Обнаружилась когда решил поспать возле Сидоровича дабы глянуть на товары за визитку. В news_manager.send_tip() передается стори ид торговца, функция по нему получает серверный объект, а дальше идут непонятки. У двух торговцев на классе script_trader (крохобор и сидор) имеется такая ошибка, в моем случае. npc = aife():story_object(sender_id) -- получаем userdata ... if npc:alive() == 1 then -- игра вылетает не обнаружив этот метод ...

Есть у кого ссылка на торрент СЗ? хочу переустановить, бо вылетучая сильно.. самый свежий вылет: сидорович оказался химерой и игра вылетела не обнаружив у него функции alive()

Заметил странное, выставил в игре меньший тайм-фактор(1) alife и выносливость стала резко сильнее расходоваться, в экзе в гору стало невозможно бегать

Подтверждаю, на атп задание на 3 псевдогигатов взял, одного нашел, вместо остальных завалил двух чернобыльских вепрей... Задание зачлось в момент смерти последнего вепря.

Может такое уже было. Соб-на вопрос, как вытащить из игровых архивов папки config и scripts, в скачаной пару лет назад 0.8.1 в gamedata есть только папка levels. Где взять распаковщик?

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

Столкнулся с необходимостью сравнить две переменные типа userdata (копаю gui классы из луа и там возникла в этом потребность) . Но меня ждал Великий Облом в виде ошибки: LUA error: No such operator definedВ начале вылетел при проверке на неравенство, потом та же ошибка и при проверке на равенство... Выдержка из руководства: "...и не имеет предопределенных операций в Lua, за исключением присваивания и проверки на равенство." Вот так, в иных сборках это ошибки не вызывает, а в сталкере похоже метаметода сравнения двух объектов нет. По крайней мере rawequal выдает вменяемые данные, придется или пользоваться им или делать сравнение по меткам.

Берешь level.add_cam_effector(). Смотришь, с какими параметрами она используется в интересующем моде, и копируешь себе в каллбек на начало новой игры. Еще может потребоваться скопировать указанный файл анимации, если там указан не из оригинальных. Сам каллбек выглядит как проверка на апдейте актора, где проверяется, что уровень загрузился и ищется переменная в pstor актора/инфопоршень. Если уровень начал рендериться и переменной нет -> выполняем одноразовый код и выдаем актору переменную/инфопорцию. В оригинале она уже есть в actor_binder.update, но по хорошему одноразовый код лучше хранить набором функций в табличке - надо, добавил фунцию. В нужном месте запускаем функции из таблички. Отработала - удалили и больше в табличке не указываем. Спавнить рестриктор для события, которое делается скриптово? Увольте, человек спросил для начала новой игры. Не вижу ничего о том, что актор для этого должен куда-то зайти. P.S. И да, он с данной логикой что, будет каждый раз падать? А рестриктор мотать эту логику всю остальную игру... Когда в изначальном алгоритме забываешь об оптимизации - не ищи быстродействие в конечном продукте.

Хочу поинтересоваться по поводу инвентаря, в нем будет реализован драг-дроп или просто будем перетаскивать мышку с зажатой кнопкой от элемента к элементу без отображения иконки(что я увидел в видео). Сам скриптовый драг-дроп вполне успешно реализуем, я когда-то создавал унифицированный модуль для перемещения статиков вслед за мышью, получалось более чем плавно.

Не обратил ранее на эту функцию внимания, считая ее аналогичной #. Проверил заодно и table.setn - да, эти функции как раз и позволяют получать и задавать "счетчик" с которым работают функции вставки/удаления. Можно ручками забивать строки через t[#t+1] = val, а затем обновлять его table.setn(t, #t) и стандартные insert/remove будут "видеть", что с таблицей что-то случилось .. и соответственно будут обрабатывать также и новые данные. Но... зачем-то их ведь удалили из стандартного набора Lua-функций. В SciTe-ru пишет: 'setn' is obsolete. P.S. Споры о том, можно ли так делать или это "моветон" пропущу мимо ушей.

Будет время - посмотрю, что там внутри этих таблиц, вдруг счетчик хранится в метаданных самой таблицы. Ладно, оставим в покое этот болезненный вопрос урезанного сталкерского Lua, интересно, какие еще особенности языка ПЫСы сумели сломать к релизу?

Хотя бы затем, что имено если бы они реагировали также как #t, то это позволяло бы работать в сталкере с концом строки по упрощенному варианту t[#t+1] = val и t[#t] = nil вместо вызовов функций. В чистом луа как раз это и работает. Никто не исследовал вопрос, где хранятся эти созданные счетчики? В недоступной части таблиц или где-то внутри движка Lua/Сталкера? Upd: Не также, в сталкере инсерт обрабатывают таблицу ровно до той позиции, которая хранится в счетчике, который кроме как в этих двух функциях, нигде недоступен. Ну хорошо, раз в сталкере нельзя работать с индексами по упрощенному варианту, значит будем каждый раз вызывать соответстующие функции... а если одновременно нужно этими инсертами забить 100500 значений в таблицу, которые заранее нельзя задать? Мы получим ощутимый нагруз от этих 100500 вызовов функции table.insert(ну ладно, пусть еще можно ссылку хранить локально). Или в этом случае полностью придется отказаться от индексных массивов и получать случайный перебор элементов из pairs(). Upd2: И да, смысла в предложенной обертке меньше, чем 0. Чтобы она работала, нужно в ней получать доступ к счетчику и вручную его менять. Upd3: Видимо я и вправду не умеею внятно изъяснять свои мысли/идеи. Твой вариант уже не будет работать совместно с table.insert/remove. Стоит их один раз вызвать и счетчик перестает зависеть от структуры таблицы. Про индексный массив с 100500 строк, тогда уж проще сделать обертку не вокруг самих функций, а вокруг метода. Т.е. реализуем свои table.insert_new/remove_new function table_insert_new(t, pos_or_val, val) local end_pos = #t if val then if pos_or_val < end_pos then for i = end_pos, pos_or_val, -1 do t[i] = t[i-1] end else t[pos_or_val] = val end else t[end_pos+1] = val end end И подобное для remove, вроде алгоритм правильно описал В результате не будет этого статического счетчика позиции для добавления/удаления, который я вижу в сталкере. А самое главное - можно будет спокойно работать как с t[#t+1] = val, так и с новой версией вставки значений в СЕРЕДИНУ индексного массива.

Давайте оставим этот момент в стороне. По отношению к индексным массива в сталкере вообще никак иначе обращаться категорически не рекомендую(как раз из за необновляющегося счетчика). Собственно я отправил свое сообщение с мыслью, что получается в движке сталкера функции добавки/удаления реагируют на изменения таблицы совсем не так, как функция #t. Вопрос имел целью узнать, как влиять на выбор текущей позиции в этих самых table.insert/remove. Если, допустим, сделать простую обертку, которая предварительно будет определять конец индексного массива, то сами эти функции будут обрабатывать перестановку nil из одной ячейки в другую до сгенерировавшегося при первом вызове внутри них счетчика. Это конечно не особо сказывается на производительности, но сам факт имеет место быть. Пример обертки, которая корректирует значение позиции текущего конца индекса function insert_two(tab, pos_or_val, val) if val then table.insert(tab, pos_or_val, val) else table.insert(tab, #tab+1, val) end end Но это не отменяет того факта, что выйдя за пределы первоначального диапазона мы получим результат, когда начало таблицы наползает на ее конец

Внезапно рухнула сеть, поэтому не отписывался. Описание теста: платформа ТЧ 1.0006(топология), встроено расширение луа от артоса(by RvP), вернул родной xrLua - результаты теста теже. (Заодно проверил на 4 патче(+от солянки) с чистой геймдатой) - также вставляет не в 1ю позицию.)

В ходе своих наработок в Lua для сталкера сделал отметил несколько любопытных моментов:

Это могло бы быть вариантом, но в целом в результате дает просто перенос выбора ветви поведения в другое место. Обработка вызова функции через метатаблицы по сути являются теми же ветвлениями, но они уже будут статичны для данного типа/класса. Если функция определена как метод, то self при ее вызове будет автоматически скрываться. Простая функция в этом случае будет вести себя несколько иначе - если вызвать ее как метод, параметры будут смещены вставкой self первым аргументом. Речь шла о замещении метода функцией, не расчитанной на получение self. И в первом посте было упомянуто - как вызвать метод (без двоеточия видимо?) и получить внутри него self не делая в заголовке каждой вариации метода лишних телодвижений с получением объекта, в котором метод был переопределен. Следует отметить, что вызов inject-метода через точку не подразумевает передачу туда self в явном виде, во время вызова, иначе это скатилось бы к тем же громоздким ветвлениям. В чем-то вы правы, но.. Работа вариантов метода полностью определяется внутренним контекстом объекта и не зависит от передаваемых значений. В данном случае было задачей убрать затратные проверки при каждом обновлении.

Хочу реализовать в сталкере классы, в которых методы будут менять свое поведение в зависимости от параметров объекта(замещаться аналогичными методами). Пока это все в виде набросков, но схема предложенного выше такова: Есть класс (скажем 1), задачей которого являет обновление состояния массива объектов другого класса (2). В этом втором классе обновление может быть реализовано как в виде метода (при инициализации в метод inject подставляется нужный в данной ситуации метод), так и в виде функции (этот метод предназначен, в свою очередь для вызова сторонней функции). Можно конечно не заморачиваться и просто использовать обертку вида function element_class:inject(...) self.fun(...) end Когда не требуется производить дополнительных действий, но меня интересует, можно ли обойтись без обертки, подставляя в метод стороннюю функцию и обрабатывая доступ к self в методах inject_xxx() как-то иначе.