(2068.PLUS.beta) Обновлена BETA-версия программы Помощник.

   Пользователям последних версий (2067+) по 30.08.2020 будут начисляться дополнительные 120 минут в рамках постоянной акции TimeBack.

 

    Что изменено с прошлого релиза:  

    - (Исправлено) прокручивание ониксовых барабанов (в том числе и бесплатных попыток, изменения от 27.08 сломали этот момент во всех старых версиях). Бесплатные прокруты можно включить обратно, если необходимо. Однако имейте в виду, что если вновь появится большое число сообщений об ошибке в логе, то первым действием будет опять отключить бесплатные прокруты и проверка уберет ли это ошибку. Сообщите если проблема не решится (активная опция бесплатных прокрутов будет заставлять программу "чудить"), логи работы сохраненные в файл приветствуются.

    Для установки обновления вызовите в меню в рабочем окне "Помощь" - "Обновить beta- версию".

    Либо установите программу поверх в ту же папку (при закрытой программе) с установщика:

http://2b2s.ru/files/Beta.Pomoschnik.Ultra.PLUS.Web.Installer.exe

Если у вас уже есть 2067-бета, то обновление можете провести с помощью облегченного установщика (в нем только программа, без базы предметов и прочих сопутствующих файлов):

http://2b2s.ru/files/light.BETA.Ultra.Installer.exe 

 

    У меня есть личный приоритет на выделение времени на те или иные задачи дальнейшего развития Помощника. Однако интересно и мнение тех, кто читает рассылку. Но результаты голосования не гарантируют кардинальных изменений моих планов =) Хотя безусловно могут поменять некоторые пункты местами. 

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

Вариант 1. Группы индивидуальных параметров. Эта тема уже поднималась ранее. Итоговый концепт - последний из описанных (ссылка).

Вариант 2. Медали, бафы, скрипты. В данный момент есть проблема с определением наличия некоторых медалей, что создает проблемы с призывами, для которых есть особые условия по расходникам или медалям, определением есть баф на своем или чужом персонаже, а так же наличием всех образов. Функция бафов также нуждается в переработке, но ее оптимальнее базировать именно на состоянии медалей. Кроме того еще в начале лета я добавил в программу скриптовый движок Lua. Однако к нему нужно создать прослойку для работы с функциями самой программы. Итоговый результат позволит лучше задавать обработку нюансов, хотя это потребует создание текстовых цепочек-скриптов (не исключено, что их, например, для кланов смогут создавать другие пользователи, что упростит реализацию локальных "хотелок"). Но как обычно на это нужно время;

Вариант 3. Турнирный алгоритм. Автоматический алгоритм проведения турниров и раньше не отличался гениальностью, я не турнирщик и нюансов ведения боя не знаю. По последнему его варианту к тому же возникают вопросы у отдельных пользователей. Да, надо сидеть глазами вылавливать странные ходы, после изучать исходные данные (какое исходное поле, какие статы у своего перса и противника, почему именно такой был выбран ход и какой вместо него был бы оптимальным). На их базе вносить изменения и снова смотреть за большим числом боев выявляя новые несостыковки (либо принимать решение, что все хорошо, если долго косяков не наблюдается). Только это требует неопределенного числа дней, и как я указывал выше я не турнирщик и мое восприятие "оптимального" хода может иметь особенности. До этого времени совсем большой востребованности автопроведения турниров не было. Сколько времени стоит тратить (с неопределенным результатом) я решу в том числе и по числу отзывов в голосовании;
Вариант 4. Возможность сохранения настроек по-блочно. Например, "вкладка" или "режим", может какие-то отдельные блоки "режима". Суть в возможности создания заготовок на разные случаи. Для них возможно не нужен полный набор всех опций, который сохраняется сейчас).
Вариант 5. Статистика работы. Виденное на бирже, графики скоростей/сумм действий по периодам, возможно учет прихода/расхода ресурсов по времени/роду деятельности (по этому направлению еще нужно думать, т.к. само по себе изменение баланса фактически ни к чему не привязано и может происходить с некоторым временным отрывом. Если происходит несколько разноплановых действий, то не исключена путаница).
Вариант 6. Совмещение управляющей программы и браузера в одном приложении. Следует понимать, что это никак не изменит способ настройки либо количество опций или окон с ними. Возможность подстройки деталей работы само по себе подразумевает, что на это нужны какие то способы/опции (под которые нужно место).

Плюсы: 

. Не нужно будет держать дублирующие друг друга структуры данных и в браузере и в программе (потенциально снижение потребления памяти и возможно немного процессора за счет урезания работы с лишними объемами);

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

Минусы:

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

. Если сейчас программа может перезапустить браузер (например, зависший) "малой кровью", то в единой связке зависший браузер может застопорить всю работу, подвесив все приложение;