Sword weapontype
Moderator: Moderators
Sword weapontype
A weapontype used for swords with an appropriate effect:
It would emit a polygon trail (like swords do in many console games) from a line of defined length, when fired the line would exist for a given time and be attached to the piece it's fired from (including rotation), if it moves in a way that intersects a collision primitive damage is dealt to the target. Each time the weapon is fired it could hit each target only once. The explosion effect is spawned whenever it intersects. Range would be counted from the center of the attacker to the edge of either the footprint or the collision primitive of the target. Only the trail is visible, it's assumed that the modder will create the look of the sword itself. By default the sword would "reload" when FireWeaponX returns instead of having a reload time.
IsSword: The tag that defines a weapon as this type.
SwordLength: Length of the collision line.
SwordVisibleLength: If desired the visible length can be different from the actual length, defaults to the value of SwordLength.
Color/ColorRGB: Obvious.
Intensity: Alpha for the trail.
Duration: Time the sword remains active after being fired.
TrailTime: Time each trail segment exists after being emitted.
It would emit a polygon trail (like swords do in many console games) from a line of defined length, when fired the line would exist for a given time and be attached to the piece it's fired from (including rotation), if it moves in a way that intersects a collision primitive damage is dealt to the target. Each time the weapon is fired it could hit each target only once. The explosion effect is spawned whenever it intersects. Range would be counted from the center of the attacker to the edge of either the footprint or the collision primitive of the target. Only the trail is visible, it's assumed that the modder will create the look of the sword itself. By default the sword would "reload" when FireWeaponX returns instead of having a reload time.
IsSword: The tag that defines a weapon as this type.
SwordLength: Length of the collision line.
SwordVisibleLength: If desired the visible length can be different from the actual length, defaults to the value of SwordLength.
Color/ColorRGB: Obvious.
Intensity: Alpha for the trail.
Duration: Time the sword remains active after being fired.
TrailTime: Time each trail segment exists after being emitted.
I *NEED* MELEE
+9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9
+9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9^9^9^9^9^9^9
^9^9^9^9^9^9^9
- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
Re: Sword weapontype
I'd rather we used another rendertype for thisKDR_11k wrote:IsSword: The tag that defines a weapon as this type.
I think there's already a length tag - for lasersKDR_11k wrote:SwordLength: Length of the collision line.
And I think there's something similar to this for lasers as well, but I can't remember what it's called...KDR_11k wrote:SwordVisibleLength: If desired the visible length can be different from the actual length, defaults to the value of SwordLength.
Re: Sword weapontype
I think all we need for melee is some tag that make weapon aims for the closest side of the target footprint, instead of aiming for the target center.
Not all melee would need polygon trail, and polygon trail could be used for ranged weapons as well.
Not all melee would need polygon trail, and polygon trail could be used for ranged weapons as well.
Re: Sword weapontype
I agree with the lord of scripting.zwzsg wrote:I think all we need for melee is some tag that make weapon aims for the closest side of the target footprint, instead of aiming for the target center.
Not all melee would need polygon trail, and polygon trail could be used for ranged weapons as well.
Re: Sword weapontype
Correct me if I'm wrong, but isn't, for the purposes of projectile collision, the sphere used instead of the footprint? Thus, all that really needs to happen is that range calculations should add the radius of the target's collision sphere in determining if a unit can be hit?zwzsg wrote:I think all we need for melee is some tag that make weapon aims for the closest side of the target footprint, instead of aiming for the target center.
Not all melee would need polygon trail, and polygon trail could be used for ranged weapons as well.
The only real problem occurs if you have a unit where the footprint is substantially smaller than the collision sphere, preventing a hand-to-hand unit from getting close enough to attack. Which is why I see you want to use the footprint... but that approach creates a strange inconsistency where the footprint is used for hand-to-hand while the sphere is used for projectiles.
But I'm neither a modder nor coder - just a humble tool-maker, so I should STFU and GBTW.
No I tried that already some time ago on request of smoth (offsetting the weapon range with collision sphere size on checks whether a unit can fire) but, while this did make the unit fire the weapon correctly, the weapon didn't deal any damage, possibly because damage calcs work on the center of a unit. (so AoE of weapon would need to be > collision sphere size of attacked unit)
Also IIRC it kept pushing it's target like mad to get to the center
Also IIRC it kept pushing it's target like mad to get to the center

Oh yes, the sphere blocking damage is fun. I had that issue in an early version of CvC, sometimes drones would take no damage at all.
What I think I forgot to mention is that the sword would check whether the path it moved (can be linear interpolation) intersected with the target, not just its current position each frame. When I tried to use beamlasers fast swings failed to connect.
While we're at it, would be nice if all pgrojectiles checked for collision on a line between their old and new position rahter than just their current position each frame, fast weapons tend to go through small units (e.g. the Tiger's ion cannon tends to go through drones and turrets in CvC if they are at just the right distance).
What I think I forgot to mention is that the sword would check whether the path it moved (can be linear interpolation) intersected with the target, not just its current position each frame. When I tried to use beamlasers fast swings failed to connect.
While we're at it, would be nice if all pgrojectiles checked for collision on a line between their old and new position rahter than just their current position each frame, fast weapons tend to go through small units (e.g. the Tiger's ion cannon tends to go through drones and turrets in CvC if they are at just the right distance).
It sounds like several issues then - the unit AI also attempts to get into firing range based on range (not range + target radius), and the damage calculation only considers damage that hits the center of a unit...Tobi wrote:No I tried that already some time ago on request of smoth (offsetting the weapon range with collision sphere size on checks whether a unit can fire) but, while this did make the unit fire the weapon correctly, the weapon didn't deal any damage, possibly because damage calcs work on the center of a unit. (so AoE of weapon would need to be > collision sphere size of attacked unit)
Also IIRC it kept pushing it's target like mad to get to the center
that can't be right, can it? Wouldn't that mean that peewees do no damage to Krogoths? After all, if the weapons collide when they hit the surface of the Krogoth's sphere, and the damage dealt is calculated based on the blast radius and distance to centre, woudln't that mean that peewees wouldn't hurt? Otherwise I don't see how a peewee shell hitting the surface of a hitsphere differs from a sword... unless this is one more way that lasers differ from normal weapons (and the sword is actually a hidden laser, not a hidden projectile).
- LathanStanley
- Posts: 1429
- Joined: 20 Jun 2005, 05:16
amusingKDR_11k wrote:As usual I have no idea what the hell Picasso is trying to suggest or why he thinks it's a good idea.

he's thinking I think....
Piccasso? um... that dosen't make much sense.. but I think I can understand that you mean to "spawn" something when the "attack" is ordered to "force" the attack on the said "target?"...
uhh... um... way beyond me.
Units like Ships have TurretTowers (Moving Weaponheads) with the Cannons inside. Now to make a SwoardArm for a Unit you just need to modell it and make it a Tower that like on a Ship is resting (and turning around) the Shoulders of the Unit. The Tower could start moving if the Enemy Sphere comes in ShortRange, fire a invisible Shot once it has aimed enough on the Target. After the Turretower is "fired" and had its hit, the Tower has a "Reset" and the Process starts again. Bad idea ? Maybe.
Sorry if some of my Posts are getting worser, but i am elsewhere with my thoughts right now.. Hope you don`t feel offended..
Sorry if some of my Posts are getting worser, but i am elsewhere with my thoughts right now.. Hope you don`t feel offended..
- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07