Jump to content
Welcome to the virtual battlefield, Guest!

World War II Online is a Massively Multiplayer Online First Person Shooter based in Western Europe between 1939 and 1943. Through land, sea, and air combat using a ultra-realistic game engine, combined with a strategic layer, in the largest game world ever created - We offer the best WWII simulation experience around.

Engine Bug - What We Know


jester
 Share

Recommended Posts

This ancient bug is one that needs to get squashed, especially if we are going to be experiencing more new players in the very near future. I have noticed it much more frequently as of late both with using one single account as well as having two accounts signed in. 

Here's what I know of this bug, please feel free to add anything you might think will help in replicating it/finding the source.

---------------------

First off, what is it? The engine bug is an audio bug which displays a vehicle's engine as running full speed at all times, even when the vehicle's engine is off. This is only observed from third person. To the player driving the vehicle, everything is as normal. To others, they may or may not hear the vehicle's engine as running full speed depending on whether or not they are experiencing the bug. This is detrimental to gameplay for both the player using the bugged unit as well as the players exposed to the bugged unit in that the player using the bugged unit cannot hide/exhibit any form of stealth as the audio cue is constantly giving the player's position away, while those who are exposed to the bugged unit have their audio flooded with a full speed engine sound at all times. This is particularly bad in close quarters scenarios (cities/towns) where bugged units may be stationary or there may be multiple bugged units.

Without question, we can all agree that a player's audio identification is key to survival and success in this game and this bug hinders that ability greatly. So let's get down to what we know.

 

1. It's likely tied to connection quality similar to that of the firebug. More or less, the client isn't reading that the event has ended (engine is off / gun stopped shooting) and this is only worsened when connection is poorer, whether ISP related or more bandwidth being used due to having two accounts logged in. However, it is different from the firebug in a few ways, which brings me to the next point:

2. Engine bug exists throughout the game world existence of the bugged unit. It will not go away until that unit is removed from the game world - you will even notice hulks of destroyed (exploded) vehicles with the engine bug still emitting the engine running full speed sound until the player actually despawns. It cannot be 'fixed' by turning engine on/off similar to the way the firebug can be 'fixed' by shooting the weapon again. I believe this property of the bug will be paramount into nailing down the root cause. 

3. Engine bug is much more common in specific units. There are certain units which are vastly more prone to experiencing the engine bug, which from my experience are as follows: DAC, R-35, 232, StuG B (possibly G as well?), Pz. 38t. This does not mean the engine bug exclusively affects these units. I have seen the engine bug on many other units, S-35. Ju 52, etc. However, this list of units are units extremely prone to the bug. Almost every DAC, R35 and StuG B I've encountered in game as of late has had the bug.

4. The bug can happen both upon unit's spawn (creation) or randomly upon a unit's later engine startup. 

5. The bug does not replace the engine sound. Instead, the bug displays as a second engine sound. You will note bugged units displaying the full speed engine sound alongside of their actual third person engine sound. In essence, bugged units are making two units' worth of engine noise. 

6. Several years back, a different type of engine bug existed in which a unit's engine would never start, sometimes upon spawn, sometimes later down the road. Interestingly enough, the units most affected by the bug were the same exact units - DAC, R35, StuG B. I'd bet whatever was changed to fix that bug is part of the reason we now have the audio engine bug today. If there are any notes on what was done to those units, that's where I'd look first. 

 

It seems impossible to replicate. But what is so different with this one that it cannot be stopped by turning engine on/off like firebug? Particuarly why is it displaying as a second sound from the unit? This one has to go..hopefully I helped a bit

Edited by jester
  • Like 1
Link to comment
Share on other sites

4 minutes ago, rotsechs said:

I hate that thing. Gets me killed because I can't hear anything.

Absolutely. On the other hand, I've also killed many units (and probably been killed myself) simply because their position was given away from their engine bug. Normally, they'd be sitting hidden in foliage/behind a berm not even able to be seen, yet still given away from the engine bug. It's bad on both ends of the deal.

Link to comment
Share on other sites

17 minutes ago, jester said:

It seems impossible to replicate.

Actually easy to replicate, have an observer on a separate network.
Trick is just not to 10057 yourself

Spawn unit with engine, or automatic weapon (or both) unit model does  not matter
Start engine, or Pull Trigger.
Induce packet loss
Release trigger or stop engine.
restore normal packet flow

Engine will continue to appear to run to the observer or gun will appear to fire (Is not always full throttle, that depends on something else)
Machine gun will continue to fire.
 

Link to comment
Share on other sites

13 minutes ago, merlin51 said:

Engine will continue to appear to run to the observer or gun will appear to fire (Is not always full throttle, that depends on something else)

Interesting, I've only noticed the full speed engine noise. I do remember, though, that the old engine bug where the unit would never start up would constantly display an engine idle sound even though for the player with the affected unit the engine just never turned over. 

Link to comment
Share on other sites

depends on what state i received you as being in.

