385 replies to this topic

[SethAbercromby]

So I took the time to make a crappy GIF of how I think delayed convergence could work.

Note how the weapons still perfectly converge onto a location, however that location takes some time to adjust to range differences. Arms converge faster than torso weapons to give some incentive to actually use them for more than just shielding on some 'Mechs and patience and careful aiming are still rewarded with pinpoint accuracy.

Size/range is exaggerated for demonstration purposes.

EDIT: I realized I made the torso line converge faster of the two. Whoops.

Edited by SethAbercromby, 08 November 2015 - 01:03 PM.

[Duke Nedo]

SethAbercromby, on 08 November 2015 - 01:02 PM, said:

So I took the time to make a crappy GIF of how I think delayed convergence could work.

Note how the weapons still perfectly converge onto a location, however that location takes some time to adjust to range differences. Arms converge faster than torso weapons to give some incentive to actually use them for more than just shielding on some 'Mechs and patience and careful aiming are still rewarded with pinpoint accuracy.

Size/range is exaggerated for demonstration purposes.

EDIT: I realized I made the torso line converge faster of the two. Whoops.

I don't think that it is that PGI doesn't want this... that's what they started out with in beta and that's why we still have the skill. In beta we also did not have any HSR (host state rewind) or "lag prediction" and I think that's the part that broke delayed convergence. There are some nice screenshots of lasers going in weird places...

[SethAbercromby]

Duke Nedo, on 08 November 2015 - 01:17 PM, said:

I don't think that it is that PGI doesn't want this... that's what they started out with in beta and that's why we still have the skill. In beta we also did not have any HSR (host state rewind) or "lag prediction" and I think that's the part that broke delayed convergence. There are some nice screenshots of lasers going in weird places...

Well yeah, HSR would have to compensate for 2 locations per 'Mech instead of one when predicting firing vectors, but I don't think it would actually take that much additional server power compared to doing all sorts of calculation gymnastics they cooked up for weapon balance the past few months, not to mention quirks, which all could take a back seat if delayed convergence were to hit.

[Duke Nedo]

SethAbercromby, on 08 November 2015 - 01:25 PM, said:

Well yeah, HSR would have to compensate for 2 locations per 'Mech instead of one when predicting firing vectors, but I don't think it would actually take that much additional server power compared to doing all sorts of calculation gymnastics they cooked up for weapon balance the past few months, not to mention quirks, which all could take a back seat if delayed convergence were to hit.

Load-wise it should be much more than that. The server will have to keep track of the reticule of every single mech, every single server frame, and project the convergence vector based on the previous point and on what you are aiming at... as it is now, it only needs to care about convergence of a particular mech when he is shooting.

Edited by Duke Nedo, 08 November 2015 - 01:52 PM.

[SethAbercromby]

Duke Nedo, on 08 November 2015 - 01:49 PM, said:

Load-wise it should be much more than that. The server will have to keep track of the reticule of every single mech, every single server frame, and project the convergence vector based on the previous point and on what you are aiming at... as it is now, it only needs to care about convergence of a particular mech when he is shooting.

You over complicate this a lot more than it needs to be. Even with instant convergence, the server creates or handles a small empty object and uses it as a reference point for the weapons fired in that frame. From a programming perspective, if this was handled properly, I'd only need to add one more empty object and alter the game logic for the two a little.

Really, checking on 8 weapons fired in an alpha whether any of them are exceeding their maximum number of weapons before heat scale kicks in since the past 0.5 seconds and the resulting heat adjustments takes a lot more calculations to resolve.

[Duke Nedo]

Sound good... perhaps then it was because you need to calculate HSR for every frame, not the hitscan. Problem was if I remember correctly that the problem lied in needing to calculate and keep track of for how long an enemy had continuously been under the crosshairs to see how much convergence you had built up.

Another problem may have been that HSR was shaky so that it had trouble with the continuous part... No clue really, but there were technical problems related to HSR.

