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...
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
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?
(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?
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?
Users browsing this forum: No registered users and 0 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