coJlHe4Hblu_noH4uk

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

Есть еще одно красивое решение - при редактировании никнейма в конец никнейма дописывать клантег. Тогда человек будет его сознательно удалять/редактировать и т.д.

@Mr 13, да. У игроков других кланов нет клантегов. Думаю, что клантег нужно оставить, оставить всем, но есть предложение. Переместить клантег перед ником - будет каша, если не изменять порядок сортировки. Оставить после автоматически - потеряется возможность настройки клантега, что некоторым пригодится. Я бы сделал, к примеру, своим сокланам красивую звёздочку или что-то типа этого. Есть идея сделать еще одно поле для клантега.

@sirmax, в принципе, не ошибка, можно вручную вбить. Вдруг некоторым и клантег поправить нужно?

При изменении ника трет клантег. Или так и задумано? Не критично.

@Kradar, любой модпак типа жопвмодпак.

@MakcT40, шаблон. Ну не ругается же.

@Kradar, кинул в \World_of_Tanks\res_mods\0.9.3\scripts\client\mods\SampleMod.pyc import BigWorld from gui.WindowsManager import g_windowsManager Запустил WoT, всё гуд. Лог норм: /------------------------------------------------------------------------------------------------------------------------\ BigWorld Release Client (compiled at 15:29:52 Sep 3 2014) starting on Tue Oct 07 22:54:40 2014 Content Type: content Checking ./res_mods/0.9.3: mods found Load mods: SampleMod [NOTE] (scripts/common/fortified_regions.py, 188): fortified_regions.init() [WARNING] (scripts/common/DestructiblesCache.py, 478): Failed to read fractureEffect name in content/Environment/env414_Pole/normal/lod0/env414_Pole.model [WARNING] (scripts/common/DestructiblesCache.py, 478): Failed to read touchdownEffect name in content/Environment/env414_Pole/normal/lod0/env414_Pole.model [WARNING] (scripts/common/DestructiblesCache.py, 478): Failed to read fractureEffect name in content/Environment/env414_Pole/normal/lod0/env414_Pole10.model [WARNING] (scripts/common/DestructiblesCache.py, 478): Failed to read touchdownEffect name in content/Environment/env414_Pole/normal/lod0/env414_Pole10.model [NOTE] (scripts/client/post_processing/__init__.py, 267): The quality = 2 was selected. [NOTE] (scripts/client/post_processing/__init__.py, 267): The quality = 3 was selected. [SPACE] Loading space: spaces/hangar_premium_v2 PostProcessing.Phases.fini() \------------------------------------------------------------------------------------------------------------------------/

А в чем особая надобность именно в __init__.py это делать?

from gui.WindowsManager import g_windowsManager Ошибка точно не тут. А что вообще импортируете?

Я за rating.xc, 55/45.

, перебор.

Предлагаю примерно такой вариант: добавить кнопку "сохранить для всех игроков группы"; (опционально, т.к. тут все упирается в вопросы этики и приватности данных) - добавить кнопку "импортировать настройки командира клана" для клановых игроков, которая импортировала бы только альтернативные никнеймы, если они прописаны командиром. В принципе, ничего страшного, если командир обозвал у себя половину игроков матом, от таких нужно уходить, поэтому можно оставить. Если же игрок, согласно вышеозвученному предложению сам добавил себе альтернативный ник и комментарий - импортировать их; Добавить поле для альтернативного нинейма, суть предложения я описывал, единственное отличие - данные будут храниться на сервере. Вот что получилось нарисовать под это дело (отличаются одной кнопкой): UPD 1. Никнейм под полем "Изменить комментарий" - сделайте тень как в заголовке, а то выбивается. UPD 2. Надписи "отмена" и "сохранить" выглядят съехавшими вверх.

Если это в рамках одного функционала, сюда можно пару предложений?

Раз уж тут есть хорошее окошко для редактирования, то может быть в него добавить второе поле для ввода и реализовать вот это: http://www.koreanrandom.com/forum/topic/18884-кастомизация-никнеймов-для-гк-рот-кб/ ? Темы ну очень похожи, за исключением того, что измененный ник ещё и в бою будет.

@psix89, спасибо.

А скоро, это как скоро? И вопрос вдогонку, что лучше для девелопинга на мощный комп поставить, кубунту или минт? И списочек IDE для пайтона киньте сразу, чтоб с автодополнением, для нуба, а я уж выберу из него. Спасибо!

Какие файлы отвечают за это?

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

Нашел мод, написанный где-то и кем-то, в общем, не суть. Мод с определенным интервалом выкидывает в общий чат сообщения о приглашении в клан. Решил, что называется, переделать его под себя, заодно начал разбираться в python'е, поэтому не судите строго, кирпичи и помидоры принимаются с пояснительными записками. "Декомпилированные запчасти (их мало, поэтому текстом):" Сабж, собственно в том, что хочется мне оформить это одним файлом, который будет грузиться из папки mods обычным загрузчиком. Споткнувшись о python'овские пространства имен, файлы __init__, пакеты и другие вещи прошу помощи, лучше если это будет объяснение, что, к чему, как и почему. res_mods.zip

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

Сабж в заголовке темы. Т.к. помимо самого пинга немаловажную роль играет еще и его стабильность, то это было бы полезной фичей. Пример: RU1: 17 (2) RU2: 15 (4) RU3: 87 (9) RU4: 37 (2) RU5: 19 (1) RU6: 18 (2) RU7: 22 (5) RU8: 54 (8) Для тех, кто не в теме (из вики):

Тогда им придется переписать и эффект попадания / рикошета снаряда по танку. Сейчас, если приглядеться, то можно увидеть, что в эти эффекты передается точный (!!!) вектор вхождения снаряда в танк для правильного отображения. Так вот, если WG пересмотрит эту фичу, то и эффекты им придется менять с "точных" на абстрактный "скидыщ" по танку. А исходя из того, что WG наоборот, только совершенствуют техническую правильность и красоту подобных эффектов, можно сделать вывод, что данную информацию читом они не считают. А вообще, как такового, преимущества это не даст. Есть мод, отображающий как раз линию прилета снаряда. Типа трассера, только от незасвеченных противников. Видел его в работе, абсолютно бесполезная вещь. Т.к. траектория снаряда идёт по дуге, точно он ничего не показывает (например, если прилетает от арты - палка "торчит" вверх). А ты уже сиди и угадывай. Известен только азимутальный угол, при отсутствии зенитного от этого толку мало. Лучше ограничивать не границей карты, а квадратом отрисовки.

только для хранения значений, которые RGB. Объясню почему. Красный в RGB это ff0000. Но в природе есть "еще более красный", но для красного 255 - и потолок, краснее не сделаешь.Но в пространствах Lab, LCh, XYZ он есть. При этом, чтобы в RGB у тебя не было чисел больше 255, есть код: if r < 0 then r := 0; if r > 1 then r := 1; if g < 0 then g := 0; if g > 1 then g := 1; if b < 0 then b := 0; if b > 1 then b := 1; Т.е. он обрезает выходящие за диапазон значения. А обрезать их можно только в случае вывода на экран циферок или при рисовании цвета. А при преобразовании Lab в LCh - там RGB вообще не нужен в расчетах. Вообще, допустим я изменил L, C или h - при этом остальные поля должны обновиться в следующем порядке: Lab. из Lab'а мы считаем RGB. из RGB - HSB/HSV/HSL/CMY/CMYK в любом порядке. Но если после этого я тронул RGB, то "волна" расчетов должна идти от него.

Хорошая идея.