[SethAbercromby]

HSR always introduces a number of problems. The golden goal of online play is "what you see is what you get" (WYSIWYG), but that is realistically impossible to achieve. You'll always have to start making compromises when talking lag compensation and to be honest, I got nothing for that. It's a topic I'm very green on and will have to figure something out for my own games once I get there.

[Ljusdahl]

To curb large pinpoint alphas, why wouldn't it work to simply decrease laser damage, but decrease cooldown as well to keep DPS the same(or slightly higher to compensate for the alpha nerf)? Alphas are now decreased, without making lasers worse. Lights can still be happy.

Also, the fact that dissipation pauses while lasers are burning really gimps chain fire. I'd love to see it go. I guess that's wrong.

Edited by Ljusdahl, 09 November 2015 - 01:57 PM.

[Hotthedd]

Ljusdahl, on 08 November 2015 - 03:59 PM, said:

Also, the fact that dissipation pauses while lasers are burning really gimps chain fire. I'd love to see it go.

This.

It makes zero sense that dissipation pauses, dissipation should be constant unless you're being hit by flamers.

[Widowmaker1981]

Duke Nedo, on 08 November 2015 - 01:49 PM, said:

Load-wise it should be much more than that. The server will have to keep track of the reticule of every single mech, every single server frame, and project the convergence vector based on the previous point and on what you are aiming at... as it is now, it only needs to care about convergence of a particular mech when he is shooting.

yes, exactly this. HSR would have to keep historical (for a few seconds) data for the distance to target reticule for every mech, and current convergence angle for all arm and torso weapons. it adds an ENORMOUS amount of data for HSR to deal with and doesnt work.

[DivineEvil]

Quote

You over complicate this a lot more than it needs to be. Even with instant convergence, the server creates or handles a small empty object and uses it as a reference point for the weapons fired in that frame. From a programming perspective, if this was handled properly, I'd only need to add one more empty object and alter the game logic for the two a little.

It's not about number of dummies. It's about how you'll need to animate a dummy to acquire a position of another, also constantly moving dummy, using real-time algoritms, for each mech on a field for each frame.

Quote

Really, checking on 8 weapons fired in an alpha whether any of them are exceeding their maximum number of weapons before heat scale kicks in since the past 0.5 seconds and the resulting heat adjustments takes a lot more calculations to resolve.

Are you really good enough in coding to tell us, that an active if-then modifier based on 0.5 second weapon counter is more process intensive, than a passive per-frame lerp movement interpolation? Seriously?

[Greyhart]

did I read somewhere that the machine gun already has a cone of fire?

[Reno Blade]

Besides my pretty nerf-heavy changes I proposed here:
http://mwomercs.com/...ost__p__4797932

I think that the Idea behind the laser Lock-for-full-damage was kinda in the right direction.
But instead of the damage, the hit location should be the value that changes, just like in Tabletop and what actually makes sense for a targeting system.

Take this:

Now see the torso cone-of-fire area before the lock and the random hits all over the target?
With the lock reducing the size of the target reticule/area and focusing the shots more where you are actually aiming.
Yes, I used RNG and cone of fire here, but isn't this kinda the most logical way to implement computer aided targeting?

PS

Edited by Reno Blade, 09 November 2015 - 09:12 AM.

[SethAbercromby]

Hotthedd, on 09 November 2015 - 04:46 AM, said:

This.

It makes zero sense that dissipation pauses, dissipation should be constant unless you're being hit by flamers.

I've made some tests months ago and this is not the case. Back when MLs had exactly 1 hps, I mounted 4 of them on a chassis with exactly 4 HPS dissipation. Firing all of them in chain fire resulted in the heat gauge standing perfectly still as expected.

[Ljusdahl]

SethAbercromby, on 09 November 2015 - 10:11 AM, said:

