Скриптование

[Svoboда 3]

Тема для обсуждения скриптов всего и всех в серии игр STALKER.

Задавая вопрос (!):
1. Внимательно изучите суть вопроса. Вопрос должен соответствовать выбранной Вами темы. Это поможет сохранить порядок и читабельность темы, а также облегчит поиск и понимание сего;
2. Изучите то, что уже есть в теме (пролистайте "руками", воспользуйтесь поиском на форуме);
3. Изучите информацию которая может вам помочь:

 

 

Stalkerin. Там есть много хороших статей касательно данной темы.
Уроки по модостроению. Есть рабочие примеры готовых скриптов различного назначения.

 

Справочное руководство по языку Lua 5.1
https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual/ru
Справочник по функциям и классам. Собрано много информации по функциям и классам, не всем, но по основные сведения предоставлены.

 

Логика со вступлением и четырьмя частями:

 

Вступление
Часть первая
Часть вторая
Часть третья
Часть четвертая.

Smart_terrain (в простонароде - гулаг)
Интересный способ настроики логики для гулагов
Скриптовая часть игровой логики

4. Дабы не превращать обсуждение в "кашу" разной информативной направленности, задавайте несколько вопросов по порядку (в разных постах) после того, как получите ответ на предыдущий вопрос;
5. "Спасибо" и тому подобное - будьте так любезны в ПМ. Если не любите писать в ПМ, в конце вопроса напишите фразу: "Заранее спасибо!" - или что-то в этом духе;
6. ПОЖАЛУЙСТА! Указывайте, для какой игры Вам необходима информация (ТЧ, ЧН, ЗП), если стоит мод - укажите название мода;
7. Если Вы что-то сделали и результат не такой, какой Вами задумывался, то, пожалуйста, приводите коды которые Вы изменяли/писали целиком! Это поможет другим правильно ответить на Ваш вопрос, а также оградит Вас от лишней писанины.
8. Оформляйте сообщение. Пользуйтесь тегами для того, чтобы отделить код от текста. Пишите грамотно - ПОЛЬЗУЙТЕСЬ ЗНАКАМИ ПРЕПИНАНИЯ.
9. И помните: «Правильно заданный вопрос – половина ответа».

 

Какие вопросы следует задавать, а какие нет...

 

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

 

Вопросы которые будут удалятся, следовательно их задавать не нужно:
-- Где находится та или иная функция?
Для ответа используем поиск по словам среди файлов оригинальной игры или мода, если объект поиска относится к нему, при помощью программы, которая Вам наиболее симпатизирует;
-- Как сделать что-то/то-то?
С подобными вопросами, либо в "ковырялки", где Вам вероятнее всего так же не ответят, либо выдвигаем мысли, подкреплённые теорией, практикой (идеальный вариант) и здравым рассудком;
-- Вопросы со смыслом: "сделайте", "совместите" и подобными глаголами повелительного наклонения.
-- К тому же удалению будут подвергаться вопросы, в которых масштабно не используются теги, для отделения кода и цитат от основного текста, а также не вписан в спойлер код размером превышающие семь строк.
Ответ на возможно возникший вопрос: В какую тему можно обратиться по поводу логики и спавна объектов?
В тему "ковырялок" соответствующей версии игры, для которой Вы задаёте вопрос.

И последнее: очень рекомендовано к прочтению Правила форума
 

---

[UnLoaded 313]

при ранге ГГ скажем, более 5000, в окне разговора показывать его не мастером, а скажем, легендой?

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

Изменено 9 Февраля 2015 пользователем UnLoaded

[AndrewMor 533]

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

Нет, 5000 - цифирь не максимальная, можно реально и больше набрать. Просто не нашел, где в каком файле, выводится сие название, там где под иконкой Меченого - ранг и его значение выводится при разговоре.

[naxac 2 578]

@AndrewMor, читай: урок по созданию нового ранга Изменено 10 Февраля 2015 пользователем naxac

