Malandrinus

singapur22, спасибо! Пара дополнений: не sid, а именно clsid. Этот метод возвращает числовое значение зарегистрированного сета, т.е. пары серверный/клиентский классы. Если помните статью про регистрацию классов, то мы в class_registrator.script пишем так: cs_register (object_factory, "CBurer", "se_monster.se_monster", "SM_BURER", "burer_s") здесь CBurer - клиентский класс, se_monster.se_monster - серверный класс, burer_s - скриптовое имя сета. Такая константа появится в классе clsid и можно будет к ней обращаться как clsid.burer_s. При этом этой константе будет назначена уникальное числовое значение. SM_BURER - конфиговое имя сета. Это то, что указывается в параметре class в секции объекта. Вот как раз это значение и читается методом r_clsid. При этом метод возвращает то же значение, что и соответствующая константа из класса clsid. В игре движок читает таким образом только параметр с именем class, но в скриптах функция будет работать для параметра с любым именем (просто в этом нет практического смысла). как раз с изменениями! Эта функция удаляет из читаемой строки все пробелы и табуляции. Таким образом, если в конфиге было: [section] param = ab cd 1; 2 4; ef 5 то вызов ini:r_string("section", "param") вернёт "abcd1;24;ef5", т.е. без пробелов. Это даже бывает иногда удобно, но часто таки надо получить нормальную строку. Для этого можно использовать таблицы строк и глобальную функцию game.translate_string(string). Но можно воспользоваться второй функцией Эта функция читает также параметр как строку. Если двойных кавычек вокруг строки нет, то она работает в точности как r_string, а вот если кавычки есть, то функция эти кавычки удаляет, а строку оставляет без изменений. Т.е. все пробелы остаются на месте. В заключение несколько глобальных функций для работы с файлами конфигураций в целом: ini_file(<имя файла>) -- можно воспринимать эту функцию, как конструктор класса ini_file (в стиле Luabind), а можно как просто глобальную функцию для открытия файла с произвольным именем. system_ini() -- возвращает открытый файл с именем "config\system.ltx". Комментарии излишни. Это главный конфигурационный файл всея игры со всеми своими включениями, распакованными и в архивах. game_ini() -- аналогично возвращает открытый файл с именем "config\game.ltx". Тоже между прочим важный файл, содержаший информацию о всех локациях и ещё некоторые полезные вещи. create_ini_file(<строка с текстом файла>) -- интересная функция, которая позволяет сделать объект ini_file в памяти без собственно физического файла на диске. Аргументом является текст файла конфигурации целиком со всеми переносами строк. Также стоит упомянуть методы классов: cse_abstract:spawn_ini() -- возвращает custom data серверного класса game_object:spawn_ini() -- аналогично для клиентского класса

KD87, движковые сеты надо конечно знать, но их фиксированное число. Я естественно говорил только о скриптовых. Но если подумать, то да, выходит, что надо ещё и вытаскивать из скриптов ту добавку, что они добавляют в нетпакет, а это уже автоматизированно не сделать. Признаться, вот это само по себе вызывает вопросы. В аллспавн значит данные есть только до cse_anomalous_zone, между тем как se_zone_anom представляет собой cse_anomalous_zone + флажок 1 байт + время (при флажке == 1). Вот как может быть скриптовый класс se_zone_anom, если в спавне для него нет данных? Он прочитает пакет до конца cse_anomalous_zone и будет читать дальше, но дальше то нет ничего. Он прочитает не понять какое значение флажка, а потом ещё и может попытаться прочитать какое-то время. Вот это и странно. Это вообще работает? Нет ли здесь большого косяка?

KD87, Мы же всегда читаем имя секции в составе данных cse_abstract. Дальше можно остановиться, прочесть секцию в конфиге и узнать имя сета, прочесть class_registrator и по имени сета найти скриптовый класс, прочитать скрипт, найти объявление класса и узнать базовый движковый, ну и парсить данные дальше уже точно зная имя класса. И не надо заморачиваться на точное знание соответствий секций и классов. Надо конечно закешировать найденное соответствие, не делать же эту процедуру на каждый объект. Правда придётся подсовывать в придачу к папке конфига ещё и папку со скриптами.

