Майн-бот

hikki · 19 Мар 2010

На картинке наверное лучше будет видно.
Кстати очень частый вопрос.

Belfigor · 19 Мар 2010

В то время когда я только начинал этим заниматься и не знал про идентификаторы окон, я боролся с этим присваивая окнам рандомные имена после каждого дока и андока :smile:

DJ_Tommy · 19 Мар 2010

sora no kaze сказал(а):
SirMaksFromEho сказал(а):

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

Нажмите, чтобы раскрыть...

а можно вот об этом чуть подробнее - где именно включается тайтл такого вида? в еве 4 года, в неск окон играю почти столько же.. но они у меня все называются одинаково "EVE" и настроек такого рода я нигде не встречал
собственно в этом была главная загвоздка, когда хотел делать майнер под себя.. ибо нужно было под 5-6 окон, но тут писали, что под каждое надо вирт.машину выделять, а это уже даже мой довольно мощный десктоп не потянул бы.. о0

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

hikki · 19 Мар 2010

Немного теории и рассуждений про майнинг бота.
Часто, когда начинают только думать ботах то сразу заводят кучу аккаунтов с именами типа SAPER1, SAPER2 и тд. они похожи как однояйцевые близнецы, план прокачки у них одинаковый, скилы одинаковые. Когда чаров начинают пользовать по назначению, они садятся на одинаковые баржи в одном и томже фите, пользуют одни и теже настройки овервью. Время цикла стрипа у них тоже одинаковое.
Зачем писать многооконного бота, который будет пасти кучу одинаковых окон и делать кучу одинаковых движений? Делаем простой однооконный бот, и делаем прогу транслятор мыши и клавы на остальные 3-5-10 свернутых окон, передача нажатий клавиатуры и движений мыши в неактивное окно уже было разобрано в других темах.
Как идея?

Belfigor · 19 Мар 2010

Это альтернативное решение использования вирт машин под каждую лопату предложенное Томми.

UPD: Суть тут вот в чём:
Высокотехнологичные боты должны делать не то что сказал им их девелопер, а именно то что сам бот считает нужным сделать в данный момент.
Самым актуальным примером конечно будет мультиоконный трейдер, но и на майнера можно найти кучу примеров.
10 лопат начинают работать ориентируясь только на одно окно:
10 лопат андокаются, бот ждет пока андок завершит главное окно. Главное окно завершило андок, бот командует ему варпаться на белт и транслирует команду на оставшиеся 9 окон. Но вот не задача, в тот момент когда увидил что главное окно андокнулось и отдал команду, еще например 1 или несколько лопат выгружались с черным экраном => команда полученная от главного окна и ушедшая в остальные окна, не пройдет в те окна которые небыли готовы в данный момент принять эту команду.
Точно так же прилетела главная лопата в белт, получила команду целиться в ройд и запускать стрипы, транслировала команду на оставшиеся 9 окон. А если часть окон еще по какой-то причине (например при уходе в варп их бампанули другие лопаты или же тупо по прилету ближайший ройд стоит за пределами радиуса досягаемости) не была готова принять эту команду?
Как результат мы имеем одно 100% нормально работающее окно и остальные 9 окон имеющием 99% шанс выпасть из цикла в любой момент времени тупо изза того что небыли в какой-то момент готовы принять какую-то команду. В лучшем случае эти окна включатся обратно в цикл лишь при следующем проходе логики через тот момент на котором они из него выпали.
То есть для того чтобы быть уверенным в том что каждое окно приняло команду, мы должны активировать каждое окно и посмотреть что оно щас делает, восприняло команду или нет, тоесть если мы хотим налаженную еспушную работу, без работы с каждым окном отдельно нам далеко не уйти.

Повторю то что сказал выше: "Бот должен делать не то что ему говорит разработчик, а то что он считает нужным".

В пример приведу одного из своих мультиоконных майнеров, даже приведу кусок его логики на автоите:

Код:

