Triggers to data rewrite

[NiktosNOTD]

Most of those are done more for sake of keeping things more organized so eventual trouble shooting does not have to include figuring out WHERE code doing something is.

Only change that "maybe" result in marginal improvement of performance is: Demo sadist rewrite, which will no longer check every dying unit anywhere on map if demo with sadist is in game, and now only act on verified demo kills.

Full list of changes:

• Sonic trap ping on activation moved to alert from trigger.
• Limiting of 'sonic traps' moved to data, related trigger removed.
• Limiting of 'arma bombs' moved to data, related trigger removed.
• Limiting of 'x1 bot' moved to data, related trigger removed. Includes adding 'psionic' attibute to nexus to distinguish them during search.
• Limiting of 'reaper drone' moved to data, related trigger removed.
• Renamed and redid slightly limiting of 'blackdog' to be in line with rest of spawned unit limiting. Removed now not used effects related to how it was done previously.
• Renamed and redid slightly limiting of 'maintenance drone' to be in line with rest of spawned unit limiting. Removed now not used effects related to how it was done previously.
• Removed trigger related to blackdog round switch which did nothing, it was done in data before and clearly someone just didn't clean up
• Demo 'sadist' moved to data, related trigger removed.
• Trigger making sure tech 'floodlights' has only 1 lvl aplied same time removed and moved to data.

[ArcanePariah]

1) I once did precisely as you did with the limiting. However, this alters game behavior because now when you place a new one, it will destroy the CLOSEST other one to your position, not OLDEST one. This is very apparent with sonics. As long as players are comfortable with this behavior change, then we can do this

2) Sadist change is also game behavior changing because now, whoever actually lands the killing blow in that 0.1 second window will be healed, not necessarily Demo. You can add a validator to the healing effect to check if the target of the heal has the Sadist behaviors, but this still leaves the issue of 2 Demos getting heals off the other Demo Sadist.

[NiktosNOTD]

Hmm, the closest/oldest might be confusing with demo arma probably, as it's only one you would on purpose leave far away to preplant. As sonic are most likely near team always so i don't think it would impact much. Oh and as i tested it. The destroyed sonic/arma was furthest away not closest

As for sadist thing O_O, i was confident the part pointing on caster would keep it ok. I was more concerned about demo being healed from mobs killed by someone in this 0.1s. Never imagined the killer will get hp not the initial buff caster. - that's fully not ok.

I will crunch the validator tommorow or monday, but if get the concept right then, The effect which does healing would need to check not for the existence of this temporary buff, but for permanent sadist which comes with lvl up skill. With such a test 2 demo with sadist become non issue, if i make separate validators for lvl 1 and 2.

[ArcanePariah]

Damage response handle effect sets caster as the Behavior holder. Though I may do an experiment, there might be a way.

[NiktosNOTD]

So um, i was right that always when unit died the DEMO was healed regardles of who got last shot.

Adding of validators makes it so that for heal to happen demo needs to deal the killing blow.

Attached replay at 2:40+ there are zombies killed by demo and reaper drone showing that demo gets healed only when he kills, and when drone kills noone is healed. Sadist values were multiplied by 10 and buff made 20s for easier testing. (The commit values are set properly/unchanged) sadist corrected.zip