jammer312

Про включение микроконтроллеров компьютерами знаю, здесь оно не используется из-за того, что нет возможности определить, относится ли микроконтроллер к ячейке или нет. Использование прямого включения в качестве запасного варианта делает нежелательным установку gps ячейки (точнее, ее контроллера) вплотную в другим микроконтроллерам, ибо и при первоначальном включении, и в случае форсмажора, из-за которого один из микроконтроллеров ячейки не проснулся, может включиться лишний микроконтроллер (вред этого варьируется в зависимости от назначения этого микроконтроллера). Могу сделать дополнительную версию, включающую подобный функционал, но имхо овчинка выделки не стоит (3 лишних прожатия пкм при постройке погоды не сделают).

Захардкоженный порт поправил, поле переименовал, `ok` сделал локальной.
Про объявление локальных переменных, использующихся один раз - мне кажется, их использование положительно влияет на читаемость кода, при этом потери от их объявления минимальны (емнип, луа держит локальные переменные на стеке, а может даже (некоторые) на регистрах, ну и оптимизаций при компиляции никто не отменял; даже если ничего из этого не выполняется, все равно упомянутые потери несоизмеримо малы по сравнению с временем работы компонентов). В частности, то, что `setWakeMessage` возвращает старое значение, мне не кажется очевидным, к тому же вики умалчивает об этом.

Суть упрощенных вычислений - в прошлой реализации я решал СЛУ методом крамера, а там много умножений. В этой реализации я пользуюсь геометрией системы:
Будем искать относительные координаты цели. Относительные координаты контроллера - (0, 0, 0), 3 микроконтроллеров - (+-1, 0, 0), ... ,(0, 0, +-1).
Вместо решения той системы (подробно об этом в прошлой теме) из 3 уравнений, будем решать систему из других трех уравнений, конкретно получаемых вычитанием из первого уравнения предшествующей системы второго, третьего и четвертого. Из-за особого вида координат контроллера и микроконтроллеров уравнения получаются вида x_i * (2x - x_i) = d_0^2 - d_i^2 (d_0 - расстояние до контроллера, d_i - расстояние до микроконтроллера, у которого i-я координата не ноль, x_i - ровно эта i-я координата) и из них весьма тривиально выражаются x, y и z.
Для получения относительных координат контроллеров пользуемся способностью микроконтроллеров "закрывать" стороны, чтобы через них не отправлялись проводные сообщений. Стороны у него не относительные (перед-зад), а абсолютные (юг-север). Собственно, на этапе конфигурации каждый микроконтроллер отправляет в каждую сторону (кроме лицевой, ибо на ней он крашится, но т.к. делает он это через pcall, все окей) сообщение, контроллер же ловит их и запоминает, с какой стороны пришло.

Ну и как обычно, важное уточнение, подобный жпс дает координаты с точностью до блока, ибо события модема дают расстояние именно до блока, а не до entity, от которой пришло сообщение.

Я уже закидывал сюда похожую прогу года три назад, но она кривая-косая, не очень надежная, ну и геморная в плане развертки.
Эта версия более компактная (и простая в постройке), использует упрощенные вычисления и более эффективный механизм передачи сообщения меж компонентами; помимо этого используются особенности микроконтроллеров для автоматической конфигурации системы.
Код в репозитории, для контроллера и периферии. Для постройки одного модуля нужно 3 микроконтроллера второго уровня и один компьютер второго уровня, начинка одинаковая, в каждом нужен процессор, плата оперативной памяти и беспроводная плата второго уровня. Операционная система на компьютер не нужна.

В данном контексте компьютер будет контроллером, микроконтроллеры - периферией. Код для них пишется на eeprom. Помимо кода на eeprom можно записать параметры работы (в сегмент данных), для периферии это просто одно число - порт, на котором ожидаются запросы, для контроллера эта строка вида "port: \d+, key: \w+, anchor: \{-?\d, -?\d, -?\d\}", в ней записаны порт, на котором ожидаются запросы и с которого отправляются ответы, ключ-пароль (для настройки координат через беспроводные сообщения, об этом потом), а также якорь - координаты компьютера. По умолчанию используется 312 порт, ключ-пароль admin, и координаты {0, 0, 0}.

