eu_tomat

Нужна, судя по всему, ещё более ранняя. Например, во второй таблице присутствуют алмазный и кварцевый охладители. А в игре я таких блоков не вижу. Файл мода NuclearCraft-1.9g--1.7.10.jar. Также ты пишешь, что охладитель из светокамня способен увосьмерять охлаждение, но игра мне пишет только про учетверение. И это только на первый взгляд. Скорее всего, есть и другие различия.

А можешь найти таблицы, актуальные именно для твоей версии? Это слишком свежие таблицы. Они не совпадают с данными в игре для указанной тобой версии.

Мда... Даже типы топлива захардкожены числами. Зато здесь хотя бы нет двусмысленностей, свойственных естественным языкам.

Вряд ли для этого потребуется какой-то новый язык, когда уже есть Lua. И чтобы не изобретать лишнего, надо понять задачу и систематизировать её условия. А с этим пока имеются проблемы, я пока не уверен, что точно понимаю все условия. Если ты знаком с механикой этих реакторов, растолкуй, как оно работает. А всякие там языки, форматы и API — вторичны.

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

Как раз особые свойства и вызывают у меня больше всего вопросов. Давай разберём на примере редстоуна. Как указанная таблица позволяет понять, что при касании охладителем ячейки реактора происходит удвоение охлаждения? А что происходит при касании двух ячеек реактора? Учетверение охлаждения? Или дальнейший контакт с ячейками реактора уже не играет роли?

@Zelenuydrakon Я нашёл упоминание о том, что нагрев реактора можно как-то получить из силы сигнала красного камня, но так и не понял, откуда его снимать. Не знаешь, как работает эта механика? И работает ли она вообще? Скинь ещё таблицу с характеристиками реакторных блоков: всякие там охладители и прочие блоки. Надо попробовать придумать какой-то компактный способ хранения этих характеристик. Тогда можно было бы задавать схему заполнения реактора в файлах конфигурации нашей программы. Зная вид топлива и конфигурацию реактора, можно вычислить скорости его нагрева и охлаждения. А зная их, можно подобрать интервалы включений и выключений реактора для его разогрева и поддержания стабильной температуры. Но там тоже не всё просто: в редких случаях возможны лаги, приводящие к изменению интервалов. Поэтому желательно иметь дополнительный контроль. @Zelenuydrakon А на какую нагрузку будет работать этот реактор? Расход энергии будет постоянным, или нагрузка может меняться? Удобно было бы, если бы реактор подключался к нагрузке через счётчик энергии или измеритель мощности. Тогда, снимая с него показания, можно было бы вычислить текущую эффективность сжигания топлива, а затем соответствующую ей температуру реактора. Есть в твоей сборке блоки с такими функциями?

@BenniShifer919 Списки пользователей и контроль доступа, конечно, являются полезными функциями. Но почему ничего не сказано про работу сети? Какую функцию выполняет роутер? Каков протокол обмена сообщениями? Например, у моего соседа подключены три компьютера, и я хочу передать сообщение на один из них. Как это сделать?

А ещё скажи версию мода Nuclear Craft. Механика реакторов зависит от версии мода. Как оказалось, не во всех версиях. Не знаю, как они правильно называются. Там какие-то блоки можно установить внутрь реактора: для охлаждения, ускорения, увеличения энергии. Правда, похоже, не во всех версиях будет достаточным просто посчитать их количество. Для точного прогноза температуры потребуется знать всю схему реактора.