[AndrewMor 533]

@AndrewMor, читай: урок по созданию нового ранга

Спасибо, все получилось. Не знал про этот урок.

[Desertod 0]

Всем привет ребята. У меня вот такая проблема: мне нужен таймер, что будет не сбрасываться при переходе на другую локацию или после сохранения и загрузки сейва. Вот нашёл вроде бы то что надо http://ap-pro.ru/forum/21-9999-669936-16-1405907977 . Подключил таймер , но после загрузки сейва он всё равно сбрасывается. Что я не так делаю ? Помогите пожалуйста. 

 

Вот геймдата: http://rghost.ru/8VsmQhhKq .

Изменено 12 Февраля 2015 пользователем Desertod

[Zander_driver 10 348]

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

Короче полистал я там написанное. Возник такой вопросец к знатокам Луа, по поводу быстродействия при работе с локальными/глобальными переменными.

Собственно, имеем файл, inv_system.script. В нем среди прочего описан класс Areal со своей пачкой полей-методов, а так же в нем же описан класс Utils_Operator со своей пачкой полей-методов.

Далее. в _g.script:

Inventory_Utils_Operator = inv_system.Utils_Operator()

И затем, в inv_system, в методе __init класса Areal:

self.Utils_Operator = _G.Inventory_Utils_Operator

И когда у нас создается объект класса Areal, мы из него можем использовать методы Utils_Operator, таким путем:

self.Utils_Operator:XXX_Method()

Для чего все именно так и почему:

1) - Utils_Operator используется не только в inv_system, он нужен (вызов его методов) и в некотором другом месте. И в этом другом месте он нужен, когда объект класса Areal не существует.

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

 

Разъясните мне, аргументированно, правильно ли я делаю или нет, с точки зрения быстродействия. В плане скорости доступа к переменным/методам, и в плане времени создания экземпляра класса Areal (если утилс_оператора создавать в нем же, то "время старта" вырастает в разы).

 

 

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

 

[Desertir 202]

@Zander_driver, тов. @Malandrinus показывал в Курилке, что так и сохраняет свой менеджер (ну или что там). Там вроде все аргументированно.

На счет создания одного экземпляра, а зачем класс делать для него? Просто функциями в скрипте не сделать?

[Zander_driver 10 348]

Ты про какой экземпляр, Areal или Utils_Operator? они оба существуют в количестве не более одной штуки.

Зачем класс - ну отчасти для простоты доступа в коде, к полям и методам класса. вместо того чтоб помнить/где-то подсматривать название каждой функции. Да и просто мне так удобнее. Кстати да, я наверно тоже повернут на ООП.

 

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

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

[Dennis_Chikin 3 665]

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

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

Во-вторых - нужно ли оно именно в глобальном пространстве (иногда тактически верно определить внутри модулей).

 

Ну и, да, "простоты" не вижу.

[Desertod 0]

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

[Dennis_Chikin 3 665]

Вот "с какого мода вырезать" - это точно не поможет. Тут надо определиться: что именно надо и для чего. Если нечто полномасштабно-коробочное - поиск по m_timers (несколько страниц назад). Если что-то одноразовое - то какое именно время нужно, и для чего. И, кстати, а нужно ли именно время ?

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

[Desertod 0]

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

[Zander_driver 10 348]

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

Очень странное заявление. Наверное я знаю что делаю в своем коде, нет? Возросшее в разы - просто за счет того что создание одного экземпляра класса Utils_Operator занимает в разы больше времени, чем создание одного экземпляра класса Areal.

Нужно - ровно один, как одного так и другого. Один и создается. И Utils_Operator в любом случае будет нужен в двух местах, есть ли разница где его создавать, если создается он один раз, и создается заранее ввиду длительности самого процесса создания?

