eu_tomat

Продолжу заниматься осветлением тёмной магии. Мне в личку поступил вопрос о назначении конструкции (dura*1e6+0.5)//1/1e6. Подозреваю, что эта информация будет интересна более широкому кругу читателей, поэтому публикую свой ответ здесь. Встретив новую конструкцию в коде, порой сложно бывает даже сформулировать запрос для поисковика, чтобы выйти на какой-то вменяемый ответ. В этом случае я рекомендую следующие способы поиска информации: Что такое 1e6? Если рассуждать логически, то можно предположить, что это какая-то причудливая форма записи числа. Поиск по фразе «форма записи числа» быстро приводит к статьям, рассказывающим о форме записи, называемой формой записи числа с плавающей точкой. Синонимы: «экспоненциальная запись», «научная форма», «нормальная форма», «полулогарифмическая форма». Примеры: 1e6 = 1 * 10^6 = 1000000. 5e-3 = 5 *10^-3 = 0.005 Я использую экспоненциальную запись для краткости. От обилия ноликов у меня рябит в глазах, а в экспоненциальной форме я сразу вижу количество нулей, что снижает вероятность ошибки. Что такое //? Это операция целочисленного деления. Как об этом узнать? Во-первых, можно загуглить фразу «lua double slash operator». Можно и на русском языке поискать, но шанс найти подобное упоминание будет ниже. Во-вторых, имеет смысл читать спецификации языка, это основной источник знаний: Lua 5.3 Reference Manual 3.4.1 – Arithmetic Operators. Также есть справочник по языку Lua5.3 на русском: http://antirek.github.io/luabook/. Что вообще делает конструкция (dura*1e6+0.5)//1/1e6? Я использую операцию целочисленного деления для получения целочисленной части числа. По-моему, это самый быстрый способ. Иначе говоря, это округление числа до целого вниз. Но перед этим я добавляю к числу 0.5, для того, чтобы получить округление до ближайшего целого. Перед округлением до целого я умножаю исходное число на 1e6, а после округления делю результат на 1e6. Эта последовательность операций позволяет мне округлить число до 6 знака после запятой. Если кто-то знает более эффективный способ округления чисел, делитесь своими решениями. Я же использую эту конструкцию с тех пор, как перешёл на Lua5.3. Для вычисления прочности инструмента, скорее всего, достаточно было бы тупо округлять число до ближайшего целого, но в экспериментах я стараюсь округлять хотя бы до 6 знака, чтобы убедиться, что располагаю запасом точности, и меня не ждут сюрпризы с этой стороны. Когда мне требуется максимальная точность, я подбором ищу самый далёкий знак, чтобы округление искажало результаты минимальным образом, но было бы достаточным для получения устойчивых и воспроизводимых результатов. Такой подход иногда позволяет мне обнаруживать новые нюансы механик во время дальнейших экспериментов. Например, если сначала мне хватало округления до 9 знака, но на каком-то этапе вдруг потребовалось округление до 6. Такое изменение может означать встречу с каким-то новым эффектом. Или, например, может сигнализировать мне о том, что я использовал слишком громоздкие вычисления приводящие к сильному снижению точности. В рабочих программах по завершении экспериментов я обычно уменьшаю точность на несколько порядков, чтобы выполняющийся код не реагировал на непредвиденные флуктации погрешностей. Надеюсь, этот пост будет полезен более чем одному читателю форума.

@Asummonster я частенько вижу реакцию "в шоке" под своими постами, но мне ни разу не удалось понять, что она означает. Вот, скажи: выставляя реакцию "в шоке", какую мысль ты хочешь донести до автора поста и до его читателей? Что именно тебя шокирует? Ты с чем-то не согласен? Или согласен, но считаешь неприемлемым высказывать это? Или согласен, но не ожидал такого решения? Или наоборот, решение для тебя настолько очевидным, что тебя шокирует его обсуждение? Ты хочешь видеть подобные посты чаще, или наоборот, реже?