Посмотрел я на эти реакторы. Механика, насколько я понял, там следующая: Сжигание топлива в реакторе реализовано просто, если сравнивать с реакторами IC2, т.к. компоненты реакторов Nuclear Craft не имеют взаимного влияния. Это облегчает вычисления. Реактор может иметь дополнительные модули, влияющие на охлаждение, на время горения топлива, и на эффективность выработки энергии. Существуют различные виды топлива. Они подбираются, исходя из имеющегося сырья и требуемого конечного продукта. В каждом конкретном случае соотношение различных видов топлива является уникальным, оно зависит от потребностей и возможностей игрока в текущей ситуации. Исходя из этого, я бы стремился к схеме, в которой реактор не выключался бы никогда. Для этого потребуется посчитать соотношения видов производимого топлива. Зная эти соотношения, можно вычислить среднюю генерацию тепла, и уже исходя из этого, заполнять реактор охлаждающими модулями. Оставшееся свободным пространство реактора имеет смысл заполнить модулями, увеличивающими энергогенерацию и охлаждение. Для оптимизации эффективности использования реактора и сжигания топлива, скорее всего, имеет смысл заранее вычислить оптимальную последовательность подачи топлива различных видов. Это позволило бы реактору работать непрерывно, не перегреваясь, и при этом выдавать максимум энергии с единицы топлива, насколько позволяет конкретная реакторная сборка. В исходной задаче режим реактора пульсирующий, поэтому задача немного упрощается. Вычислять последовательность загрузки различными видами топлива не требуется, достаточно будет лишь вычислить момент, когда можно закидывать новую порцию топлива в реактор. Но даже для вычисления только этого момента всё равно потребуется таблица с характеристиками всех видов топлива, а также реакторных модулей. @Zelenuydrakon Не знаешь, где найти такую таблицу? Она бы позволила знать температуру реактора, ориентируясь лишь по моментам загрузки топлива.

А что там за нагрев? На что он влияет? И что влияет на него? Можешь описать полную механику работы этого реактора? Я никогда не играл с ним.

Хорошая мысль. В этом случае вся программа может свестись к примитивному алгоритму: положить заранее вычисленное количество топлива, выдержать заранее вычисленную паузу и повторять этот цикл до бесконечности. Или там более сложная механика? Есть какая-то зависимость от потребления энергии?

А какая версия игры и мода OpenComputers? Не так уж и мало. Если точно знать всё механику работы этого реактора, и она не содержит случайных элементов, то её можно эмулировать на компьютере и на слабонагруженных серверах включать-выключать реактор в точностью до такта. На лагающих серверах нужен некоторый запас по времени. При наличии случайностей в механике тоже возможны предсказания с некоторой точностью.

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

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

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

Хорошо, с этим разобрались. А каков диапазон чисел? И каковы шансы встретить маленькие числа в сравнении с большими? Если появление чисел в некотором диапазоне равновероятно, и для их кодирования достаточно, например, 16 бит, то не морочим себе голову и кодируем число двумя байтами. Или тремя, четырьмя и т.д. А если короткие числа встречаются заметно чаще длинных, то можно адаптировать трюк, использованный в кодировке UTF-8. Он позволит хранить числа переменной длины. Но, к слову, в UTF-8 он реализован не самым эффективным образом с точки зрения компактности, т.к. при его создании преследовалась ещё и цель быстрого определения первого байта, кодирующего символ. Выбросив это требование, мы получим ещё по два дополнительных бита с каждого последующего байта. Если же маленькие числа тоже встречаются не особо часто, а максимальная длина чисел при этом заранее известна, то длину числа эффективнее будет кодировать фиксированным количеством бит. Проиллюстрирую сказанное: UTF-8 кодирует значащие биты таким образом: 1 байт кодирует 7 бит: 0xxxxxxx 2 байта кодируют 11 бит: 110xxxxx 10xxxxxx 3 байта кодируют 16 бит: 1110xxxx 10xxxxxx 10xxxxxx 4 байта кодируют 21 бит: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx Выбрасываем из UTF-8 быстрый поиск начала цепочки: 1 байт кодирует 7 бит: 0xxxxxxx 2 байта кодируют 14 бит: 10xxxxxx xxxxxxxx 3 байта кодируют 21 бит: 110xxxxx xxxxxxxx xxxxxxxx 4 байта кодируют 28 бит: 1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx Продолжение цепочки для удобства можно кодировать старшим битом в каждом байте: 1 байт кодирует 7 бит: 0xxxxxxx 2 байта кодируют 14 бит: 1xxxxxxx 0xxxxxxx 3 байта кодируют 21 бит: 1xxxxxxx 1xxxxxxx 0xxxxxxx 4 байта кодируют 28 бит: 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx При кодировании длины цепочки фиксированным количеством бит немного снижается эффективность кодирования коротких чисел, но заметно увеличивается для длинных: 1 байт кодирует 6 бит: 00xxxxxx 2 байта кодируют 14 бит: 01xxxxxx xxxxxxxx 3 байта кодируют 22 бит: 10xxxxxx xxxxxxxx xxxxxxxx 4 байта кодируют 30 бит: 11xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx К этому добавлю, что хотя стандарт UTF-8 и не предусматривает использования более 4 байт для кодирования символа, в наших применениях мы не обязаны следовать этому правилу и можем компактно кодировать сколь угодно длинные числа.