Select	
								#Region - На Станции
								Case $LogicState[0] = "Station|Empty|Объект не найден|False|Inactive|Inactive" ;На станции, трюм пустой
									UpdLog("Андокаюсь")
									_Then("Undock")
								
								Case $LogicState[0] = "Station|Not Empty|Объект не найден|False|Inactive|Inactive" ;На станции, трюм частично заполнен
									UpdLog("Разгружаюсь")
									_Then("Unload Cargo")
								
								Case $LogicState[0] = "Station|Full|Объект не найден|False|Inactive|Inactive" ;На станции, трюм полный
									UpdLog("Разгружаюсь")
									_Then("Unload Cargo")
									
									
								#EndRegion - На Станции
								
								
								#Region - Возле Станции
								Case $LogicState[0] = "Space|Empty|Объект не найден|False|Inactive|Inactive" ;Возле станции, трюм пустой
									UpdLog("Варпаюсь на белт")
									_Then("WarpBelt")
								
								Case $LogicState[0] = "Space|Not Empty|Объект не найден|False|Inactive|Inactive" ;Возле станции, трюм частично заполнен
									UpdLog("Докаюсь на станцию")
									_Then("Dock")
									
								Case $LogicState[0] = "Space|Full|Объект не найден|False|Inactive|Inactive" ;Возле станции, трюм полный
									UpdLog("Докаюсь на станцию")
									_Then("Dock")
									
								Case $LogicState[0] = "Space|Empty|Объект не найден|False|Warping|Inactive" ;Возле станции, трюм пустой, разгоняюсь на белт
									UpdLog("Беру разгон на белт")
									
								Case $LogicState[0] = "Space|Empty|Объект не найден|False|In Warp|Inactive" ;Возле станции, трюм пустой, ушел в варп на белт
									UpdLog("Ушел в варп на белт")
									
								Case $LogicState[0] = "Space|Full|Объект не найден|False|Warping|Inactive"
									UpdLog("Вышел из варпа у станции")
								#EndRegion - Возле Станции
								
								
								
								#Region - В белте
								Case $LogicState[0] = "Space|Empty|Объект найден|False|In Warp|Inactive" ;Пустой трюм, вышел из варпа в белте
									UpdLog("Выхожу из варпа в белте")
									
								Case $LogicState[0] = "Space|Empty|Объект найден|False|Warping|Inactive"
									UpdLog("Вышел из варпа в белте")
									
								Case $LogicState[0] = "Space|Empty|Объект найден|False|Inactive|Inactive" ;Пустой трюм, висю в белте ничо не делаю
									UpdLog("Беру ройд на таргет")
									_Then("Target")
									
								Case $LogicState[0] = "Space|Empty|Объект найден|True|Inactive|Inactive" ;Пустой трюм, ройд на таргете, стрипы не работают.
									UpdLog("Запускаю стрипы")
									_Then("Launch Strips")
									
								Case $LogicState[0] = "Space|Empty|Объект найден|True|Inactive|Active" ;Рою первый цикл
									UpdLog("Рою первый цикл")
								
								Case $LogicState[0] = "Space|Not Empty|Объект найден|False|In Warp|Inactive" ;Не полный трюм, вышел из варпа в белте
									UpdLog("Вышел из варпа в белте")
									
								Case $LogicState[0] = "Space|Not Empty|Объект найден|False|Inactive|Inactive" ;Не полный трюм, висю в белте ничо не делаю
									UpdLog("Беру ройд на таргет")
									_Then("Target")
									
								Case $LogicState[0] = "Space|Not Empty|Объект найден|True|Inactive|Inactive" ;Не полный трюм, ройд на таргете, стрипы не работают.
									UpdLog("Запускаю стрипы")
									_Then("Launch Strips")
									
								Case $LogicState[0] = "Space|Not Empty|Объект найден|True|Inactive|Active" ;Рою второй цикл
									UpdLog("Рою второй цикл")
									
								Case $LogicState[0] = "Space|Full|Объект найден|True|Inactive|Inactive" ;Полный трюм
									UpdLog("Варпаю на станцию")
									_Then("Dock")
									
								Case $LogicState[0] = "Space|Full|Объект найден|True|Warping|Inactive"
									UpdLog("Беру разгон на станцию")
									
								Case $LogicState[0] = "Space|Full|Объект найден|False|In Warp|Inactive"
									UpdLog("Ушел в варп на станцию")
									
								Case $LogicState[0] = "Space|Full|Объект найден|False|Warping|Inactive"
									UpdLog("Беру разгон на станцию 2")
									
								Case $LogicState[0] = "Space|Full|Объект не найден|False|In Warp|Inactive"
									UpdLog("В варпе на станцию")
									
								Case $LogicState[0] = "Space|Full|Объект найден|True|Inactive|Active" ;Трюм полон, мы в белте, должны были отварпать на разгрузку, но каким-то хитрым маневром бот умудрился еще раз запустить стрипы. В прочем это ничего не меняет, разгружаться нам один хй надо.
									UpdLog("Варпаю на станцию")
									_Then("Dock")
									
								Case $LogicState[0] = "Space|Full|Объект найден|False|Inactive|Inactive" ;Трюм полон, мы в белте, должны были отварпать на разгрузку, но каким-то хитрым маневром бот умудрился еще раз запустить стрипы. В прочем это ничего не меняет, разгружаться нам один хй надо.
									UpdLog("Докаюсь")
									_Then("Dock")
									
								Case $LogicState[0] = "Space|Full|Объект найден|True|Warping|Active" ;Еще одна ситуация из цикла "А вы не ждали? А вот, получите!". Полный трюм, надо бы уйобывадь на разгруз но почему-то у нас включены оба стрипа. Надо переделывать логику и раскладывать ее по уровням.
									UpdLog("Беру разгон на станцию")
									
								Case $LogicState[0] = "Space|Full|Объект не найден|True|Warping|Inactive"
									UpdLog("Беру разгон на станцию")
									
								Case $LogicState[0] = "Space|Not Empty|Объект не найден|True|Inactive|Active"
									Sleep(1000)
								
								Case $LogicState[0] = "Space|Empty|Объект не найден|True|Inactive|Active"
									Sleep(1000)
									
								Case $LogicState[0] = "Space|Full|Объект не найден|True|Inactive|Inactive"
									UpdLog("Варпаю на станцию")
									_Then("Dock")
								
								
								#EndRegion - В белте
								
								
								
								
								
								
								
								
								Case $LogicState[0] = "Space|Not Empty|Объект не найден|False|In Warp|Inactive"
									UpdLog("Лечу с неполным трюмом разгружаться на станцию.")
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
								#Region - Разное
								Case $LogicState[0] = "Идет загрузка...|Empty|Объект не найден|False|Inactive|Inactive"
									UpdLog("Выгружаюсь в космос")
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
;~ 								Case $LogicState[0] = ""
								#EndRegion - Разное
								
								Case Else
									ClipPut($LogicState[0])
									Local $asas = WinGetTitle("[active]")
									BlockInput(0)	
									MsgBox(0,"","Найдена невиданная доселе конструкция! В окне "&$asas&" Ахтунг!"&@CR&"Конструкция помещена в буфер обмена:"&@CR&$LogicState[0]&@CR&"До выяснения обстоятельств рекомендуется не запускать бота."&@CR&"Работа автоматически продолжится через несколько секунд", 5)
