Лидеры

Не думаю, что цели твоего и моего проекта совпадают. Сейчас объясню, почему Вот оно! OCNS задумывался (и даже немножко реализовывался) как портирование протоколов из реальных сетей в Minecraft. Для "картошечки" действительно логична будет сеть одноранговая - простой и надежный, как алмазная мотыга, вариант Но для меня главным было реализовать по максимуму основные возможности протоколов реальных - многоранговость, межсетевая коммуникация, и прочие умные слова, которые совершенно не нужны обычным любителям "картошки" - им куда удобнее будет твоя концепция. Вот мое мнение - в этом вопросе нет ни "сильно неправых", ни сильно правых - есть просто две противоположные, скажем пафосно, философии - "картошечки" и "песочницы". Хочешь делать "картошку"? Пожалуйста, делай - ничего нехорошего в этом нет - создать хороший инструмент, которым все будут пользоваться - та еще задачка, и если ты ее решишь - формчане тебе будут признательны Но, боюсь, тогда с моим проектом тебе просто не по пути

13*0.05 = 0.65 секунд на проверку. Плюс 2*0.05 = 0.1 секунд на замену одного отражателя. Вполне реально. Но при сильном снижении TPS сервера можно и не успеть произвести замену. Особенно, если требуется заменить более одного отражателя за раз. Есть более быстрый способ контроля, но он потребует усложнения алгоритма. Реактор не является чёрным ящиком, и его текущее состояние поддаётся вычислению из предыдущих. В большинстве случаев даже не требуется писать эмулятор реактора. Достаточно вычислять лишь ключевые значения. Что для этого нужно знать? Во-первых, компьютеры OpenComputers определяют время с точностью до тика. Реакторы и все его компоненты одномоментно изменяют своё состояние один раз в 20 тиков. Во время лагов интервалы между реакторными тиками могут становиться неравномерными, сжимаясь и расширяясь на несколько майнкрафтовских тиков. Но в одном можно быть уверенным: если в какой-то момент была зарегистрирована смена состояния одного из компонентов реактора, то изменилось и состояние других компонентов, если схема вообще предполагает изменение их состояния. Во-вторых, некоторые из малых изменений состояний реакторных компонентов невозможно остследить по причине слегка кривой арифметики. Поэтому очередной реакторный тик не всегда удаётся отследить посредством проверки, например, прочности MOX-сборки, и тем более, урановой сборки. Но в нашей схеме отражатели сгорают быстро, их прочность меняется каждый реакторный тик на очень большие величины, которые невозможно скрыть даже имеющейся арифметикой. В-третьих, в зависимости от применённой схемы можно посчитать точное время работы любого из компонентов реактора. Это позволяет заранее составить график плановой замены компонентов. Для максимальной защиты реактора от лагов сервера график замены компонентов должен быть по возможности равномерным. Знание этих механик позволяет вычислять состояние всех компонентов реактора, ориентируясь по состоянию лишь одного из них, экономить драгоценные тики и повышать устойчивость микроконтроля. А пр аккуратном программировании можно даже снизить нагрузку на сервер.

А за сколько примерно можно чекнуть 13 слотов со старым апи? Если это не слишком большая задержка, то можно просто офать реактор до проверки и врубать после проверки и замены конденсаторов.

Rate my setup guys

Там скорее огрызок от апи, сделать то оно конечно можно, но сильно сомневаюсь что оно будет работать а не лагать. По моим наблюдениям конденсатор за одну секунду может выгореть от 0 до 4 % в зависимости от схемы в реакторе. Реактор обновляет данные 1 раз в секунду, сейчас прога опрашивает его каждые 0,7 секунд методом транспозера getAllStacks получая сразу всё содержимое камеры реактора в виде таблицы, затем молниеносно проверяет ранее сохранённое расположение конденсаторов не перебирая всё содержимое камеры. Возьмём к примеру эту эффективную схему Здесь 13 конденсаторов, и без метода getAllStacks придётся перебирать их по очереди делая 13 опросов реактора, и это нужно успеть сделать за 1 секунду, или на следующей секунде конденсатор уже может догореть и взрыв обеспечен Вторая замеченная проблема это поиск стороны расположения реактора и сундука, там использован метод транспозера getInventoryName которого также нет на ранних версиях. Сейчас можно произвольно лепить управляющие блоки реактору, программа сама их найдёт и назначит, в противном случае придётся назначать стороны ручками, или строить только один вариант расположения блоков. Возможно это можно будет победить опросом размера инвентаря, но это не сильно надёжно и возможны ошибки, например если поставят нестандартный большой сундук, а сейчас поиск происходит по имени и ошибок быть не может. Возможны ещё какие то проблемы вылезут в процессе. Как по мне зря иговые серваки сидят на старом OC по три и более лет, обновить не так уж и сложно, тем более что мод развивается.