Схема постройки простая, нужно установить где-либо компьютер-контроллер, а потом вплотную к трем его сторонам установить микроконтроллеры-периферию, при этом не должно быть такого, что контроллер расположен между двумя периферийными микроконтроллерами (если с одной стороны есть микроконтроллер, на противоположную ставить нельзя). Помимо этого лицевые стороны микроконтроллеров (одна из 6 сторон имеет иную картинку, и, что важно, к ней не присоединяются провода) не должны смотреть на контроллер.
После постройки нужно единожды включить каждый из 4 компонентов, они при этом сами быстро выключатся. Это нужно для настройки модема, для того, чтобы компонент просыпался при получении определенного сообщения.
После этого система уже готова к работе, но при этом не знает (если это не было заранее записано в сегмент данных eeprom контроллера) своих координат, и будет отвечать на все запросы относительными. Для включения системы достаточно отправить сообщение "gps_wake", при этом система запустится, сконфигурируется, и после этого отброадкастит сообщение "gps_ready". Такое же сообщение, но на адрес того, от кого пришло "gps_wake", отправится в случае, если система уже активна на момент получения запроса.
Для того, чтобы сообщить координаты контроллеру, нужно отправить сообщение "gps_anchor", после которого идет ключ-пароль (записан в сегменте данных eeprom контроллера), после которого идут координаты (3 числа) контроллера. Координаты при этом запишутся на eeprom, т.е. при выключении-включении они все так же будут известны контроллеру.

Для использования системы достаточно отброадкастить "gps_request", контроллер ответит (именно тому, от кого запрос) сообщением "gps_response", после которого идут 3 числа - координаты x, y, z. Таймаут обработки запроса - 1 секунда, если вдруг 1 секунда прошла, а ответа не пришло - что-то не так. При этом контроллер при таймауте запроса забывает все его данные, поэтому кривой запрос (например, отправленный сквозь толстую стену, которая снизила мощность сигнала настолько, что он дошел лишь до части системы) не будет "портить" последующие. Имеет смысл "включить" систему перед первым запросом (послать "gps_wake" и дождаться ответа "gps_ready"), на непосредственно включение уйдет до примерно 2 секунд (вообще с потолка взял, на деле должно шустрее, но внутри таймаут привязки стоит именно 2 секунды, после этого он отправляет 3 сообщения периферии и посылает сообщение о готовности), включенная же сразу ответит.

Картинка для референса:

Кажется, я нашел, в чем проблема.
Когда робот идет по координатам, он сначала поворачивается, потом идет вперед, пока не дойдет до нужной координаты. Все бы хорошо...
НО. На каждом шагу (на самом деле каждые 32) робот проверяет разные параметры, и, если ими не доволен, возвращается домой, потом возвращается обратно на те же координаты, при этом не учитывая своей ориентации. Если он это сделал в середине пути, он может после возвращения быть повернут не туда, и переть не в ту сторону, все так же ожидая достижения нужной координаты, которой он никогда не достигнет.

Лечится добавлением запоминания направления туда же, где в home запоминаются координаты, и добавлением smart_turn на это направление после возвращения на эти координаты.

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

P.S. Завершение работы нашел, робот снова убежал далеко (но потом вернулся), пока неясно, почему.

В 27.06.2019 в 08:10, Doob сказал:

@BrightYC Нашел странный баг на 1.7.10, надо проверить фикс.

 

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

Удивительно, но я пропустил самое главное.

Может, это я чайник, но теперь у вас робот при возвращении домой пакует ресурсы (вызывает сортировщик ДО выгрузки), проверяет инвентарь (вызывает в конце сортировщика), видит, что инвентарь полон, возвращается домой...
Иными словами, циклится.

Не уверен, насколько эффективно и верно предлагаемое, но оно весьма просто. Ну и я на практике не проверял, это просто на ходу придуманный вариант.
Сначала надо выяснить, какое максимальное целое число можно хранить в переменной в луа без потери точности, пусть это будет N, тогда n=sqrt(N) (округленное вниз).
Длинное число реализуем как индексированную таблицу произвольной длины, в которой в каждой ячейке хранится число от 0 до n, сие есть запись числа в позиционной системе счисления по основанию n+1. Тогда операции можно реализовать по аналогии с сложением/вычитанием/делением/умножением столбиком (с учетом того, что система счисления уже не десятичная, конечно же), при этом операции над разрядами - просто арифметические операторы луа. Выбор основания гарантирует, что при сложении, вычитании и умножении разрядов переполнения или потери точности не будет. Взятие остатка от деления можно реализовать через деление, умножение и вычитание (ессно целочисленное) (a%b = a-(a/b)*b).

