SergOmarov

Хз, вроде открытый, ща...

Открыл.

Оптимизированный ридер мира готов)

Попробую сделать.

Извиняюсь, но ты вообще о чём думаешь???

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

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

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

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

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

А зачем тогда они поставили мод? А я знаю зачем: они думают, что на проекте никто не будет строить лагодром. Да и AE с парой авто-рецептов несильно нагрузит сервер.

В очередь

Да не трудно. Нужно просто получить его. Посмотреть реально цифры.  Вика дает приблизительную зависимость. На 100-м уровне уже огреха в 4000 ед опыта. Там немного не точные данные и  получены как-то экспериментально. Лучше для перестраховки трусов самим получить данные и посмотреть, где там линейная зависимость где квадратичная и пр.

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

Я имел в виду в исходниках игры покопаться.

Не заметил сообщения от Нео)

Если хочешь, чтобы пригодилось, и еще долго писать не зря - переноси на OC.

Версию для eeprom доделал, теперь перед записью происходит тест переданного кода, если положительный, происходит запись.

Тесты еще не проводились.

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

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

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

Каждый будет проводить для себя собственную грань)

Если не знал, то чем выше уровень, тем больше опыта он содержит.

А это так трудно решается?)

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

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

Типо, не реагирует?

А, она в виде той плоской фимгни жителя изобразила)

Я что-то не понял, что это такое?

А почему возникает проблема с уровнями?

А как камера реагирует на сущности?

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

 

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

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

Спасибо, а я вот дня 2 назад на эту вики заходил, там было указано только 2 аргумента=/

load('код в виде строки', '', '', env)

передается код, 2 пустые строки и окружение, чем являются 2 пустые строки?

Есть код, в виде строки, его нужно запустить, указав окружение. Как это сделать в bios?

И еще хотелось бы узнать про функцию load, на вики написано, что она изменена, но нет подробного объяснения.

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

Запутанные решения получаются в разных случаях, например:

1) Человек не умеет адекватно выразить свою идею с помощью имеющихся инструментов.

2) Человек выбрал неадекватный инструмент для решения своей задачи.

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

4) Реально сложные задачи. Почти всегда в разработке таких задач принимает участие множество людей, и никто по отдельности неспособен охватить задачу полностью.

 

Про сложность и простоту пояснил. Теперь скажу несколько слов об эффективности. Давай зададимся вопросом. Кто будет сильнее нагружать сервер: значительную часть времени находящийся с состоянии сна робот, по расписанию подъезжающий к сундукам и печкам для их загрузки и выгрузки или же МЭ-система, каждый тик проверяющая все подключенные к ней объекты, в какой из них и что нужно положить и откуда взять? AE эффективен только в сравнении с БК трубами, мгновенно перемещая предметы.

 

Хочешь быть инженером?

Так строй хорошие системы, будь инженером, б***ть!

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

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

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

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

Смысл в том, что если дрон попытается пройти сквозь блок жидкости, то он выключится.

Пример защищённой двери:

Ты правильно сделал, взяв фразу "побыть инженером" в кавычки, потому что будучи настоящим инженером ты бы не городил сложных и запутанных схем на основе работающего на магии AE, а собрал бы простую и эффективную на основе прозрачно работающих компьютеров

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

Тема актуальна, нет?