Я сейчас повторил эксперимент в игре и обнаружил, что значимых проблем с точностью нет. Можно округлять до 6 знака после запятой, и всё будет сходиться. Но откуда могла взяться ошибка в моём прошлом эксперименте? Подозреваю, что в тот раз я не глядя взял значения с википедии, а увидев расхождение, не довёл эксперимент до конца. Рассмотрю проблему на примере алмазной кирки. Согласно вики, её прочность равна 1562. Проверка прочности через контроллер инвентаря: component.inventory_controller.getStackInInternalSlot(1).maxDamage 1561.0 Проверка прочности при использовании: d0=robot.durability() repeat robot.place() robot.swing() d=robot.durability() until d~=d0 dura=1/(d0-d) print(dura,(dura*1e6+0.5)//1/1e6) 1560.9999999999 1561.0 Значение максимальной прочности кирки, полученное экспериментально, совпадает со значением, полученным с помощью контроллера инвентаря с погрешностью до 6 знака после запятой. На самом деле погрешность ещё меньше, просто я не увидел смысла в её точном определении. Вики, к слову, тоже не врёт, если вникнуть в механику использования инструмента. После рубки алмазной киркой 1561 блока остаток прочности кирки будет равен нулю. Но даже нулевая прочность позволит сломать ещё один блок, при этом кирка окончательно сломается.

Без паники! Тяжело точно измерить объём полной бочки напёрстками, даже заранее зная, что она содержит целое число напёрстков. Небольшая погрешность легко может накопиться в один-два лишних или недостающих напёрстка. Но когда ты измеряешь небольшой остаток воды в бочке, всё так же зная, что количество напёрстков должно быть целым, ошибиться почти невозможно. Погрешность вычислений снижается естественным образом, и округление до целого полностью решает эту проблему. А учитывая, что мы не доверяем шансам, то и частоту проверки остатка прочности мы также увеличиваем по мере падения прочности. Покажу это на примере всё той же железной кирки: robot.durability() показывает прочность примерно в 251 использование. В среднем кирка износится за 2510 использований. Поэтому даже если мы получили слегка завышенную прочность, мы вряд ли сломаем кирку до конца, применив её, например 252 раза. Если тебя интересует вероятность неудачного исхода в таком применении, я могу потормошить голову и посчитать. Это как-то связано с биномом Ньютона, но мне требуется вспомнить, как именно. Но идём дальше. Предположим, мы использовали кирку 252 раза. За это время она износится в среднем на 25 единиц. Мы снова проверяем остаток через robot.durability() и получаем остаток прочности, равный, например, 226. И теперь мы используем кирку 226 раз. В следующий раз мы используем кирку 204 раз, затем 184 раза, затем 166 и т.д. Чем ниже остаток прочности, тем чаще выполняется его проверка. При таком алгоритме сложно проскочить критический момент. Особенно учитывая, что по мере приближения к нему точность вычислений возрастает по причине естественного снижения погрешности.

Не совсем так. Робот также снижает прочность кирки на единицу, но с шансом 0.1, т.е., в среднем один раз из 10. Таким образом, робот железной киркой может добыть не 251 блок, а в среднем 2510 блоков. Но это в среднем. В каждом конкретном случае может быть больше, а может быть меньше в зависимости от выпадения шанса. Да. Причём, можно исхитриться и выполнять замер не отдельной процедурой, а прямо во время работы. И так, наверное, даже более правильно. И да, ты прав, это значение примерное. С точки зрения идеальной математики оно должно быть взаимно обратным значению максимальной прочности. Но погрешности вещественных типов приводят к расхождению, если максимальная прочность большая. Я уже не помню, насколько большим было это расхождение, но точно помню, что оно не не корректировалось округлением до ближайшего целого. Поэтому правильным способом будет непрерывное уточнение значения в процессе использования инструмента. Конечно же, если есть желание получить максимально точное значение максимальной прочности инструмента. Но на практике, я думаю, это не играет особой роли. Когда прочность инструмента высока, расхождение в единицу прочности не будет фатальным. А по мере износа инструмента точность определения остаточной прочности будет увеличиваться. Кстати, с синим буром в режиме 3x3 опять будет сложность: он теряет заряд пропорционально количеству срубленных блоков, которое не всегда одинаково и зависит от конфигурации встреченных полостей.

Если речь идёт о моих расчётах, то оптимально делать так: То есть, вызывать robot.durability() следует как можно реже, самостоятельно довычисляя рабочее значение остатка прочности. Это позволит получить выигрыш во времени около 2-3%. И ездить на зарядку тоже следует как можно реже, не дробя работу на крупные куски. Если, конечно, смотреть с точки зрения оптимизации. А что нам даст знание о целых процентах? Остаток прочности, выраженный в гарантированном количестве оставшихся использований, можно напрямую сравнивать с объёмом работы. А проценты какой смысл сравнивать? Это же относительная величина.

Как будет? Пусть скорость снижается, но упростится код? Ну, хорошо. Если упрощаем код, тогда и robot.durability() можно вызывать два раза подряд, это уже не играет особой роли. Но почему константа 100 захардкожена? Разве она не должна зависеть от используемого инструмента?

В этом случае резервирование прочности инструмента фискированным куском способствует не столько минимизации затрат времени, сколько упрощению кода. Но, например, в случае протяжённых челночных перемещений робота таки образом можно было бы экономить и время тоже. На сравнительно коротких дистанциях для работа более важна способность корректного возврата ровно к той позиции, где он прервал свою работу. Предложенная же эвристика не способствует экономии времени, потому что затраты на проверку прочности инструмента крайне малы в сравнении со временем, затрачиваемым роботом на перемещение к заряднику. Разберём несколько примеров. Для упрощения предположим, что роботу для рубки блоков не требуются перемещения, блоки каким-то образом сами появляются перед роботом. Но для зарядки инструмента роботу требуется переместиться на 10 шагов к заряднику и обратно. Пусть на рубку одного блока требуется 8 тиков. Столько же требуется для единичного перемещения. Также предположим, что инструмент заряжается мгновенно, и для его зарядки робот тратит время лишь на дорогу. 1) Остаток прочности инструмента: 1000/1000. Очевидно, что в этом случае нет смысла перемещаться к заряднику, а можно смело рубить 1000 блоков, сразу после проверки реальной прочности инструмента один раз перед началом работы. Накладные расходы: 1/(8*1000) = 0.000125. 2) Остаток прочности инструмента: 100/1000. Если робот сразу приступает к работе, то накладные расходы = 1/(8*100) = 0.00125 Если робот сначала идёт к заряднику, то накладные расходы = (1+20*8)/8*1000 = 0.020125 Видно, что к заряднику идти не выгодно, имеет смысл сначала израсходовать имеющуюся прочность инструмента. 3) Остаток прочности инструмента: 7/1000. Если робот сразу приступает к работе, то накладные расходы = 1/(8*7) = 0.018 Если робот сначала идёт к заряднику, то накладные расходы = (1+20*8)/8*1000 = 0.020125 Аналогично: сначала имеет смысл потратить прочность инструмента на добычу блоков. 4) Остаток прочности инструмента: 6/1000. Если робот сразу приступает к работе, то накладные расходы = 1/(8*6) = 0.0208 Если робот сначала идёт к заряднику, то накладные расходы = (1+20*8)/8*1000 = 0.020125 А уже в этом случае теряется смысл расходовать прочность инструмента до последнего, выгоднее сначала зарядиться. А теперь другой пример: расстояние до зарядника = 40, остаток прочности 2/1000. Если робот сначала идёт к заряднику, то накладные расходы = (1+80*8)/8*1000 = 0.080125 Если робот сразу приступает к работе, то накладные расходы = 1/(8*3) = 0.0625 В этом случае имеет смысл расходовать прочность инструмента практически до нуля. Вывод: Для экономии времени на вызовах robot.durability() нет смысла дробить работу на крупные блоки. Запас в 48 блоков приведёт не к увеличению, а снижению скорости копки. Дополнительный смысл такого решения может появиться при длинных челночных проходах роботом или же для упрощения кода, чтобы не прерывать копку в произвольных точках карьера.

