Zander_driver

@Verberes, Раз уж речь идет про удаление сжета, то я бы заодно предложил поудалять все рестрикторы из аллспавна, кроме тех что к кострам пришпилены. Хуже не будет, а от всякой сюжетной "автоматики" избавитесь. И кстати да, правка аллспавна тоже влечет за собой новую игру. Так что лучше в один присест сделать и то и другое.

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

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

Аналогично, коллега. И собственно так и делаю, если открыть скрипт моего инвентаря и набрать в поиске "xml" - ничего не находит. Я не пользуюсь никакими обращениями к xml-конструкциям вообще. У меня переносит спокойно... весь вопрос в том, что есть окно, что есть перенос текста. и как найти в тексте эту "\n"... Да, для этого приходится ручками переписать кое-что из того, к чему пользователи Виндовс привыкли как к тому что "само делается". но не так уж это сложно. Например, хоть одну назовите? или "не-управляемых" это опять о классах, исходно выданных движком, а не собственными руками написанных. Давно завел себе правило - если какая-то система не желает работать как мне надо, не дает мне средства управлять тем что мне надо, я посылаю ее куда подальше и пишу свою. Движок крутить для этого не требуется, все можно создать в скрипте. Мне вообще то казалось что все достаточно очевидно. Написать для его реализации надо много, но кроме числа строк все остальное, все принципы - простые. Есть некоторый набор итемов, принадлежащих актору, по ним можно получить определенный комплекс информации, и так или иначе отобразить эту информацию на экране. Получение информации о наличии итемов - это собственно известные всем функции скриптов. Отображение на экране, такое как хочется и как вздумается - задача для гуи-классов, тот же принцип, если "выданное движком" не работает как надо, то пишем свое. Я вообще не заморачивался и из экспортированных классов взял один CUIStatic, одел его в класс-оболочку, который позволяет с ним работать более нормально и удобно, и уже из этих классов как из кирпичиков, построил все что мне требовалось. Дополняя новыми классами, своими опять же, при необходимости. Я ответил на вопрос? если нет, то прошу уточнений, о чем идет речь. А я не могу написать свое окно, у которого можно будет менять все-какие-захочу параметры, вообще никак не меняя код? Да неужели. Может потому что для 99% авторов сделать другие - не представляется возможным?

С таким подходом, скоро не останется модов, которые вы себе поставить сможете А вообще - как то тут у вас интересно стало. Но, к слову - хоть я и знаю о возможности перезагрузки xml, она даже у меня есть, как-то не пригодилось. xml сам по себе горбат и неудобен, это уж мое личное имхо, не говоря уж о том что без довольно существенных телодвижений, он таки остается прибитой гвоздями статикой. Когда-нибудь вытравлю его отовсюду где он не нужен, ltx-конфигов и скриптов в сумме более чем достаточно в большинстве случаев.

Сильно подозреваю что ныне - без ковыряний в движке никак, ибо диалоговый интерфейс - штука движковая. Ну или соорудить ему взамен скриптовый аналог и устанавливать свои правила. Какие вздумается.

Ну вообще я не про news_manager, если только он тут просто для примера... Вспомните как выглядит диалог в xml. удобно его писать там? Удобно вникать, где что? А если предположим, когда-то ранее созданный диалог, да еще с довольно сложной структурой, изменить-доработать захотелось, удобно ли это будет делать? Может быть у кого то другое мнение, незнаю. Лично для меня на все эти вопросы ответом оказалось "Нет". сама форма представления диалогов в xml - громоздкая и неудобная на мой взгляд. В ltx-конфигах все получается компактнее, нагляднее и удобнее. И существенно проще для последующего редактирования, если понадобится. Кроме того, несколькими постами выше уже описывалась ситуация, как себя ведет в xml составленный диалог, в случае банальных опечаток. либо тихо-мирно игнорирует ошибку, не делая ничего, там где вообще-то надо что-то делать (action), и не давая модмейкеру ни намека, почему же у него что-то не работает, либо так же тихо-мирно валится на рабочий стол, опять же не давая ни намека почему конкретно, т.к. лог-файл пуст. Искать ошибку телепатически, это же безумно удобно, да? а я почему то решил что нет... Если слегка призадуматься, несложно понять, что при формировании диалога скриптом, оба случая несложно отловить еще на этапе формирования диалога, проверив существуют ли заявленные функции, и - внимание! - выгрузить игру на рабочий стол с предельно ясной и подробной информацией в логе, что, где, почему. Там же можно отловить и ошибки криво составленного диалога, которые насколько я помню, присутствовали даже в O.G.S.E. И ведь такую малость надо сделать чтоб искоренить саму возможность таких ошибок, но - "никому не надо"... И к слову о переводчиках на другой язык, сами тексты - из xml-файлов переносить вовсе не требуется.

