[GUI-Friendly] Custom Missile System 1.4.1

Author(s)
Wietlol
Tags
System, GUI / Triggers, JASS, vJASS
Size
236.32 KB
Rating

(3 ratings)

Downloads
515
Created
Mar 1, 2015
Updated
Aug 11, 2024
Resources
1
State
Approved
This bundle is marked as useful / simple. Simplicity is bliss, low effort and/or may contain minor bugs.
View usage Statistics Legacy download
  • Like
Reactions: ILH
Description

This system provides a way to create flying projectiles or existing units and move them periodically.
It allows you to easily set the properties of the affected units via GUI triggers with minimal custom script usage.
Another nice feature is that a missile can hit the same target multiple times but not multiple times between the given amount of time.
Another reason why I made this system is to have missiles that can collide with other missiles and can be targetable.

Installation Guide

Settings:
  1. Enable JassHelper in the menu JassHelper > Enable JassHelper
  2. Enable vJass if not already enabled in the menu JassHelper > Enable vJass
Imports:
  1. Import the BLACK.tga texture (export from the example map and import in your map)
  2. Import the DUMMY.mdx model (export from the example map and import in your map)
  3. Import the MISSILE_DUMMY.mdx model (export from the example map and import in your map)
  4. Make sure all resources are in the same paths (at the root) as the example map or adjust the paths in the object editor resources
Object Editor:
  1. Copy the DUMMY unit (in Custom Units > Human > Melee > Units)
    You can copy the unit [ctrl][c] in the example map and switch to your map and paste [ctrl][v].
  2. Copy the MISSILE unit (in Custom Units > Human > Melee > Units)
  3. Copy the CMS ABILITY GHOST ability (in Special > Units)
  4. Copy the CMS ABILITY MORPH ability (in Special > Units)
    Set the "Data - Alternate Form Unit" to DUMMY
    Set the "Data - Normal Form Unit" to MISSILE
Trigger Editor:
  1. Copy the "Variables" folder or all the variables that start with "CMS_" and paste them in your map.
  2. Copy the "Required Libraries" folder and paste it in your map.
  3. Copy the "Custom Missile System (CMS)" folder and paste it in your map.
  4. In the CMS Configuration trigger, set the variables to the correct units and abilities from the object editor.
The map should now be ready to use the system.

Usage Guide

Creating a missile is done in 3 steps:
  1. Set "CMS_Starting..." variables.
    These variables define the starting state of the missile.
  2. Invoke "CMS_CreateMissileEx" using a custom script.
    This function creates a missile using the starting variables and returns an integer that references the missile.
  3. Set "CMS_Param_..." variables.
    These variables define the current behavior of the missile.
Here is a description of every CMS_Starting field:
  • CMS_StartingAcceleration (real default 0.00 aka not accelerating)
    Defines how fast the missile should speed up in distance units per second per second.
    I.e. when acceleration is 500, the missile's speed will be 500 more after 1 second and 750 more after 1.5 second. (Applied each tick.)
  • CMS_StartingAngle (real default 0.00 aka facing east)
    Defines in which direction the missile should be going at the start.
    The value is in degrees (0-360).
  • CMS_StartingDefaultValues (boolean default true)
    When true, uses the default values for the "CMS_Param_..." fields on creation.
    Not sure why you would ever want to try to turn that off.
  • CMS_StartingHeight (real default 60.00)
    Defines the height of the missile at creation.
    When the missile should be on the ground, the default value is usually good enough.
    When the missile should be in the air, set this value to what it should be. For example when the creator is a flying unit or like the meteor strike in the example map.
  • CMS_StartingLocation (point default null aka center of map)
    Defines where the missile will be spawned.
    This location automatically gets removed after missile creation, so do not use this location again after the missile is created.
  • CMS_StartingLocust (boolean default true)
    If true, the created missile will be given the locust ability. (Read more on the locust ability at world-editor-tutorials.thehelper.net Abilities - Guide.)
  • CMS_StartingMissile (unit default null)
    When set, this unit is used instead of creating a new missile unit.
    This can be useful for when the missile logic needs to be applied to existing units (for example a knockback effect).
    When set, the CMS_StartingLocust has no effect. The trigger creating the missile can handle that behavior itself.
    This is by design because the default value of true is not preferred in most cases for existing units.
  • CMS_StartingPitch (real default 0.00 aka facing horizontal)
    Defines how high up the missile is aiming at the start.
    The value is in degrees (0-90).
  • CMS_StartingSource (unit mandatory to set)
    Defines the owner unit of the missile.
    This is used to define the owner player of the missile.
    It also gets passed on to the CMS_Param_Source allowing other triggers to know which unit created the missile for example for scoring or dealing damage, etc.
  • CMS_StartingSourceFilter (boolean default true)
    When true, the creator (CMS_StartingSource) of the missile is initially excluded from collision to prevent it from being collided with immediately when the missile is created at the location of the creator.
    The creator will be made available for collision again just like any other unit after a specified amount of time.
  • CMS_StartingSpeed (real default 0.00 aka not moving)
    Defines the speed of the missile in distance units per second.
    Making it similar to the "Combat - Attack # - Projectile Speed" or "Movement - Speed" values for units or "Art - Missile Speed" value for abilities.
    Keep in mind that this is the 3D speed, which means that for missiles that are moving in the Z axis (height), their horizontal speed will be less based on their pitch.
  • CMS_StartingType (integer default -1)
    The type is a number used to invoke triggers with CMS events.
    The value should be a positive number (1 or higher) or -1 for "no type".
    See CMS Events for more information.
