Crystallize писал:
в чём проблема что оно не работает через простые флоаты?
Работает, только оно меняет локальные копии переменных в вызванной функции. В вызывающей они как проинициализировались нулями по дефолту, так и сидят на нулях. Кстати зачем ты их объявил статичными?
nemyax писал: Работает, только оно меняет локальные копии переменных в вызванной функции. В вызывающей они как проинициализировались нулями по дефолту, так и сидят на нулях. Кстати зачем ты их объявил статичными?
Скомпилить пытался хоть как-то, зачем же ещё. Сейчас уже не помню точно. Когда я код открыл они вообще инициализировались через ={0,0,0}. Так-то я перепишу это место чтобы возвращалось одно значение, из двух там одно по определению ненужное, просто писал реализацию по-быстрому чтобы было от чего плясать.
Цитата:
SNMetamorph писал: Через что компилируешь? Попробуй для файла этого сделать расширение .cpp
Шестёркой
Цитата:
nemyax писал: Но со статиком непонятно. Ты, похоже, путаешь статические переменные, объявленные внутри функции и снаружы.
Я с чего-то решил что при указании входных переменных они не просто передаются туда, а у функций аж scope становится общий, ну типа войд волшебный
Стоит ли в пределах одной комнаты, ну или одного открытого места, объединять кучу func_illusionary или wall в одну энтитю? Если у них свойства совпадают.
Я так понимаю, что один иллюженари/волл считается как "модель" и занимает edict, то лучше делать все, скажем, перила одним func_wall и это будет считаться как один edict? Или func_wall, состоящий из нескольких брашей, все равно как-то разбивается движком?
Aynekko если для таких брашей не нужны рендермоды, то лучше их делать детайлами. В случае с перилами или стёклами - func_wall. Объединять их в одну энтитю можно, но с оговоркой. Если у тебя, грубо говоря, два func_wall в виде букв "L" или "Г", и расположены они так, что один занимает угол напротив другого по диагонали, то если объединить их в одну энтить - пушабли через пустое пространство между ними не катаются. Сталкивался с таким. Возможно, что и монстры могут не ходить.
Ku2zoff писал: если для таких брашей не нужны рендермоды, то лучше их делать детайлами.
Детайлами я само собой пользуюсь. Но перилам и решеткам, ну и стеклам тоже, нужны рендермоды.
Цитата:
Ku2zoff писал: пушабли через пустое пространство между ними не катаются. Сталкивался с таким. Возможно, что и монстры могут не ходить.
Про пушабли не знал (но я ими и не пользуюсь впрочем). А вот монстры нормально ходят.
Мне главное понять, как edict'ы считаются, стоит ли так заморачиваться или без разницы. По логике, т.к. я уже лазил в коде, у каждого func_wall свой спаун, свои параметры и т.д., каждый инициализируется, поэтому наверное по возможности стоит делать все одной энтитей.
Aynekko писал: Мне главное понять, как edict'ы считаются, стоит ли так заморачиваться или без разницы.
Лимит на эдикты даже в обычной халфе можно поднять до 4096 штук, поэтому это не проблема. Проблема в MAX_MODELS и MAX_MAP_MODELS. Ты же работаешь под ксашем, поэтому забей. Я работаю под голдсорсом, поэтому у меня есть несколько вариантов как эти лимиты экономить. Первый экономится засовыванием нескольких моделей в одну (см. патроны в HLWE), а второй детайлами и внешними BSP-моделями для пушаблей, поездов и для того, для чего не важно освещение.
Ku2zoff писал: Проблема в MAX_MODELS и MAX_MAP_MODELS. Ты же работаешь под ксашем, поэтому забей.
Забить не получится, т.к. я уже превышал этот лимит и пришлось перекомпилировать движок. На самой большой карте надо будет пройтись и пообъединять все это дело. Много такой брашевой лабуды, а также env_static'ов. Около 800 "моделей" точно есть на карте.
К сожалению, я не думаю, что компиляторы позволят. Ну или я что-то не так делаю. Вот делал тестовую карту - 896 env_static и столько же func_illusionary (стеклянные палки). Light_environment желтый, сами модели белые. Результат вот такой.