Прозекторская

[Dennis_Chikin 3 658]

"Вскрытие показало, что больной умер от вскрытия."

Тема для "крупной формы", то есть, на уровне скриптов целиком или больших частей оных скриптов. "Что у него внутри, зачем оно там, и что с этим можно сделать ?"

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

[Zander_driver 10 334]

 

 

нет способа задать его при выдаче работ

почему? не понял. Есть же движковый метод. нпс пришел в онлайн - установили ему это все.

 

 

В смысле, прописав в свойства смарта или в работы.

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

 

to Karlan: спасибо кэп. Я так и думал. Я только не пойму почему один из вас говорит что метод этот давно есть (он вроде как и в оригинале был...) а другой утверждает что его нет.

[Dennis_Chikin 3 658]

В смысле, метод есть, и регулярно вызывается. Вот тем самым xr_gulag при распределении работ. Но именно тим - оставляет родной, неписевый. То есть, надо допиливать напильником. Я вот об чем.

 

Делать просто "рандомизацию" - а зачем ? У нас 3-4 смарта с неписями одного вида на локе. Из них в онлайне одновременно - ну вот 3 на Кордоне, 4 на агре. И то не понятно - на кой, собственно, их в онлайне принудительно держать.

 

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

Изменено 19 Ноября 2015 пользователем Dennis_Chikin

[Zander_driver 10 334]

 

 

То есть, надо допиливать напильником. Я вот об чем.

Если брать оригинал, то там просто все надо допиливать напильником...

И собственно почему бы не допилить и причем тут "охота на читеров" я не знаю.

[Полтергейст 37]

Касательно допиливания smart_terrain'ов напильником. Я так думаю, лучше все работы завернуть в класс с соответствующими методами. Т.е. чтобы каждая работа была не табличкой, а объектом класса. Для объединения работ с одним "gulag type" создать ещё один класс, в который засунуть проверку условий приёма NPC и всякие атавизмы типа номерных состояний.

 

[Карлан 1 049]

@Полтергейст, это усложнение, которое по моему не нужно, там и так слишком много ненужного ооп. все это прекрасно оформляется в табличном виде, не в первозданном естественно.

[Dennis_Chikin 3 658]

<<И собственно почему бы не допилить и причем тут "охота на читеров" я не знаю.>>

 

Ну просто я пока не вижу чего-то такого, требующего радикального вмешательства. В данном случае. Ради 5-ти смартов, сделанных и расставленных неподумавши.

Поправить вот эти конкретные 5 штук, да и все.

 

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

Мороки много, толк - сомнителен.

 

Как бы, другой конец шкалы радикализма, противоположный объявлению виновниками собственной лажи (или лажи своего Гуру) вот тех самых неведомых читеров.

[Полтергейст 37]

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

При правильном подходе толк будет.

Во-первых, вместо хранения кучи таблиц, описывающих работы с одинаковой логикой, достаточно всего один раз их преобразовать в объекты. Так, чтобы на одну секцию логики приходился только один объект  работы. В этих же объектах хранить табличку NPC, назначенных на эту работу. Сокращение количества записей о работах может увеличить производительность. Да и на каждый чих дёргать работы из таблицы уже не нужно будет.

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

 

Для реализации поддержки нескольких "gulag type" потребуется как-то объединять работы разных типов. Возможно потребуется делать ещё один класс, хотя можно попробовать обойтись и обычной таблицей. Если бы не было номерных состояний и списка группировок в строке communities, то этого можно было бы вообще не делать.

Изменено 20 Ноября 2015 пользователем Полтергейст

[Карлан 1 049]

это все теория, и я сомневаюсь что от этого подхода будет прирост производительности, ты впендюриваешь еще одно нагромождение совершенно не нужное, когда надо и так разгружать то что имеется. если ты сделаешь объединение разных типов работ, от этого резко упадет наглядность работ для гулага, и можно будет запросто запутаться при создании (это моя практика), а еще надо будет учитывать динамические лтх, и, прости хоспаде, стейты. или у тебя в планах еще один какой-нибудь smart_gulag написать на 40кб?

[Dennis_Chikin 3 658]

Меня смущает то, что как минимум в двух местах при выборе работ явно требуется сортировка. - объектам, + плоским таблицам.

А хранение информации о неписях - вот это - точно надо переделывать все.

 

Ну и, да, если уж переделывать - так мы, помнится, бурно обсуждали в более соседних темах преимущества и недостатки, и я все-таки склоняюсь вообще к убежищам. Вообще чисто движковым.

 

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

Покойникам же (то есть, всей системе смартов, гулагов и респавнеров) - устроить торжественное погребение.

Изменено 20 Ноября 2015 пользователем Dennis_Chikin

[Полтергейст 37]

 

 

еще одно нагромождение совершенно не нужное, когда надо и так разгружать то что имеется

