eu_tomat
Модераторы-
Публикации
2 666 -
Зарегистрирован
-
Посещение
-
Победитель дней
331
Тип публикации
Блоги
Профили
Форум
Багтрекер
Магазин
Все публикации пользователя eu_tomat
-
Обнаружилась непонятная проблема на SkyTech Есть робот, добавленный в приват: /rg info Ownwes: name:eu_tomat Members: name:eu_tomat.robot,name:opencomputers Нормально выполняется robot.suck() и robot.drop(), но контроллер инвентаря сундук не видит: lua> print(require("component").inventory_controller.getInventorySize(0)) nil no inventoryАналогично для сторон 1, 3. У TraerTaer была аналогичная проблема. Заходил newbie, но проблему не вылечил. Куда копать и что сеять?
-
Для того, чтобы программисты смогли оставить споры и начали спокойно кодить. Но это невозможно, мы всё равно найдем тему для спора. К примеру: сколько бит в миллибайте?
-
Не понимаю, зачем тратятся ресурсы на обратные вызовы get/set, если вместо вызова get можно передать параметр в функцию execute, а вместо вызова set вернуть из execute нужное значение. Должно получиться что-то типа: speed = speed + loop:execute(0.1,r-c) c = c + speedс избавлением от лишнего кода. Не понимаю из примера, как управлять реактором. Какие показатели из реактора считываются, а какими параметрами реактор управляется. Не понимаю из описания, как подбирать коэффициенты. Без этого код бесполезен. Также есть мелкие ошибки, например, в строке local get=get() или if value>0 then speed=speed+math.min(value,0.1) else speed=speed+math.max(value,-0.3) end
-
Ффу-ухх... Я думал, это для наглядности и удобства пользователя, как учебный пример. Похоже, зря. Сейчас один символ кодирует 10 значений, хотя в пределе способен кодировать все 256. Потребление памяти и количество операций отличается о предельного в 25,6 раз! Это действительно лучше таблиц? Кроме того, число в таблице более, чем 8-битное.
-
@@Zer0Galaxy, а мантисса обязательно должна храниться в десятичном виде? @@Fingercomp, а насколько критично быстродействие в твоем проекте? Если оба ответа «да», то придется написать другую библиотеку. Иначе потребуется как минимум одна промежуточная строка и три дополнительных преобразования.
-
dases, почему ты считаешь это значительной трудностью? У развившегося игрока есть роботы, способные быстро свернуть постройку внутрь привата, есть возможность переместиться в окрестности второго привата, и даже есть возможность устроить засаду. Я понимаю печаль нуба, потно копающего золото на свой первый комп. Но папке, богатство которого не помещается в куб 16x16x16, точно не за что проклинать админа.
-
Осилил магию методом тыка. Оказалось, нужно сделать ШПКМ, держа процессор в руке.
-
В OpenOS используется Lua5.2. Там даже \lib\bit32.lua служит лишь для обратной совместимости с Lua5.3, внесение изменений в этот файл не дает никакого эффекта.
-
Не путай цель и вторичную пользу. Самым эффективным оружием против лагодромов является закрытие сервера, но мы же говорим об интересной игре, желательно на всём ее протяжении, от начала развития и до конца. Игра без приватов – это постоянный риск потерять всё. Преимущество будет иметь тот, кто играет с начала открытия сервера и играет много. Не успевшего развиться новичка можно будет грабить неограниченно. Сервер для PvP-шников, а не программистов. Игра с большими приватами – это спокойное развитие и возможность создавать красивые постройки и лагодромы. Игра с небольшим риском в начале, и совершенно пресная после небольшого этапа развития. Скучающие игроки находят утешение в PvP или строительстве гигантских лагозаводов. Большинство задач уже автоматизировано, писать остальные программы игрокам лень, т. к. уже имеющихся достаточно для развития. Ига с двумя мини-приватами – это возможность сохранить самое ценное и безопасно переехать на новое место в случае неприятного соседства. Объем привата достаточен для размещения небольшой линии переработки сырья и крафта необходимых вещей. Развитие новичка происходит с умеренным риском во время вылазок за сырьем. Окрепшие игроки, желающие расширить свое производство, тоже получают адреналин, защищая свое незаприваченное производство. Причем, развлечение есть как для любителей PvP, так и для программистов, как со стороны атаки, так и защиты. По-моему, хорошее сочетание безопасности и динамичности. Объясни, dases, почему игроки проклянут админа, рискнувшего ограничить объем приватов.
-
Вот, и хорошо. Пусть бегают, чистят карту от лагодромов, админам спокойнее будет. А игроки постарше не ставят гектары солярок. У них на каждой кухне стоит ядерный реактор, дающий и свет, и тепло, и поле для экспериментов.
-
Всё классно в новом робике кроме двух моментов: 1) Труднодоступность золота, которое наряду с железом и редстоуном является незаменимым сырьем в производстве роботов. Без алмазов поначалу обойтись можно, без золота – никак. Пустыню же еще потребуется найти, а роботов хочется использовать как можно раньше и независимо от точки спавна. 2) Единственный приват делает рискованным переезд на новое место. Два привата и, например, квантовый мост смогут значительно облегчить переезд в новый дом. При этом общий объем всех приватов я предлагаю сделать небольшим, скажем, 16x16x16. Смысл маленьких приватов в том, чтобы сберечь в них самое ценное, а гектары ветряков, жердочек и дубовую рощу размещать за предалами привата. Тогда автоматизация быстрого сворачивания/разворачивания производственных линий станет такой же важной, как и на хардкрафте. Но не будет страха потерять всё. В чате уже засветились желающие играть вообще без приватов. Я эту идею не разделяю, т. к. на мой взгляд она мешает и развитию и автоматизации. Но большие приваты нужны разве что для архитектурных экспериментов, которыми на сервере не часто увлекаются. Зато увлекаются полями из солярок или жердочек. Вот, и пусть это лагающее добро останется без защиты. И серверу хорошо, и гриферам весело. Короче, все мои хотелки: * Спавн золотой руды не ограничивать; * Разрешить два привата; * Суммарный объем приватов игрока ограничить 4096 блоками.
-
А разве сложно написать решалку для быков и коров, и пользоваться ею всем сервером?
-
@@Doob, А почему тебя не заботит то, что исходящий поток содержит символы за пределами ASCII? Вдруг пользователь не в той кодировке скопирует? Правильным было бы либо разрешить все символы, либо везде ограничиться печатными символами ASCII. Что-то я еще более запутался. В чем смысл жать исходники начальным размером менее 1КБ? Проблема, как правило, впихнуть в BIOS код более 4КБ. Давай разберем на примере. Есть библиотека filesystem из OpenOS: http://pastebin.com/xfM5yrsu оригинал filesystem.lua, 13457 байт http://pastebin.com/S1uscQ8t результат работы минификатора, 8615 байт До какого размера жмет твой компрессор оба этих кода, и каков размер декомпрессора?
-
А где чудодейственный math.pow() для подключения всей математической мощи компьютеров?
-
Точно. gsub в твоем алгоритме эффективен. Зациклился на классических алгоритмах. Кстати, они мне кажутся более уместыми, как по причине большего объема словаря, так и по всеядности. Ну, ладно, твой выбор понятен. Мне непонятны условия задачи. 1. Сначала ты говоришь об ASCII, потом говоришь, что не используешь управляющие символы ASCII, т.к. они повреждают текст. При этом перевод строки и табуляция текст не повреждают, хотя и являются управляющими символами. Какие символы во входящем потоке являются допустимыми для твоего алгоритма? Определившись с ними, можно будет еще до сжатия проверить поток на запрещенные символы. 2. Также не ясно, какие символы допустимы в исходящем потоке. 3. Ты сравниваешь сжатие своим алгоритмом с deflate. На каких данных проводилось тестирование? Насколько объемен входящий код? Насколько я понимаю, степень сжатия заметно уменьшится при недостаточном объеме словаря.
-
Потому что Т.к. Lua не позволяет просто заменять произвольные символы в строке, приходится часто использовать конкатенацию. От этого сильно страдает производительность. Казалось бы, для ускорения записи в файл следует набирать максимальный буфер, изредка производя запись. На деле же оказывается, что десяток конкатенаций одного символа с длинным буфером обходится дороже одной операции записи в файл. Я не проводил глубокого анализа, но интуитивно пришел к выводу, что скорость конкатенации, по крайней мере в OpenComputers, падает с увеличением длины результирующей строки. Уменьшить затраты помогает двоичная конкатенация. К примеру, нужно склеить символы 1 2 3 4 5 6 7 8. Имеем строки: 1, 12, 123, 1234, 12345, 123456, 1234567, 12345678 при линейной конкатенации и 12, 34, 56, 78, 1234, 5678, 12345678 при двоичной. Разница в длинах заметна на глаз даже для итоговой строки длиной в 8 символов. Код, выполнявшийся на двух планках памяти T3.5, говорит сам за себя: -- тестирование конкатенации строк local time = require("computer").uptime -- линейная конкатенация local time0 = time() local s="" for i=1,1024*32 do s=s.."." end print(string.format("time: %.2f sec", time()-time0 )) -- 8k: 0.15-0.25sec, 16k: 0.55-1.05sec, 32k: 1.5-2.95sec, 64k: TLWY os.sleep(0) -- для избежания TLWY -- двоичная конкатенация local time0 = time() local tbl={} for i=1,1024*128 do tbl[#tbl+1]="." end while #tbl>1 do local tb_={} for i=1,#tbl-1,2 do tb_[#tb_+1]=tbl[i]..tbl[i+1] end tbl=tb_ end local s=tbl[1] print(string.format("time: %.2f sec", time()-time0 )) -- 128k: 0.30 sec, 256: not enough memory
-
Чем будет ограничена продажа бедрока?
-
Интересная сборочка. Смущает лишь отсутствие приватов. Возможно, это вообще не помеха, если разберусь с этим: Что такое "именное эндер пространство"? Как что-то отправить в него и взять из него? Как пользоваться адресами "ник[0-4096]"? Что за цветные эндер-сундуки? Какими модами всё это реализовано?
-
Контроллер инвентаря нужен как минимум для перемещения предмета в слот инструмента (inventory_controller.equip()). Кроме того он позволяет не вытаскивать всё содержимое сундука, которое, кстати, может и не поместиться в инвентарь робота, в поисках нужного предмета, а проверить слоты сундука (inventory_controller.getStackInSlot(side,slot)) и взять из него нужный предмет (inventory_controller.suckFromSlot(side,slot,count)).
-
А в чем новизна геймплея? Майнить любую понравившуюся криптовалюту и сейчас никто не мешает. Майнить UU можно скриптом для голосования. А майнить ресы роботами только ленивый не пробовал.
-
А Doob сделал зрение Полезное применение камеры из Computronics
-
Опасаясь дальнейшего развития дефолтофобии, поддержу оффтоп: Есть множество оттенков дефолтофилии. К примеру, я тоже хочу видеть собственный генератор в OpenComputers, чтобы сыграть в ваниль + OC. Но такие сборки как раз и являются редким исключением из правил. Возможно, их распространение сможет убедить Сангара добавить в мод собственный генератор, чему я был бы рад. Но не сильно, т. к. меня устраивает IC2 в качестве компромисса. OC без энергии вполне играбелен, хотя и становится более скучным. Но точно так же становятся скучными и роботы, апнутые в 100 раз по энергии. Дефолт хорош не потому, что он идеален, а потому, что в большинстве своем правки конфигов не решают противоречий, а либо отодвигают их, либо порождают новые. Классические примеры: 1) Робот кажется какашкой, т.к. быстро разряжает бур, или не может за один раз обойти весь карьер. Можно подправить конфиг, но теперь какашкой становится программа, т. к. в ней не предусмотрена подзарядка робота или инструмента. На карьере большего размера программа всё равно споткнется. И это при том, что никто не мешал роботу менять инструмент и добираться до зарядки или даже самостоятельно развертывать зарядную станцию в удобной для него позиции. 2) Робот кажется какашкой, т. к. быстро теряет заряд при пользовании геосканером. Но робот, занимающийся геологоразведкой, не обязан быть вдобавок ко всему еще и рудокопом. Проблему можно решить, забив все слоты аккумуляторами и вовремя подзаряжаясь. Но можно подкрутить конфиг, совместить геолога с шахтером и не парить себе мозг согласованием их работы. Но тогда зачем нужен OpenComputers, если BuildCraft позволяет вообще не заморачиваться? 3) Геосканер кажется какшкой, т. к. не различает плотности руд в десятке блоков от него. При этом никто не мешает подобраться поближе к исследуемой жиле, но проще же подкрутить конфиг. В результате появляются программы, требующие максимального объема памяти, и в цикле перебирающие огромный массив данных. 4) Какашкой могут показаться и wi-fi карты, не позволяющие отправлять сигналы на дальние расстояния. И я бы понял отклонение от конфига, если бы применение wi-fi карт на сервере ограничилось лишь имитацией радио. Но на обычном шахтерском сервере такая беспроводная связь превратится в чит, а OpenNet выродится до банального роутера на весь сервер. 5) Какашкой кажутся дроны, теряющие заряд через несколько минут работы. Это, конечно, проблема для свинолёта, и при отсутствии иного транспорта правка конфига оправдана. Но долголетающий дрон переводил гриферство из разряда искусства в простую забаву, а также способствовал расширению дроноферм без усложнения программ для них. При таком раскладе на computercraft.ru дефолтофилия выглядит предпочтительнее дефолтофобии. Особенно после того, как роботы сначала апаются, чтобы упростить их программирование, а потом усложняется их крафт, чтобы было не так читерно. И это усложнение требует не более тщательной проработки алгоритма, а большего присутствия в самой игре, что для computercraft.ru выглядит очень странно.
-
Дефолтность или кастомность конфигов – тема для обсуждения. Но предложение в обязательном порядке выдавать информацию о прослушиваемых портах – вредительство. Это не стандартизация, а дыра в безопасности. В реальных сетях ping не дает информации об открытых портах. А то, с каких адресов доступен открытый порт, решает фаервол. Фаервол разберется, чей ping-запрос достоин ответа, а чей нет, и операционка не откликнется даже на «стандартный ping», не стоит так уповать на него. И сниффер тоже не нужен: всё тот же фаервол залогирует, если твой запрос так важен.
-
Как обычно и случается, 100500 бочонков закроют проблему водоснабжения. Интересно, насколько сильно они будут лагать во время дождя. Самая интересная идея. Захотел послушать эфир – надел очки, подключил нужных абонентов. Ненужных выключил. Поменял очки на алмазную шапочку – медитируешь в полной тишине. Вопрос лишь в том, многим ли это понравится, и можно ли смириться с потерей игроков, не желающих перестраиваться. На мой взгляд, побуждать игроков к использованию OpenComputers следует не столько ограничениями привычных вещей, сколько созданием новых возможностей для роботов. К примеру, если устал от общего чата, то отключил его, надел очки, в которые чатбокс транслирует лишь нужные тебе сообщения. А если флудер желает пообщаться с приличным игроком, то сам надевает очки и тщательно фильтрует базар, дабы не оказаться в черном списке.
