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

Практика показывает, что или это напишет один, или это не напишет никто.

Без возможности управлять движением мы получим тот же кооп.
Где только колонны и возможны и что-то изменить можно только перезагрузив карту.
Может не стоит заморачиваться тогда, раз решение есть уже готовое.

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

Мне это не интересно. Сорри.

А зачем глаза-то им? Глаза у коммандера есть.
В АПИ идут координаты колонн - коммандер сравнивает расстояние если дистанция близкая колонна строится во фронт.


з/ы/ Ежли дадите инструмент, то готов поучавствовать.
Правда, «...давно не брал я в руки шашек©».

Из опыта программирования, Яву не знаю (пока). А так - ассемблер 86, Паскаль, Си++, Форт, ВизуалСтудио, ПХП, Яваскрипт. Ну и SQL до кучи.

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

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

я тебе могу сказать по своему опыту, что на перестроение танков уйдет где то месяц. ну можт недели 2.5-3. ибо все делают ето после работы, каждый день по чуть чуть ковыряя код.
а разговоры что сейчас идут они не бесполезны, ибо они реализуемы.
а самое главное- они пересекаються с ковырянием АИ наземки, его движением. т.е. пока код не расковыряешь- не будет никакого мода. а когда расковыряешь-моды пойдут связанные с етим. и построение и АПИ связаны будут одними и теми же классами. я понимаю там, если бы целью мода было сделать ИИ наземки, а тут бы люди обсуждали какие новые саомлеты надо добавить в игру...

так вот, ето я все к тому-что за ети 2-4 недели ковряния кода, нужно уже обдумать и решить по всем вопросам...в том числе и по АПИ


а вот ту не факт. по идее, ето можно получить 2 путями
-опрашивая танки

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

А в чем насущная проблема?
Сделать ИИ в иле?
Или сделать ИИ снаружи, а в ил только данные передавать?

И еще вопрос.
Ты вот сколько заплатил Бармалу за защиту и мод "туман войны"?
Вот и посчитай работу профессионала.

Это все один путь - получить данные в миссии запустив танчики.

Второй путь - это заранее посмотреть формулы в движке Ил-2.
Т.е. по идее знать точно.

как вариант...так...ладно...таки нада определиться сначала как и что мы можем вытащить из ила....

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

если по перестроению, то мб запускать\незапускать перестроение в зависимости от скорости на марше+колво врагов?
типа если врагов мало, то зачем обновлять строй?
а елси врагов мала, и скорость низкая-то пусть занимаю оборону...

Хороший перевод темы.
Столько же, сколько ты заплатил VGV, IvanoBulo, Solar и другим. Вот и посчитай.

А может это коммандеру дадим решать? Тока команды в АПИ пропишем типа set XX_Chief formation 1 (2,3,4,5) Если коммандер промолчит, то формация не поменяется.
А вот вообще в идеале описание маршрута в миссии я бы расширил на манер маршрута авиаботов, там есть точки - взлет, полет, атака, (причем с указанием цели). И у наземки можно так - точка перестроения в колонну, фронт, ромб, хаотично, экстренный тормоз и т.д.
Т.е. не в прямую указывать команду перестроения, а подменять точку маршрута с типом построения. А по дефолту будет колонна, как полет у авиаботов. (из соображений совместимости как у мода зен :))

Выглядеть будет примерно так - set XX_Chief_Road xxxxx.xx yyyyy.yy vv.vv Type_fоrmation

Вообще в АПИ добавить только команду set - т.е. изменить/переописать объект в миссии. (даже с сохранением синтаксиса)

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

Что касаемо конвоя кораблей. Имхуется мне, что сделать это надо опять таки на манер колонн наземки. Т.е. введением новых объектов - конвой из 3-4-5-6-7 кораблей, разного класса, правда :). И управлять ими как одним объектом. с теми же заморочками по перестроению.

А при чем здесь они? Это ты стрелку переводишь.
Или может мне еще Ивану Грозному и Петру 1 заплатить, ведь я же живу в созданных ими государствах?

В общем я и не сомневался, что для ГФ мод "туман войны" и защита ничего не стоили.
Но и ты не сомневайся, что они сделаны были отнюдь не на энтузиазме.

Собственно это к тому, что по-быстрому сделано ничего не будет. А на энтузиазме будет как пойдет энтузиазм.

Вопрос в цене вопроса? :)

Мож сначала ТЗ сформулируем - потом экономическую эффективность считать начнем? :)

