GTA-Multiplayer.com

Вот это утро вы мне устроили.... C# стал скриптовым языком, а скриптовый и компилируемый язык - это у вас антонимы. А. Фи. Геть.

Не появится И дело даже не в дефиците разработчиков МТА. Моя мысль была не о контроле версий а о восприятии.

Одним словом - некритично (по крайней мере, для меня) Думаю играет роль количество разработчиков.

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

В МТА значения можно вывести разными путями: в консоль, в чат и т.д. На вики функции сгруппированы по общему смыслу, группа функций "Output" содержит то, что вам нужно. Ну и доки по Lua пригодятся: http://www.lua.ru/doc/

Многими учеными, философами и языковедами, выдвинуто множество концепций связи между языком и мышлением, но всеми ими не оспаривается непосредственная связь между ними. Языки программирования, как и любые другие языки (как например дорожные знаки - тоже язык, пусть и простой), подчиняются этому принципу. Они серьезно связаны с мышлением (mention) человека. В случае с вербальными языками, человек, знающий не один язык, а, например, русский и английский, имеет, как билингв, объективное преимущество перед людьми владеющими единственным языком. Не только мной было замечена твоя "сишность". Без претензий к этому семейству языков, но рассматривать весь многообразный мир программирования с позиции только одного си и его детей, да еще и бравировать этим, по моему мнению, профессинальная стратегическая ошибка. Нужно стать билингвом, мультилингвом, — мир программирования заиграет новыми красками. Go beyond, bro.

Склоняюсь к мысли, что для этого у нас в API MTA пока маловато инструментов, с сожалению.

Интересная задача. Уменьшать альфу в циклах предполагаю уже были попытки?

Важный хоть и маленький нюанс, как в личке выяснилось. При инициализации экземпляра класса с передаваемой таблицей в виде аргумента нужно инициализировать эту таблицу каждый раз. То есть, так можно: local car1 = cars:new() local car2 = cars:new({model = 577}) local car3 = cars:new({model = 588, color="white"}) Так нельзя: local car1 = cars:new() local tableWithFields = {model = 588, color="white"} local car2 = cars:new(tableWithFields) local car3 = cars:new(tableWithFields) Очевидно, что в этом случае car2 и car3 будет одним и тем же "объектом"-таблицей. Просто поля car2 будут перезаписаны полями car3. Например, поле-ссылка на мташный объект vehicle и в car2 и в car3 будут указывать только на машину #3, а машина #2 потеряется.