P.S. Основание у системы счисления выбрано согласно двум соображениям: 1. оно должно быть как можно больше, чтобы кол-во разрядов, а следовательно - кол-во операций при умножении и делении, было как можно меньше; 2. оно должно быть таким, чтобы при самой "опасной" операции - умножении - не происходило потери точности (ну или переполнения, будь в луа целочисленная арифметика).
Ну и "какое максимальное целое число можно хранить в переменной в луа без потери точности" сформулировано немного некорректно, я имел ввиду такое число N, что все числа от 0 до N представимы в переменной. Скорее всего с этой оценкой я переосторожничал, но лучше недооценить, чем переоценить.

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

Концепт - цистерна настроена на некий цвет, хранит некую жидкость; если в цистерне кончается жидкость, она переключается на другой цвет, в цистерне с которым жидкость есть; если же цистерна заполняется - переключается на "пустой" цвет. Вот простая реализация, которая работает (не проверял, но должна) как на ОпенОС, так и на чистой прошивке: https://pastebin.com/2V1qY4LH

В начале проги три параметра, первые два задают области частот (на каких цветах цистерна может хранить жидкость), третий - задержку меж обновлениями цистерны (проверкой и переключением на цвета).

Для работы нужен комп с подключенным к нему адаптером, стоящим вплотную к цистерне. Работает согласно описаному концепту.

Защиты от дурака особо не содержит, разве что ограничение диапазона частот (нижняя граница взята "с потолка", но наверняка верная, верхнюю искал бинпоиском (последняя не рантаймящая)(да, мне лень было считать кол-во цветов и возводить в куб))

Преимущества:
1. Весьма дешевая 4-блоковая цистерна емкостью в 65536 ведра (можно меньше).

2. Неужто вам первого пункта не хватило? Оная цистерна может находиться в нескольких местах сразу, а также легко перемещаема, что существенно, например, при осушении незера.

Недостатки:

1. Задержка меж обновлениями. Если у вас нечто, что люто быстро забирает или заливает жидкость, скорость оного будет ограничена скоростью компа.

2. "Дребезжание" на границах. Если цистерна заполнена, она будет переключаться меж эти "заполненным" цветом и следующим "пустым", что может немного задержать доступ к жидкости (когда надо выкачать, а оно "прыгнуло" в "пустой" цвет, например). Я не придумал умного способа это отлавливать, но можно придумать внешнее средство контроля (которое в этом неопределенном случае определяет состояние), или захардкодить определенный выбор. Но текущий вариант позволяет без вспомогательных конструкций и забирать, и доливать жидкость, пусть и с небольшой задержкой.

3. Возможные приколы при использовании нескольких таких канистр на пересекающихся диапазонах (например, когда из состояния неопределенности из-за небольшого рассинхрона одна канистра ушла на следующий цвет и в нее долили, а из другой в то же время забрали, и они рассинхронизировались меж собой).

Проблема:

Комп не может менять частоту цистерны с алмазным замком, что делает идею неприменимой на сервере (ибо с замком оно не работает, а без замка использование приравнивается к раздаче, и вас скорее всего переедет фемидой). Однако, если вдруг подобное ограничение уберут, система наверняка будет востребованной. К синглу эта проблема по очевидным причинам не относится.

io,component=require"io",require"component" -- Подключаем библиотеки io и component для взаимодействия соответственно с пользователем и с компонентами

redstone=component.redstone -- Получаем прокси компонента редстоуна, будь то карта или блок



SIDE=2 -- Задаем сторону, в которую будет выдаваться сигнал



function lock()

	print"Enter password"

	t=io.read()

	if t=="123" then

		print"Correct!"

		redstone.setOutput(SIDE,15)

		os.sleep(7)

		redstone.setOutput(SIDE,0)

	else

		print"Incorrect!"

	end

end



-- Начало самой программы



while true do --Всегда повторяем кусок ниже

	lock() --Вызываем функцию замка

	os.sleep(0) --Даем событиям шанс на обработку. Здесь не играет особой роли, но обычно полезно

end

1. Объявляешь функцию lock, вызываешь функцию pass. Pass не определена, о чем он тебе и говорит.

2. Если не ошибаюсь, у тебя не заработает еще по одной причине, а именно redstone не определен. Попробуй впихнуть в самое начало 'redstone=require"redstone"' или 'redstone=component.redstone'.

