Думаю, либо баг, либо не успели доделать наземку либо как-то по-хитрому делается. Скрипт - это же код программы, насколько я понимаю, какая разница, в каком .cs файле он прописан? Главное, чтобы программа его нашла и выполнила по большому счету. Но вероятно есть тонкости, которых не знаю.Сообщение от Small_Bee
Эта ветка с вопросами, думаю будут и ответы )
зы. проблема только статиков касается или всей наземки?
...зелёные горят.
----------------------
i7-860@3.8, 4GB, ati4890-2GB, 1680x1050, Win7-64.
Ну, в общем как я и говорил, сейчас статики - мишура и акторами не являются, интерфейса для доступа к ним нет, посмотрим, может быть в будущем сделаем.
Да, всё так.но дошла одна маленькая вещь.. Как до жирафа.. Надо сильно забыть концепцию миссии из ила, т.к. тут как таковой миссии (с точки зрения Ила) не существует. Есть "битва", а в ее рамках выполняются различные миссии. Миссия вообще умеет может загружать сама себя. Технически это конечно не так, но выглядит именно так.Т.е. из миссии мы приказываем через GamePlay.gpPostMissionLoad() загрузить в битву еще одну миссию, а что это за миссия - не важно. Походу общими для всех миссий является объект Battle и наверное GamePlay... Каждая миссия загружается под новым номером.
Можно баталию останавливать саму.Скажем у меня есть одна миссия-хост (так сказать, "точка входа"). По OnBattleStarted() она загружает стартовый набор миссий (скажем одна - красные танки, вторая синие танки, едут навстречу). И в каждой из этих миссий отслеживается OnActorDead(). Если была уничтожена группа (она одна все равно), миссия загружает себя снова, сразу или по таймеру. Если помер танчик, то через несколько сек. убираем его трупик через Destroy(), что бы не мешался. Получается "бесконечная" стенка-на-стенку.
Что делать со старыми, "сёгранными" кар... миссиями? Или если на круглосуточном сервере скажем рано или поздно счетчик выйдет за MAXINT?
это поле, которое показывает события какой миссии скрипт миссии слушает - при загрузке миссии в это поле ставится её номер - т.е. она "слышит" только свои события. Если выставить номер другой миссии - будет "слушать" только её, чтобы все миссии слышать - поле в меньше нуля выставить надо.
тут пока не могу сказать, в юзер-аддоне можно свою Battle описывать и миссии загруженные дёргать.
надо посмотреть, тут я не помню.Кстати интересная особенность (возвращаясь все к той же машинке из колонны). Похоже события миссии должны срабатывать только для своих "объектов".. Но они работают и для другой миссии - частично для "продвинутой" наземки и полностью для самолетов. Частично - имеется ввиду, что когда загружается новая миссия с акторами, в "старой" на каждого свежесозданного актора срабатывает OnActorCreated(), но никакой внятной инфы из параметров выдрать нельзя. shortName = "NONAME", actor не является ни группой, ни наземкой, вообще ничем походу... Хотя если в одной миссии поставить триггер "Враги прилетели", то если эта "анонимная" наземка из другой миссии туда заезжает, тригер срабатывает... Или я совсем уже запутался.
Don't happy, be worry
Это было бы гуд, тем более что артиллерия тоже в статики записалась.
О, супер, походу то что надо, вечером попробую..это поле, которое показывает события какой миссии скрипт миссии слушает - при загрузке миссии в это поле ставится её номер - т.е. она "слышит" только свои события. Если выставить номер другой миссии - будет "слушать" только её, чтобы все миссии слышать - поле в меньше нуля выставить надо.
Походу, с MissionNumberListener много вопросов снимаются. А скрипт отдельной миссии нужен конечно, скажем так одну битву можно будет дополнять сколько хошь новыми интересными миссиями, не ломая старое.
1.Готовые программы, оттранслированные в машинный код, выполняются значительно быстрее скриптов, которые интерпретируются из исходного кода динамически при каждом исполнении. Поэтому скриптовые языки не применяются для написания программ, требующих оптимальности и быстроты исполнения. Но из-за простоты они часто применяются для написания небольших, одноразовых («проблемных») программ.
а для чего нужно сторонним людям ковырять готовую прогу...
Как тяжелы знамёна без победы....,Il2-for ever
Думаю, что в данном случае это не совсем скрипт. Просто класс компилируется во время исполнения и становится частью всей большой программы.
А ковырять всю программу приходится чтобы этот класс заставить работать так, как хочется - т.е., понимать как он встроится в игру и что из него можно в игре сделать.
так скрипт к миcсии и есть одноразовый («проблемный») программ
Это к чему? Вообще в С#, как правильно выше заметили, есть такое понятие как "динамическая компиляция", не надо путать это с тем же PHP или JS. К тому же в C# все классы\сборки умеют хранить в метаданных исчерпывающую информацию о себе самих. Так что к "ковырянию" это тоже отношения не имеет. Есть такое понятие как "рефлексия" или "отражение".
--- Добавлено ---
При чем тут проблемный? или одноразовый?так скрипт к миcсии и есть одноразовый («проблемный») программ
--- Добавлено ---
Грубо говоря, .NET приложение может само себя написать, скомпилировать и запустить на выполнение.
При чем тут проблемный? или одноразовый?
Никакой юзер-интерфейс не обеспечит такого функционала, который может полноценный язык, не говоря уже о том, сколько времени и сил уйдет на его написание и отладку. Причем сложность его будет сравнима с каким ни будь про-инжинир, учить надо будет отдельно в институтах. Базовые возможности существующий интерфейс предоставляет, а скрипт если и ограничивает фантазию, то не очень сильно. К тому же С# сам по себе очень простой язык, как в освоении, так и использовании. Для повседневных задач, я бы сказал, не сложнее HTML`a (во загнул).
Все верно.... скрипты это гуд.
Я возможно заблуждаюсь, но я всегда считал что NET приложение строго говоря компилируется в маш. коды при первом запуске у пользователя в его системе фреймворком.... ну хз конечно.
Собственно так и есть - IL в машинный код.
Нет.
.NET приложение компиллируется (обычно) как обычно - программистом, написавшим это приложение. Просто, для его выполнения, нужна "песочница", называемАя .NETFRAMEWORK.
Но может и динамически компиллировать исходники и прямо на лету их подгружать.
В бесплатной visualstudio (express) прекрасный интерфейс и куча сервиса для простых пользователей.
Изобретать скриптовый язык нафиг не надо. Тем более, что столько возможностей он никогда не обеспечит.
С другой стороны, совершенно не понятно почему, используя .net, надо было заниматься динамической компилляцией, а не подсовывать вместо текстового файла, скомпиллированную длл-ку - оно бы и в плане отладки было удобнее.
И почему совершенно не используются события и делегаты, а организовано всё через абстрактные классы а не интерфейсы?
К тому же, нет доступа к объектам в миссии, а всё взаимодействие через классы-посредники.
Не знаю - может, в этом какой-то смысл разработчики увидели, мне пока не доступный..., но странно всё это выглядит.
Да ладно, нормально выглядит. Имхо посредники (хз, мож и посредники, не слишком силен) для того, что если в кишках что поменяется, не пришлось скрипты заново переписывать. Для не слишком сложных задач юзаем скрипт - можно по быстрому накидать, плюс сменять что то безболезненно, если хотим что то более глобальное - аддон. Когда то же они заработают.
Классов для скриптов там всего три если не ошибаюсь - собственно AMission, Player и ABattle, остальное интерфейсы.
Событий да, не хватает, имхо...
А я вот всегда думал... что оно вот типа так:
http://habrahabr.ru/blogs/net/109117/
"по структуре .NET программы, для тех кто не знаком с разработкой под данный Framework: весь код, написанный на любом .NET языке (C#, Visual Basic, F#, Delphi.NET) компилируется в особый Intermediate Language, называемый обычно IL или MSIL. Это что-то типа ассемблера, только весьма умного и обладающего весьма мощными инструкциями. И это, в принципе, такой же равноправный язык как и C#, только синтаксис похуже (а возможности больше). Кроме того, в программе на .NET активно используются метаданные, т.е. вся информация о классах, метода, пропертях, атрибутах и всём остальном сохранена в исполняемом файле.
Т.е. на самом деле, декомпиляция программы не очень верное понятие в данном случае. Она и так вся в открытом виде лежит, а инструменты в виде Reflector'а занимаются тем, что приводят конструкции MSIL к соответствующим конструкциям C# или другого языка, повышая читабельность кода."
Так для этого и нужны интерфейсы - всё, что за ним - переписывай хоть с нуля, хоть каждый день, а интерфейс остаётся и всё, что работает через него, тоже остаётся.
Это и есть почти тот же абстрактный класс.
В интерфейс миссии вынеси несколько методов для получения ссылок на объекты в этой миссии.
В интерфейсах объектов определи все их игровые события, свойства и методы, доступные из пользовательского кода.
Дальше в скрипте определяем делегаты только тех событий, которые хотим отследить (имея подсказку прямо в студии при написании скрипта).
Объекты (что родные, что пользовательские) наследуются от всех необходимых интерфесов, часть из которых используются только ядром, а часть - могут использоваться пользователем. И при создании нового объекта достаточно просто реализовать всё необходимое.
В этом суть ооп и структурированности, им обеспечиваемой.
Ну так и есть.
IL считай "ассемблером для "песочницы""
Вот эта "песочница" и обрабатывает откомпиллированную программу.
Ребята, а подскажите скрипт к мисии должен из одного *.cs файла состоять или можно разбить на несколько таковых файлов? Ну ради того чтоб свой добавить к чужому?
Если я правильно понимаю, то файл скрипта определяется по имени, совпадающим с именем миссии. Поэтому должен быть один. А вот можно ли в одном файле прописать несколько классов, наследуемых от AMission (просто скопировать определение класса из другого скрипта)?
Не вижу области применения для такого решения.
Интерфейсы это хорошо, но решение сделать AMision, Player и ABattle именно классами вполне, имхо, логично. В будущем в аддоне мы сможем наследоваться от этих классов, писать собственную реализацию (скажем для миссии под каждое событие сделать делать соотв запись в базу или лог), а в скрипте наследоваться от собственного класса миссии, просто не забывая вызывать базовую реализацию методов. В случае интерфейса нам бы пришлось каждый раз все заново писать. Тоже самое и для ABattle и Player. Таким образом сделаны миссии для кампании - в скрипте мы наследуемся не от AMission, а от специфичного для кампаний класса.
Пока мне реально не хватает только доступа к статикам.
Крайний раз редактировалось Small_Bee; 20.04.2011 в 21:34.
Появился такой вопрос: Как в скрипте вытянуть тип самолета? В смысле не бомбер/истребитель, а скажем He-111 или G.50. Ну и касательно наземки тоже. GetType() не помогает - походу реальный класс экземпляра динамический? Даже базовый тип и тот с нечитаемым именем... (
И еще в догонку. Как убрать разбитые/разрушенные статики? Они сволочи с миссией то подгружается, их раздолбят, а они радостно чадят до посинения.. И ничего им сделать не могу... Или они как-то по времени сами уйдут? И схожий вопрос.. Миссию мы загрузить можем, а вот выгрузить... Можно это как-то сделать? Скажем что бы убрала все за собой при выгрузке. Это сняло бы проблему со статиками.
Крайний раз редактировалось Small_Bee; 25.04.2011 в 00:01.
Немного не об этом, но может поможет. Doghouse писал, что airport.cpp убирет с аэродромов разбитые самолеты. Может его расковырять, посмотреть. Если ему радиус на полкарты задать, может он и статики уберет.
...зелёные горят.
----------------------
i7-860@3.8, 4GB, ati4890-2GB, 1680x1050, Win7-64.
В ближайших патчах будет InternalTypeName() для самолётов и наземки.
Горят до ~20 минут. Выгрузить - это сложно, миссия же может по скрипту кого-то нарожать, что-то в себя подгрузить и т.д. Скорее всего будет доступ к статическим объектам, но не прямо сейчас , чуть позже.
Don't happy, be worry
Как сделать так, чтобы танкеры рождались не по одному, а сразу группой?
Вооружить танкеры зенитками не удалось. Не нашел где выбрать тип загрузки - зенитки. Подскажите, кто разобрался.
...зелёные горят.
----------------------
i7-860@3.8, 4GB, ati4890-2GB, 1680x1050, Win7-64.
Такой вопрос возник, как определить, имеется ли самолет какой-либо группы в данный момент или нет?
Поясню. У немцев названия группы содержат знаки (|, ||, |||, |V, V, V|) и так далее. Но, при написании скрипта игра подобные знаки игнорирует.
С англичанами проблем нет, у них обозначения цифровые, например 218Sqn. А вот у немцев обозначения типа JG51_| игра в упор не видит. Может стоит заменить | на 1, || на 2, ||| на 3, |V на 4 и т.д. ?
В свойствах ставишь галку "Показать скин" (что бы 3д картинка была), там выше картинки несколько выпадающий списков, в одном из них можно выбрать зенитки или пукшу.
Ваши права
Ответить с цитированием