Плюс если делать виртуалку, там придётся учитывать наследование классов, для того чтобы, оно отвечало текущей иерархии дллки, которая оптимизирует эти классы под новую структуру движка. Ну скажем, студиомодельки теперь работают только из класса CBaseAnimating, потому что это единственный класс, который занимается сетапом костей.
Добавлено 13-11-2019 в 13:06:
Цитата:
thambs писал: Соображения есть, но пока не готов расписать, нужно ещё продумать всё. Сначала вопросы:
1. Есть ли в игре возможность явного доступа на чтение к полям энтити, например к таргетнэйму, ориджину и пр.?
2. Если ли возможность явного доступа к полям на запись, если есть, то как они защищены/не защищены?
3. В каком виде сервер сохраняет состояние энтить, как она сериализуется?
1. Что значит в игре? Ну очевидно у игрового движка в целом (ядро+геймкод), если полномочия модицифировать абсолютно всё по своему усмотрению, я ж говорю, что даже новое бсп-дерево налету строю при загрузке. Таргетнеймы никто не модифицирует, просто потому что в этом нет смысла, а не потому что нет доступа.
2. опять не понял. Что значит "поля" ? Куда их записать? В энтпатч?
Дядя Миша
Насколько я понимаю, скриптинг обычно реализуют именно в виртуальной машинке и на основе отправки-приёма ивентов между скриптованными сущностями.
Цитата:
Дядя Миша писал:
эти сами скрипты, они запускаются как в hlfx из какой-то энтити типо script_lua или из файлика с именем карты?
Например, имя скрипта может быть указано для энтити в поле script, а сам скрипт с этим именем быть определён в игровых файлах.
Цитата:
Дядя Миша писал:
Если скрипты пишутся для конкретной карты, как понять, что их исполнение нужно забрать на следующую карту?
При инициализации на карте скрипт может гетать своих действующих лиц по имени и дальше работать с ними, если всех нашёл.
Вызов цели это всего лишь одна разновидность ивента. Бывают и другие. Взять те же префиксы, которые через задницу реализуют кокрастоке разные типы ивентов.
И да, без скрипта ты не запрограммируешь обработку принятого ивента.
Скриптовой язык, это ведь не только операции, это еще и переменные.
Переменные через энтити конечно тоже доступны - env_local, env_global, но пока их немного, и они в сущности практически булевы. В скриптах же так не получится, надо как-то придётся указать, что вот эти переменные относятся к той или иной энтите, которая потом потенциально уедет на новый уровень. То есть либо эти скрипты так задавить ограничениями, что они не будут особо отличаться от скриптования энтитями, либо одно из двух.
Кстати говоря, в халфе када лепили свою скрипт-систему это отлично понимали, поэтому она у них умеет только групповой вызов целей, скрин-фейд, ну и прогрывание сентенций. Никаких переменных там и близко нету.
Добавлено 13-11-2019 в 15:26:
Цитата:
nemyax писал: Что за переменные?
да я почём знаю. Но язык без переменных, это уже и не язык вовсе.
Я думаю, что скриптовым языком в ксаше просто обязан стать Haskell.
Представьте себе, какое удовольствие будут получать мапперы, когда смогут реализовать сложнейшую функциональную взаимосвязь всего несколькими строчками и без переменных.
Дядя Миша
Я имел в виду, что этот скрипт можно связать с любой энтитью, и у неё появится этот конкретный обработчик ивента kill. При kill-е любой такой энтити она поведёт себя так, как определено в скрипте. А например on_use здесь не определено, поэтому на use она реагировать не будет.
Добавлено 13-11-2019 в 16:30:
Либо пусть запускает дефолтную реакцию энтити на ивент, если обработчик не определён. А чтобы отключить реакцию, явно прописывать в классе void on_hurt(float) {} или void on_hide(void) {return;}.
Если просто ограничить скрипты вызовом эвентов, ну просто разгрузить карту от нагромождения логических энтить, то какой-то смысл в этом есть. Ну, послушаем, что Тхамбс предложит.
| IP: 
13-11-2019 10:06
