Перейти к содержимому

whiskas

Пользователи
  • Публикации

    392
  • Зарегистрирован

  • Посещение

  • Победитель дней

    17

Все публикации пользователя whiskas

  1. да дерево это понятно что круто. Но я думаю легче будет сделать хеш таблицу
  2. я про то дерево. Что дерево в 1 файле не смогу хранить иза того что оно не поместится в ОЗУ при сериализации. А твой вариант с постоянно открытым файлом и записивать посекторно думаю может сработать
  3. Он не поможет. Ибо в 1 файлике хранить это все не смогу. А в многих файликах идет по 1 тику на открытие.
  4. можна пример? Ато не доконца понимаю что это означает
  5. whiskas

    Как это пофиксить?

    Хотелось бы узнать ошибку.
  6. В далеком прошлом я начал делать хранилище вещей на ОС (пародия на АЕ2). Для этой задачи я хранил все данные в оперативной памяти. При увеличении размера хранилища у меня начало падать по нехватки памяти. Я решил выгружать все данные в различные файлики и так у меня родилась база данных (пародия на бд). Хранил каждый вид предмета в отдельном файлике, вроде все кул но тут идет большое но "открытие каждого файлика тратится 1 тик" и когда файликов много и тебе нужно найти какой-то определенный файл по какомуто филду то это будет длиться вечность. Для этого я перенял идею баз данных и создал индексы. Индексы у меня были самые примитивные, это тупо таблица ключ значение. Я начал добавлять индексы по всех полях по которых ищу. Все вроде работало и хранилище стало намного больше. И тут я долго ним пользовался, файликов поднакопилось и программа опять начала падать по нехватки ОЗУ. Индексы слишком большие и не влазят в память. А у меня в планах еще увеличивать хранилище. Так вот к чему я веду. У кого-то есть идеи как можно хранить индексы поярче в ОС? Меня там ограничивает что почти каждая команда требует 1 тик. Ничего не лезет в голову как решить эту проблему.
  7. Да построить такое и соеденить в 1 сеть это простая задача. Сложнее задача потом искать по такому хранилищу. Ибо памяти не хватит хранить все в ОЗУ
  8. Программа может быть реализованная только вместе с компом. Нужна связка комп + робот. Комп нужен для того что б узнать гены растения с помощу адаптера ибо робот не умеет пользоватся анализатором растений. 1) Адаптер можна подключить к грядке (только с модом openperipheral). Потом через адаптер можна узнать гены посадженого растения. 2) Там есть баги. После каждого действия робота над грядкой (посадка, ставление грядки, ломание грядки) лучше всего ставить os.sleep(2). Я делал когдато себе такую прогу и когда он работает с грядками без sleep то робот иногда пропадает или его мета слетает или жёдрочка моментально ломается. 3) Робот дюпает семена при посадке на жёрдочки. Семено садится но у робота не забирается. На некоторых серверах на это стоит фикс но в ванильном ОС фикса нету
  9. У меня вроди работала. Она может отправлять любую команду в консоль.
  10. Этот банкомат написан админами McSkill. Чтобы его заюзать нужно заменить их opencb на дебаг карту и также заменить команды их плагина на команды FeEconomy. Никакого доступа к БД не нужно делать ибо плагин сам имеет доступ /fe (name) - This will display the balance of the user, the (name) is optional. /fe grant [name] [amount] - This grants a player an amount /fe deduct [name] [amount] - Deducts money from a player /fe set [name] [amount] - This sets a players balance to an exact amount /fe create [name] - This creates an account with the default holdings. /fe remove [name] - This permanently deletes an account. /fe clean - This removes all accounts with the default holding. /fe reload - This reloads the Fe config, does not work for database changes.
  11. opencb это вроди самописный командный блок. Можна заменить дебаг картой
  12. Прогнал на 17 конденсов. Результат тотже. Теоретичиски с нейтронами может получится больше. Но увы пока что я не могу это обсчитать. Нужно думать как оптимизировать. 4360 1 2 1 1 2 1 1 1 2 1 2 1 1 1 1 2 1 1 1 1 1 2 1 1 1 1 2 2 1 1 1 1 2 1 1 1 1 1 2 1 1 1 1 2 1 2 1 1 1 2 1 1 2 1 4360 1 2 1 1 1 1 2 1 2 1 1 1 2 2 1 1 1 1 2 1 1 1 1 1 1 2 1 1 1 2 1 1 2 1 1 1 1 1 2 1 1 1 1 1 2 2 1 1 1 2 1 2 1 1 4360 1 1 2 1 1 2 1 1 2 2 1 1 1 1 2 1 1 1 1 1 1 2 1 1 1 2 1 1 2 1 1 1 2 1 1 1 1 1 1 2 1 1 1 1 2 2 1 1 2 1 1 2 1 1 4360 1 1 2 1 2 1 1 1 2 2 1 1 1 1 1 2 1 1 1 1 1 2 1 1 2 1 1 1 2 1 1 1 1 1 1 2 1 1 1 1 2 2 1 1 1 2 1 2 1 1 1 1 2 1 4360 2 1 1 2 1 1 2 1 1 1 1 1 2 1 1 1 1 2 1 2 1 1 1 2 1 1 1 1 1 1 2 1 1 1 2 1 2 1 1 1 1 2 1 1 1 1 1 2 1 1 2 1 1 2 4360 2 1 2 1 1 1 1 2 1 1 1 1 1 2 2 1 1 1 1 2 1 1 1 1 1 1 2 1 1 1 2 1 1 2 1 1 2 1 1 1 1 1 2 1 1 1 1 2 1 2 1 1 1 2 4360 2 1 1 1 2 1 2 1 1 1 1 2 1 1 1 1 1 2 1 1 2 1 1 2 1 1 1 2 1 1 1 1 1 1 2 1 1 1 1 2 2 1 1 1 1 1 2 1 1 1 1 2 1 2 4360 2 1 1 1 2 1 1 2 1 1 1 2 1 1 1 1 2 1 2 1 1 1 1 2 1 1 1 1 1 1 2 1 1 1 1 2 1 2 1 1 1 1 2 1 1 1 2 1 1 2 1 1 1 2
  13. Чесно говоря отфанаря. запускал от меньшего количества к большему. До 14 (не включая) ниодна схемка не складывалась. Тоесть с 13 конденсаторами нельзя запустить реактор (без пустых клеток и без других компонентов). На 14 конденсаторах я получил много вариантов как можна раставить конденсаторы что б получить 4360. Но что б навернека не прогадать решил увеличить еще на 2 макс количество конденсаторов и ничего не изменилось. Потом я еще попробувал добавить в расчет нейтрон. Схемки с 14 конденсаторами и нейтронами очень долго обчисляются (не смог оптимизировать для расчета). А с 13 конденсаторами и нейтронами получалось максимум 4340. Это зависит от алгоритма который ты юзаеш. В моем случае все варианты создаются рекурсивно. Я начинаю запихать компоненты в реактор (в масив) по 1 компоненту и проверять нормальная ли эта часть схемки (не бомбанет лм или много конденсаторов уже заюзал) А условие выхода из рекурсии это то что в всех клетках стоят компоненты и тогда обчисляется сколько енергии дает эта схемка. Большенство вариантов уже было откинуто рекурсией и сюда приходят только рабочие схемки. Получается иза грамотно написанной рекурсии у меня в памяти в любой момент хранится только 1 инстанс реактора (1 схема). А большенство вариантов у меня даже не разсматривается иза того что большенство вариантов отрезаются еще в начали рекурсии. Поэтому у меня получается перебрать все варианты. (зачем мне проверять +100500 вариантов схем реактора если у меня в начале схемки уже бум).
  14. Только варианты с конденсаторами и счетвер ураном. Обычное i5-8250u При создании всех вариантов я откидывал заведомо провальные варианты еще в начале рекурсии и их не нужно было обсчитывать. Откидывал такие варианты (если около урана еще 4 урана это 100 проц взрыв), Если использовано больше 16 конденсаторов то эта схема точно не даст так много энергии. И еще парочка. В итоге после всех манипуляций я получил результат за меньше чем минуту
  15. Запустил я прогу для перебора всех вариантов (4360 это макс). Прога перебирала только с ураном и конденсатором (без других компонентов)
  16. для работы с улеем нужно подключать к ванильному блоку улия. Не к трансформатору, не к инкубатору. К ванильному. Да и компонент называется не "items"
  17. Я сделал чтото подобное. Оно скорее non-sql база данных ибо релейшенов нету. Но все хранится в разных файликах и даж индексы есть для ускорения роботы. Но оно немножко недоработаное и там нужен жёсткий рефакторинг потому её нету в паблике.
  18. Да и еще прийдется делать их куча а каждый будет забирать -1 от общего количества компонентов.
  19. Ты шариш что оно делает?. Просто если заменять на него тебе прийдется их сделать +100500 ибо в 1 оч мало вещей лезет
  20. Ну да можна выгружать в разные файлы одну таблицу с ключами. И потом просто мапить по тех ключах. Тоесть получится что при загрузке будет использоват патерн FlyWeight. И получается большенство обьектов будут тежесамые. Просто сылка в таблице будет дублироватся. А при изменениях тех таблиц не изменять тужесамую а создать другую и заменить
  21. Как многим извесно я уже разрабатывал систему хранения с рекурсивным автокрафтом. Все работает кул и тд. Но когда приходит время к маштабирование то памяти в ОЗУ не хватало. Пришлось запилить какую не какую БД на файликах. Каждый айтем это отдельная строчка и в енм хранятся все метаданные и его расположение в всех сундуках. После того как запилил БД появились очень жёсткие проблемы с временем ожидания которую смог решить добавив индексы по количеству та название. Долгое время все работало нормально пока я не захотел к системе подключить 69 сундуков с емкостю 400 слотов каждый. После этого у меня начали падать ероры при сериализации ибо сериализация большых обьектов очень ресурсозатратна. А ерора падала на рядочек с пустыми слотами (ибо после постройки системы все слоты у меня пустые) тоесть апликуха падала по причине что 1 ров очень много занимал памяти. Эту проблему я решыл тем что переводжу индексы слотов из отдельных таблиц в 1 путем конкатинации их индексов. Тоесть вместо слотов с одинаковыми предметами и количеством к примеру слоты [1][2][3][4][5][6][9][10] я трансформировал в ["1-6,9,10"]. В некоторых случаях экономия огромезная (когда сундук пуст вместо 400 таблиц я имел только одну ["1-400"]. И сейчас вроди все работает норм но чуствую что система на пределе.
  22. Я знаю что. В основному реакторы и механизмы. Просто я знаю о каком он сервере говорит. Там потому и ввели ограничение на реакторы ибо их ставили по 200 штук в чанк
  23. Дак 16 иза вас лагадромщиков. ТПС падает иза таких людей
  24. а с помощу ОС ваше изи. 1) Ставиш воронку. 2) закидуеш в каждый слот по 1 предмету (валюта) 3) когда в слоте больше чем 1 валюта то что б транспоузер перемещал их в ме или другой сундук. p.s я б не рекомендувал юзать транспоузер для таких мелких задач ибо он зачастую не может работать в приватах пока ты не добавиш в приват [opencomputers]
  25. Да блин я знаю какие там методы есть з овпенперипхералом. Обьясняй что за спец блок. И можеш ли ты ним + воронками закинуть вещи в верстак
×
×
  • Создать...