• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Lasertower System

This bundle is marked as awaiting update. A staff member has requested changes to it before it can be approved.
  • Like
Reactions: Devalut
Everything began when I felt the urge to have a tower which attacks using lightnings. But I didn't want it to have those normal lightning attacks which disappear betwenn every attack, so I created this system with a permanent lightning between tower and target.

After I finished the first working system with one target, I thought it would be great if the tower had some kind of chain lightning and would be able to attack two targets. Then came the idea to have it buildable etc.


Now I am here, presenting my first Jass map/spell/trigger whatever. A customizable laser tower system with damage increase over time, dmg reset after a certain time of not attacking, lightnig colour change during damage increasing, the possibility to have up to at least 20 (didn't test with more) targets at once, lightnings fitting flying heights, damage reduction per lightning jump and all of this buildable and upgradable in "melee" maps.

Hope you like it and can use it, would be very thankful for improvement suggestions concerning Jass from more experienced users than myself :3
Contents

Lasertower System (Map)

Reviews
MyPad
Is the user still active? If so, apologies for the inconvenience of reviewing it again so late. Interesting to look at, and even more interesting to realize it in person, a phrase that I dare say might suit the bundle. There are some issues I brought...
Level 12
Joined
Jun 12, 2010
Messages
413
Isn't there a new native called BlzIsUnitInvulnerable? Does it not work as expected? Because if it does, this function may be unnecessary.

JASS:
function IsUnitInvulnerable takes unit u returns boolean
   return GetUnitAbilityLevel(u,'Avul')==1 or IsUnitSleeping(u) or IsUnitCycloned(u)
endfunction

Also, to make importing the system easier, you should make it into a library and put it into a separate trigger, instead of the map header. This way, people can just copy the trigger instead of having to copy the map header.

Also, don't use SaveRealBJ that function is just a wrapper over SaveReal which inverts the order of the arguments (to fit into GUI structure). Since it calls a function, it's much slower than the native. This goes for all the hashtable BJ functions that you used.

Anyway, this system looks pretty neat and easy to configure, but you should improve on those points, imho.
 
Level 3
Joined
Jun 30, 2012
Messages
9
The BJ, it burns~

On a more serious note, is this similar to Persistent Beam v3.2? If so, what's the advantage of this and the other system.

Is there something wrong with BJ? As I said, this was my first attempt of using Jass, I have not really any idea of what to use, especially when it comes to those BJ functions. For me, they were just easier to use so I chose them.

For a relatively small system such as this, of course there is a high chance that there already exist something similar and obviously more advanced. Therefore, I can't tell if my system has any advantage over Persistent Beam. For me, obviously because I made it, my system is easier to edit and use, but this os overall just my own opinion, can't really state that as an advantage :3

Wow that's super neat
Have a gif

I tried to upload a gif myself, but I failed miserably. Therefore, thank you very much :3

Isn't there a new native called BlzIsUnitInvulnerable? Does it not work as expected? Because if it does, this function may be unnecessary.

JASS:
function IsUnitInvulnerable takes unit u returns boolean
   return GetUnitAbilityLevel(u,'Avul')==1 or IsUnitSleeping(u) or IsUnitCycloned(u)
endfunction

Also, to make importing the system easier, you should make it into a library and put it into a separate trigger, instead of the map header. This way, people can just copy the trigger instead of having to copy the map header.

Also, don't use SaveRealBJ that function is just a wrapper over SaveReal which inverts the order of the arguments (to fit into GUI structure). Since it calls a function, it's much slower than the native. This goes for all the hashtable BJ functions that you used.

Anyway, this system looks pretty neat and easy to configure, but you should improve on those points, imho.

Is there? I didn't yet look into the new natives, I had more than enough trouble finding my way through the old ones. I found some kind of online Jass manual, but I don't think it has been updated with the newest natives. Would be nice to have some easy to use documentary. If you know some, please let me know :D

I will look into the new natives and see how I may use the suggested function in order to replace my version.

Now to BJ. As I stated above, for me, the BJ functions were just easier to use for me, I didn't know which one would be better. I will change those to the not BJ versions and try to not use BJ in future projects.

Thank you very much for your suggestions, helped me a lot :3
 
Last edited:
Level 38
Joined
Feb 27, 2007
Messages
4,951
Is there something wrong with BJ?
Yes, most BJ functions are just wrapper functions (that just add additional function calls to slow down your code), call regular functions with one of the arguments being static (essentially a wrapper), or force you to use locations when the natives take xy coordinates. They should generally always be avoided, but for code that only runs once or a couple times (like trigger setup) some of them (such as TriggerRegisterAnyUnitEventBJ) can be helpful/acceptable.

You can look at all the BJ functions here: JASS Manual: API Browser - Blizzard.j
And the natives here: JASS Manual: API Browser - common.j
These have not been updated for a while and don't contain the recent natives, but it's an easy to browse site for the older stuff. You could also extract the common.j and blizzard.j files from your own installation's CASC archive, or use an editor that includes TESH (trigger editor syntax highlighting).
 
Level 3
Joined
Jun 30, 2012
Messages
9
Yes, most BJ functions are just wrapper functions (that just add additional function calls to slow down your code), call regular functions with one of the arguments being static (essentially a wrapper), or force you to use locations when the natives take xy coordinates. They should generally always be avoided, but for code that only runs once or a couple times (like trigger setup) some of them (such as TriggerRegisterAnyUnitEventBJ) can be helpful/acceptable.

You can look at all the BJ functions here: JASS Manual: API Browser - Blizzard.j
And the natives here: JASS Manual: API Browser - common.j
These have not been updated for a while and don't contain the recent natives, but it's an easy to browse site for the older stuff. You could also extract the common.j and blizzard.j files from your own installation's CASC archive, or use an editor that includes TESH (trigger editor syntax highlighting).

I see, this was the manual I was using too.
It was annoying to use vanilla World Editor to make this, but somehow all the other Editors won't work properly for me right now, so gotta stick with what I have XD

Anyway, thanks for suggestions, I will not use BJ functions in future projects (and get rid of them in this project) :3
 
Level 12
Joined
Jun 12, 2010
Messages
413
I see, this was the manual I was using too.
It was annoying to use vanilla World Editor to make this, but somehow all the other Editors won't work properly for me right now, so gotta stick with what I have XD

Anyway, thanks for suggestions, I will not use BJ functions in future projects (and get rid of them in this project) :3

You need an old version of WC3 to use the editors with TESH =/

You can always try editing on an external tool and then copying the text into the triggers inside of the map. There JASS addons for Visual Studio Code and Notepad++.
 
Level 3
Joined
Jun 30, 2012
Messages
9
You need an old version of WC3 to use the editors with TESH =/

You can always try editing on an external tool and then copying the text into the triggers inside of the map. There JASS addons for Visual Studio Code and Notepad++.

Ye, tried to write the code in Notepad++ but as soon as I paste it into World Editor, wrapping is removed and everything becomes a one liner XD
 
Level 12
Joined
Jun 12, 2010
Messages
413
It's exactly as Pyro says, that's why I asked you to try notepad. You should see if there is a setting in Notepad++ to change the line endings from \n (newline) to \r\n (carriage return + newline), which are the Windows line endings. It's pretty weird for WE to only accept the less-used windows line endings, though. Since I always used TESH I assumed it accepted Unix newlines.
 
With the presence of a lot of BJ functions, there are a lot of things that can be optimized here.

Since the system is in JASS or vJASS, I highly recommend using real coordinates instead of location handles, as that saves a local dereference and destructor function invocation.

Using IsUnitAliveBJ is fine and all, but one can make the comparison of a unit's health directly or invoke a native that checks the unit's state (if it is alive or dead).

Some useful natives:
JASS:
native GetUnitX takes unit whichUnit returns real   // Returns the unit's x-coordinate in the world
native GetUnitY takes unit whichUnit returns real   // Returns the unit's y-coordinate in the world

// Must be declared in the map script
native UnitAlive takes unit id returns boolean
 
Last edited:
Interesting to look at, and even more interesting to realize it in person, a phrase that I dare say might suit
the bundle.

There are some issues I brought up here that might still hold as of the current version, so I will refer to them
here:

With the presence of a lot of BJ functions, there are a lot of things that can be optimized here.

Since the system is in JASS or vJASS, I highly recommend using real coordinates instead of location handles, as that saves a local dereference and destructor function invocation.

Using IsUnitAliveBJ is fine and all, but one can make the comparison of a unit's health directly or invoke a native that checks the unit's state (if it is alive or dead).

Some useful natives:
JASS:
native GetUnitX takes unit whichUnit returns real   // Returns the unit's x-coordinate in the world
native GetUnitY takes unit whichUnit returns real   // Returns the unit's y-coordinate in the world

// Must be declared in the map script
native UnitAlive takes unit id returns boolean
  • Function names appear to be too generic. For example, SetTarget might describe a missile being configured to strike a target, a Locust-based unit harvesting health off of an enemy unit, etc.

Hence, I'll have to move this to Awaiting Update
 
Top