GPCracker

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

Картофель считает изменение сцены дискретно с интервалом. А тебе нужно определить точку пересечения снаряда и противника, при условии, что ты стреляешь прямо сейчас (задержка 0.0). Это задачи разного порядка. В картохиной баллистике учитывается только скорость снаряда и гравитация. Сопротивление воздуха, закрутка снаряда, вращение земли, разная плотность слоев атмосферы не учитываются. То-есть снаряд летит строго по параболе. Это уже описывается квадратным уравнением. Второе квадратное получается исходя из того, что решается т.н. торпедный треугольник (то, что реализовано в снайперском режиме, там гравитация и кривизна траектории не учитываются, или считаются упрощенно, для арты такое недопустимо, т.к. будет слишком большая погрешность). В итоге уравнение четвертой степени и неслабенький такой матан (можешь погуглить). Описывать его на языке программирования, а потом еще и оптимизировать вычисления с точки зрения процессора - времени уйдет очень много. Потому что решать такое уравнение с интервалом в 0.03 сек (обновление GUI, ЕМНИП) это тебе не в тапки *****, калькуляторы загнутся 100%, а так не интересно. А повесить такие вычисления на MatrixProvider'ы не получится, т.к. расчеты нелинейные. Картоха там тоже понемногу думает перебалансить арту, ибо баттхерта в ее сторону в последнее время очень много, причем как от тяжеводов (криты/урон), так и от артаводов (хрен попадешь). Так что м.б. это временная мера, ибо нагибает (по мнению картохи). И чем лично мне арта не нравится - от твоего скилла ничего не зависит, все зависит от вбр (в большинстве случаев), а картоха все подгоняет под средний (раковый) дамаг. Т.е. играть вообще не интересно, проще взять Т-54 / Т-62А / 140 / Бата / ... взводом и пойти убивать ТТ/СТ. В разы веселее, чем сидеть и кликать одну кнопку (ну переезжать еще периодически) в надежде на склонность ВБР. И фарма больше будет, если голдой направо-налево не шмалять.

Респект. Однозначно плюсану, хоть и в танки давно не заходил.

1. Маркер упреждения для арты рассчитывается через решение уравнения 4 степени. Большая вычислительная сложность. Вероятность 90% что фпс на калькуляторах ляжет на дно. А писать мод для суперкомпьютеров только не совсем корректно, согласитесь. 2. В моде есть скалярная скорость, векторную поломали. Поэтому маркер упреждения в снайперском не работает. 3. Если арта будет еще и по маркеру стрелять, тяжеводы и не только будут люто негодовать, так как раки и олени тупо пользуясь одной кнопкой, будут попадать чаще. А опытные артоводы и без всякого маркера накинут даже по ЛТ (если повезет с разбросом). Учитывая что я в последнее на арте играю крайне редко и то взводом для ЛБЗ (из-за большой рандомности и скучного геймплея), либо что-то тестирую, и моего скилла мне хватает для стрельбы по тяжам в движении, особой необходимости в таком маркере лично у меня не возникает. За всем этим следует вывод: реализация маркера для арты не оправдывает на данный момент затрат на нее. Качайте скилл. Если в будущем разрабы как-то перебалансят арту и сделают ее более интересной в плане геймплея и уменьшат рандомность этого класса (при 100% правильном прицеливании результат может находиться в промежутке от сплеша без урона до ваншота - как по мне - это слишком большой рандом), не исключаю возможность реализации маркера упреждения. На данный момент складывается такая ситуация - работа сложная, а личной заинтересованности (по большому счету) и свободного времени на нее нет. В танки не заходил наверное уже недели 3-4. Да и в последнее время мне кажется что в них я больше себе нервную систему убиваю, чем получаю удовольствие от игры. Расчеты по наведению где-то были, по возможности скину.

Это в лучшем случае КТТС. Нескоро будет. Но теоретически возможно. По крайней мере в текущем проекте (то, над чем сейчас работаю) подобная флешка робит нормально. Что касаемо поддержки - не знаю, с двумя принципиально разными версиями проекта параллельно очень сложно работать. Так что скорее всего переход будет резкий, но постараюсь упростить процесс. Флешка там несложная, тем более что весь нужный код (кроме пользовательского, привязанного к конкретной анимации) я напишу сам, а нарисовать картинку/анимацию - гайдов в инете достаточно. Для разработки там без проблем хватит AS 2.0 / Macromedia Flash 8.0. По крайней мере для боевого интерфейса. Для ангара - нужно поновее, уже адоб, там AS 3.0 и для большинства задач хватает Flash Develop, ибо рисовать там приходится очень редко. Опять же: все КТТС. Кстати, как правленый вариант? Работает?

