| 07-11-2004, 09:56 PM | #1 |
Well, I have tried quite a few things, and I can't seem to give a hero the root ability without making the game crash. What I want is a hero tower that is able to turn to face where it is attacking. If anyone has any ideas please let me know. |
| 07-11-2004, 11:40 PM | #2 |
You could make it an ancient. That's supposed to work. Myself I prefer to give a building movement type "foot" and speed 1. |
| 07-12-2004, 12:42 AM | #3 |
That would be okay, except I need the room where "patrol" goes, unless there is a way to get rid of that... |
| 07-12-2004, 01:20 AM | #4 |
You can get rid of Patrol by getting rid of Move with triggers, but that will defeat your purpose because the unit will again be unable to turn to face targets. You can also create a pathing blocker at the location of the unit when it is built to prevent it from moving. I do not know if making the unit an Ancient will work, but I haven't encountered anything except spell targets that otherwise makes it useful to use the Ancient classification. Perhaps. |
| 07-12-2004, 05:42 AM | #5 |
It looks like the Ancient classification does keep it from crashing. How quaint. However, the unit will start rooted, and there seems to some difficulty in making it re-root. That probably has to do with some aspect of pathing or structure placement, but I don't know precisely what. However, for your purposes, I don't think that it's necessary to worry about it. |
| 07-12-2004, 06:45 AM | #6 |
I performed yet more experiments. If your unit has a movement speed of 0.00, it will still crash the game if it has Root, even if it's an Ancient. Furthermore, and more importantly, it doesn't seem to be able to turn to face attackers, even with Root. I'm not entirely sure why not, but I'm sorry, it doesn't look like this solution is going to work. On the other hand, I know for a fact that placing pathing blockers on their location will prevent them from being able to move, even though they can still turn. However, they will have all the standard command-card buttons that movable units have. |
| 07-12-2004, 01:47 PM | #7 |
Ancients models have a separate bone for the rotating torso. That allows them to spin around. You could always remove the Hold Position button instead (thats possible right?)... |
| 07-12-2004, 04:41 PM | #8 |
For most Ancients, what you have said is true, th15, however, the Ancient Protector moves the entire model. Other structures with Root can rotate all they want. It does occur to me, however, that I may have been using Root (Ancients) instead of Root (Ancient Protector), and that the difference between the two abilities might be that one allows rotation and the other does not. Investigation commences. |
| 07-12-2004, 07:09 PM | #9 |
Unfortunately, Root (Ancient Protector) does allow the unit to turn, but as far as I can tell, it only turns the unit from wherever it's facing to the default facing degrees, and doesn't turn to attack units. Also, when using Root (Ancient Protector), the unit stops using Attack 1 and uses Attack 2, for reference. I'm going to see if a trigger that manually turns the building to the thing that it is attacking will work. EDIT: Okay, enough new posts for me in this thread. I don't think anyone's reading it anyway. Since the Root (Ancient Protector) allows the unit to change facing but doesn't actually change it, I put together a trigger that changes the facing of the tower as it attacks, and it seems to work greatly. Here's the jass: Code:
function Trig_Grove_Dweller_Facing_angle_Conditions takes nothing returns boolean
if (not(GetUnitTypeId(GetAttacker()) == 'ubsp')) then
return false
endif
return true
endfunction
function Trig_Grove_Dweller_Facing_angle_Actions takes nothing returns nothing
local location locAttacked = GetUnitLoc(GetAttackedUnitBJ())
local location locAttacking = GetUnitLoc(GetAttacker())
call SetUnitFacing(GetAttacker(),AngleBetweenPoints(locAttacking, locAttacked))
call RemoveLocation(locAttacked)
call RemoveLocation(locAttacking)
set locAttacked = null
set locAttacking = null
endfunction
//===========================================================================
function InitTrig_Grove_Dweller_Facing_angle takes nothing returns nothing
set gg_trg_Grove_Dweller_Facing_angle = CreateTrigger( )
call TriggerRegisterAnyUnitEventBJ( gg_trg_Grove_Dweller_Facing_angle, EVENT_PLAYER_UNIT_ATTACKED )
call TriggerAddCondition( gg_trg_Grove_Dweller_Facing_angle, Condition( function Trig_Grove_Dweller_Facing_angle_Conditions ) )
call TriggerAddAction( gg_trg_Grove_Dweller_Facing_angle, function Trig_Grove_Dweller_Facing_angle_Actions )
endfunctionCode:
Grove Dweller Facing angle GUI
Events
Unit - A unit Is attacked
Conditions
(Unit-type of (Attacking unit)) Equal to Hero Tower
Actions
Custom script: local location udg_locDummy
Set locDummy = (Position of (Attacked unit))
Unit - Make (Attacking unit) face locDummy over 0.00 seconds
Custom script: call RemoveLocation(udg_locDummy)
Custom script: set udg_locDummy = null |
| 07-12-2004, 08:23 PM | #10 |
LOL, thanks for the testing, saved me a good chunck of time. I was wondering about doing a trigger on unit is attacked, but I thought it would fire after the unit was hit, and make it look funny. I am going to try this out and see what happens... there are a few things that may make this not work, I didn't state them before because they wouldn't have mattered, but I am going to test this out before I say more :) Edit: BTW, is it nessesary to set the temppoint to null? Doesn't removing it get rid of the mem leak? If so I have to go back and add that to all kinds of triggers :P |
| 07-12-2004, 08:46 PM | #11 |
There are two schools of thought. One says it's not necessary, and the other, which has many reputable jass ninjas in it, says that it is necessary for a perfect cleanup. I have no personal say in the matter, I simply decided to go with the other school, since another line of code at the end of a trigger doesn't terribly disturb me. |
| 07-12-2004, 08:57 PM | #12 |
Okay, it seems to work fine with my other triggers and the units settings :) Now... I don't know if anyone will see this that can help with it, but is there a way disable unrooting? In the end I will try to bump the icon off, but it would be nice to be able to just use the blank icon for it and stick it in an unused spot (yeah it looks funky with a blank tooltip, oh well) then I wouldn't have to worry about the order of icons and getting it to bump instead of the ability I want in 2,3. Eh that might read funny, but I think people will get what I mean. A trigger solution to this if fine as well... EDIT: Okay, I have the even, unit - issued order with no target... order = uproot now how would I stop the unit from uprooting? order unit to stop, does not stop it from uprooting |
| 07-12-2004, 09:14 PM | #13 |
Well, you can make a trigger that orders it to stop whenever it is ordered to unroot. Otherwise, if you have a "Sell" trigger, you can make it fire off of the unroot order and change the icon and tooltip to Sell. |
| 07-12-2004, 09:26 PM | #14 |
Sell would be nice... but I don't have selling on these, towers are preplaced (this is for my "The Gate" map) and ordering a unit to stop doesn't seem to keep the uproot from happening, and I can't set the duration of root/unroot to 0 and order a unit to reroot because it won't allow for rooting on an unbuildable surface :( Edit: Okay, I can add a buildable space if I need to but.... In order for the root command to work, a wait action is needed after unroot is issued. Even though it can be 0 wait, the move buttons appear and you can override the root action by just click one of the new buttons when they appear for a quick second... is there maybe a way to add a comman to the units que? then I could do it without a wait and hopefully you won't even see the buttons... but I don't think you can add to a comman que with triggers :( WOO HOO got it to work.... forgot to do a "pause" before I issued the stop order, it works now :) Thanks a lot Panto |
| 07-12-2004, 09:55 PM | #15 |
Sure, I'm glad it works for you. Working on this solved a similar issue for me, too. |