I've made some tests months ago and this is not the case. Back when MLs had exactly 1 hps, I mounted 4 of them on a chassis with exactly 4 HPS dissipation. Firing all of them in chain fire resulted in the heat gauge standing perfectly still as expected.

Dang, I think you're right.

[SethAbercromby]

Ljusdahl, on 09 November 2015 - 01:30 PM, said:

Dang, I think you're right.

Yeah it's easy to misinterpret the heat spike as it circumventing your heat dissipation. Though a ML generates 1 HPS, it's beam duration of then 1 second generated an effective 4 HPS, more than most 'Mechs can dissipate on a whim.

[Tombstoner]

SethAbercromby, on 08 November 2015 - 10:48 AM, said:

Anecdotal evidence is anecdotal.
(Sorry, I only get to use them this often)

Seriously though, just because you think it's fine doesn't mean that it's actually good.

This however is what PGI management uses to play test the game. When they hear about something they drop in and check it out. How it feels is used very often to asses players issues. If they find it acceptable it stays.

Reno Blade, on 09 November 2015 - 09:12 AM, said:

Besides my pretty nerf-heavy changes I proposed here:
http://mwomercs.com/...ost__p__4797932

I think that the Idea behind the laser Lock-for-full-damage was kinda in the right direction.
But instead of the damage, the hit location should be the value that changes, just like in Tabletop and what actually makes sense for a targeting system.

Take this:

Now see the torso cone-of-fire area before the lock and the random hits all over the target?
With the lock reducing the size of the target reticule/area and focusing the shots more where you are actually aiming.
Yes, I used RNG and cone of fire here, but isn't this kinda the most logical way to implement computer aided targeting?

PS

Yes.. yes it is. Add in something like a gunnery skill modifier from TT or the current tier system,one that furthers reduces radius reduction time and you got some fried gold. you can scale it such that Tier 1-2 are pin point and 4-5 take time. then you can add in a piloting skill to further reduce shake from jumping.

Its a stupid simple system to stratify players based on skill for easy match making. The game can tolerate pinpoint high alphas easily if and only if you add this and then correct for the changed hit frequencies from TT. In fact it would become the hall mark of a highly skilled player...

PGI should just build in a COF for tiers 4-5 and reduce it to pin point for 1-3.

[mechkearney]

dante51, on 23 October 2015 - 12:29 AM, said:

Honestly I don't understand problem with high alpha. I have different mechs with different builds, some of them high alpha builds. Besides being a part of the lore, it's present nearly at every multiplayer game (from Dota to Counter-Strike). Why do you want to get rid off it?

A lot of good configs (and mechs too) were killed with ghost heat, instead of balancing other weapons and now, the same mistake is happening.

Then go play DOTA/Counter-strike. Don't turn something into something else simply because you like it. Respect variance.

SOLUTION PART 1:
The first part of the solution is to make every weapon group chain fire. Alpha strikes still fire all weapons, but, I see a lot of builds where weapon group 1 is an alpha strike of 6 med lasers or 6 small pulses. What's the point of alpha striking when weapon group 1 is an alpha strike?


SOLUTION PART 2a:
Energy drain. In battletech mechs couldn't run at full speed while alpha striking. They ran. Stopped. Shot. Ran away/moved. Firing weapons should use energy. Firing more than X weapons uses 80% of mech's energy.

SOLUTION PART 2b:
Mechs cannot run at full speed and fire simultaneously. Sarna mentions a mech's cruising (walking) speed, which is not it's maximum speed. So, a mech can cruise and shoot at the same time, or run full speed, but not do both. This means lights are no longer wrecking balls of high damage and assaults can once again regain their reputation as most damaging mechs.

SOLUTION Part 2c:
Mechs have to be stopped to alpha strike. Since weapons groups can only chain fire, firing multiple weapons at once will be considered alpha striking, and should use up mechs energy reserve. As such, the mech can only walk instead of run for a set period of time. Maybe 2 seconds. After which, the mech can run at full speed.