;~ 									Exit
							EndSelect

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

Например я могу не иметь в цикле хаулера и каждое окно наполнив трюм будет прыгать на станцию на разгруз. В такой ситуации я могу разместить все окна на одной стартовой позиции (например все в доке) и запустить их, или же могу рассовать их в различные места производственного цикла (например одно висит на станции с полным трюмом, второе на станции с пустым трюмом, третье андокнутое, четвертое в белте, пятое в белте с затаргеченным ройдом, четвертое в белте и уже копает и тд и тп) и после запуска моего бота каждое окно продолжит заниматься своим делом с той точки на которой бот его обнаружил.
За 1 цикл окон каждое окно в зависимости от ситуации выполняет одно действие. Например:
Лопата которая была неразгружена и сидела в доке, - разгрузится, тем самым продвинувшись на 1 шаг в цикле.
Лопата которая балв в доке но у нее был пустой трюм, андокнется
Лопата которая уже висела на андоке, прыгнет в белт
Та что была в белте но без таргета, возьмет ройд на таргет
Та что уже висела с таргетом но не копала - начнет копать
Та что уже копала - останется копать до того как не заполнит свой трюм.

Тем самым каждый раз при активации любого окна, оно продвигается на 1 шаг цикла, независимо от других окон.

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

Я не утверждаю то что бот должен работать именно по моей системе, я только утверждаю что система трансляции команд тут неприменима. А эта система позволяет выжимать 100% кпд из ботов.
Добавлено:
Сообщение автоматически объединено: 19 Мар 2010

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

hikki · 19 Мар 2010

Теперь понятна твоя борьба за производительность и скорость выполнения кода)) Получается у тебя при каждом разворачивании окна происходит анализ происходящего и выставляется значение в переменную. Интересно, будем думать.
Но и мой болванчик имеет право на жизнь, особенно если ему не надо быть таким умным :smile:

а для большинства этого достаточно.

Belfigor · 19 Мар 2010

Имеет, тут уже дело вкуса и преследуемые цели, от них зависит по какому пути пойдет девелопер :smile:

necrozyablo · 23 Мар 2010

