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

[Zander_driver 10 343]

  Карлан писал(а):

Я например se_stor никогда не пользовался, как-то без надобности порнуху хранить (но система проста и гениальна, круто)))

В давние времена (Дезертир помнит) у меня была в моде архаически-динозавровая система хранения всего-на-свете в пакетах/псторах физ.объектов. Этот реликтовый монстр утрамбовывал все до битов (ага, даже не до байтов) и засовывал все в какую-нибудь лампочку. Которая ему на локации приглянулась. 8 сохраненных переменных в одном байте нетпакета - это конечно прикольно. Но в итоге этот динозавр вымер (даже архивов не сохранилось), уступив место se_stor. Потому что правда удобнее, для любых технических нужд там сохранять все что вздумается. Так надо ли плодить таких динозавров?

 

  Dennis_Chikin писал(а):

Суть же заказа с class_registrator: Артос его дорабатывал для нетпакетов и хранилища, но в результате "потерялась" никогда не существовавшая совместимость с другим кодом/конфигами. А читаемость скрипта в оригинале была ужасна, в модах - еще хуже. Что надо: отпрепарировать/провести необходимые гибридизации для повышения читабельности, сразу разобрав на блоки - что осталось от оригинала, что от амк, что добавлено для хранилища, что - для пакетов. Ну и откомментить как-то.

Что-то я вообще не понял о чем речь идет. класс_регистратор - это же в основном просто набор строчек наподобие такой

cs_register (object_factory, "CWeaponAK74", "se_item.se_weapon_magazined_w_gl", "WP_AK74", "wpn_ak74_s")

cs_register    (object_factory, "CWeaponAK74",        "se_item.se_weapon_magazined_w_gl",        "WP_AK74",    "wpn_ak74_s")

иногда упакованных в блоки if что-то там then ... end. Или я отстал от жизни и там все иначе?

Как простейший вариант - упаковать вообще все в блоки if then присобачив к каждому комментарий, а для чего нужен этот блок. Больше я не знаю что там еще городить и зачем.

 

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

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

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

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

[Zander_driver 10 343]

  Цитата

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

 

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

Я например, поразмыслив, этот момент так и не понял. Система хранения и таймеры - ну ладно еще допустим взаимосвязаны. Хотя я бы сказал не факт. А третье...

 

  Цитата

 

Если по факту раз n секунд надо лишь проверить, не наступило ли собственно время для события х. То есть, сравниваем нашу константу с game_time(). При чем здесь таймеры ?

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

 

DC: Можно я твой вопрос про таймеры перефразирую немножко иначе. Вот так: Для чего нужно ООП? для каких целей уместно применять, для каких нет. и почему. Сформулируй свой вариант ответа на такой вопрос?

Кстати ответ уважаемого маландринуса, на этот же вопрос, мне тоже любопытен.

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

[Zander_driver 10 343]

 

 

  Dennis_Chikin писал(а):

function init()

local t = actor_data.get_pstor() -- хранилище данных актора

if t.timers then

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

 

 

  Dennis_Chikin писал(а):

из упомянутого 13Гб мода

Кажись, свой я еще не выкладывал.

[Zander_driver 10 343]

 

 

  Dennis_Chikin писал(а):

Нужны диалоги на скриптовом гуе

А диалоги, оформленные как в Mass Effect, не хочешь?

А то ведь будут, запросто.

[Zander_driver 10 343]

 

 

  Shadows писал(а):

Пруф?

Присоединяюсь к вопросу, аж любопытно стало.

[Zander_driver 10 343]

Для тех кто кругом видит свежезакопанные велосипеды маскирующиеся под "сверх-новейшие скриптовые штуковины"

А так же любителей копаться в сыром и неготовом коде.

 

http://rghost.ru/6YYfr8GjH- инвентарь Судьбы Зоны, собственной персоной, как есть. Многие классы/методы не используются, не вызываются, являются рудиментами двухлетней давности или еще что нибудь такое. У кого есть желание, копайтесь

 

А кто хочет готовое и с пояснениями, где что куда и зачем - все так же ждите.

[Zander_driver 10 343]

Я тут скромно встряну со своей темой. Думал-размышлял, куда, и пожалуй таки сюда это постить надо. Ну, мне так думается.

Короч, есть такие объекты, смарт_террейны называются. Пачка методов к ним описана в smart_terrain.script.

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

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

  тык (Показать)

