Привязываю к юниту что-то через хеш-таблицу, например:
	call SaveInteger( hashtable, GetHandleId( whichUnit ), 0, integer )
Но привязываю, только, если ранее к этому юниту не привязывалось, то есть:
	if not HaveSavedInteger( hashtable, GetHandleId( whichUnit ), 0 ) then
		call SaveInteger( hashtable, GetHandleId( whichUnit ), 0, integer )
	endif
Так вот, проблема вот в чем: на карте создаётся огромное количество юнитов и к ним крепятся данные, как написано выше. Эти юниты удаляются после смерти и их хендл освобождается, для другого нового созданного юнита. И в итоге, я к юниту не могу что-либо крепить, потому что проверка выдаёт, что в хеш-таблице по данному ключу уже что-то сохранено, потому что новый юнит занял хендл старого юнита. Как это обойти?

вариант №1 - не нулить переменные, оставляя утечки номеров хендлов. это безопасно, да, если знаешь, что делаешь.
№2 - ловить UNIT_DEATH и чистить за ним
`
ОЖИДАНИЕ РЕКЛАМЫ...
22
при смерти юнита
FlushChildHashtable(hashtable, GetHandleId( whichUnit ))
стирает данные из таблицы
21
biridius, но тогда я потеряю абсолютно всё, что связано с данным юнитом.
22
отдельно не стереть
можно сохранять туда же boolean true, а при гибели false, и проверять это вместо HaveStored
21
biridius, нашел еще такую функцию:
	native RemoveSavedInteger takes hashtable table, integer parentKey, integer childKey returns nothing
думаю, она идеально сюда подходит.
22
хендл не бывает копия если он умер хендла уже нет теперь уже будет возврашать 0 поэтому ты получаеш 0 много таких удаленых... Думай головой
2 пункта от Кет: 1.2.1 (безграмотность) без знаков препинания каменты понять очень сложно
21
pro100master, лучше бы не отвечал, если не знаешь, что говоришь...((
21
pro100master, когда объект удаляется его хендлайди освобождается и его место может занять другой объект!
28
pro100master, ты хоть знаешь что такое хэндл?
и что именно возвращает функция GetHandleId
ScopteRectuS:
biridius, нашел еще такую функцию:
	native RemoveSavedInteger takes hashtable table, integer parentKey, integer childKey returns nothing
думаю, она идеально сюда подходит.
если работает то закрывай вопрос
22
nvc123, знаю его как и машиный код, удаленый юнит который польностью удаляе из памяти и знать черех хеш самый бредовый...
2 пункта от Кет: 1.2.1 (безграмотность)
3 комментария удалено
16
вариант №1 - не нулить переменные, оставляя утечки номеров хендлов. это безопасно, да, если знаешь, что делаешь.
№2 - ловить UNIT_DEATH и чистить за ним
Принятый ответ
Этот комментарий удален
28
DracoL1ch, я бы 2 вариант юзал
с первым могут быть проблемы если есть арифметика с хэндлами
да и делать намеренную утечку памяти вместо того чтобы просто чистить за собой данные это какой-то жуткий костыль
16
nvc123:
это не утечка, это сохранение id хендла, не более. на память не влияет от слова никак, разрушь объект - и сборщик его уберет.
29
ну если ты ловишь юнит_дес и чистишь табличку а там вдруг ульт паладина то действительно будет баг.
28
Doc, ну так учитывать рес надо, это всегда при отлове смерти проверять надо
DracoL1ch, на память это влияет как минимум тем что хэш таблица забита не используемыми значениями
26
что бы не было непоняток с ультой паладина, можно удалять значения таблицы по мере того как труп разложился до такой степени, что уже не сможет быть воскрешен. банальный таймер.
16
А еще можно просто не юзать ульт паладина. Ну а мусорка в хештаблице у ТС и так, и так
7
GetUnitTypeId() вернет рав-код юнита, даже если он разлагается, что может помочь в поиске мусора
21
Ige, GetUnitTypeId() вернет же одинаковое значение для одинаковых юнитов.
7
ScopteRectuS, как делаю я
Когда креплю данные к юниту через хт, добавляю его в группу. По группе периодически пробегаюсь, ищу несуществующих юнитов (GetUnitTypeId() вернет 0, если юнита больше нет на карте) и если нахожу, то очищаю данные в хт.
22
самый оптимальный это юнит покинул облость вся карта... после чего можно уже его удалить данные покинувший есть уже наработка index unit
Чтобы оставить комментарий, пожалуйста, войдите на сайт.