Belfigor сказал(а):
Имеет, тут уже дело вкуса и преследуемые цели, от них зависит по какому пути пойдет девелопер

А ты не боишься с одной машины много окон запускать? Видно же что у CCP есть проверка на кол-во запущенных EVE на одной машины, в частности то что не дают запустить пару триал аков.
Виртуальные машины как то безопасней, а связывать их можно через расшариную папку по средстав писание в файлик конфига.
Я когда игровые серваки держал больше всего ботов ловил через длину сессий в неделю и кол-ве запущенных клиентов с одинаковыми железными данными(железные серийники) + одновременные действия.
Хотя конечно я понимаю что сам по себе запуск на виртуальной машине это то ещё палево(определить что программа запущена через виртуальную среду проще пареной репы)
Вообще что думаешь по этому поводу?

Belfigor · 23 Мар 2010

По 5 ботов на одном компе, если бот нормальный то с момента запуска до момента бана он за короткий промежуток времени полностью отрабатывает затраты на себя и приносит прибыль, как только он приносит в два раза больше чем на него потратили мне уже параллельно что с ним случится, как только его забанят то тут же на средства с него полученные я запущу новых ботов. Вот так они и работают изолированными ячейками по 5 чаров на одной машине, никак между собой не контактируя.

necrozyablo · 23 Мар 2010

Я так понимаю у тебя бот работает не через виртуальную машину, а через неактивные окна? (судя по кол-ву на одной машине)

Kinex · 23 Мар 2010

Подобная организиция работы ботов приемлима для майнинга, но для ханта в нулях, на мой взгляд, врядли. Те же пять виртуалок можно запустить на одной машине с 8 гигами памяти, зато реагировать на изменение ситуации боты будет быстрее.

Belfigor · 23 Мар 2010

Активные окна или нет, это не зависит от того через что работают боты. Можно запустить 30, 50, 100 штук на машине и всеми ими работать через активные окна.

Kinex · 23 Мар 2010

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

flikstrange · 31 Мар 2010

А вообще перспективно писать бота майнера?
У кого сколько икс\ч выходит? Мне кажется хантер бот зарабатывает на порядок больше или я не прав?

Хотя конечно если пачкой Халков с Оркой наверное доход намного выше чем от двух коветоров.

Kinex · 31 Мар 2010

Хантер делает больше, но и написать его сложнее и оргвопросов с ним больше. А иск/час майна и ханта на любом форуме евы можно найти. Майн еще упадет прилично после следующего патча.

hikki · 31 Мар 2010

ну нескажите, если уберут мета 1 лут с миссий то думаю что хант в дронрегах и майнинг вообще станет более выгодным.

Lexx98 · 1 Апр 2010

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

Kinex · 1 Апр 2010

Уменьшают на 31.7% выплаты по страховке. Это опустит цены на Т1 корабли, что опустит цены на минералы и т.д. Вот топик: http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1283806

necrozyablo · 1 Апр 2010

Перевод девблога

руговорот Жизни
reported by CCP Chronotis | 2010.03.30 14:01:51 | Оригинал блока

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

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

Основы Минералов

Минералы появляются из трёх разных источников в ЕВЕ: Астероиды и майнинг, сражения с NPC и переработка лута, переработка сплавов из Rogue Drone. Из перечисленного майнинг руды в астероидах и переработка сплавов зависят от цен минералов, и эти цены определяет прибыльность занятия, в то время как в случае с лутом это только одна из наград даваемая за сражения с NPC

Хьюстон, у нас проблема!

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

Тем не менее, цена минералов всё больше зависит от распространённой переработки лута - источника, который даёт только небольшую порцию от всей награды в сражении с NPC, а также обесценивает и медленно разрушает специализированные роды занятия, поскольку прибыль от сражения с NPC не сильно зависит от цены минералов, в то время как специализированные роды занятия сильнее зависят от них.

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

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

Так какие же изменения будут в источниках минералов?

NPC Лут

Мы установили, какие основные таблицы лута ответственны за ввод большинства минералов с NPC лута, и это первое, что мы хотим отрегулировать в Тираннисе - уменьшение количества Тech 0 [прим. перев. Думаю подразумевается Мета 0] вещей сыплющихся и замена их всякими скрап металлами и тагами, например. Будет сыпаться такое же количество Tech 1 мета 1-4 модулей, из них всё ещё будут репроцесситься минералы, если вы хотите пользоваться минералами от сражением с NPC.

В то время как это уменьшит вторичный доход от сражений с NPC по началу, это будет не так значительно по отношению к другим наградам. Меньшие количества минералов всё ещё можно будет получить с переработки лута, и они, скорее всего, стоить будут дороже.

