MX_Master

getGroundPosition (клиент) + setElementPosition

Уже можно открывать/создавать собственные SQLite БД, а также конектится и рулить MySQL БД новыми функциями (с версии 1.1.1 r3328) - https://wiki.multitheftauto.com/wiki/Ser ... _functions . Надеюсь, это поможет в разработке, потому что модули уже не надо юзать. зы: возможно, мы уже далеко ушли от темы

А найти такой скрипт не удалось?

Могу только добавить, что при кодинге в МТА реально разбегаются глаза на всякого рода возможности, и даже иногда в непонятках находишься сделать ли то или другое. Выбор реально большой, а это пугает многих начинающих скриптеров. Как ни банально, но я бы мог освоить и какой-нить "С" язык, для тех кто в танке - это несложные языки, а вот меня как новичка пугает объем возможностей. Поэтому если кто-то почувствует, что в МТА очень сложно что-то спроектировать, просто сосредоточитесь на чем-то одном (желательно попроще), как сделаете - переходите к другому (немного посложнее). Так быстрее освоится и тогда уже не будет мыслей про "напрасные труды". Скорее сам скриптер забросит скриптинг, чем МТА перестанет существовать (:

а оно работает хоть? в коде много чего, но работает не всё (:

Суховато, но на НАШЕМ языке - http://www.lua.ru/doc/5.5.html

На мой взгляд, в ТОМ мультиплеере сервер перегружается, потому что все подсчеты выполняются только сервером. У МТА-же есть огромный ресурсный потенциал клиентской части, а все плюшки в большинстве случаев нужно делать именно в клиенте. Эту тенденцию можно заметить в современном веб программировании - флэш интерфейсы, контент, генерируемый с помощью яваскрита и аякса в клиенте. Сервер должен играть связующую роль. Также должно быть и в МТА, причем все решаемо на скриптовом уровне, в САМПе такое вряд ли возможно на данный момент. Этим я хотел подчеркнуть действительно реальную гибкость МТА в вопросе проектирования сложных систем. И самое главное - сначала попробуйте как следует оптимизировать задуманное на скриптовом уровне (Lua) и только если не удасться - переходите на более низкий уровень. Я сам долгое время создавал одну очень сложную клиентскую библиотеку с множеством подсчетов в каждом кадре прорисовки. Логика была действительно сложной, но на итоговую производительность это сказывалось всего лишь в падении FPS на 2, максимум 3. Все дело в оптимизации. И я думаю, что у меня все равно были неучтенные моменты в оптимизации. Как напишите, так и будет работать.

just REBUILD (not compile) "Client - Deathmatch"

There's one server browser here - https://github.com/mabako/mta-browser, written in C++

Молодец, Sector, всё доступным языком описано.

Отсюда код? : http://www.google.com/codesearch#KdIewV ... .com&l=710 http://www.google.com/codesearch#KdIewV ... .com&l=510 эти функции закоментированы, но некоторые из них добавлены ниже или выше, некоторые - не добавлены, ввиду их ненужности или какой-то несовместимости. Это же серверные, допустим, аудио функции все есть в клиенте, поэтому сервер полностью не управляет аудио функциями, а мелодии из миссий можно вытащить из игры и проигрывать в клиенте.

Тогда без проблем

он развивает наш форум (: ты все названия функций прочитай, что непонятно - просмотри описание. И ВСЁ. Больше не будет таких вопросов, как "как заспавнить игрока?" и "как поменять скин?"

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

добавить новое событие, например, onPlayerHealthUp и добавить к нему обработчики или вручную запускать onPlayerDamage с нужными параметрами (не желательно, конечно, так делать)

Все глобальные предопределенные переменные на данный момент сервер _G -- таблица, содержит все глобальные переменные _VERSION -- версия LUA на сервере coroutine -- таблица, содержит функции для псевдо-потоков debug -- таблица, содержит дебаг функции exports -- таблица, содержит все экспорт функции сервера math -- таблица, содержит математические функции resource -- элемент, текущий ресурс resourceRoot -- элемент, корневой элемент текущего ресурса root -- элемент, корневой элемент сервера string -- таблица, содержит строковые функции table -- таблица, содержит функции для таблиц клиент guiRoot -- элемент, корневой элемент всех GUI элементов localPlayer -- элемент, локальный игрок _G -- таблица, содержит все глобальные переменные _VERSION -- версия LUA в клиенте coroutine -- таблица, содержит функции для псевдо-потоков debug -- таблица, содержит дебаг функции exports -- таблица, содержит все экспорт функции клиента math -- таблица, содержит математические функции resource -- элемент, текущий ресурс resourceRoot -- элемент, корневой элемент текущего ресурса root -- элемент, корневой элемент клиента string -- таблица, содержит строковые функции table -- таблица, содержит функции для таблиц

local myMarker = createMarker(84, 1946, 17, 'cylinder', 2.0, 255, 0, 0, 150) function MarkerHit( hitElement, matchingDimension) if getElementType(hitElement) == 'player' then givePlayerMoney(hitElement, 1000) outputChatBox( getPlayerName(hitElement).." inside myMarker", getRootElement(), 255, 255, 0 ) end end addEventHandler( "onMarkerHit", myMarker, MarkerHit )

Не сказал спасибо? Пасиба К слову о коде, стессна, если я захочу написать конвертер или "конструктор", я напишу его не словами, а в коде - на Lua и под МТА.

а если сделать редактор полностью обрабатывающий логику и функции и перенести это в gui-вседоступный вариант типа блоксхемы, т.е. просто последовательно ставить блоки друг за другом аля "пирамидко для детей" - аналог лего конструктора, то в мта и не только сампо-скриптЭры пойдут писать свои моды, или точнее - собирать. Потеряется главный смысл профессионального программирования - работы с кодом. Конечно, при помощи такого "lego" какой-нибудь DM простенький смастерить возможно будет, но не более. Никто не потянется. Разве что только вначале, что бы удивиться. Я конечно, извиняюсь, но я даже немного поржал над этим ответом все-таки основной раздел может быть с офтопом.. Сразу понравилась фраза "смысл профессионального программирования - работа с кодом" ! А тот факт, что "этот смысл сейчас потерялся" улыбнул мое лицо еще шире. А терь серьезно.. тема о самповых скриптах в МТА.. вполне актуально. Многие скриптеры, проработав над своими модами эННое кол-во месяцев ни за что не согласятся переписывать весь функционал на новом языке и под новый мультиплеер. Если учитывать, что эти скриптеры не знают почти ничего об МТА, то резонно предположить - конвертер скриптов сразу же покажет, как все знакомые им конструкции, должны выглядеть в МТА скриптах. Для нормального скриптера (умного) два одинаковых скрипта, написанных на разных языках - раскрывают больше инфы, чем прочтение многих доков и мануалов по языку. К тому же я уверен, если можно написать полноценный конвертер ИХ скриптов в МТАшные, то написать обратный конвертер будет почти невозможно, потому что в МТА функционала как минимум в 2-3 раза больше. Как я уже ранее говорил, в МТА можно полностью скриптово эмулировать весь их функционал, но не наоборот.

насчет ЛЕГО надо еще поразмышлять, а насчет конвертера - 100% будет иметь успех

Суппорт это у коммерческих продуктов, но НАШИМ-то все равно.

ДОБАВИТЬ НОВЫЙ ОБЪЕКТ БЕЗ ЗАМЕНЫ ЛЮБОГО ИЗ СТАРЫХ - НЕЛЬЗЯ поэтому можешь заменить какой-то из совсем ненужных объектов, например фишку из казино. Решение многих задач лежит почти что всегда на поверхности, поэтому голову сильно ломать не надо

Мне кажется, что простой конвертер "samp's pawn script > mtasa server script" решит многие проблемы, и AMX не понадобится. Если будет такой полный конвертер, то народ активно потянется ОТТУДА сюда.

есть такой ред Zanoza Modeler, он вроде может открывать 3ds'овские модельки, а также может экспортирвать модельку в DFF

если в DFF сконвертировать - да