The way 3rd person engin works is off perceived speed of movement.
I have no way of knowing what your gas pedal is going, the game does not transmit that data, probably to reduce useless network traffic.

So engine on/off state + Speed of movement = approx rpm range of 3rd person engine sound.
If you are rolling, slam on brakes and kill engine for example and some of that data gets lost, i may hear you sitting still with the engine revved.
If you had been sitting idling for a while, and i had a stream of data showing you idling, but i miss you cut the engine, i will hear you simply idling.

Where the data gets lost can happen on either end.
You can guess at that by if 1 person is seeing it in 3rd person or multiple. 

Edited by merlin51
side tracked, words made no sense
Link to comment
Share on other sites

5 minutes ago, merlin51 said:

depends on what state i received you as being in.

The way 3rd person engin works is off perceived speed of movement.
I have no way of knowing what your gas pedal is going, the game does not transmit that data, probably to reduce useless network traffic.

So engine on/off state + Speed of movement = approx rpm range of 3rd person engine sound.
If you are rolling, slam on brakes and kill engine for example and some of that data gets lost, i may hear you sitting still with the engine revved.
If you had been sitting idling for a while, and i had a stream of data showing you idling, but i miss you cut the engine, i will hear you simply idling.

Where the data gets lost can happen on either end.
You can guess at that by if 1 person is seeing it in 3rd person or multiple. 

This doesn't explain why certain units are spawning in and having the full speed engine bug right when they turn their engine on for the first time, though. I've heard the engine turning on "idling" sound come on at the same exact time as the full speed engine bug sound, all the while the unit is totally stationary and hasn't even shifted into gear.

Link to comment
Share on other sites

1 hour ago, jester said:

This doesn't explain why certain units are spawning in and having the full speed engine bug right when they turn their engine on for the first time, though. I've heard the engine turning on "idling" sound come on at the same exact time as the full speed engine bug sound, all the while the unit is totally stationary and hasn't even shifted into gear.

I havent run across anything unit specific yet.
People specific yes, ive run across some people that everything they spawn in with, if it has potential for a state bug, they are going to have it.
Rode out on a morris, was listening, but not looking at screen while we were driving.
I eventually realised like 10 minutes of that ride was me sitting there stopped at our destination cause i still heard the engine as if we were driving.
Later on, same guy, we are defending a CP, he is spraying bullets by the 1000's, just a constant stream.
Shame they are non fatal.

Link to comment
Share on other sites

  • Registered Users

Was talking about the engine/fire bugs the other night with Oldzeke.  The presumption is that you miss getting a state change packet telling you when someone has stopped shooting, or turned and engine on/off.

However, if that was the case then shooting again, or turning the engine on/off should fix it as you would received an updated state. But in many cases it doesn't.  Also for example, if it was the person who is shooting who's PC is failing to send the packet to the server, then everyone should see that person with a fire bug, but they don't which suggests that there is more to it then just a missed update state packet.

We did think that maybe when you do something like start an engine, it creates for want of a better word a packet that says player A has started his engine.  You PC receives this packet (with a specific reference to this incident, lets say 50) and plays the appropriate engine sound. Now player A then turns his engine off which creates another packet saying cancel the action referred to in packet 50.   Now if you never receive this 2nd packet it wouldn't matter if they turned their engine on or off lots of times as there would never be a packet telling your PC to stop the action referred to in packet 50.

We had also pondered the idea that the sound loop that is stuck is actually tied to an animation. eg, when you fire a gun it displays a muzzle flash animation and plays the sound of the shot.   We think it may be this 3rd person animation sequence that gets stuck in a loop on your computer that means you see that person with a fire bug.  Same thing with engines were the animation is of the exhaust fumes and dust from the wheels/tracks.

Link to comment
Share on other sites

There are lots of possible scenarios for such errors.

Code determines who's in interaction range with whom. When an area is near max interaction population, there have to be instances of my being close enough to you to get your effects packets, but then at least one player with a higher priority moves into our vicinity and I stop getting your packets. If I got your engine start/run packet and then you drop off my interaction list, maybe it's possible for the "periodic bookkeeping cleanup" to glitch and my client's playing the engine run sound on your behalf to never stop, even though your status has changed. 

 

Link to comment
Share on other sites

  • CORNERED RAT

@jester have you tried disabling Netcode3 to see if it makes a difference Better or Worse ? 

Link to comment
Share on other sites

4 minutes ago, OHM said:

have you tried disabling Netcode3 to see if it makes a difference Better or Worse ? 

I have not, i have been trying to keep it on since you guys fixed the bug with it

Link to comment
Share on other sites

Sounds like the host/client require an <ack> exchange for all messaging. An increase in frequency of this bug might be related to a change from TCP to UDP. The unacknowledged messaging is always going to be vulnerable to lost packets.

Link to comment
Share on other sites

On 8/1/2017 at 7:32 PM, OHM said:

@jester have you tried disabling Netcode3 to see if it makes a difference Better or Worse ? 

I will try this tonight. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...