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

Dennis_Chikin

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

    6 272
  • Регистрация

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

  • Дней в топе

    33
  • AMKoin

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

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

  1. В общем, опять пришли к тому, чтобы переделать ВСЕ под автогонки. Хе-хе... Таки автосимулятор на движке x-ray. Да, в солянке эти самые вертолеты, похоже, достали уже всех. Я вот, кстати, отдельный скрипт родил, который при запуске игры их все удаляет. Потом, правда, обратно спавнить приходится, по тому как есть решение сюжет максимально сохранить. Но по крайней мере эти вертолеты появляются только на момент, когда они нужны. И, да, до сих пор непонятно, почему по Зоне до сих пор кто-то передвигается ногами, если там в небе постоянно болтается минимум вертолетная дивизия...
  2. Я бы сказал: что мешает поправить сразу ? Хотя, да, это было б смешно, если б не было так грустно, я 4 (!) года угробил на перелопачивание кучи кода только ради того, чтоб не трогать конфиги. Ну, то есть, мне в свое время как бы милостливо позволили трогать код, но вышел знатнейший скандал, когда я показал, что У СЕБЯ на компьютере, ради того, чтоб хоть как-то проверить то, что делаю, не вслепую и без дивного секса с уворачиванием от пуль, монстров и аномалий, и сотен перезагрузок, когда увернуться не сумел - тронул эти самые конфиги. Ага, ЧИТЕР и все такое. Со стороны, прости-господи, "тестеров". А а ОП2 - вон - аж ЗАЩЩИТУ от изменений конфигов прикрутили, которая тормозит и глючит на каждом шагу, но, не дай бог кто вдруг покусится. Мдя... А арты в солянке как проваливались под землю, так и продолжают проваливаться, хотя решение тоже найдено те же 4 года назад. Но... есть только один "лицензированный" правильщик конфигов артов, который из принципа не будет это делать. Аж тьфу.
  3. Замечательно. Прячем проблему, которую в свое время кто-то нашел и вытащил на свет, обратно. И считаем, что ее решили. А если будет вылетать "по стеку" или вообще без лога, то всегда можно посоветовать "добавить памяти" или "не лезь своими кривыми руками в мой совершенно безглючный мод". Но чтоб просто исправить очевидную найденную ошибку с отсутствующей секцией - не, так неинтересно. Конфиги - священны и неприкосновенны. Мы лучше перекурочим весь код до полного изумления системы, и перепишем заново движок, но ни единой буквы, ни единой точки изменить не позволим ! Ни кому !
  4. А при чем здесь модификации, если при формировании динамического ltx идет ссылка на секцию, которой в этом ltx и рядом не стояло ? Просто либо монолитовцы реагируют на дэнжер/видят врага, и срываются в бой, игнорируя любую логику, либо получат хит, и радостно виснут.
  5. Кстати, о движках и не-движках, картинка. Давно хотел, а сегодня наконец руки дошли. В смысле, ни один бит движка не пострадал. Можно, кстати, и отрицательный сделать. Да, с любым грузом замечательно бегаем, прыгаем и не устаем. Хоть пол-тонны, только артами в соответствующем количестве запасаться надо, и будет 0 кг.
  6. Движок. На основе конфига. И, да, традиционно в этих самых конфигах у неписей ноги почему-то второй по важности орган после глаз, при этом, в отличии от глаз, никогда не бронируется.
  7. И чтоб не выбирали "неправильное". Зачем оно так сделано - не знаю. Вообще, вся эта конструкция в том виде, в котором есть, скорее не работает, чем работает. Вчера ж обсуждали. Или позавчера. Читать-то его внутри схемы кто будет ?
  8. Теперь осталось понять, тот ли это файл. Впрочем, очевидно, что таки да, строчки, которые эту секцию хотят - не нужны.
  9. И ГДЕ здесь написано [hit@altar_monolith] ? А также все остальное, что в этом случае полагается ? [walker@...] - вижу, [hit@...] - не вижу.
  10. there is no section [hit@altar_monolith] for npc [pri_monolith_28] Какое слово непонятно ? Кто-то где-то хочет [hit@altar_monolith], но не находит. Соответственно, ищем, где ее спрашивают, тупо, поиском по всем файлам, а дальше думаем: или оторвать совсем, или что-то куда-то дописать.
  11. Продолжение дискуссии про "нужно/не нужно" удалил. По причине бессмысленности. Но вообще - странный подход: спрашивают - "как сделать", ответ - "а у меня сделано". Тема все-таки не рекламная. Или описываем, как, или одно из двух, если уж решили ответить. Но вообще Бак просто на время торговли отбирал у неписей "непродажное оружие". Но результат - гм... А еще был DTL, еще додвижковоковырятельный, в котором это тоже вроде было сделано. Как-то. Вообще же данная конкретная идея представляется неправильной без глубокой переработки неписевой жизни, ибо вот вся эта вот "автоматика выбора оружия" в итоге регулярно дает разнообразные странные результаты, типа "ни за что не променяю свой дробовик - лучше сдохну. И буду стрелять из него всегда и везде, даже если дострелить вообще невозможно". То есть, смысл ровно тот же, что и выкупленный у непися единственный ствол, и даже хуже. Без ствола он хоть просто убежит.
  12. Dennis_Chikin

    У Костра XIII

    Воистину полетел !
  13. Не оффтоп. Хотя трэд надо будет потом по двум разным темам разносить однозначно. И таки отнюдь не единственный. Интерфейсы откровенно уродливы, и их требуется завернуть в нечто вменяемое. И в принципе это делается. В смысле, можно сделать. Вменяемых обменов я пока что не видел, поскольку они везде следуют за интерфейсом, а не за естественным человеческим представлением. Если представить это по простому, по рабоче-крестьянски, без новомодных графов и объектов, то требуется на самом деле следующее: что у нас на самом деле есть | что мы можем с этим сделать | на каких условиях | что и с чем мы делаем | каковы результаты. Это все должно быть плоским (по тому что язык на это заточен) и формируемым динамически, под нужды "здесь и сейчас". Да, если бы оно изначально было бы в движке - возможно, ориентировались бы на движок. Родить мгновенно, переделать сразу и навсегда, всех обучить и дружно перейти на стабильную новую версию... Гм. Опять же, если б 6 лет назад у движка была команда "вызвать код из внешнего модуля и передать ему вот этот кусок памяти" - ага, все б делал на этих самых модулях, благо, у мну есть правильно и годно спроектированная система вот таких вот модулей взаимодействия, 20 лет назад написанная и много раз помогавшая быстро родить странное под всякие странные идеи нашего родного государства. И, внезапно, под работу с таблицами же и заточенная (как предвидел, что кто-нибудь LUA придумает). Но, это все из серии "если б у бабушки было сами-знаете-что". А сейчас же есть две ветки работ, которые начать и кончить. Первое - сделать в движке то, не знаю что, но чтоб красиво, и всем перейти на сделанное; либо таки обертка на существующего уродца, которую можно оперативно затачивать под внезапно обнаружившуюся надобность, не трогая движок. Как бы, оба направления вполне благодарные, но нельзя сделать все сразу. Эрго, кто-то полез в одно, кто-то пилит другое. И это радует, коль скоро не сподобились наладить совместную работу ну хотя-бы на уровне хоть того же freebsd.org - как говорится, ну хоть что-то.
  14. Dennis_Chikin

    У Костра XIII

    "Я не интеллигент, у меня профессия есть !" ©
  15. Для этого надо вдумчиво почистить config\misc\task_manager.ltx, некоторое количество файлов в config\gameplay + возможно, srcipts\xr_effects.script. Как результат - новая игра, поскольку ни сэйв править, ни переписывать специально под заказ тот же task_manager.scipt - ни кто не будет. P.S. Кстати, к вопросу об всех этих "менеджерах" с сохранениями, и об xml'ах, гвоздями прибитых. upd: ну, "что-править, что-править"... Раз уж есть такое желание, то просто читать внимательно все, что там написано, и думать - а нужно ли оно, и для чего. В xml - файлы info* и task*
  16. Гм, методически неверно было с самого начала выкладывать что попало куда попало без объяснений, но, впрочем, объяснения были даны, про то что на форуме было отдельное спрятанное от большинства подполье, где предполагалось понаписать всякого разного, а потом все писатели куда-то делись, и в мир вышло вот это самое что попало и как попало. И, да, по-хорошему бы надо и к этим кускам, каждому, во-первых добавить пояснения про то, что это такое, зачем, что внутри, и как это едят, а еще перетащить сюда же дискусси из других тем. Но... в общем, некогда и лень. Однако, не лень добавить еще один очередной малоосмысленный кусок чего-то странного. Точнее, не то, чтоб не лень, а "за державу обидно". Обидно в общем-то следующе: в свое время я поимел немало дивного секса с кучей монстротаблиц в "солянке", и был этим самым сексом, э-эээ, удовлетворен более, чем хотелось. До полного осознания смысла фразы "много хорошо - тоже плохо". А еще кроме монстротаблиц в десятках экземпляров одного и того же, было 100500 чтений конфигов с разной степени этой самой пессимизации. В общем, все это было выковыряно, и собрано в набор "табличных" скиптов, а также написана пара скриптов "кэширующих". Не в смысле "держать все конфиги в памяти", по тому как этим прекрасно занимается движок, а убрать откуда попало кучу строк со странными вызовами и странными преобразованиями. Ну так вот, смотрю я сейчас на некоторые вполне "современные" изделия, и снова становится обидно и мучительно больно за бесцельно прожитые годы. Итак, выкладывается набор, который может быть кому пригодится, а нет, так хоть на пару мыслей наведет. И, да, я знаю, что "у всех уже сделано", и про "на лесоповал, чтоб не смели". Можно про это не повторяться. https://dl.dropboxusercontent.com/u/27871782/%D1%81%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D1%8B%20%D1%81%D0%BE%D0%BB%D1%8F%D0%BD%D0%BE%D1%87%D0%BD%D1%8B%D0%B5.zip Основная часть этого - именно таблицы, позволяющие по какому-либо свойству объекта убедиться, что это именно тот объект, который нам нужен. Заменяют простыни "if .. then ... elseif ... end" на 100500 строк. Ну, то есть, ничего принципиально нового, но собрано в разные часто используемые комбинации. Да, в этой теме я уже упоминал про class_registrator, и по-хорошему надо бы доработать все это дело, по тому как часть таблиц явно должна заполняться оттуда, а не руками, и наоборот, данные браться из таблиц, чтоб не дублировать набивание руками. Из того, что заслуживает некоторого количества отдельных слов: _tbl_protected.script - исторически сложилось, что делается куча проверок для противоестественого интеллекта неписей и прочих уборщиков, чтобы не уничтожали квестовые и уникальные предметы. По-хорошему, это бы надо всего 2 проверки: на флажок quest_item в конфиге (который препятствует продаже или выбрасыванию ценного предмета), и на уникальный story_id. Но, опять таки исторически сложилось, что конфиги - священны и неприкосновенны, и конфигурист пишет там то, что левой пятке захотелось, а потом скриптами мы пытаемся все это как-то разобрать. Но, там где используется protected_items.script - скрипт этот, мягко говоря, тоже странен. Куча неочевидных странных и кривоработающих проверок десятками способов. На практике мне оказалось как-то проще сделать таблицы свойств, и поверять наличие нужного свойства в нужной таблице. Да, в процессе еще вынесено куча "одноразовых секций", поскольку элементарно пересчитывается в конкретный объект непосредственно из логики ситуаций. Но это уже другой отдельный вопрос. Далее, _tbl_outfit.scipt: как понятно из названия, позволяет получить свойства костюмов из визуалов неписей, и наоборот. Заменяет 5 разных солянкоскриптов, делающих примерно одно и то же, требующих одновременных правок, и, кстати, все с ошибками (ну или конфиги с ошибками, но от того виснуть и бредить все это дело не не перестает). В обшем, смотрите комментарии. И, наконец, xl_imgr.script - это банальное "кэширование конфигов". Когда вместо упомянутых 100500 строк чтения конфигов мы просто берем нужное свойство из таблицы по секции конструкцией ( t[sect] or get_prm(sect) ).prm Так реально помогает, а память даже и экономится. На данный момент кэшируются только те свойства тех предметов, с регулярным опросом которых я сталкивался. Вот примерно так. P.S. Да, тот код, который я время-от времени куда-нибудь выкладываю, именно на эти таблицы и опирается. Так что, опять же, если кого интересуют какие мои поделия, то вот можно глянуть сюда на предмет всяких "недостающих" частей.
  17. Ну, в таком случае хотелось бы ознакомиться с обоснованиями для такого интересного хода мысли. Где и каким образом читаются ОБЕ эти строки, и как именно используются ?
  18. Графом по-определению является все, что может быть представлено набором вершин и связей между ними. Но это может быть "дерево", может быть "клетка" (пустая внутри), а может быть и "блин" (все со всеми). Кстати, сколько-то осмысленный софт - это, как правило, именно "блин" (и труба как частный случай). Иное - результат деятельности разработчика-извращенца. Мне, кстати, как человеку, измученному этим нарзаном еще с 86 года, вообще как-то ближе представления не в виде графов, а в виде таблиц с набором векторов (континуальным, на то оно и программа, а не человек) между ними. Впрочем, это уже, наверное, в курилку.
  19. Вчера только пытался показать, что это на самом деле делается табличкой разрешенного и сканом инвентаря + чтение дескрипщенов у найденных трусов. И из этого формируется текст для кнопки. То есть, ни каких развесистых древ не нужно заранее прописывать.
  20. Про лаконичность и читаемость кода - гм, этот самый dialog_manager, особенно в его исходном виде - хорошая иллюстрация, да. Вообще же, разделение кода и данных - это хорошо. Но здесь именно с движка бы надо начинать. И, пожалуй, нет ничего хуже, чем делать вид, что управление данными - это и есть сами данные. Ага, я про условия в диалогах и их отработку. Впрочем, не об том хотел сказать. А о том, что дерево диалогов - от нормального общения, которое таким образом пытались и изобразить, бесконечно далеко. Именно тем, прежде всего, что в нормальном разговоре всегда можно выбрать интересующую тему СРАЗУ, и в любой момент к ней вернуться. А не "привет - привет - у тебя пнв есть ? - есть - а к костюмам прикручиваешь - прикручиваю - а цветные есть - есть - тогда дай зеленый - тебе его на пальто красное прикрутить, или на синее - мне на трусы - тогда их надо было с самого начала на себя надеть - досвидания."
  21. Экстренный рескан смартов на предмет может ли быть назначен.
  22. Еще раз переделывать не хочу, по тому как сделана связка для AI, и любопытствующие могут сравнить. Есть в соседней теме. Возращать обратно все унылые извращения... Бр... Кому хочется- берите и адаптируйте. Если будут вопросы - подскажу, что зачем, и где взять недостающее. Сам не буду. Ну вот если на скорую руку, снести наиболее очевидный бред, то что-то типа такого: https://dl.dropboxusercontent.com/u/27871782/watcher_act_op2.script А вот как оно работать будет, и будет ли вообще... P.S. но все равно бред. Кто-то в свое время очень старался с очередным ущучиванием игрока. Чтоб ни единого сломаного ПМа, и ни одного облезлого хвоста с дохлой собаки не досталось.
  23. Поставить одну строку в проверку. Опять же, переделанный скрипт в солянкоскайпе я давал еще 4 года назад. Можно ж и там посмотреть. В общем, для всех остальных: function add_to_binder( трам-пам-пам ) ... action = act_reach_item( чо-то там ) вот ТАК должно быть: action:add_precondition( world_property( stalker_ids.property_alive, true ) ) action:add_precondition( world_property( stalker_ids.property_enemy, false ) ) action:add_precondition( world_property( stalker_ids.property_danger, false ) ) action:add_precondition( world_property( prop_contact, false ) ) action:add_precondition( world_property( xr_evaluators_id.sidor_wounded_base, false ) ) action:add_precondition( world_property( blowout_scheme.evid_anomaly, false ) ) action:add_precondition( world_property( blowout_scheme.evid_blowout, false ) ) action:add_precondition( world_property( evid_see_stuff, true ) ) а вот это наоборот: -- action = manager:action( stalker_ids.action_danger_planner ) Ну и, да, напоминаю, что всю ересь про memory_sound() стоит снести заодно. Они и так на 360 градусов и на всю локацию сквозь стены видят, чтоб потом еще раз по всем год-либо имевшим место в игре звукам проверять. Слава слонопотаму, что хоть еще поиск по нюху не добавили.
  24. Кстати, о птичках, точнее - об этих самых кнопках из соседней темы: w = CUIButton() w:SetWindowName( "btn_next" ) w:SetAutoDelete( true ) w:Init( 250, 60, 50, 30 ) self:AttachChild( w ) self:AddCallback( "btn_next", ui_events.BUTTON_CLICKED, self.next, self ) w:Show( true ) Что здесь не так, что первое нажатие оно отрабатывает нормально, второе - 2 раза, а дальше - 4 и т.д. Кнопку мы после каждого нажатия перерисовываем, но как бы вроде разве недостаточно w = CUIButton(), чтобы старая удалилась ? Это надо еще какое-то волшебное слово сказать ? 2 abramcumner: в общем, да, DetachChild() помогает, но дешевле оказалось избавиться от перерисовки. Выяснилось, что нужные статики ложатся в нужном порядке, а оригинал был странен, но просто до подобной ситуации обычно не доживал.
  25. 2 Serge!: баны здесь прилетают за переходы на личности. Ну или за явный оффтопик. Посты в отстойник уходят из-за этого же. За спор по существу вопросов такого не бывает. Так что, берем пост из отстойника, вычищаем из него все лишнее, и с чистой совестью возвращаем обратно сюда. (Ну, правда, бывают еще и такие посты, из которых и возвращать-то нечего...) Что касается дополнительных dll - если именно дополнительные, то ничего страшного не вижу, чтобы установить нечто в дополнение к имеющемуся. Пока останавливает именно возможность конфликтов между этими самыми дополнениями. Но, в наличии имеются несколько средств, для некоторого круга задач вполне рабочих, и этих самых дополнений не требующих. Как бы просто стоило их здесь упомянуть, ну и если кому непонятно, КАК ИМЕННО в принципе ими можно пользоваться - то и показать пример. Из полезного далее можно было бы еще показать примеры реализаций других вариантов, которыми кто-либо здесь пользуется, но упомянуты вскользь. Каждый, кто заинтересуется, может сравнить, и сделать выводы для себя лично. Кому не надо... Ну, тот не заинтересуется, и будет дальше плодить копипастой свои мегабайты. P.S. 2 Zander_driver: может уже пора слегка приоткрыть тайну золотого ключика ? Я имею в виду принцип, на котором сделан скриптоинвентарь ? 2 Nazgool: ересь в том, что остальным теперь надо это все самостоятельно повторять, или откуда-то выкапывать, что не сильно легче.
×
×
  • Создать...