KD87, Ну к примеру, чтобы хранить какие-то данные в серверном классе. Да и вообще, мало ли кто добавит свой новый класс для какого угодно объекта. Мне однако интересно, как можно разрулить это автоматически. Получается, надо прочитать из секции имя сета, найти скриптовый серверный класс в class_registrator, потом разделить имя на модуль и имя класса, разпарсить модуль и найти объявление класса вида class "имя класса" (движковый класс) тогда можно найти собственно движковый класс и понять, как разбирать пакет. Perl я не знаю, но там кажется регулярные выражения рулят, так что это сделать несложно.

KOKC, Если задержишь скрипт, то тем самым задержишь и всю игру. Если же ты хочешь, чтобы игра продолжалась, а через 5 секунд выполнилось то, что тебе надо, то это решается через установки проверки в апдейте актора. По проверке на прошедшее время выполняется действие, снимается флажок, чтобы перестать проверять и т.д., как сам организуешь. Из готовых решений есть таймеры АМК, которые в сущности это всё и делают, но делают также много другой ненужной работы.

Desertir, Значит надо изменить расчёт так, чтобы уменьшить все полоски, чтобы влезали.

Desertir, Полоски рисует движок, их не убрать. Непонятна проблема. Если не нравится, как этот скрипт рассчитывает длину этих полосок, то что мешает заменить его на свой расчёт? Именно для этого этот расчёт и вынесли в скрипт. Уберите всю арифметику, которая вам непонятна, и замените на свою.

Massaraksh, Это не получится.

KOKC, надо создать окно на основе XML и там в XML задать параметр heading="1". Тогда будет реагировать на задание угла.

Vergas, Согласен, нечего здесь делать. Кроме бесконечного нытья здесь ничего почти и не происходит. adiós Строгое предупреждение от модератора Portezan Предупреждение!

Vergas, а чего ты такой серьёзный? Вроде взрослый человек, а пафоса развёл, что пятнадцатилетний школьник. И вокруг чего, вокруг компьютерного шутера.

Все эти разговоры об "атмосфере" мне напоминают дебаты о "теплом ламповом звуке". Никогда не понимал, а что собственно имеют в виду под атмосферой. Вполне возможно, что большинство игроков попросту ностальгируют по первым впечатлениям от ТЧ: вот ролик - ух круто, каморка Сидора - ух рожа, вылезли на поверхность - всё незнакомое такое, первый кабан - вот тварина, первый раз в аномалию угодил - что за хрень такая и т.д. Господа, смиритесь с тем, что это всё было тогда в первый и единственный раз. Никакие усилия разработчиков не позволят обеспечить на том же сеттинге ту новизну впечатлений. А по мне так все продолжения были вполне достойны. ЧН так вообще на уровне первой части. Вот только бы багов в первых патчах поменьше, и было бы вообще ничего.

Kirag, насколько я понимаю, все схемы и состояния так или иначе сводятся к вызову одного из вариантов функции set_sight. Вот чуть более полное описание аргументов, чем сейчас в справочнике: // куда смотрит void set_sight(enum SightManager::ESightType <sight_type>, const vector*, DWORD dwLookOverDelay); void set_sight(enum SightManager::ESightType <sight_type>, const vector&, bool <torso_look???>); void set_sight(enum SightManager::ESightType <sight_type>, const vector*); void set_sight(enum SightManager::ESightType <sight_type>, bool <torso_look>, bool <path>); // на кого смотрит void set_sight(game_object* <object_to_look>); void set_sight(game_object* <object_to_look>, bool <torso_look>); void set_sight(game_object* <object_to_look>, bool <torso_look>, bool <fire_object>); void set_sight(game_object* <object_to_look>, bool <torso_look>, bool <fire_object>, bool <no_pitch>); Думаю, одна из них сработает так, как тебе надо. Однако с логикой всё равно может конфликтовать.