Так и обсуждается. Просто Борада решил процесс прервать :)

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

Да и ТЗ легче составить. Типа: есть вот это и вот это, надо еще это и это.

Имхуется:
надо впихнуть в него 3 команды.
1.1 set X_obj_name x y v add_param - возможность переопределения свойств объекта заданного в файле *.mis
1.2 define X_Static_obj_name1 as X_Static_obj_name2 - возможность переопределения объекта (статического) заданного в файле *.mis
1.3 create X_obj_name x y add_param - возможность создания объекта не заданного в файле *.mis

, где add_param может быть все, что угодно от построения до меткости зен. в зависимости от объекта.

2. ну и соответственно расширить свойства подвижных объектов
2.1 ввести понятие построения
2.2 ......
2.3 ......

Таким путем можно и ботам маршрут менять, кстати. А то полетят под конец карты бомбить уже ставший своим филд или промзону :)

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

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

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

это для статиков и их координаты известны и постоянны. а использовать можно как угодно. Например подъем аэростатов )), наведение переправы, визуальное пополнение цели (склада) - был один бензовоз, стало восемь, или пришла колонна снабжения к цели появляются зенитки и т.д. синтаксис повторяю - общий. (можно и мосты со временем восстанавливать:))

блин, да все можно!!!

О! чтоб было понятно, я алгоритм ила представляю так - считал файл мис. отпарсил - занес маршруты и объекты в массив. И потом. по тикам времени, перемещает их в те координаты, что прописаны в массиве, а если их сменить? поедет по другой дороге :). А по статикам - как подлетаешь к объекту, он лезет в массив и показывает тебе его. сначала первый - из мис, а второй раз подлетишь, объект сменили, уже покажет второй. Должно быть так, как то...

На данный момент в иле маршрут создается при создании объекта, функции замены маршрута я не нашел. Можно тупо текущий объект удалять, а на его месте создавать такой же, но с другим маршрутом.
Как-то так.

что то типа ТЗ я уже пытался сформулировать... вот что получилось


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

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


а вот как и что, каким команды будут в АПИ- пока неясно...но идея правильная что нужно решать уже какие команды ОБЯЗАТЕЛЬНО нужны и искать места в коде..

с командой 1.3 согласен на 100%-нужна такая команда. так и запишем. а вот с переопределением...ну ето очевидно, что что то надо переопределить. может просто добавлять новые точки к маршруту?
и команда будет типа
add (unit_name) X Y Z V(скорость)?

----
а теперь касательно илоносной части( ет у мя в списке 1 пунктами идет
поскольку всякие там построения, остановки и т.п. ето уже задано в алгоритмах кода, ИМХО, команды на ето с командера НЕ НУЖНЫ, ибо тут хотябы путь бы сделать, не то что построение...
и предложение у меня такое- все ети перестроения можно спокойно подвязать к скорости например(командеру все равно нужно задавать скорость)

работать ето будет таким алгоритмом:

если скорость больше 20 км\ч то юниты при атаке останавливаться не будут(типа идут на прорыв).если меньше-они остановяться и будут стрелять стоя.
аналогично перестроение: если скорость в интервале ( 15-20) км\ч то значит они едут на марше, строяться колонной.
если скорость менее 15 км\ч то при втсрече с врагом они перестраиваються в линию. если скорость больше 20 км\ч значит они в прорыве и едут например линией(ромбом)
аналогично с остановками под атакой авиации
вот такие вот дела...сразу команд нужно будет меньше делать :)
как думаешь на счет такого способа задания свойвств? имхо. так будет лучше...кроме того, если ето запрограммить то и в оффлайне не нужен будет командер, достаточно будет в полном редакторе задавать скорости :)

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


вроде бы так...только не факт что мы ето найдем...работа сложная...

Я понял так алгоритм ила
Читаем из файла миссии и создаем объект и привязанный к нему лист с маршрутом. Он читается не в виде точек а в виде отрезков - segments (Так же и я сделал на ГФ маршруты) . Движение идет по сегментам ( 200м) которые еще делятся для обсчитывания. Потом с производной от скорости и идет смена координат. В этом и проблема с синхорнизацией видимо, так как временной переменной нету. Принцип трека - с середины его смотреть не получится... У паравозов сегмент больше, потому заметнее рассинхронизация. У кораблей еще больше.
Один из способов - менять на лету этот массив с сегментами. Но боюсь будут проблемы, так как надо отслеживать какой из сегментов сейчас в работе у объекта. Хотя это чисто техническая проблема.

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

