eu_tomat

Маловато. Во-первых, возвращается локальное время сервера, зависящее исключительно от предпочтений админа. Во-вторых, каждую секунду дёргать файловую систему ради получения точного времени — тоже сомнительная идея, которая при массовом использовании вряд ли будет одобрена админом. Самый правильный способ, на мой взгляд, как уже предложил @ivan52945, использовать ComputerCraft для отслеживания рестарта сервера. А время корректировать сразу после рестрата и каждые 15 минут, например. Интересно было бы рассмотреть возможность использования каких-либо схем на красной пыли, но единственное, что я смог сразу вспомнить — это сенсор робота-рыбака, сбивающийся при выгрузке чанка. Вряд ли кто-то захочет использовать такую схему в часах. Возможно, кто-то найдёт более удачный способ отслеживания момента перезагрузки чанка без использования ComputerCraft.

Какова ирония! То, что всегда считалось недостатком ComputerCraft, в определённой ситуации стало достоинством.

Надо корректировать после каждого рестарта сервера. Как отследить этот момент, не ясно, поэтому надо корректировать периодически. А вот, как часто надо корректировать, зависит от условий задачи. Слишком частые обращения к сервису чреваты баном по IP, а редкие коррекции лишают такие часы смысла. Заходишь такой после рестарта сервера, а часы отстают на минуту-две. Зачем они тогда вообще нужны? Да и вообще, хороший вопрос, зачем наблюдать реальное время именно в Майнкрафте, когда есть более удобные инструменты. Сделать более-менее правдоподобные часики реально, но админ сервера не будет рад использованным методам.

А зачем нужны драйверы? В настоящих системах, использующих разношерстное оборудование, назначение драйверов понятно. А в OpenOS они зачем нужны? Какое такое разнообразие протоколов приводится к единому стандарту?

Пусть будет. Если проблема сохраняется, то способы ее решения полезно знать не только тому, кто решился задать вопрос.

Глобальные переменные не совсем зло. Они всё-таки необходимы для некоторых целей. Память занимают любые переменные, но локальные работают быстрее. Правда, есть нюансы, о которых где-то рассказывал @ECS: если часто вызывать функцию, внутри которой определена локальная переменная, то вместо ускорения можно получить замедление. Выход из ситуации заключен в создании локальных переменных на уровнях выше часто вызываемых функций. К слову, затраты на доступ к глобальной переменной эквивалентны затратам на доступ к полю локальной таблицы. Главная же особенность глобальных переменных заключена в том, что они доступны любым программам, запущенным в данном окружении. С одной стороны, это ведёт к замусориванию глобального окружения и созданию помех одними запускаемыми программами другим программам, а с другой, глобальне переменные при грамотном использовании дают программам механизм обмена данными через глобальное окружение. И если не стоит именно такая задача, то глобальные переменные создают больше проблем, чем решают их.

Можно помочь с организацией соревнований дронов-пылесосов.

Если рекурсивное создание каталогов не требуется, то зачем нужны лишние действия по разбору пути к файлу на части и последующей их сборке?Есть же filesystem.path(path)

Пояснение: sides.side - обращение к полю с именем side в таблице sides. sides[side] - обращение к полю с именем, содержащейся в переменной side, и находящимся в таблице sides

@@Miroshka, участок кода, начинающийся с elseif, не может быть функцией. И что значит запись 222()?

Пикнуть и выключить, если на то пошло. Но этому способу приходится конкурировать с массой других, в том числе и рекордно компактных.

local, конечно же, не крашит. А вот, require не даст взлететь твоему дрону.

@@lokin135, советы, конечно, полезные, но автор уже больше года не появлялся на форуме.

Так и должно быть. Переназначение io.stdout:write в глобальном окружении перенаправляет весь стандартный вывод в модем. Для перенаправления вывода лишь определенных потоков, следует пересоздать таблицу io.stdout в их окружении, скопировав поля, оставшиеся неизменными. Также должны быть заново созданы родительские таблицы: -- создание таблицы нового окружения, копирование всех полей из старого local env = {} for k,v in pairs(_G) do env[k]=v end -- ссылка на глобальное окружение в новом окружении env._G=env -- подмена таблицы env.io с копированием полей из старой env.io={} for k,v in pairs(_G.io) do env.io[k]=v end -- подмена таблицы env.io.stdout с копированием полей из старой env.io.stdout={} for k,v in pairs(_G.io.stdout) do env.io.stdout[k]=v end -- подмена функции env.io.stdout.write в новой таблице function env.io.stdout:write(...) m.broadcast(512, ...) end

Проверил на OpenComputers-MC1.7.10-1.7.0.1085-universal.jar Методы getAllStacks и getInventoryName отсутсвуют как для контроллера инвентаря, так и для транспозера.

Чётко! И сборщик мусора зря не напрягается, и результаты вычислений используются повторно.

А можешь скинуть ссылочку на твиттер Рида?

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

Не уверен, что я понял вопрос. Это решение обратно преобразованию idx = x + y*80 + z*80*64, оно изначально задумывлось таким образом, чтобы получить однозначное соответствие частных индексов и общего. Попробуем для начала излечь x. Нам известно, что значение x находится в диапазоне [0..79], а idx равен сумме x и еще какого-то числа, кратного 80. Логично, что для получения x достаточно взять остаток от деления idx%80. Далее i получает значение целочисленного деления i//80 Теперь i = y + z*64 Теперь извлекаем y, зная, что значение y находится в диапазоне [0..63], а i равен сумме y и еще какого-то числа, кратного 64. Значение y будет равно остатку от деления i%64, а i получает значение целочисленного деления i//64 Теперь i = z Осталось присвоить z = i, и задача решена.