Это и будет то, что имеется, просто методы будут вызываться не из смарта, а из самой работы. Один раз при загрузке работ преобразовывать их из таблиц в объекты, объединяя при этом работы с одинаковой секцией логики в один объект. Все эти объекты занести в индексированную таблицу (которая self.Job) и в хеш-таблицу, в которой ключом будет имя секции. Вот, собственно, и всё.

 

 

 

а еще надо будет учитывать динамические лтх, и, прости хоспаде, стейты.

А что их учитывать? Для каждого типа работ сделать промежуточный объект, в котором будет храниться вся инфа о типе работ (имя ltx и ссылка на него, ссылка на gulag_***.script, текущий state), и пропускать все обращения к gulag_***.script через него.

 

 

если ты сделаешь объединение разных типов работ, от этого резко упадет наглядность

Во избежание путаницы не использовать несколько типов работ и переключение state в одном смарте. От последнего со временем вообще лучше избавиться.

 

 

 

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

Как тогда быть с путями, логикой и именованием этих "укрытий"? Да и рельеф на других уровнях (где игрок не был ещё) вряд ли можно просчитать...

[Dennis_Chikin 3 658]

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

 

Правка заведомо кривых конфигов скриптами - занятие почтенное, традициями освященное, но не сильно благодарное, да.

[Zander_driver 10 334]

 

 

и переключение state в одном смарте. От последнего со временем вообще лучше избавиться.

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

У меня вот от 4 до 8 стейтов в каждом гулаге... что я делаю не так.

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

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

[Полтергейст 37]

Чем вам не угодили стейты, почему от них надо избавляться?

Потому что вместо них можно использовать несколько gulag type. В конфиге это будет выглядеть примерно так:

 

 

[smart_terrain]
type = general_lager, esc_fabrika_bandit_normal, esc_fabrika_bandit_alarm
;больше в этой секции ничего не надо писать

[general_lager]
cond = {+esc_kill_bandits_quest_done}
;Пишем условие не для смарта целиком, а для каждого типа отдельно. Использовать вместо state.

[esc_fabrika_bandit_normal]
cond = {-esc_kill_bandits_quest_done !gulag_has_alarm}
groups = 1,2,3,4 ;это просто для примера
squads = 5,6,7,8 ;это тоже

[esc_fabrika_bandit_alarm]
cond = {-esc_kill_bandits_quest_done =gulag_has_alarm}
groups = 1,2,3,4 ;это просто для примера
squads = 5,6,7,8 ;это тоже

 

Вместо использования состояний, тип esc_fabrika_bandit разделён на esc_fabrika_bandit_normal и esc_fabrika_bandit_alarm. А general_lager здесь для того, чтобы не делать отдельный несюжетный смарт esc2_st_fabric.

Изменено 24 Ноября 2015 пользователем Murarius

[Dennis_Chikin 3 658]

То есть, все-таки вернуть несколько гулагов под одним смартом ?

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

 

Также упрощается контроль за валидностью работ/занятых, и все эти приоритеты {здесь текст удален по причине п2.0 правил} - тоже таки да - проще становится.

 

 

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

Изменено 21 Ноября 2015 пользователем Dennis_Chikin

[dsh 3 824]

 

 

Вместо использования состояний, тип esc_fabrika_bandit разделён на esc_fabrika_bandit_normal и esc_fabrika_bandit_alarm. А general_lager здесь для того, чтобы не делать отдельный несюжетный смарт esc2_st_fabric.

 

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

[Полтергейст 37]

 

 

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

Для отдельных NPC порядок посещения смартов определяется в секции smart_terrains из customdata. На него эти правки вообще не влияют.

Для всех обитателей смарта такого механизма и в оригинале не было. Можно было только запретить всем идти в указанный смарт, но это и после правок можно делать. Просто надо будет писать конфиг так, чтобы при определённом условии все типы работ блокировались, и все с них выгонялись.

[Карлан 1 049]

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

Изменено 21 Ноября 2015 пользователем HellRatz

[Zander_driver 10 334]

Потому что вместо них можно использовать несколько gulag type

Хоть убейте меня я не понимаю зачем.

И вот эта простыня что ниже приведена - это теперь на каждый гулаг вот такое городить?

т.е. у меня например получится что-то вроде такого

[smart_terrain]
type = lager1, lager2, lager3, lager4, lager5, lager6, lager7, lager8
[lager1]
cond = {дневное время суток, дождя нет, выброса нет, никто не нападает}
[lager2]
cond = {дневное время суток, дождя нет, выброса нет, на нас напали}
[lager3]
cond = {дневное время суток, дождя нет, случился выброс. никто не нападает}
и т.д... ... ...

И вот под каждый смарт городить такую простыню? И вбивать туда условия одни и те же для всех смартов? и "сценочные уникальные" туда же, ага.

Нет, я конечно уважаю чужое стремление заниматься мартышкиным трудом, писать под каждый смарт простыню конфига, под каждый gulag_type свой gulag_xxx.script, что в итоге оборачивается такими же километровыми простынями в скриптах занимающихся обработкой работ и гулагов. И вообще любую проблему можно решить, написав тонну конфига. Ну, или попытаться.

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

 

