Jump to content

Alternative To "laser Lock" Requirement Pts Rebalance


7 replies to this topic

#1 SilentScreamer

    Member

  • PipPipPipPipPipPipPip
  • FP Veteran - Beta 1
  • FP Veteran - Beta 1
  • 556 posts

Posted 16 October 2015 - 01:21 PM

Okay, I am seeing lots of posts regarding implementing "cone of fire" mechanics in the current PTS threads. Please continue the discussion here.

Are laser alphas a problem PGI should deal with? I think yes. If your opinion is no, the following question won't really apply.

What is the best course of action to fix the problem?

A ) More Ghost Heat penalties?
B ) Cone of Fire mechanics?
C ) damage spread for lasers ( currently used on clan er ppc )?
D ) lock required for full laser damage ( currently on PTS )

Suggest something else if you have an idea to share.

Edited by SilentScreamer, 16 October 2015 - 04:37 PM.


#2 Livaria

    Member

  • PipPipPipPipPipPip
  • Moderate Giver
  • 405 posts

Posted 18 October 2015 - 10:06 PM

I am undecided, It's really hard topic to respond with a definitive answer because lasers are vital for many 'mechs. I may be one of the few that sees potential in the laser lock method. However, It may need to be altered and refined first.

in my opinion, some mechs *need* to hit and run from a distance in order to be effective. At least it can be overcome if there is a target lock which shouldn't be too hard to perform. It really comes down to number results to decide how often and how much it affects the game. After that, it's a matter of knowing whether or not it enhances gameplay experience.

Edited by Livaria, 18 October 2015 - 10:10 PM.


#3 Wibbledtodeath

    Member

  • PipPipPipPipPip
  • 169 posts

Posted 19 October 2015 - 01:35 AM

a)- no, Ghost heat is a problem worse than its solution.
b )- Cone of fire works ok in games with 1 weapon firing rapidly. It would look very derpy with an alpha of lots of weapons crossing fire all over the place. (Recall the clan LB2x issues). Infinite vs targeted convergence would be similar but better/more predictable and have = effect regardless of range
c) Duration does spread laser damage already and my answer to B would enhance this somewhat
d) Spread damage reduces its effectiveness without changing the numbers- again predictability is of value. We have just got hitreg working ok- now they are implementing variable hitreg with lasers! no thanks- not when better options are available.

Edited by Wibbledtodeath, 19 October 2015 - 01:36 AM.


#4 Ialdabaoth

    Member

  • PipPipPipPipPipPip
  • Bridesmaid
  • Bridesmaid
  • 329 posts

Posted 20 October 2015 - 02:42 AM

E) No convergence unless you lock a target (even if it takes some netcode refactoring)

#5 Makenzie71

    Member

  • PipPipPipPipPipPipPip
  • Big Daddy
  • Big Daddy
  • 938 posts
  • Location"I don't like your loadout...you must have no idea what you're doing." ~This forum

Posted 20 October 2015 - 03:41 AM

View PostIaldabaoth, on 20 October 2015 - 02:42 AM, said:

E) No convergence unless you lock a target (even if it takes some netcode refactoring)


That would affect every weapon...not just lasers. And then, once people adjusted to the mechanic, there would be no change.

Not that I understand why anyone thinks it should change...

^That's the say I would love to have someone explain to me why it needs to change.

Edited by Makenzie71, 20 October 2015 - 04:12 AM.


#6 Greyhart

    Member

  • PipPipPipPipPipPipPip
  • Bad Company
  • Bad Company
  • 894 posts
  • LocationUK

Posted 20 October 2015 - 04:49 AM

The problem as I understand it is that it is possible to deposit a large amount of damage on a single part very easily.

This is known as pinpoint damage.

Lasers are the best at this as there is no travel time so it is point at a single part and fire all lasers to do all the damage to a single part. So it is point and click.

what is also a problem is that lasers have no ammo so firing them (as long as you have time to cool down) has no down side. people therefore find the longest ranged lasers and shoot at where they think an enemy might be, if the crosshairs flash red they know they've hit even if they can't see anything.

So you reach the silly conclusion that the best strategy is to boat a lot of long range lasers and stand at the back squinting at the screen to see if you can notice a pixel change and then firing on where you think a mech might be.

#7 Shae Starfyre

    Member

  • PipPipPipPipPipPipPipPip
  • The Widow Maker
  • The Widow Maker
  • 1,429 posts
  • LocationThe Fringe

Posted 20 October 2015 - 07:52 AM

I think the real issue is bandwidth and base code; Ghost Mechanics are the only way things can get programmed to any simulated resemblance of what a vast majority wants without breaking this down to a one-on-one game.

Remember, because of all the points of reference for computations, each Mech is like having between 6-10 single hit box 'toons.

These computations range from size, position, weapon output and location, armor sections, critical slots, and so on, that if all the suggestions were ever put in to play just the way we want it, we couldn't have 12-on-12 matches with the current game engine.

This basic understanding is missed by a vast majority of people on this forum.

We settle for some factual and manageable and understandable mechanics and leave the rest to 'Ghost' mechanics; not to mention there are more changes coming, more added points of reference down the road.

There is just so much that can be done; so many calls that are capable.

This is not a top-down 3rd person game; it is not a single hit box (hit point pool), one gun avatar game; it is a complex (already) monstrosity of calculations between 24 players that not even HSR is capable of allowing an SRM 6 to be reliable.

#8 Ialdabaoth

    Member

  • PipPipPipPipPipPip
  • Bridesmaid
  • Bridesmaid
  • 329 posts

Posted 23 October 2015 - 12:03 PM

I can't imagine how the net code doesn't allow adjustable convergence. When a group of weapons is fired, the client needs to tell the server:

1. The timestamp of when the fire button was pressed
2. The point being aimed from (where the mech is on the battlefield)
3. The point being aimed at (where the shots should converge to)
4. the list of weapons being fired (at minimum this can just be a weapon group number or an individual weapon number)

If currently (3) is replaced with a direction vector, and the server calculates the point, that doesn't change a thing. In either case, at step 3, either the client or the server calculates the convergence point - if the client calculates it, then the server needs to verify it.

Since lasers now have a changed mechanic, it's obvious that a new piece of information is being sent:

5. Which target is locked (if any).

Since the server has all this information, it can easily adjust the convergence at step 3 to be a point 2 km out, instead of the first hitscan collision out from the client mech's firing vector. Or, if the client has locked a target, then adjust the convergence at step 3 to be a point as far forward as the target is (even if the target isn't directly under the reticle).

This is simple trigonometry, and does not require any unknown variables - all the information to do this is necessarily being sent to the server already, or the server couldn't calculate hits at all.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users