20 replies to this topic

[Rawrshuga]

[note: - oddly enough the tooltips for the poll I tried to setup decided to appear behind the poll window, so I have no idea what I've checked and unchecked. Apologies if the poll is messed up. FYI I am using Google Chrome.]

When I first started playing MWO I thought my game was screwed up--that lag was a severe problem in the game--because when firing the LB-10X that was on my mech it seemed to take forever for the weapon to actually fire. My thoughts on lag were quickly put away when I fired the medium lasers though--they fired immediately.

I've been trying to understand the reason for the firing delay on autocannons and initially put it aside as a game balancing issue. However after more time in the game, not just playing, but also trying out mech builds I think the firing delay is actually rather unbalancing.

Lasers fire immediately but require you to stay on target to maximize damage. Lasers are relatively light, but require more heatsinks to prevent overheating. Autocannons do full damage but require you to lead your target--not just to account for bullet travel, but also to account for the firing delay. Autocannons are heavy, require ammunition, but build significantly less heat than lasers.

From the way I see it, autocannons are already balanced WITHOUT the firing delay. The tremendous weight and space requirements, and the need for ammunition (thus more weight) already balance them against the lighter, instant-fire, instant-hit, infinite ammunition, lasers.

Autocannons like the AC/2 and 5 are meant for longer range engagements, and as a balance do little damage compared to equivalent long range lasers like the ER Large. However, it becomes very difficult to use these weapons at their intended range because of the firing delay. You already have to lead a target because of bullet travel, where with a laser you don't.

AC/10s and 20s are meant for closer engagements and here the firing delay is just ridiculous. The issue with firing delay, particularly for close range engagements is the fact that the shooter now has to account for his own mech's movements, or remain perfectly stationary (without torso twisting) in order to make sure the round actually lands where his cross-hair is. This makes weapons like the AC/20 nigh unusable and functionally useless, because it is totally ineffective at it's most effective range.

Weapons like the AC/20 are the bane of light mechs, but the firing delay makes the AC/20 useless against them, because in the half-second it takes to fire, any half-decent light mech pilot can (and should) be modifying his movement just that little bit to throw the shot off completely. Only Jedi can use the AC/20 against a light mech.

Just for some context, I am a light mech user and regularly engage heavy and assault mechs with wolf-pack pairs because, by and large, assaults are useless against light mechs. I've also used mechs equipped with gauss rifles, or ER PPCs, and do take down opponents at long range with these weapons. I however, do feel that removing the firing delay from Autocannons would: -

i) make the autocannon are more viable, even practical weapon
ii) sort out other balance issues, such as the feeling that the game favours highly expensive, tricked out, light mechs (which, IMO, currently, it does).
[An AC/20 shot to ... ANY part of a light mech ... will quickly change that. And now all the shooter need do is attempt to lead a 150 km/h perpendicularly moving target at 50m range, on a slow traversing torso, but for once does not have to wait another half second for his weapon to actually fire.]

Edited by Rawrshuga, 01 January 2013 - 11:48 PM.

[Rawrshuga]

I think I ended up clicking on Poll-only, preventing others from replying to this topic. I've since changed that, I hope. I did mention that the tool-tips are blocked, so I have no idea what box does what in the poll creation.

[Tolkien]

I agree that the firing delay is very awkward, but I am not sure to what extent it can be removed. I think the delay comes from the message that you want to fire your AC going to the server when you press the button, reaching it after x ms of latency, then the 'ok you fired it' message coming back from the server after another x+- ms of latency.

I *think* the server actually counts you as firing the weapon after the message reaches the server, but your firing animation is delayed until the response comes back. Against lights (best of luck) I believe you have to actually try to miss them by leading so far in front that you will hit 'where they are going to be' with the shell, just like with lasers you need to miss in front of them to actually hit them, so even if they remove the optical firing delay I think it is still going to rely on fixing the underlying net code before it will actually get any easier to hit things.

Either way, I voted yes since the firing delay makes the game feel really unresponsive and sticky.

[MasterBLB]

@tolkien - would that be true then we should see fire delay for lasers too,wouldn't you agree?

Btw - I voted on yes.

Edited by MasterBLB, 02 January 2013 - 02:19 AM.

[Rawrshuga]

@Tolkien

