Exedore's Highlighting code thread

(FireWorks) #1

[QUOTE=Exedore;358841]

A few people have announced this frustration; can I hear of more please (perhaps its own thread)? The focal point highlight code couldn’t change, but I need to put forth a value assessment for any functionality that further differentiates the platform codebases because it means increased maintenance on our end.

I’m certainly willing to make the case, but I’m ultimately not the one to do the work.[/QUOTE]

So Ill take the bait and open a new discussion on this. I think this is general talk so I will not limit it to a platform, but I ask every poster to state his platform while commenting to avoid confusion.

My thoughts on this…
I assume that theres a timer function in this highlighting code. The time for acquiring a target to buff and it is just too high, at least thats my perception and what I hear out of the comments.

Cant this time be reduced to zero (point at your target to buff/revive) or with a very short error margine code (.1 sec)?

If we cant rework the code for priority of targets like command posts, low health guys and incapacitated, I dont think we need to rework it at all. With this target acquiring time near zero, you always buff what you want (at the time you press the button and being in range).

Why I believe its only this timer? I saw a video with a certain Jolly playing in a very fancy HUD. The target acquisition animation was very sophisticated and took its time. While the animation was kill in release, the time it takes was not! and this is what feels like lag now.

It wont make everything perfect but will significantly work better… I hope…
Hope thats a starting point for a discussion :slight_smile:

While PCs should go easily with 0.0secs. Maybe consoles would take a little more of error margine time for the controller (0.1or0.2 secs)

(Smoochy) #2

it often doesnt lock for ages. seems worse with the last patch but one. (i.e. patch before the recent one)

the F button seems to be the biggest gripe these days

(dazman76) #3

A description of a few scenarios I’ve seen. Bear in mind, that this is a difficult one to “prove” as a culprit - I definitely do think the highlighting is falling over, but since testing for a lag at an instant’s notice is pretty difficult, lag is always going to be a possible contributor to the problem in general.

(I mostly playe(ed) a medic - hence these comments/suggestions are medic-centric, but certainly not limited to that class).

So…

b Delayed (or denied) highlighting[/b]

It sometimes feels like the targeting doesn’t connect at all, even when a player is front and centre in your view. Obviously this can happen when you have no relevant buffs/abilities for the given player - I assume this is part of the rationale for highlighting? This however, is easy to test at the very beginning of the match - because all players are eligible for buffs at that point, and therefore should be valid targets.

b Delayed target switching (probably a sub-product of (1))[/b]

It also seems that sometimes, when a player is already highlighted and you really need to switch to another, this doesn’t happen in a timely fashion. It feels like you’re fully locked/focused on target A, when you’ve actually manipulated your position/view in order to be closer to, and focussing on, player B. Again, lag could always play a part in this - but I do believe something isn’t quite right. Maybe too heavy an emphasis on keeping hold of a focus that has been acquired?

b Focus on objects not even in view, over objects front and centre[/b]

This is a regular one, but may be due to the fact that (a) you’ve prioritised command posts too highly or (b) distance is more important than view relevance. When attempting to revive or buff a team mate, when a command post is nearby but not in view (behind), the game will often interact with the command post instead of buffing/reviving the player - even thought they are highlighted at the time the key was pressed.

Suggestions

As FireWorks noted, any time implication with this highlighting should be drastically reduced for PC. We can turn our view so quickly, we really shouldn’t be “glued” to a current target as if auto-aim is present. While cracking along @ 60fps+ and being able to rapidly change our view focus, the highlighting code speed should allow us to use this properly - i.e., if we point at another player, the focus should immediately change to them.

This would drastically improve medic playability. I was tempted to suggest prioritising revive above all else, but I don’t think that’s a good idea after thinking it through. Better to simply say that the prioritisation and “cone of focussing” need to be tightened - trust the players to be slightly more precise with their aiming to highlight players, and allow them to quickly change that highlighted when required.

Quick suggestion regarding the one-key situation

I honestly think a solution for this problem can be found without TOO much hassle. I know eveything means work for SD, but I’m thinking reduction of work here. As I mentioned in the other thread, allowing OPTIONAL 3 binds for abilities shouldn’t impact the focus/highlight code. Taking the suggestions above regarding focus switching and speed, it should be a case of pressing one of the binds, and simply checking if the action is relevant with the current target.

Press REVIVE when live player focused - NO effect (a message if required)
Press REVIVE when command post focused - NO effect (same with the message)
Press REVIVE when downed player focused - REVIVE

