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

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

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

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

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

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


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

Из опыта программирования, Яву не знаю (пока). А так - ассемблер 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 ......

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

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

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