I have considered the netcode issues, but as I've mentioned I noticed no such delay on lasers. Fire delay is evident on Gauss rifles, PPCs, autocannons, SRMs and LRMs. However my petition is only in regards to autocannons. On Gauss rifles the delay isn't so pronounced and I've managed to take out a mech or two within 50m with them, while moving, while they're moving. IMO the gauss rifles benefit from zero heat generation and massive long range damage so I can see having the firing delay on them as a balance. PPCs likewise, the delay is evident but not unbalancing especially now that they have a 'projectile' speed of 2000m/s, and when you consider the TT canon that PPCs have a minimum effective range.

However, the autocannons are--at the higher damage range--close combat weapons, and the delay there breaks the weapon. Not to say that the netcode can't be improved, but I've got no experience with sorting out netcode so I'll refrain from commenting on it.

[blinkin]

MasterBLB, on 02 January 2013 - 02:19 AM, said:

@tolkien - would that be true then we should see fire delay for lasers too,wouldn't you agree?

Btw - I voted on yes.

oddly enough calculating instantaneous weapons tends to be much easier than things with flight time.

with a laser type weapon you do a single check along it's entire path and pick the closest thing that intersects.

however weapons with flight times must check short distances at regular intervals because objects can enter or leave their path while they are in the air. checking for moving objects can prove very difficult because you not only need to check if something is in the path you also have to check for anything that might be able to enter the path, a much wider area is checked than the single line of the laser and it is all checked repeatedly.

that is the likely source of delays for all of the non laser weapons. it is not just AC weapons, missiles, and PPC share this problem as well.

you are basically asking them to make the game perform the same processes it already performs except faster. it's like telling a mechanic to make your car faster, but not allowing him to add, remove, or change any parts. <-do you see the problem here?

i voted no because what you are asking is essentially impossible.

Edited by blinkin, 02 January 2013 - 02:52 AM.

[Adridos]

The firing delay is the delay between you firing and server acknowledging you fired, thus it is tied to netcode. Basically every projectile weapon has it, while lasers are hitscan, so the client renders them instantly and that's the they don't have the problem.

[UnseenFury]

It's a bug, bob. Read known issues before posting.

[Rawrshuga]

Ok so I've read a bit around the forum on this and no where does it state that this is a bug. I've seen a lot of conjecture about it being a bug, a side-effect of firing happening on the server side then relaying information back to the client, but nothing official. So I would like to know from some low-ping players (I have a 250ms ping) ... I notice a 0.5 second firing delay, how much of a delay do you experience?