Магия тут вполне себе светлая. @Doob находит скорость износа экспериментально, совершая несколько попыток применения инструмента, т.к. робот изнашивает инструмент не при каждом использовании, а с некоторой вероятностью, определённой в файле конфигурации OpenComputers. Метод медленный, но не требующий наличия контроллера инвентаря в роботе. Контроллер же инвентаря позволит выполнить эту операцию быстрее: W_R = 1/maxDamage. Запоздалое, но важное дополнение к абзацу выше: Метод, использующий контроллер инвентаря, успешно работает только с обычными инструментами. Значение maxDamage для перезаряжаемого инструмента имеет другой смысл. А здесь обратная операция: robot.durability()/W_R, остаток прочности инструмента переводится в остаточное количество использований инструмента. Реальное количество при стандартном конфиге примерно в 10 раз больше, но гарантированное количество именно такое. Это количество сравнивается с манхэттенским расстоянием до исходной позиции робота. Именно такое количество блоков может потребоваться прорубить при возвращении. К этому добавляется запас в 64 блока. Скорее всего, это максимальное количество движений, которое может потребоваться для полной выработки слоя. Если я верно помню, эта копалка копает столбиками площадью 8x8=64 блока. Да, именно так. Вызвав robot.durability(), имеет смысл сразу сохранить остаток использования инструмента в переменную и декрементировать её при каждом успешном использовании инструмента. Но при снижении её значения ниже критического уровня не надо сразу бежать на базу, а следует перечитать robot.durability() ещё раз и уже после этого принимать решение. @Doob решил эту задачу иначе. Его программа уже знает, что слой может быть полностью выкопан до того, как возникнет необходимости вернуться на базу, и проверяет прочность инструмента после обработки очередного слоя. Такая частота проверки, скорее всего, избыточна, и robot.durability() можно вызывать реже.

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

