eu_tomat

Какие файлы OpenOS были изменены? Я не понял, как извлечь эту информацию из репозитория, а просматривать все файлы в поисках изменений выше моих сил.

Какие могут быть подводные камни? Если приостанавливать выполнение приложения, то подводные камни зависят от характера самого приложения. Может оказаться нежелательным в определенные интервалы времени прерывать управление технологическим процессом или обмен данными. Например, программа разогревает ядерный реактор, периодически проверяя его температуру и останавливая нагрев в нужный момент. Приостанов такой программы приведет к взрыву реактора. Если речь идет о приостановке экранного вывода, то при условии аккуратной реализации виртуального gpu не должно возникать каких-либо проблем.

Словом «все», взятым в кавычки, я надеялся выразить свою иронию. Но твоя новая формулировка меня устраивает: большинство программ – это не все программы, тем более с таким выделением жирным шрифтом: Многозадачность можно реализовать двумя путями: 1) Подменить load своей функцией, автоматически расставляющей по всему коду вызовы yielding. Недостатки этого способа в том, что он провоцирует повышенное потребление памяти и процессорного времени, и годится не для любого кода. Достоинство в том, что потенциально он может спасти систему от падения в TLWY из-за одного кривого приложения. 2) Подменить буквально все методы всех компонент, которые неявно выполняют уступку времени. Начать, конечно, следует с computer.pullsignal, но этого недостаточно. Например, есть программы, которые не выполняют sleep/listen, а длительно работать без TLWY им позволяют обращения к периферии. Если ты готов подменить методы всех компонент, добавляя в каждый из них вызов yielding – пожимаю руку. Еще надо не забыть, что периферия может динамически подключаться и отключаться от компьютера, и таблицы методов нужно будет подменять на лету. Предполагаю, что ты выбрал второй способ, удовлетворившись подменой pullsignal, да gpu Например, есть два редстоун-адаптера и два приложения, работающих с ними. Как ты планируешь обеспечить каждому из приложений доступ к нужному адаптеру, изолировав от другого?

Без доработки приложений этот пример последовательно выполнит сначала одно, затем другое приложение. Вряд ли @RccHD стремится к такому результату. Подменить таблицу component можно, но часть механизма обработки коллизий все равно придется вынести в приложения. Поэтому данное утверждение не соответствует действительности: «Все» программы придется сначала адаптировать к новой OS, а это уже заметный недостаток.

Запустить можно будет все программы, но работать будут не все. Если, конечно, речь идёт не о самых простых программах, написанных для демонстрации. Основные проблемы: * Кооперативная многозадачность потребует обязательной доработки запускаемых программ. А в случае подвисания одной из программ подвиснет вся система. * Для совместного использования оборудования запускаемые программы тоже потребуют доработки, а в отдельных случаях такая доработка невозможна.

Где они остаются?

@@bugmenot, поэкспериментируй со сторонами машинки. Некоторые слоты могут оказаться доступными только с определенной стороны и недоступными с друой.

Например: Мониторинг цистерн RailCraft

Говорили уже: начинай с простых примеров, так будет легче, и ничего не пригорит. Попробуй, например, сделать простую кнопку, которая красиво меняет свой вид, и больше ничего не делает. Отдельно сделай маленькую программу, которая подает какие-то сигналы на редстоун-блоки и завершает свою работу. Потом подумаешь, как объединить управление редстоуном с твоей кнопкой. Ну, и само задание надо переписать. Из него не ясно, что, и в какой последовательности должно выполняться.

Вот, значит, почему я не смог понять задание! Оно распадается!

Графен:

Не обязательно. Ошибка возникла в шестой строке при обращении к несуществующей таблице "forms" А в первой строке создается таблица "formsl". Поэтому ошибка либо в первой строке, либо в шестой. Если в первой строке таблица намеренно названа "formsl", то и в шестой строке нужно использовать ту же таблицу.