DC, Если не передумал еще присматриваться к моему инвентарю, я бы предложил - перестать пока относиться к ООП как к "ненужно-непонятной чертовщине". Вникнуть и понять его преимущества. Потому как этот инвентарь на 100% состоит из классов и методов. Весь код - царство ООП.

И причина тому очень простая. ООП дает преимущество. Реальное. Без него я не знаю как бы я вообще это все делал. наверное никак.

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

[Dennis_Chikin 3 665]

Тогда стартовый пост стоило бы как-то переформулировать, что-ли...

 

Inventory_Utils_Operator = inv_system.Utils_Operator() -- вот он создался. В смысле, объект класса Utils_Operator.

Ссылка на этот объект лежит в _G.Inventory_Utils_Operator.

self.Utils_Operator = _G.Inventory_Utils_Operator -- теперь ссылку скопировали еще и в self.Utils_Operator

 

а вот если self.Utils_Operator = inv_system.Utils_Operator() -- будет столько объектов, сколько раз сделаешь.

 

P.S. Можешь в лицензии запретить персонально мне использовать лицензируемое в каком-либо виде. Буду вынужден делать свое, да.

[Zander_driver 10 348]

Не собираюсь никому что либо запрещать. Или в чем-то ограничивать. Напротив.

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

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

 

Inventory_Utils_Operator = inv_system.Utils_Operator() -- вот он создался. В смысле, объект класса Utils_Operator.

Ссылка на этот объект лежит в _G.Inventory_Utils_Operator.

self.Utils_Operator = _G.Inventory_Utils_Operator -- теперь ссылку скопировали еще и в self.Utils_Operator

 

Я вроде так и писал.

Занятно, но видимо и такое бывает. Когда-то давно у меня то, что теперь является классом Utils_Operator, создавалось долго, устраивало подвисоны и было за это сослано в тот самый _g.script.

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

Время формирования скриптового инвентаря в режиме default: 146.37866210938 миллисекунд. (class Areal)
Время формирования оператора: 1.65636 миллисекунд. (class Utils_Operator)

Замерялось через profile_timer, измеряемый отрезок - собственно метод __init класса.

[Dennis_Chikin 3 665]

если self.Utils_Operator = inv_system.Utils_Operator() у тебя выполняется всего один раз - манипуляции с _G - лишние.

 

По поводу конструкций вида self.obj:f() - ну, тебе решать.

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

[Zander_driver 10 348]

этот Utils_Operator нужен еще в другом месте. совсем в другом.
Хотя раз он теперь создается за 1.6 мс, действительно нет нужды создавать его заранее. Так что да, я неправ)

 

 

По поводу конструкций вида self.obj:f() - ну, тебе решать.

А что в них такого?

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

Может тут мне кто объяснит?

Вот откопал, из своего. Не инвентарь, но близко к нему.

self.reactions[self.data[a].type](self.data[a], SCAS, SCAM)

или вот, уже из инвентаря.

    self.base.statics[self.downbtn]:LMouse(function()
        local wnd = mag_ref_support.GetWND()
        wnd:DescrWndUp()
    end)

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

 

 

[Dennis_Chikin 3 665]

Монстровидны.

По поводу "другого места" - тут все определяется, опять же, нужен ли тебе тот же самый объект, или более другой. Ну, собственно, как и с self.

 

Да, еще: мне категорически не нравится вот такое вот:

 

function actor_binder:__init (obj) super(obj)
  self.weather_manager = level_weathers.WeatherManager()

...

function actor_binder:net_spawn(data)
  self.weather_manager:reset()

...

function actor_binder:update(delta)

self.weather_manager:update()

...

function actor_binder:save_old(packet)

    self.weather_manager:save(packet)

...

function actor_binder:load(reader)

    self.weather_manager:load(reader)

-- да еще и с очевидной ошибкой, там, где было бы достаточно просто

function actor_binder:update(delta)

weather_update()

 

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

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

[Zander_driver 10 348]

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

[Dennis_Chikin 3 665]

Это пример. Пример того, что именно мне не нравится.