Обычная развилка: либо дописывать документацию, что с таким-то инструментом программа не работает, либо дописывать новый функционал. Добро пожаловать в разработку. Кстати, если речь идёт о синем буре 3x3 из Gravitation Suite, то для него оптимален другой алгоритм копки. Поэтому придётся не только детектор бедрока, но и всю копалку переписывать. Эта копалка просто не может реализовать весь потенциал синего бура. Да, адаптивность полезна. Тут вопрос лишь в том, готов ли разработчик усложнять алгоритм ради коротких эпизодов перемещения к сундуку. Кстати, синий бур в роботе разряжается довольно быстро, и перемещения к сундуку становятся не такими и редкими.

Сигнал "inventory_changed" будет поступать только после заполнения очередного стака, то есть, в среднем при каждом 9/64 взмахе бура. Это ненадёжный метод. С другой стороны, и опрашивать robot.count() по всем слотам тоже не вариант. Видимо, надо сначала оптимизировать эту проверку, проверяя только неполные слоты, а применять её только в случае, когда робот ушёл в шахту именно с этим видом бура. Обработка сигнала inventory_changed должна облегчить поиск неполных слотов.

Применительно к копалкам первое решение хуже второго. Третье решение обещает дать лучший результат, но не оправдывает надежд. Оно лучше первого, но также хуже второго. В случае, если маршрут робота пролегает в целом через пустые блоки, оптимален вариант "если не удалось осуществить движение, бей блок". Если пустые блоки на пути робота встречаются редко, оптимален вариант "сначала ударь блок перед роботом, затем двигайся". Вариант "сначала проверь блок, а затем бей или двигайся" уместен только на фермах опыта, где двигаться вообще не надо. Впрочем, возможно, даже там неуместен, я не проводил таких исследований. При желании можно даже посчитать тот уровень заполненности пути робота блоками, выше которого выгодно будет использовать первый вариант, а ниже – второй. Если тема получит развитие, можно будет и посчитать точное значение. А пока для простоты я буду исходить из предположения, что пещеры довольно редки, и почти всегда на пути робота находится блок. В случае, когда робот сначала пытается двигаться, а затем рубить блок в случае неудачи затраты времени примерно такие: 10 тиков на неудачную попытку движения. 6 тиков (предположим) на рубку блока. 8 тиков на успешную попытку движения. В случае, если робот сначала бьёт, а затем двигается: 6 тиков на рубку блока 8 тиков на движение Скорость продвижения увеличится в 24/14=1.71 раза. При сплошной копке "слой через два" ускорение не столь высоко, но всё равно ощутимо: в 1.38 раз. В случае, если перед роботом нет препятствий, и он выполняет неудачный взмах киркой до выполнения движения, произойдёт замедление в (1+8)/8 = 1.125 раза. Но при работе в шахте препятствие перед роботом чаще присутствует, нежели отсутствует. Применив подобные расчёты для варианта с использованием detect(), ты обнаружишь, что его применение вредно. По крайней мере, в шахте без больших полостей.