This (in my mind) is simple to achieve, and really doesn’t wander much from the current system. I’m certainly NOT suggesting that these separate binds should come with extra logic that feeds back into the highlighting system. I’m also not suggesting it’s a perfect solution - but it would really improve things for medics at the least. Sure, sometimes I’ll be hitting revive just a bit too late after I’ve switched to a closer player who’s still up and running, but with the above changes I quickly snap back to my revive target, hit revive again, and Robert’s your Father’s Brother™ :slight_smile:

(Inofor) #4

It would be a good solution to remove the interface lag and have different binds for different actions. Using a single button actually works worse in this case. With the current F system, different actions are constantly confused when there is a lot of F-action objects such as players/corpses/satchels/a command post around.

(Smoochy) #5

just make it immediate OR let medics throw syringes. thats a quick fix. why do we need to lock? it often does the most random and stupid thing, and in the case of medic, you can easily use your past pip to try and revive yet it turns around and buffs someone.

of course give people the option but medic seems to suffer more as they have to inject where every other class just throws.

also, as a medic i like to buff specific classes on the start of a game. for instance on CC you want to give speed buff and health buff to all soldiers. with this system its almost impossible to do it. if you press F it should lock on and instantly buff the highlighted person. now it just seems to do its own thing

for me this is the most important issue in brink and can cause you to lose games.

(coolstory) #6

What I hate is waiting for the thing to lock on to a target before I can do anything…or if someone’s in-capped near the CP and if I try to throw a syringe quickly I usually get stuck using the CP :S

Having the option to bind actions to separate keys would be awesome…

(Apoc) #7

Its especially bad for comp, where everyone dies alot quicker, meaning you dont have time to mess around trying to get the revive prompt to come up.

The way it should work is; a medic runs into a room, throws revive to his downed allies, then starts shooting the enemy in the room, that way covering his teammate while he is reviving and vulnerable, and also ensuring that he has not just given away the room on the chances of winning a random one on one (as he has backup even if he dies).

However, what actually happens is: a medic runs into a room, trys to revive teamate, but the indicator doesnt show up for the first 2 seconds as hes at the wrong angle, he moves around trying to get the revive prompt and eventually gets the revive thrown, however at this point the enemy has been shooting at him for well over 2 seconds, the medic dies quickly, then the person getting revived gets gibbed before they can get up.

So what has started happening is, if a medic runs into a room…he has to kill everyone first then revive. I dont know if this is how you intended it. But its not very efficient and smooth and isnt suited to comp.
This thread describes the issue clearer and provides a suggested solution, as well as 3 pages of supportive comments.

(Kendle) #8

For me the biggest issue is the key bind situation. I want the game to do what I ask it to do, not try and guess and sometimes guess wrong. If the 3 functions had 3 keys there would never, ever, be any doubt. If I’m looking at a buff-able team-mate and press revivie nothing happens because I told the game I wanted to revive etc.

The highlighting issue is secondary, although still relevant. On PC, as explained above, we can move our mouse faster than the game can (re-)acquire targets, thereby leading to delays that get you killed, or with the current one key situation lead to un-intended actions being performed and / or those actions being performed on un-intended targets.

3 separate keys for 3 separate functions + faster (instant?) lock-on.

(Stormchild) #9

Differentiating uses for the F button would also mean several parallel targeting code. So at one moment you can have 1 ‘selected’ friend, for using buffs & co, and 1 ‘selected’ corpse/incap maybe, and 1 ‘selected’ CP. So if all are at the same position, you can use different keys to specify interaction target but that means 3 times the selection algorythm running.
Might have consequences performance-wise (especially when all are cluttered at the same place, like a battle around a CP with friends, incaps, foes, CPs…).

Otherwise, the targeting can stay as one, but more reactive and precise so it really takes in account where your crosshair points. Not very pad-friendly I’m afraid. Could be a “stick target” selection margin adjustable depending on platforms, so at least on PC with the quicker mouse precise targeting you can afford a precise highlight/selection.

Then, difference between selection in the game mechanics and the highlighting drawing. If the targeting waits for the highlighting to be drawn, in order to be useable for interaction, then it’s a problem maybe. Should be deactivable so fast PC player just mouse point on the element to interact with, and can execute action instantly without waiting for a fancy highlighting, useless once they know the gameplay mechanics well enough. Or a simplified highlight based on the cursor graphic itself and not on the world 3D model.

(Humate) #10

So what has started happening is, if a medic runs into a room…he has to kill everyone first then revive.