Я ни на чем не настаиваю разумеется. Просто имхо. Не могу молчать когда в очередной раз такое вижу...

 

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

Есть смарт, у него есть гулаг. Всегда один и тот же тип, больше не надо. Все gulag_type выпиливаются без сожалений, остается gulag_general. Зачем? сокращаем объемы кода который надо писать для гулага. Просто в дикое число раз сокращаем. Заодно убиваем необходимость писать вышепоказанные простыни. Вообще не надо.

У этого гулага может быть 2,3,5,10,25 стейтов, сколько душе угодно. стейты обрабатываются кодом одного и того же гулага, в одном и том же месте. Они вообще ничего под себя писать не просят. И переключаются в одном и том же месте для всех гулагов. Просто голову немного включить, ага. Ну и наконец работы, в виде путей с вбитыми в них настройками всего-что-душе-угодно.

Вот и что еще надо? Остается у нас один gulag_general.script которого хватает вообще на все случаи жизни, из тонны конфигов для гулагов остается пара файлов. smart_terrain_presets и gulag_general опять же...

В результате приходите на голую локу, на целину. спавните смарт_террейн, ставите работы. и все...

закинули изменения в спавн, запустили игру и гулаг уже работает отрабатывая все что положено, все на что у вас фантазии хватило. 10-20 минут на создание смарта с абсолютного нуля.

И это не текст в духе "смотрите что я сделал". Это намек тем кто хочет делать так чтоб не убивать на это тонны времени и получать результат. Делайте сами как вам надо, я дорожку показал. Остальные будут писать свои простыни на каждый гулаг и тыкать в вас пальцем.

 

 

Изменено 21 Ноября 2015 пользователем Zander_driver

[Полтергейст 37]

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

Упрощение - в наглядности. С номерными state не сразу понятно, что они значат, надо их для каждой работы прописывать, надо искать, где и как они считаются. К тому же все эти 'if type == "gulag_1" then ... elseif type == "gulag_2" then' выглядят не очень красиво.

А так сразу видно, какие работы и при каких условиях доступны, всё собрано в одном конфиге. Нет разделения на несколько смартов.

 

Именно вот в данный конкретный момент для меня, когда я не смогу сидеть и переделывать все что есть под о великое.

Если сделать, чтобы работало и так и так, то переделывать не обязательно. Разве что оставить на будущее парочку переменных, которыми при необходимости можно отключить старый способ обработки.

 

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

Работа смарта - то же, что и раньше. То, что хранится в таблице Jobs.

Тип работы, gulag type - то, что в конфиге пишется в строке type.

 

И вот эта простыня что ниже приведена - это теперь на каждый гулаг вот такое городить?

При правильной организации самой логики (logic@что-то_там) чтобы получить такую простыню, надо очень постараться. Часть условий просто уйдёт внутрь логики. Вместо переключения gulag type будет привычное переключение секций логики персонажей. Сюжетные условия редко включают в себя что-то кроме инфопоршней, и больше двух-трех type вряд ли потребуют для себя. Те единичные случаи, где условия будут выглядеть слишком длинно и непонятно, можно засунуть в функцию в xr_conditions и вызывать оттуда.

 

И вбивать туда условия одни и те же для всех смартов?

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

 

писать под каждый смарт простыню конфига, под каждый gulag_type свой gulag_xxx.script

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

В принципе, можно и с checkStalker/checkMonster также поступить, но тогда или строка cond разбухнет ещё больше, или потребуется делать ещё один condlist в конфиге. Тут пока ещё есть над чем думать.

 

И вообще любую проблему можно решить, написав тонну конфига. Ну, или попытаться. Просто попробуйте представить объемы этих простыней... попробуйте представить их редактирование рядовым мододелом

Оттого, что это всё будет не в виде одной простыни, а раскидано по параметрам путей, конфигам и скриптам, меньше всё равно не получится. Можно конечно пытаться делать "самособирающуюся" из путей логику, но обобщить и "сжать" всё - не получится. Где-то всё равно это придётся писать, особенно для сюжетной логики.

Изменено 23 Ноября 2015 пользователем Полтергейст

[Карлан 1 049]

"А так сразу видно, какие работы и при каких условиях доступны, всё собрано в одном конфиге. Нет разделения на несколько смартов."

 

ага, и имеем теже if gulag_type then только в виде кондлиста в логике, ну добавь всю логику в скрипт, вот тебе тоже вполне все наглядно. для тебя текущий синтаксис логики не нагляден, для меня более чем, вот и тут также я для себя не вижу никаких реально помогающих упрощений, от того что ты крючки из одного места в другое перекидываешь они, крючки, нагляднее и проще становятся лишь исходя из твоей субъективной точки зрения, меня и так все устраивает. в xr_gulag написан необходимый функционал для управления лагерями, вроде тоже достаточно удобный.

 

"Часть условий просто уйдёт внутрь логики."

 

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

 

"Можно конечно пытаться делать "самособирающуюся" из путей логику"

 

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

 

 

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