Lightning Field v1.0

[Moderator]

12th Dec 2015
IcemanBo: Too long as NeedsFix. Rejected.

Moderator: Pharaoh_ Date: 22:51, 12th Jul 2012 One spell having so many triggers is unacceptable. Merge them, ask within Triggers and Scripts forum, if it is more convenient. You do not need the unit group to have an array; you are destroying every possible group this way, owned by the 12 players. You are supposed to only "kill" the group that has been created for that specific player only. MPI is so old-news. Update it to MUI.

 

[KnnO]

Nice spell.

- Change the (Integer A) in all for loops to an integer variable you create, it avoids errors, when there is many custom abilities and triggers using this in the same map.

 

[GhostRiderX]

Ok, thanks for advice, I changed it

 

[Magtheridon96]

This gives me an idea.

I need to write a tutorial explaining the ugliness and bug-prone usage of (Integer A) in loops.
It's more complex than you think.

Most users don't understand /why/ this is buggy.

And about the spell, well, all I'm going to say is that it would be far better if you were to store things like (Owner of (Triggering unit)) and (Triggering unit) in variables so you don't have to continue calling the functions again and again and again and again.

An example:

Trigger

• Cast
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to Lightning Field
  • Actions
    • Set LR_Int = 0
    • Set LR_Caster = (Triggering unit)
    • Set LR_Level = (Real(Level of Lightning Field for LR_Caster))
    • Set LR_Caster_Loc = (Position of LR_Caster)
    • Set LR_Player = (Triggering player)
    • For each (Integer LR_Int2) from 1 to 4, do (Actions)
      • Loop - Actions
        • Set LR_Int = (LR_Int + 90)
        • Set LR_Target_Loc = (LR_Caster_Loc offset by ((Real(LR_Radius)) + LR_Level x (Real(LR_Radius_PerLVL)))) towards (Real(LR_Int)) degrees)
        • Unit - Create 1 Lightning Orb for LR_Player at LR_Caster_Loc facing Default building facing degrees
        • Set TempUnit = (Last created unit)
        • Unit - Order TempUnit to Move To LR_Target_Loc
        • Unit - Add Lightning Field to TempUnit
        • Unit - Set level of Lightning Field for TempUnit to (Integer(LR_Level))
        • Unit - Add a (((Real(LR_Radius)) + ((Real(LR_Radius_PerLVL)) x LR_Level)) / 520.00) second Generic expiration timer to TempUnit
        • Custom script: call RemoveLocation(udg_LR_Target_Loc)
    • Custom script: call RemoveLocation(udg_LR_Caster_Loc)

 

[zv27]

Totally chaotic way to make such a simple spell !!!

I hate spells with more than two trgs.
The best solution is: one spell,one trigger.
Which means, jass and only jass.

 

[defskull]

Totally chaotic way to make such a simple spell !!!

I hate spells with more than two trgs.
The best solution is: one spell,one trigger.
Which means, jass and only jass.

Don't ever compare GUI with JASS... ever.

 

[GhostRiderX]

This gives me an idea.

I need to write a tutorial explaining the ugliness and bug-prone usage of (Integer A) in loops.
It's more complex than you think.

Most users don't understand /why/ this is buggy.

And about the spell, well, all I'm going to say is that it would be far better if you were to store things like (Owner of (Triggering unit)) and (Triggering unit) in variables so you don't have to continue calling the functions again and again and again and again.

Oh well, yeah it's more simple like that, I'll use that in future, thanks

 

[zv27]

Don't ever compare GUI with JASS... ever.

Go play Super Mario man muhahahaha

 

[GhostRiderX]

Totally chaotic way to make such a simple spell !!!

I hate spells with more than two trgs.
The best solution is: one spell,one trigger.
Which means, jass and only jass.

Not everyone knows Jass ...

 

[zv27]

Do not see my comment as something bad, cynical and so on.I also do not know jass ,but the six trigger for one spell..hmm it is really too much!

 

[Magtheridon96]

GUI and JASS have their pros and cons.

GUI:

• Pros:
  • The graphic interface is nice.
  • It's very beginner friendly.
• Cons:
  • The functions it uses are incredibly slow and redundant most of the time.
  • It's hard to develop complex systems.

JASS: (Not vJASS, plain JASS with the normal editor.)