Second, why is the delay less on PPCs and gauss rifles and seemingly more on autocannons? (don't currently have the c-bills to put together a gauss and AC mech just to test this).

[Rawrshuga]

Found elsewhere on the forum:

Quote

I tried various Autocannon and found that there is NO firing delay for AC2. Why is that? I love theBattletech gaming system and would like to love this game very much, but I am starting to question the judgement of the dev team because of this. It seems to me the weapons that can really hurt light mechs are dumbed down to empower them.

Entire classes of main guns like PPC, ERPPC, Autocannon and Gauss are affected by this fire delay. I cannot use these weapons which are central to defining Battletech without feeling insulted. I am stuck with using LRMs which are very expensive, so I will probably never be able to afford to drive anything over 50 tons, which further limits my variety. There are many mech designs I have on paper I would like to try in a 3D setting, but implementing them here will simply leave me feeling very disappointed.

[Orkimedes]

This was covered back in closed beta quite extensively (and should be in the known issues forum...somewhere), but firing delay on any other weapon system than missile weapons is, in fact, NOT intentional. Lasers don't really suffer from it, but PPCs, ERPPCs and autocannons are, or at least were, notorious for their often unpredictable fire delays.

EDIT: in case I hadn't made this clear yet, I'm 99.999% certain that removing the fire delay is on PGI's to-do list, and hopefully will leave the game when the reworked netcode comes up.

Edited by Orkimedes, 02 January 2013 - 05:15 AM.

[Firewuff]

They are currently refactoring allthe netcode to deal with rubber banding etc, this will also benefit firing delay. This is in a lead up to reinstating collisions.

At the moment the way it is coded is really bad, it is possible for me to turn so fast in my Raven that when i fire a PPC I it actually at 90deg to where I am facing when I hear the noise. I do hope it is fixed as when I use my AC20's in my cat I tend to be opportunistic and run straight at the enemy to avoid this issue, usually when they are engaged with some one else if i can help it. Walking staight with torso twist also work but circling is almost impossible to hit with an AC of any type.

I should be able to pick off a Raven with an AC20 but as it stands they ignore me and eat the assults alive because of it. There will be a lot of upset light pilots when this is fixed but, hey they are not designed to go toe to toe with an atlas and win most times.

[Rawrshuga]

I hope what Orkimedes wrote is true and this will be sorted out. I have played previous Mechwarrior (single-player, meaning no netcode) games--the ones where the PPC was an agonisingly slow ball of blue light (which made it useless) and Autocannons had a delay before they fired--so forgive me if I'm sensitive to these issues because of that legacy.

blinkin, on 02 January 2013 - 02:50 AM, said:

I voted no because what you are asking is essentially impossible.

Interesting attitude. If that's how eveyone approached things then we'd have no innovation, no invention, nothing groundbreaking. The vote asked if it should be--not if it can be. Understand the difference. Stating 'No' simply because you think it cannot be done doesn't make you right. This not a quiz. It's an opinion poll. If everyone thinks that things shouldn't be done simply because they can't, then you know what? No one would try to do it, and 'impossible' things will never get done, not because they can't be, but because they won't be.

"It always seems impossible until it is done." -- Nelson Mendela

This was a question of what is balanced, not what is possible. And what you say is impossible has been done a lot better in so many multiplayer shooters--Battlefield, MW, Left4Dead--firing with projectiles with minimal delay. I'm not asking to make it as good at 250ms as it would be at 40ms. I'm asking that those with a 40ms ping not experience a firing delay. And I say experience, not if there is or isn't, but if they feel like there is or isn't. Lag issues will be resolved should servers start appearing in other regions.

Here's a simple solution for your impossible problem. Have the firing animation of the weapon be displayed client-side first, before the round gets fired server-side. Nothing really changes, except the user experience. Why I find it funny that people say this is purely a netcode issue is ... well, why is it then that I can torso-twist immediately on the client side, only to find out a second later that I'm actually facing in my previous position? Why is it that I can run past a mech, only to find out a second later that I'm actually running into him. Why are those client side first, same with lasers, and then why are the projectile weapons server-side? Why two different systems?

I find your analogy of the car rather misplaced, since I would expect this to be fixed in a patch, thus totally allowing them to add/remove/change parts. I'm not putting limits on this, you are. But since you decided to give me the analogy of car, I'll end on another car analogy.

Steve Jobs said:

You know how you see a show car, and it's really cool, and then four years later you see the production car, and it sucks? And you go, What happened? They had it! They had it in the palm of their hands! They grabbed defeat from the jaws of victory! What happened was, the designers came up with this really great idea. Then they take it to the engineers, and the engineers go, 'Nah, we can't do that. That's impossible.' And so it gets a lot worse. Then they take it to the manufacturing people, and they go, 'We can't build that!' And it gets a lot worse.

[Elder Thorn]

i remember, in the very dark corners of my memory, that it had something to do with anti-cheat measures

[Rawrshuga]

Yeah I've heard that, and kudos to them for trying. Really.

But I'm not sure if it's worth it. We'll see what future patches brings.

[blinkin]

Rawrshuga, on 03 January 2013 - 09:41 PM, said:

I hope what Orkimedes wrote is true and this will be sorted out. I have played previous Mechwarrior (single-player, meaning no netcode) games--the ones where the PPC was an agonisingly slow ball of blue light (which made it useless) and Autocannons had a delay before they fired--so forgive me if I'm sensitive to these issues because of that legacy.



Interesting attitude. If that's how eveyone approached things then we'd have no innovation, no invention, nothing groundbreaking. The vote asked if it should be--not if it can be. Understand the difference. Stating 'No' simply because you think it cannot be done doesn't make you right. This not a quiz. It's an opinion poll. If everyone thinks that things shouldn't be done simply because they can't, then you know what? No one would try to do it, and 'impossible' things will never get done, not because they can't be, but because they won't be.

"It always seems impossible until it is done." -- Nelson Mendela

This was a question of what is balanced, not what is possible. And what you say is impossible has been done a lot better in so many multiplayer shooters--Battlefield, MW, Left4Dead--firing with projectiles with minimal delay. I'm not asking to make it as good at 250ms as it would be at 40ms. I'm asking that those with a 40ms ping not experience a firing delay. And I say experience, not if there is or isn't, but if they feel like there is or isn't. Lag issues will be resolved should servers start appearing in other regions.

Here's a simple solution for your impossible problem. Have the firing animation of the weapon be displayed client-side first, before the round gets fired server-side. Nothing really changes, except the user experience. Why I find it funny that people say this is purely a netcode issue is ... well, why is it then that I can torso-twist immediately on the client side, only to find out a second later that I'm actually facing in my previous position? Why is it that I can run past a mech, only to find out a second later that I'm actually running into him. Why are those client side first, same with lasers, and then why are the projectile weapons server-side? Why two different systems?
[/size][/font]

i can respect your point about never saying something is impossible. however you are asking them to do the coding equavalent of curing cancer.

lasers act differently from everything else because they are far simpler to code. that technology has existed since well before the original Doom. you create a line and then test what is the nearest object that intersects that line.

but with projectiles the slower it moves the more tests that must be run (speeding up all of the AC weapons probably either made them more accurate or require less memory to process). much of the code that is used for projectiles is the same that you would use for physics collisions. the major issue is that for the most part we care much more about whether the kill shot we aimed for actually hit or not, where we don't really care or notice if our shoulder hit a wall.

have you noticed how many projectiles are in flight at any given moment in a match? each and every missile, AC round, PPC shot, and Gauss round MUST be tested for collisions multiple times during flight, i suspect with the accuracy they have now these shots are being tested at least a dozen times per second. mind you this is all being done in a 3 dimensional environment with 112 randomly moving objects (16 mechs X 7 independent moving parts, the real number is probably much larger considering facings and different joints like legs). the closer together all of these objects are the more testing that needs to be done for every shot.

my best guess is that they found something close to the worst case scenario and throttled back all of the calculation times to equal that so that weapons would always act consistantly, instead of slowing down randomly in heated battles. in short i think they artificially added lag so that the weapons would always fire the same way.

i have a catapult that fires 24 srm per volley and all 24 of those missiles need to be accounted for EVERY time i shoot.

i have yet to see a game that doesn't have this problem with ballistic weapons, most games just put it on the kill end so that a headshot turns out to be a leg or chest shot. once in battlefield 3 i fired my rocket launcher from the passenger seat of a jeep and hit the back of that jeep with that very same rocket. i have seen this very same issue when i played Tribes Ascend. i do not know of any online fps that doesn't have some flavor of this very same issue.

this game relies much more on precision than most so we feel these effects much more than we ever have in other games.

Edited by blinkin, 04 January 2013 - 12:55 AM.

[VXJaeger]

Countless times are when I've shoot my teammate into back 'cause it takes so long to start and finish firing ACs.

[Rawrshuga]

@blinkin

I see your point. I hadn't considered the combined effects of the multiple LRM boats and their frequency of fire and how that would strain the system. I daresay neither did the developers, apparently.

So maybe along with the netcode some short of weapon balancing--in terms of matchmaking--is also needed, and this would be a multipart solution, like 1) limiting the maximum the available missile hardpoints on any one mech and 2) limiting the total number of LRMs per side (e.g. say 100 missiles; so no more than 5 LRM 20s, or 20 LRM 5s, or combination thereof), I'm leaving out SRMs as I think the short range might make them less of an issue.

Edited by Rawrshuga, 04 January 2013 - 02:52 AM.

[Daora Wing]

@blinkin: Maybe it's impossible to remove the fire delay, but I would say PGI should at least try to improve it. What's to say against at least trying?

Fire delay is one point of ACs being unbalanced, so i voted yes.

[Rawrshuga]

Outside of the above I also have to consider the user experience. Having the fire animation play on the client side. As a player who has to deal with lag, half the time I'm not sure if I've fired or not, because the expected response is not there, this was much worse when using something like the Ultra AC/5 because I'd end up double firing when I never intended to. I think having the feedback resolve on the client-side first would go a long way to address ... I dunno, input feedback? ... like that.