Перейти к содержанию

Doob

Гуру
  • Публикаций

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

  • Посещение

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

    78

Весь контент Doob

  1. В первом посте есть пример обучения. Только тут нет выбора типа сети, нет адекватного управления дампами, представление данных совершенно костыльное. Если есть идеи, как использовать нейросети в опенкомпах, можно написать либу, с поддержкой 4 самых популярных типов сетей. Благо, в основе они очень похожи, за исключением сверточных. Обучать можно на нормальной платформе, дампы переносить в опенкомпы и использовать по назначению.
  2. Не все так просто. Lua написан на си и написан чисто. https://github.com/lua/lua/blob/master/lmathlib.c https://github.com/lua/lua/blob/master/lbitlib.c Тут не к чему придраться. Си тоже неплохо отполирован, хотя и остаётся языком костылей. Тут надо разобраться с виртуальным процессором, т. к. реальный процессор работает сверх-очевидно и оптимально написанные программы работают как и должны.
  3. Неплохо, но где обратная операция? Она ведь во многих случаях вызывается чаще и жрет больше времени. А теперь попробуем адаптировать подход, который часто применяется в ассемблере: разделим 64int на 3 части, y максимум будет 255, а x и z - 134217728, хеширование происходит за 6 операций (тут нет умножения, хотя с мат. сопроцессором это не играет роли). local function hash(x, y, z) x, z = x+134217728, z+134217728 return y|(x<<8)|(z<<36) end Если бы не требовалось при поиске пути каждый раз получать исходное число, скорость была бы не намного выше, чем при использовании многомерных массивов.Я проводил сравнение нескольких алгоритмов хеширования и для реализации на опенкомпах остановился на единственном оптимальном варианте - многомерный массив, т. к. если расход памяти сверхкритичен, проще подгружать чанки оптимально закодированной карты, чем тратить кучу времени на ползание по ней. Сравнительная таблица где-то потерялась, но хорошо помню, что поиск таким способом в 100^3 вершинах происходит где-то за 20 секунд (в опенкомпе это около четырех часов), алгоритм поиска A* с манхетеннской эвристикой. Вот, кстати, тестовый код: https://pastebin.com/0uj6v3KX, убрать одни операции и добавить другие можно, но результат примерно тот же. И да, должен быть алгоритм нахождения расстояний в захешированных координатах, как-нибудь надо будет проверить.
  4. Не стоит сильно экономить память в опенкомпах, т. к. ее очень много, а процессор крайне медленный. Например, если для хеширования массивов использовать традиционный битовый сдвиг, то скорость работы с массивом падает в тысячи раз. Особенно критично, если применять это для хранения карт и поиска пути на традиционных алгоритмах. Да, реализация битового сдвига хромает, но деление по модулю и взятие остатка заставляет биться головой об стену.
  5. У меня лаги смертельные, играть невозможно. Рендер внешности персонажей лишний, это ведь не спектрум, можно было бы оптимизировать (а еще лучше показывать внешность только в диалогах), чтобы не перерисовывать по килопикселю за раз.
  6. Почему же не интересно? Если сделать это в виде толковой мини игры, то будет такая фича сервера. Могу взяться написать. Графоний, правда в опинкомпах отсутсвует, но есть куча текстовых игр, в которые играют десятилетиями.
  7. Я думал, добыча должна производиться в реальном мире виртуальными ботами, там нужна подгрузка чанков, а получать ресурсы из воздуха - никаких проблем, можно написать. Была идея магических ферм - игрок совершает определенный ритуал и ему начинают рандомно начисляться ресы из виртуальной фермы (тростник/булыга/шерсть), которые можно обналичить. Идея интересная, но из воздуха ресурсы получать не интересно, можно и надюпать с таким же успехом.
  8. Давнo мусoлят эту тему, накoнец-тo ктo-тo заинтересoвался. Для начала, если игрoк oграничен в вoзмoжнoстях, не следует oграничивать егo фантазию. Пoэтoму, игрoк дoлжен иметь на старте не гoтoвых рoбoтoв, а ресурсы для их изгoтoвления. Это позволит каждому выбрать свои приоритеты. Так как пoдразумевается мультиплеер, тo дoлжнo быть сoревнoвание, задача "не пoмереть и не пoтерять рoбoтoв" выглядит глупo. Следoвательнo, нужна система, кoтoрая будет кoнтрoлирoвать кoличествo ресурсoв каждoгo игрoка и куда-тo вывoдить, для пoддержания сoревнoвательнoгo духа. Мoжнo даже немнoгo изменить идею - игрoки этo шахтеры, кoтoрых пoслали перерабатывать планету на ресурсы, лидерам пo дoбыче кoрпoрация дает бoнусы (бoльше энергии и ресурсы, кoтoрые нельзя или oчень труднo дoбыть в этoм мире), этo кстати, пoзвoлит игрoкам активнo тoргoвать друг с другoм. Ну и стoит учитывать не дoбытые ресурсы, а скoрoсть, с кoтoрoй их пoлучает кoрпoрация. Если капсула заперта, тo зачем oтрубать руки? Даже такoй кoмпутер-френдли мoд, как IC^2 имеет кoмпoненты, с кoтoрыми рабoтать мoжет тoлькo игрoк (мoжнo их не испoльзoвать, нo вырастает слoжнoсть), чтo тут гoвoрить прo всякие дюпo-мoды, кoтoрые рассчитаны исключительнo на игрoка (хoтя... да, безрукий игрoк пoчти не мoжет дюпать). Мoжнo кoнечнo, запереть игрoка в oднoблoчную капсулу, нo oчевиднo, мнoгие плюшки мoдoв будут недoступны. Игрoку, бoлее или менее oсвoившему кoмпьютерный мoд, автoматизация дается легкo и непринужденнo (крoме тех oтраслей, где еще нет интеграции мoдoв). Пoэтoму вoпрoсы типа а как рoбoт этo сделает? и ээ, ента наверна слoжнэ? лишние - если хoрoшенькo пoдумать, а если нет инфoрмации, тo прoтестирoвать, будет oтвет: рoбoт этo мoжет/не мoжет. И тут все упирается в лень прoграммирoвать или в лень махать лoпатoй. Я с удoвoльствием буду прoдавать кoд за ресурсы, т. к. неoбхoдимую утилиту мoжнo написать oдин раз и пoльзoваться вечнo, чем на каждый чих вгрызаться в камень. Давным давно такое есть, только без подргузки чанков. Можно скиллы добавить и вообще, что угодно.
  9. Лагает страшно, сама игра захардкожена в одном файле. Во многих местах есть баги (особенно при конфликте потоков). Графика не оптимизирована совсем. Для маломощных машин платформеры - не самый лучший выбор. Да и вообще, RPG традиционно надо делать с видом сверху/изометрически, так и кодить проще и экономней по ресурсам, ну и красивей результат.
  10. Doob

    OpenComputers 1.7.0

    Да, опенось починили, а то пользоваться было совершенно невозможно. Теперь больше плюшек и больше багов, в добавок к старым.
  11. Сохраняет в file.txt туда же, где находится. Можно отправлять по сети или еще каким-нибудь способом. Сначала установить библиотеку: pastebin get iKzRve2g /lib/forms.lua, затем создать файл edit cmnt.lua, прописать в автозапуск, убрать кнопку выхода и запретить прерывания. И в бой.
  12. Нет, то можно легко сделать на основе готовых библиотек. Например, за пару минут на основе forms: local forms = require('forms') local w, h = require('component').gpu.getResolution() local main=forms.addForm() main.border=1 main.H=15 main.W=43 main.left=math.floor((w-main.W)/2) main.top=math.floor((h-main.H)/2) textfield=main:addEdit(3,2) textfield.text = {} textfield.H=11 textfield.W=39 local btn_sumbit=main:addButton(29,13,'Sumbit',function() local file = io.open('file.txt', 'a') file:write(table.concat(textfield.text,'\n')..'\n') file:close() textfield.text = {} textfield:redraw() end) local btn_exit=main:addButton(6,13,'Exit',forms.stop) forms.run(main)
  13. Ещё и адаптер прицепить, чтобы контролировать все функции. Апгрейд БД тут лишний, можно хранить в прошивке все возможные схемы, определяя и устанавливая по имеющимся компонентам доступную. Игроку в таком случае остается только крафтить компоненты и отбирать энергию.
  14. Предлагаю вместо доминашки сделать ctf или гибрид, как в ut2004/ut3 - захват цепи нод. Хоть какое-то будет развлечение, а не беготня по кругу.
  15. Функция os.sleep поймает один сигнал и завершится, а если поймает нужное сообщение, то упадёт замертво. Максимальный размер пакета можно получить через maxPacketSize() Нужен протокол рукопожатий, чтобы можно было запускать несколько сетей. Защита от взлома тут самое важное. Связанная карта - не вариант, ест много энергии. Неплохо бы иметь набор программ из коробки для работы с дронороботами.
  16. Загрузка по старой ссылке: pastebin run umGdzPYT Если надо, могу добавить ветвления для угловых. Есть еще такой набор:
  17. Если нужно назначить компонент ДО запуска системы, то надо писать установку примари-компонента в EEPROM, а не в системный автозапуск, все просто.
  18. pastebin run umGdzPYT Если делать плинтус, т. е. первый блок от пола, то можно сделать красивей.
  19. Тут даже для минимализма не хватает шейпов, а для нормальных паттернов тем более.
  20. Я к прошлому серверу готовил орнаменты, где-то валяются, могу еще наделать. Соблюдать ограничение на 24 шейпа? Плитки на пол какие, чтобы по ним ходить можно было? Можно кое-где толщину в 2 шейпа?
  21. Всё-таки лучше оставить симметричное шифрование. Для анализа крафта можно сделать специальную службу - терминал с печками/верстаками, не удобно, но самодостаточно. Можно сделать, чтобы для конечного пользователя все предметы были в метасостоянии, т. е. не только те, которые были загружены, но и те, которые можно скрафтить из них. Это позволит экономить время, которое придётся затратить на рассылку книги рецептов, при крафте по запросу.
  22. Весь мир давно делает локализацию для своих прог, Тоторо только проснулся. Если пакет зазипать, то места он будет занимать крайне мало, sfx - тоже не плохо, но в основном пользуют загрузку нужных кишок при установке программы - никаких лишних телодвижений со стороны разработчика.
  23. Здорово, конечно, но совсем не те ощущения. Часами крутить эту ручку - совершенно непередаваемое "удовольствие". В большинстве задач хватало логарифмической линейки.
  24. Это ось для алмазных компов. Поначалу был файл-менеджер с плюшками, теперь больше чем форк OpenOS. Осталось сделать установщик на чистый диск и будет вполне себе ось. Замена библиотек в некоторых местах ломает опеось, этим грешат не только "операционные системы", но и простые программы. Вполне приличная штука для новичков, для ознакомления с возможностями мода, но очень мало людей идет дальше пары кликов. А я даже опеносью пользуюсь только из-за удобной возможности прошивки eeprom нужными программами, т. к. для большинства практических задач ось не нужна.
×
×
  • Создать...