56 replies to this topic

[Oni Ralas]

Ranek Blackstone, on 26 October 2013 - 11:01 AM, said:

Not true. The radius is so small because lighter mechs are more compact. The old 2m radius is roughly the distance from a spider's feet to its knees, so a whole lot of armor would get caught In the blast, so an SSRM to the arm would have the CT caught in the blast radius as well, and deal some minor damage there as well. So they nerfed the explosion radius on missiles so that lights would take the damage they were supposed to from them.

Problem is, lights *don't* take the damage from them correctly. Even at 10cm (Dev), a light takes little to no damage - while in motion - from a missile group. The extremely small - yet instant - blast only scratches the mech (if it even registers as a hit). So coverage aside, we're back to one of two possibilities:

1) Hit registration is not functional 100% on high speed mechs
2) Impact calculations are still wrong in some fashion

It's really easy to test on a live match, impossible in testing grounds. It would also be very helpful to have logging available...but that isn't on deck right now.

[Kitane]

Not just lights, anything that goes faster than 80km/h has a noticeable resistance to LRMs. There's no way I should fire 160 missiles at Dragon at 400m only to watch all four volleys do about 6-7% damage total.

It was like this since I've started to play last year. The missile damage always started to drop when firing at faster heavies, mediums were taking low damage and light mechs were just scratched. Anything stupid enough to stop or get slow enough would suffer full damage on impact, I even one shotted a newbie Jenner pilot that stopped behind my teammate while facing in my direction.

It was never documented anywhere. It might be even a design decision, because lights would be getting erased by LRM boats faster than a Streaktaro could say "Blueberry Pie", but in that case it would be nice to have the penalty system described to playerbase...

[Destoroyah]

It's not only lights that this lack of hitting happens. Just today I spectated a enemy heavy mech moving and shooting at a teammate and the spectated mech moving almost exactly parallel of the enemy heavy at about 300-400 meters with artemis and tag, both in the wide open on even terrain. He fired off like 6-8 volleys at the other mech and almost non of the missles hit. I mean there is no excuse for the missle tracking to be that bad.

[focuspark]

stopped reading after the first page of comments but as a coder, i'm willing to bet if there is a bug it's here:

'mech is moving. missiles change 'mech and catch it. sphere is generated. component positions relative to sphere are calculated. most spheres have no components in them.

what happened?

the logic doing the hit detection happens, then the center of sphere is pinned. then they calculate position of all components relative to the sphere. The bug is that the 'mech's position isn't frozen correctly at the moment of impact giving the illusion of explosion velocity when there is none and creating a HSR bug.

[Murphy7]

Oni Ralas, on 24 October 2013 - 12:06 PM, said:

Then you would be wrong. Let me elaborate on your failure...

While I greatly appreciate the whole of the discussion you had on the missle damage calculations, this quote was worth +10 likes all on its own.

[Murphy7]

focuspark, on 28 October 2013 - 11:18 AM, said:

stopped reading after the first page of comments but as a coder, i'm willing to bet if there is a bug it's here:

'mech is moving. missiles change 'mech and catch it. sphere is generated. component positions relative to sphere are calculated. most spheres have no components in them.

what happened?

the logic doing the hit detection happens, then the center of sphere is pinned. then they calculate position of all components relative to the sphere. The bug is that the 'mech's position isn't frozen correctly at the moment of impact giving the illusion of explosion velocity when there is none and creating a HSR bug.

I'm more familiar with physics than code, but I really do fail to the see the difference between explosion velocity with a real time understanding of the target mech's motion, and a snapshot that checks for hit, cycles explosion calculation, checks for mech presence in which case the mech has the time allowed from "check for hit" to "check for mech presence" to have moved away, or rather, the explosion grows effectively during that dwell time between checks.

[Lupin]

Oni Ralas, on 24 October 2013 - 01:05 PM, said:

We used to kinda have that back in the day actually. I personally dislike the current implementation of splash - not that splash itself is wrong, but they way they are doing it is.

Artemis changes the game a bit, makes it seek CT on LoS. Funny thing though, it still doesn't hit the CT while in motion :|

Correct me if I am wrong, but was not splash damage turned off or reduced sometime ago and the reason for the increase in damage to LRM, SRM SSRM?

