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

[proper70 72]

Кстати, по звукам и по скорости загрузки игры.

По звукам:

Очень странно, что у ПЫСов нет обьекта звук, который можно создать через alife():create(). Как с рестрикторами и прочими вспомогательными фичами. А ведь как было бы просто: сделал alife():create("sound_object") с его логикой, как у рестриктора, указанием пути к файлу и когда играть, а когда замолчать - и все))

Я тут просто в .ОП-2 делал сюжет по поиску тайников по звуку и реально пришлось изобретать велосипед, реализуя запуск и отключение звуков по сюжету) Но копаясь в скриптах, я понял, что ПЫСам это просто было не нужно - нет у них таких квестов - вот они и не сделали)

А насчет быстродействя: Buusty сегодня наконец-то вычистил алспаун от дублирующих путей (их просто невероятное количестово было) и он пишет, что ОП1 стал грузиться чуть ли не быстрее чем оригинал ТЧ. А у меня оригинал ТЧ вообще грузится 10-15 секунд. Так что вот так, уважаемые Господа)

 

А классы... они только ПОВЫШАЮТ производительность, и никак не понижают - это основы ООП)

Изменено 12 Января 2013 пользователем proper70

[7.9 174]

я в своём моде со звуками вообще никак не работаю, зачем мне расширять sound_theme

Если-бы функционал был - наверняка работал-бы. А если не работаешь, то, получается, что не надо

Изменено 12 Января 2013 пользователем 7.9

[ХuMuK 0]

self.Tbl = {}

self.Tbl[Name] = {}

self.Tbl[Name]["value"] = Value

self.Tbl[Name]["Time"] = Time

Как сохранить такую таблицу в pstor actor'у и как потом загрузить?

[Malandrinus 611]

Shredder,

Это первое на что я грешил, getFS():exist(), т.е. проверка на существование.

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

 

proper70,

Очень странно, что у ПЫСов нет обьекта звук, который можно создать через alife():create(). Как с рестрикторами и прочими вспомогательными фичами. А ведь как было бы просто: сделал alife():create("sound_object") с его логикой, как у рестриктора, указанием пути к файлу и когда играть, а когда замолчать - и все))

Зато у них есть переключаемая логика, которая делает в точности это и которую можно прикрутить к совершенно любому объекту.

 

А классы... они только ПОВЫШАЮТ производительность, и никак не понижают - это основы ООП)

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

[Shredder 49]

Да, ты совершенно прав. Основная задержка приходится вот на этот участок:

if _self.is_combat_sound then
_self.npc[npc_id].max = npc:add_combat_sound(_self.path, nstl, snd_type.talk, 2, 1, _self.npc[npc_id].id,"bip01_head") - 1
else
_self.npc[npc_id].max = npc:add_sound(_self.path, nstl, snd_type.talk, 2, 1, _self.npc[npc_id].id) - 1
end

 

Для самого первого НПС, вышедшего в онлайн у меня задержка составляет порядка секунды, для последующих порядка 0,02 секунды на чистой версии игры, и 0,007 после переделки без использования классов. Так что проблема лагов при выходе нпс в онлайн не здесь, т.к. при приближении к Скадовску метод net_spawn выполняется достаточно быстро, но фризы ощутимы. В общем, копаю дальше...

[abramcumner 1 023]

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

Начни с того, что отключи биндер у НПЦ, проверь фризы. Если исчезнут, значит дело в скриптах. Дальше замеряешь методы биндера reinit, load, reload, net_spawn, первое выполнение апдейта. Смотришь тайминги.

 

А отказ от классов - это уже тяжелая артиллерия, если совсем не найдешь причину фризов.

Изменено 12 Января 2013 пользователем abramcumner

[A.l.e.x.a.n.d.r. 0]

Подскажите что означает self. Везде где искал, написано только что он "обозначает данный, текущий экземпляр класса", но из этого я ничего не понял. Можете поподробнее рассказать для чего он?

 

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

ColR_iT