Creating the missile.
This is done via a custom script to invoke the function that handles the creation of the missile:
  • Custom script: call CMS_CreateMissileEx()
After the missile has been created, a lot more properties become available, controlling the current state of the missile.
These properties are all arrays and need to be accessed by the index of the missile.
At creation, the index would be whatever variable you use to store the result of the CreateMissile function which has the same value as the CMS_Amount variable.
On collision events, the index of the colliding missile would be CMS_LoopIndex.
On destruction events, the index of the destroyed missile would be CMS_Index.
Here is a description of every CMS_Param field:
  • CMS_Param_Collision_Unit (boolean default true)
    Defines if the missile should have collision detection with units.
  • CMS_Param_Collision_Dest (boolean default false)
    Defines if the missile should have collision detection with destructables.
  • CMS_Param_Collision_Item (boolean default false)
    Defines if the missile should have collision detection with items.
  • CMS_Param_Collision_Cooldown (real default 1.00)
    When a missile collides with a target, and the missile is not destroyed in the process (for example a piercing missile).
    The missile would probably collide with the same unit in the next tick... and probably as well in the tick after that, depending on the speed and collision size.
    The collision cooldown defines how long (in seconds) collided units should not be triggering collision events again after a collision event.
    This allows the units to be hit by the same missile multiple times.
    See the "Fury Fire" ability in the test map as example use case.
  • CMS_Param_Collision_Type (integer default NONE)
    Defines which collision algorithm to use.
    Options are:
    • CMS_COLLISIONTYPE_NONE (collision is disabled)
    • CMS_COLLISIONTYPE_SIMPLE
      Uses a very fast collision detection system by using grid aligned distance checks.
      This does mean that the collision size varies depending on the angle of the missile.
    • CMS_COLLISIONTYPE_CIRCLE
      Uses a relatively fast collision detection system by using the absolute distance in the horizontal plane.
      This should be the default for most missile usages with collision.
    • CMS_COLLISIONTYPE_RECTANGLE
      Uses a collision detection system that creates a rectangle from the previous position of the missile to the current position of the missile, fixing the potential gap issue of the above two systems.
    • CMS_COLLISIONTYPE_POLYGON
      Uses a system with custom polygons to create virtually any shape for the collision detection.
