eu_tomat

Quant, люди на форуме иногда жалуются, что программировать в Майнкрафте уже нечего, что все программы написаны. А ты такую идею бросил, а с получением вайта вообще на флуд переключился. Эээххх.

Теперь понял, как ты сжимаешь: вместе с индексом цвета пересылаешь количество символов.

Но откуда взялось 5, ты так и не пояснил.

 

Картинка в пещере не шумовая. В ней должно быть эффективным дельта-кодирование.

 

::a::robot.use()goto a -- 22 символа

А вообще, это не работает, я замерял - кпд меньше 100%

 

Ах, вот, зачем ты спрашивал в чате про разное время выполнения в разных циклах! Здесь копипаст вне конкуренции по скорости. Правда, размер программы большой. Но можно же и RAID подключить для такой задачи.

Я теперь знаю, зачем в ДЦ столько компов.

Не понимаю, о чем идет речь:

• 46 индексов для одного символа Имеется в виду – возможных индексов?
• для сжатия берем 46 для двух идущих подряд, 46 для 4х, 46 для 8, 46 для 16... Как берем, что делаем?
• Следовательно, в общем имеем 46*5 = 230 индексов Откуда появилось пять?
• процент сжатия равен... откуда взялась такая формула?

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

r = require("robot") while true do r.use() end;

Ты разгласил главный секрет нашего сервера.

Теперь mini_bro станет одним из нас.

А я короче сделаю! У тебя целых 47 символов!

while true do require("robot").use() end -- 40 символов

 

Зато ты тратишь время на вызов require(). Ты не труЪ-лагодромщикЪ.

Теперь другая проблема, стоит вообще сжимать? Можно же обойтись кодированием, т. к. сообщения передаются моментально. Сжатие и разжатие отнимают время.

Отличный вопрос.

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

 

Главное, не передавай избыточную инфу. Ты же сейчас передаешь цветовые индексы, а не сами цвета?

Если вы когда-нибудь играли в Dota 2 или CS GO то вы знаете что там есть система сундуков или кейсов. Проект уже почти готов, но мне нужна помощь в создании социальной части программы. Планируется: 1.Торговая площадка для вещей выбитых из сундуков. 2.Система друзей 3.Магазин предметов.

• Я, например, не играл ни в то, ни другое. Опиши своими словами, что за систему ты строишь, и как она должна работать.
• Что такое "социальная часть программы"?
• У нас на сервере уже не используется ComputerCraft, и все его фанаты теперь изучают OpenComputers.

Скриншотов много, но о чем идет речь, не ясно.

Я спорю, только потому, что ты утверждаешь что AE - скучный мод. Да, он может со временем надоедать, но это не значит что его сразу на свалку. Если тебе он наскучил, это не значит, что и всем. О своей позиции скажу так: мне гораздо интереснее юзать AE2 вместе с OC, но новичкам она может нравиться и в чистом виде, что я и пытался донести(как раз новички, обычно, и строят лагодромы).

Теперь я думаю, что споришь ты потому, что невнимательно читаешь.

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

 

А теперь приведи мне цитату, где бы я предлагал выкинуть мод на свалку.

 

P.S.: Читай внимательно.

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

Я не понял, что там ↑ вообще обсуждают.

У нас было четыре пресса, высекатель, стак молекулярных сборщиков, алмазный сундук, наполовину заполненный ячейками памяти и целое море разноцветных кабелей, шин и сборочных процессоров...

Твоя очередь флудить.

Два замечания по теме:

1) Название темы не соответствует вопросу. Не играет роли канал передачи данных. Вопрос в том, как сжать данные.

2) Зачем сначала преобразовывать карту высот в цветное изображение, а потом его сжимать, если можно сжать первичные данные, и уже в конце декодировать в цветную картинку? Конечно, если цветопередача приемника ограничена, имеет смысл еще до передачи произвести огрубление данных, но желание передавать именно картинку, создает лишние проблемы.

 

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

 

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

