Перейти к контенту

Malandrinus

Жители
  • Число публикаций

    1 930
  • Регистрация

  • Последнее посещение

  • Дней в топе

    13
  • AMKoin

    120 [Подарить AMKoin]

Весь контент пользователя Malandrinus

  1. Malandrinus

    OGSE - Обсуждение и прохождение

    @dwAxel, никто список не вёл, да и не добавляли со времён двойки (т.е. в то время, что я наблюдал) практически ничего со стороны. От АМК какие-то компоненты остались (например что-то там с оффлайновым alife и таймеры), хотя мы и приложили усилия по их замене (особенно хотелось изжить таймеры, но некоторые квестовики всё равно их использовали, поэтому остались). Многие компоненты сильно изменены. Какие и насколько - никто уже не скажет. По AI схемам наверное проще взять и поглядеть наличие конкретных файлов в папке скриптов.
  2. А какое это вообще имеет значение? Единственное, что имеет значение - сколько потратить времени и сил на достижение результата. Если гейм-дизайнер поменял только файл данных, и не заморачивался вообще на алгорититмы и программирование в целом (и даже может не умея программировать), то это хорошо. Если он при этом красиво пошевелил мышкой в визуальном интерфейсе, вместо того, чтобы руками редактировать текстовый файл - ещё лучше. Если для достижения ровно того же результата ему потребовалось программировать - это совсем плохо. Не потому плохо, что что-то из этих трёх способов "хуже", а что-то "лучше", а попросту потому, что они все почти заведомо существенно отличаются по трудозатратам. Программировать не только сложно (нужно владеть дополнительными знаниями), но и обычно не быстро. Редактировать руками текст, даже если это не требует отладки алгоритмов, всё равно требует повышенного внимания и процесс уязвим к синтаксическим ошибкам. Визуальный инструмент же, при должном развитии разумеется, обеспечивает максимальную производительность труда. Вот с этой точки зрения и имеет значение разделение кода и данных. Менять данные - это значит не программировать. Вообще не программировать. Ну я не знаю, мне кажется, я бегаю с этим объяснением уже по третьему кругу. @FonSwong, хотя не до конца понятно, что именно ты хочешь делать, всё равно могу посоветовать создать минимальную заготовку XML для нужных окон. Убедись, что на основе этой заготовки ты можешь создать окно нужного типа по отдельности. Просто создать, без привязки к твоей задаче. Тогда уже в свой код ты сможешь вставить эти блоки для создания нужных окон, заведомо зная, что они рабочие. Пусть там какие-то параметры надо будет переписать скриптовыми вызовами. Это не принципиально. Тебе же ехать надо, а не шашечки.
  3. Разумеется не можешь! Разделение кода и данных - это в первую очередь разделение труда: программиста и дизайнера. Данные редактирует дизайнер, он не программирует при этом. Скрипт же редактирует программист. Редактирование данных - это задание конечного результата. Редактирование скрипта - это изменение алгоритма достижения результата. Второе существенно сложнее первого, именно поэтому разделение данных от кода упрощает работу: написав код парсера один раз мы больше этим не занимаемся, а занимаемся только более простым описанием данных. Ты написал парсер для чего? Чтобы и со своим парсером для каждого диалога что-то писать скриптами? Мне кажется, я уже повторяюсь, и даже странно, что это надо повторять. Разве это не очевидно? И что? Какое это отношение имеет к окнам и диалогам? Работа с ними как была, так и осталась неизменной с тех времён, когда скриптов не было. Скрипты ввели в основном для ограничения поведения неписей, т.е. для написания/модификации поведенческих схем. Это универсальный язык хранения любых данных в текстовом виде. Тебе видимо словосочетание "промышленный стандарт" действительно ни о чём не говорит. XML - это повсеместно используемый стандарт. Не просто в "куче мест", а вообще повсеместно. Его удобство редактирования руками вообще не при делах. В наше время никто даже не рассматривает всерьёз вопрос удобства редактирования голого текста. Причина проста - ручное редактирование текста всегда существенно медленнее визуального. Именно поэтому я считаю, что правильный путь - это не написание ещё одного парсера под другой текстовый формат, а написание инструментов визуального редактирования.
  4. Malandrinus

    X-Ray extensions

    @TIGER_VLAD, вот фрагмент исходника из файла Actor_Movement.cpp if (fis_zero(character_physics_support()->movement()->gcontact_HealthLost)){ m_fLandingTime = s_fLandingTime1; mstate_real |= mcLanding; }else{ m_fLandingTime = s_fLandingTime2; mstate_real |= mcLanding2; } Судя по всему разница в том, ушибся или нет при приземлении.
  5. Malandrinus

    X-Ray extensions

    Тогда уж is_actor_sprinting Да, наверное можно и их использовать. Эти функции добавили позже. Нельзя.
  6. Malandrinus

    X-Ray extensions

    Проиграть произвольную анимацию худовой модели: db.actor:set_hud_animation_channel(2) db.actor:set_use_hud_animation_callback(true) db.actor:set_hud_animation_callback_param(12345) wpn:play_hud_animation("reload", true) Колбек на окончание анимации вызывается для актора, код колбека 157. В колбек передаётся один целый аргумент - то число, которое было установлено вызовом db.actor:set_hud_animation_callback_param(<целое число>). Так можно в колбеке различать, какая именно анимация закончилась. Определить состояние актора (взято из OGSE, _g.script): local body_states = { -- флажки состояния тела актора [1] = "fwd", [2] = "back", [4] = "l_strafe", [8] = "r_strafe", [16] = "crouch", [32] = "accel", [64] = "turn", [128] = "jump", [256] = "fall", [512] = "landing", [1024] = "landing2", [2048] = "climb", [4096] = "sprint", [8192] = "l_lookout", [16384] = "r_lookout" } -- получения флагов состояния тела актора function actor_body_state() local body_state = body_states[db.actor:get_actor_int(nil, 1432)] if body_state ~= nil then return body_state else return "" end end Определение установленного подствольника (взято из OGSE, ogse_wpn_utils.script) -- флаги аддонов addons_flags = { scope = 1, gl = 2, silencer = 4, grip = 8, magazine = 16, scope_mount = 32, } -- подствольник function get_grenade_launcher_flag(wpn) return bit_and(wpn:get_wpn_int(nil, 936), addons_flags.gl) ~= 0 end
  7. Malandrinus

    X-Ray extensions

    @ed_rez, ну так и я и говорю о том, что можно проигрывать произвольную анимацию. Определяем состояние - бег, установленный подствольник - включаем нужную анимацию. Собственно, движок ведь так и делает, а здесь просто тоже самое будет делать скрипт.
  8. Malandrinus

    X-Ray extensions

    Вообще-то анимации худа можно проигрывать на текущем наборе правок. Также можно определять состояние бега. Поэтому шатание оружия с помощью анимации во время спринта вполне реализуемо и без дополнительных правок.
  9. Тогда ты сам себе противоречишь. Уж не знаю, что ты так завёлся. Примерно до 2004 года никаких скриптов в движке не было. Т.е. совсем. А окошки, диалоги и всё прочее было примерно в том же виде, как и сейчас. Даже и сейчас в ванильном варианте игры подавляющее большинство всего задаётся чисто данными. Даже в немногих скриптовых окнах оригинала собственно скрипты носят роль чисто формальную - инициализация на основе внешних данных, т.е. вызовы парсера, т.е. в сущности ровно тоже самое, что делает внутри сам движок. Для этого можно спокойно создать окно на основе xml, а потом доделать что надо скриптами. Хм. И для чего же его разработали?
  10. @advisor890, идея примерно как ты написал, хотя реализация будет сложнее. Поскольку метку на объект надо ставить только один раз, то надо держать массив помеченных аномалий, и периодически их все проверять на предмет того, что актор вышел из радиуса. Если вышел, то метку снимать и удалять из массива. Кроме того, лучше наверное использовать не level.map_add_object_spot_ser, которая ставит постоянную метку, а level.map_add_object_spot, которая ставит метку, не сохраняющуюся в сейве.
  11. @Zander_driver, Данные разумеется есть всегда. Идея отделения их от кода в том, чтобы менять их, не меняя код. Если данные смешаны с кодом, то по очевидной причине, придётся менять код, чтобы менять данные. Поэтому твой пример кода №1 - это как раз типичное грубое смешение кода и данных. В том числе, хотя и менее плохо, вынесение данных в отдельный блок кода, поскольку и тогда придётся править файл кода. В идеале должен быть отдельный файл данных, чтобы его правка вообще бы не трогала ни одной строчки и ни одного файла кода. Собственно, так и задумана работа с файлами игры. Я откровенно не понял про "мифы и стереотипы". Для начала, не я это придумал, а умные люди пришли к этому многие десятки лет назад. Этот принцип реально помогает упростить жизнь. Данные легче менять, чем код. Меняя данные мы описываем результат, а код - это описание процесса достижения результата, и его изменение заведомо более сложное, нежели данных. Заключается это в массе мелочей: необходимость отладки, больше возможностей по внесению ошибок, больше усилий на понимание и т.п. Это касается как написания, так и всех этапов последующего сопровождения. Это промышленный стандарт, для которого не надо делать парсеры, поскольку они уже есть во множестве. Редактирование же в свою очередь не должно быть руками. Нужны адекватные инструменты, о чём я тоже говорил. Применительно к разным задачам модостроя такие инструменты уже появились или появляются. И это - правильный путь. Быстрее того и другого разберётся в инструменте визуального редактирования. Но сейчас то нельзя. Чтобы это сделать, тебе надо залезть в движок. А если ты можешь залезть в движок, то зачем тебе скриптовый парсер? Я бы тогда уж сделал парсер движковый, пусть и не на xml, а на ltx. В любом случае, что ты хочешь мне доказать? Ты же делаешь инструмент как раз для архитектурно правильного разделения кода и данных, так о чём вообще спор? Твой парсер - это не "чисто скриптовое создание", с которого начался разговор. Хотелось тебе сделать всё по своему - право твоё. Хотя я бы и не стал так делать, а направил бы усилия на развитие инструментов для того же xml (что я и делаю по мере сил). В любом случае, здесь разговор вообще не об этом. Твой пример №1 - вот то, о чём я говорил. Люди продолжают так делать сплошь и рядом: окна, диалоги, что ни попадя. Конкретно то, что я имел в виду, это когда человек создавал каждую фразу отдельным вызовом функции и отдельными ручными вызовами пришпиливал к ним предусловия, инфопорции и т.п. Это - зло в чистом виде. Лучше бы ответил не ты, а @FonSwong. Потому что это конкретный вопрос, а не "вообще". Практически всегда, когда я задаю конкретный вопрос "что за задачу вы собираетесь решать вот этим извращённым способом?" ответа либо нет, либо он так и звучит "а вдруг надо будет" или "а почему бы и нет". Лично я уже давно излечился от этого и решаю только те задачи, которые передо мной реально возникают.
  12. Malandrinus

    OGSE: КБ разработчиков

    @nasar75, я понял, но это действительно не проблема плагина, а проблема TC. Кроме того, я намеренно не регистрировал никакие расширения, кроме *.db0 (и то лишь потому, что хоть какое-то надо было указать). Дело в том, что этих расширений архивов может быть десятка два, да ещё вот хотя бы с OGSE добавилось десяток совершенно экзотических. Поэтому, как верно посоветовал @Romz, надо просто заходить в архив, используя "Ctrl+PgDn". Я даже вроде бы об этом написал в readme к плагину.
  13. Malandrinus

    OGSE: КБ разработчиков

    Обновил плагины для Total Commander для распаковки игровых архивов. Теперь поддерживают упакованные файлы, которые имеются в архивах OGSE. Вот новые версии обоих плагинов на яндекс диске. Ссылки на официальный сайт с новыми версиями в моей подписи. https://yadi.sk/d/094hymb_r275S https://yadi.sk/d/hCfFUj7Tr277b
  14. Обновил плагины для Total Commander для распаковки игровых архивов. Теперь поддерживают упакованные файлы. Вот новые версии обоих плагинов на яндекс диске. Также ссылки на официальный сайт с новыми версиями в моей подписи. https://yadi.sk/d/094hymb_r275S https://yadi.sk/d/hCfFUj7Tr277b
  15. Не всё можно, а главное, зачем это надо - чистое скриптовое создание? Разделение кода и данных - не причуда бюрократов от софтверной индустрии, а вполне себе правильная вещь. Нет, я говорил совершенно о другом человеке (и вообще странно, что ты счёл, что я бы мог назвать тебя новичком=). Раз уж ты привел в пример твою наработку, то это как раз не скриптовое создание, а также создание с помощью данных. Просто ты реализовал для этого альтернативный парсер. Замечу при этом, что истинно динамические диалоги, т.е. с созданием на лету диалога с произвольным графом, так всё равно не сделать. Поэтому выходит, как я и сказал, попросту другой механизм разделения кода и данных, не xml + движковый парсер, а ltx + скриптовый парсер. На мой взгляд, перечисляемые в твоём посте недостатки xml преодолеваются с помощью нормальных инструментов редактирования. Утилита из SDK - это как раз пример крайне плохого инструмента. Я пытался сделать лучше, на мой взгляд получилось неплохо. Будут силы и время, доработаю свою утилиту до приемлемого состояния. А что значит "полностью динамическим"? Ты всерьёз собираешься скриптами менять ВООБЩЕ ВСЕ параметры окна или контрола? Когда ты размещаешь окно как дочернее, то установка этого параметра в true приведёт к тому, что это окно удалится автоматически при удалении своего родительского.
  16. Malandrinus

    X-Ray extensions

    @macron, по сути правки конечно надо у KD уточнять, но почему её для r1 нет вполне понятно. Правки делались в рамках OGSE, а первый рендер мы оттуда убрали.
  17. Malandrinus

    X-Ray extensions

    @macron, а это разве не чисто шейдерная правка?
  18. Malandrinus

    X-Ray extensions

    Да, без правок работать не будет. Худ и сцена отрисовываются в двух разных очередях и при этом с разным FOV (из-за этого и смещение вперёд). Разрабы ТЧ сделали так, что шейдер самосвечения всегда срабатывает в очереди сцены, даже если принадлежит худовой модели. Свинтусы они, разрабы эти. Косяк в исходниках лечится парой строк, а так вышла одна из самых мерзких и нудных правок.
  19. @FonSwong, В твоём коде самом по себе ошибки нет, но твой контрол скорее всего недоинициализирован. Создай его по-человечески с инициализацией через xml и не парься. А зачем было полностью переходить на скрипты? Можешь как-то обосновать необходимость этого? Я кстати встречал подобные экстремальные замашки и почему-то в основном среди скриптёров-новичков. Из подобного припоминаю один запущенный случай, когда человек создавал диалоги исключительно скриптами, полностью игнорируя xml. Зачем? Ну вот так хотелось, может считал, что это круто или что-то в этом роде. Что это не даёт никаких преимуществ, что создаёт совершенно несопровождаемый код, и такие диалоги невозможно редактировать никакими редакторами, а только вручную, человека не волновало.
  20. @Achiever, какое время надо измерять? Секунды, доли секунд, часы? В какой среде ты запускаешь свой скрипт? Это чистый Lua, мод сталкера? Здесь нет ответа на все случаи жизни.
  21. @Achiever, if <прошло сколько-то времени> then break end
  22. Внесу свои пять копеек. SDK разумеется нужно изучать, с этим не поспоришь. Однако его использование именно в модостроении связано с одной существенной проблемой, а именно принципиально однопользовательским режимом работы с SDK. Т.е. над конкретным уровнем с использованием SDK может работать только один человек. Пока речь идёт о геометрии, сетке, порталах и т.п. - это нормально, но как только начинается заселение - это становится проблемой. А вот ACDC позволяет работать со спавном в команде: исходные текстовые файлы лежат в сетевом репозитарии и правки разных людей друг другу не мешают. В общем то и при использовании ACDC никто не мешает как вспомогательный инструмент спавна использовать SDK. Вносишь изменения на уровне, компилируешь спавн, разбираешь его в текст, переносишь в общую версию изменённый или новый кусочек. Конечно это не идеальный способ работы, но возможность совместной разработки того стоит.
  23. @FonSwong, обычно так пишут, когда в пути имеется "бэкслэш", т.е. символ "\". Этот символ специальный, в комбинации со следующим за ним он имеет определённый эффект. Например "\n" - это перевод строки, "\t" - символ табуляции и т.д. Набери в гугле "escape последовательности" и узнаешь больше. Так вот эти специальные комбинации в Lua работают только если строка заключена в кавычки. Чтобы не использовать эти специальные комбинации, а трактовать каждый символ строго как он есть в Lua можно заключить строку в двойные квадратные скобки. Для путей, где обратные слэши встречаются постоянно, это особенно удобно. По второму вопросу. Нет, как ты хочешь не сделать. Кстати, и обратное тоже не сделать, т.е. замедлить все процессы, физику, анимацию, партиклы и т.п., тоже не получится. Т.е. сломо, буллеттайм и т.п. на текущем движке не выйдет.
  24. Ну вот, как я и подозревал. Ты привёл как раз тот самый случай, когда этот алгоритм (на мой взгляд бессмысленный в общем случае) вырождается для строго единичного инкремента. В этом случае сразу после перехода верхней границы идёт переход на начало. Сразу - за счёт единичности инкремента. И в этом случае это в точности соответствует операции, обычно реализуемой с помощью остатка от деления. local low_boundary = 3 local upper_boundary = 7 local current_position = 5 for i=1,20 do print(current_position) current_position = current_position + 1 current_position = low_boundary + math.fmod(current_position - low_boundary, upper_boundary - low_boundary + 1) end

AMK-Team.ru

×
×
  • Создать...