Сплавы из Rogue Drone

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

Основной целью наших изменений было изменить не только количества дропающихся сплавов с отдельных дронов, но и количество минералов, которое получается при переработке, так что объём минералов будут лучше соответствовать объёмам необходим при производстве, также будет уменьшен общий объём лута, и будет проще привезти сплавы на станцию, например.

Это даёт дополнительные преимущества жителям дрон регионов, они смогут быть более самодостаточными, имея большие объёмы минералов для своего производства, в то время как не будет какого-либо перенасыщения определенными отдельными минералами.

Астероиды

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

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

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

И теперь о страховке кораблей ohmy.gif

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

Ключевым принципом является то, что вам компенсируется часть ИСК, которые нужны для замены корабля. Тем не менее, эти выплаты базировались на статических ценах корабля, которые мы выбрали при запуске ЕВЕ, когда мы устанавливали цены всех минералов на рынке. С тех пор мы убрали ограничения и полагались на то, что весы потенциального спроса и предложения каждого минерала будут поддерживать относительную ценность.

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

Так что страховки будут привязаны к рынку?

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

Но нужно ещё кое-что обсудить!

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

Мы можем сказать что таклерские корабли, которые выполняют опасную роль, скорее всего будут умирать часто, поэтому будут получать большие компенсации, чем скажем специализированные коверт опс корабли, у которых больший шанс выживания. Так что игроки которые летают на недолго живущих кораблях будут более устойчивы и смогут летать на меньших доходах, то же самое относится к обычным кораблям, типа крейсеров или БК, которые часто используются новыми игроками, чтобы они могли привыкнуть к игре, а не потерять всё в момент.

На другом краю находятся стратегически важные классы кораблей и ценные цели. Мы говорим о суперкапиталах, самых больших кораблях в игре, которые не могут докаться. На данный момент они получают выплату 40% от старой статической цены корабля, что составляет 5 миллиардов для суперкарьеров и 20 миллиардов для титанов.

Идея в том, чтобы урезать это до доли их текущей выплаты, так что они будут получать только 1-10%, например, от базовой стоимости своего корабля. Это будет сделано, чтобы стратегически важные корабли были более ценными целями, и их смерть была бы более важной и дорогостоящей.

У нас есть свои идеи по поводу того какая полная страховка должна выплачивать для каждого корабля, в общих чертах мы имеем такую картину: 100% для Tech1 кораблей, 20-60% для Tech 2 и 100% для Tech 3 кораблей (но это только часть стоимости всего корабля, посколько субсистемы не включены). Тем не менее мы ждём ваших отзывов по поводу того какие страховки должны быть для каждого класса кораблей и почему.

В завершении

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

necrozyablo · 2 Апр 2010

Как я понимаю в нулях можно будет майнить выгодно среднею руду.
Страховка для простых короблей будет покрывать чуть ли не 100%, а для титанов 1-10%
Как мне кажется из этого следует такой цикл:
Положим Игрок имеет 100кк страховку за 5кк и корабль ценой 100кк
Игрок теряет корабль ему возвращается 95кк до этого бы вернулось скажем всего 80кк. Он докидывает свои 5кк + ещё 5кк на страховку и вот у него новый корабль.
В итоге он может слить 10 раз корабль, а до этого мог только раз 5. По идеи это должно привести в удвоению потребления ресурсов\минералов.

UPD хотя почему то все пишут что страховка станет дороже.
Вообще общий посыл как мне кажется в том что майнить станет выгодней и именно майнеры будут определять кол-во минералов, а репроцес всего и вся.

Автор темы	Похожие темы	Форум	Ответы	Дата
E	Мышь, клавиатура Движение в майнкрафт	Разработка ботов	2	31 Янв 2022
H	Нужна программа которая запускает бота на опр сервер (майнкрафт)	Стол заказов	1	3 Май 2021
	Майнер бот, от вермишели до ии	EVE Online	19	7 Апр 2019
Z	Майнинг Бот By Zuzik	EVE Online	13	11 Май 2010
	Майнер бот. Эволюция от примитивного до умного.v2.5	EVE Online	230	10 Май 2010

Майн-бот

Продвинутый

Модератор

Продвинутый

Продвинутый

Модератор

Продвинутый

Модератор

Новичок

Модератор

Новичок

Новичок

Модератор

Новичок

Новичок

Новичок

Продвинутый

Продвинутый

Новичок

Новичок

Новичок