Thats how I did it in etqw.
Brink on the other hand is terrible for that approach though. : /

(Exedore) #11

One thing I need to establish, are the 3 central issues that dazman76 has mentioned as prevalent if you run a local match solo?

(FireWorks) #12

What I have understood so far from the developer side is that they dont have the ressources at the moment for a large new coding action that splitting would be.

I think a quick workaround for the moment would be this quicker lock on.

(Dormamu) #13

Not gone happen!
The amount of work/time/money is huge for this to be implemented. So i say Ney!
Cut your loses, grab your balls and say: At this point is impossible to do this.
And focus on the next project. You have ET,ETQW, Brink you should know by now what PC, Xbox360 and PS3 want, put it on a list and glue it to your front dour, so you never forget.

As a workaround to your current problem and knowing that the multiple key is out of the question i propose to look at this from another point of view:
What if you could give to every class a grenade to do the job, the grenade will not auto-focus, where you trow it, it will go, so:

  • give another Lazarus grenade to the medic, make it with a small AOE (to be used for 1 player area), make it with a heavy mass (to counter the bounce, and to be throne from a short distance).
  • give a repair grenade to the engy to repair the CP, walls, etc. You can give him another one to buff teammates.
  • Give a dynamite stick to the Soldier to blow up stuff.
  • and so on.
    Make it a free DLC, please the masses and focus on the other problems. Or you can say it’s for the promod (hardcore mode) on Brink, or for the Competitive game play.

PS: I see it as a workaround and not a fix. The fix will be available in Brink 2 (remember the list glued to your front dour and me for beta testing) :smiley:

(DarkangelUK) #14

[QUOTE=Humate;358971]Thats how I did it in etqw.
Brink on the other hand is terrible for that approach though. : /[/QUOTE]

Yeah was gonna say, that was fine in ETQW when the lower spread meant you could take 3+ enemies out with 1 clip (normal clip, there are no extended mags in ETQW for those that don’t know).

(dazman76) #15

Good thinking that man, I should have thought of that really :slight_smile: That’ll will be why you do this as a job, and I just lurk on forums all day causing trouble.

I have limited time available in the evenings this week, but I’ll try to have a few local matches and see what happens.

It’d be great if others reading this thread could also try this, and report back here. If it moves us any closer to understanding the problem and potentially having a fix, I think it’s worth an hour or two of testing :slight_smile:

(Seiniyta) #16

I’ll check this out now :slight_smile:

edit: to me it feels quicker, but I can’t really tell, what I do notice is the annoying “guy needs reviving” and you turn around to buff someone who was behind you and wasn’t buffed. I would change the priority from buffing to reviving.

(Apoc) #17

Yes all issues seem to be non internet depenant, as its just as bad offline. The problem as dazman said is that its prioritising things (feels most likely by distance, not where your looking) as even in offline, you can target someone to give a buff to directly infront of you, but it will grab you and make you go to cp if thats nearer (also seems to prioritise).

Also the revive and buff thing, as they are equally prioritised, people buff instead of revive unreasonably often. If there are 3 people round an objective, and one soldier trying to plant goes down, you pretty much have to buff everyone around you before you can revive the soldier.
I think you should definately highly prioritise revives over buffs for medics, like revives as high a priority as possible and buffs as low as possible…i mean id much rather a medic accidentally revives someone instead of buffing someone already alive, than the other way round.

(Stormchild) #18

If priority is based on distance only, it is indeed a problem but I would be surprised if it was the case.
Priority based on a cone/circle around the crosshair would be more logical (maybe it is a mix of both actually, except that the distance weights too much compared to direction of looking ?).
The % of model visible in the cone/circle around the crosshair could play a role too. In case you have several possible targets in your targeting cone / crosshair (it will happen), differentiating them based on distance (always within a targeting distance limit based on abilities, ie detonate C4 has bigger targeting range than revive), or differentiating them by % of model or a combination, oculd be a key. But avoiding too much computation is also key.

(FireWorks) #19

Every start of a round where you start as last and keep F pressed, you end up running after first guy in line. You really aim through a whole spawnwave to the guy most far away.

(BMXer) #20

Ive personally made it a point to not buff anyone for a few moments just as we spawn. 9 times out of 10 if I try to buff right away, it pulls me to the closest CP. Its especially bad on Aquarium offensive.

Touching the F key anywhere near a CP mean you get latched to the CP. It makes no difference what you are trying to buff or what direction you are facing, the CP is a tractor beam!