Изменено 13 Января 2013 пользователем ColR_iT

[A.l.e.x.a.n.d.r. 0]

Я знаю что означает это определение. Но можете всего лишь поподробнее написать зачем он вообще нужен этот self?

Изменено 14 Января 2013 пользователем A.l.e.x.a.n.d.r.

[Desertir 202]

A.l.e.x.a.n.d.r., не обижайся, но если ты действительно знаешь, что означает это определение, то таких банальных вопросов бы и не было. Для того, чтобы действительно понять, что такое self нужно знать и понимать что такое класс, экземпляр класса, свойство, метод. self это сам объект, для которого вызван метод (object:method() - в классе в методе method объектом object является self)

Для меня вопрос "зачем вообще нужен self?" все равно что "зачем нужно ООП?", складывается впечатление, что человек очень далек от программирования. Хотя конкретный, но в то же время расплывчатый, ответ на твой вопрос можно дать - self может быть использован для (почти) всего, смотря для чего класс. Да, в некоторых случаях self не используется, но с ходу такой класс я не придумаю, ибо это какойто класс-пустышка.

PS: посмотри примеры в скриптах наконец!

[Labus 0]

Как заставить скрипт, при обращении к конфигу, не обращать внимания на класс объекта?

Делаю несколько итемов на базе гранат. НПС их либо боятся как гранат, либо не боятся даже гранат (до момента взрыва, разумеется)

...
if bd_type == danger_object.grenade then
local ini = system_ini()
local bolt = ini:section_exist("grenade_bolt")
local f1 = ini:section_exist("grenade_f1")
local rgd5 = ini:section_exist("grenade_rgd5")
if bolt == true then
return false
end
if f1 == true then
return true
end
if rgd5 == true then
return true
end
...

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

Изменено 14 Января 2013 пользователем Labus

[Shredder 49]

Да, повеселил ))) Ты хоть напиши какую версию игры ковыряешь или мод? И в тему Ковырялок бы этот вопрос лучше.

[Labus 0]

Shredder, чистая 1.0004

Изменено 14 Января 2013 пользователем ColR_iT

[ColR_iT 171]

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

Car = {_model = "", _year = 0, _type = ""}

function Car:setData (model, year, type)
self._model = model
self._year = year
self._type = type
end
function Car:getData ()
print (self._model.."; "..self._year.."; "..self._type)
end

local Tarantayka = Car
Tarantayka:setData("ZAZ", 1970, "SUV")
Tarantayka:getData()

Подправил... Вот так будет нагляднее.

 

Вот здесь: >>ClicK Me<<, на пятой странице, весьма доступно описан этот момент.

Изменено 14 Января 2013 пользователем ColR_iT

[Shredder 49]

ColR_iT, Интересный подход. А где конструктор? И local Tarantayka = Car, разве в Tarantayka будет новый объект? Там же будет ссылка на всё тот же Car. Как создать несколько экземпляров? И замерял ли скорость работы такого ООП? Извиняюсь, что столько вопросов, но на первый взгляд ООП рядом не стоит.

 

Labus, ТЧ не занимаюсь.

 

После Вот так будет нагляднее. совсем голову сломать можно

Изменено 14 Января 2013 пользователем ColR_iT

[ColR_iT 171]

Другого ООП в Lua нет, всё реализуется посредством таблиц.

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

[Labus 0]

Shredder, а как в ЗП заставить скрипт не обращать внимания на класс объекта? Понимаю, вопросы глупые, но поиск не выдает ничего на фразы. Только на отдельные слова.

 

Форматирую текст перед отправкой. Писать жирным шрифтом на форуме запрещено.

ColR_iT

 

Прошу прощения, только что заметил, хотел исправить.

Изменено 14 Января 2013 пользователем Labus

[Shredder 49]

ColR_iT, как нет, а в сталкере что?

 

 

class "SurgeManager"
function SurgeManager:__init()
end
...

 

 

хотя и работают отвратительно...

 

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

 

Labus, я совсем не понимаю твой вопрос.