Ищу модели более современных образцов авто-техники, чем те что представлены в оригинале ТЧ, т.е. всякие там "Газели", "Лады-Калины", иномарки мб, и т.д. в таком духе из того что по нашим улицам каталось и катается после распада СССР. можно (даже желательно) в битом / ржавом виде, можно (даже желательно) в качестве физ.объектов - декораций, а не как модель для транспорта, вобщем все в таком духе, если кто-то такое делал или выдирал из метро каким-то образом (там помнится, Газели были) - поделитесь ссылкой. Заранее спасибо.

Да получается что из центра зоны, отправляют грузовики с потенциальными Мечеными. гру-зо-ви-ки. Кто-нибудь видел под ЧАЭС филиал автозавода "Зил"? я нет. стало быть эти грузовики там еще и откуда-то берутся, не из воздуха же их делают. то бишь чтобы задумка авторов стала возможной, надо регулярно эти грузовики на ЧАЭС пригонять, а затем оттуда же отправлять, но уже со "смертниками". Какая то ахинея в квадрате получается, если честно Я думаю не стоит все же слишком пристально цепляться за многие моменты оригинального сталкера, по одной простой причине. На момент релиза ТЧ, концепция зоны, даже самими авторами игры, вовсе не была так уж хорошо продумана и взвешена, и в ней хватало нестыковок. Благо теперь мы имеем возможность все взвесить получше, и таких нестыковок не допускать в своих модах.

Респавн оригинальный у меня отрублен полностью. А свой - вызывается только в определенные моменты, после выброса + два раза в сутки в определенные часы. Больше никогда. Длительность апдейта актора именно что нормальная. кручение головой - не влияет, смотрел себе под ноги на серый бетон, происходило то же самое. Чем таким может заниматься движок, вопрос хороший... и в каком месте искать причину.

А я тут наведаюсь с вопросом... для Кашпировских, если честно. Потому как сам ничего пока не накопал, хотя вроде постарался. Знал бы точнее - решил бы сам, свою проблему. Есть просто небольшая надежда что у кого-то подобное было и дадут подсказку в какую сторону копать Собственно, суть проблемы. Периодически какими-то "наплывами" происходят странные тормоза. Причем, мониторинг апдейтов всех биндеров всего-на свете, который я к слову в соседней теме и выложил, показал что все там нормально, в том числе апдейт актора и все что к нему прицеплено. Никаких заоблачных цифр нигде не нашлось. Входов в онлайн/выходов в оффлайн массовых тоже не происходит ни у каких объектов, ГГ неподвижен, массовых миграций кого-то/чего-то тоже не происходит. А при наступлении этих тормозов (которые повторюсь, не постоянно а некими "наплывами") - время самого апдейта актора, остается то же, все прочие апдейты всех объектов - те же, Но, время между апдейтами актора становится равно ста миллисекундам. т.е. апдейт 10 раз в секунду, delta сообщенная движком = 100. и так по несколько апдейтов, затем опять поехали нормально. По апдейтам проверял актора, неписей, монстров, физ. объекты, рестрикторы не стал (они ведь через актора обновляются?), гулаги-смарты, менеджеры кампов и анимаций, везде время сжираемое на апдейты в пределах нормы, более чем. У кого есть идеи что это может быть? куда еще стоит воткнуть profile_timer чтоб посмотреть? зы. если это я сам что-то нахимичил то я же и раскопаю, не переживайте. Вопрос задается единственно на случай если у кого-то такое было.

Я тут соорудил у себя такое: скриптовый элемент худа, позволяющий вести мониторинг состояния различных биндеров и др.объектов, пользующихся апдейтом. В реальном времени можно наблюдать, сколько у нас в игре таких объектов, сколько они жрут процессорного времени на свой апдейт, и как вообще поживают, не зависли ли часом. Единственный момент, из-за того что выведение на худ вызывается внутри апдейта актора, система не обнаруживает зависание его биндера. Это делается извне, другими средствами. Хотя если у кого-то биндер актора зависнет это сразу станет видно по тому, что показания этой системы обо всех категориях объектов перестанут меняться. Решил выложить - вдруг кому пригодится, потому что держать именно эту систему до выхода "Судьбы Зоны" - смысла не вижу, вряд ли ТАМ она кому-то после релиза понадобится.