[AC]

Lupin, on 29 October 2013 - 04:41 AM, said:

Correct me if I am wrong, but was not splash damage turned off or reduced sometime ago and the reason for the increase in damage to LRM, SRM SSRM?

Not totally, but splash damage acts wierd in this game. You take damage to the front and then die because your rear CT armor is being melted by missile splash.

[Corvus Antaka]

I dont mind LRMS missing or doing low damage on fast moving lights that work to dodge them.

But on stationary/poptarting/not moving or very slow lights/mediums LRMS when catching them staning still should be a lot more effective than they currently are.

LRMS are a counter to popsniping but right now their weak damage doesnt justify it given cover/ecm/etc etc.

Edited by Colonel Pada Vinson, 29 October 2013 - 11:19 PM.

[KinLuu]

Oni Ralas, on 26 October 2013 - 12:18 PM, said:

Problem is, lights *don't* take the damage from them correctly. Even at 10cm (Dev), a light takes little to no damage - while in motion - from a missile group. The extremely small - yet instant - blast only scratches the mech (if it even registers as a hit). So coverage aside, we're back to one of two possibilities:

1) Hit registration is not functional 100% on high speed mechs
2) Impact calculations are still wrong in some fashion

It's really easy to test on a live match, impossible in testing grounds. It would also be very helpful to have logging available...but that isn't on deck right now.

Not 100% correct.

If the missiles hit, they deal damage as intended - as damage is applied instantly.

The problem is not the small damage radius, the problem is, that LRMs do not hit at all.

[Satan n stuff]

focuspark, on 28 October 2013 - 11:18 AM, said:

stopped reading after the first page of comments but as a coder, i'm willing to bet if there is a bug it's here:

'mech is moving. missiles change 'mech and catch it. sphere is generated. component positions relative to sphere are calculated. most spheres have no components in them.

what happened?

the logic doing the hit detection happens, then the center of sphere is pinned. then they calculate position of all components relative to the sphere. The bug is that the 'mech's position isn't frozen correctly at the moment of impact giving the illusion of explosion velocity when there is none and creating a HSR bug.

You'd normally code it to do all of that before anything else is allowed to process so the mech couldn't possibly have moved, ( specifically to avoid that kind of bug ) so I seriously doubt it, but I guess with PGI anything's possible.

[focuspark]

***** n stuff, on 30 October 2013 - 01:02 AM, said:

You'd normally code it to do all of that before anything else is allowed to process so the mech couldn't possibly have moved, ( specifically to avoid that kind of bug ) so I seriously doubt it, but I guess with PGI anything's possible.

Referencing of global variables is a common bug creation source, especially when dealing with a multi-threaded system.

std::list collideMissiles(mwo::missle* m, mwo::mech* p, std::list* intersected)
{
Sphere explosion(m->location);
for(int i = 0; i < p->sections.count; i++)
{
if( p->sections[i].intersect(explosion))
intersected->insert(p->sections[i]);
}
}

in the example above, the mech pointer 'p' could be updated asynchronously from another thread - say the one managing motion. This becomes a significant problem.

[Cycleboy]

I'm going to loop right back around to my "splash = dumb" statement. Unless you are doing the code debugging, I can see where you are going with this (and I'm not a programmer!). The check for "hit" may use a different location system from the "check radius vs location" system, and with HSR bouncing around, the position of a fast mech could be way off... i.e. HSR says missile hit, freeze!, explosion radius check vs location... but mech moved... so no damage in range.

Just let "HIT = 1 dam to location of impact" and be DONE! K I S S!!!

[verybad]

What I think would be nifty is if LRMs moved faster if they weren't tracking (ie dumbfired) As well as perhaps did some damage closer in when fired without a lock. (perhaps half to 90m, 0 inside that?)

[Zerberus]

Oni Ralas, on 26 October 2013 - 11:58 AM, said:

Translation: You ****** up, got called out, tried to play it off as a joke and lash out to make yourself look cool. Ad Homenim - it's all the rage these days.

The thing is though, no matter how you slice your post, it's wrong. On one hand you insinuate that you do not fire at lights for the following reason:



