Malandrinus

Нашёл. Но фича выглядит недоделанной. Т.е. конвертирует, но неправильно. Однозначно получается не то, что было исходно. Траектория совершенно не та, при этом направление камеры вообще не меняется. Фича не анонсирована и отсутствует в описании и встроенной справке программы. Может именно по причине недоделанности? Кому-нибудь удалось с её помощью получить осмысленный результат?

stunder, SDK хорош всем за исключением одного, нужен SDK =) На самом деле нужен ещё и декомпилированный уровень, на котором делаешь облёт. По себе могу сказать, что это огромное, иногда просто непреодолимое препятствие для применения этого способа. Так что я до сих пор думаю, как бы сконвертировать файлы демозаписи в anm. Kolmogor, а какая версия? У меня апрель 27 2008. Там вроде такого нет.

IQDDD, скрипты здесь не при чём. Это делает сам движок. В состоянии разговора заставляет актора смотреть на собеседника. Скриптами сделано только удержание собеседника перед актором.

В связи с внезапным окончанием бета версии Visio красивая картинка с иерархией оконных классов откладывается =) Так что сейчас разберём общие вопросы, т.е. В неохваченном осталась тема о создании окон на основе XML описания. Для этого есть класс CScriptXmlInit. Он сам по себе несложен, но к нему надо ещё и описывать форматы XML файлов для разных окон, а к этому я сейчас морально не готов =) Также есть ещё достаточно сложная тема о модификации стандартных окон: торговли, PDA и прочего. Здесь на помощь может прийти функция level.main_input_receiver(), которая возвращает текущее активное окно. Приемы работы в этом случае достаточно нетривиальны. Кроме того, в ЗП этой функции нет. Может как-нибудь и дойдут руки...

IQDDD, Этот класс по-моему не имеет прямого отношения к состоянию отдельно взятого контрола. Что-то для работы с настройками. P.S.: Я может вопроса не понял. Сохранить - что означает? Сохранить до следующей игры?

IQDDD, насчёт колбеков сейчас точно не могу сказать. Либо что-то не то делаешь, либо они не работают. Можешь ещё попробовать для чекбокса "кнопочные" события типа BUTTON_CLICKED. Насчёт сохранения, пошарь методы для CUICheckButton двумя постами выше =)

Привожу описание системы классов для построения оконного интерфейса. Описание приводится для ТЧ и ЗП. Для ЧН специально не выделял, но следует учесть, что в этой части ЧН ближе к ТЧ, нежели к ЗП. Описание есть только для некоторых методов, но чаще всего о назначении и так можно догадаться. Точные типы аргументов и возвращаемых значений приведены для всех без исключений методов. Надеюсь в скором времени дополнить данный пост дополнительной информацией в этом направлении: будет диаграмма классов для общего развития и несколько общих слов о применении всей этой системы в целом.

IQDDD, эффектор - это строго определенная последовательность повторотов и перемещений камеры. Т.е. на конкретный угол тебе нужен отдельный эффектор. И это временно. Т.е. отработает эффектор и вернется все как было. Насчет "как комбинировать" не понял. Что тут непонятного? так obj:object_binder(nil)

IQDDD, попробуй вызвать метод клиентского объекта bind_object с аргументом nil. Не уверен, правда, получиться ли это. никак. Как частное решение можно комбинировать с эффектором камеры. Но это, понятное дело, общей проблемы не решает.

shooting unicorn, Смотря что сделал. Если, к примеру, потёр инфопорцию, которая выдана или будет выдаваться, то скорее всего словишь вылет. С самой общей точки зрения без начала новой игры допустимы добавления новой информации в файлы конфигов (как XML так и ltx). Удаление чаще всего приводит к проблемам. Изменения допустимы в зависимости от характера, одним словом не опишешь.

Elite на ZX Spectrum-е (да там вообще не упомнить всего). на PC: UFO все части, Total Annihilation, Parkan, Deus Ex, Half-Life, MYST (не все прошёл, только первые части)

Drunken Master, да вроде как никто о движке и не говорил. =) как тот цыган из анекдота

REMEDI, А вы выразите это иначе: люди решили реализовать то, что им не дали сделать или не было возможности сделать при работе над сталкером. Григорович же их не с потрохами купил. Это люди со своими амбициями и желаниями. Ушли от него и унесли свои идеи с собой. Нормальная ситуация. Они не просто не вошли, их никто в итоге там и не делал. Поэтому все разговоры о плагиате беспочвенны. Все шутеры с монстрами похожи друг на друга. Все пост<что-там> игры похожи друг на друга ещё больше. Сталкер такой исключительный только в глазах жителей бывшего Союза. Для западников это обычная игра. Метро - тоже обычная игра. Это уже разговор о другом, не о плагиате. Можно и об этом поговорить, но вроде как для сравнения этих двух игрушек есть отдельная тема.

ZeeK, В смысле не работает? Ничего там не изменилось с предыдущих версий.

_Призрак_, из alife.ltx, ничего вызываться не может. Там просто прописывается его имя. Движок читает конфиг и затем вызывает функцию с этим именем.

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

_Призрак_, Из вызываемых без затей с классами и прочим могу посоветовать из _g.script: on_actor_...() таких там несколько штук start_game_callback() там же

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

_Призрак_, Не моя =) Это вроде бы известная GNU утилита. Хотя я о ней не знал сам, пока не потребовалось найти, чем применять dif файлы.