Система, которую предложил @Alex, меня, как казуальщика, почти полностью устраивает. Она повысит мой вклад в общий онлайн. В то же время я опасаюсь появления лагов в этом прекрасном мире и последующего вынужденного отказа администрации от идеи улья. Кроме того, у других игроков есть иные интересы: кто-то хочет компактный бизнес-центр, а кто-то ищет приключений и разнообразия ландшафтов. Может, имеет смысл сделать маленький мирок с компактными приватами c бутиками для торговли и складами на случай вайпа? В этом мире запретить спавн мобов и установку перерабатывающих машин. Разрешить лишь установку генераторов энергии, МЭ-сети, да компьютеров с торговыми роботами. А производственные мощности игроков желательно размещать в других мирах (не обязательно в овере), очищающихся по расписанию или в случае необходимости. Так, пожалуй, будет интереснее. Тогда и мир с магазинами-складами дольше сохранит свою стабильность.

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

Сама схема улья мне кажется слишком вытянутой. Может, лучше использовать схему из проспектов и улиц? Вот так, например: Путь на противоположный край такой карты будет короче, чем вдоль вытянутой в линию. Каждый квадрат на схеме соответствует одному чанку. Схема масштабируется блоками 32x32 чанка и соответствует одному файлу региона Майнкрафта. В каждом регионе помещается 28 сот размером 48x96 блоков. Останется только заглушить выходы с проспектов на пустые участки карты, а при расширении карты – снова прорубить проходы.

@Fingercomp когда-то отвечал про чтение NBT-тегов в инвентаре

Отлично. Живые учителя – лучшее средство для преодоления инертности мышления. Ради эксперимента даже я буду заглядывать в VK.

Ок. Если VK используется для фоток, лайков и прочей имитации социальной активности, то как продвижение группы VK поможет притоку новых участников проекта? А, кстати, почему? Мне казалось увлекательным осваивать программирование через игру. Майнкрафт идеален для этого. Юные программисты слишком серьезны, чтобы играть в игры? Или, наоборот, программирование в Майнкрафте слишком сложно для них? И не надо транслировать на стену ВСЕ топики. Я имел в виду только отдельные посты и только значимых тем и какую-то автоматизацию переноса форматированного текста. Да ладно. В ОК тем же самым: фотки, лайки и котики. Разве что, не так много пони и единорогов. Сам же говоришь: Так если этого достаточно, то и прекрасно. Можно даже пойти немного дальше и публиковать дайджест более-менее значимых тем и блогов. Вопрос в том, будет ли это кому-нибудь интересно. Даже я могу публиковать подобное: «Обычный школьник за 15 минут накопал стак алмазов. Он запустил программу...» «Наши инженеры разработали ядерный реактор на 15000 EU/t. Для его работы нужно всего лишь...» «Как не потерять нажитое непосильным трудом во время вайпа. Сейфы будут доступны в...»

Объясните отсталому человеку: зачем нужна группа в VK; почему не на OK или FB; почему недостаточно форума. Зашел сейчас в группу, потыкал в статьи (или как оно там называется). Опять же, не понимаю, зачем дублировать инфу на двух ресурсах. Почему недостаточно просто оставить ссылку? А если важен полноценный текст, то, может, проще написать транслятор из форумного кода в ВК? Или статьи должны быть адаптированы? И если да, то какова цель адаптации? Возможно, я тут не один такой, кто не понимает смысла ВК, и пользоваться им тоже не умеет. Я в свое время создал учетку только для того, чтобы голосовать за проект на Топах. На этом моя активность в ВК закончилась. Что там еще можно делать? Народ в ВК выкладывает свои фоточки, ставит лайки, повсюду всякие чмоки-чмоки, котики, пони и единороги. Почему этой публике вдруг будут интересны ComputerCraft или OpenComputers? Даже если группа будет наполнена интересным для них контентом, то как потенциальная аудитория узнает о ней? А если нужно как-то рекламировать группу, то почему сразу не рекламировать форум? Что вообще требуется делать для раскрутки группы? Как это поспособствует развитию форума? Извините за нубские вопросы, это не троллинг. Если что, можете не отвечать. Может, я в принципе не способен понять смысла ВК.

