GPCracker

@Crus, в этом порядке проглядывается некоторая логика, если сравнивать с выводом set для того же набора элементов... такое ощущение, что это list(set(keys))... или что-то подобное. Просто на разных версиях и других условиях это поведение, как и хэш-функция, на которой базируется set, скорее всего может несколько отличаться, т.к. оно не задокументировано, нужно смотреть исходники питона. Но вот насчет чего я точно уверен - так это в том, что картошка как всегда.

А что именно возвращает? Пример есть? Я просто немного не на винде, но интересно же :)

Большие правки?

Именно так. Сортировка занимает весьма приличное количество ресурсов. Хотя в данной ситуации это не особенно важно - здесь нет жестких требований по скорости работы алгоритма дедупликации.

Как по мне - рядом с reversed в built-in.

Юра, на номерах строк на GitHub есть ссылки, если что. И да, этот вариант я тоже видел, правда написан был чуть по-другому. Плюс того варианта, что привел я - он относительно короткий. Минусы - скорость. Варианты с добавлением с set или list быстрее, по крайней мере на небольших объемах данных. Нативный вариант реализации в виде генератора был бы существенно быстрее, особенно на больших объемах данных. В любом случае, похожий алгоритм используется при создании set. Почему его не добавили в питон, учитывая что это типовая и широко используемая функция - непонятно. Вы тут с пакетами модификаций играетесь, а я вот сижу лишние пакеты из системы вычищаю...

Картошка как всегда. Вообще для этих целей существуют функции типа unique, различные варианты реализации которых можно без проблем найти в гугле. Не самый быстрый, но один из самых коротких вариантов. uniques = lambda entries: sorted(set(entries), key=entries.index) З.Ы. Я один не вкуриваю, какого **** *** *** в питоне нет built-in генератора unique по принципу того же reversed?

Хмм... .ipsType_richText a { color: inherit !important; } По идее этого должно быть достаточно :)

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

Если даже картошка танки в 1.0 только обещает, и один раз с этой версией они даже об******ся успели (нет никакой уверенности что не получится очередной "рубикон" и в этот раз), что уж говорить о модах, которые не в состоянии выбирать, с какой версией клиента им удобнее работать, приходится работать на том, что "у танков в продакшне". Как следствие, одной только "форсированности обновления клиента" достаточно, чтобы убить наповал весь правильный процесс разработки с адекватным тестированием. Отсюда и получается, что если танки в бете, моды выше альфы (речь про уровень стабильности) не в состоянии подняться, если танки таки выйдут в релиз - выше беты по стабильности ну никак не прыгнуть. Про стабильность кода от WG думаю не нужно рассказывать, сам не по наслышке знаешь :) Что насчет четвертого года - так за четыре года много новых фич появилось. Многое изменилось. Процесс идет, разработка не стоит на месте. Просто тесты на стабильность ну никак не получается нормально прогонять - к моменту, когда уже в принципе можно назвать сборку относительным стейблом, картошка подгоняет очередной патч. Не говоря что после добавления новых фич это сразу сброс до уровня альфы, потому как нужно все обкатать. Это тебе не какой-то там простенький мод, где уже несколько лет никаких изменений в алгоритмах не было - тут раз в несколько месяцев накатывается немаленькая обнова с кучей различных новых функций. Тут не спонсорская помощь нужна, а скорее толковая система работы с релизами, версиями и т.д. Придумать что-то реально толковое, с учетом того, что рабочая среда (клиент игры) обновляется форсированно, а не "по необходимости", как у любого другого адекватного софта, пока не удается. Обнова, которая сейчас находится в статусе подготовки к релизу, устраняет практически все оставшиеся жесткие связи между модулями. Это дает возможность жестко отключить через конфиг все ненужные/сломанные модули, не затрагивая при этом критическим образом остальные. Собственно, это дает возможность "пережить патч", ценой потери части функционала, даже если в течение некоторого времени я не смогу выпустить необходимые фиксы. От критических изменений, это, конечно, вряд ли поможет, а вот от мелких правок в конкретных модулях игры - вполне. Даже тот патч с многобашенностью, который сломал чуть менее чем все, можно было бы пережить, если бы не один мелкий хвост, который я тогда еще не успел окончательно перевести в "динамику" - упал модуль данных сведения, а он был жестко прилинкован к модулю gui, как следствие потащил за собой весь графический интерфейс, основной модуль работал, но без gui от него толку было немного. Надеюсь, что в 1.0 они не притащат огромную гору изменений в питоне или BigWorld API, из-за которой придется перепиливать половину нижнего уровня.

В принципе, как временное решение можно использовать udisksctl, но решением это назвать сложно - пинать каждый раз командную строку... udisksctl unmount -b /dev/sdb3 && udisksctl mount -b /dev/sdb3 -o dmask=022,fmask=133 remount () { udisksctl unmount "$@" && udisksctl mount -o dmask=022,fmask=133 "$@"; }; remount -b /dev/sdb3 Хотя с другой стороны влияние флага исполняемости на работу графической оболочки пока не замечено, там все равно используются mime-ассоциации. Проблема по большей части именно консольная. Но тем не менее, писать каждый раз команду на перемонтирование... как-то неправильно, да и неудобно.