* DBG: smart_terrain:         Капитан Орехов [rank: 267] Location: l01_escape  TABLE:;    {    [KEY:  STRING:exclusive] = VALUE:  BOOLEAN:true;    [KEY:  STRING:community] = VALUE:  STRING:dolg;    [KEY:  STRING:group] = VALUE:  NUMBER:2;    [KEY:  STRING:story_id] = VALUE:  NUMBER:12527;    [KEY:  STRING:o_group] = VALUE:  NUMBER:2;    [KEY:  STRING:level_vertex] = VALUE:  NUMBER:300835;    [KEY:  STRING:smart_terrain_id] = VALUE:  NUMBER:1796;    [KEY:  STRING:squad] = VALUE:  NUMBER:1;    [KEY:  STRING:stay_end] = VALUE:  USERDATA;    [KEY:  STRING:o_squad] = VALUE:  NUMBER:1;    [KEY:  STRING:game_vertex] = VALUE:  NUMBER:208;    [KEY:  STRING:id] = VALUE:  NUMBER:1797;    [KEY:  STRING:se_obj] = VALUE:  USERDATA;    [KEY:  STRING:is_sniper_name] = VALUE:  BOOLEAN:false;    [KEY:  STRING:section_name] = VALUE:  STRING:stalker;    [KEY:  STRING:profile_name] = VALUE:  STRING:kordon_orexow;    [KEY:  STRING:is_sniper] = VALUE:  BOOLEAN:false;    [KEY:  STRING:name] = VALUE:  STRING:orexow;    [KEY:  STRING:weapon_rating] = VALUE:  NUMBER:5;    [KEY:  STRING:team] = VALUE:  NUMBER:10;    [KEY:  STRING:cond] = VALUE:  TABLE:;    Table value:       {       [KEY:  NUMBER:1] = VALUE:  TABLE:;       Table value:          {          [KEY:  STRING:infop_check] = VALUE:  TABLE:;          Table value:             {             }          [KEY:  STRING:infop_set] = VALUE:  TABLE:;          Table value:             {             }          [KEY:  STRING:section] = VALUE:  STRING:true;          }       }    [KEY:  STRING:class_id] = VALUE:  NUMBER:34;    [KEY:  STRING:rank] = VALUE:  NUMBER:237;    }

* DBG: smart_terrain:         Капитан Орехов [rank: 267] Location: l01_escape
 TABLE:;
   {
   [KEY:  STRING:exclusive] = VALUE:  BOOLEAN:true;
   [KEY:  STRING:community] = VALUE:  STRING:dolg;
   [KEY:  STRING:group] = VALUE:  NUMBER:2;
   [KEY:  STRING:story_id] = VALUE:  NUMBER:12527;
   [KEY:  STRING:o_group] = VALUE:  NUMBER:2;
   [KEY:  STRING:level_vertex] = VALUE:  NUMBER:300835;
   [KEY:  STRING:smart_terrain_id] = VALUE:  NUMBER:1796;
   [KEY:  STRING:squad] = VALUE:  NUMBER:1;
   [KEY:  STRING:stay_end] = VALUE:  USERDATA;
   [KEY:  STRING:o_squad] = VALUE:  NUMBER:1;
   [KEY:  STRING:game_vertex] = VALUE:  NUMBER:208;
   [KEY:  STRING:id] = VALUE:  NUMBER:1797;
   [KEY:  STRING:se_obj] = VALUE:  USERDATA;
   [KEY:  STRING:is_sniper_name] = VALUE:  BOOLEAN:false;
   [KEY:  STRING:section_name] = VALUE:  STRING:stalker;
   [KEY:  STRING:profile_name] = VALUE:  STRING:kordon_orexow;
   [KEY:  STRING:is_sniper] = VALUE:  BOOLEAN:false;
   [KEY:  STRING:name] = VALUE:  STRING:orexow;
   [KEY:  STRING:weapon_rating] = VALUE:  NUMBER:5;
   [KEY:  STRING:team] = VALUE:  NUMBER:10;
   [KEY:  STRING:cond] = VALUE:  TABLE:;
   Table value:
      {
      [KEY:  NUMBER:1] = VALUE:  TABLE:;
      Table value:
         {
         [KEY:  STRING:infop_check] = VALUE:  TABLE:;
         Table value:
            {
            }
         [KEY:  STRING:infop_set] = VALUE:  TABLE:;
         Table value:
            {
            }
         [KEY:  STRING:section] = VALUE:  STRING:true;
         }
      }
   [KEY:  STRING:class_id] = VALUE:  NUMBER:34;
   [KEY:  STRING:rank] = VALUE:  NUMBER:237;
   }

 

 

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

Например - общая таблица npc_info, индексирована как мы помним, id объектов. интересно для чего в таком случае, id также содержится в самой таблице в качестве поля?

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

Видимо архи-нужная, раз эти сквад и гроуп записаны в таблицу непися каждый по два раза дублируя друг друга - поля squad и o_squad, group и o_group. Я вывел такую статистику по всем смартам на всех локациях, просмотрел, и... у 99% нпс сквад всегда 0, и группа тоже 0.
у всех остальных, у того самого одного процента, сквад 1, группа 2. и все эти особенные нпс - занимают эксклюзивные работы и имеют собственный стори_ид.

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

