Сталкер-Стрелок

Ты меня не понял. Флаг добавляешь в инит биндера, если он появляется у объекта - биндер существует, нет - валишь игру. Я не об объекте биндера. Да тут, понимаешь, в двух словах не пояснишь, возьми готовый вариант и попробуй погонять корректные и некорректные скрипты, поймешь алгоритм где заваливается работа этой системы. Какие конкретно у тебя цели я не знаю, но у меня, например, вполне симпатично все работает. Очевидно на основе твоих биндеров, биндер выступает, к примеру, значением таблицы, ты проверяешь не только сам файл на nil, но сразу и биндер. Проверяешь не на объекте, а обычным луа, на как-раз таки ошибки этого синтаксиса, т.е. опуская саму функцию биндинга. Надеюсь понятно объяснил. Извини, ухожу.

@UnLoaded, зачем тебе он?

@Zander_driver, если речь только о проверке биндера, то ты же сам что-то такое изобретал, можно заваливать игру если объект биндера не подает признаков жизни. Вставь abort куда нужно (например можешь в ините ставить булево поле о инициировании, и если его нет заваливать игру), и в целом будет решено. Если цель выявить некорректные скрипты как файлы с различными модулями, то есть хороший вариант с песочницей на мотив ЗП, который не пропускает таких инвалидов. Если хочется перебирать, разумно будет составить таблицу биндеров и итерироваться по ней, там объектов будет наверняка меньше 65т.

@Outfater, твой вопрос некорректен, советую почитать что-нибудь по рестрикторам, конкретно обрати внимание на обработку конфига логики, я думаю вопрос разрешится. @Zander_driver, в параллельной теме как-раз это обсудили вот только что, по-моему даже с готовым примером. Общно, нужно полю fixed_bones присвоить основную кость и записать кастом дату, что-бы не шумело.

@Zander_driver, твои претензии совершенно не уместны , к примеру я вообще поста не видел. Сам разобрался - молодец, но все же подскажу свой вариант: local vdis = actor_position:distance_to(vpos) local function check() local function in_f( v1, v2 ) return (math.acos((v1.x*v2.x + v1.y*v2.y + v1.z*v2.z)/(math.sqrt(v1.x*v1.x + v1.y*v1.y + v1.z*v1.z )*math.sqrt(v2.x*v2.x + v2.y*v2.y + v2.z*v2.z)))*57.2957) end local yaw = in_f(device().cam_dir, vpos:sub(db.actor:position())) return yaw < 35 end if vdis < scan_distance and check() then table.insert(vertex_bufer, {current_vertex, vpos}) end С таким отношением отпадает всякое желание вести сотрудничество.

Тогда стоит научится азам СДК. При современном интернете скачать эту программу не так сложно, для того, что-бы посмотреть кости нужно сделать один батник для конвертера и открыть в СДК получившуюся модель, и все кости будут видны. Это экономически выгоднее, чем способы предложенные выше. dump ogf конечно тут вырывается вперед, не спорю. Неправильно он сдвигается с точки зрения того, что именно ты хочешь от этого мешка, кому-то возможно понадобится именно такие его движения, и ему будет нужна не основная кость. Это скорее исключение из правил, но тем не менее. Извини, вопроса не понял. Или это риторический?

@Comador, фиксация может идти по любой кости. @UnLoaded, коллизия в любом случае произодйет у объекта когда об него "запнется" ГГ или нпс/монстр. По уму нужно править кастом дату. Смотря какие цели у мода, серьезным и объемным может быть и текстурный мод, и мод, который модернизирует и исправляет логику поведения, к примеру. Можно еще несколько вариантов привести.

@HellRatz, введя кассеты как итем можно создать квесты, где задание будет записано на кассету, ну или не обязательно задание, а какая-то загадка или вроде того. В общем как в пиле .

Может кто-то пример привести того, что указано в шапке? И дописать описание недостающего. У меня к сожалению нет времени самому разобратся.

@BFG, судя по твоим постам, сообразительность - не твой конек. Тут явно предлагают и обсуждают не первую страницу о реструктуризации xrGame.dll, я даже не предаствляю кем надо быть, что-бы это не понять.

@UnLoaded, вывод очевиден, это и есть те тонкости о которых я упомянул .

@UnLoaded, еще кастом дату надо написать, что-бы не гудел. К тому же есть экспортированный класс для работы с фиксацией костей, только там тоже есть свои тонкости, но всеже лучше работать с ним.

@Anonim, ну а чего еще надо? Посмотри на параллельную кухню - относительно готовые варианты оптимизации скриптов - каждый делает исключительно свой вариант, и панацеи еще пока никто не придумал. Широкое применение нашли точечные решения мушкетера, но в общем его вариант целиком и полностью никто не взял, потому-что постоянно все развивается, и акутальное сегодня - не нужное завтра. С движком таже история, но с ним работать тяжелее в плане адаптации, так как вносить изменения порою приходится вплоть до ассемблера. Что-бы что-то в него внести достаточно разобратся в модуле и в прилегающих файлах высшего порядка (как правильно не знаю, профильных книг не читаю). Я пока трудностей не увидел. Но в целом если-бы каждый модуль лежал бы отделной библиотекой - тут ничего плохого не вижу, было бы удобнее, и правки времени бы отбирали столько же, сколько у скриптов.

@Elz, Я об этом, о реструктуризации файлов. Раскладывать код по полкам тоже палка о двух концах как мне думается. Но если кто начнет - будем поглядеть.

Почему? Собирай на дебаге. Ню-ню. @Elz, зачем нужна реструктуризация?