Смотри. Прежде всего в функции cars:paintjob должны быть (). Далее. У тебя есть таблица cars. Это и есть класс для твоего автомобиля. Логичнее ее бы называть в единственном числе: car, но дело твое. Этот класс (таблица) и будет содержать общие функции для всех экземпляров твоего класса "cars". Собственно ты это и делаешь когда объявляешь: cars = {} function cars:new (o) -- Some stuff end function cars:paintjob() -- Все таки должны быть здесь скобки "()" -- Some stuff end Класс, кроме общих функций должен иметь и общие и дефолтные свойства, как я вижу из твоего кода: model = 566, x = 1421.6, y = -1345.9, z = 13.6 , rx = 0, ry = 0, rz = 0, carText = "Text". В таком случае добавляем к нашему классу "cars" метатаблицу: cars = {} setmetatable(cars, {__index = {model = 566, x = 1421.6, y = -1345.9, z = 13.6 , rx = 0, ry = 0, rz = 0, carText = "Text"}}) function cars:new (o) -- Some stuff end function cars:paintjob() -- Some stuff end Таким образом мы выставили свойства model, x, y, ... классу. Все экземпляры класса будут по умолчанию иметь эти свойства. То есть все поля таблицы сейчас выглядят так: model = 566, x = 1421.6, y = -1345.9, z = 13.6, rx = 0, ry = 0, rz = 0, carText = "Text", -- Это свойства класса new = function () -- Some stuff end, paintjob = function () -- Some stuff end -- А это методы класса Далее тебе нужно "инициализировать" класс, т.е. "создать объект". Все в кавычках, потому что перед нами Lua, а не ООП-язык. "Конструктором" нам служит new(). В нем будет рождаться экземпляр класса. Что такое экземпляр класса (или объект) в Lua? Это новая таблица, которая имеет своей метаблицей таблицу класса, т.е. твою таблицу "cars". Мы в "конструкторе" new() создаем новую пустую таблицу и присваиваем ей класс-таблицу cars как метатаблицу, вот так: cars = {} setmetatable(cars, {__index = {model = 566, x = 1421.6, y = -1345.9, z = 13.6 , rx = 0, ry = 0, rz = 0, carText = "Text"}}) function cars:new (o) local carObject = {} -- это и есть наш экземпляр класса cars, пока пустой setmetatable(carObject, {__index = self}) -- а теперь он имеет все свойства и методы (включая paintjob()) класса cars. Это ключевая вещь, все волшебство именно здесь. -- Здесь добавить создание игрового объекта Vehicle: createVehicle и так далее return carObject end function cars:paintjob() -- Some stuff end Важный момент, для того чтобы потом обращаться к экзмепляру класса (объекту) мы должны его возвращать. Можно возвращать сам объект-таблицу "carObject", а "carObject"-ы хранить в отдельной таблице под индексами. В своем проекте я поступаю иначе и, как мне кажется, изящнее - я сам класс делаю хранилищем созданных экземпляров класса. Но это уже другая история. У нас еще остался маленький нюанс - аргумент o, передаваемый в конструктор и который может содержать индивидуальные свойства для каждого экзмепляра класса. Скажем model может быть не 566, а 577, другая позиция или другой carText. Или вовсем добавлено новое свойство, например, color. В этом случае мы поступаем так: 1. Рождаем экземпляр класса как и раньше. 2. Проверяем, если o не пустое значение, то к нам приехала индивидуальная таблица. 3. Делаем этой таблице o метатаблицу наш инициализированный экземпляр класса carObject. То есть по сути мы делаем эту таблицу экзмепляром класса, а ее родителем - carObject. 4. Присваиваем carObject = o, чтобы остаток кода в методе (пока это только "return carObject") сработал как надо. cars = {} setmetatable(cars, {__index = {model = 566, x = 1421.6, y = -1345.9, z = 13.6 , rx = 0, ry = 0, rz = 0, carText = "Text"}}) function cars:new (o) local carObject = {} -- это и есть наш экземпляр класса cars, пока пустой setmetatable(carObject, {__index = self}) -- а теперь он имеет все свойства и методы (включая paintjob()) класса cars. Это ключевая вещь, все волшебство именно здесь. if (o) then setmetatable(o, {__index = carObject}) carObject = o end -- Здесь добавить создание игрового объекта Vehicle: createVehicle и так далее -- Затем полученный мта-объект засовываем в carObject, например carObject.element = vehicleElement return carObject end function cars:paintjob() -- Здесь берем self.element и красим его, например, setVehiclePaintjob(self.element, 2) end Все теперь мы можем делать как тебе нужно: cars = {} setmetatable(cars, {__index = {model = 566, x = 1421.6, y = -1345.9, z = 13.6 , rx = 0, ry = 0, rz = 0, carText = "Text"}}) function cars:new (o) local carObject = {} -- это и есть наш экземпляр класса cars, пока пустой setmetatable(carObject, {__index = self}) -- а теперь он имеет все свойства и методы (включая paintjob()) класса cars. Это ключевая вещь, все волшебство именно здесь. if (o) then setmetatable(o, {__index = carObject}) carObject = o end -- Здесь добавить создание игрового объекта Vehicle: createVehicle и так далее -- Затем полученный мта-объект засовываем в carObject, например carObject.element = vehicleElement return carObject end function cars:paintjob() -- Здесь берем self.element и красим его, например, setVehiclePaintjob(self.element, 2) end local car1 = cars:new() trace(cars1.model) -- 566 trace(cars1.color) -- nil local car2 = cars:new({model = 577}) trace(cars2.model) -- 577 trace(cars2.color) -- nil local car3 = cars:new({model = 588, color="white"}) trace(cars3.model) -- 588 trace(cars3.color) -- white cars2:paintjob() -- красим cars2 Вроде весь твой вопрос расписал. Вот так собственно выглядит принцип наследственности в Lua. Использовать необязательно, но просто необходимо знать и понимать всем кто называет себя знающим Lua. Я специально перегрузил текст терминами "экземпляры класса", "классы" и др., потому что считаю что их использовать надо, это полезно. Lua - крутой язык, мне нравится

Реализация классов (вернее ее имитация) легко делается средствами Lua. Без библиотек. Таблицами или с использованием метатаблиц. Можно использовать библиотеки, которые отдельно занимаются этой задачей - окей, ну если уж действительно так хочется. Но включать костыль с сомнительной необходимостью в МТА?... Впрочем, предложить разработчикам можно, другое дело какие шансы возьмут ли в работу. Кстати, кто-нибудь это им предлагал на bugs.mtasa.com? Я не нашел такого тикета.

В том что это возможно только с использованием сторонних библиотек, которые нужно включать в каждый ресурс, а это костыль. Речь о реализации классов как таковых внутри самой МТА, без необходимости делать это своими силами. Это НЕ так! В сущности что такое класс в Lua? Это таблица, в полях которой может содержаться то, что в ООП-языке содержит настоящий класс - конструктор, деструктор, какое-то поведение и пр. Ну что мешает создавать эти таблицы? Причем в сети действительно достаточно материала об этом! Хотя бы вот на хабре: http://habrahabr.ru/post/228001/

По поводу кастомных классов. Я не совсем понимаю, в чем именно сложность создавать свои классы с конструктором, деконструктором и т.п. С обращением к элементу по типу как в реализовано в МТА. Есть же куча статей на всех языках по теме "реализация классов в Lua"

Это вопрос был следующим. То есть с первым все решено, все ок?

Ну отлично Вот только воевать не надо начинать, в лучших традициях русскоязычных форумов, да? Еще раз. Тобой было написано, что то, что есть в МТА - это сложно назвать ООП. И должно быть как минимум наследование, полиморфизм. Это действительно странное заявление, учитывая, что вся система эелементов в МТА построена с точки зрения наследственности. Element --> Ped --> Player. Пример полиморфизма: player:setParent(object). То есть этот (один) метод выполняет разный код в зависимости от типа элемента. Ну ок. Если этого недостаточно, чтобы поверить, что наследственность и полиморфизм есть, я привел наглядный пример, как эти принципы можно использовать в собственном проекте. И после того, как я спросил "К вопросу о существовании/несуществовании наследственности и полиморфизма, то его можно закрывать?" мне говорят, что я зря стараюсь, пытаясь что-то доказать и что я вообще ушел от какой-то темы. Мне очень хочется верить, что причина спора просто в формулировках, а не в некомпетентности.