Лидеры

@Oleshe Поздравляю с самостоятельным решением проблемы. Я, к сожалению, не смог понять ни вопрос, ни его решение.

Для тех, кому лень читать длинный текст: Проблема: Код, записанный в EEPROM и на загрузочных дисках, может быть запущен на процессоре неподходящей архитектуры. Решение: Описанный в статье стандарт. Автор предлагает добавлять в код EEPROM комментарий с указанием требуемой архитектуры, а также модифицировать OpenComputers, чтобы тот распознавал архитектуру, указанную в EEPROM. Есть похожее предложение по маркировке дисков, но я уже не стал вникать. По-моему, проблема высосана из пальца и не требует решения. Обычно этим занимается установщик. Он прошивает EEPROM, записывает файлы на диски, устанавливает нужную архитектуру и перезагружает компьютер, полностью настроенный и готовый к работе.

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

Совершенно не обязательно. От конкретной версии компилятора зависит, и скриптовость языка на это никак не влияет. И вообще, я отвечал на это утверждение: Задержку никто намеренно не вызывает. Такая ситуация во многих ЯП, не только в Lua и не только в OpenComputers.

в конфиге computer - ramsizes там они все

Есть огрызок кода: Как мы видим, оно должно привязывать параметры к их эквивалентам в raw. Но, когда мы изменяем параметр объекта, параметр raw-а остаётся тем-же. Соответственно нужно что-бы если мы изменяли параметр объекта, мы изменяли его и в raw. Аля: local object = {} local raw = {localX = -20} object.raw = raw object.x = 15 object.raw.localX = object.x print(object.x,object.raw.localX) -- 15 15 object.x = 0 print(object.x,object.raw.localX) -- 0 0 object.localX = 20 print(object.x,object.raw.localX) -- 20 20 Вручную каждый друг к другу привязывать не вариант т.к. их слишком много, можно объединить параметры, наставить сравнений, то через цикл оно будет само подбирать нужный вариант.