Snusmumriken
Фаркрай который на крайэнжин
Snusmumriken
Шо, нда нарушаем?
Немножко попользовавшись ты внезапно обнаруживаешь что местная ECS напрямую завязана на рендер, и следовательно в основном потоке. Системы сообщений нет, например.
Snusmumriken
Крайэнжином, чем ещё?
Serhii
Крайэнжином, чем ещё?
так и фар край уже давно не на крайенжине
Serhii
Согласно официальному интервью с Луи-Пьер Фараном (англ. Louis-Pierre Pharand), главным продюсером Far Cry 2, в движке Dunia Engine использовалось лишь 2—3 процента от кода движка CryEngine, разработанного немецкой компанией Crytek для FarCry 1, так как код всего CryEngine был полностью переписан. (с) Википедия
Snusmumriken
Да всем насрать, тогда не фаркрай а крузис, я говорю про крайэнжин, и нет никакой разницы, какая конкретно игра.
Snusmumriken
Тем более что крайэнжин уже пятнадцать лет принадлежит юбисофту, и хз сколько раз его переделывали и как обозвали на этот раз, вероятность что фк6 на нём или на каком-то из его модов, который можно обозвать КАК УГОДНО крайне высока.
Anonymous
Здраствуйте, а как использовать конструкторы классов в usertype sol?
Roy
Здраствуйте, а как использовать конструкторы классов в usertype sol?
Не уверен, что библиотека sol тут будет обсуждаться
Roy
Посмотри примеры в документации
Roy
или на гитхабе, где юзается sol
Roy
Подскажите, вот мы решили отрефакторить с нашим коллегой луа скрипты в игре. Проблема такая, что там очень засран глобальный спейс функциями и переменными. Я предложил использовать модули, как посоветовал человек в этом чате выше. Решили мы значит выбрать такой подход, если что-то надо использовать снаружи (в других скриптах), то мы создаем объект локальный в lua и возвращаем его через return object, а в другом скрипте решили в спейсе просто создавать local myObject = requires(....) 1) Хотелось бы узнать, такой подход хороший или нет? 2) Дело в том, что сейчас коллега все что юзает в скрипте луа (в том где этот объект модуля создается), он помещает короче все данные в этот объект. Вопрос такой: стоит ли пихать все данные в этот объект если они снаружи не требуются? Я просто подумал, что логичнее в возвращаемом объекте хранить только те функции и данные, которые могут использоваться снаружи в других скриптах
Roy
Вот он написал такой объект в скрипте, он local, но в конце функции есть return, но вот тут он вписал еще glow, rates типы тоже, хотя они нужны только текущему скрипту. Что делать, оставлять их в объекте или лучше писать ниже local и объявлять их так, так как они не нужны снаружи в других скриптах?
Snusmumriken
Имхо многовато массивов, или они где-то используются именно как массивы? Задолбаетесь запоминать. *localization.lua* local en = { low_hp = "Eat something!", ... use_cloak_on_seiling = "Cannot use while sailing!", use_cloak_on_locked_inventory = "Please unlock inventory!", use_cloak_on_wrong_item = "Cannot use %s on %s!" } local ru = { low_hp = "Ты почти умер, жуй!", ... use_cloak_on_seiling = "Невозможно использовать во время плавания!", use_cloak_on_locked_inventory = "Разблокируйте инвентарь!", use_cloak_on_wrong_item = "Невозможно использовать %s на предмет %s!" } local langs = {ru = ru, en = en} langs.current = langs.en return langs *cloak.lua* local cloakSystem = { capeID = 7596, dustyID = 7597, ... } local lang = require'localization' cloakSystem.event = {} cloakSystem.event.sailing = function(self) Say(lang.current.use_cloak_on_seiling) end cloakSystem.event.use = function(self, other) Say(lang.current.use_cloak_on_seiling:format(self.name, other.name)) end
Snusmumriken
Можно, но это не принципиально, и немного усложняется доступ.
Roy
Я вообще не понял честно говоря
Roy
Мне было бы проще понять если бы просто ответили на вопросы
Snusmumriken
Решили мы значит выбрать такой подход, если что-то надо использовать снаружи (в других скриптах), то мы создаем объект локальный в lua и возвращаем его через return object, а в другом скрипте решили в спейсе просто создавать local myObject = requires(....) Да, так и происходит. В модулях у тебя грубо говоря конструкторы объектов, в нужных местах ты их реквайришь и делаешь конкретные объекты. *vec.lua* local Vec = newClass(...) function Vec:new(x, y) self.x, self.y = x, y end return vec *otherclass.lua* local vec = require"vec" local OtherClass = newClass(...) function OtherClass:new(x, y) self.coord = vec:new(x, y) self.dimensions = vec:new(20, 20) end return OtherClass
Roy
Не, так прикол в том, что я хочу создать именно объект в cloaksystem.lua и вернуть его
Roy
А не вернуть для того чтобы создать
Snusmumriken
А зачем? Он уникален?
Roy
Да
Snusmumriken
Ну тогда возвращай объект, сойдёт за синглтон. Луа кеширует результат require, поэтому синглтон будет везде одним и тем же буквально.
Roy
Я же говорю, у нас щас один скрипт может срать N функциями в глобал спейс
Roy
Поэтому я предложил подход - все функции строго локал, но если надо что-то тащить наружу, то только через ObjectSystem и require
Snusmumriken
local a = require"cloak" a.foo = 10 local b = require"cloak" print(b.foo) --> 10 потому что мы выставили выше Ну типа синглтон.
Snusmumriken
Сойдёт. Под пивас ))
Roy
А вот что касается 2 вопроса?
Roy
Там вопрос касается того, нужно ли запихивать в эти объекты все данные или же пихать только те, что собираемся наружу вытащить через require
Roy
или вообще без разницы
Snusmumriken
Подскажите, вот мы решили отрефакторить с нашим коллегой луа скрипты в игре. Проблема такая, что там очень засран глобальный спейс функциями и переменными. Я предложил использовать модули, как посоветовал человек в этом чате выше. Решили мы значит выбрать такой подход, если что-то надо использовать снаружи (в других скриптах), то мы создаем объект локальный в lua и возвращаем его через return object, а в другом скрипте решили в спейсе просто создавать local myObject = requires(....) 1) Хотелось бы узнать, такой подход хороший или нет? 2) Дело в том, что сейчас коллега все что юзает в скрипте луа (в том где этот объект модуля создается), он помещает короче все данные в этот объект. Вопрос такой: стоит ли пихать все данные в этот объект если они снаружи не требуются? Я просто подумал, что логичнее в возвращаемом объекте хранить только те функции и данные, которые могут использоваться снаружи в других скриптах
2) Дело в том, что сейчас коллега все что юзает в скрипте луа (в том где этот объект модуля создается), он помещает короче все данные в этот объект. Сойдёт 2.0. Если вы планируете мастурбировать на "приватные поля которые никто не может даже увидеть вне модуля" — надо выделять в локальную часть, если вам пофигу на это — нормась.
Roy
Наш луашник короче написал примерно такой код // ObjectSystem.lua local msgFunction local Object = { Msg = msgFunction } msgFunction = function() print("Hello") end return Object // TestSystem.lua local ObjectSystem = requires('ObjectSystem') local foo() ObjectSystem:Msg() end
Roy
Прикол в том, что у него msg() не вызывается из ObjectSystem в TestSystem.lua
Roy
хотя сам foo вызывается из С++ кода
Roy
С чем это может быть связано?
Roy
Он говорит Msg является nil'ом почему то, а вот сам ObjectSystem нет
Roy
Я сначала подумал, что может нельзя вызывать функцию через : но вроде как тоже самое что через точку
Roy
Короче, не знаю с чем связано, но Msg не находит
Roy
типа потом определить msgFunction
Roy
а как мне сделать чтоб оно не присваивала, а ссылалась
Roy
на функцию
Snusmumriken
local Object = { Msg = function(...) msgFunction(...) end }
Snusmumriken
Таким образом оно будет в функции искать по данному имени функцию, а не присвоит сразу пустое значение.
Snusmumriken
Но можно тупее. local Object = {} function Object.Msg() print("Hello") end
Roy
Смотрится неплохо
Snusmumriken
Потому что прямо и тупо, без выкрутасов.
Roy
local Object = { Msg = function(...) msgFunction(...) end }
Я так понял, в этом варианте мне вообще не надо париться с созданием local function
Roy
А достаточно просто ниже завести функцию
Roy
local Object = { Msg = function(...) msgFunction(...) end } function msgFunction(...) end
Snusmumriken
Ну да )
Snusmumriken
Стоп
Snusmumriken
local Object = { Msg = function(...) msgFunction(...) end } function msgFunction(...) end
В этом случае, ты сделаешь глобальную функцию, которая закакает неймспейс. А если заведёшь local function msgFunction(...) end ниже — оно её не найдёт ))
Roy
аа да, я опечатался, хотел локальную
Roy
Ну херова че, по сути у нас тогда 1 вариант тока ))
Roy
Вариант без выкрутасов
Roy
Этот
Функция же будет локальной насколько я знаю, если сам объект локальный
Snusmumriken
Она принадлежит локальному объекту. Запихнута в локальный объект.
Roy
А так можно? local object = {} function object.Boo() object.Foo() end function object.Foo() end
Roy
Ну типа, мы вызываем Foo, которая зарегана ниже чем Boo
Roy
или же для объектов тоже самое правило
Snusmumriken
Можно.
Snusmumriken
При вызове функции Boo он будет искать вызываемую функцию в object, что позволит тебе найти Foo объявленную ниже.
Roy
Еще один вопрос про область видимости, объектные функции могут вызывать локальные функции расположенные ниже по определению?
Roy
local object = {} function object.Boo() object.Foo() end function object.Foo() Wtf() end local function Wtf() end
Roy
Если предыдущие 2 вопроса включали: видит ли локальная функция другую функцию в зависимости от порядка, а так же объектная функция объектную функцию, то сейчас вопрос стоит про объектную функцию и про локальную
Snusmumriken
local object = {} function object.Boo() object.Foo() end function object.Foo() Wtf() end local function Wtf() end
Поставь интерпретатор отдельно и проверяй. Прошу заметить, Foo найдено, оно застопорилось на Wtf.
Snusmumriken
Тут куча материала на проверку. Спрашивать каждый отдельный кейс — задолбаешься и задолбаешь, проще запустить в интерпретаторе.
mva
Если предыдущие 2 вопроса включали: видит ли локальная функция другую функцию в зависимости от порядка, а так же объектная функция объектную функцию, то сейчас вопрос стоит про объектную функцию и про локальную
1) нет никаких объектных функций 2) в случае вызова функции из другой - она должна существовать на момент вызова. На момент объявления окружающей функции - не обязательно. И всё это напрямую следует: а) из упомянутого выше тезиса про интерпретируемость (в частности, декларативность), б) из понимания как вообще работают интерпретаторы