@serafim, у меня возникли вопросы в связи с этим кусочком кода: if r.forward() then xPos = xPos - 1 else r.swing() end Ты пришёл к этому решению интуитивно, или подсмотрел его в других программах? Это очень важный вопрос, т. к. касается не только твоей копалки, но и многих других. Подобное решение, будучи неоптимальным, встречается повсеместно. Тут сначала происходит попытка движения, а затем рубка блока, если попытка не удалась. Мне интересно понять, как мыслят программисты, применяющие такое решение. А их, похоже, большинство. Идея поменять порядок операций движения робота и рубки блока кажется тебе контринтуитивной?

Это поправимо: file:seek( "set", blkSize*blkNum ) blkData = file:read( blkSize ) if blkData then array = blkData:byte( 1, blkSize ) end

Проиндексировать можно. Читать данные массива можно так: content.byte(i,j) С записью тоже можно что-нибудь придумать, но универсального решения не существует, т.к. Lua не позволяет модифицировать строки, а пересоздание длинных строк весьма накладно. Оптимальное же решение придётся искать под конкретную задачу.

Поразмыслив, я запоздало сообразил, что можно было пойти более коротким путём в своих рассуждениях. Когда звучит вопрос об оценке правильности, то первый встречный вопрос, который следует задать: а по каким правилам следует оценивать правильность. По сути, правильность – это соответствие определённому своду правил. Эти слова не случайно являются однокоренными. Выражение "каждый прав по-своему" подразумевает, что каждый действует по своим правилам, не во всём совпадающими с правилами других. Мы следуем правилам не потому, что они абсолютно правильны, а потому что те помогают эффективнее достигать поставленных нами целей. При этом те же самые правила могут мешать достижению других целей. Например, есть правило документировать свой код. Но при недостатке времени следует достигать минимально рабочего результата, иногда жертвуя документацией. Или, например, студенты зачастую неразумно используют оператор goto, превращая свой код в невнятную свалку символов. Поэтому преподаватели вводят правило, запрещающее использование goto. И... часть студентов на всю жизнь вступает в секту противников оператора goto, избегая его применения даже там, где оно облегчает код. Вот ещё живой пример из другой темы: Прошло уже 10 месяцев с момента публикации этого кода, но правильность именования переменной до сих пор никого не волновала. А почему? А потому что в том контексте это правило не играло особой роли, и название переменной не мешало участникам обсуждения понимать друг друга. Вот такая получилась философско-филологическая тема. Не столько о программировании, сколько о логике и о смысле слов и действий. Применяйте правила там, где они уместны. А рассуждая о правильности, уточняйте контекст, который зачастую может содержать множество целей, иногда противоречащих друг другу.

Сложный вопрос. У нас на форуме мало любителей визуального программирования, а мод ComputerCraftEdu многие даже не запускали. Знатоков Mac у нас тоже не много. Но я попробую дать какие-то общие рекомендации. Во-первых я посоветую использовать обычный ComputerCraft и программировать на Lua. Всё-таки, визуальное программирование годится лишь для самых примитивных программ. Создавать чуть более сложные программы в визуальном редакторе становится очень затратно. Если программирование на Lua категорически не устраивает, то я могу дать только один совет: привести ПО на проблемных компьютерах к тому же состоянию, что и на рабочем: версии операционной системы и пакетов, java. Если версии совпадают, то следует скопировать настройки. А для начала можно просто скопировать папку лаунчера и Майнкрафта с корректно работающим модом на проблемные компьютеры.

Это лишь одна часть контекста, имеющая свою традицию именования переменных. Но это не весь контекст. Программист не должен ограничивать себя мелкими правилами, если они не позволяют ему осуществить задуманное. Поэтому первичен вопрос о целях, которые ставил перед собой программист при написании кода. И если особых целей не было, что выяснилось в последних постах автора вопроса, то смело применяем стандартные правила. Разве ты всегда чётко следуешь всем правилам? А как иначе? Ссылку на функцию, возвращающую счётчик, мы называем count. Тоже тавтология? Итератор, возвращающий ответ, можно назвать response. Как это название мешает пониманию кода? Кого оно вводит в заблуждение?

