DestroyTrigger sucks at its job.

01-22-2005, 04:09 AM

Many people are under the notion that destroying a trigger will destroy Trigger Conditions...well they are wrong.

Unfortuantly, you need to manually destroy the boolexpr or perhaps use the remove condition function I'm not sure. The boolexpr still exists. Here is my proof:

Code:

function BT_getCReq takes integer itemtypeid returns boolexpr
	return GetStoredInteger(objects(),I2S(itemtypeid),"m_creq")
	return null
endfunction

function CreateBT takes integer itemtypeid,integer capacity,boolexpr creq returns integer
	local string this=I2S(itemtypeid)
	local gamecache gc=objects()
	call StoreInteger(gc,this,"m_cap",capacity)
	call StoreInteger(gc,this,"m_creq",H2I(creq) )
	set gc=null
	return itemtypeid
endfunction

function Hero_evaluateCreq takes unit hero, item bag,item it returns boolean
	local gamecache gc=objects()
	local trigger t=CreateTrigger()
	local boolean b
	local triggercondition tc
	set tc=TriggerAddCondition(t,BT_getCReq( GetItemTypeId(bag) ) )
	call StoreInteger(gc,I2S(H2I(t)),"m_hero",H2I(hero))
	call StoreInteger(gc,I2S(H2I(t)),"m_bag",H2I(bag))
	call StoreInteger(gc,I2S(H2I(t)),"m_item",H2I(it))
	set b=TriggerEvaluate(t)
	call DestroyObject(I2S(H2I(t)))
	call TriggerRemoveCondition(t,tc)
	call DestroyTrigger(t)
	return b
endfunction
function Creq_notBag takes nothing returns boolean
	return not IsItemBT( BT_Item() )
endfunction

function Creq_noReq takes nothing returns boolean
	return true
endfunction

function Trig_TestBag_Actions takes nothing returns nothing
	call CreateBT('I00G',12,Condition(function Creq_notBag))
endfunction

These seemingly nonsensical peices of code are from my latest beta of DT4a (not posted anywhere yet). Anyway, I never recreate the boolexpr but each time I use evaluate it should destroy the trigger condition and the trigger but the boolexpr sitll lives.

01-22-2005, 06:50 AM

Guest

Quote:

Originally Posted by weaaddar

Many people are under the notion that destroying a trigger will destroy Trigger Conditions.

That surprises me. It's been known for a long time that destroying a trigger will leak its trigger actions (providing of course that you don't actually destroy the trigger actions themselves first), so I've always assumed it was the same with conditions.

Anyways, I am slightly confused by your post though, do you mean that even after removing the trigger condition that the boolexpr still exists? That would almost make sense, I always wondered why it was RemoveCondition instead of DestroyCondition. Perhaps it just detaches the condition from the trigger, or does it actually destroy something?

So yeah I've got nothing to add, except maybe to wonder if overwriting one of the global blizzard.j boolexprs might help in some way. In particular, the boolexpr filterMeleeTrainedUnitIsHeroBJ is only used by one, well, two functions: http://jass.sourceforge.net/doc/api/...rce.shtml#7283 and again in http://jass.sourceforge.net/doc/api/...rce.shtml#9057 which just creates the filter. I'm certain that if you are making a custom map you will be able to work around the map ever using that function on its own, and well I don't know if a global would even help at all but anyways so yeah.

02-17-2005, 03:38 PM	#3
Vexorian	I remember that Cubasis tested this stuff, it is weird that Cubasis was wrong in his testing. Anyways the best thing would be to forget about them when the trigger was created in game, I don't really see the point of using TriggerConditions, you can just use an if statement inside. I am raising the dead, yes, but this is the first time I saw this thread

02-17-2005, 08:50 PM	#4
Guest	OK...now I'm really confused...as if I wasn't before... For those of us out there who can barely understand JASS, but have become paranoid about memory leaks and so on due to the number of posts around here about this....what are we supposed to do then?

02-17-2005, 10:24 PM	#5
Vexorian	If you don't know JASS, you don't create triggers in game, if you don't do that, you shouldn't worry

02-18-2005, 03:26 AM	#6
weaaddar	For boolexpr which is the only way to evaluate a boolean returning function on the fly (as far as I know) this is currently the best way to do it I think.

02-18-2005, 07:35 PM	#7
Vexorian	Well I would replace the damn thing with ExecuteFunc and a SetResult gamecache based function. To deal with this leak you would need to use gamecache anyways. No matter ExecuteFunc uses other thread since you can't use waits in boolexprs anyways.

02-18-2005, 09:03 PM	#8
weaaddar	All that leaks in this case is the boolexpr. As I want the boolexpr to exist so that I can reuse its actually benefecial that it sucks at its job.