Обычный скриптовый хит и пинает. Степень физического воздействия определяется параметром impulse.

Sync, Что за событие?

Моды бесплатные по определению, иначе это уже бизнес со всеми вытекающими. Нет ничего плохого в том, чтобы хотеть за свою работу денег. В сущности, ничто не мешает делать по сути те же моды на коммерческой основе. Это называется аддоны к играм. Могу ошибаться, но вроде как многие движки позволяют делать такие аддоны с нулевым стартовым капиталом. Однако, идея о том, что модостроители работают на совершенно безвозмездной основе - это миф. Я уже здесь об этом говорил. Модостроительство - это разновидность опенсорсных free разработок. Хотя в чистом виде это не совсем тот "free", что к примеру GPL софт. Однако психология разработки похожа. Профитом являются репутация, знания и опыт, а также fun, что можно перевести как "радость от жизни". Те, кто думают, что эти вещи неконвертируемы, очень сильно ошибаются. Для большинства людей это вполне реальные ценности. А я смотрю, сюда заглянул bac9-flcl. Может порадует нас новостями?

Полтергейст, этот колбек (callback.zone_enter) работает только для одного класса ce_script_zone. Движковый сет для этого класса имеет имя SCRPTZN, имеется готовая секция с именем "script_zone". Из всех трёх игр этот объект используется только для ТЧ для Арены. Собственно там и можно посмотреть пример использования этого колбека. Это файл xr_zones.script

Artos Правда?! Нет, в самом деле? Так это обнадёживает. Я то был искренне уверен, что всем глубоко по барабану. Особенно злостную полемику я отсюда вычищаю, а немногие статьи, написанные не мной, берегу как редкую драгоценность =) Можешь пролистать и убедиться сам, насколько беспочвенны твои опасения по поводу "бездумно набежавших". По поводу XML. Я написал: не вижу, что здесь неправильного. Я написал "почти", что вполне покрывает те единичные случаи, когда элементы настолько динамичны, что даже создавать их через XML смысла нет. Но эти случаи действительно единичны. И в общем основной тезис - "модостроители не знают возможностей XML" (почти все). Если человек знает все возможности, то ему мои рассуждения побоку, сам решит. Нет, не проще. В подавляющем числе случаев трудозатраты на создание нескольких вариантов конфигов будут гораздо меньше, чем на вариативный код. Собственно, поэтому и придумали идею разделения кода и данных. Кроме того, см. ниже. Таки да, будет тем же, поскольку в сталкере для интерфейса используются виртуальные координаты, и экран всегда имеет размеры 1024х768 вне зависимости от физического разрешения. Поэтому достаточно только создать варианты конфигов для отдельных пропорций. А учитывая доминирование всего двух пропорций задача становится не такой уж и неподъёмной. По большому счёту, для нестандартных пропорций можно мириться с небольшими искажениями.

