Dennis_Chikin

prior = 5 - это нужно, когда есть работы, на которых должен быть кто-то конкретный, или когда нужно, чтобы из всех возможных заняты были именно эти. У меня работы с условиями всегда проверяются первыми, так что здесь уже задумываться слишком сильно не надо. Вообще, опять же, в мультигулаговый смарт такие отдельным гулагом имеет смысл оформлять. Избавились. сквады - имеет смысл менять динамически, раз пошла такая пьянка. группы - как выяснили, нужны там, где задействованы в путях с сигналами. position_threshold - это интересная такая штука... Смысл - надо ли в офлайне бежать к начальной точке пути. capacity - нужно для текущего формата, если используешь условия в работах. И для генералов. Плюс, если они у тебя прописаны для всех - можешь исправить разные косяки, дописав "запасные работы" (классика жанра - волк/фанат/шустрый, и наймы на кордоне, где при неудачном стечении обстоятельств получаещь сбежавшего непися или висяк.) Кондлисты - мне не нравятся. Медленные, и читаются плохо. Лучше иметь возможность задавать явно.

А поясните мне такую вещь: когда в дескрипшен таска мы передаем id статьи из "энциклопедии" - текст должен быть сформирован в xml- файле ? Хранится ведь не он, а только id ?

Вроде, 20 минут выкроил, выполняю обещанное. Итак, мне вот тоже не нравятся работы с состояниями. Не нравятся тем, что получается слишком много букв, и очень трудно контролировать все это глазами. Буквально пару дней назад описка с 0 вместо 1 - и пол дня на то, чтоб ее найти. Простыни получаются преразвесейшистые. Накладные расходы по получению/сортировке/переключению работ со стейтами - тоже не маленькие. Но в данном случае как раз имеем повод отбросить хакерские замашки в пользу читаемости, и даже не задумываться особо про то, какой же из вариантов будет быстрее на сотую микросекунды . Из собственно же методов борьбы с развесистыми простынями вижу два простых (в смысле, скриптовых, не дожидаясь, пока с неба свалится экзешник, чтоб сам кофе варил, и за пивом бегал): 1. Развернуть часть текущего ужаса и кошмара в плоские таблицы (все равно xr_gulag в итоге именно их хочет, и формирует). То есть, не вот вставка в переданную таблицу, и не проверка на каждый чих "подходящести", а отдать готовые. При некотором усилии можно эти работы со стейтами записывать так, что просто скользя глазом замечаешь отличия. И руками можно посчитать. А потом валидатор напустить, в сомнительных моментах. Этот код я вкладывал в более специализированной теме, ссылку давал, примеры давал, повторять смысла не вижу. Кому надо - найдет/посмотрит. 2. Перейти, вот как я понял прозвучавшие здесь предложения, к системе один смарт - несколько гулагов в нем. Преимущество - простыни становятся гораздо менее обширными, общие параметры из работ выносятся в параметры гулага, можно даже банально эти работы наследовать, подставляя отличия. То есть, для каждого стейта - один гулаг, в смарте - по гулагу для каждого стэйта. С точки зрения кода, навскидку, переключение между гулагами - будет проще-изящнее-быстрее. На самом деле даже "освобождать/переназначать/и т.д." ни кого не надо. Переключили гулаг, переинициализировали логику, и все. При покидании смарта - запустили "сборку мусора". В обоих случаях, заметим, НЕ требуется срочно переделывать все готовое. Оба варианта вполне дополняют стандартный. Собственно, в моем варианте с плоскими таблицами есть вариант такого вот одностейтового гулага, и осталось только "когда-нибудь" дополнить до "более одного гулага в смарте". Работа вот с этим одностейтовым - по факту проще и по факту, оно быстрее. Проверено. То есть, если коротко, то оно вот как-то так в итоге выглядит: local g_comms = { ["atp_brigada"] = "stalker", -- 14.08, Калинин ["atp_fabrika_bandit"] = "bandit", -- ["atp_stalk"] = "stalker", -- допа 2011 ... local g_jobs = { ["atp_fabrika_bandit"] = { -- Бандиты на АТП { section = "logic@atp_fabrika_bandit_walker1", idle = 0, prior = 10, state = {0}, in_rest = "", out_rest = "" }, { section = "logic@atp_fabrika_bandit_walker2", idle = 0, prior = 10, state = {0}, in_rest = "", out_rest = "" }, ... local t_states = { ["esc_blokpost"] = esc_blokpost, ["esc_lager"] = esc_lager, ["esc_bridge"] = esc_bridge, ["esc_fabrika_bandit"] = esc_fabrika_bandit, ["esc_dogs_to_fox"] = esc_dogs_to_fox, ["esc_specnaz"] = esc_specnaz, ["esc_boars_dogs"] = esc_boars_dogs, ["esc_killers"] = esc_killers, ["esc_dogs_swarm"] = esc_dogs_swarm, ["esc_stalker_camp"] = esc_stalker_camp, ["esc_corps"] = esc_corps, ["esc_assault"] = esc_assault } function load_states( gname, type ) -- стэйта нет - значит, всегда 0 return t_states[type] end function checkStalker( npc_community, gulag_type, npc_rank, obj ) local c = g_comms[gulag_type] if c then return c == npc_community end return ( obj["profile_name"] and obj:profile_name() == g_names[gulag_type] ) or false end function checkMonster( npc_community, gulag_type ) local c = g_comms[gulag_type] if c then return c == npc_community end if gulag_type == "esc_boars_dogs" then return npc_community == "dog" or npc_community == "boar" end return false end Ну вот как-то так, да. Это "дополнительный", альтернативный формат записи. Но все еще один смарт - один гулаг. С несколькими - в 2 раза сокращается количество строк, и сами строки упрощаются (от них в основном только секции логики и нужны) Вот что я не понял в звучавших предложениях - это заворачивать КАЖДУЮ работу в "псевдообъект". Подозреваю, что имелось в виду нечто иное.

Э-эээ... Распутываю. Текст, естественно, отвечает на предыдущий пост. Кроме того места, где цитата из более раннего. В основной части текста идет речь про то, для чего может быть нужна однострочная функция в глобальном пространстве, в которой к тому же еще и проверяется наличие alife(). То есть, представим момент загрузки какого-нибудь смарта или респавнера (а они грузятся НУ ОЧЕНЬ своеобразно), в котором зачем-то добавили xr_logic.pic_section_непомнючего, которая проверяет это самое инфо. Вот в этот момент действительно есть вероятность (и я такой код ВИДЕЛ), что все встанет колом, если нашу однострочную функцию "упростить". Но при этом мы и не можем адекватно обработать и случай с несуществующим инфо на входе, так что пущай падает/вылетает/рушится и т.д. ССЗБ тот, кто написал такой странный код. В остальных 99% случаев - да, есть и актор, и инфо, и вот эту однострочную проверку лучше выполнять "на месте", явным образом. Также есть места, где нам заведомо известно, что и alife() есть, и несуществующих инфо нет, и эти места выполняются точно и при отсутствии актора. Здесь, опять же, явным образом вписать alife():has_info(0, info_id) - то есть, конструкция сама за себя говорит и о том, что делает, и об условиях, в которых работает. Впрочем, это все на любителя, конечно. Кому и 100500 строк if ... end; if ... end (даже не elseif) милее. Здесь мы вроде бы ВСЕ возможные варианты и условия для них озвучили, вместе с подводными камнями, так что цель разбора вроде как достигнута. Посты с личными разборками, которые здесь были, ушли по назначению. Не зависимо от того, что в них было кроме разборок.

модераторское: дискуссия слегка переместилась в эмоциональную сферу, а предложения оппонентов, на сколько я вижу, читаются невнимательно. Ну и сами предложения эти несколько неконкретны. По крайней мере лично я понял предлагаемое совершенно иначе, чем остальные. Предлагаю внимательно перечитать хотя бы СОБСТВЕННЫЕ тексты, и попробовать сформулировать более четко и доходчиво. Я через некоторое время напишу, как именно понял. 2 Murarius: не совсем так. В некоторых случаях код не нужен. Или его еще нет. А вот описание в этих случаях желательно бы как можно более однозначное.

Ты не понял. function return_true( v ) if v == true then return true else return false end В лучших традициях индусского кода. Теперь, где-то, в другом скрипте, вызываем if return_true( another_var ) == true then Что делает вызываемое ? Правильно, ищем, где оно, и смотрим. Нет, функция НЕ бессмысленна. По тому что где-то в xr_logic.чего-то() или еше в каких диалогах требуют строго true или строго false. То есть, сей индусский код имеет право быть. В принципе. Для вот этого вот, где таки требуют. Но не ВЕЗДЕ. "function has_info(info_id) return actor and actor:has_info(info_id) or has_alife_info(info_id) end" Вот опять же плохо по той же причине: в 99% случаев у тебя есть актор, и 146% гарантии, что без него до сюда не дойдет. Вот и можно писать сразу actor:has_info(info_id), не через 10 скриптов и 20 проверок. Если не уверен - alife():has_info(0, info_id) сразу. Тоже наглядно, и жрет всяко меньше, чем + 2 вызова функции плюс пачка эзотерических проверок внутри каждой. "по крайней мере намного вероятнее, чем вызов из главного меню до загрузки игры" - у меня куча скриптов, где отключен вывод в лог об успешном контроле целостности. По тому как smart_terrain и иже с ним хотят их не только до алайфа, но даже до консоли. Опять же, половина level.* кучу времени выдает nil.

Винда, однако. Кроме того, а оно вообще разве позволяет гулять за пределы FS root ?

info_id ~= "" - если подобное вызвали - у нас где-то проблемы. Проверка на sim ЗДЕСЬ - по тому что если вызвали, а alife() еще нет - мы об этом все равно ни как сообщить не сможем - и висяк будет весьма загадочный. "А можно ссылку на бенчмарки, исследования по этому поводу?" - функции в сталкере не инлайнятся.

Едем дальше. function debug_get_level_object( obj_name ) function debug_get_actor() По понятной причине - не работают. Если кому не понятно - в стандартном движке нет wait(). Можно оставить как есть, можно - удалить. Если вруг, в чем я сильно сомневаюсь, случится вылет - найти, и удалить там. function distance_between( obj1, obj2 ) function distance_between_safe( obj1, obj2 ) Собственно, все очевидно, кроме того, что это исключительно для game_object, и ни как иначе. Кроме того, непонятно, зачем делать функцию, которая дает повисание при отсутсвии объекта. Опять же, про однострочные функции уже говорилось - это не тот движок, и не тот язык, где можно позволять себе подобную роскошь. Читаемости вашему коду оно не добавляет. function has_alife_info( info_id ) -- Проверка на инфопоршны, даже если игрока не существует local sim = alife() if sim then return sim:has_info( 0, info_id ) end return false end- в общем, функция много где использующаяся, но смысл ее использовать - сомнителен. По тому что и alife() и actor в абсолютном большинстве случаев - есть, а там, где их нет - там и не нужно. Где нужно - там - actor_proxy более уместен, или более другой вариант, чем info. Да, я помню про smart_terrain и респавнеры, но я не уверен в пользе их работы в ходе загрузки. Там и так есть, чем заняться. То есть, нужна ревизия. Ну а дальше у нас будет несколько классов, весьма, я бы сказал, феерических, и опять же - с неработающим кодом.

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

Британские учОные изобрели компьютер, который, наконец, прошел тест Тьюринга: на любой вопрос он отвечает: "Нет !" и загадочно улыбается. Похоже, в этой теме, как и у мапперов, тоже пора вводить дополнительное правило про дыбу и испанский сапог.

Тогда вопрос такой будет: как экспериментально увидеть, на что действует это самое pdm ? 2 shahvkit: он имеет в виду config\creatures\* disp_walk_stand = и т.д. Но было ощущение, что с параметрами из конфигов стволов оно таки перемножается/суммируется. Гм, так для актора - что можно написать, и на что смотреть, чтобы было сразу НАГЛЯДНО ? Ну поймите вы, что вот так каждому сидеть перебирать все параметры, когда кто-то это уже делал - занятие слегка малоосмысленное.

То есть, все-таки вернуть несколько гулагов под одним смартом ? Да, по сравнению со стэйтами - явно лучше. И можно заодно сбрасывать всякое странное, чего неписи успели неведомым путем нахвататься в предыдущем. Также упрощается контроль за валидностью работ/занятых, и все эти приоритеты {здесь текст удален по причине п2.0 правил} - тоже таки да - проще становится. P.S. А вот по злопамятности неписей, похоже, грядут новые шокирующие подробности... enable_memory_object( ..., false ) - внезапно, похоже, очень даже при чем.

Гм, попробую тогда расшифровать. Правда, не уверен, что еще больше запутаю. у мну иногда проблемы с изложением бывают. По вопросу n1: как минимум часть настроек "отдачи" и иже с ними - оверрайдится моделями. То есть, как анимация запустилась - так и отыгрывает. Другое дело, что, например, при отстреле одиночными, когда настраивал кривые точки прицеливания - ваще не заметил "увода". То есть, если очередью - унесет нафиг. Если один выстрел - возвращается. pdm же - по ходу, неписевые параметры. По крайней мере, на это - они реагируют, а вот дырка от пули и возврат ствола при отстреле - нет. Однако, говорят, что нет. Значит это я просто сильно хотел увидеть - вот и увидел. И, да, нифига не понял, кто отвечает за гуляние ствола в зуме. Просто не интересно было. То есть, да: из 3-х (как минимум) разных историй. И требует бобровольца, который проведет отстрел, меняя что попало как попало, а потом составит отчет. Или просто опубликует уже готовое здесь, а не где-то в теме на тыщу постов. По второму: имеет место смесь пысорудиментов и реально имеющих значение явлений. Пысорудимент - несомненно, различение стволов по clsid, а не по секциям. Ну, как это было с брониками, но выпилено. Со стволами - не выпилено. Одновременно с этим, модель, конечно, не при чем, но при чем - поддержка очередей, подствольников, типа перезарядки/боеприпасов и черт знает чего еще. То есть, на уровне нетпакета как минимум различия. И будешь менять кондишн - а получишь - гранаты в подствольнике. И наоборот. Не удивлюсь также другим эффектам. При этом, да, есть еще и ограничения модели. Но, если ты прописал подствольник модели, у у которой его нет - получишь проблемы в онлайне, однако в офф ни что не мешает твоему творению спокойно существовать. Поменяешь класс стволу, который прописан в олспавне - огребешь "укороченный автомат Стрелка" с кондишн в нуле, или еще чего хуже. А скриптово потом исправлять это переспавном - вот даже не пытайся.

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

На счет act и переименования - там, кстати, дальше будет функция совершенно феерическая. Просто я до нее не дошел еще. В общем, логично, про защиту от странного. Теоретически - не нужна, на практике - вот черт ее знает.

Меня смущает то, что как минимум в двух местах при выборе работ явно требуется сортировка. - объектам, + плоским таблицам. А хранение информации о неписях - вот это - точно надо переделывать все. Ну и, да, если уж переделывать - так мы, помнится, бурно обсуждали в более соседних темах преимущества и недостатки, и я все-таки склоняюсь вообще к убежищам. Вообще чисто движковым. То есть, плясать от оценки движком укромности рельефа в окрестностях некоторой заданной точки (а также -собственно, поиск таких точек), и там все и организовывать. Покойникам же (то есть, всей системе смартов, гулагов и респавнеров) - устроить торжественное погребение.

Итак, внезапно, не смотря на все идеи в духе "форум - закрыть, всех пишущих - на лесоповал", я, все-таки, продолжу. Просто по тому, что единственный известный мне работающий метод избавиться от невыносимого ужаса - озвучить то, что его вызывает. Собственно, те куски, которые были выше - им в общем-то в _g.script вообще не место. Ну вот плохая это идея - оформлять ОДНУ строку отдельной функцией (особенно, в скриптовом языке), формировать там таблицу, возвращать в виде результата, а потом уныло разбирать возвращенную таблицу. И вообще, даже если что-то очень сильно хочется иметь в глобальном нэймспейсе - есть в конце-концов метод _G.* = Ну да ладно. Перейдем, наконец, уже к той части, которая была в оригинале и в очень классических модах. Ну, с первыми двумя все понятно. Как раз тот случай, когда что-то удобно вызывать из глобального пространства. Первое - просто - табличка загруженных "схем". Тут еше отдельный приятный повод для флэйма по поводу "что такое схема", и зачем оно, но для него существует отдельная тема. Про "логику", да. Второе - избавление от некоей монстровидной строки, путем определения функции с коротким именем. Сама функция - получение времени от начала загрузки игры в миллисекундах. Ну, это все знают. Единственно что, сразу возникает вопрос: а нельзя ли оное упрощение как-то еще больше упростить ? Можно, и выиграть при этом в скорости. Но про это будет позже. А вот две следующие - уже вызывают вопросы. Вот на самом деле не знаю, используются ли они где-либо, и определено ли вообще это самое verify_if_thread_is_running() и coroutine.yield(), ибо невозможно объять необъятное силами одного человека, но очевидно, что используемое в оригинале game.time() здесь не подходит, ибо рассчитано на один игровой месяц. По-этому, сразу переписал. Переписал, кстати, в весьма не самом оптимальном виде, поскольку не уверен в моменте использования этой функции. Вторая - то же самое ожидание, но уже в реальном времени и от загрузки. Поскольку реальный месяц без перезагрузки вряд-ли кто будет ждать - вполне допустимо, и вопрос сводится опять же к тому, определено ли coroutine.yield() Две следующих - реально используются, как минимум монстрами (включая, "почему-то", дохлых), БТРами и, видимо, кем-то еще. Вот лень прямо сейчас поиск делать. Привожу сразу оригинал, и попытку это как-то изменить:

<<И собственно почему бы не допилить и причем тут "охота на читеров" я не знаю.>> Ну просто я пока не вижу чего-то такого, требующего радикального вмешательства. В данном случае. Ради 5-ти смартов, сделанных и расставленных неподумавши. Поправить вот эти конкретные 5 штук, да и все. Как и заворачивания работ каждую в отдельный псевдообъект. Мороки много, толк - сомнителен. Как бы, другой конец шкалы радикализма, противоположный объявлению виновниками собственной лажи (или лажи своего Гуру) вот тех самых неведомых читеров.

Ну и напомню хрестоматийный случай с АКСУ и АК длинным в тайнике Стрелка.

Военные постоянно нападают на Деревню Новичков. Как решить эту проблему ? Ответ: Попробовать прописать в gulag_escape.script в работы военным на БП squad = 2 Быстро уйти за радиус алайфа от деревни, дождаться смены дня/ночи. Должно полегчать. Буквально несколько дней назад разбиралось. Подробности см. http://www.amk-team.ru/forum/index.php?showtopic=13078&p=974373 и далее. А вообще - править ПАЧКУ багов в нескольких местах. Поскольку тестеров нормальных для модов нет, и не предвидится - ну, ждите. Через годик сделаю. Для 0309.

Не, ну а по смыслу если ? Применительно к конкретному ТЧ ? Без всяких дополнений/расширений ? Там entity_action() - функция не абстрактная, а делает вполне конкретные вещи. Что-то принимает, и что-то возвращает. Так вот надо ли ее вызывать, чтобы в итоге вернуть результат, если аргумент ранее был получен такой же entity_action() без аргумента, или таки return entity_action():set_action( v ) - более чем достаточно ?

"и конструктор копирования" - и на кой он, в такой вот конкретно форме ? Или даже a = entity_action(); a:set_action( v ); return entity_action( a ) ?

Господа присяжные заседатели, вчера, в соседней палате, лед - тронулся ! То есть, а скажите мне: ни кому ни разу не приходило в голову, что конструкция entity_action( entity_action() ) - несколько странна ?

В смысле, метод есть, и регулярно вызывается. Вот тем самым xr_gulag при распределении работ. Но именно тим - оставляет родной, неписевый. То есть, надо допиливать напильником. Я вот об чем. Делать просто "рандомизацию" - а зачем ? У нас 3-4 смарта с неписями одного вида на локе. Из них в онлайне одновременно - ну вот 3 на Кордоне, 4 на агре. И то не понятно - на кой, собственно, их в онлайне принудительно держать. Сначала героически создаем себе проблемы, затем - героически их преодолеваем. Или еще лучше - устраиваем очередную "охоту на читеров", из-за которых у модододела колбаса в холодильнике плесенью покрылась, и жена с соседом изменила. Аж тьфу.