Assume a missile is moving along a path, here we are showing 3 positions where that missile would be in 3 ticks of the system:
View attachment 482081
COLLISIONTYPE_SIMPLE will use a grid aligned system and use simple X and Y distances between the game widgets and the missile itself.
This means that when the missile is moving directly east, west, north or south, the collision detection is correct.
But when it is moving at an angle, the collision detection becomes wider, making it sometimes hit units that are further away than the missile's collision width.
This type is the most efficient, but least accurate.
View attachment 482082
COLLISIONTYPE_CIRCLE will use a horizontal distance check.
This is less performant than the SIMPLE type, but it is more accurate and suffices in most scenarios.
View attachment 482083
However, when the missile is moving very fast or when the collision size is very small, both SIMPLE and CIRCLE will leave gaps in between the iterations of the missile's movement, allowing units to be not collided with even though they are directly in the path of the missile.
View attachment 482084
COLLISIONTYPE_RECTANGLE uses an angled rectangle with as width, the collision with of the missile and as length the distance between the positions in each tick and the collision with as start and end margin.
This is the most accurate collision detection, but more CPU intensive than the SIMPLE or CIRCLE collision types.
This should only be used when the other two are insuffient to apply collision reliably.
View attachment 482085
COLLISIONTYPE_POLYGON uses a system where you can define your own collision detection shape.
This is by far the worst for performance, but allows for full customization.
For example, using a heart shape to make units directly in the path of the missile hit earlier than units a bit further to the side.
This should only make any significant different for very large area collisions
View attachment 482086
  • CMS_Param_Collision_Width (real default 50.00)
    Defines the size of the collision.
    (Has no effect on polygon collision type.)
  • CMS_Param_Collision_Width_Inc (real default 0.00)
    Defines how much the size of the collision should increase per tick.
    (Has no effect on polygon collision type.)
  • CMS_Param_Collision_Height (real default 0.00)
    Defines the height of the collision detection.
    When the value is 0.00, the collision detection will check for height.
    When the value is above 0.00, the collision detection will check if the height difference between the missile and collided unit is less than the Collision_Height.
    This means that COLLISIONTYPE_CIRCLE for example is actually a cylinder, not a sphere.
    If the height is 0.00, the cylinder has practically infinite height, if the height is a different value, the cylinder has that specific height.
    Polygon collision type does have the same rules for height as other collision types.
  • CMS_Param_Collision_Height_Inc (real default 0.00)
    Defines how much the height of the collision should increase per tick.
  • CMS_Param_Distance (real default 0.00)
    Tells how far the missile has been travelling.
    This should only be read by your triggers, pretty much never set.
    Unless you want to reset the maximum distance check for example.
  • CMS_Param_Duration (real default 0.00)
    Tells how long the missile has been travelling.
    This should only be read by your triggers, pretty much never set.
    Unless you want to reset the maximum duration check for example.
  • CMS_Param_Effect (effect default null)
    This is a variable for an attached special effect.
    The special effect in this value is automatically destroyed and cleaned up when the missile is destroyed.
  • CMS_Param_Gravity (real default 0.00)
    Defines the amount of gravity that should be applied per tick.
    Gravity will increase the velocity in the direction of the ground by this amount.
  • CMS_Param_Index (integer default <auto-generated>)
    Defines a unique index for each missile.
    This can be used with custom arrays to define additional fields per missile, such as additional special effects or linked missiles.
    Keep in mind that this value can go up to very high numbers.
    This value is auto generated by the system.
  • CMS_Param_IsAUnit (boolean default false)
    Defines if the missile is a unit.
    When true, the system will not remove the unit when the missile logic ends.
    This should be true for applying knockbacks or dashes for example.
  • CMS_Param_IsDestroyed (boolean default false)
    Defines if the missile is destroyed.
    Should be set to true in a trigger with a collision event if the missile should be destroyed after colliding with something.
  • CMS_Param_IsFlying (boolean default false)
    Defines if the missile is flying.
    Flying missiles are allowed to update the pitch during re-aiming of homing missiles.
  • CMS_Param_IsHoming (boolean default false)
    Defines if the missile is homing into a specific target.
    When true, it will update the angle and pitch (when flying) to try to aim more towards the target.
  • CMS_Param_MaxDistance (real default 0.00)
    Defines the maximum distance that the missile is allowed to travel.
    When this amount is reached, the missile is automatically destroyed.
    When the value is 0.00, there is no maximum distance.
  • CMS_Param_MaxDuration (real default 0.00)
    Defines the maximum time that the missile is allowed to travel in seconds.
    When this duration is reached, the missile is automatically destroyed.
    When the value is 0.00, there is no maximum duration.
  • CMS_Param_Missile (unit default <auto-set>)
    References the missile unit itself.
    This value is auto assigned from the CMS_StartingMissile or from the newly created missile.
  • CMS_Param_Source (unit default <auto-set>)
    References the source unit of the missile.
    This value is auto assigned from the CMS_StartingSource.
  • CMS_Param_Subtype (integer default 0)
    Defines a sub type that you can use in your triggers.
  • CMS_Param_Target_Type (integer default NONE)
    Defines what kind of targeting system the missile is using.
    Only has effect when IsHoming is true.
    Options are:
    • CMS_TARGETTYPE_NONE (collision is disabled)
    • CMS_TARGETTYPE_UNIT
      The missile is targeting a unit, aiming closer towards it each tick.
    • CMS_TARGETTYPE_LOCATION
      The missile is targeting the ground at a specific location, aiming closer towards it each tick.
  • CMS_Param_Target_Location (point default null)
    Defines the target location of the missile.
    Only has effect when IsHoming is true.
    (This location is automatically removed when the missile is destroyed.)
  • CMS_Param_Target_Unit (unit default null)
    Defines the target unit of the missile.
    Only has effect when IsHoming is true.
  • CMS_Param_TurnRate (real default 0.00)
    Defines how fast the missile is rotating to aim at the target in degrees per tick.
    180+ would be instant rotation.
    5.4 would allow it to only do a full reverse after one second.
    When the value is 0.00, there is no rotation and IsHoming has no effect.
  • CMS_Param_Type (integer default <auto-set>)
    Defines the type of missile, which is used in trigger events.
    This value is auto assigned from the CMS_StartingType.
  • CMS_Param_WalkingHeight (real default 0.00)
    Defines the walking height of a missile.
    At this height, a non-flying missile will retain it's height from the ground instead of falling down due to gravity.
    Flying units below this height will be destroyed.
  • Firebolt Cast
    • Events
      • Unit - A unit Starts the effect of an ability
    • Conditions
      • (Ability being cast) Equal to Firebolt (2)
    • Actions
      • Set VariableSet TempLocation = (Position of (Target unit of ability being cast))
      • Set VariableSet TempUnit = (Triggering unit)
      • -------- - --------
      • Set VariableSet CMS_StartingLocation = (Position of TempUnit)
      • Set VariableSet CMS_StartingAngle = (Angle from CMS_StartingLocation to TempLocation)
      • Set VariableSet CMS_StartingHeight = 50.00
      • Set VariableSet CMS_StartingSource = TempUnit
      • Set VariableSet CMS_StartingSpeed = 700.00
      • Set VariableSet CMS_StartingAcceleration = 200.00
      • Set VariableSet CMS_StartingType = 1
      • Custom script: set udg_TempInteger = CMS_CreateMissileEx()
      • -------- - --------
      • Set VariableSet CMS_Param_WalkingHeight[TempInteger] = 55.00
      • Set VariableSet CMS_Param_Gravity[TempInteger] = (-45.00 x 0.03)
      • Set VariableSet CMS_Param_MaxDistance[TempInteger] = 1700.00
      • Set VariableSet CMS_Param_Collision_Type[TempInteger] = CMS_COLLISIONTYPE_CIRCLE
      • Set VariableSet CMS_Param_Collision_Width[TempInteger] = 20.00
      • Set VariableSet CMS_Param_Collision_Height[TempInteger] = 75.00
      • Special Effect - Create a special effect attached to the origin of CMS_Param_Missile[TempInteger] using Abilities\Weapons\FireBallMissile\FireBallMissile.mdl
      • Set VariableSet CMS_Param_Effect[TempInteger] = (Last created special effect)
      • -------- - --------
      • Custom script: call RemoveLocation(udg_TempLocation)