SOLUTION Part 3:
remove throttle decay. only allow for cruising/running speeds. Press forward makes mech walk. Pressing forward a second time makes mech run. Pressing backwards makes mech stop if walking forward, then start walking backwards. If you want the mech to stop, you must press the full stop key (normally x).

Look, I know these will make the game more difficult. But, they will also make everyone play together as a team. Units will actually operate more as a unit and try to train its members. This also discourages people who think this game is CoD or Modern Warfare. It's not. It's a team based game.

This also makes mechs that aren't used, usable again. Hint hint Summoner pilots. I know PGI won't listen, but, I think these will not only make things more like MechCommander 2, but also better for BattleTech in general.

[Serpentbane]

I voted other, explain, so here is my take on it. It don't like the artificial laser damage based on lock solution as there is no realistic reason for it to happen what so ever. More spread before lock is slightly more explainable, but should then affect all weapons.

This solution is from this thread btw.
http://mwomercs.com/...ergence-issues/
(poll)


Static Convergence for torso mounted weapons.
The weapons on mechs can be mounted on either torso or arms. These two locations are very different. The arms can move independently of each other and the torso, while they still follow the torso movement as well. The torso can move, but all weapons on the torso will point at the same direction.

Torso weapons are bolted on to the hull. This means they should not be able to move independently at all. They can only move with the torso. In short, the convergence range on torso mounted weapons should be the same regardless of the range to the object the pilot targets.

Weapons on the more flexible arms could however adjust to converge at the distance of the object the pilot is aiming at.

Now, take a look at this high detail representation of a Dire Wolf shooting at a smaller mech and an enemy Dire Wolf with fixed convergence ranges on the torso mounted weapons. I have included several examples, where Convergence Value (CV) represents a defined set of convergence ranges in each example. (CV1000 converges at 1000m) As you can see, this can really affect the effective convergence depending on the defined CV relative to the range to the targeted mech. In particular if the CV is set at close range where the problem is bigger.



Now, this can be implemented in several ways.

1. PGI defines the default CV for all mechs or per chassis.

2. Players can set a CV for each mech in the mech bay.

3. Players can adjust CV ingame, but this takes time as the servos do their work. Lets say 20 sec where the weapons cannot fire.

I also think that removing arm joints also removes the arms flexibility, and weapons mounted on that arm converges with the torso mounted weapons.

In this next high quality representation of the batteflield I also let the mech fire it’s arm mounted weapons. They will converge fine at all ranges, except at close range where the arms on some mechs can come in conflict with the mechs body. Also, the shots will hit the closer mechs out to the sides if you’re piloting a Dire shooting at a smaller mech. Like in example 3.



This would also work depending on the height of the mechs weapon mounts. So the spread will really be circular relative to the aim.


So, with CV1000 aiming high on the CT/head, the hits will be spread out or even shoot above the close by mech.

The strength of this design is the ability to tailor your mech to a certain role and play style. Having high CV would make the mech less accurate at closer range spreading the damage or even making the shots miss. At long range the ordinance spread would be less, however the aim would also be less accurate and the weapons could suffer from lowered damage.

Players wanting to have high close range alpha strikes could still do this, making them dangerous close range opponents. However, having low CV values make them close to useless at ranges surpassing the set CV.

So, what do you think?

I realize this will affect wider mechs more than the smaller mechs. And mechs with CT mounted weapons would have some advantages. But, then again, the high dmg pinpoint alphas are usually tied to the larger mechs as well. In all cases, the convergence point will spread some counting weapons from left to right arm. Adjusting convergence is not about making the mech useless either.


* Yeah CR (Convergence Range) could have been a better word, but I already made the images.

[Zionkan]

@Serpentbane, your solution has some flaws, it hits mechs with Torso only weaponry hardest while not touching in same way mechs with arm mounted weapons, see Gargoyle/Exe/Dire vs Banshee as example.