Изменено 14 Января 2013 пользователем Shredder

[Malandrinus 611]

Shredder,

на первый взгляд ООП рядом не стоит.

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

Что касается Lua, то здесь имеем прототипную реализацию ООП. Если вкратце, то понятия класс как такового нет. Есть сразу объект, и класс ты строишь, дополняя этот объект методами, данными и пр. Новые "классы" таким образом строятся на основе копий объектов.

а в сталкере что?

class "SurgeManager"

 

Это расширение Lua, называемое luabing. В сущности, к собственно Lua ничего особенного не добавляет и нужно в основном для того, чтобы экспортировать классы C++. К слову сказать "class" - это синтаксически функция. Поэтому вот это

class "SurgeManager"

синтаксически эквивалентно такой строке

class("SurgeManager")

т.е. никаких "классов" с точки зрения Lua не появилось. Этот вызов регистрирует некий внутренний пользовательский объект в luabind. Также выполняет клонирование прототипа, если используется наследование в такой форме

class "SurgeManager" (<базовый класс>)

Всё это просто некий мелкий сервис. Тоже самое можно сделать и прямо на таблицах.

[Shredder 49]

И всё-таки на первый взгляд трудно было увидеть ООП. Взглянем ещё раз

Car = {_model = "", _year = 0, _type = ""}

Создали таблицу. Если конечно любую таблицу называть объектом, то да, ООП на лицо.

function Car:setData (model, year, type)
self._model = model
self._year = year
self._type = type
end

Функция - сеттер, устанавливает знаечения полей в таблице Car и только в ней

function Car:getData ()
print (self._model.."; "..self._year.."; "..self._type)
end

Функция "печатает" содержимое поле, дальше совсем не понятно

local Tarantayka = Car:setData("ZAZ", 1970, "SUV")

В Car устанавливаются значения полей, причём в Tarantayka будет nil, т.к. функция ничего не возвращает

Tarantayka:getData()

Тут просто вылетит, т.к. вызываем метод от nil. Поправте, если ошибаюсь.

P.S. Повторюсь, что прочитав статью, понял, как реализуется прототипное ООП в lua, тут я это никак не увидел

 

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

ColR_iT

Изменено 14 Января 2013 пользователем ColR_iT

[Malandrinus 611]

Shredder,

Если конечно любую таблицу называть объектом, то да, ООП на лицо.

Нет, ООП не начинается с таблиц или даже классов. ООП начинается с проектирования класса (или таблицы Lua, если это то, что мы имееем для реализации). Когда структура таблицы спроектирована с учётом идей ООП и потом соответственно используется, вот тогда мы имеем ООП. Есть же основные принципы: инкапсуляция, наследование, полиморфизм. Как они технически реализуются в общем-то неважно, хотя разумеется язык, под эти идеи специально заточенный, использовать будет удобнее. И это только принципы дизайна классов. Их ещё надо правильно применить, и за программиста это никто не сделает.

 

local Tarantayka = Car:setData("ZAZ", 1970, "SUV")

В Car устанавливаются значения полей, причём в Tarantayka будет nil, т.к. функция ничего не возвращает

Tarantayka:getData()

Тут просто вылетит, т.к. вызываем метод от nil. Поправте, если ошибаюсь.

Ну разумеется вылетит, поскольку сам пишешь, что setData ничего не возвращает. Напиши там return self и будет работать, хотя не совсем ясно, какое это отношение имеет к сути ООП.

К слову сказать, здесь на лицо типичный стилевой косяк, а именно именование метода getData не соответствует его функционалу. Он ничего не получает, а только показывает данные. Поэтому назвать его стоило бы showData или printData, но никак не getData.

 

 

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

 

Я и не утверждал, что это полноценная реализация объектного программирования. Я сразу оговорился, что сути ООП это не передаст, а вот суть поста - да. Это лишь пример, максимально простой, для восприятия не осведомлённому человеку.

ColR_iT

Изменено 14 Января 2013 пользователем ColR_iT