The system knows the following events:
  • on Created (invoked when a new missile is created)
  • on Destroyed (invoked when a missile is destroyed)
  • on Tick (invoked for each missile on every tick)
  • on Collided with Destructible (invoked when a missile collides with a destructible)
  • on Collided with Item (invoked when a missile collides with an item)
  • on Collided with Terrain (invoked when a missile collides with the terrain)
  • on Collided with Unit (invoked when a missile collides with a unit)
To create a trigger with a missile event, add an event like one of the below:
  • Events
    • Game - CMS_Event_Missile_Created becomes Equal to 0.00
    • Game - CMS_Event_Missile_Destroyed becomes Equal to 0.00
    • Game - CMS_Event_Missile_Tick becomes Equal to 0.00
    • Game - CMS_Event_Missile_Collided_D becomes Equal to 0.00
    • Game - CMS_Event_Missile_Collided_I becomes Equal to 0.00
    • Game - CMS_Event_Missile_Collided_T becomes Equal to 0.00
    • Game - CMS_Event_Missile_Collided_U becomes Equal to 0.00
To create a trigger with a missile event specifically for a certain missile type, set the value in the event (i.e. the 0.00 in the above example) to the missile type number.
Triggers with "... becomes Equal to 0.00" will trigger for every missile.
Triggers with "... becomes Equal to 1.00" will trigger only for missiles with type 1.
Triggers with "... becomes Equal to 2.00" will trigger only for missiles with type 2.
etc.