3. Делать это через рекурсию - упорото и небезопасно, переделай под цикл.

P.S.

4. 'sleep' замени на 'os.sleep'

5. В начало проги 'io=require"io"', 'read' замени на 'io.read'

Вот одно из предложений:

http://computercraft.ru/topic/1977-rekvest-apgreida-kompas-dlia-os/

Для поддержания чистоты темы предлагаю все обсуждение этого предложения вести в его теме.

Вкратце суть: предлагается введение апгрейда для планшета, который позволяет получать направление, в котором смотрит игрок.

Апгрейд для планшета; возможно, найдется применение и в роботах/дронах, но я пока не придумал.

Суть апгрейда - позволяет получать направление, в котором смотрит игрок, который держит планшет (два угла, по горизонтали и по вертикали), помимо этого сообщает оное вместе с событием "tablet_use".

Область применения - задачи, в которых требуется более точное позиционирование в пространстве, вот несколько идей в качестве примеров:

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

Очевидно, применение апгрейда этими примерами не ограничивается.

Надеюсь, многие найдут предложенное полезным, просьба оставлять конструктивную критику/предложения по улучшению идеи апгрейда в комментариях, если таковая (-ые) будет.

У меня не получилось установить оное ингейм, валится на подгрузке иконки. Пока в код не лез, но вот скрин проблемы:

P.s. До меня внезапно дошло, что может не хватать места. Ща вставлю второй хард и попробую снова.

[uPD] Да, именно так, теперь вроде нормально поставилось.

