View topic - Status of melee weapons.



All times are UTC + 1 hour


Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: 03 Aug 2011, 19:51 
Cursed Developer
User avatar

Joined: 17 Feb 2005, 22:05
knorke wrote:
Problem I found with short ranged "melee weapons" was that when in close distance (like it happens in melee combat) weapons refuse to fire sometimes. (also a problem with CT's mining if the weapon range is set too low) I think it has to do with hitvolumes intersecting or emit points being inside a hitvolume(?)
As you said. The hitspheres and footprint sizes need to be adjusted carefully for all units or targetborder won't work as soon as the emit point is inside the targeted sphere. Take a look at The Cursed - there should be no buildings/big units left that can't be attacked properly with melee weapons.

smoth wrote:
Unit stops in place does swing animation..
Rapid fires a weapon forward.
Target get hit by weapon call...
Chance to block if direction comes from front...
If success target does block animation...

Thoughts guise?
I had the vague idea of using HitByWeapon in the lua animation scripts to "fake" blocking by returning zero damage (and play an animation) if the weapon is fired from the front and is melee. I never did actually try it though...


Top
 Offline Profile  
 
PostPosted: 20 Aug 2011, 11:29 
Cursed Developer
User avatar

Joined: 17 Feb 2005, 22:05
Here is an experimental parry script. You can see that units only parry when they are not just attacking (first few hits).

http://www.youtube.com/watch?v=mv8WysvnLZY

What does it do:
- check: is the attacking weapon a melee weapon?
- check: is the attack coming from the front of the unit?
- check: is the unit currently attacking?
- check: is the unit already parrying something?

It might be of interest for Smoth and CarRepairer (CA:K).

Code:
UNITSCRIPT:

local attacking, parried, isparrying

function script.parry()
   if math.random()>0.33 then
      parried = true
   end
end

function script.HitByWeapon ( x, z, weaponDefID, damage )
   parried = false
   GG.CheckParriableWeapon(unitID, weaponDefID)
   if (parried and (z>0)) then
      if ((not attacking) and (not isparrying)) then
         isparrying = true      
         StartThread(MeleeAnimations)   
         return(0)
      end
   else
      return(damage)
   end   
end

function script.AimWeapon1(heading, pitch)
   randomsleeptime = math.random(50)
   Sleep(randomsleeptime)
   if isparring then
      return false
   end
   Sleep(50)
   Signal(SIG_AIM1)
   SetSignalMask(SIG_AIM1)
   return true
end

function script.Shot1()
   attacking=true
   StartThread(MeleeAnimations)
end

MeleeAnimations=function()
   if attacking then
      .......
   end
   if isparrying then
      .......
   end
   attacking=false
   isparrying = false
   return(1)   
end

Code:
GADGET:

if (not gadgetHandler:IsSyncedCode()) then
   return false
end

local parriableWeaponDefs = {}

local function CallUnitScript(unitID, funcName, ...)
   Spring.UnitScript.CallAsUnit(unitID, Spring.UnitScript.GetScriptEnv(unitID).script[funcName], ...)
end 


function gadget:Initialize()
   for i=1,#WeaponDefs do
      if (WeaponDefs[i].description =="Melee") then
         parriableWeaponDefs[i] = 0.98
      end
   end
end

function GG.CheckParriableWeapon(unitID, weaponDefID)
   if not parriableWeaponDefs[weaponDefID] then return end
    CallUnitScript(unitID,"parry")   
end


Top
 Offline Profile  
 
PostPosted: 20 Aug 2011, 13:14 
Moderator
User avatar

Joined: 22 Feb 2006, 01:02
Location: cheap kitchen
nice!
video looks like from The Settlers 2. :-)

That is how I would do it too, with one difference:
Instead of doing
script.HitByWeapon
if (parried ...

I would put that into the gadget like

gadget:UnitPreDamaged()
if (meleeUnits[unitID].parried ...
[/i]

You can start the animations from the gadget.
One problem might be that gadget:UnitPreDamaged() does not get the direction of the attack. Maybe GetUnitHeading could be used to see if attacker/defender are facing each other etc.
Advantage would be to only have animation stuff in the unitscript while the logic stuff would be in all in the gadget. (and not multiple times in several unit scripts, so if you change something there it just needs to be changed in one place)


just wondering is
MeleeAnimations=function()
the same as
function MeleeAnimations()
or what does this do?


Top
 Offline Profile  
 
PostPosted: 20 Aug 2011, 14:54 
Content Developer
User avatar

Joined: 13 Jan 2005, 00:46
Location: ModalitÃ
knorke wrote:
(also a problem with CT's mining if the weapon range is set too low) I think it has to do with hitvolumes intersecting or emit points being inside a hitvolume(?)
yeah something like that happens. if a firepoint goes inside a unit. The shooter cannot shoot. it is a really dumb spring "feature" that makes me rage on a regular basis.

knorke wrote:
But I think best would be a gadget that keeps track of all melee units.
ie their recharge, blocking status, and if a attack was blocked.
The gadget would then deal out damage via AddUnitDamage() and use CallAsUnit() to notify units what animation to play (attack/block/hit)

For gundam this would be damn near all units. Wouldn't that be pretty expensive and have to update frequently?


Top
 Offline Profile  
 
PostPosted: 21 Aug 2011, 11:13 
Cursed Developer
User avatar

Joined: 17 Feb 2005, 22:05
knorke wrote:
That is how I would do it too, with one difference:
Instead of doing
script.HitByWeapon
if (parried ...

I would put that into the gadget like

gadget:UnitPreDamaged()
if (meleeUnits[unitID].parried ...
[/i]

You can start the animations from the gadget.
One problem might be that gadget:UnitPreDamaged() does not get the direction of the attack. Maybe GetUnitHeading could be used to see if attacker/defender are facing each other etc.
Advantage would be to only have animation stuff in the unitscript while the logic stuff would be in all in the gadget. (and not multiple times in several unit scripts, so if you change something there it just needs to be changed in one place)

Actually that was my first try. As you said - it is more difficult to get the direction of the attack. When you do it in the animation script you can easily get the incoming attack as a direction in unit-space. Thus no math or complicated scripting is needed. It is the lazy way. You could use the non-amination part of the script as a module (inculde) in the animation scripts if you want to avoid changes to multiple scripts.

knorke wrote:
just wondering is
MeleeAnimations=function()
the same as
function MeleeAnimations()
or what does this do?
As far as I can see it is the same.


Top
 Offline Profile  
 
PostPosted: 21 Aug 2011, 16:44 
Cursed Zero-K Developer
User avatar

Joined: 07 Nov 2007, 21:48
Location: Horse
Oh yeah I made one a while ago but I forgot about it.

Image


Top
 Offline Profile  
 
PostPosted: 21 Aug 2011, 16:46 
Content Developer
User avatar

Joined: 13 Jan 2005, 00:46
Location: ModalitÃ
what happens when they move around?


Top
 Offline Profile  
 
PostPosted: 21 Aug 2011, 16:59 
Cursed Zero-K Developer
User avatar

Joined: 07 Nov 2007, 21:48
Location: Horse
Then it looks dumb. I never finished it.


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

All times are UTC + 1 hour


Who is online

Users browsing this forum: Google [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group

Site layout created by Roflcopter et al.