Ты хочешь кодировать одним символом именно для визуальной компактности? Или требуется сократить объём в байтах? Символов-то в юникоде много, но на компактность хранения это не особо влияет. Например, кодировка UTF-16 использует 2 байта для хранения одного символа. А кодировка UTF-8 использует переменное количество байт: от 1 до 4, что получается более компактно при преимущественном использовании ASCII-символов (чисел от 0 до 127), но не очень компактно при кодировании чисел в диапазоне 128-65535.

@Oleshe Какую задачу ты пытаешься решить? Для кодирования произвольных двоичных данных при помощи символов существует, например, стандарт Base64.

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

Не совсем так. В OpenComputers задержка намеренно добавлена лишь при обращении к компонентами. А вызовы функций сами по себе обходятся заметно дороже обработки простых операторов. И это относится практически ко всем языкам программирования.

История очень интересная, но запутанная. Жаль, раскрыта не до конца. Не ясно, как перенос компьютера в гараж решает проблему оплаты электроэнергии. В гараже имеется какой-то бесплатный источник энергии? А если имеется, то зачем выключать компьютер и морочить голову дистанционным включением-выключением? Зачем эмулировать нажатия клавиш для выключения компьютера и тут же вызвать какой-то батник, если в том же батнике можно вызвать команду "shutdown"? Зачем вообще писать клиент-серверное ПО, если в Windows уже имеется всё необходимое? Команда "shudown" в Windows может выключать также и удалённую машину при наличии нужных прав. И то же самое, насколько я знаю, может делать пакет samba-common в Linux. Много ненужных усилий, мне кажется. Либо я не до конца понял задумку. Про трудности с доступом к серверу я не совсем понял. Но, попробую дать пару советов. Доступ к файлам на Windows сервере настраивается несложно, а к ним можно доступитсья не только из Windows, но и из Linux с помощью пакета smbclient. Доступ к GUI сервера через локальную сеть имеет смысл реализовать через что-нибудь интернето-независимое. Например, VNC неплохо работает как в Windows, так и Linux. А ещё проще будет на сервере Windows дать доступ по RDP, а с Linux-машины подключаться с помощью клиента "rdesktop", например. Надеюсь, мои комментарии как-то соответствуют заявленной теме. Всё-таки, выбранный стиль текста не способствует хорошему пониманию изложенной истории. Желаю удачи с переносом майнинга и крафтинга в реальный мир!

Спасибо, важное напоминание. Но в этом случае мод и не обязан пересчитывать занятое место, если файлы создавались не через сам мод. В этом случае фраза о недоделках теряет смысл.

В какой версии мода для получения занятого пространства требуется создавать файл? И какой результат возвращает spaceUsed(), если файл не создавать?

Потому что для быстрогого доступа по ключам Lua использует не сами ключи, а их хеши. Для перебора таблицы по ключам в требуемом порядке требуется ещё одна таблица, дающая доступ к ключам по их последовательным целочисленным индексам. Если требуется выводить ключи в алфавитом порядке, такую таблицу можно сформировать автоматически: > tbl={a=11,b=22,c=33,d=44,e=55,f=66,g=77} > for k,v in pairs(tbl)do print(k,v)end ee 55 gg 77 ff 66 aa 11 cc 33 bb 22 dd 44 > key={} for k,v in pairs(tbl)do key[#key+1]=k end > table.sort(key) > for i,k in ipairs(key)do print(k,tbl[k]) end aa 11 bb 22 cc 33 dd 44 ee 55 ff 66 gg 77