_Призрак_, Класс отвечает за поведение и данные, учебник ООП вам в руки. Конкретно эти два класса отличаются тем, что CWeaponAK74 может иметь подствольник, а CWeaponLR300 - нет. Впрочем, ничто не мешает в игре использовать максимально обобщённый ствол, урезая его конфигами (что обычно все и делают). серверный: CSE_ALifeItemBolt клиентский: CBolt скриптовое имя сета: clsid.obj_bolt конфиговое имя сета: II_BOLT В движке внутри зарегистрировано более сотни сетов. class_registrator просто расширяет этот набор. внутренний номер класса генерируется на основе строки II_BOLT по простому алгоритму. Для некоторых сетов почему-то этот номер не генерируется из строки, а явно прописан числом. В частности так сделано для болта.

Real Wolf, Зарегистрированную - это я так понимаю, к которой прицеплен колбек на нажатие? Как таковую кнопку удалить с родительского окна можно, но колбек на нажатие на кнопку с таким именем уже намертво будет связан именно с этой кнопкой (видимо как объект кнопка не удаляется при наличии колбека на неё). Т.е., если планируешь кнопку создавать обратно, то лучше кнопку не удалять, а просто скрыть.

nuklia, может версия не та? Попробуй найти 5.5

7.9, Сделано наложением дополнительного физического объекта, который и реагирует на хит. Хороший подход. Задачу в общем-то решает.

gruber, sapsan, хорошо, что напомнили. Я и сам об этом забыл. Ящики не просто не имеют визуала, даже если им прописать видимый визуал, это не поможет. Этот объект не имеет и не может иметь физической оболочки, что означает, что он не отрабатывает столкновений и значит не может генерировать событие хита. Так что косяк неустранимый.

Rolan, Я ценю ваши старания, но давайте таки определимся. Это не исходники. Исходники - это то, что писали разработчики, и они их никому не давали. А это - сгенерированный идой текст. Его нетрудно получить самому. Загружаем в IDA pro вашу dll и делаем File -> Produce File -> Create C File... Толку от этого текста чуть менее, чем ничего. Потеряна информация о типах, точных сигнатурах и именах функций, именах аргументов функций, шаблонах C++ и ещё куча всего. Существенная часть функций не распознана (поскольку ссылки на них сделаны не вызовами, а косвенные). Комментариев в этом тексте естественно нет (хотя не факт, что они и в исходниках были =). Отсутствует деление на файлы (а между прочим в одном только xrgame.dll файлов исходного текста несколько тысяч). Читать этот текст и извлечь из него полезную информацию невозможно. Это не значит, что декомпилятор hex-ray из IDA бесполезен. Напротив, полезен весьма, но использовать его имеет смысл точечно. Вот нашли функцию, которая делает что-то (и вы знаете что именно), тогда уже именно эту функцию и пытаетесь декомпилить, чтобы понять, как именно она делает то, что делает. И это не избавит от необходимости смотреть в окно дизассемблера, уж поверьте. С практической точки зрения более интересным и информативным представляется разбор файлов билда MP 2947, которые шли с отладочными дампами. Насчёт законности. Вся эта возня не более и не менее законна, нежели прочая деятельность модостроителей (т.е. вообще говоря незаконна, почитайте лицензию к игре, параграф 1). AK74, Для начала, Lua здесь используется в связке с JIT копилятором. Т.е. интерпретируется текст только при первом исполнении, затем уже исполняется скомпилированный код. Такой же принцип используется в исполняемой среде .NET. Естественно, это помедленнее будет, чем код движка, но не так уж драматически медленней. И потом на скриптовую часть не ложится большая нагрузка (естественно до тех пор, пока какой-либо новичок не начнёт делать при каждом апдейте перебор всех объектов =). Потом, утверждение о "переносе функций из скриптов в движок" - это ерунда из того-же разряда, что и разговоры о протекторах и прерываниях. Я утверждаю, что движок в той части, что соответствует xrgame.dll (т.е. вся игровая логика) практически мало изменился за все три игры. В лучшем случае была проведена работа по исправлению ошибок и может быть некоторой оптимизации. Практически все функции, которые были экспортированы в ЧН и ЗП по сравнению с ТЧ - это функции, которые там имелись изначально (т.е. ещё в ТЧ), просто были экспортированы в Lua и даны в распоряжение скриптёров. Т.е. выходит картина с точностью до наоборот - в новых версиях движка скриптёру предоставляются потенциально более широкие полномочия. Вот ведь... Господа, есть форумы и тьма их, на которых только тем и занимаются, что обсуждают ломание всяких защит и прочее в этом роде. Но обсуждать это здесь, при том, что никаких защит тут нет - это уже не смешно даже. Это к сожалению невозможно. Совсем. Всё, что можно сделать в этом направлении, уже сделали разработчики. _Призрак_, Это всё-таки именно имя, не более. Только учтите, что в IDA есть только адреса ячеек памяти, поэтому это просто метка адреса. Имя метки IDA определяет при первичном анализе. Если по каким-то причинам IDA сочла, что по этому адресу лежит 4-х байтовый float, то имя составляется как flt_virtual_address. В дальнейшем вы можете изменить как это имя, так и интерпретацию содержимого памяти по этому адресу. Есть замечательная утилита PE Tools, которая позволяет это сделать.