Отлично! У нас есть критерий оценки правильности. Мы называем переменные так, чтобы их название было осмысленным и не противоречило коду. С этой точки зрения прав сетевой программист: название переменной вводит его в заблуждение. Жаль, что он не предложил альтернативу, но попробуем восполнить этот пробел. Эту проблему тебе придётся решать каждый раз при написании кода. Названия переменных вроде handler, socket, interface, container и т.п. нежелательны в виду их излишней абстрактности. К тому же, в определённом контексте за этими названиями закреплены конкретные смыслы. Об этом уже упомянул @NEO. Чтобы правильно назвать переменную, надо задать себе вопрос, что именно она хранит. А для этого надо понять, какие значения ей присваиваются. Что делает функция request? Документация говорит, что функция request осуществляет запрос. Вполне логичное название для функции. Что возвращает функция request? Ответ на осуществлённый запрос. Значит, переменная хранит ответ. Теперь осталось перевести слово "ответ" на английский язык. Эта задача не всегда проста из-за наличия в языках синонимов. Причём, синонимы почти всегда имеют альтернативные смыслы. Для поиска наиболее точного перевода я рекомендую использовать гуглопереводчик, он показывает варианты перевода слова с дополнительными смыслами. Именно анализ дополнительных смыслов позволяет выбрать наиболее адекватный перевод. Предлагаю кликнуть по ссылке, там есть варианты перевода слова "ответ". В поле формы можно вбить любое другое слово. В нашем случае предложено 8 вариантов перевода. Ориентируясь по дополнительным смыслам синонимов, я выбираю название "response". Возможно, меня поправят другие форумчане, лучше меня владеющие языком.

Вопрос был не о назначении сетевых сокетов, а о правильности названия переменной. Без конкретики вопрос о правильности абстрактен. И ответ на него также будет абстрактным до тех пор, пока не появится конкретика. У тебя есть взгляд на вопрос в контексте сетевого программирования. Предлагаю дополнить его ответами на конкретные вопросы: Какое название переменной ты считаешь правильным в данном контексте, и почему? Какая проблема возникает, если эту переменную назвать "socket"?

Вне контекста вопрос о правильности некорректен. А контекст всё ещё не ясен. Поэтому все ответы на подобный вопрос окажутся мнениями, которые можно будет оспорить. Но ты же хочешь не спора, а какого-то устойчивого и однозначного решения? Есть такое правило: критикуешь – предлагай альтернативу. Альтернатива даёт возможность сравнения. И даже если критерии правильности изначально были непонятны, они начинают проясняться во время сравнения и обсуждения альтернативных вариантов. Здесь есть небольшой намёк на предмет спора: Знакомый, скорее всего, использует слово "socket" в узком смысле этого слова, как его обычно понимают программисты, работающие с сетевыми запросами. И если ты хочешь, чтобы такие программисты не спотыкались, читая твой код, то да, название переменной было выбрано неудачно. Именно неудачно, о правильности пока не говорим. Буквально слово "socket" означает разъём. Это очень абстрактный смысл, позволяющий применять это слово к любому программному интерфейсу, если очень хочется. На чьей стороне правда, сказать сложно. Ты прав, потому что не преследовал каких-то особых целей. Если нет целей, то нельзя определить и критерии истинности. Код работает? Значит, он правильный. Твой знакомый прав, потому что мыслит в определённом, привычном ему контексте. Он различает нюансы терминов, и в этом контексте название "socket" вводит его в заблуждение. Ты не прав, потом что ищешь правильность, не сформулировав критерии правильности. Твой знакомый не прав, потому что не предложил альтернативу. Вернёмся к поиску критериев правильности. А их можно определить только исходя из целей. Какой цели ты хочешь достичь, задавая вопрос о правильности использования термина "socket"? Предположим, ты получил ответ. Как ты его применишь? Какую проблему снимет новое решение?

Вне контекста вопрос о правильности не имеет смысла. Поэтому именно с выяснения контекста и начнём. Изначально вопрос был задан в разделе вопросов по Lua. И с точки зрения синтаксиса Lua ничто не мешает назвать переменную именно таким образом. Но, подозреваю, этот вопрос не про Lua. Поэтому пусть пока этот вопрос побудет в разделе общих вопросов. Может быть, это философский вопрос или филологический. Как знать... В чём заключалась твоя идея? Почему, на твой взгляд, именно это название переменной лучше всего отражает идею? Как понял эту идею другой человек? Какую он предлагает альтернативу?

Для работы с мышью используются сигналы touch, drag, drop и scroll. Почитать о сигналах можно на русском и английском языках.

То есть, это какой-то трудновоспроизводимый глюк? Это проверялось в сигнле или на сервере? Другие игроки могли внести изменения в BIOS или библиотеки?