[1:41:35 AM] 3do/Buildings/Airdrome/Hangar1/live.sim destroyed by 1_Chief2 at 111464.89 113493.55
[1:43:55 AM] 63_Static destroyed by 1_Chief0 at 111458.82 113515.07
[1:44:05 AM] 3do/Buildings/Airdrome/Hangar1/live.sim destroyed by 1_Chief0 at 111310.33 113452.14
[1:44:16 AM] 59_Static destroyed by 1_Chief0 at 111302.75 113474.61
[1:44:18 AM] 3do/Buildings/Airdrome/Hangar1/live.sim destroyed by 1_Chief2 at 111348.984 113462.484
[1:45:35 AM] 3do/Buildings/Airdrome/Hangar1/live.sim destroyed by 1_Chief2 at 111194.45 113421.08
[1:45:46 AM] 57_Static destroyed by 1_Chief2 at 111226.83 113454.18
[1:45:48 AM] 55_Static destroyed by 1_Chief0 at 111148.6 113434.14
[1:45:50 AM] 68_Static destroyed by 103_Static at 110905.82 113488.09
[1:45:50 AM] 1_Chief0 destroyed by 15_Chief1 at 111072.94 113290.49

особенно последняя строка.

надо тока найти. и как вариант, ввести команду для юнита, на выдачу в АПИ своих координат. Типа определить местоположение .

это ключевое...я ща попутно ковыряюсь в моде на остановку танков...

Тебе нужен Wagon.java Ищи там msgCollisionRequest, как я понял эта функция отвечает за возможность столкновения вагона с другим объектом.
Там есть строки
Короче, тебе нужна 342 строка этого файла.
Меняешь ее на
По идее вагон с вагоном больше не столкнется, локомотив (как я понял) тоже считается вагоном.

По аналогии, наверное, и с короблями

По кораблям.
Класс BigshipGeneric.java
Тоже функция msgCollisionRequest
после 1236 строки добавляешь

ТОже проделываешь в классе ShipGeneric

Ок, спасибо.

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

F что касается создания АПИ для внешнего "генерала", то за основу можно взять код devicelink - там уже реализован код обмена данными с внешней программой. Придумать формат сообщений, которыми будут обмениваться ил и "генерал".
Ну и самое сложное - дистрибьюция этих сообщений по иловским объектам и организация их реакции на сообщения. D Иле уже есть класс Message - можно попытаться его наследовать и вклиниться в существующюю цепочку передачи сообщений.

Нашел место в коде, где колонна упирается в разрушенный мост и встает намертво.
Класс ChiefGround.java
Функция moveChiefPacked

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

Кстати есть класс ChiefManager, в нем нет кода, но он создается в классе World%)

Сам ОМ велел реализовать в нем управление колоннами :)

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

может через консоль - по старинке, или еще одну завести?

з/ы/ Кроме того, devicelink, кажется UDP? Не исключена вероятность что генерал отдаст команду, а сервер пропустит ее мимо ушей. Или наоборот.
Лучше будет отдельный потоковый сокет.

тут уж надо смотреть сначала что получиться...
я то пока сорри немного не тем занимаюсь, атмосферный мод дотачиваю...
а что такое devicelink если не секрет?

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

Шанс, что сервер пропустить команду мимо ушей - никакого.
В плане безопасности - в devicelink'е уже есть код, который отключает его при сетевой игре. Почему бы его не задействовать?

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


а вообще нашел в классе например ShipGeneric метод
private void LoadPath(SectFile sectfile, String s) {
ну он есть почти везде. очевидно, что он и прогружает путь(разбивает на сегменты и т.п.). найти бы что его вызывает( в каком месте) и куда передаються ети данные. думаю ето то что нужно...копаю в общем дальше тут :)

Сделай doxygen'ом документацию с диаграммами dot с CALL_GRAPH, CALLER_GRAPH - будет тебе красивые диаграммы кто кого вызывает (правда прога работать будет полдня:) )

LoadPath есть только в ShipGeneric и Ship, вызывается конструктором (это я про оригинальный ил)

ДА! Не забудь в доки еще исходники добавить - разбираться будет куда проще.

Теперь боты исчезают через 1 секунду.
Тестировалось только в оффлайне. Я не знаю, что нужно чтоб оно заработало в онлайне - возможно ничего больше и не надо = просто достаточно наличия этого мода у юзера.

Если что - могу сказать где что править