Malandrinus

Real Wolf, Значит надо запоминать открытую закладку и использовать эту информацию в сочетании с сигналом от открытия окна. Т.е. есть сигнал от вкладки - используем его, нет - используем запомненную в Lua закладку + сигнал от главного окна.

Обновил проект для ЗП. Вроде убрал вылет.

Файлы из раздела "downloads" со страницы проекта удалены, как устаревшие. В дальнейшем никаких новых архивов для скачивания не будет, поскольку поддерживать актуальную сборку хлопотно, и это вызывает вопросы типа "там одно старьё". С этого момента получение исходников возможно только через svn. Там всегда последняя версия.

abramcumner, Зачем, я тебе верю. Я в своё время искал событие, предшествующее регистрации в реестре сидов, но выходит недостаточно внимательно. Впрочем, использовать функцию думается всё равно удобнее. Если поглядеть это место в коде, то там много чего регистрируется, не только sid-ы. Смарты регистрируются, родительские объекты, присоединёные инвентарные, объект прописывается на апдейты и в алайфе и ещё что-то непонятное.

abramcumner, К сожалению, ничего из указанного не поможет. SID не пропишется в глобальный список до следующей загрузки игры или перехода на другой уровень. Эту проблему можно решить только правками движка. Функцию для ТЧ, которая прописывает объекту SID с регистрацией, я уже сделал, при ближайшем апдейте она будет доступна.

lychagin0, Что касается машин, то двери там можно сделать таким же образом. Машина - это в целом физический объект, правда уже не общего вида, а специальный. Двери можно сделать по тому-же принципу: разблокировать шарниры, добавить схему управления открытием/закрытием. Только пользы с этого мало, поскольку уж анимации влезания/вылезания вырезаны начисто, и тяжело привязать эту манипуляцию дверями к моменту посадки/вылезания.

Clayman, Не уверен, как насчёт того, были ли такие двери раньше в билдах и как они были там реализованы, но сейчас двери можно сказать не движковые, а скриптовые. Собственно дверь в игре - это физический объект общего вида с шарниром вращения. При нажатии на дверь скриптовая схема прилагает вращающий момент к нужной кости, что приводит к открытию/закрытию. Таким образом, никто не мешает сделать и сдвигающуюся дверь. Только вместо шарнира вращения нужно сделать сочленение с линейным перемещением и изменить схему с применения вращающего момента на силу. Ещё раз, движковые возможности это вполне позволяют, просто никто до сих пор этим не озаботился. lychagin0, Причём здесь "транспорт мод" и тем более какое отношение имеет БТР и его "шустрость" к вопросу о дверях?

Полтергейст, Вопрос непонятен. Да, проигрывается. Надо это убрать? Я бы забил этот фрагмент инструкцией nop. А если вдруг надо вернуть, то это можно без проблем сделать сриптом.

Стрелоk, Понимаешь, движок этого никак не мог сделать, поскольку вся эта ботва "; cse_abstract properties" - это вообще к движку не имеет никакого отношения. Это же распакованный all.spawn, а движок знает только про забакованный бинарный, где такого текста уже нет. Так что этот текст туда внести мог кто угодно, но только не движок.

SkyLoader, почти сделал, на выходных выложу

СаняZ, В движок ЗП вшит движок ЗП. Извини, но на твой вопрос иначе не ответить.

Artos, формально говоря, в Lua свойств нет, поскольку ООП имитируется, так что называть можно по разному: поле, свойство, параметр, переменная. "Свойство" будет наиболее точным словом, если делать акцент на ООП. Сказав "запись" я имел в виду, что это свойство доступно на запись, что бывает не всегда, поскольку свойства бывают и только на чтение, и значит громкость можно менять, а не только узнавать. "На запись" - так говорят, как и "на чтение". Это нормальный оборот.

У объекта sound_object есть параметр на запись volume. Полагаю, громкость именно так и нужно менять. Реверберация, как мне кажется, является свойством уровня и её скриптами не изменить.

Shadows, Какая-то странная команда. Для начала, неправильно называется. fov может быть только один, и относится он к камере и только. Потом, расстояние от камеры до худа определяется исходно выверенными конфигами из секции худа оружия. Какой смысл сбивать это настроенное значение? Ну и признаться, не уверен, что от этой команды вообще что-то осталось, что можно восстанавливать.

SkyLoader, Почему не работают? Вот пример получения/записи значений для объекта актора. Что значат конкретные смещения - уже не помню, но там корректные и читаемые строки. Если прочитать абы откуда - будет естественно вылет. db.actor:set_actor_shared_str("test", 1392) local sss = { 1392, 1396, 1400, 1404, 1408, 1412, } for _, s1 in ipairs(sss) do set_int_arg0(s1) local s = db.actor:get_actor_shared_str() log1(""..s1.." "..s) end Shadows, Для fov под ТЧ есть функции вместо консольной команды. fov = db.actor:get_camera_fov() -- чтение db.actor:set_camera_fov(fov) -- установка.

Shadows, Никогда об этом не думал. А зачем может понадобиться скрывать курсор? Впрочем, это вероятно реализуемо. Это для вида от третьего лица? Признаться, никогда этот режим не любил. В сталкере же он особенно кривой и неинтересный. Насчёт реализуемости не знаю. Надо разбираться, а со временем лучше не становится.

