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). То есть этот (один) метод выполняет разный код в зависимости от типа элемента. Ну ок. Если этого недостаточно, чтобы поверить, что наследственность и полиморфизм есть, я привел наглядный пример, как эти принципы можно использовать в собственном проекте. И после того, как я спросил "К вопросу о существовании/несуществовании наследственности и полиморфизма, то его можно закрывать?" мне говорят, что я зря стараюсь, пытаясь что-то доказать и что я вообще ушел от какой-то темы. Мне очень хочется верить, что причина спора просто в формулировках, а не в некомпетентности.

Ребят, сорри, я вас уважаю и все такое, но у меня нет времени открывать кружок по изучению Lua. Я привел теоретический пример из моего работающего проекта. Я не готов расписывать все с примерами из кода, а самое главное, я считаю это излишним. Ибо для того чтобы понять, что наследственность и полиморфизм вполне могут использоваться, достаточно изложенного. Если этого недостаточно, то, думаю, нужно подтянуть теорию объектно-ориентированного программирования, это достаточно легко. По поводу библиотек. Я не использую библиотеки, для меня они слишком универсальны. И подозреваю, что их значение у тебя переоценено. Если ты думаешь, что какие-то библиотеки создают классы каким-то своим магическим образом, недоступным для тебя, ты ошибаешься. Они точно также имитируют создание классов, которых в Lua на самом деле нет. Все остальное я не совсем понял. Все созданные объекты являются "userdata" - всмысле в МТА, тогда да. А если ты имеешь в виду экземпляры класса в коде - то не факт. У меня объекты класса - это тоже таблицы, одна из ячеек которой содержит "userdata" объекта из МТА. Но если вернуться к предыдущему вопросу о существовании/несуществовании наследственности и полиморфизма, то его можно закрывать? И то, и другое существует и реально помогает людям.

Я не знаю что такое уровень MTA в этом деле. У меня используется ООП, имитируемый языком Lua. Мой пример не из МТА, тем более Lil Toady уже привел примеры из него. Приведу теоретический пример из собственного проекта: реализация логики транспортных средств (vehicles). Для наглядности картинка с фрагментом структуры моего проекта: Наследственность Как вы наверняка догадались, все производные классы с более сложными названиями наследуются из корневого класса из файла vehicle.lua Класс из vehicle.lua содержит основные методы и обработчики событий (будем называть их просто одним словом "функции"). Например, при респавне (onVehicleRespawn) я должен у всех видов vehicle производить одинаковые действия: выключить фары (setVehicleOverrideLights), выключить двигатель (setVehicleEngineState) и прочее. Следуя принципу наследования я реализовал это в родительском классе из vehicle.lua и это выполняется для всех. Далее, как можно видеть из названий файлов, содержащих классы "детей", есть некоторые специальные виды транспорта с чисто своими функциями. Например, при попытке повреждения "policevehicle" (как и "fbivehicle" или "nationalguardvehicle") игроку (если он не полицейский, не из ФБР и тд...) выдаются звезды розыска. Или, например, "ownvehicle" имеет собственный метод lock --> закрыть транспортное средство. Полиморфизм Кроме функций общего характера, класс из vehicle.lua содержит пустые функции, которые переопределяются в некоторых (или некотором) из его "детей". Например, метод save --> сохранить данные автомобиля. Этот метод вызывается при каждом изменении данных автомобилей (например, изменения цвета в покрасках). Но он пуст в vehicle.lua, то есть для всех видов автомобилей и переопределен только в классе из ownvehicle.lua. Потому что только собственные автомобили (у меня – купленные в автосалоне) должны сохраняться. И вместо того, чтобы устраивать проверки какой перед нами автомобиль, мы не глядя вызываем метод save, а код сам разберется сохранять или нет. Ну и задача доступа к тому или иному виду транспорта легко и непринужденно решается с помощью полиморфизма. Это далеко не единственные примеры применения этих двух принципов, но я выбрал самые наглядные. Это вполне себе годная имитация ООП, которая реально облегчает жизнь. Другое дело, что если пытаться использовать ООП, не зная зачем и что это даст, в этом случае, я думаю, жизнь скорее осложнится. Таким образом, наследственность и полиморфизм есть и их можно использовать.

Эммм, никого не хочу задеть, но это довольно странный ответ. На предыдущий пост, в котором было сказано, что мол не хватает полиморфизма и наследственности, было отвечено, что это не так. И Lil Toady прав, они есть. И используются очень многими, мной тоже. Если нужны примеры использования, могу привести отдельно. Lua всего лишь имитирует ООП, возможно по другими принципам ООП и есть вопросы, но как раз упомянутые наследственность и полиморфизм работают. И их можно и нужно использовать. Эта возможность у нас есть

Awesome!

Действительно, сделай самостоятельно исследование этого вопроса. И о результатах напиши. Это же намного интересней

Думаю, анализ кода МТА будет интересен русскоязычным разработчикам МТА: http://habrahabr.ru/company/pvs-studio/ ... gn=twitter

Можно еще починить рекламный щит Sprunk разрушенный Сиджеем Id обломка: 3083 Координаты: posX="2533.82007" posY="-1290.55286" posZ="36.9414" rotX="0" rotY="0" rotZ="0"

Топик-стартер все верно изложил. Но насчет этих глупых букв рпг рп и тд у меня есть немного другое мнение. МТА намного богаче по возможностям и по уровню стоит выше этих самповских условных обозначений. Она над этим. В МТА могут быть вложены друг в друга несколько видов режимов. Все ограничено только фантазией. Но мое мнение, что можно еше больше раскрутить МТА только одним способом: делать. И точка.