Память мне не изменила. Проверил на ComputerCraft1.75.jar -- демонстрация параллельной обработки потоков черепашками ComputerCraft -- движение вперед-назад local function f1() for i=1,20 do turtle.forward() turtle.back() end end -- вычисления local function f2() for i=1,40 do for j=1,2e+5 do k=j*j end sleep(0) end end turtle.refuel() -- затраты времени на движения, на вычисления, и на все сразу: t0=os.clock() parallel.waitForAll( f1 ) t1=os.clock() print(t1-t0) t0=os.clock() parallel.waitForAll( f2 ) t1=os.clock() print(t1-t0) t0=os.clock() parallel.waitForAll( f1, f2 ) t1=os.clock() print(t1-t0) Запустил три раза: Экономия времени очевидна. А как провернуть подобный трюк на OpenComputers?

В OC потоки выполняются псевдопараллельно. А, если мне не изменяет память, библиотека Parallel в CC позволяла выполнять вычисления во время движения черепахи. Робот не может напрямую подключиться, например, к монитору или к радару. А черепаха могла. С переходом на ОС некоторые из мобильных схем стали менее мобильными.

Самые значимые, на мой взгляд, механики IC2: * Ядерные реакторы, более тонко управляясь OC, выдают больше энергии. Большое количество схем на все случаи жизни. * Энергохранители, управляемые OC, могут компактно хранить и учитывать огромные количества энергии, что способствует более полному использованию ядерной энергии. * Фермы резины на гевее, обслуживаемые роботами, могут быть весьма производительными, занимая при этом небольшой объем. * Селекция на жердочках тоже выполняется роботами. От разработки рабочей схемы меня остановило только недопонимание всей математики скрещивания, а на эксперименты я не нашел времени. А без математики схема неоптимальная и печальная. * Пиво. Избавиться от рутины по дозировке и выдержке напитков тоже помогут роботы. Благодаря роботам пивной погребок имеет максимальную производительность в небольшом объеме. * Ограниченная производительность машин IC2 далеким от технологий людям кажется недостатком (в сравнении с Mekanism, например), но такие ограничения заставляют более тщательно продумывать производство. При большом количестве машин приходится решать задачу логистики, а при малом – тщательно планировать производство и манипулировать приоритетами. Обе задачи сильно облегчаются роботами и компами. Кажется, всё самое существенное перечислил. Остальное вполне заменяемо другими модами: руды, провода, крафты, инструменты и броня. Это слишком абстрактный список. Он не раскрывает сути задач. Да и задачи должны быть увлекательными. Помнится, были какие-то турели, которые можно было включить, а еще можно было выключить. Это скучно. А другие турели с управлением углами и моментом выстрела оказались гораздо интереснее. Так же, как магические моды дополняют технические: просто поставить оба мода. Кто-то использует Mekanism, кто-то – IC2, а кто-то использует преимущества обоих модов и сравнивает их возможности. Разнообразие путей развития делает счастливыми всех обитателей песочницы.

В сингле ничего не мешает. Но если я верно помню, конфиг сервера не влияет на переключение режимов отображения карты.

Мое отношение к модам простое: чем глубже интеграция мода с компами, тем мод полезнее. А если интеграция с компами слабая, то главное в сборке – не ставить компы в зависимость от подобных модов. И пока это условие соблюдается, мое мнение даже к самым магическим из модов будет спокойным. А вот, замену IC2 на Mekanism считаю плохой затеей. IC2 даёт интересные механики, хорошо интегрирован с OC, хорошо изучен, и при этом, судя по форуму, связка IC2-OC еще не до конца освоена. А насколько интересной будет связка Mekanism-OC, пока неизвестно. Поэтому для начала Mekanism должен не заменять IC2, а дополнять его. Что же касается карт, то Antique Atlas – штука более атмосферная и соответствующая миру магии. Rei's Minimap, насколько я помню, дико читерный с его отображением на карте игроков, мобов и пещер.

Дать бы роботам те же возможности по работе с потоками и периферией, что были у черепашек, тогда можно было бы говорить про устаревание и про ничтожность мода. Поэтому не стоит отговаривать тех, кто пишет под ComputerCraft. У обоих модов есть свои преимущества и недостатки. ComputerCraft убрали с сервера за неконтролируемое потребление вычислительных ресурсов, и лишь после этого местные игроки к нему охладели. Теперь многие из нас уже позабыли тонкости этого мода, а вникать заново уже лень. Поэтому новичкам сложнее найти помощь – вот главный недостаток мода, а не какое-то там устаревание.