We are aware of the issue and are looking into it. Thanks for the report!
Showing Posts For Joel Helmich:
Regarding Phase Traversal, I just made a post about that on the revenant forums: here
This is a bug for sure, but unfortunately there isn’t a simple solution. For context, action camera intentionally does not auto select skill targets if they are out of range, which usually feels better for gameplay as most skills don’t work on out-of-range targets anyway. The exception cases were enemy-targeted shadowstep skills, such as Guardian sword 2, so I put in special logic to allow these skills to be used on a target when out of range, so long you aim at the target (though there is currently a bug with this when you have autotargeting off; see this post that I made over on the Thief forums). Specifically, the client knows whether or not to target the out-of-range enemy because the skill being used does preemptive path checking, where the skill is stopped early if no path to the target can be found.
The way Phase Traversal works is that it does a short dash and then a shadowstep toward the target, which is a pretty unusual thing. Because the majority of travel distance in the skill is from a shadowstep, it may make sense to flag this skill as needing a preemptive pathing check, so that you don’t waste it on unfavorable terrain; this would also immediately fix the described bug. However, at the same time, there is a non-zero component of travel that comes from the dash, so stopping the skill because of pathing might seem wrong in some cases. It is something that will have to be pondered.
Thanks for the reports.
There’s also a also problem with steal, it goes on full cooldown when you’re out of range and infiltrator’s strike does not work most of the time (to clarify, when you target someone, it conducts the skill as if you had no target so it’s just an awkward stationary infiltrator’s strike) even if you’re in line of sight.
I assume you are aware of this given your question, but just in case or for the sake of other folks, there are some hidden features of action camera. One of these allows you to use enemy-targeted shadowstep skills from outside of their range by aiming at the target (this and some other features are described in this thread). You won’t see a circle crosshair, just the X shape, but the skill will still target the enemy.
There is unfortunately a bug with this where the out-of-range allowance does not work if you have autotargeting turned off and are instead manually locking targets. I have a fix for this locally but can’t give an ETA on when it will go live.
Steal has some extra issues on top of this, regardless of action camera. It can be fired without a target, but goes on full cooldown if you do so. If fired on a target that is out of range, it goes on interrupt cooldown. These things come from content rather than code (roughly, design rather than programming), but I can ask around to see what’s up. It’s quite possible that there’s a legitimate reason I’m not aware of.
pointing the camera down does not shorten the Heartseeker’s leap, making it much more difficult to jump inside Black Powder multiple times.
The behavior you want is almost certainly a bug in the first place, so I’m not sure what to tell you.
My main gripe with action camera atm is not being able to aim at my feet. I wanna Vault Goomba Stomp in place lotta the times, especially when fighting bosses pve.
As vault is ground-targeted, if you are also using snap ground targeting, there is a secret interaction with action camera where if you aim the camera straight down, you will ground target right at your feet. This might get you what you want.
Normally: When you have a target selected and you are running away (facing away) and you use Shortbow 3 (disabling shot) your character performs an animation that is quickly turning and shooting back at your target but evades in the direction you were running (away from your target).
With Action Cam: When you lock a target (right click) and run away from your target and use shortbow 3… you just awekwardly shoot in front of you and evade backward toward your target.
There is actually a bug with the animation for shortbow 3 (also true for Ranger shortbow 3, which shares the same animation), and it shows up even without action camera, though in a different form. If you stand so that your target is pretty far off to the side, but not behind you, and you use skill 3, your character will jump straight back from their current facing direction, NOT away from the target as it supposedly should (also the arrow will fire sideways and look all janky). This happens because the animation is flagged so that the skill doesn’t try to aim you at the target; as far as I can tell the reasons for this are lost to history, but there it is all the same.
With action camera, specifically when you don’t have/are out of range of a target, things get extra funky. Because the skill isn’t allowed to change your facing, if you start running toward the camera and then use skill 3, you’ll jump away from the camera/toward your target, though usually only after you’ve previously used a skill. It’s all quite magical and clearly incorrect.
As far as I can tell this should be fixable, but as before I can’t give an ETA on when such a fix will be live.
On a note, “Reverse Withdraw” trick doesn’t work with action camera.
Since your character is on a permanent free camera state.
I’m assuming you mean using Withdraw as an advancing move? You may be able to get use out of the About Face keybind, which does now work with action camera (and regular right-mouse-held-down mouse look, too).
Alright, it looks like there are quite a few questions. Some of them have been answered already or are duplicates, but I’ll otherwise try to address ones that I have answers for.
So teleport skills which needed a target (like guard sword 2, steal, infiltrator signet, infiltrator strike) can be used currently even if the target is not in line of sight – it will teleport you to this target (which doesnt need to be in los). Will I be able to use those skills on locked targets without having them in the crosshair? Or how will it work?
Interesting question. If you have a target locked, it is considered a valid possible hover target (and thus is eligible for action camera targeting) even without line of sight. I didn’t actually know this until today, but you asked and I had to find out. Note that you will still need to aim mostly at the target, as with any targeting done under action camera.
So with auto targeting on the system is more generous in aiming. but what happens if there are for example 5 mobs really close together and all the “auto targeting hitboxes” are on top of each other, can you nevertheless get your specific target (out of those 5). Do you need to preemptive lock your target?
You might want to if you want to be certain what you’re firing at. One thing to know is that when you use a skill on a target, it will become your “skill target” and action camera will give it greater weighting than other targets (similar to locking the target but less permanent). However, if this isn’t enough of a guarantee for you, you’ll want to lock targets.
My main question is: Is it possible to rebind the actual number keys to other skill slots, including one. In other word, if I wanted to use 1, 2, 3 for my utilities, would that interfere with the left-click auto-attack?
It will not interfere. Left click explicitly fires skill 1 and is not reliant on the usual keybinding for skill 1 (i.e. the number 1 key).
Q: Right-clicking selects a target. Would right-clicking also deselect the current target? Sometimes I would be in combat and like to deselect targets, I could press escape but that stops other actions before actually de-selecting targets, and sometimes de-selecting is a top priority for me.
Q: Right-clicking makes the enemies hit-bot more generous. Would right-clicking another target while in this hit-box select that target instead?
Right click will lock the target if there is one under your crosshair and will clear your target if there is nothing under your crosshair. Also, regarding the second question, when deciding whether or not there is something under your crosshair for the purpose of locking/clearing a target, the extra selection weight that you get from having a locked target is ignored. I found that it was just too hard to clear or switch locked targets without this exception.
One question, does channeled skill such as Ranger Lb#2 rapid fire continue tracking stealthed enemies using the new camera?
Once the skill starts firing at a target, it will do whatever it does normally; whether or not action camera kicked it off isn’t relevant. With skill retargeting you can switch targets mid-skill, but the skill still acts as it normally would when firing at a target.
Will snap targetting follow through stealth in any situation? Such as putting a target on a profession that is likely to use stealth a lot?
No, when a target stealths your client no longer knows about their location. Accordingly there is no way it could know where to place the ground target marker.
I have a question regarding snap ground targetting and targets that are above you. For example, if I am aiming at enemies standing on their walls in a tower / keep in action camera with snap ground targetting on, will my AOE get cast on them? Or will it use the obstructed LOS rule you mentioned that is related to structures to place the AOE where the LOS failed?
Assuming the ground-targeted skill in question requires LoS in the first place, yes, it will be placed where LoS fails.
Is it possible to get a keybind for toggling autotargeting on and off? It will be especially useful when switching between classes that have a lot of movement skills (and attack without a target), and those that require a target for most skills; or even when doing different things on a single class.
The complexity of this depends on what the keybind will do. If it acts to simply toggle the state of the option for autotargeting (i.e. the state of the checkbox in the options menu), it would legitimately be pretty simple; however, I don’t believe we have precedent for a keybind like that, so it might be an argument waiting to happen. If it instead acts as an override for the usual option, all places in code that reference the state of the autotargeting option would need to be updated to also check for this toggle state, and we would need to be careful about when the override state is preserved vs cleared, etc. It is an on the table™ sort of thing but I can’t give any guarantees.
Will it be possible to customize the sensitivity of the hitbox of the crosshair to prevent something like when you struggle between the two deers?
If it’s the part of the stream I’m thinking of, I was actually trying to demonstrate how action camera prioritizes the target under your crosshair even if you’ve got a locked target behind you. However, the deer decided he didn’t want to cooperate and kept running in front of me, so I had to take drastic measures. It may be that you’re referring to another thing that happened though, where there was a lootable dead body of a deer in front of a living deer which I actually wanted to target, but the hover selection kept prioritizing the dead body. This was actually a bug that I’d just never noticed before then, because I usually just loot stuff without really thinking about it. I fixed it today on my development machine, though the fix will probably have to go in after launch given how close we are. It’s probably a pretty rare bug in practice anyway; people aren’t going to leave an unlooted body just sitting around.
To actually answer your question, making this sort of thing customizable isn’t planned unless there turns out to be a very wide variance in player preferences. Tweaking the current values is however always an option should it prove to be necessary.
What happens when you use snap ground targeting on a fish while standing on land.
Snap ground targeting attempts to find a point on the ground underneath the target, so it should find a spot on the sea floor, so long as that is within skill range.
What skills does it (skill retargeting) affect beside Rapid Fire? Are skills like ranger warhorn 4 affected?
It’s largely up to how the skill is implemented. You can usually switch targets before the first attack of the skill, and most multi-attack skills will let you switch targets between attacks. I hadn’t tried it before you asked, but ranger warhorn 4 appears to be an exception and doesn’t let you switch, at least not once the birdemic starts. I only tried it a couple of times so don’t take that as hard fact, though.
How will action targeting work along side the use of the “F” Key? Will it kick you out of action targeting allowing the use of the mouse to make selections as in dialogs with npc’s and then back into action targeting once one closes the dialog box?
If you aren’t using autolooting, meaning a little dialog will pop up whenever you loot something, action camera will automatically shut off when the dialog appears and automatically turn back on once the dialog is closed. This is the expected behavior for most dialogs.
Will action camera pip work with UI off?
As the crosshair is itself part of the UI system that gets shut off, no it will not.
Does the aoe-snap to target work on world boss targets as well?
It does.
If I’m auto-attacking the target (with 1 rather than LMB), I assume that the S key will backpedal rather than turn and run at full speed as it would if no skill is being cast. To disengage, do I have to hit esc to stop auto-attacking or can I turn the camera away and run forward key as per the traditional camera system?
Your assumption is correct, and if you turn and run the other direction the behavior should be the same as with the normal camera mode.
So it turns out I reaaaaaally should have brought a list of key items to talk about on the livestream, but at any rate there are some details about action camera and associated features that are worth clarifying. I’d also like to address some questions that I’ve seen get asked since yesterday.
When will this be available?
HoT launch, so… five and a half days or so from now.
Will these features be restricted to people who purchase HoT?
No, they will be available to everyone.
If I don’t want to use action camera, what should I do?
You should do nothing, since the toggle key isn’t bound by default and you can’t accidentally turn it on without that binding. The camera and controls will continue to work as they always have.
What do I do if I want to use action camera but I’m bad at aiming?
If you turned off autotargeting at some point in the past, you should turn it back on. Basically think of it as aim assist when you’re in action camera mode; you still have to point more or less at your target, but it doesn’t have to be super precise.
What specifically determines the state of the crosshair, and what do these states mean for skill use?
dot – nothing is going on; skills will fire at the crosshair
X – the thing under the crosshair could be a target but is out of range, or autotargeting is turned off; skills will fire at the crosshair
X+circle – the above, plus the target is within range of at least one skill on your bar; skills will fire at the target
X+circle (rotated) – the above, plus the target is within range of skill 1 (i.e. your left click); skills will fire at the target
What determines whether or not I run toward the camera at full speed?
When you are using a skill, and for a short period after the skill completes, your character will face in camera direction. Moving backwards will cause you to backpedal in this case. When not using skills at all, you will run at full speed in all directions. Generally, this should work out so that when you are actively attacking something, you will be facing toward it, and when you are repositioning without using any skills you will run normally. Practically speaking, your character needs to face in camera direction during skill use because it would look kind of dumb to fire arrows and things backwards. Many skills have checks in skill script to make sure that you’re not attacking something behind you, for this reason. It would be a problem if action camera caused this check to fail all the time, hence the described behavior.
Can I use snap ground targeting and skill retargeting without action camera?
Yes, these features work with or without action camera.
Can I use other target selection methods (tab, closest) while using action camera?
You sure can. Doing so will lock whatever target gets chosen, and as explained (hopefully) on stream, locked targets receive greater priority when deciding who skills will be used on.
Can I rebind left/right click?
I’ve seen this asked a bunch of times, and unfortunately the answer is no, not at this time. That is not to say there is a lack of desire to make it happen, but there are significant complicating factors. Left and right mouse buttons are treated as special snowflakes in our input system and throughout code, and changing that so that people can arbitrarily bind them to other actions was a can of worms I didn’t have time to open. Another consideration I had was to put some action-camera-specific binding selector for right mouse in the options menu; however, I decided pretty early on that I wouldn’t have any options specific to action camera in the options menu for this first release, other than the toggle keybind itself. Generally speaking, we don’t have options that themselves depend on other options, and I didn’t want to unnecessarily ruffle feathers. Anyway, custom rebinding is definitely not off the table™ but it won’t be natively supported for now.
Can you hold down left+right mouse button run forward while in action camera mode?
Yes.
I like having skill 1 autocast and don’t want to hold down the left mouse button all the time, but I still want to use action camera otherwise. What should I do?
While in action camera, both the regular hotkey for skill 1 and left mouse will fire skill 1. However, if you use the regular hotkey, it will also respect your autocast settings for the skill, and will keep using skill 1 so long as you continue to aim at the target. Left click ignores autocast settings because it is intended to be more of a precise action, with a deliberate start and end.
I’m using snap ground targeting and sometimes I want to target AoEs at my feet, but I’m too lazy to be bothered with the snap ground target toggle key. What should I do?
There is a secret feature of snap ground targeting that is available only when you are also using action camera. If you aim the camera so that it’s pointing as close to straight down as it will go, the ground target marker will snap to your character’s feet, rather than being placed at either the crosshair or at your target’s feet if you have a target. This issue came up as an annoyance during alpha testing and the aforementioned behavior was the best compromise that happened at the time.
I’m using snap ground targeting and sometimes I want to target AoEs on an ally, but I’m too lazy to be bothered with the snap ground target toggle key. What should I do?
Snap ground targeting will work for allied targets, but ONLY if you lock them as your target first. If your are using action camera, you also must be aiming mostly at the ally for the snap to happen. Allied targets picked up by autotargeting intentionally do not get the snapping behavior.
Does snap ground targeting work on structures too?
It does, though this presented an interesting problem. Many ground-targeted skills do a line-of-sight check to their target point, and many structures obstruct line of sight. As a result, putting the ground target marker at the base of the structure would cause LoS to be obstructed every time, which would be sorrow. Because of this, snap ground targeting has special behavior where it will put the target marker at the point where the LoS check failed (should it fail), typically resulting in it being placed on the surface of the structure.
I’m using snap ground targeting, but I really don’t want to Blink right on top of an enemy, and I’m too lazy to use the toggle key. Am I doomed?
Skills which do a preemptive path check (typically shadowstep skills, such as Blink) are exempt from snap ground targeting and will always cast under your crosshair/mouse cursor.
There are a few targeted shadowstep skills in the game, such as Guardian sword 2, that can be used from outside of skill range to shadowstep you in the direciton of the target. Won’t this behavior no longer function with action camera?
Probably nobody was asking this until now, but it’s worth knowing all the same. This small set of skills (I think there are four of them total?) gets a special exception to the usual crosshair rules. So long as the target is under your crosshair (so it’s in the X state), these skills will activate on that target, rather than try to fire at the crosshair with no target.
I have a different question about one of the new camera and control features.
This thread is a great place to ask!
(edited by Moderator)
Since this has come back onto public radar recently, I’d like to take some time to better inform people about what’s what about the “no valid path to target” error and shadowsteps in general.
-Why was “no valid path to target” added as a mechanic?
The quick answer is that it wasn’t, contrary to popular belief. A message informing players about it was added, but shadowsteps failing because of an invalid path has been a thing since game launch. Read on to learn more about what is actually going on behind the scenes when this error message appears.
-What is a shadowstep?
A shadowstep is a teleport with validation on its destination point. This validation is only there to prevent exploits and has no other lore reasoning or whatnot.
As an aside, despite what skill text may claim , most “teleports” are actually shadowsteps. An actual teleport, such as what happens when you use a mesmer portal, does no validation.
-How does validation work?
Pathfinding is performed between your current position and the target point, using the same mechanism that AI uses for navigating. Specifically, this uses “navmesh”, which is derived from collision data (terrain, objects, etc that you can run into). Navmesh is automatically generated and represents the places where it is “safe” for NPCs to walk. Essentially, more complicated pathing tasks (“will I fit between these two rocks?” and so forth) are precalculated so that finding paths for NPCs on the fly doesn’t cost too much.
Speaking practically, shadowsteps make use of the navmesh for validation because it is the most reliable option that isn’t absurdly expensive. Still, it is the case that generated navmesh sometimes leads to results which can seem surprising. For example, you can get a valid path from the ground to the rooftop of the Kyhlo tower because of a walkway that wraps around the building, but can’t find one from the ground to an elevated rock because the sides of the rock are too steep. This apparent discrepancy is unfortunate but an inevitability of how the system works.
-When does this validation happen?
Some skills which will perform a shadowstep are flagged as needing to perform a path check on cast. When the client asks to activate such a skill, the server will do pathfinding to the target point first, before any activation costs are paid. Should pathfinding fail, the skill will be canceled and the “no valid path” error message will be sent to the client.
Additionally, for all skills which shadowstep (not just those that are flagged), this same validation will occur when the shadowstep action itself fires. The purpose of this validation is to stop exploits, whereas the previous check (if there was one) is only there to minimize player grief. It is important to note that, as shadowstep actions are driven by skill scripts, this later validation will happen after skill activation costs are paid.
Generally, for skills which preemptively path check, the second check should only fail for non-instant skills, and only when the delay between checks allows you to move from a valid position to an invalid position. Thief shortbow 5 in particular is the key offender here, given that the skill is used often and the missile has flight time.
As mentioned, not all skills which shadowstep will perform the preemptive pathing check, and there is some reasoning for why this happens or doesn’t happen. Broadly, skills which the user directly activates to perform a shadowstep, such as Blink, will do a path check first. It is expected that players would prefer to keep such a skill off cooldown if it’s going to fail anyway. Flipover skills, such as Shadow Return, do not path check first. Players may want to clear out the flipover skill right away, which would be hard to do if pathing kept failing.
Also, for skills with preemptive path checking, if you attempt to use such a skill which also happens to be a stun break while you are stunned/knocked down/etc, it will fire regardless of pathing success.
-Why does my shadowstep give me a path error now when it used to work from this same spot?
To help answer this, you should first know that there is fallback behavior for shadowsteps which uses what’s called “straight-line” pathing, should normal pathfinding fail. Basically, the pathfinding engine will go in the direction of the target point until it hits anything and then will stop immediately, so you end up with a really simple path that has just two points. Because of the easy failure condition, this is quite unreliable, as the path may go decently far or just a few inches, depending on what the navmesh looks like.
The straight-line pathing fallback was used by all shadowsteps before preemptive path checking was introduced. As a result, there were certainly times when you would fire your shadowstep and, despite not quite reaching your target point, still move some reasonable distance. However, this fallback behavior was as likely as not to move you a very short distance, and still at full skill cost of course.
Skills which preemptively path check will no longer do this fallback behavior, as pathing would pretty much always succeed, defeating the purpose of checking ahead of time (technically speaking, straight-line pathing almost never fails).
-Why doesn’t the shadowstep ground target marker go red when pathing will fail?
I’ve seen this suggestion come up a few times, and this is actually how preemptive path checking was originally intended to work. Unfortunately, navmesh data is not included on the client, and as such the only way to get the necessary information to color the ground target marker would be to continually poll the server. Having the server respond to client polls and do a bunch of pathing calculations on demand would be too expensive and too vulnerable to lag to be considered a good solution. Also consider that one of our ground targeting options, instant ground targeting, would have no marker to color in the first place.
The best compromise was, as mentioned, to flag skills which will perform shadowsteps as needing to do a path check on cast, and to have those skills stop early before costs are paid. This way players are at least not punished for the state of the navmesh, which they cannot see.
-Are any changes planned for shadowstep behavior?
As mentioned earlier, for skills which do a preemptive pathing check, there is a second validation which happens when the skill actually executes, and this second check can fail if you manage to move to an invalid spot in between the two. The first check will not allow a straight-line path fallback, as that would defeat the purpose of checking for a valid path ahead of time. However, currently if the first check happens, the second check also will not allow a straight-line path fallback. This means that if the first check passes but the second fails, skill costs will be paid but no shadowstep of any kind will occur. This is a bug and was never intended, and so is being fixed for Heart of Thorns release. The reasoning is that since costs have been paid, even a small shadowstep in the target direction is better than nothing at all.