Предположим, нужен массив [x,y,z] размером 80x64x20 Зная частные индексы и размеры массива нужно получить общий индекс. Выбираем любой из индексов. Пусть это будет x. Изменение x на единицу будет приводить к изменению общего индекса на единицу. x ограничен 80 значениями. Значит, последующие индексы надо будет умножить на 80 Теперь выбираем следующий индекс. Пусть это будет y. Изменение y на единицу будет приводить к изменению общего индекса на 80, как мы поняли выше. y ограничен 64 значениями. Значит, последующие индексы надо будет умножить на 64. И не забываем об умножении на 80. То есть, на 80*64. Теперь остался индекс z. Исходя из предыдущих рассуждений, изменение z на единицу будет приводить к изменению общего индекса на 80*64. z ограничен 20 значениями. Значит, последующие индексы надо будет умножить на 20. И не забываем об умножении на 80*64. То есть, на 80*64*20. Но других индексов после z не наблюдается, поэтому не забиваем себе голову. Итоговая формула: idx = x + y*80 + z*80*64 При выборе другого порядка индексов формула может отличаться. Следует придерживаться выбранной схемы. Для получения частных индексов из общего индекса используется обратная схема: i=idx x=i%80 i=(i-x)/80 y=i%64 i=(i-y)/64 z=iЭту последовательность вычислений можно (и нужно) оптимизировать, избегая лишних присваивний, но она лучше подходит для объяснения алгоритма. Пример > X,Y,Z = 80,64,20 > x,y,z = 37,21,11 > idx = x + y*X + z*X*Y > =idx 58037 > i=idx > x=i%80 i=(i-x)/80 > y=i%64 i=(i-y)/64 > z=i > =x,y,z 37 21 11И надо помнить, что индексы в этой схеме нумеруются от нуля в отичие от принятого в Lua.

Апргрейд-крафт спасёт нас.

Мне кажется, это лишнее. Мобы прекрасно пеленгуются и разбираются роботами на запчасти.

Сидеть в бункере и рулить роботами – скучноватое занятие, как по мне. Управляя, наблюдать за армией роботов – совсем другое дело. Для зрелищности нужна свобода перемещений, но возможности игрока влиять на мир следует сильно ограничить. Года два назад, крепко задумавшись над чем-то похожим, я так и не придумал ничего внятного. Более-менее легко реализуемый вариант был таким: Есть специальные майнерс-миры, привлекающие игроков кратной рудогенерацией, повышенными урожайностью и ростом растений, неограниченным количеством разрешенных реакторов и чем-то ещё. Игрок защищен от агрессивного мира эффектами скорости и регенерации, но скован огромного размера эффектами усталости и слабости. Миры ежесуточно регенерируются. Можно обойтись без эффекта скорости, заспавнив побольше свиней для развития авиации.

Кстати, о законе. За гриферами (как и за вампирами) закрепился негативный смысл, и связано это с тем, что Майнкрафт является песочницей. Там игроки лепят куличики и строят домики. Понятно, что их печалит несанкционированная порча своих творений. Это, конечно, плохо. Но на индустриальном сервере, где всю нудную работу могут выполнить роботы и другие механизмы, утрата становится менее существенной. А при наличии полностью защищенной базы, сохраняющей всё самое ценное, некоторый запас роботов, инструментов и небольшое производство, потеря завода перестаёт быть трагедией, особенно, если учесть, как быстро окупают себя заводы в Майнкрафте. Если на сервере любая постройка может быть собрана и разобрана роботом, ресурсы для построек тоже добыты роботом, то и постройки и ресурсы перестают иметь решающую ценность. И, как говорит @qwertyMAN, ресурсы для грифера тоже вторичны. Первичен же сам процесс. И если процесс завязан на использование роботов, то такой процесс на computercraft.ru должен быть не только не запрещенным, но и поощряемым. Мне кажется, имеет смысл пересмотреть роль грифера на наших серверах. Понятно, что это не относится к PVP и сканированию или убийству игрока с помощью SGSC. Но грифер, льющий воду на мельницу Lua, достоин не наказания, а уважения.

Почему перед публикацией не проверяешь код на работоспособность? В этом фрагменте и if потерялся, и в elsif ошибка, и в кодах zn разнобой. print ("Знак ❶[1],❷[2],➌[3],❻[6],➒[9],Нет знака[-]") zn = io.read() elsif zn == "-" then cb.setName(m.."§7§o]§r§8 [§"..pcol..pref.."§8") elseif zn == "1" then cb.setName(m.."§7§o]§r ❶ §8[§"..pcol..pref.."§8") elseif zn == "2" then cb.setName(m.."§7§o]§r ❷ §8[§"..pcol..pref.."§8") elseif zn == "➌" then cb.setName(m.."§7§o]§r ➌ §8[§"..pcol..pref.."§8") elseif zn == "❻" then cb.setName(m.."§7§o]§r ❻ §8[§"..pcol..pref.."§8") elseif zn == "➒" then cb.setName(m.."§7§o]§r ➒ §8[§"..pcol..pref.."§8") end И вообще, вместо длинной последовательности elseif удобнее использовать таблицу: local sign={["1"]=" ❶ ", ["2"]=" ❷ ", ["3"]=" ➌ ", ["6"]=" ❻ ", ["9"]=" ➒ "} cb.setName(m.."§7§o]§r" .. (sign[zn] or "") .. "§8[§"..pcol..pref.."§8")