Интересно.. мне Fingercomp предложил сделать проще: У меня есть набор из n цветов в разных таблицах, я для каждого цвета создаю индекс в виде одного символа, т.е. чтобы мне передать изображение алмазного монитора 160*50 - оно принимает вид 8 килобайт, но я использую квадратное окно, следовательно у меня абсолютный максимум для алмазного монитора = 4950 байт.

Собственно, я предлагаю то же самое.

Преобразуем карту высот в n уровней и передаем именно ее.

Если сжатие недостаточно, можно использовать дельта-кодирование.

Всё очень просто.

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

Да, собственно, поэтому я начал спорить с Томатом)

Серж, ты теперь уже и меня ни к месту упоминаешь. Мои утверждения не противоречат утверждениям Фигнера. Перечитай свой первый пост, где ты начал спор со мной. Я напомню для наглядности:

 

eu_tomat: Система транспортировки в AE — скучная.

SergOmarov: AE нескучен, он дает возможность "побыть инженером", составляя сложную, запутанную схему обработки предметов

eu_tomat: стремление к запутанным схемам при наличии других простых и эффективных — враг хорошего инженера.

SergOmarov: Запутанное — не всегда непонятное. Простое — не самое эффективное.

eu_tomat: Запутанное — почти всегда непонятное. Усложнять иногда нужно, но только по необходимости. На нашем сервере нет задач, требующих запутанных решений.

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

eu_tomat: Твой пример как раз опровергает применение сложных схем на AE. И ту схему ты сам назвал сложной и запутанной. Давай не обижать логику.

SergOmarov: Нелогично использовать медленного робота взамен мгновенной AE-сети. Я понимаю, что логистика на AE лучше логистики на роботах.

eu_tomat: Чтобы понимать, надо сравнить. Мгновенность AE основана на магии, создает лаги, да и мгновенность перемещения не нужна. Даже медленный робот успешно решает задачу логистики.

SergOmarov: Мгновенность очень нужна, особенно, если нужно скрафтить что-то большое. Администраторы, поставив мод AE, заранее одобрили мой подход, лагов не будет.

eu_tomat: Мгновенность перемещений робота не нужна, а при выполнении крупного крафта — особенно. Администрацию не приплетай, т.к. лагострой может привести к удалению мода или скорому вайпу. Кстати, после вайпа гораздо быстрее поднимается полноценная логистика на роботах, чем на AE.

SergOmarov: Не упоминай о нагрузке на сервер, тогда не буду ссылаться на администрацию.

eu_tomat: Администрация не побуждает тебя к лагострою. Наоборот, изобилие лагосхем на сервере может привести к удалению мода.

SergOmarov: Как это не побуждает? Зачем тогда мод нужен? Да и не собирался я строить «сложные и запутанные схемы».

Fingercomp: Поставили потому, что мод дает полезные возможности хранения, перемещения и автоматизации.

SergOmarov: Я не дурак, чтоб строить лагодром. А с Томатом спорю, чтобы разъяснить ему пользу мода AE.

 

И если ты все еще продолжаешь спорить с Томатом, читай по кругу.

 

Серж, на самом деле никому не интересно, почему ты споришь. Все хотят знать, какой позиции ты придерживаешься. Если ты не лагодромщик, то не строишь «сложные и запутанные схемы на AE», и значит видишь, насколько просто выглядят твои схемы в сравнении с реальной логистикой. Захочешь ли ты после этого сравнения спорить с тем, что «система транспортировки в AE — скучная»? Со мной спорить можно, это возбуждает. Но зачем спорить с логикой?

Тогда не надо было затрагивать вопрос о нагрузке на сервер.

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

Пущай в ДЦ поставят и КИНО крутят.

Крутить можно, но кто будет смотреть?

Или "не будет смотреть — отключим газ"?

Это у тебя готовая "рекламная доска" (Доска обьявлений)