@Mr 13, раз тут речь про цитаты и код, не буду создавать отдельную тему для мелкого пожелания. Возможно добавить Bash и Batch (батники винды) в список поддерживаемых языков? И кстати, было бы прикольно, если бы чисто для себя можно было подрубить дополнительный скрипт, но не через браузер, а глобально, чтобы работало при логине с любого устройства. Это бы отчасти решило проблему нехватки настроек и необходимости постоянно что-то куда-то переключать, например тот же "язык программирования" при создании элемента "код".

Все просто же :) Если версия финализируется (ее прекращают править) в конце недели, а выходит в релиз во вторник, а я сильно сомневаюсь, что у вас работают по выходным, значит "на детально и скрупулезно протестировать финальную версию" остается только понедельник, что само по себе с логикой никак не вяжется (даже если и с выходными), и то, я полагаю, релиз отложат разве что если найдут major security issue. Отсюда следует простой вывод - версия выходит на релиз сырой, поэтому и катятся микропатчи в процессе. Насколько мне известно, в большинстве серьезных проектов есть правило, что версия уходит в релиз, если с момента исправления последнего найденного существенного бага прошло не менее определенного времени, достаточного для полного тестирования, и в течении этого времени новых багов найдено не было. @ribbed, кстати, у вас там не задумывались над темой упрощения отправки баг-репортов, скажем из лончера, или клиента игры? Просто логиниться на форум, создавать тему, а потом еще и следить за ней, для рядового пользователя это долго и геморно. Гораздо проще нажать пару кнопок в лончере. Например, как сделали в Escape from Tarkov? Или это не делается из-за "проблем с целевой аудиторией"?

Не надо тут... Caps'ить, ... не в лесу :)

Собственно, вопрос к опытным пользователям Linux. Сам использую относительно недавно, в тонкостях еще толком не разобрался, поэтому прошу сильно не пинать. Недавно обновил свой Debian с Jessie до Stretch. Одним из замеченных существенных изменений стало изменение дефолтных прав доступа при монтировании ntfs - все файлы по умолчанию стали исполняемыми (x-flag, execute permissions), хотя никаких конфигов по этой части я не трогал. Речь идет о монтировании через графическую оболочку, KDE. Почему это внезапно стало проблемой? Очень большая вероятность случайно ввести имя файла, не указав программу для запуска, и если при этом это будет текстовый файл без шебанга, баш начнет его весело выполнять, со всеми вытекающими последствиями. Что ну совсем не круто. Из анализа параметров mount, udisksctl и т.д. выяснил, что для решения проблемы нужно дописать в параметры монтирования dmask=022,fmask=133. Но есть одна очень существенная проблема. Прописать это в fstab не вариант, потому как это касается не конкретного раздела, а вообще любого ntfs-раздела. Монтирование вручную не рассматривается в принципе, как и другие аналогичные варианты. Из анализа структуры всего этого дела было установлено примерно следующее (прошу не пинать сильно, если где-то ошибся): "монтирование" из графической оболочки через D-Bus пинает демон UDisks2, который собственно получает данные из udev и монтирует раздел в отведенную для него папку. Найти какую-то адекватную информацию по файлам конфигурации для ntfs-3g тоже не получилось, есть сомнения что они в принципе существуют (а все параметры передаются через командную строку). Дефолтные опции для ntfs в самом UDisks2 прописаны в исполняемых файлах, и как их поменять через файлы конфигурации я не нашел (может быть плохо искал), а вариант с пересборкой пакета не рассматриваю по вполне понятным причинам. Утилита udisksctl без проблем принимает на вход необходимые дополнительные параметры, но опять же, это "ручной вариант", а в данном случае нужно (насколько я понимаю) прописать их по дефолту для всех ntfs-filesystem. Взаимодействие между KDE и UDisks2 осуществляется через D-Bus, на тему перехвата и подмены сообщений тоже ничего адекватного найти не удалось. Если такое вообще возможно. Ну и собственно, можно ли прописать где-то опции монтирования в KDE, или там тоже очередной хардкодинг, выяснить пока не удалось. Вопрос, как уже многие догадались, звучит достаточно просто - как и где можно прописать опции монтирования по умолчанию для конкретного типа файловой системы, не привязываясь к конкретному тому/диску/etc, и не редактируя исходники, чтобы эти опции применялись желательно только при монтировании через графическую оболочку?

То есть финальное тестирование как таковое отсутствует, все допиливается вплоть до даты релиза? Тогда понятно, откуда такое количество багов...

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

