Dmut

новые мозги - слишком сильно сказано. скорее - обновленные.

достаточно только чемодана денег, документацию найдем. опыт есть.

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

Dragon_Blue. у меня попкорн заканчивается - давай уже апофеоз поскорее, про карту наколенную!

нет, причина крэшей в 32бита не в лишней памяти. лишняя установленная память никак на 32битную систему не влияет, ни в лучшую ни в худшую сторону. причина в том, что в 32бита висте и семерке доступно меньше памяти. не 3.5-3.2gb, как в XP, а намного меньше. из-за механизма виртуального расширения видеопамяти за счет обычной оперативки.

наоборот. эти файлы нужно озвучивать. в игре есть замечательный механизм против изменения нечистоплотными клиентами ТТХ юнитов. просто не все владельцы серверов заморачиваются с правильной настройкой сервера. в скрипт "\Scripts\net\default.cfg" в секцию integrity_check нужно внести, видимо, весь "\Scripts\Aircrafts". тогда клиенты с измененным содержимым просто не смогут войти на сервер.

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

какие именно файлы, по твоему, отвечают за двигатели и ТТХ ?

Wadim, шитяковский текст не имеет вообще никакого отношения к реальным боям.

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

какие дополнительные файлы для какого накручивания ТТХ?

а производительность?

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

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

дай номер мобильника - я тебе весь локон эмэмэской пришлю

Steff32, если ты не знаешь английского и не знаешь, как делать разгон - тебе это не надо, только навредит. Falcon =SB=, давай советы сообразно знаниям клиента. с разгоном как с врачами, "главное - не навреди"

изучай скрипты техники: \Scripts\Database\vehicles \Scripts\Database\navy \Scripts\Database\scripts что будет непонятно - спрашивай, но сначала изучи скрипты и луа.

планируется честный спаун, но не в а-10

рекомендую покупать версию "basic" или "starter", мне они нравятся больше, чем ultimate по вылетам могу дать только такой совет - используйте XP 32бита либо, что лучше, семерку 64. на висте и семерке 32 есть одна неприятная особенность с менеджером видеопамяти. которая, по нашим подозрениям и вызывает проблемы с вылетом игры. причем чем больше видеопамяти и чем сложнее миссия и более высокие настройки - тем больше вероятность вылета.

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

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

к такой идее - централизированного управления ПВО, и мы пришли, но остаётся много вопросов - что , где, как и когда.... ага, чувствуется определенная лексическая направленность, характерная для написания больших, малозначимых статей, рефератов, и т.д. =)

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

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

обнаруженный - это как? где критерий "обнаруженности"? обнаруженный ботом или игроком? как определить "обнаруженность" игроком? идеи есть, но пока неопределенные. как ты сформулируешь это самое более сложное поведение? условие ИЛИ для триггеров можно сделать, меняя только скрипты игры.