GPCracker

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

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

Может у тебя установлено 2 safeShot?

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

Текстуры окружения. Для этого есть снайперский режим. Блокируется, когда в сведении не показана толщина брони. Т.е. между игроком и противником есть препятствия.

Если маркер орудия (сведение) находится на на текстурах в аркадном режиме, то выстрелы блокируются. Простреливаемость не учитывается. В установке расстояния смысла нет.

-Добавлена возможность настройки текста причины блокировки выстрела. -Изменена логика работы SafeShot, исправлена блокировка стрельбы по трупу союзника, добавлена функция отслеживания наведения орудия для блокировки дружественного огня. -Исправлена блокировка выстрелов при удерживании кнопки стрельбы. -Частично исправлена проблема с триггерным режимом кнопки сброса автоприцела. -Добавлена возможность выхода из снайперского прицела на артиллерии, по той же кнопке, что и вход в режим. -Добавлен случайно забытый в коммите 20932e5 файл "AdvancedAimingSystem-M/Hook-RadialMenu.py" (в собранной версии коммита все ОК, проблема только с репозиторием). 79a129f.zip Yeah. I've forgot to add (stage) a new file to a commit. Fixed. Thanks. You could change language of interface at the top of a page in left corner.

Недавно писал что-то в SublimeText 3... Внезапно обнаружил консольку с питоном)

Прям как у нас в универе некоторые преподы с большим интересом рассказывают про микросхемы 155/74 серии... И ни слова про микроконтроллеры.

Thanks for the reply. You could just left a new function request here, and if function is useful and implementable, it will come soon as an update. All bugs could also be reported in this topic, in accordance with bug report rules. Here are not many users who understand python language, so you could use spoilers or PM, because it's useless information for most of topic visitors. Any way, they will wait for an update. Your suggestion will be applied soon.

Я предлагаю вообще не интегрировать питон в Орион, а запускать его дочерним процессом с перехватом потоков ввода/вывода/ошибок. С процессом по сути ты работаешь, отправляя ему в поток ввода код, и забирая результат с потока вывода/ошибок. "Перенаправление потоков ввода-вывода процесса (Python)"

Может реально запускать питон дочерним процессом и перехватывать потоки? Подобным образом

Отсчет от центра, числа любые, в диапазоне от -1 до 1. Табличка показывает координаты углов и середины экрана. Координаты от центра экрана. НЕ от маркера, а от геометрического центра монитора. Первое число 0 означает что по горизонтали надпись по центру. Второе число 0,25 показывает, что надпись чуть выше центра по вертикали на 1/4 половины (1/8) высоты монитора. Координаты правого верхнего угла монитора +1;+1, левого нижнего -1;-1.

А чем не вариант безоконный запуск питона с перехватом потоков ввода/вывода/ошибок? Помню как-то делал так, правда на C#. Ведь по сути получится то же самое?

-1;+1 +0;+1 +1;+1 -1;+0 +0;+0 +1;+0 -1;-1 +0;-1 +1;-1 Последняя координата - уровень слоя (передний план/задний план), ЕМНИП. Первая Х, вторая У Цвет в формате RGBA (Red-Green-Blue-Alpha)

1. Операции проецирования есть. Только не в модуле Math, а написаны на питоне как матричные вычисления в файле scripts/client/AvatarInputHandler/cameras.py 2. Проблема с проецированием контура. Хотя думаю вполне возможно заюзать BoundingBox, прямоугольник вокруг объекта (для тех, кто в танке). Надо будет посмотреть, можно ли определить координаты углов. В любом случае, алгоритм получается весьма и весьма непростой.

Хмм... Подумаю, насколько такое реализуемо... Прикол в том, что расстояние нужно считать не до центра танка, а до его краев. Всмысле краев его проекции на плоскость монитора.

В случае плотного расположения танков сложно описать алгоритм адекватного и подсознательно воспринимаемого выбора. Танк не точка а значительный по размерам материальный объект. Для точек можно просто брать ближайшую к перекрестию, для танков так не получится (у танков есть размеры). Тут проблема не в коде, а в алгоритме понятного выбора. Будет адекватный алгоритм - будет фича. Это не фикс. Фикс - это исправление ошибок. Роза меняется, в зависимости от того, на кого ты наводишь прицел. Например поведения хоткея фокуса цели разное, в зависимости от того, наводишься ты на противника, союзника или ни на кого. Рентген позволяет использовать розу, когда нужная цель находится за текстурами, например ставить фокус на противника, или отдавать команды союзникам.

Т - это "хоткей" розы. Будет.

По просьбе в соседней теме добавлен рентген на команды из радиального меню (розы). Теперь фокус на цель можно ставить через текстуры. Параметр добавлен в конфиг. 20932e5.zip

коммиты посмотри, поймешь) Картохин косяк Указывайте хэш-код коммита, который был у вас последним при сборке мода из репозитория. Чтобы не было путаницы в версиях и фиксах. Потому как при обычном коммите версия не обновляется. Только при релизе.

Я про свой мод говорю, LoL Ну типа я тебя правильно понял. Рентген-сканер цели. В Advanced Aiming System он уже есть. По сути прикрутить его к розе в пару строк будет, если конечно там разрабы не намутили ничего замутного.

Команды из розы рентгеном... Хмм... Идея неплохая, но придется покопаться. Да и если такое появится, то в соседнем моде (Advanced Aiming System). Там для этого по крайней мере база (рентген-сканер) есть.

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