Изменено 2 Октября 2015 пользователем Zander_driver

[Zander_driver 10 343]

Ну да, smart_terrain не является рекордсменом среди нечитаемых скриптов) все более менее сносно, но притом весьма горбато работает. Это вот и раздражает слегка.
Хотя, не настолько чтобы я взялся собственноручно его переписывать. Если постараться - читаемо, да. И в принципе работает. Так что при отсутствии альтернатив пока сойдет и то что есть.

[Zander_driver 10 343]

я у себя вообще оставил только один тип - gulag_general. соответственно дописал как мне надо gulag_general.script, а все остальные gulag_XXX.script выбросил на помойку.

[Zander_driver 10 343]

 

 

  Dennis_Chikin писал(а):

Вообще-то "все остальные" - имеют смысл с точки зрения размера файла

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

Нет. Я просто это все выбросил как ненужный хлам, а размер gulag_general вырос незначительно.

[Zander_driver 10 343]

 

 

  Карлан писал(а):

Ню-ню, я тебе уже говорил не раз о тучах на горизонте от этого самого gulag_general

Что-то я подзабыл. напомни?

 

 

  Карлан писал(а):

В любом случае все эти системы теряют всякий смысл ровно на этом (если, конечно, понятие "новый" движок я верно для себя растрактовал):

Возможно. Даже спорить не буду, т.к. не вникал детально в то, что на эту тему сделано в "других движках".

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

[Zander_driver 10 343]

Вот кстати о тех же смартах и гулагах...

в xr_gulag в методе __init класса gulag, вставил такую строку

    self.Task_Reactor = task_creator.Task_Reactor(self)

    self.Task_Reactor = task_creator.Task_Reactor(self)

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

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

И в отладочных целях в логе подсчитывается всякая статистическая инфа по созданию этих объектов...

 

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

smart_terrain - метод __init вызван 194 раза, объектов смартов создано - 194.

xr_gulag - метод __init вызван 194 раза, объектов гулагов создано - 194.

task_creator - создание вызывалось так же 194 раза. но объектов с уникальными именами получилось 90, и в итоге имеем 90 записей в se_stor.

 

т.е. на самом деле "по-настоящему нужных", уникальных смартов-гулагов в игре 90. но зачем-то создание объектов вызывается по 2-3 раза... я бы понял если бы было 90 * 2 = 180 вызовов. Но 194... это в моей голове вообще не укладывается. Зачем, почему...

Почему нельзя создать столько объектов, сколько действительно нужно?

 

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

Изменено 9 Октября 2015 пользователем Zander_driver

[Zander_driver 10 343]

ах да, окей...

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

[Zander_driver 10 343]

 

 

  Карлан писал(а):

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

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

[Zander_driver 10 343]

 

 

  abramcumner писал(а):

А вот зря. Если забить в гулагах на группы/сквады, то НПЦ на уровне запишутся в группу 0 сквад 0

Как у меня например

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

 

 

  Dennis_Chikin писал(а):

это для прости-господи респавнеров

Почитал. порадовался что убил к черту все респавнеры) вот реально не надо вообще ни зачем.

 

 

  Dennis_Chikin писал(а):

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

И даже за этим - не нужен. Имхо и поидее, "рождать" должна живая аномалия. А если аномалия сгинула то и появиться уже ничего не должно.

 

 

  Dennis_Chikin писал(а):

А не хранить всякую ересь в нетпакете актора.

Спаси и сохрани)

 

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

[Zander_driver 10 343]

  Dennis_Chikin писал(а):

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

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

 

 

  Dennis_Chikin писал(а):

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

Ну вот таки вместо кучи ручной и несколько кропотливой работы можно все же попробовать доверить все автоматике. Все ж гулаги у меня под gulag_general.script работают, послав далеко все остальные gulag_XXX и избавив разработчика (не только меня..) от необходимости руками брать молоток и прибивать гвоздями то что прибиваться не должно вообще, даже если есть в этом сюжетная необходимость.

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

 

Edit:

Немного покопался... метод онлайнового объекта нпс obj:change_team(team, squad, group) - разве не позволяет там где надо установить то что надо? или я что то не понимаю

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

[Zander_driver 10 343]

 

 

  Dennis_Chikin писал(а):

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

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

 

 

  Dennis_Chikin писал(а):

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

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

 

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

[Zander_driver 10 343]

 

 

  Dennis_Chikin писал(а):

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

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

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

[Zander_driver 10 343]

 

 

  Полтергейст писал(а):

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

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

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

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

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

[Zander_driver 10 343]

  Полтергейст писал(а):

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

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

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

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

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

[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