Проверка на индекс не корректная. Первый созданный для игрока имеет индекс 0 и поэтому он игнорируется в OptimizeSampPools__get_vehicle_id
Спасибо, не заметил, когда правил такое же условие в reset_id.
Еще вопрос. Не нужно ли удалять удалять с вектора адресс при удалении сущности игрой? Он же просто растёт как грибы и при продолжительной игре будет работать в ущерб производительности
Не нужно и не растет. Тут вектор в максимальной своей размерности совпадает с размером игрового пула. На производительность это не влияет.
О том как это работает
В игре есть пул:
struct CVehiclePool {
CHeli *objects; // CHeli самый большой класс машин, по этому пул его использует
flag_t *flags;
uint32_t size;
};
В этом пуле objects создается примерно так:
objects = new CHeli[size]. Т.е. Это динамически аллоцированыей массив, к объектам которого можно обращаться по индексам, как если бы это был статичный пул
CHeli objects[size];.
Мои вектора по типу
vehicle_ids это аналогичные пулы, где
size часть структуры вектора, а вместо
CHeli хранится самповский id.
Я хукаю создание объекта сампом, и из указателя
CHeli* вычисляю его индекс в пуле. Это очень простая арифметическая операция без перебора:
const auto index = vehicle_ptr - pool->objects (по факту в коде еще есть деление, но это потому что я не завез настоящих игровых структур. С ними деление добавил бы компилятор).
После получения индекса я проверяю, что он не выходит за пределы пула, что бы не ресайзить свой пул (
vehicle_ids) больше игрового пула.
Ну и оптимизация самповских циклов работает по такому же принципу. По дефолту сам вызывает функцию поиска id, где перебирает все элементы своего пула и сравнивает указатель на игровой объект. Плагин вместо цикла использует вычитание для получения индекса в игровом пуле (
const auto index = vehicle_ptr - pool->objects) и далее просто достает id по этому индексу:
const auto samp_id = vehicle_ids[index];.
Edit: залил поправленную версию
TODO: пухукать initgame с id локального игрока