You stated, in two lines, why you do not fire and the logic behind it. Except that logic is wrong. Even if you had just fat fingered (as you say, an "obvious mistake") then the logic is still wrong. You yourself prove that in a short post later by even *correcting* the speeds. The icing on the cake was your comment about 1st grade math. I poked at you on this topic - not as an insult (well, it is now) - but rather as just a spot of fun.

So rather than saying "Woops -- hehe, yeah I ****** up. My bad... wait, why *do* lights outrun LRMs then if the speeds aren't...", you went all politician on me and tried to cover up your weak stance with rants and personal attacks. Unless your name is Sara Palin, I - nay, this entire community - expect more from you moving forward.

PS. Good catch on the 120m/s. 9sec delivery time instead of 10. So used to it being 100ms since they day LRM'***** the shelf.

You can believe whatever you want. You will anyway, but that won`t make it true, nor will it make any of what I posted false.

And that`s why I`m very proud to not owe you or the MWO forums any sort of justification for anything I do, here or anywhere else re: what you or other misguided sould expect from me or anyone else moving forward. Too many people here believe what they want rather than accepting what is in fact verifiably true.

In other words, Whoever died and made you king needs to be shot.

Edited by Zerberus, 30 October 2013 - 09:40 AM.

[Kaeb Odellas]

Zerberus, on 30 October 2013 - 09:38 AM, said:

You can believe whatever you want. You will anyway, but that won`t make it true, nor will it make any of what I posted false.

And that`s why I`m very proud to not owe you or the MWO forums any sort of justification for anything I do, here or anywhere else re: what you or other misguided sould expect from me or anyone else moving forward. Too many people here believe what they want rather than accepting what is in fact verifiably true.

In other words, Whoever died and made you king needs to be shot.

Dude, what?

This is what you said:

Zerberus, on 26 October 2013 - 04:50 AM, said:

I rarely target lights with LRMs for a simple reason.

A proper light travels at 150KM/h or more, LRMs travel 120km/h. 1st grade math says I shouldn`t be able to hit it reliably becasue he can outrun my missiles, and that is exactly what we see with missiles impacting 5 meters or so behind spiders.

So it kind of makes everything else more or less irrelevant at that time.

The underlined text is demonstrably false and completely invalidates your argument. He calls you out on this obvious mistake, and you respond with:

Zerberus, on 26 October 2013 - 09:59 AM, said:

ROFL at how you fell into the trap. I need to do this more often....

You try to tear someones academic credibility apart and thereby prove yourself completely oblivious to the obvious mistake that eould have saved you the effort of thought. And you displayed a lack of knowledge of the actual subject in the process.

The PROPER answer would have been alonmg the lines of "You`re making a mistake. Lrms fly at 120 M/s, not KM/h, (which btw is where you failed in the knowledge department, see also http://mwomercs.com/...23-21-may-2013/ ). That equates to approximately 430 KM/h"

But you proved my theory right that the MWO forum will jump to attack anybody who makes even the most obvious of honest mistakes, regardless of how stupid they end up looking afterwards, and for that I thank you

So you deliberately posted something that was completely wrong, just to trick him into doing what? Correcting you in a rather impolite and tactless way and looking like a jerk? This was your grand plan? Newsflash: Being a tactless jerk doesn't make you wrong!

Why don't you try actually discussing the topic of the thread instead of playing useless games like this? It's far more productive. Seriously, you would have been a far bigger man to have made a simple mistake and owned up to it, rather than these silly mind games you're claiming to be playing.






And now to follow my own advice: Why exactly do LRMs need a blast radius? Why couldn't you just have each missile do full damage to whatever component touches? That way you wouldn't have to all of those radius checks and everything runs more efficiently.

Edited by Kaeb Odellas, 30 October 2013 - 11:09 AM.

[focuspark]

Kaeb Odellas, on 30 October 2013 - 11:06 AM, said:

And now to follow my own advice: Why exactly do LRMs need a blast radius? Why couldn't you just have each missile do full damage to whatever component touches? That way you wouldn't have to all of those radius checks and everything runs more efficiently.

to better emulate the TT to hit chart. It's that simple.

I don't agree with the solution, but that's the choice the devs went with. At this point removing the radius check would harder than just making the radius 0.1m (which is what they did).

Edited by focuspark, 30 October 2013 - 04:14 PM.