[Trigger] I have a question?

[venger07]

Is there a custom script when removing an event to a trigger? I only see a GUI event for adding an event to this trigger...

 

[JustNrik]

As far as I know, it's impossible to remove events.

Edit: What do you need exactly? There are much ways to code without a need to delete an event.

 

[deathismyfriend]

As far as I know, it's impossible to remove events.

Yes events can't be destroyed. They are never removed.

@TO
Why would you want to use custom script when there is a GUI action for it ?
Also all GUI actions have a custom script.


The only way to remove / destroy an event is to destroy the trigger that that event belongs to.

 

[venger07]

I just thought that my trigger causes players to desync at a certain period of time... like for every 15 mins they disconnect.. I have checked my triggers several times and I still don't know what causes it... -_-

 

[Gismo359]

Post the trigger

 

[Dr Super Good]

Unfortunately the developers forgot to include a "RemoveEvent" native. They even went as far as to include the "event" type which is only ever returned by all the event creating natives.

The only solution to remove events is to destroy the trigger they are attached to. As long as there are no pointers to the event handle (which there should be) it will be completely removed. Do note that destroying triggers under certain conditions (not sure which) will result in the game client crashing.

 

[venger07]

well, is there a possibility to desync players when you over populated the event of a trigger? if I add 1 event to a trigger for every second... will it cause the player to desync?

 

[Dr Super Good]

well, is there a possibility to desync players when you over populated the event of a trigger? if I add 1 event to a trigger for every second... will it cause the player to desync?

No it will not cause the game to desynchronize. However there is a good chance it might start to degrade performance and eventually cause the game to crash.

 

[LordDz]

well, is there a possibility to desync players when you over populated the event of a trigger? if I add 1 event to a trigger for every second... will it cause the player to desync?

What event are you needing to add to a trigger every second?

 

[venger07]

No it will not cause the game to desynchronize. However there is a good chance it might start to degrade performance and eventually cause the game to crash.

..well I don't experience crashing and it's not degrading performance.... I just can't find what causes other players to desync...grr..I've created variables for playergroups and removed leaks.. how about pan camera? does it make players to desync?

What event are you needing to add to a trigger every second?

The event I add to a trigger is when unit enters entire map...add unit to this trigger with event unit takes damage... and I have 5 creeps spawning every 30 seconds...

 

[pOke]

Are you using pan camera as necessary? That will cause desyncs.

Here's a tut on what to change if that is your issue

http://www.hiveworkshop.com/forums/...ls-279/fixing-smartcamerapanbj-desync-243334/

 

[Vinz]

http://www.hiveworkshop.com/forums/spells-569/gui-damage-engine-v2-2-1-0-a-201016/
Use this instead of your current trigger as a DDS. Adding everyone that enters Playable Map Area will cause an infinite leak, since the events can never be removed.

 

[Lender]

The event I add to a trigger is when unit enters entire map...add unit to this trigger with event unit takes damage... and I have 5 creeps spawning every 30 seconds...

what mythic said is a good solution. If you still want to make it from scratch ( I did the same coz thats how it can fit the best way in your map ) then do this.

create a whole new trigger for every damage event u want to register
and save the trigger handle in hashtable or somewhere
when unit dies destroy trigger

 

[BPower]

1.) If you use a Damage Modification/Detection System, use one of the existing ones from
our database. They are very reliable, because many people tested them and reported bug issues over a long time.

2.) Which event are you adding so regulary? Unless your script does support trigger rebuilding,
it's probably avoidable to register so many events.
Without seeing your trigger I can't tell it for sure, but a single UNIT_PLAYER_EVENT and a filter condition should be enough, or?
UNIT_PLAYER_EVENT runs that trigger for every unit on the map. In you example it's always evaluated when a unit is attacked.
For the Filter (if needed) you could use an hashtable. A Unit Is Attcked --> If HaveSavedInteger(hashtable, GetUnitTypeId(attacked), 0) then
or if you have to check for each unit --> If HaveSavedInteger(hashtable, GetHandleId(attacked), 0) then.

What you are trying to do (UNIT_EVENT), should only be done with a complex trigger rebuild implementation. You will need vJass/wurst/zinc knowledge for it.

3.) One of the main issues for a desync is, when you use non local code (net traffic) within a GetLocalPlayer() block.
This always results in a crash. You may also find the reason within folder errors of in your wc3 directory.
Each time a game crashes a textdocument is created, sometimes you can comprehend the cause from it.

 

[Lender]

Which event are you adding so regulary?

He registers EVENT_UNIT_DAMAGED. I think he tried to make something similar to a DDS

 

[Wietlol]

You want to make something like I have.
I use this instead of the DDS that Mythic showed you.
You can use this or at least you can see how I remove an event from a trigger.
You can also see how much "Unit takes damage" events will eventually lagg the game.

Just take a look at it

 

[deathismyfriend]

You can't destroy events as said above to remove events you simply destroy the trigger that contains the event.

 

[Wietlol]

True but you can recreate the trigger and add the events you want.

That is what I do:
I have an empty trigger 'gg_trg_Taking_Damage' which is modified by the other triggers.
I have another trigger 'gg_trg_Add_Units' which add units to the taking damage trigger once they enter the entire map area.
Then there is the third and last trigger that runs once every ... seconds (in the stress test map it is 35 but you can change that to 15 minutes or half an hour or whatever you want).
This trigger removes the old trigger and creates a new one, adds all units in the map as an event to that trigger and add the action to the trigger.

local group g = GetUnitsInRectAll(GetEntireMapRect())
    call DestroyTrigger(gg_trg_Taking_Damage)
    set gg_trg_Taking_Damage = CreateTrigger()
    call ForGroupBJ(g,function Add_Unit)
    call DestroyGroup(g)
    call TriggerAddAction(gg_trg_Taking_Damage, function Taking_Damage)

In the stress test, the map starts to look buggy after 25 seconds and starts laggin after 30-35 seconds.
I however add the "unit takes damage" event so many times per second that in a real melee game, 12 players require 5.000 barracks each that all continuasly train footmen (which require infinite resources and food) to actually keep up with that amount.
If you create 1 unit per second for each player (12 players), you can play without problems for 2 hours before you have to reset it.

But as you said, you cannot destroy an event but you can re-iniialize a trigger.

 

[Lender]

look buggy after 25 seconds and starts laggin after 30-35 seconds.

that is heavily based on your PC. an old computer might start lagging after 3-5 sec with those numbers:/
I will make a stress test about this too, the way I do in my map.

 

[Wietlol]

12 players having a total of 60 thousand barrackses training footman continuasly that is a map which runs slow anyway XD
But indeed it was on my laptop and some might run slow on 15 seconds and others wont have problems for a few minutes, but that doesn't take away the point that I reset the trigger and thus remove all events and re-initialize it.

 

[Lender]

yep that's okay. I chosed to create separate triggers for every event end destroy on units death coz I wrote my unit indexer , DDS and some other systems linked together and that way it was better to have this in there rather then creating a separate method to clear out unneeded events.