2
Quote
Answer from Paul: Weapon convergence is a tough nut to crack. We want to keep the number of random “dice rolls” to a minimum, and network synchronization can become unpredictable when trying to determine a convergence point that may or may not be moving. It will be necessary to make the convergence point calculation server authoritive and that can cause a desync due to the fact that the simulation runs at different frequencies on the server and client.
While this is something we’ve wanted for a while, it’s becoming more and more apparent that it is going to take some serious engineering time to address. Currently, the engineers who would be working on this are already tasked with other high priority features and investigations. Pulling them off their current schedule will have both short and long term negative effects on the game as a whole, so the chances are very low that they will be able to address convergence any time soon. Convergence will always be something we will keep on the drawing board but as to when it can be tackled is not known at this time.
While this is something we’ve wanted for a while, it’s becoming more and more apparent that it is going to take some serious engineering time to address. Currently, the engineers who would be working on this are already tasked with other high priority features and investigations. Pulling them off their current schedule will have both short and long term negative effects on the game as a whole, so the chances are very low that they will be able to address convergence any time soon. Convergence will always be something we will keep on the drawing board but as to when it can be tackled is not known at this time.
After reading the first half of this in Homeless Bill's thread, I found myself reevaluating my previous suggestion for convergence. Clearly, highly dynamic weapon convergence would be extremely difficult to implement with a server-authoritative system, as Paul points out. Even so, I firmly believe that MWO requires a convergence mechanic that sometimes makes it more difficult to concentrate your shots in a single location on your target. Doing this without resorting to a cone of fire, retaining a skill-based system is also vital.
Thus, I started trying to think of ways to make such a system easier to implement, based on the server-authoritative systems that already function in MWO, primarily Host State Rewind, and also Missile Locks (which do not appear to suffer from desync issues).
The conclusion that I arrived at is a variation of another idea that has been previously mentioned for convergence, namely using a system similar to missile locks. The level of complexity would depend greatly on how much time the engineers can spend on it, so I'll start with the simplest version.
Simple Target-Lock Convergence:
- When no target is selected, the weapon convergence point should be set at ~5000m. At normal combat ranges, this would be nearly parallel, but would not require adding code to make the weapons actually fire straight ahead.
- When a target is selected, the pilot must hold the crosshair over the target to gain 'Target Lock'. Moving the crosshair off of the target loses progress towards a full lock. Once full lock is achieved, briefly moving the crosshair off of the target will not break the lock. (exactly the way missile locks work)
- When a full 'Target Lock' is achieved, the convergence point would be set at the distance under the crosshair. (exactly the way convergence works right now, instant)
- When 'Target Lock' is lost, the convergence point reverts to `5000m.
Dynamic Target-Lock Convergence:
- When no target is selected, the weapon convergence point should be set at ~5000m.
- When a target is selected, the pilot must hold the crosshair over the target to gain 'Target Lock'.
- At the beginning of the lock process, the convergence point is at 5000m. As the lock progresses, that distance shrinks at a steady rate, proportional to the progress of the 'Target Lock', until the convergence point reaches the crosshair distance, at 100% lock. When progress is lost, the convergence distance increases at a steady rate, until it reaches 5000m or the lock gains progress again.
- When a full 'Target Lock' is achieved, the convergence point would be set at the distance under the crosshair. (exactly the way convergence works right now, instant)
- When 'Target Lock' is lost, the convergence distance will increase at a steady rate until reaching 5000m.
A downside to this system is that closer targets would require longer lock time. This would be mitigated to some degree by the fact that a closer target is also effectively a bigger target.
A positive effect would be that hardpoint placement will become much more relevant. Head and Center Torso hardpoints would be highly accurate even without full lock, while widely spaced arms (Jagermech, I'm looking at you) would require a full lock to achieve pinpoint damage at any range, but particularly up close. This would make the 2xAC20 Jager less deadly, as the pilot would have to hold their shot until full lock, though there would be no effect once a lock is achieved.
This would also make ECM more powerful, but it shouldn't be too devastating once people get used to it. Closer targets will be easier to hit even without lock, including light 'Mechs. At longer ranges, however, ECM becomes a minor defense against snipers, who would be unable to focus damage at a single point without lock, though they could still damage their target. Similarly, LBX and regular SRMs would be more useful against ECM carriers at short range, giving them another role.
The overall effect should be to spread damage over more sections of the 'Mechs, reducing the impact of massive Alpha Strikes to some degree, and generally increasing the survival time for everyone. It might even render the boating heat penalty unnecessary. A crosshair that indicates the convergence progress and 'Target Lock' status would be needed, of course, but that shouldn't be a big deal either.
Thoughts?
Edited by Renthrak, 17 July 2013 - 02:56 PM.