*Shoker*, смотри здесь. В конце поста таблица с именами. Вообще-то странно, что игра виснет. По идее, сразу после создания ящика в него можно безопасно спавнить.

Artos, в этом примере локальной переменной цикла является только i. К t1000s это не относится никаким боком, поскольку эта переменная в цикле не объявляется, а всего лишь используется. Добавлено через 12 мин.: Ещё народ, хотелось бы отметить, что разговоры о таблицах, которые "хеш/не хеш" - это не совсем верно. Любая таблица в каждый момент времени имеет как хеш часть, так и часть с индексами. Вся разница только в том, куда в силу используемого способа занесения элемента (и способа создания таблицы вообще) попадёт очередной элемент. Может как в одну часть, так и в другую, но ещё раз, и та и другая часть в таблице присутствуют всегда.

Zander_driver, Не так. По правилам языка, в конструкции if obj and obj:do_something() then ... вторая проверка будет проверяться только если сработает первая. Так кстати не во всех языках, но в большинстве. В общем-то это чаще всего самый логичный вариант, зачем делать вторую проверку, если всё выражение уже по первой части заведомо не истинно.

[sINGULAR], что ты имеешь в виду под "изменением инвентаря"?

Gun12, Ты не прав, это всё ещё 'userdata', но это именно объект Lua. В этом объекте хранится указатель на собственно движковый объект, и вот по этому указателю уже ничего нет. Проверь эту ситуацию сам. Запомни где-то ссылку скажем на серверный объект аптечки из инвентаря ГГ, потом аптечку съешь, потом проверь свойства этого объекта и что с ним можно и что нельзя делать. Кстати, я в очередной раз встречаю некоторое непонимание разницы между ссылкой и самим значением. Имя переменной (в примере выше object) - это фактически ссылка. У ссылки типа нет, тип есть у значения. Даже неинициализированная ссылка на самом деле имеет значение. Это nil. Ещё раз: nil - это с точки зрения Lua не отсутствие значения, а специальное значение, которое в частности присваивается ссылке по умолчанию. Соответственно, проверяя тип переменной, мы на самом деле проверяем тип того, на что она ссылается. Ссылается на nil - получаем строку "nil". Теперь к чему это всё. Вот ты сохранил ссылку на объект. Пока ты эту ссылку не перепишешь другим объектом, с этим объектом ничего не сделается и в том числе не изменится его тип. Lua попросту не умеет менять тип значения. Тип не меняется, просто ссылку можно переназначить на объект другого типа. Но в этом случае мы договорились, что мы ссылку не трогаем. Поэтому тип не изменится, в частности не станет nil, поскольку, как я уже сказал, для этого надо явно переписать ссылку специальным значением с типом "nil". Так что в примере выше всё будет плохо. Первая проверка сработает, на второй будет вылет.

Artos, Если точнее, то в этой строке часть type(object) == 'userdata' ошибки не вызовет, поскольку это проверка объекта Lua и обращения к движковому объекту нет, а вот вторая часть type(object.id) ~= 'nil', или точнее вот это object.id, как раз и вызовет безголовый вылет, поскольку здесь идёт обращение к свойству id, а при этом делается попытка прочитать его из движкового объекта, которого уже нет.

Artos, Я полагаю, что _Призрак_ имел в виду, что при налаженной регистрации/очистке таблиц из биндера они отражают факт нахождения объекта в онлайне. Т.е. объект появляется в онлайне - он появится и в таблице, так что причинно-следственная связь здесь вполне имеется =) Собственно, надёжность этой причинно-следственной связи никак не умаляется вторичностью её организации (не движковая, а на скриптах).

Artos, Ну значит чистить и ещё раз чистить. Вот здесь бы пригодился сборник этаких "шаблонов", т.е. типичных подходов для серверных, клиентских объектов разного типа и где и как это делать.

abramcumner, Да, с id выходит тоже надо чистить, но уже реже, только при удалении объектов. Получается, что подход с id имеет свои ограничения, поскольку контролировать момент удаления можно далеко не для всех объектов. Однако для монстров/неписей/физических объектов вполне годится. Неудобно будет со всякой инвентарной мелочёвкой: патроны, аптечки/еда и т.п., поскольку они удаляются движком, но такого рода объекты обычно и не надо учитывать, а если надо, то это уже специальные случаи и имеют свои решения. Так что насчёт "универсального подхода" я был неправ, нет здесь такого. Т.е. никогда, в свете последних новостей =) Кроме шуток, это всё возможно, но IMHO не всегда нужно. Насчёт прокси можно и подумать, а вот Null Object pattern - вещь более чем сомнительная, поскольку может (и с гарантией будет) скрывать ошибки и вместо повышения надёжности в итоге приведёт к появлению неуловимых и неотлаживаемых багов. Artos, Вставили дополнительную чистку. В данном случае это было несложно и потребовало что-то около пяти строк кода. Если так разобраться, то проблем id вызывают не меньше. Помогают два факта: 1. Удаление - вообще говоря не такое уж частое действие и как правило достаточно контролируемое, если не считать всякую инвентарную мелочёвку, как я говорил выше. 2. Движок назначает новые id "на удалении" от последнего и рандомно, что несколько сглаживает возможность коллизий, хотя и не исключает их совсем.