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

Totoro

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

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

  • Посещение

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

    289

Сообщения, опубликованные пользователем Totoro


  1. Основная концепция любой библиотеки - сделать приложение проще.

    По какой причине приложение должно отлавливать эвент библиотеки?

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

     

    Это библиотека основанная на эвентах. Не вижу причин делать иначе. Это усложнит библиотеку, а пользы особой не будет.

    Эвенты - это очень удобный способ для обработки асинронных событий и действий.

     

    Да, можно навешать колбеков, но зачем, когда чистые эвенты дают больше гибкости.

     

    Библиотеку можно усложнять до бесконечности. В финале, это может быть монстр на 100500 Мб, который позволит сделать так:

    lib.run("чатик")
    

    И у тебя есть чат. Или:

    lib.run("сайт")
    

    И у тебя поднят сайт. Правда удобно? Никакого лишнего кода, всё очень просто, прозрачно, легко и удобно.

     

    Но вот проблема. А что если на не нужен чатик или сайт, а нужена программа для обмена файлами?

    Придётся дёргать автора либы, чтобы запилил нам команду lib.run("файлообменник"), да?  :D

    • Нравится 1

  2. Данная библиотека _должна_ обеспечивать связь, приложение - только бизнес логику. Сериализировать или нет - решает пользователь передав параметр mode.

    Если ожидает таблицу - true.

    Почему приложение должно знать о существовании какого то "zn_message"? Почему это не задача библиотеки, ведь это она передает

     

    Вполне логично что библиотека и разбирается с принимающими пакетами. Это то же самое, что сказать... эм, ты знаешь, мы тут библиотеку tcp/ip написали, но на приеме вы сами там с пакетами разбирайтесь)

     

    Ну нет я не согласен. Ты просто предлагаешь добавить библиотеке больше логики, сделать её толще.

     

    Основная концепция библиотеки - это расширенный модем.

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

    Она основана на эвентах, так же как и связь через обычный модем.

     

    Мы даже выбросили из библиотеки аналог TCP, когда библиотека ждёт подтверждения получения отправленного сообщений.

     

    Сериализация, шифрование, подтверждение приёма, кастомные протоколы - это всё легко реализуется поверх библиотеки.

    • Нравится 2

  3. Так же я добавил метод

    zn.listen = function(mode)
      local _, message = event.pull("zn_message")
      if mode then
        message = serialization.unserialize(message)
      end
      return message
    end
    
    

    Ожидает сообщение и возвращает его.

     

    А нужна ли такая конструкция?

    Ведь можно использовать стандартный listen:

    event.listen("zn_message", function()
      ...
    end)
    

    А что касается десериализации - то не факт что пользователю нужно будет десериализовывать контент.

    Это уже относится к логике твоего приложения.

     

    Вот и выходит, что в библиотеку добавлять особенно и нечего.


  4. над дизайном надо бы поработать))))

     

    Мы открыты для предложений.  :)

    Баги будут пофикшены постепенно. А если есть предложения по дизайну (особенно с набросками CSS стилей, или хотябы картинками) - пиши в личку, в тему или просто в ирку. Как минимум обсудим.

     

    З.Ы. Создал пакет. Попробуй, работает ли, и отредактируй, если нужно.

    https://hel.fomalhaut.me/#packages/me


  5. Очень надеюсь)

     

    Просто даже самая обычная команда не срабатывает rs.setOutput и все ее вариации. Не понимаю, в чем дело... По видео когда делал похожие программы, у них все в миг зарабатывало, а у меня - такая фигня

     

    У тебя ошибки совсем не связаны с этой командой.


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

     

    Не надо расстраиваться. Проблема в том что у тебя каша в коде. Много синтаксических и логических ошибок. Щас тебе наши гуру всё расскажут как правильно.


  7. @@Seryoga, охрененный фидбек. А джва года такого ждал.  :D

     

    Всё справедливо. Там надо передизайнить, отрефакторить, отдебажить и допилить всё. Я если честно начал забывать уже про этот проект.

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


  8. 1EjAZmA.png

     

    Выкладываю код бота, с которым участвовал в UT2: Deathmatch.

    Много костылей и багов, да и код не образец красоты, но может кому-то будет интересно.

     

    https://pastebin.com/WHj45CNm

     

    Самое полезное там, наверное это функция raytrace. Она получает на вход две точки в трёхмерном пространстве, строит отрезок между ними, и возвращает все "кубы" которые этот отрезок пересёк. Использовалась для просчёта выстрела робота, чтобы исключить friendly-fire и стрельбу в молоко.

    Можно ещё глянуть алгоритм совместного гео-сканирования карты всеми роботами команды. Он позволял нормально сэкономить батарею.

    • Нравится 5

  9. Если будет время, на праздниках немного поработаю над понятностью и простотой.

    Ещё будет така фишка как кастомные блоки. Можно будет нарисовать схемку и запечь её в свой блок. А потом использовать везде.


  10. посмотрел на код и на "осьминога",  и начал сомневаться, что же все-таки проще понять новичку, первое или второе :D

     

    П.С. Интересно было бы увидеть копалку ProShow в этой программке. Какое там получится существо=)

     

    Да вот я тоже сомневаюсь. Надо сделать редизайн и ребрендинг  :)


  11. Если рассуждать логически. Здесь всё выполняется по линиям.

     

    У цикла есть две ветки - ветка "плюс" и метка "минус".

    По ветке "плюс" программа идёт когда цикл активен, а по ветке "минус" - когда он завершился.

     

    То есть надо сделать так, чтобы ветка "плюс" вернулась обратно в цикл в конце. А продолжение программы должно идти из ветки "минус".

     

    Пример:

     

    iE5Dd9L.png

    Выполняется этот осьминог так:

    1) Программа заходит в цикл

    2) Цикл повторился 0 раз. Надо 10. Значит цикл активен. Значит идём по "плюсу".

    3) Печатаем номер попытки в консоль

    4) Возвращаемся к началу

    5) Цикл повторился 1 раз. Надо 10. Идём по "плюсу".

    ....

    31) Цикл повторился 10 раз. Цикл завершён, идем по "минусу".

    32) Конец программы

     

    Вот такой исходник сгенерится:

    -- [OcBlocks v0.3a generated code] --
    local a = '10'
    local robot = require('robot')
    for c = 1, tonumber(a) do
      print(c)
    end
    -- [The END] --
    
    • Нравится 1

  12. Как рассчитать выстрел с такими препятствиями? Это нужно высчитывать расстояние до каждого блока, выделять их контур с точки зрения робота, определять по какому углу он сможет задеть робота за препятствием. Это только усложняет игру.

    Я же предлагаю пустые территории и укрытия в 1 блок. Робот встал за укрытие - может охранять территорию позади него и рядом. Сделал шаг наверх и может атаковать вперёд. Не нужно никаких сложных вычислений, сможет или нет атаковать за укрытиями и какой угол выбирать, чтобы не попадать в укрытие.

     

    Возможно так будет проще, да.

    В идеале - пустая квадратная арена с колонной посередине. И лучше чтобы карта была 2D (1 блок высотой). Тогда не надо будет думать о том, что противник может зайти сверху.

    А лучше - 1D арена. Пилим стеклянный тоннель в один блок, а команды расставляем рандомно по его длине. Только представь всё многообразие восхитительных стратегий, которые можно будет реализовать!


  13. ...

     

    У робота есть геосканер.

    Только тебе решать, будет робот стрелять по рандому, или будет рассчитывать свой выстрел с учётом препятствий.

     

    Простреливание - вполне честная стратегия. Но чтобы дать шанс другим стратегиям и внести некоторое разнообразие, достаточно поставить посередине арены постоянную колонну.


  14. У конкурсов (особенно на нашем проекте) ДОЛЖЕН быть низкий порог вхождения. Идеален конкурс в котором может поучаствовать каждый.

    Желательно при этом чтобы было несколько направлений и вариантов решения задачи.

     

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

     

    Попробуйте предложить идею, исходя из таких критериев.

    А я пока проедусь по нескольким мыслям, которые тут мелькали.

     

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

     

    Чем плохи лабиринты? Тем что это будет конкурс - "кто точнее реализует алгоритм A*". В этом скучно участвовать, и на это крайне скучно смотреть.

     

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

    • Нравится 3
×
×
  • Создать...