Lua-программирование для чайников

Содержание:
dofile() — открывает файл по указанному пути и выполняет его содержимое как Lua задачу.
В скобках в кавычках должен быть написан путь до файла, его имя и, конечно же, расширение, потому что расширение файла может быть не *.lua, а любым другим, но при этом внутри него будут коды на Lua.
Путь должен должен быть записан в кавычках.
Пример:
dofile("data/scripts/Main.lua");
dofile("data/configs/config.cfg");
tonumber() — преобразует переменную в число. Не очень понимаю, как это работает. Если параметр уже является числом или строкой, конвертируемой в число, то tonumber() возвращает это число, иначе возвращает nil. ссылка ниже
Основание может быть любым целым числом в диапазоне от 2 до 36 включительно.
Если основание больше 10, то символ «A» (как в верхнем, так и в нижнем регистре) представляет 10, «B» представляет 11 и так далее, символ «Z» представляет 35. При основании 10 (по умолчанию),
число может быть представлено в экспоненциальной форме.
Для других оснований можно указывать только беззнаковые целые числа.
Tonumber
tonumber - преобразование параметра в число. Если параметр уже является числом или строкой, конвертируемой в число, то возвращает это число; иначе, возвращает nil.
tonumber (<var> [, base])
Где:
var - параметр для преобразования.
base - необязательный параметр. Указывает основание системы счисления для интерпретации числа. Основание может быть любым целым числом в диапазоне от 2 до 36, включительно. Если основание больше 10, то символ 'A' (как в верхнем, так и в нижнем регистре) представляет 10, 'B' представляет 11, и так далее, символ 'Z' представляет 35.
Примеры
--lua
local a = "12"   -- переменная 'a' (строка)
print(type(a))    -- вывести в лог тип переменной 'a'
a = tonumber(a)  -- преобразовать переменную 'a' в число
print(type(a))    -- вывести в лог тип переменной 'a'
--lua
local color1 = "66FFCC"         -- цвет из шестнадцатеричной системы счисления
color1 = tonumber(color1, 16)   -- преобразовать в десятичное число
print(color1)
print(tonumber("0x7DE")) --перевод hex-строки в число
print(tonumber("7DE",16)) --альтернативный перевод hex-строки в число
_VERSION — глобальная переменная (не функция), возвращающая строку с версией интерпретатора.
Пример:
-- при вызове этой переменной на самой последней официальной версии Lua эта перменная возвращает следующее:
print(_VERSION); -- Lua 5.3.1
В языке lua для контроля нестандартных ситуаций имеется базовая функция assert(). Очень полезная функция, однако имеет и одно неприятное свойство.
assert()
Функция assert() выдает сообщение об ошибке, если значение её первого параметра равно false (то есть nil или false).
Обычное использование - контроль ситуаций, возникновение которых свидетельствует об ошибке в программе.
Как использовать? Например, для проверки правильности переданных в функцию параметров.
Напишем простейшую функцию, которая делит одно число на другое. Работать она может неправильно в случае если второй параметр равен 0. Интерпретатор Lua поделит на 0 без затруднений и получит бесконечность, однако нас вряд ли устроит такой ход событий. Такие ситуации обычно нужно отслеживать сразу же, не позволяя ошибкам накапливаться и всплывать уже где-то в другом месте. Вставляем assert()
function divide(x,y)
   assert(y ~= 0, "Деление на ноль")
   return x/y
end
Всё чудесно, стоит передать вторым параметром 0 - и мы получим диагностику в процессе исполнения этого кода.
Однако ничто не даётся даром. Такой подход имеет 2 серьёзных недостатка.
assert() выполняется всегда, даже в отлаженной программе.
замедляет быстродействие (довольно значительно)
Можно смириться с этим. Также можно в отлаженной программе руками каждый раз убирать все лишние вызовы assert(). Третий способ - использовать препроцессор. Пишем простейший макрос:
define(m4_assert',ifdef(DEBUG',assert(`$1',"Assert failed: file line line")')')
Теперь наша функция будет выглядеть так:
function divide(x,y)
   m4_assert(y ~= 0)
   return x/y
end
Теперь мы легко управляем наличием или отсутствием проверок. При отладке программы проверки должны быть, в конечном варианте они не требуются. Если собрать готовую программу с объявленным флагом DEBUG (то есть вставим в начало программы строчку define(`DEBUG') ), то на выходе получим код на Lua:
function divide(x,y)
    assert(y ~= 0, "Assert failed: d:/test.lua line 2)
    return x/y
end
Если флаг DEBUG для окончательной сборки не задавать, то вызова функции assert() в результирующем коде не будет.
function divide(x,y)
     return x/y
end
Эти конструкции я использую во всех своих библиотечных функциях. В основном благодаря такому подходу отпадает необходимость пользоваться отладчиками для поиска ошибок в отлаживаемых программах на Lua и в конечную версию программы не попадает уже ненужный код проверок.

`
ОЖИДАНИЕ РЕКЛАМЫ...
0
6
2 года назад
Отредактирован Lasto4ka
0
dofile объясняется, только его в WC3 нет. Как и require, если не программировать под какую-нибудь систему сборки карт. Как минимум напомнить об этом надо.
0
27
2 года назад
Отредактирован MpW
0
dofile объясняется, только его в WC3 нет. Как и require, если не программировать под какую-нибудь систему сборки карт. Как минимум напомнить об этом надо.
Обязательно. Но это нужно лично проверять. Мне вот интересна как подключать require в варкрафте. Мб можно как то из скриптов подключать?
0
6
2 года назад
0
require делается через эту систему сборки github.com/ceres-wc3/ceres наример. Есть ещё какая-то китайская на гитхабе. В самой игре - лучшее, что можно сделать, это через прелоад файлы. И то, им нельзя быть чистыми Луа скриптами, а иметь специально написанные комментарии, чтобы Lua-код преобразование через jass2lua пережил.
Короче говоря, нету require в WC3, работы с файлами у карт тоже нет. То что есть - новичкам не по зубам.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.