[SoC] Ковыряемся в файлах

[Zander_driver 10 348]

А для самих работ лучше вернуть отключенную проверку на валидность, и не допускать.

 

О чем идет речь, о том самом соотношении что число работ не должно быть меньше вместимости гулага?

Я что-то не совсем понял ответ. Гулаг у меня не завис, а вполне явственно продолжал функционировать.

 

Причем валидных работ. function gulag:validate_jobs()

А зависнет там в итоге неизвестно что в неизвестно какой момент. dc

Изменено 23 Октября 2014 пользователем Dennis_Chikin

[Zander_driver 10 348]

 

А я один раз, пока не изменил стиль и шрифт Нотепада++ не мог избавится от вылета из-за того, что было написано не look, а 1ook)))

У меня был случай, вылетало из-за того что было написано не cristall_flower, а cristаll_flower. В чем разница? во втором буква а на кириллице...
История отлова этого вылета была долгой.

[Zander_driver 10 348]

 

 

Модели на ходу всовывать пока не приходилось, но вроде тоже все нормально. За партиклы и шейдеры не знаю.

При смене модели инвентарного предмета, мне например приходилось не только игру перезапустить, но и сделать новое сохранение + загрузиться с него. Предполагаю что это как то связано с тем, что визуал предмета хранится в его нет-пакете, И после просто перезапуска и загрузки сейва игра еще "прежние" адреса визуалов может помнить. Детально в эту сторону не копал-не разбирался, так что могу ошибаться.
Партиклы - достаточно игру перезапустить, и все работает по новому.

[Zander_driver 10 348]

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

[Zander_driver 10 348]

А между прочим он подал мне идею. Так что @Smith_86, - Спасибо.

По теме - вспоминай, правда, в каких файлах ковырялся и что там делал.

[Zander_driver 10 348]

Вопрос по файлу 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 у какой то локации не верны, я могу их как то проверить, и выяснить точные правильные значения? Как их вообще можно узнать, если не из файла.

[Zander_driver 10 348]

А я тут наведаюсь с вопросом... для Кашпировских, если честно. Потому как сам ничего пока не накопал, хотя вроде постарался. Знал бы точнее - решил бы сам, свою проблему. Есть просто небольшая надежда что у кого-то подобное было и дадут подсказку в какую сторону копать

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

У кого есть идеи что это может быть? куда еще стоит воткнуть profile_timer чтоб посмотреть?
зы. если это я сам что-то нахимичил то я же и раскопаю, не переживайте. Вопрос задается единственно на случай если у кого-то такое было.

[Zander_driver 10 348]

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

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

[Zander_driver 10 348]

 

 

Моды требующие перезаписи bin вообще никогда не устанавливаю

С таким подходом, скоро не останется модов, которые вы себе поставить сможете

 

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

[Zander_driver 10 348]

 

 

Поэтому когда-то и решил для себя, что все окна буду делать только на скриптах.

Аналогично, коллега. И собственно так и делаю, если открыть скрипт моего инвентаря и набрать в поиске "xml" - ничего не находит. Я не пользуюсь никакими обращениями к xml-конструкциям вообще.

 

 

Ведро холодной воды на голову получил, как только мне понадобилось переносить текст в пределах окна по "\n".

У меня переносит спокойно... весь вопрос в том, что есть окно, что есть перенос текста. и как найти в тексте эту "\n"...
Да, для этого приходится ручками переписать кое-что из того, к чему пользователи Виндовс привыкли как к тому что "само делается". но не так уж это сложно.

 

 

кроме "complex_mode" в xml еще много опций не управляемых скриптово.

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

 

 

P.S. 2 Zander_driver: может уже пора слегка приоткрыть тайну золотого ключика ? Я имею в виду принцип, на котором сделан скриптоинвентарь ?

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

 

 

Так вот XML - это отличная вещь. Экономит кучу времени. Позволяет выделить данные из кода и менять многие параметры окна, не меняя код. Сам код становится более структурированный и лаконичный.

А я не могу написать свое окно, у которого можно будет менять все-какие-захочу параметры, вообще никак не меняя код?

 

 

99% всех окон статичны

Да неужели. Может потому что для 99% авторов сделать другие - не представляется возможным?

[Zander_driver 10 348]

 

 

Malandrinus верно говорит, что при наличии исходников писать какие-то схожие дубликаты движковых интерфейсных классов - напрасная трата времени.

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

[Zander_driver 10 348]

 

 

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

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

 

 

Началось я так понимаю это все с багажника для машины.

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

[Zander_driver 10 348]

 

 

Вот я могу подробно объяснить, чего именно я добиваюсь, разделяя код и данные:

Секундочку, а разве я что-то сказал против разделения кода и данных? Код - в скрипте, данные - в ltx-конфиге. без XML, да.

 

 

Код становится меньше, причём существенно.

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

 

 

Код становится гораздо более структурированный и его гораздо легче воспринимать, поскольку в этом случае код содержит только действия, неразбавленные малопонятными константами.

Это опять про разделение кода и данных? У меня код тоже содержит в основном действия. Причем он структурирован на методы и классы, и для того кто понимает что такое метод и что такое класс - ну не знаю, какие могут быть проблемы в восприятии.

 

 

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