In each event, the missile parameters are available via index.
In Created events, the index is CMS_Amount.
In Destroyed events, the index is CMS_Index.
In Tick events and Collided events, the index is CMS_LoopIndex.

In Collided events, the following variables are also available:
  • CMS_Collided_Dest (for collision with destructibles)
  • CMS_Collided_Item (for collision with items)
  • CMS_Collided_Unit (for collision with units)
When colliding with a target, the target will probably be collided with on next tick and after that as well because of the tiny ticks of the system.
So, when colliding, the collision trigger should probably do one of two things:
  1. Set CMS_Param_IsDestroyed[CMS_LoopIndex] to true
    This will destroy the missile after the collision, preventing it from colliding with anything.
  2. Set CMS_ValidTarget to true
    This will tell the system that the collided target is a valid target and will apply the collision cooldown on it, preventing it from being collided with again for a specified amount of time.
Keep in mind that any unit can be collided with (except locust units).
So, for most collision event triggers, you probably want to verify that:
  1. The collided unit is not a structure (unless the missile should hit buildings, like shockwave)
  2. The collided unit is either an enemy or ally (enemy for negative effects and ally for positive effects)
  3. The collided unit is not dead (unless the missile should hit dead units, like a resurrection wave)
For example:
  • If - Conditions
    • (CMS_Collided_Unit is A structure) Equal to False
    • (CMS_Collided_Unit belongs to an enemy of (Owner of CMS_Param_Source[CMS_LoopIndex]).) Equal to True
    • (CMS_Collided_Unit is dead) Equal to False
When an ability is used, creating a missile that flies towards the target, the user can still level up the ability that was used before the missile hits the target.
While this is an edge case and most users won't really care if the missile will deal the damage of the level it had when it was created or when it hit the target, the system does provide a way to attach extra information to the missile by providing a unique index to each missile in use.
This index can then be used to access data in either an array or hashtable to attach more information.
Take for example the triggers for Jaina's Blizzard in the example map.
In the "Blizzard Cast" trigger, the damage is calculated and set in the "Blizzard_Damage" variable using the index of the last created missile:
  • -------- attach damage value to the missile --------
  • Set VariableSet Blizzard_Damage[CMS_Param_Index[CMS_Amount]] = damage
In the "Blizzard Collide" trigger, the damage is read from that same variable using the index of the colliding missile:
  • -------- read the damage again as it was set on cast --------
  • Set VariableSet damage = Blizzard_Damage[CMS_Param_Index[CMS_LoopIndex]]
This way, the damage can be calculated on cast rather than on hit and would be more accurate.
This matters more if for example the damage would increase based on if the user has a buff or not.
Players would expect that the missile would receive that bonus damage if the user had the buff when the missile was created, not when it landed.
Especially if that should also remove the buff on use (on creation of the missile).
In the example map, there is a Paladin with 4 abilities using the missile system:
  1. Magic Missile:
    Launches a missile at the target unit, following it.
  2. Firebolt:
    Launches a missile at the target unit.
    If the missile hits, it knocks back the hit unit.
    If the unit being knocked back hits a cliff, it takes damage.
    Firebolt cannot hit flying units (unless terrain allows it to).
  3. Fury Fire
    Creates a missile that spins in a circle, hitting units in it's path.
    Fury Fire cannot hit flying units (unless terrain allows it to).
  4. Meteor Strike
    Calls down a giant meteor from the sky at the target location.
    When it lands, kills all (enemy and friendly) units in the target area.
There is also Jaina with 2 abilities using the missile system:
  1. Blizzard:
    Calls down a wave of freezing ice shards that damage units in a target area.
  2. Frost Nova:
    Creates an ice explosion, sending ice shards in every direction.
    (Which looks a lot like Gandalf's fireworks in Lord of the Rings: Gandalf's Fireworks )
