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

[UnLoaded 313]

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

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

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

[AndrewMor 529]

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

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

[naxac 2 447]

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

[AndrewMor 529]

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

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

[Desertod 0]

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

 

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

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

[Zander_driver 10 341]

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

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

Собственно, имеем файл, 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 341]

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

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

 

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

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

[Dennis_Chikin 3 658]

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

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

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

 

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

[Desertod 0]

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

[Dennis_Chikin 3 658]

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

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

[Desertod 0]

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

[Zander_driver 10 341]

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

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

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

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

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

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

[Dennis_Chikin 3 658]

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

 

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 341]

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

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

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

 

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 658]

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

 

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

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

[Zander_driver 10 341]

этот 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 658]

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

По поводу "другого места" - тут все определяется, опять же, нужен ли тебе тот же самый объект, или более другой. Ну, собственно, как и с 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 341]

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

[Dennis_Chikin 3 658]

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