@Mr 13, а можно как-то вынести это дело в настройки? Лично мне этот резкий синий цвет иногда взрывает мозг, а ссылки я и в старом дизайне нормально видел. Вариант с менее яркой расцветкой просто необходим, слишком большое количество абсолютно разных цветов очень сильно дезориентирует. Серый сайт... и синие ссылки. Например, оставлять ссылки того же цвета, что и текст, но при этом делать подчеркивание похожего, но отличимого цвета, чтобы было заметно, что это не просто подчеркнутый текст, но чтобы при этом не разъедало глаза контрастностью. @Mr 13, есть еще одна небольшая просьба. Создать отдельную тему-лог, и туда постить инфу обо всех изменениях на форуме (в том числе планируемых), которые заметны пользователям, со ссылками на обсуждение вопроса. А то старую общую тему предложений прикрыли, все в новых темах постится, а в разделе еще кучу всяких вещей публикуют... Или хотя бы вынести все предложения в отдельный подраздел, отделив их от вопросов и т.д. Чтобы можно было спокойно подписаться и не получать при этом кучу ненужных уведомлений.

Находишь там код, который описывает содержимое окна редактирования сообщения и правишь ручками :)

Ctr+Shift+I

Увеличение параметра ускоряет процесс реакции камеры на перемещение мыши (уменьшает "подтормаживание" камеры), делает камеру более резкой. Применимо только для баллистического режима, в стратегическом интерполяция отсутствует (в стратегическом режиме камера жестко привязана к курсору). По сути данный параметр вносит изменения в одноименный параметр во внутреннем конфиге баллистической камеры (картошка выносит в настройки игры далеко не все параметры, точнее их малую часть). По сути, сама по себе интерполяция вызвана криворукостью разработчиков картошки, которые сделать все аккуратно на MatrixProvider'ах они не смогли, и попытались так замаскировать тот факт, что маркер прицельной сетки далеко не сразу устаканивается в нужную точку, причем на слабых машинах это выражено значительно сильнее. Но такая маскировка приводит к тому, что при резком перемещении камеры приходится ждать, пока она устаканится. По факту, там нужно полностью переделывать весь режим прицеливания, но это слишком неэффективно, ибо большое количество правок, которые невозможно внести без полного оверрайда некоторых методов, делают процесс сопровождения кода (обновление под новые патчи) слишком затратным по времени, а сам код слишком нестабильным и "очень вероятно конфликтным" по отношению к другим модификациям. При активации корректировки прицеливания в режиме сопровождения цели к координатам точки прицеливания добавляется вектор высоты танка, умноженный на это число. Подробнее данный момент уже обсуждался ранее, есть даже картинка под спойлером. При активации этого параметра танк противника при расчете точки прицеливания учитываться не будет. Стандартно при наведении на танк противника прицеливание идет на середину высоты танка в точке прицеливания, при активации этого параметра - в землю под танком. Этот параметр также описан по ссылке выше. При активации параметра корректировка точки прицеливания в режиме сопровождения цели также будет работать и при непосредственном наведении на танк противника (в случае, когда этот параметр неактивен применение корректировки по высоте при наведении на противника бессмысленно - точка прицеливания и так уже поднята над землей алгоритмами картошки). Собственно, этот параметр полезен в двух случаях - если игрок привык "заводить за танк", а не наводиться непосредственно на него, либо для выравнивания алгоритмов расчета при корректировке в режиме сопровождения цели - чтобы при пропадании танка из засвета, либо когда противник ерзает в прицеле, точка прицеливания оставалась стабильной, а не прыгала в зависимости от высоты танка противника в точке прицеливания. В отличие от аркадного или снайперского режимов прицеливания, где ручная и автоматическая корректировка (сопровождение захваченной AAS цели) выполняются аналогично, в стратегическом режиме прицеливания между ручным и автоматическим режимами имеется важное различие - в ручном режиме точка прицеливания фиксируется по абсолютной высоте (может быть использовано для стрельбы под различные "крыши" без перехода в баллистический режим прицеливания), а в режиме сопровождения - по относительной высоте над поверхностью земли (позволяет стрелять на упреждение в борт противнику, а также препятствует перенаведению в землю под танком при пропадании противника из засвета). Механики, связанные с сопровождением цели, раньше были очень эффективны при использовании ББ снарядов, в текущей реализации артиллерии их применение достаточно специфично, так как случаи, когда нужно попасть именно в танк, а не в землю под ним, стали очень редкими.

Все предельно просто, даже проще чем "проще пареной репы". Его там попросту нет, то, что ты видишь в конфиге, это шаблонная заглушка. Класс, который для режима arty используется - по сути только наследует класс интерфейса корректировщика прицеливания, и ничего по большому счету не делает. А базовый код и параметры в конфиге добавлены исключительно для симметричности, чтобы не было определенного рода ошибок и "персональных подходов" к некоторым элементам, и в качестве задела на будущее. В частности, все информационные панели объявляются идентично (разве что с разными именами), но при этом панель сведения в режиме arty работает, сканер в принципе тоже, а вот дальномер [пока] нет, и поэтому гораздо проще и правильнее создать заглушки и работать с ним как с остальными, чем прописывать ему отдельные хэндлы. Пока каких-то идей на тему того, что в arty нужно корректировать и как нет. Будут - допилим шаблон-заглушку до "боевого" состояния.

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

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

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