Сие ( http://pastebin.com/C0S2m3d8 ) является реализацией программной навигации для робота под eeprom.

Здесь уже мелькали реализации подобного, но их все отличает от предложенной большой размер и наличие малоиспользуемых функций.

Собственно эта реализация влезает в 780 байт с учетом двух переводов строки после себя (ну мало ли). Имена переменных и функций сокращены настолько, чтобы занимать как можно меньше места, но при этом оставаться осмысленными. Отступы убраны для уменьшения размера. Некоторых проверок "на дурака" нет из тех же соображений.

Значимые переменные: ns,nx,ny,nz - направление и три координаты, где x и y образуют горизонтальную плоскость. Изначально робот смотрит в сторону оси x, ось y направлена направо, ось z - вверх.

Значимые функции:

n_u, n_d - navigation_up/down, движение вверх/вниз;

n_f - navigation_forward, движение вперед;

n_l, n_r - navigation_left/right - поворот налево/направо;

t_t - turn_to, повернуть к, принимает в качестве аргумента число от 0 до 3, задающее новое направление. 0 - направление оси x, далее по порядку по часовой стрелке;

n_t - navigate_to, движение к заданой точке, принимает в качестве аргумента координаты точки, в которую требуется проследовать. Сначала передвигается по оси z, затем x и y.

Для использования достаточно скопировать код в вашу программу, далее все описанное будет доступно. Если место позволяет, для удобства можно переназвать планируемые к использованию функции (аля "local turn_left=n_l"). Далее у вас будет более 3Кб под остальную часть программы.

Надеюсь, кому-нибудь будет полезно.

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

Комп знает расположение вялилок и помнит, что на них висит, дрону только говорит "неси туда/оттуда". При вялении разных ресурсов дрон еще сообщает компу тип ресурса, чтобы комп учитывал это при выдаче заданий.

Учитывая скорость и проходимость дрона, это сильно лучше, чем транспозеры или роботы. Лучше по: цене (очевидно), плотности (можно упихать гораздо больше вялилок в единицу объема), наверное, лагодромности, ибо 1 дрон + 1 комп наверняка грузят сервер меньше, чем сервер + тонны транспозеров.

P.s. Специально потратил некоторое время на проверку возможности взаимодействия дронов с вялилками, чтобы удостовериться в том, что автор не выбрал дронов не потому, что они не могут решать эту задачу. Они могут.

Общий недостаток системы в том, что оставаясь на месте, невозможно определить текущее направление робота. Требуется хотя бы одно движение. А если мы готовы пожертвовать одним движением, то один из контролеров становится лишним.

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

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

Во первых, в робота это не вставить, то есть придётся каждый раз на место работы робота ставить эту конструкцию с ограниченным радиусом действия.

Во-первых, помимо роботов есть дроны, которые не изобилуют количеством слотов, во-вторых, не всегда "робот" означает копатель, не всегда место работы означает дикую глушь вдали от населенных пунктов. В-третьих, радиус действия достаточно хорош, 400 блоков в любую сторону, если не ошибаюсь(точнее, чуть меньше, и зависит от конструкции). И конструкция одна на много клиентов. Да и построить эту конструкцию можно шустро, особенно если применить того же робота, если тебя таки интересует необитаемая глушь.

Которая к тому же на связь через плату будет тратить не мало энергии (с стандартными конфигами)

Ну не знаю, я только что проверил посыл сообщения на максимальную(400, вроде максимальная) дальность броадкастом с замером энергии до и после, разница - 20 единиц энергии. А потом сделал то же самое, но вместо посыла сигнала - os.sleep(1). Второе выжрало 10 единиц энергии. Неужто такой большой расход энергии на посыл одного единственного сигнала? P.S. Вспомнил, что у меня соляра в планшете, которым я это тестировал. Но по сути (если я не великий бог рандома) оно должно уменьшить только расход при сне, а не при посыле сигнала, так что особой роли не играет.

Во вторых, зачем нам абсолютные координаты, если робот может сам записывать в себя относительные координаты от точки установки например. Да и намного меньше это будет тратить энергии робота. К тому же робот сам сможет определять стороны света, так как эти данные будут храниться в нём и редактироваться по ходу выполнения программы.

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

Да и это будет не совсем транспортабельно для робота или дрона. Но в целом плюс в том что таки улучшение "Навигация" не будет занимать собой слот для улучшений.

Суть в том, что это почти что та же навигация(если ее не тыкать и не кормить новыми картами), только без особых дополнительных затрат на каждое новое устройство. Про транспортабельность - тот же дрон и робот могут шустро построить, робот - демонтировать, но не вижу в этом особого смысла, т.к. данная система предполагалась для использования в местах обитания человека либо для большого числа устройств.

Недавно столкнулся с тем, что апгрейд навигации, предоставляемый модом, достаточно убог, при этом он занимает компонент-слот и относительно затратен для крафта. Был удивлен тем, что еще никто не запилил систему геопозиционирования (gps), собственно, написал ее сам.

Заранее скажу, что, очевидно, ее можно улучшить, в том числе перенести работу контроллера на один из реле, но первая попытка по написанию системы, состоящей лишь из микроконтроллеров, была неудачной, возможно, из-за малого уровня компонентов, которые вмещают микроконтроллеры, но скорее всего из-за того, что я криво что-то написал (вполне вероятно, если учесть отсутствие вывода ошибок и нормального дебага). Вполне вероятно, что текущую версию можно перенести на контроллер (с минимальными модификациями для избавления от необходимости в операционной системе), и все заработает, но мне это не нужно и лень.

Использование клиентом:

Требуется беспроводная плата.

Клиент(то, что хочет получить свои координаты через gps) броадкастит одно сообщение с содержанием "gps_request" на порт 312 (можно поменять, менять надо в коде реле), через некоторое время, если сообщение достигло всех 4 реле, он получает в ответ сообщение на порт 312 (опять же, можно поменять, на этот раз в коде контроллера), содержание сообщения: строка "gps_response", число x, число y, число z; где x,y,z - координаты клиента, x и y по горизонтали, z - высота.

Использование сервером:

Сервер состоит из компьютера-контроллера с установленной OpenOS и четырех микроконтроллеров, которые я буду называть (и уже называл) "реле".

Реле должны иметь беспроводную и сетевую платы, а также процессор и память (я грузил 2 планки 1 уровня, но даже одной должно хватить). Помимо этого в них должен быть биос с программой(2 ссылка), соответствующей определенному реле. Программа должна быть отредактирована под соответствующее реле (4 переменных в начале, координаты, где (по крайней мере в моей системе) y полагается горизонтальной осью, и идентификационная строка реле, которая должна быть уникальна для конкретной системы (иначе не будет работать)). Предпочтительно на каждом реле по разу запустить wakesetter (программа, третья ссылка).

Каждый реле должен быть подсоединен к компьютеру-контроллеру кабелем, помимо этого все 4 реле должны быть некомпланарны (расположены так, чтобы нельзя было провести одну плоскость через все 4 реле) .

Компьютер-контроллер должен иметь помимо базовых составляющих, необходимых для работы, беспроводную и сетевую платы.

Для запуска системы нужно лишь запустить программу gps_controller (1 ссылка), которая разбудит реле в сети с ней и начнет выполнять свою функцию. Программа является блокирующей, т.е. не позволяет пользоваться компьютером, на котором установлена, пока сама работает.
Программа будет выводить print'ом пойманные сигналы от реле, выводить им же координаты, когда сигналов достаточно (когда все 4 реле поймали запрос); уведомлять о таймауте зафейлившихся запросов (когда запрос достиг не всех реле, программа выжидает 2 секунды, чтобы удостовериться в том, что сигналов от остальных реле на его счет она не получит, и удаляет его из таблицы обработки). Ну и, естественно, отвечать на запросы координат.

Принцип работы:

Когда реле получает запрос от клиента, оно передает свои координаты, идентификатор и расстояние до клиента контроллеру.

Контроллер, набрав 4 таких различных (от реле с разными идентификаторами) запроса, вычисляет координаты клиента и отсылает их ему.

Подробнее о вычислении: известны 4 точки и расстояние от пятой точки до каждой из них. Тогда мы можем построить по сфере на каждой точке с радиусом, соответствующим расстоянию до пятой, причем эти 4 сферы пересекутся, и пересекутся только в этой точке. Пересечение очевидно, ибо все они проходят через эту точку. Единственность пересечения гарантируется некомпланарностью центров(в трехмерном пространстве), доказывать ее мне лень, примите как факт.
Запишем гмт пересечения сфер системой уравнений (каждое вида (X-xi)^2+(Y-yi)^2+(Z-zi)^2 = Ri^2, где Ri - i-тое расстояние, xi,yi,zi - координаты i-той точки, X,Y, Z - координаты искомой(-ых) точки(-ек)), получим 4 уравнения в системе, вычтем из первого, из второго третье, из третьего четвертое, получим систему линейных уравнений на 3 уравнения, при условии некомпланарности точек и верных входных данных она совместна и имеет единственное решение, находим его через метод Крамера. Задача решена.

Код:
контроллер: http://pastebin.com/QD44ZWBv
реле: http://pastebin.com/eAzPst2s

прога, которую желательно по разу запустить (записать на биос чип, вставить в микроконтроллер и включить его) на каждом из реле, она позволяет контроллеру их включать через сообщение на модем ("gps awake"): http://pastebin.com/XijvUbB9

Скрины:

Как может выглядеть сервер:

Скрин того, что он выводит во время работы:

Скрин клиента (планшет) с простым кодом для проверки:

Следует заметить, что планшет на самом деле на блок выше, чем координата игрока, также следует еще раз для себя заметить, что координаты идут в порядке плоскость-высота, а не как в майне. Сверху код проверщика, чуть ниже зафейленная попытка, ибо сервер gps был вырублен, чуть ниже успешная попытка уже при включенном серве.

Был, когда я последний раз был на сервере.

Но либо он не работает, либо у меня руки кривые

P.S

не работает всмысле многие функции(конкретно перекидка вещей между сундуками) не работают

У одного много програм и аддонов, а другой самые крутые гуру ОС нашего сервера знают как Сибирь ( справка для не россиян : в Сибири достаточно мало разработок и вообще подробно разведанных областей из-за суровости климата).

ОС интереснее копать, чем уже сто раз перекопанный СС (однако и там не все раcкопали)

Кстати, трубы проект реда оставят или опять вырежут?

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

Чтобы кто-то в них селился и автоматом получал лут

П.С. трубами, т.к. для изменения содержимого сундука по идее чанк надо загрузить, а конвеер ГТ моментом берет предметы

Не совсем понял, что значит "обрыв", то есть если игрок перешел в другой мир, ему в какой-то момент кирдык настает?

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

Убрать карьеры и помпы - хорошая идея, без карьеров живется и так хорошо(1 робот с ЧЛ и подзарядкой от угля (генератор апгрейдом) копает гигантские территории без особой нагрузки сервера и особых затрат не подпитку энергией, чего не скажешь про карьер.), а без помпы надо будет ломать моск над правильным выкачиванием жидкостей.

Нерфить логистику - вот с этим не согласен:

Нефрить БК - куда его дальше нерфить то?

Нерфить ГТ - нехорошо получается, их и так никто не использует, теперь вообще позабудут.

А как сквозь двери приваченые лазить?

С железными работает или нет?