Если придраться к "букве" вопроса, то да, ответ именно такой. Если же вдуматься в смысл того, что хочет вопрошающий, то я дал вполне правильный ответ. князь, а почему вы решили что тут стол заказов? Для самостоятельного поиска, рекомендую модуль отлова выстрела, автор - @*Shoker*

В сталкере возможно все, и уж тем более такие простые вещи. Просто надо понимать, что спавнится - игровой объект. А уж у него может быть визуал конкретной нужной вам модели. Таким образом вам нужно: 1) заспавнить объект. если вспоминать оригинал, то там есть physic_object и physic_destroyable_object, но если поискать, да полазить по модам, то еще всякое найдется, это уж вы сами определите какой именно вам надо. 2) через нетпакет присвоить объекту нужный вам визуал (см. модуль для работы с нетпакетами от Артоса, хотя, есть и другие варианты) 3) опять же через нетпакеты Артоса, или через подачу импульса после входа в онлайн, задать объектам положение в пространстве, чтоб они в воздухе не висели.

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

Я бы сказал это жуть как неверная тактика. По каждому поводу плодить объекты - не, спасибо. Я все еще собираюсь сделать потом большую и густонаселенную зону.

Рандомное смещение в произвольном направлении от объекта - для установки метки, элементарная вещь, но даже это разрабам лень было сделать... Я пока предполагаю два (три) метода установки меток. 1 - по координатам. т.е. в метод создания передается id локации и координаты на ней, плюс такой метки - не является игровым объектом, не требует объекта, соотв-но не жрет те пресловутые 65к. 2 - на серверный объект. с возможной добавкой проверок-условий что он в онлайне, что он живой, что он еще что-нибудь. определение объекта при установке - по id. (3) - то же самое, но определение объекта по story_id.

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

Ну вообще то у меня диалоги УЖЕ пишутся не в xml. Хотя этого мало, надо еще многое сделать.

Вылетать будет, если допустить опечатку в имени функции под тегом precondition. Причем вылетит без лога в виде "FATAL ERROR" А в экшенах, то бишь action, если там опечатка и такого скрипта/такой функции нет, то тупо ничего не произойдет, вообще. В каком-то справочнике вылетов я про это уже писал давно. В вылетах без лога, кажется. проверка доступности фразы (пусть даже первой), и проверка доступности диалога - не одно и то же. Если сам диалог доступен то в нем не должно возникать ситуаций, когда никакие дальнейшие фразы не доступны, иначе опять вылет. зы. Вообще эта маразматическая система диалогов у меня следующая в очереди на переделку, после ПДА

Вопрос по файлу game_maps_single.ltx. У каждой локации там есть параметр bound_rect = -512.000, -512.030, 0.000, 512.001 ;512.000x1024.031 Я так понимаю, это координаты в системе отсчета локации, соответствующие противоположным углам ее террейна. первые две - левый верхний угол, последние две - нижний правый, и даны они по осям x и z (в сталкере ведь, y - это вертикаль). Снимок террейна (собственно скрин карты) получаем при необходимости через demo_record on -> F11. И я так понимаю, это именно углы этого самого скрина, выдаваемого движком. И вот предположим, если я думаю что значения координат прописанные в bound_rect у какой то локации не верны, я могу их как то проверить, и выяснить точные правильные значения? Как их вообще можно узнать, если не из файла.

Процент готовности мода, по моим оценкам, теперь составляет 90%.

И все таки, еще раз давайте попробуем. Пообсуждать метки на карте в ПДА, и идеи которые в связи с ними можно придумать. Все так упорно не хотят обсуждать эту тему что мне даже стало любопытно, почему. зы. давайте я вам пример приведу, чтоли. В теме "Судьбы" недавно был пост про разноцветную подсветку карманов. Это идея не моя, и не кого-то в команде. Это один из пользователей в комментарии на ютубе предложил, а мы реализовали и удивились - как нам это в голову не пришло? ведь так удобно. Для такого логичнее сделать метку не на клиентский объект, а на один просмотр. Метка ждет когда на нее посмотрят хотя бы один раз, затем удаляется. Хотя мне пока кажется что у любой метки так или иначе можно определить сроки ее востребованности - и выражаются они временем, а не числом просмотров.

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