ВТФ? Я окно создаю одной строкой

self.slot3_frame_id = self:Construct_Frame(self.SCA_Slot3, "slot3", self.mainframe, false)

Опишете мне полноценное окно с рамкой, с возможностью его двигать и менять размеры, рисовать на нем что угодно, писать на его заголовке, в XML, в ОДНУ СТРОКУ?

А если говорить о том что я вызываю какой-то метод и у него там есть свой код - ну так извините он может вызываться в десятках и сотнях мест для кучи разнообразных окон.

 

 

Сопровождение кода существенно упрощается. При необходимости что-то изменить я меняю это не в коде, а в файле данных, что снижает вероятность внесения ошибок в логику. Учитывая особенности движка и отладка изменений упрощается, поскольку я могу менять XML не перезагружая игру/сейв, с кодом так не получается, т.е. внёс изменение - перегружайся.

Вообще не понял. Хотим изменить данные - меняем конфиг. Там же текстуры описаны. Хотим изменить алгоритм действия - как ни крутите но придется лезть в скрипт.

 

 

Как следствие предыдущего п. до определённого предела интерйес сможет менять не программист, что важно в командной разработке.

У меня не до "определенного предела". у меня внешний вид моего скриптового инвентаря, целиком и полностью, начиная с основ и заканчивая мелочами, может изменить до неузнаваемости как угодно тот самый не-программист.

Вообще, зачем ограничивать дизайнеров какими-то пределами, можете мне сказать?

 

 

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

Проще - не проще, в коде ее можно просто сделать и пользоваться.

 

 

Для XML есть средства визуальной настройки интерфейса. Они пока недостаточно продвинутые на мой взгляд, но это вопрос решаемый.

Для интерфейса созданного совокупностью скриптов и конфигов они тоже уже есть.

 

 

Использование XML ничуть не ограничивает в использовании скриптового контроля при действительной необходимости.

Я бы не сказал, что это удобно. Лично для меня.

 

 

Ряд параметров можно задать только с помощью XML. Это конечно связано с движком, а не с парадигмой разработки, но тем не менее фактор такой есть.

Я по прежнему ни в зуб ногой что это за параметры, которые магически привязаны к XML. Я сам свое окно нарисовал, сам на него кнопку прилепил, сам текст написал. Интерфейс - я создал, я и устанавливаю в нем правила. Выровнять текст, перенести по /n или по слову "апчхи", сделать его полупрозрачным, мигающим, прыгающим, ползающим по потолку туда-сюда, меняющим цвет в зависимости от настроения кровососов на Припяти - я могу какие угодно параметры создавать, и управление ими выводить в LTX-конфиг. И тот самый не-программист сможет это все настроить как ему надо, не чертыхаясь в дебрях горбатого xml.

 

 

Можешь привести похожую аргументацию со своей стороны?

Мне кажется я ответил. Единственным не отвеченным вопросом осталось то, что вы пользуетесь XML который когда-то, кто-то создал, и написал код для его обработки. Да-да. А я трачу свое время на то чтоб написать систему которая работает так как мне надо. Но это мое личное время за которое я никому ничего не должен

 

 

@Сталкер-Стрелок, Я вам скоро смогу дать удобный функционал для того что вы в своем посте описали. И это будет на порядок удобнее чем существующими методами через xml или полностью скриптово. Просто не спешите
Он уже есть, этот функционал, но пока не в том виде чтоб его выдавать на публику...

[Zander_driver 10 348]

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

[Zander_driver 10 348]

@Сталкер-Стрелок, Вовсе нет. ничего делать с движком для этого не требуется.

[Zander_driver 10 348]

Все камни преткновения

на самом деле не все, ты видимо некоторые забыл) или не знал о них. Ну не важно. В движок я конечно полезу, всему свое время. Изменено 12 Апреля 2015 пользователем Dennis_Chikin

[Zander_driver 10 348]

@TASGREEN, А еще можно зайти в тему "Судьбы Зоны", посмотреть видео из шапки, узнать что существует скриптовый инвентарь и скоро выйдет на публику. И по части подсветки тех или иных предметов там функционал на месте.

Не навязываюсь, просто к сведению что кроме "Возможности такой нет" и "ковырять движок" - есть еще вот такой вариант.

[Zander_driver 10 348]

Но вообще - странный подход: спрашивают - "как сделать", ответ - "а у меня сделано".

Согласен, подход нехороший, но как мне еще было ответить? рассказать по порядку, как и из чего делается скриптоинвентарь? навряд ли вопрошающий станет то же самое делать сам

А релиза пока нету.

 

А принцип описать хотя-бы коротко, раз уж сделано ? dc

Изменено 13 Апреля 2015 пользователем Dennis_Chikin

[Zander_driver 10 348]

 

 

Я еще чуть-чуть народ поинтригую, а потом тайну золотого ключа раскрою. Вообще не понимаю, почему это не сделали в 2008 году

Это похоже на меня, не так ли?

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

[Zander_driver 10 348]

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

Только на этот раз я тоже не могу понять, чего ради этот огород городить.