Вау! Это круче сайтов в OpenNet. За компом сидеть вредно, а прогуляться до домика Программиста — одно удовольствие. Буду туда почаще захаживать.

Предоставленная идея о расположении саплингов с одноблоковым удалением друг от друга

Кстати, скорее всего, имеет смысл ставить деревья и на большем удалении друг от друга, чтобы уменьшить взаимное перекрытие листвы. Сплошная посадка деревьев хороша только для максимизации выхода древесины с единицы площади.

Что-то это BSOD напоминает настоящий только цветом. И то, отдаленно.

Мне интересно: А для изображения более-менее реального BSOD'а места на диске не хватило?

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

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

 

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

 

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

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

На счет нагрузки на сервер: если администраторы поставили AE2, то они считают, что сервер может справиться с нагрузкой.

Что еще за потребности, требующие мгновенности? Скрафтить потерянную броню? На этот случай всегда лежит запасной комплект брони и инструментов в enderchest. Мгновеннее некуда.

 

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

 

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

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

 

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

 

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

Ах тыж подлец

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

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

На вику постить не смогу, у меня по какой-то непонятной причине очень провисает gamepedia.

Следующий квест: пройти в вайт-лист на gamepedia.

А что за готовое решение? Я тоже не знал. И GPS я не пытался портировать, и код его никогда не видел. Как увидел твою тему, сразу она мне понравилась, и я тоже взял карандаш и тетрадь, написал изначальные уравнения и получил простые формулы для нахождения координат.

 

Ты хотя бы сначала на бумаге рисуешь. Это гораздо лучше бездумного спонтанного кодинга.

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

 

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

 

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

 

Не проще ли было бы пойти от задачи, а не от метода?

 

Я, наверное, буду повторять это часто:

1) Усложнение решения без необходимости приводит к снижению его эффективности и затрудняет его восприятие.

2) При решении инженерных задач наиболее эффективен проблемно ориентированный подход.

 

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

Интересно... Триангуляция? Я пробовал - дрон делает круг, находит примерный вектор и летит к источнику сигнала... и промахивается даже при неподвижном источнике.

Конечно, триангуляция. Со времен станций GPS на ComputerCraft ничего не изменилось. Разница только в том, что тогда у нас стояли четыре неподвижных компьютера, а черепашка, определив расстояние до них, могла вычислить свои координаты. А сейчас дрон, слегка изменяя свои координаты и определяя в этих точках расстояние до неподвижного источника сигнала, точно так же способен вычислить свои координаты.

 

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

 

Например, есть у нас начальная точка с неизвестными координатами x,y,z, и известным расстоянием r0 до источника сигнала

Теперь смещаем дрона на +1 по оси x и по радиосигналу определяем новое расстояние. Назовем его rx.

 

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

 

Почему твой дрон промахивается? Либо играет роль предыдущий пункт, либо с уравнениями что-то не то.

 

Попробуем решить наши уравнения:

r0^2 = x^2+y^2+z^2

rx^2 = (x+1)^2+y^2+z^2

Раскрываем скобки во втором:

rx^2 = x^2+2x+1+y^2+z^2

И переписываем его так, чтобы было похоже не первое:

r0^2 = x^2+y^2+z^2

rx^2 = x^2+y^2+z^2 + 2x+1

Далее выносим (x^2+y^2+z^2) по одну сторону знака равенства.

x^2+y^2+z^2 = r0^2

x^2+y^2+z^2 = rx^2 - 2x-1

Получаем новое уравнение:

r0^2 = rx^2 - 2x-1

И тут становится несложно вывести, что

x = (rx^2 - r0^2 - 1) / 2

 

При этом следует помнить, что мы вычислили координату в начальной точке. А сейчас мы находимся в (x+1,y,z). Оставшиеся две координаты вычисляются аналогично, тут главное аккуратно посчитать все суммарные перемещения, которые мы выполнили для замера сигнала, иначе заблудимся.