Времени немного, да и в разработке сейчас другой проект висит, плюс нехилая куча задач. Переработать мод в принципе неплохая идея, но в любом случае отдельно от данного проекта, т.к. задачи модов абсолютно разные, и общего кода там будет менее 5%. Не исключаю вариант перехода на флеш, если к тому моменту разрабы ничего сильно не перепилят. Рисование конечно станет намного сложней, для юзеров и в несколько раз проще для тех, кто может во флеше. Ибо не нужно будет рисовать кучу картинок, анимация без проблем пишется скриптом (Tween).

Картоха как всегда. Переименовали пару классов.

Попробуй это, скинь лог)) AnimatedSixthSense.zip

GetText конвертишь в *.po, если нет линуксы, прокатит MinGW или что-то подобное... Либо онлайн сервисы. *.po - обычный текстовый файл, редактируется блокнотом и потом тем же макаром пакуется обратно. Почитай про пакеты локализации, погугли GetText)) Онлайн сервис для этих целей))

ХЗ. Может уже пофиксили. Но пару-тройку патчей назад не мог с локального FTP получить содержимое файла, через консоль все работало отлично, а в клиенте никак.

Хммм... А зачем? ResMgr и то, и то нормально хавает? Разве нет?

Я не об этом, я про класс Loader из стандартного набора. Ссылку на доки выше кидал. Смотри контексты (Context / Ctx), копай питон игры. Там есть уже готовые функции. Если прям очень сильно надо, могу поискать, но будет гораздо интереснее, если ты найдешь их сам)) ((( У тебя в "исходниках" только питон, тут о Flash речь идет. Кстати, кому нужны исходники, могут заглянуть сюда. Вот-вот. Для получения большинства AS3 классов нужно декомпильнуть hangar.swf, application.swf или lobby.swf (какой точно не помню). Но при этом не стоит забывать, что код в этих классах может описывать поведение графических элементов, созданных во флеше (подключение базового класса к Flash-объекту). Скорее всего потому и запилили XVM библиотеку... Чтобы графика не терялась. Я тоже одно время пытался запилить скрол-пэйн (UI со скроллом), у меня нифига не работало, какие-то ошибки (сейчас уже не помню) вылетали иногда, да и дебаг флеша тогда не включал (уровень лога). Скорее всего это из-за "потери" графических элементов, к которым привязывался этот класс... Или что-то типа того. Потому что я видел картину типа "переменная есть, ее значение никто не определяет, а используют". Так же делают, когда класс подвязывают к графике. Я во флеше не особо разбираюсь, не так давно начал копать в эту тему, еще не успел толком разобраться... В Орионе работает... Точнее: в Орионе или трансмиттере / клиенте? ...кидаешь в папку с игрой... Куда кидаешь? Загрузчики на месте? ...import requests... Ты уверен, что в клиенте игры есть такой модуль? У тебя там не ImportError случайно сыплется? Что делать? - Если проблема в импорте - то либо впилить модуль в игру, либо написать на тех модулях, которые там уже есть. Если модуль pure-python, без зависимостей, то вообще никаких проблем. Закидываешь в res_mods/0.9.9/scripts/common/Lib (ЕМНИП, посмотри, этот путь уже прописан в sys.path) и все ништяк будет. Главное не накосячить и не кидать ничего мимо папки res_mods. Там с urllib / urllib2 какие-то косяки есть на уровне протоколов (ftp кажется не фурычит, в свое время тоже неслабо мозги кипели). И у Ориона есть проблемы с кодировками... Про Unicode вообще молчу. Хотя я не совсем понял, что ты имеешь ввиду... Какое окно? Какой текст? urllib всего лишь выполняет запрос и выдает сырое содержимое ответа. И работает только с прямыми ссылками, что есть очень большой минус, учитывая неработоспособность ftp в клиенте (х.з. куда файл закинуть, локальный FTP при дебаге не катит)

*.xml и *.def А что кроме этого?

Угу. В AS3 упростили загрузчик немного...

Данные туда поступают, когда ты их туда посылаешь. Эту функцию ты вызываешь из питона. По сути должно работать и прямая (из питона) установка текста твоего поля. Никакой сложности, базовые объекты такие как списки и словари (не уверен, но скорее всего) нормально воспринимаются AS, так что ЕМНИП можно их спокойно туда отправлять. Главное - правильно настроить приемник. Сериализацией / десериализацией / преобразованием типов объектов занимается DAAPI, так что за это не парься. Определяет конструирование UI. Именно тут по сути должно писаться все создание интерфейса. Поменять / установить дополнительные параметры можно потом (когда надо будет), но основное задается здесь. Т.е. тут ты определяешь, как будет выглядеть пустая болванка. Принцип называется DAAPI (Direct Access API). Работает, как видно из названия, по принципу "прямой доступ". Т.е. при помощи C-части движка flash (AS) связывается с Python, т.е. ты имеешь доступ к объектам, при изменении свойств которых / вызове методов C-часть преобразует формат переданных тобой данных, и выполняет действие в другой части "мостика". Опуская существование невидимой C-части, можно сказать, что ты напрямую вызываешь методы, описанные на другом языке, данные преобразуются автоматически. Как это выглядит: Python -> AS3: У тебя есть flashObject. Все свойства и методы базового класса (если я это правильно назвал) (или почти все), будут доступны в питоне через этот объект. AS3 -> Python: Ты определяешь в базовом классе флешки методы, которые будут перегружены питоном (декларируешь переменные). Поэтому достаточно определить их как переменные и указать их тип (Function), вместо нормального определения метода. Далее при подключении флешки DAAPI находит такие методы и перегружает их. Насколько я понимаю, через базовый класс доступны все функции питона, имена которых определены как переменные в AS3 классе. И если я не ошибаюсь (не уверен, не проверял), все методы, имена которых совпадают с питоновскими, будут перегружены питоновскими (что произойдет, если в питоне будет метод одноименный со "стандартным", например, configUI, тоже не могу сказать, не тестил). Опять не совсем все понятно с модификаторами (private public overload static ...), я в AS не особо шарю, так что не могу сказать, как они влияют на этот процесс. М.б. масштабирование?

Один вариант предложил ShadowHunterRUS. Второй - использовать пустой MovieClip и MovieClipLoader (для AS2). Наверняка у картохи в AS3 тоже должны быть готовые классы UILoader или что-то подобное. Таким макаром подгружаются иконки снарядов на панельку в бою)) Для AS3 - еще проще Если картинку нужно запихнуть во флеш, есть Embed, ЕМНИП. Давно FlashDevelop не юзал.

А разве нет стандартного обработчика... ЕМНИП, в питоне вроде было такое...Да, глянул коды ВГ. def onWindowClose(self): self.destroy() З.Ы. Глянул в старых тестах, данный код тоже присутствует. Закрытие точно работало. Пару патчей назад. Не думаю, что серьезно перекопали.

Для понимания проблемы в большинстве случаев достаточно скинуть все блоки ошибок, содержащие имя файла мода, повторяющиеся можно просто отметить комментарием, с сохранением порядка. Если нужен будет полный, я отпишу (ну или кто другой, кому хватит знаний вам помочь). Приоритет - блоки, в которых имя файла мода упоминается в предпоследней строке блока (последней "сдвинутой") - это файл, в котором как раз и была инициирована ошибка. Т.е. если ошибка возникает в моде, в предпоследней строке блока указано имя файла AdvancedAimingSystem.py или AASMX.py. Блок начинается с Traceback (most recent call last):и заканчивается типом ошибки и тексовым комментарием TypeError: 'NoneType' object has no attribute '__getitem__' Эта ошибка возникает при рассинхронизации: не удалось получить вектор высоты техники - техника была удалена (ушла из засвета / квадрата отрисовки). Если никаких видимых проблем не вызывает - просто игнорируем. Неверно задана последовательность клавиш (хоткей). Проверь правильность всех имен клавиш и общий синтаксис хоткеев (плюсы обязательно и только между клавишами, модификаторы только контрол, альт и шифт). Без указания типа ошибки конкретней не могу сказать. З.Ы. Модификатором считаются все, кроме последней клавиши.

a. прописать в sys.paths б. прикрутить к питону, подключенному к программе (использовать внешнюю среду, terminal->settings, ЕМНИП)

Чувствую тут скоро появится @Mr 13 и будет отстреливать особо буйных... Почти 2 страницы уже.

Тебе только повод дай) С нетерпением ждем новые шкурки!

@StranikS_Scan,

Общий тест это одно, а основа - это другое. Еще скажи что на тесте голдой стреляют реже чем на основе. Никто не поверит.

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

Насколько я понимаю, все обновления питона 2.7 - это фиксы багов... Так что мне кажется все должно в принципе работать. Но перестраховаться и версии выровнять никогда не мешает) Возможно, он либо поставил не ту версию (х64) питона, либо не прописал пути к пидам. Та фича с копированием dll по сути снимает необходимость пути к пидам провисывать каждый раз в sys.paths. По крайней мере у меня так все фурычит норм. Я поначалу тоже как-то хитро выкручивался с путями, когда разбирался почему пиды не работают...