• Pros:
  • Very fast system development.
  • Convenience and easier configuration thanks to functions which can be used as filters and shit.
• Cons:
  • It's hard to read the code due to the lack of highlighting.
  • Syntax errors can occur a lot due to the lack of highlighting.
  • The syntax checker is terrible.

vJASS fixes all of JASS problems giving it 0 cons.
Well, there's only one con. We have to use some workarounds to
fix JassHelper issues and get top-notch scripts with no shit-code.

vJASS > JASS = GUI.

 

[Kingz]

Plain JASS is in most cases again better than GUI.
Local variables and globals are much cleaner and easier to use if nothing else.

 

[Magtheridon96]

With no highlighting, development is harder. Plain JASS would be far better for development if the normal editor had highlighting.
In general, yes: JASS > GUI, but for beginners, they're just about the same.
This isn't a problem for people like me though, I don't need highlighting.
In fact, most of my systems are made here, on the spot, with no compiling or testing, and I don't often get errors

 

[eubz]

Too much triggers for a simple spell.

 

[defskull]

This gives me an idea.

I need to write a tutorial explaining the ugliness and bug-prone usage of (Integer A) in loops.
It's more complex than you think.

Most users don't understand /why/ this is buggy.

Maggy, a delivery!

What they were discussing;
(Integer A) is a global which might collide with another (Integer A) usage in another trigger (provided that 2 triggers run at the same time using the same (Integer A)).

But as I have been told that Warcraft III uses a single-threaded system which if a global is shared (used in another trigger at the same time), it won't bug because it would run in Trigger A first before running to Trigger B (though, we can't see the speed of these "queue")

If you want a prove, try these triggers;

• Trigger A
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Set u = Blood Mage 0000 <gen>
    • Unit - Kill u

• Trigger B
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Set u = Blood Mage 0001 <gen>
    • Unit - Kill u

It will kill both of those units but they share the same global variable, right ?
That's why it won't bug.

NOTE: But with the use of TriggerSleepAction or Waits, it could bug the system, otherwise it will work as it intended.

 

[KnnO]

But as I have been told that Warcraft III uses a single-threaded system

- I read that somewhere yesterday and I think what you said is 100% right.
- but the advantage of using a variable de-indexing, .. or ...
(I think you can use something like bj_loopAInteger -= 1 )
- Also I never seen it bugging

 

[defskull]

(I think you can use something like bj_loopAInteger -= 1 )

Computer Science method much ?
Haha just type it completely.

 

[Magtheridon96]

Maggy, a delivery!

The amount of idiocy in that thread amuses me :L

Yes, (Integer A) does bug.

If you nest an Integer A loop inside of an integer A loop, it will bug.
And no, this can't be avoided theoretically speaking.

Never use (Integer A). Never I say.

Triggers

• Derp
  • Events
    • Unit - A unit dies
  • Conditions
  • Actions
    • For each (Integer A) from 1 to 10, do (Actions)
      • Loop - Actions
        • Custom script: call BJDebugMsg("la la la la la A unit died la la la la la la la")

• Herp
  • Events
  • Conditions
  • Actions
    • For each (Integer A) from 1 to 10, do (Actions)
      • Loop - Actions
        • SomeUnit = (Random unit in .....)
        • Unit - Kill SomeUnit

See how that bugs?
And it's unavoidable. Individually, they both look perfectly fine. Nothing's wrong with them.
When put together, they interfere with each other.

Don't use (Integer A). Never I say!

NEVER.

Thanks :3

 

[KnnO]

Computer Science method much ?
Haha just type it completely.

I know Jass/vJass but not using it much distracts my knowledge lol

 

[defskull]

There is a catch, I said that in my previous post didn't I ?
There are restrictions not to use that, not to use this, such as Waits, well I think if it's meant for simple things you can use (Integer A) but if it's deep and runs through lots of code, I suggest it should be our own variable because that function is meant for simplicity.

Also, you should not use this as to interfere with each other's Events (like what you did in that example), it should be Trigger A did its thing and Trigger B did its thing, if it meant to interfere, well, just resort to variables I guess.

There's no harm in using as long you know the taboo.

 

[KnnO]

Yes They bug ... If you are nesting/using nesting-like triggers.

If you know what you are doing, then use it.
I think that is what was discussed in that thread