Dat new type of Lightning Attach system

[Tal'Rarity]

Lightning Unit to Unit system
This is an example and a system in progress to show a possible better method of lightning manipulation.

[trigger=]
hashtable
Events
Time - Elapsed game time is 0.00 seconds
Conditions
Actions
Hashtable - Create a hashtable
Set DatTable = (Last created hashtable)
[/trigger]

[jass=]
function yays takes nothing returns nothing
local unit u=LoadUnitHandle(udg_DatTable,GetHandleId(GetTriggeringTrigger()),StringHash("da"))
local trigger t=LoadTriggerHandle(udg_DatTable,GetHandleId(GetTriggeringTrigger()),StringHash("trig"))
call IssueImmediateOrder(u,"unravenform")
call IssuePointOrder(u,"move",GetUnitX(u),GetUnitY(u)) // this is to fix the animation bug which is unit death
set u=null
call DestroyTrigger(t)
set t=null
endfunction[/code]

[trigger=]
lu2u main
Events
Player - Player 1 (Red) skips a cinematic sequence
Conditions
Actions
Set groupint = 0
Set groupint2 = 0
Unit Group - Pick every unit in (Units currently selected by Player 1 (Red)) and do (Actions)
Loop - Actions
Set groupint = (groupint + 1)
Set grouped[groupint] = (Picked unit)
Custom script: loop
Custom script: exitwhen udg_groupint2 == udg_groupint
Set groupint2 = (groupint2 + 1)
Trigger - Run lu2u run <gen> (ignoring conditions)
Custom script: endloop
[/trigger]

[trigger=]
lu2u run
Events
Conditions
Actions
Custom script: local trigger t=CreateTrigger()
Set u = grouped[groupint2]
Unit - Add Crow Form to u
Custom script: call IssueImmediateOrder(udg_u,"ravenform")
Custom script: call SaveUnitHandle(udg_DatTable,GetHandleId(t),StringHash("da"),udg_u)
Custom script: call SaveTriggerHandle(udg_DatTable,GetHandleId(t),StringHash("trig"),t)
Custom script: call TriggerRegisterTimerEvent(t,0.01,false)
Custom script: call TriggerAddCondition(t,Condition(function yays))
[/trigger]

A bug was recently revealed to me thanks to GhostHunter123, it seems that every lightning attach can only handle 1 lightning at a time so even though this is sadly limiting it doesn't wreck anything. Just have to look at it from a different angle for example look at it like a projectile system instead. Even though a dummy unit can be in more then one spot at once it doesn't look good due to the dummy unit flashing at high speeds.

Though if anyone finds a workaround to this then I would really appreciate it being shared.

 

[Spellbound]

I don't know what this does. I've tried reading the code and there are no lightning effects created anywhere, only ravenform and unravenform orders beings given to currently selected unit when Player 1 pressed ESC. Care to elaborate a bit? Also the health bars are all messed up.

 

[Tal'Rarity]

I don't know what this does. I've tried reading the code and there are no lightning effects created anywhere, only ravenform and unravenform orders beings given to currently selected unit when Player 1 pressed ESC. Care to elaborate a bit? Also the health bars are all messed up.

My bad, uploaded it and forgot all about the example I made and deleted. Try again, I was removing stuff that wasn't part of the main system and didn't notice I removed the example too.

The triggers handle removing and adding the lightning while object editor handles the creation of lightning effects.

 

[Spellbound]

So it uses Finger of Death to spawn the lightning effects, and using crow form ends the lightning cast from the unit?

 

[Tal'Rarity]

So it uses Finger of Death to spawn the lightning effects, and using crow form ends the lightning cast from the unit?

Yup, working on better/different methods too however currently this is the best and I think even bests trigger only lightning handling.

 

[Wareditor]

What are the benefits of such a method over the classic one ?

 

[Tal'Rarity]

What are the benefits of such a method over the classic one ?

Well there is quite a benefit right there, no classic one exists. It is either coordinates or points which translates to coordinates anyways.

 

[Tasyen]

This takes in account xyz offset from missle start/hit + flying height of both units.
If one mimics single target missles/Lightning with scripts, one has no real access to this offsets and it won't look that good.

 

[~El]

What's wrong with using coordinates in the first place? If you want to update it in real-time, just use a timer. I don't see any reason not to use a timer, unless you are starting to see real performance losses.

I've worked a bit with lightnings before, and I've never had any issues using them that way.

 

[Tasyen]

What's wrong with using coordinates in the first place?

The Timer + coordinate thing is good, but guess Dat-C3 wanted to show us an alternative.

Except When using Units differ much in Size on this case a fixed z offset looks sometimes quite ugly.
Could be avoided by using an table for such units, but dat is somehow redundant (unneeded) extra data :|.

I like timers.

 

[Tal'Rarity]

What's wrong with using coordinates in the first place? If you want to update it in real-time, just use a timer. I don't see any reason not to use a timer, unless you are starting to see real performance losses.

I've worked a bit with lightnings before, and I've never had any issues using them that way.

My alternative allows for up to 2000 near lagless beside obvious graphic lag and likely past. No need for slow timers or a fast loop.

The Timer + coordinate thing is good, but guess Dat-C3 wanted to show us an alternative.

Except When using Units differ much in Size on this case a fixed z offset looks sometimes quite ugly.
Could be avoided by using an table for such units, but dat is somehow redundant (unneeded) extra data :|.

I like timers.

This is mostly for dummy units only because it only links to a units feet/origin.

 

[~El]

My alternative allows for up to 2000 near lagless beside obvious graphic lag and likely past. No need for slow timers or a fast loop.


This is mostly for dummy units only because it only links to a units feet/origin.

Could you, please, elaborate, how this whole scheme works? It's not really clear from the code.
Does attach a lightning between two units, e.g. a caster and a target? Or do you have to use one dummy unit for one end, or for both?

The reason I'm asking is, because, if you need to use dummies for both the start and the end, it just pushes the problem up the stack. Now, instead of moving the lightning directly, by calling e.g. MoveLightning, you need to move the dummy units by calling SetUnitX/SetUnitY. You still need to update the positions.

If you can attach it to a caster and the dummy unit as a target, you still need to update the dummy's position, which posits the same problem as moving the lightning by itself. Sorry, but I have some doubts that this is truly that much of a performance benefit.

The only real way to know, of course, is to make some sort of comparison test between the two methods. We can discuss this for weeks, but until there is some kind of solid test showing that one method is better than the other, this is all wishy-washy talk with no real verification behind it. It'd be great if you (or someone else, I might try this myself during some free time), could make a test to actually verify that.

 

[Tal'Rarity]

Could you, please, elaborate, how this whole scheme works? It's not really clear from the code.
Does attach a lightning between two units, e.g. a caster and a target? Or do you have to use one dummy unit for one end, or for both?

The reason I'm asking is, because, if you need to use dummies for both the start and the end, it just pushes the problem up the stack. Now, instead of moving the lightning directly, by calling e.g. MoveLightning, you need to move the dummy units by calling SetUnitX/SetUnitY. You still need to update the positions.

If you can attach it to a caster and the dummy unit as a target, you still need to update the dummy's position, which posits the same problem as moving the lightning by itself. Sorry, but I have some doubts that this is truly that much of a performance benefit.

The only real way to know, of course, is to make some sort of comparison test between the two methods. We can discuss this for weeks, but until there is some kind of solid test showing that one method is better than the other, this is all wishy-washy talk with no real verification behind it. It'd be great if you (or someone else, I might try this myself during some free time), could make a test to actually verify that.

Keep in mind that it is a mess currently in code/triggers however in-game is a different opinion. Should be mostly operational for testing in game, some weird spiky-like lag happens however it is minimal and the fps seems to stay around 30 or above. Think its mostly graphic lag.

Edit: Will likely be able to reduce even more lag once I finish the rest of the system and replace a few things.

 

[HappyTauren]

Can you post an example map without everything that is unrelated to this functionality?

 

[ZiBitheWand3r3r]

It is very nice find, I just looked at test map and found out that source of lightning - unit with custom FoD ability can hit only one target. I guess setting cooldown to 99999 is simplest solution for this inconvenience. Then instead of ravenform remove/add FoD ability on source unit for killing lightning. Of course it needs a loop (but 0.50sec can be enough) for checking distance/source and target alive/visible for player owner of source-unit. In my opinion it may be very usefull for unit-to-unit lightnings, as we dont need 0.03sec timer loop, no need for checking unit's height, no need for moving light. Good find @Dat-C3 , aa and health bars are messed up because there are not needed changes made in Game Play Interface.