Jump to content

How About Some Real Beam Focusing?


  • You cannot reply to this topic
5 replies to this topic

#1 Sader325

    Member

  • PipPipPipPipPipPipPipPip
  • 1,181 posts

Posted 08 November 2015 - 02:04 PM

Let me be clear, I don't think the current pinpoint damage is a problem. However the beam focusing solution led me to an interesting idea.

The idea that your lasers do less damage when you aren't locked is pretty stupid, but I don't see any reason that the beams can't become more pinpoint while your target is locked.

Simply put, spread the area of damage on beams, make them have a cone that reduces over time while your target is locked with damage proportional to the area of the spread.

What does that mean?

Posted Image

So here's my idea, and I'll make it as simple as possible.

Lasers will initially fire in a cone, the damage of laser will be divided by the number of hits within that cone.

Shoot a mech in the armpit, and it'll probably do 50% damage to center torso, and 50% damage to the arm.

Lock the target and your laser becomes focused, returning to more "pinpoint" type damage. However the transition from spread to pinpoint is not instant. So your laser will decrease in size as you have target lock.

A IS large laser at 600 meters will do 9 points of damage at and underneath its optimal, but if its hitting two components at once, it will do 4.5 points of damage to each component its hitting.

This is a rough idea, so feel free to leave comments on how it could be improved and flesh it out.

#2 Kyrs

    Member

  • PipPipPipPipPip
  • The Nimble
  • The Nimble
  • 176 posts

Posted 08 November 2015 - 02:57 PM

So it basically a micro- reticle screen shake ?

#3 Omi_

    Member

  • PipPipPipPipPipPip
  • The Blade
  • 336 posts
  • LocationWinnipeg, Manitoba, Canada

Posted 08 November 2015 - 06:01 PM

The major issue here is that if you calculate damage as the proportion of surface area of the beam on each critical component, then you're introducing a crap ton of calculations on the server. I'll explain:

You're now having to...

(perform a frustum cast, which is much more expensive than a raycast)
x (total number of lasers being fired simultaneously during a given frame)
x (some work to determine which hitboxes are hit or are close to being hit by those lasers)
----------------------------------------------------------------------------
= to get the final work required every single frame.

As a second matter, have you ever shot at a roaming Firestarter and not had your fire register? That's because the server can't know exactly what your commands to steer your mech and spin your torso are until at least half your ping's time into the future after you actually entered those inputs. That's a pretty wide window where the server's simulation of the game can differ from yours, and those two simulations are effectively out of phase by a little bit all the time.

Take a look here for a little demo on how this actually looks:
To get a good idea, enter Lag = 100, prediction and reconciliation both on, server updates 30 times per second (MWO servers are probably honestly a bit lower than this).
http://www.gabrielga...m/fpm_live.html

PGI often talks about HSR (Host State Rewind) as an aid to improving hit detection. What it does is rebuild the current game simulation in the past according to exactly how it believes you the player should have viewed the world anytime your client reports that you've fired at and hit your target. If it can confirm your "head shot" according to your supposed view, it takes it at face value and updates the server simulation to include this "head shot" within the original simulation, even if originally the server saw your opponent duck marginally behind a wall in time. Your opponent might have even escaped from your sights on their screen, but the server accepts your version of events as good enough.

The amount of work required to produce your surface-area laser would wreck HSR, preventing that system from correcting hits from lasers.

Lasers currently either hit or do not hit. If they do hit, the range at which the hit occurred is made available by very the nature of how raycasts work. They're very simple to do (consider that machine-guns create raycasts for every bullet, or think of some other FPS with rifles or whatever). I imagine one laser as you described might be more intense on the server hardware than 24 FS9-As in a game today.

TL;DR: Server workload for calculating damage not feasible. Game would feel unresponsive.

------

Before the laser-lock mechanic got scrapped, I had imagined a visual effect like this to show whether your lasers were firing with enhanced range or not. I like the idea behind the visual, as long as damage isn't part of the suggestion.

Technically speaking, the cheapest way to make a 3D laser would be to render it as a coloured pyramid, with one vertex on the weapon's firing point and a triangle face drawn on whatever is being hit. It also couldn't shine through crevices between components like a flashlight except on very high-end rigs, and you couldn't expect all players to see the same thing.

TL;DR #2: I still like the visual effect! I think it would have been a great way to show when your lasers were firing at optimal range in the current PTS #3.

#4 Greyhart

    Member

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

Posted 09 November 2015 - 04:59 AM

If we were to riff on this idea. And assuming that we want to keep some benefit to having a lock over blind firing, but we don't want to nerf damage or range or create a lot of math.

Lasers are a Damage over time weapon. So how about if you have not locked the rate of damage at the start of the burn is very low (due to the beam focusing) and then it increases so it does the same damage in total. If however you are locked then the damage is applied evenly.

This way a person firing on an unlocked target has to hold the enemy in its sights for then entire burn and this allows the opponent time to torso twist and put most of the damage where he wants.

#5 Jack Shayu Walker

    Member

  • PipPipPipPipPipPipPipPip
  • The God
  • The God
  • 1,451 posts

Posted 09 November 2015 - 07:46 AM

lock for damage mechanics have been canned by PGI. Personally, with their targeting algorythm, I'd like not to revisit them.

#6 Greyhart

    Member

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

Posted 09 November 2015 - 08:30 AM

not lock mechanics but the current idea of reduced damage and reduced range.

I think there is merit in the idea of lock effecting something.

Of course technical problems with the targeting algorithm are a relevant concern.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users