Именно так, да. В халфе довольно сложная возня с объявлением сейв-рестора, чтобы в новой энтите сохранить хотя бы одну переменную, надо скопипастить довольно большой кусок кода и там поперименовывать всё. А потом еще и в KeyValue добавить лишнее условие, народ (и я в том числе), предпочитали брать уже готовые переменные. Вот в кваке там с этим было хорошо, объявил переменную с точкой и она у тебя уже и из настроек сразу читается и в сейв пишется.
Дядя Миша писал: Ну и стараюсь убрать эту порочную практику, когда для новых энтить вовсю использовались переменные из entvars_t подходящие по типу, чтобы не возится с описанием IMPLEMENT_SAVERESTORE и прочей гадости. Помоему это Лаури первым придумал, этот фантазёр.
Этим занимались сами Valve. body у gibshooter в качестве количества сабмоделей, netname у монстров в качестве названия сквада, message в самых разных смыслах и т.д.
Мне кажется, энтварсы очень удобная штука. Они позволяют шарить основные параметры энтитей между разными библиотеками, и в том числе с ботами и скриптовой системой (в волатиле это например Lua). А переиспользуются они в целях экономии памяти, и в этом с точки дизайна нет ничего плохого. Единственное что я делаю - добавляю в класс простенькие геттеры/сеттеры, чтобы по ходу кода потом не гадать, что же тут значит pev->body.
энтварсы для разработчика это UB в первую очередь, потому что нет никакого соглашения какие переменные смотрит движок, какие он меняет, на какие реагирует, на какие возможно будет реагировать в дальнейшем.
В квейке была виртуальная машинка и там было совсем другое дело.
Дядя Миша
Движок реагирует на очень небольшое число энтварсов, и как правило, они имеют вполне чёткое предназначение, типа classname или origin. Но я согласен, работу движка с энтварсами надо минимизировать, они нужны пользовательским дллкам, и конечно же скриптовой системе, которая ничего не знает про pvPrivateData.
XaeroX писал: Движок реагирует на очень небольшое число энтварсов, и как правило, они имеют вполне чёткое предназначение, типа classname или origin.
я тебе про то, что в халфе получилось. Там как минимум половина энтварсов просматривается движком без чёткой логики со пользовательской стороны. Скажем pev->flags используется частично. Некоторые флаги движок не смотрит, причём они даже по диапазонам не разделены. Ну как повизёт.
Удачный интерфейс - это явный каллбэк, а не вот такой вот просмотр приватдаты по тихому. А в той же кваке движок мог даже пользовательские переменные искать из вирт.машины, она же как решето в этом смысле. И менять он их тоже мог. Нет в таком подходе ничего хорошего.
C++ Source Code:
1
struct edict_s
2
{
3
int flags; // edict->flags
4
float freetime; // sv.time when the object was freed
5
int serialnumber; // increment each time when entity was freed
6
link_t area; // linked to a division node or leaf
7
void* pvPrivateData; // alloced, freed and used by DLLs
8
};
мой эдикт вот так выглядит сейчас. Единственное поле, которое смотрит движок - это flags. В остальные он не лезет.
Дядя Миша
А если ты потом захочешь скрипты прикрутить, ну или блупринты какие-нибудь, как ты туда инфу о классах протащишь?
Не знаю, как в новом УЕ, а в старом классы были на UnrealScript и к ним был доступ через специальный экспорт, где перечислялись "внешние" поля. Но на плюсах ты так легко не сделаешь, по идее.
XaeroX писал: как ты туда инфу о классах протащишь?
ну посмотри как в третьем дууме сделано. Там скрипт является продолжением класса, объявленного в движке и наследует его поля. Очень оригинально, я такого больше нигде не видел.