There is also a Tinker with 2 abilities using the missile system:
  1. Rocket Barrage
    Launches 8 rockets at the target area. Damaging allies and enemy units.
  2. Seeker Missile
    Launches a rockets in the target direction. The rocket will search for enemies to engage on and will explode on impact.
The enemy units wont attack. They just act as dummy targets for target practice.

There is a chat command /test that will run all test scenarios.
There is a chat command /showcase that will run all abilities mentioned above.
The test and showcase commands also accept a filter for example /test collision which only runs the tests with "collision" in their name.
Tests will probably fail if the user is starting tests while other tests are still running.
Tests will probably fail if the user is creating other missiles while the tests run.

There are two videos showing the above scenarios:

Changelog:
- 1.4.1 - Added examples and fixed some bugs.
- 1.4 - Added additional features (detection, optimized events, acceleration).
- 1.3 - Redesigned data and calculation structure.
- 1.2 - Rewritten the system.
- 1.1 - Fixed Collision bugs.
- 1.0 - Official releas on te Hive

Feel free to post any feedback or suggestions.

Keywords:
Wietlol, CMS, Missile, Projectile, Knockback, Knockup, Dash, Jump, Leap, System, Firebolt, Advanced, OP, GUI.
Contents

Custom Missile System (Map)

Author
Unknown
Filename
Custom-Missile-System-1.4.1.w3x
Suggested players
Any
Players
1
Required game
Warcraft 3: Reforged
Recommended version
1.36
Dimensions
52x52 (64x64)
Size
236.32 KB
Uploaded
Aug 11, 2024
Updated
Never
Map Info View Resources In Use Preview Triggers Download
Reviews
29.02.2016 BPower: Very well written. Very read-able as expected. The homing missile behaviour doesn't work for me in the uploaded test map. I think it has to to with radians to degree conversion. Can you check that? 21:56, 16th Jun 2015...
Read full review...

Shaeam

Shaeam

Shaeam

Level 7
Joined
Aug 11, 2010
Messages
270
Wietlol said:
Because the API is incomplete, the code is far from optimal and it is a pain to read/edit.
Click to expand...

I actually find it easier to modify than the 3D bash system, which is is the system everyone seems to recommend when recommending a missile system. If you wouldn't recommend this system, what would you recommend? Because honestly; the feature set of this one has forever won my heart, but I'm willing to try out other systems.
 

darkravenbest

darkravenbest

darkravenbest

Level 8
Joined
Aug 5, 2014
Messages
205
It is possible to change size of missile? And its possible to add more than one effect on the missile?

I've edited the code, to allow me to do it, but were there any built-in parameters to to this?
 
Last edited:

Wietlol

Wietlol

Wietlol

Level 24
Joined
Aug 1, 2013
Messages
4,658
Just updated the map with better examples and uploaded 2 videos with the showcasing and test scenarios.
See the system's description for more details.

It is possible to change size of missile?
Click to expand...
Yes, you can scale the created missile unit, which in turn scales the special effects added to those units.
Although this is not available via GUI, so you would need a custom script (after the creation of the missile).
This will set the last created missile's scale to 3 times the normal size. (3 times in depth, 3 times in width and 3 times in height)
JASS: 
call SetUnitScale(udg_CMS_Param_Missile[udg_CMS_Amount], 3, 3, 3)

And its possible to add more than one effect on the missile?
Click to expand...
Not with built-in options.
You can create the special effect on the missile, but only one will be automatically deleted.
You can however store the second special effect in your own array with custom data attached to the missile.
See the "Custom Data" section in the description for more information.
 
You must log in or register to reply here.

Similar threads

Wietlol
[GUI] Item Set System 1.4.1
Replies
24
Views
13K
3xKataratos
3xKataratos
_Guhun_
[GUI-friendly] Timer System
Replies
3
Views
6K
Devalut
Devalut
_Guhun_
[GUI-friendly] Aura System
Replies
19
Views
5K
Ricola3D
Ricola3D
Rheiko
[GUI-Friendly] Knockup System v1.1b
Replies
12
Views
688
Rheiko
Rheiko
AutisticTenacity
GUI Friendly Shield System 1.00b
Replies
35
Views
11K
KitsuneTailsPrower
KitsuneTailsPrower
Top