Garry_Galler, спасибо за вклад в тему! Очень полезная информация. Описание только движковых классов/функций, хоть и не закончено, но постепенно себя исчерпывает. Между тем остаётся немерянный пласт скриптовых наслоений, которые в сущности являются частью движка, поскольку используются уже поколениями модостроителей практически без изменений. Вот как минимум механизмы логики относятся к этому разряду. Их тоже можно было бы описать здесь. Artos, по мне так лучше, если бы писали здесь статьи хоть как-то, пусть и криво. Почистить и упорядочить в конечном счёте можно, если есть что чистить и упорядочивать. А последнее время вижу только смесь стола заказов и отделения ковырялки. Разумеется, крайне желательно придерживаться примерно такого шаблона изложения (применительно к классам): 1. Общее назначение класса. В объёме одного абзаца или даже предложения объяснить, зачем вообще нужен данный класс. Какой объект он описывает или что можно сделать с его помощью. В случае с CScriptXmlInit это могло бы выглядеть таким образом. Класс CScriptXmlInit предназначен для создания объектов окон (или объектов пользовательского интерфейса) на основе описания, заданного XML. Выгод от использования данного класса может быть несколько: - вынос громоздкой инициализации во внешние XML файлы позволяет сделать правильное разделение данных и кода, что делает код более компактным, читаемым и в конечном счёте более управляемым. - возможность задать свойства окон, недоступные для изменения скриптом. К примеру, так можно задать перенос текста в текстовых полях. В сущности, это самый правильный способ создания окон. При желании можно всегда скриптов изменить нужные динамические характеристики окна. Полностью же скриптовое создание окон используется модостроителями почти всегда только лишь по причине незнания возможностей XML. 2. Формальное описание. Примеров таких описаний я наплодил достаточно много. Я предпочитаю некий псевдо C++. В данном случае может выглядеть так. class CScriptXmlInit { CScriptXmlInit (); // конструктор, как и для большинства других классов соответствует глобальной функции CScriptXmlInit void ParseFile(string <имя XML файла>); // прочитать файл с описанием окна // инициализировать (не создать) окно базового типа, родительское не задано bool InitWindow(string <имя тега с описанием>, int index, CUIWindow* <окно для инициализации>); // создать окно типа CUIStatic, статический элемент CUIStatic* InitStatic(string <имя тега с описанием>, CUIWindow* <родительское окно>); // создать поле для редактирования текста CUIEditBox* InitEditBox(string <имя тега с описанием>, CUIWindow* <родительское окно>) // и т.д. } 3. Общие комментарии к описанию. - В целом класс CScriptXmlInit предназначен для компактного с точки зрения кода создания элементов управления, т.е. разных специальных окон, расположенных на родительском окне диалога. Поэтому все методы создания имеют второй аргумент - ссылку на родительское окно. Это то окно, на котором будет расположен создаваемый элемент. - Только один метод работает не так. Это метод InitWindow, который предназначен для инициализации самого родительского окна. Обращаю внимание, что этот метод не создаёт окно, а только задаёт его параметры (к примеру размеры). Ссылка на уже существующее окно, требующее инициализации, передаётся третьим параметром. - Все методы принимают аргумент - имя тега, содержащего описание окна. Формат тега, дополнительные теги внутри него и атрибуты тега зависят от создаваемого окна. Их полное описание выходит за рамки данной статьи =( 4. Примеры использования. Например так. local xml = CScriptXmlInit() xml:ParseFile ("ui_game_over.xml") xml:InitWindow ("main",0,self) -- здесь self - это ссылка на экземпляр диалога - окна верхнего уровня (не имеющего родителя) local st = xml:InitStatic("background", self) -- создать на диалоге статический элемент на основе описания из тега "background" self.scroll_view = xml:InitScrollView("scroll", st) -- создать на диалоге выпадающий список, описанный тегом "scroll" К сожалению для класса CScriptXmlInit этого будет недостаточно, поскольку за каждым методом стоит ещё и описание всех сопутствующих тегов и атрибутов тегов, коих могут быть десятки. В целом же класс самоочевиден. Именно поэтому я его не описывал.

Desertir, а для чего класс то предназначен и что вообще с ним делать? Из поста совершенно не ясно.

Desertir, Не полное описание, но минимальный набор приёмов использования есть в этом посте справочника.

Real Wolf, перечитываю твой предыдущий пост и никак не могу понять, что именно ты пытаешься сделать. Какие такие новые данные? Что за новый размер? Такое ощущение, что ты какой-то ересью пытаешься заниматься. Показал бы код что-ли. Только не здесь. Запости вопрос в ковырялке.

Real Wolf Часом не в онлайне пытался это делать?

Whisper, Попробуй отрицательных денег дать.

Народ, у вас интересное обсуждение, но мне же придётся его потереть как оффтоп. Жалко ведь! Так что идите вы... в ковырялку.