Hallo,
wir hatten heute eine super angenehme und spaßige Runde BF1942 auf dem RBTV Server von dem LAN Event. Da es mir soviel Spaß gemacht hat mit der Community eines meiner Lieblingsspiele zu spielen, wollte ich fragen ob Interesse besteht so etwas regelmäßig zu machen.
Man könnte sich zwei-wöchentlich (oder sogar wöchentlich) samstags (Wochentag variabel natürlich) auf einem Server treffen und ein paar Runden BF1942 zocken. Server könnte ich mich drum kümmern und falls jemand sein Spiel nicht zum laufen bringen kann, kann ich da auch behilflich sein. 
Der Thread hier ist erstmal dafür da das Interesse abzufragen und dann sehen wir weiter.
Battlefield 1942 Bohnenkrieg Abend - 12.02. - 20:45 Uhr
Paar gute Guides um Battlefield 1942 zu lernen [WIP]
Zusammenfassung
Fliegen:
Guides:
http://matthewbrownetx.tripod.com/bf1942/planes.html
Videos:
Battlefield 1942 Flying - YouTube
Tanken:
Infantry:
Erklärung zum Serververhalten in BF1942:
Zusammenfassung
Brief Introduction to Multiplayer Netcode To achieve synchronicity in a multiplayer game two different concepts can be utilized.
- Centralised Synchronisation/Serverside Synchronisation
The clients send their input to the server. The server updates its simulation according to the info it receives from the clients. The server sends updates of the simulation states back to every client.
- Decentralised Synchronisation/Clientside Synchronisation
The clients send their input to each other. Each client receives input from all other clients connected to the session and update their simulation accordingly. The clients update their simulation and send the update to everyone.
This concept may use a server to transmit data, however,
point-to-point connections are a feasible way to omit a server. A server is then only used for managing the session, as in connecting and disconnecting clients that want to join or leave.
Any solution will have to be implemented into the engine of a game.
Other solutions to the problem will use a synthesis of these concepts.
Basics about netcode in Battlefield 1942
1942 runs with the Refractor engine, which was dice’s second go at a multiplayer game engine. We can confidently say that refractor utilizes centralised synchronisation.
That means the client regularly sends its input to the server, this either happens in form of transmitting client keystrokes or - more likely - by transmitting a refractor-interpretation of client keystrokes.
The server uses the information of the clients to update the state of its simulation. This means it’s the only authority that decides where a player is at a given moment in time, and whether shots somebody fired are hitting something or not.
The server also regularly sends updates of its simulation state back to the clients so they can update their respective simulation. This way the client will learn if a vehicle is comming closer and an engine sound has to be played. Or the client player has been hit and died.
Ping, refresh rates, ticks, frames
Many people probably know and understand the meaning of ping. It’s the round-trip-time of a network-packet going from the client to the server and back.
However, another important factor in understanding the netcode in a multiplayer game is the refresh rate at which clients and the server send their updates.
This refresh rate is in general independet from the actual speed of the engine’s gameloop, however, it’s also sometimes referred to as engine tickrate.
So if the game of a client is rendered at 120 frames per second. It does not mean all these frames are sent to the server.
In 1942 the client refresh rate is set to 30hz. That means only every 4th frame your cpu/gpu renders for (potential) display on your monitor actually will be transmitted with the respective information to the server. It will arrive there after ping/2 ms. The results of the input to the server simulation will be transfered back to the client with the next server update - the transfer time will again be ping/2 ms.
The server refresh rate in 1942 depends on the connection type chosen by the client in the bottom right of the server browser menu. You can choose there from ‚Modem56k‘, ‚ISDN‘,
‚ADSL‘, ‚LAN‘. Choosing ‚Modem‘ will set the server to send updates at a 10hz refresh rate, choosing anything else will set a 20hz refresh rate.
Short summary of information so far
-
1942 uses serverside synchronization, that means hitregistration and physics are computed on the server.
-
The default client refresh rate at which the client sends updates to the server is 30hz.
-
The highest default server refresh rate is 20hz.
Movement-prediction: Inter-/Extrapolation
Now you might ask: ‚But Mitch, if I really only receive 20 updates per second from the server, shouldn’t my game stutter like hell? Why is it running so smooth, especially when I use renderer.lockfps to make the game pre-render hundreds of frames per second?‘
Well, that’s because your game is constantly lying to you, but it’s trying to do this as good as possible. The clientside of the game never knows the exact current game state of the server. It can only know the exact game state of the server ping/2 ms ago right after a server update arrived.
To make the game seem fluid the client-simulation tries to predict what the next server update will look like. This prediction is computed by utilizing Inter-/Extrapolation.
If you render your game at 120 fps then in every 6th frame you would receive an update with new information from the server. The other 5 frames will only be predictions.
It is possible to make this effect visible by turning the clientside movement-prediction off. Increasing the server refresh rate to a higher value will result in the game seeming fluid, despite turning movement-prediction off.
Understanding bad hitreg: Worst-cases and tick-alignment
To understand why the hit-registration of the game can be inconsistent it’s best to think about worst-case scenarios. On one hand we will try to understand what are worst-cases for movement-prediction, and on the other hand we will try to explore what are worst-case scenarios concerning the netcode.
In terms of movement-prediction it should be quite obvious that high velocities will scale possible errors in inter-/extrapolation. For example when a player is traveling at a high velocity in a certain direction but then suddenly changes its path.
Two classical examples for when movement-prediction will do badly.
- Infantry strafing: Suddenly changing between moving from left to right and vice versa is hard to inter-/extrapolate and will therefore genereally lead to errors.
In this example you can see how the movement-prediction can lead to errors. Let’s think about the moment shortly after Player A changed his direction. If the server receives an update from Player A in this moment shortly before it sends its update to Player B then Player B will receive quite fresh information that the movement direction of Player A has changed.
However, if we imagine that the server has just sent it’s update when the info about the movement-change arrives. Then this means the movement-change will only be updated to Player B at the next update, roughly 50ms later. When the update finally arrives at Player B the game will not just correct its mistake by ‚teleporting‘ the player to the correct position. But instead it will keep lagging behind a bit for a while, trying to seemlessly unite the ‚wrong‘ game-state of the client with the game-state sent from the server.
- Plane dive-bombing: Sudden changes in direction and speed such as when flying divebomb-attacks are another prominent candidate to produce movement-prediction errors. Faulty predicted and displayed can be the position of the plane as well as the bomb-trajectory.
vielleicht gibt es ja auch paar Bohnen Mitarbeiter die ab und zu Bock haben.
finde ich auch gut 
. Noch geiler fänd ich natürlich einen BFV Server mit guten Maps in der Rotation (WAKE!). Kann man da mittlerweile Server mieten?