h$98s&      !"#$%None#$&'(/258:<=>? &alpaca-netcodeClient -> Server: Regularly sent. Used for clock sync and to acknowledge receiving auth ticks up to a given point.'alpaca-netcodeServer -> Client: Sent in response to Msg_Connect. This indicates the clients PlayerId(alpaca-netcodeServer -> Client: complete authoritative inputs for a run of ticks)alpaca-netcode(A non-authoritative hint for some input.alpaca-netcodeSettings for simulating network conditions. Packets in both the send and receive directions are randomly dropped or delayed by `simPing/2` plus some random duration between `-simJitter` and .alpaca-netcodeExtra ping (seconds)alpaca-netcode4Extra jitter (seconds). Should be less than simPing.alpaca-netcode8Package loss (0 = no packet loss, 1 = 100% packet loss). alpaca-netcode7The game is broken into discrete ticks starting from 0.*alpaca-netcode,How many missing inputs to request at a time+alpaca-netcode*TODO I need some proper logging mechanism.,alpaca-netcodeConvert a list of maps to a datastructure that is more compact when serialized by flat. This is more compact assuming that many subsequent maps have the same key set.-alpaca-netcodeInverse of toCompactMaps.alpaca-netcode Send functionalpaca-netcodeReceive function (blocking)alpaca-netcodeSimulated pingjitterpacketloss[0-1]alpaca-netcodeNew send and receive functions./01)('2&34 56*+7.8,-None#$'(/258:<=>? 9alpaca-netcodereturns (off, drift) sutch that serverTime = (drift * clientTime) + offset:alpaca-netcode!Initialize clock synchronization.:alpaca-netcode$Tick time (time per tick in seconds)alpaca-netcode0Get the current time from the system in seconds.alpaca-netcodeReturns: Given some  extraTime=, Estimate the tick on the server when a message sent at now + extraTime8 is received by the server plus some extraTime time.Record a clock sync event. Given a heartbeat meassge, this is: client send time, server receive time, client receive (of the heart beat response) time)analytics returns:PingEstimated error from the server clock. This error occurs when we've committed to some time samples then realize that our measurements are off. Instead of immediately correcting, we simply dilate time (speeding up a bit or slowing down a bit) until the "effective" clock is corrected (see min/maxTimeDilation). On till corrected, our time estimates differ from what we really think the time is on the server, and that difference is the "estimated error". Specifically `error = servertime - effective time` ;<=>?@ABCD9:None #$'(/258:<=>?] alpaca-netcode*Configuration options specific to clients.alpaca-netcode(Tick rate (ticks per second). Typically 30 or 60. Must be the same across all clients and the server. Packet rate and hence network bandwidth will scale linearly with this the tick rate.alpaca-netcodeAdd this constant amount of latency (in seconds) to this client's inputs. A good value is 0.03 or something between 0 and 0.1. May differ between clients.Too high of a value and the player will get annoyed at the extra input latency. On the other hand, a higher value means less miss-predictions of other clients. In the extreme case, set to something higher than ping, there will be no miss predictions: all clients will receive inputs before rendering the corresponding tick.alpaca-netcode2Maximum number of ticks to predict when sampling.  uses ccTickRate / 2. If the client is this many ticks behind the current tick, it will simply stop at an earlier tick. You may want to scale this value along with the tick rate. May differ between clients.alpaca-netcodeIf the client's latest known authoritative world is this many ticks behind the current tick, no prediction will be done at all when sampling.  uses ccTickRate * 3. Useful because want to save CPU cycles for catching up with the server. You may want to scale this value along with the tick rate. May differ between clients.alpaca-netcode>When submitting inputs to the server, we also send a copy of ccSubmitInputDuplication many recently submitted inputs in order to mittigate the effect for dropped packets.  uses 15.alpaca-netcode+A Client. You'll generally obtain this via .alpaca-netcode The client's PlayerIdalpaca-netcodeSample the world state. First, This will estimate the current tick based on ping and clock synchronization with the server. Then, the world state will be rollback and inputs replayed as necessary. This returns:New authoritative world states in chronological order since the last sample time. These world states are the True world states at each tick. This list will be empty if no new authoritative world states have been derived since that last call to this sample function. Though it's often simpler to just use the predicted world state, you can use these authoritative world states to render output when you're not willing to miss-predict but are willing to have greater latency. If the client has been stopped, this will be an empty list.The predicted current world state. This extrapolates past the latest know authoritative world state by assuming no user inputs have changed (unless otherwise known e.g. our own player's inputs are known). If the client has been stopped, this will return the last predicted world.alpaca-netcodeSet the client's current input.alpaca-netcodeStop the client.alpaca-netcodeSample the current world state.. First, This will estimate the current tick based on ping and clock synchronization with the server. Then, this extrapolates past the latest know authoritative world state by assuming no user inputs have changed (unless otherwise known e.g. our own player's inputs are known). If the client has been stopped, this will return the last predicted world.alpaca-netcodeSensible defaults for  ClientConfig based on the tick rate.alpaca-netcodeStart a client. This blocks until the initial handshake with the server is finished.alpaca-netcodeTick rate (ticks per second). Must be the same across all clients and the server. Packet rate and hence network bandwidth will scale linearly with this the tick rate.alpaca-netcodeFunction to send messages to the server. The underlying communication protocol need only guarantee data integrity but is otherwise free to drop and reorder packets. Typically this is backed by a UDP socket.alpaca-netcodeBlocking function to receive messages from the server. Has the same reliability requirements as the send function.alpaca-netcodeOptional simulation of network conditions. In production this should be E. May differ between clients.alpaca-netcodeThe  works well for most cases.alpaca-netcodeInitial input for new players. Must be the same across all clients and the server. See .alpaca-netcode9Initial world state. Must be the same across all clients.alpaca-netcodeA deterministic stepping function (for a single tick). Must be the same across all clients and the server. See . None#$'(/258:<=>?$alpaca-netcode-Configuration options specific to the server.alpaca-netcode(Tick rate (ticks per second). Typically 30 or 60. Must be the same across all clients and the server. Packet rate and hence network bandwidth will scale linearly with this the tick rate.alpaca-netcodeSeconds of not receiving packets from a client before disconnecting that client. alpaca-netcodeSensible defaults for  ServerConfig based on the tick rate.!alpaca-netcodeRun a server for a single game. This will block until the game ends, specifically when all players have disconnected. alpaca-netcode(Tick rate (ticks per second). Typically 30 or 60. Must be the same across all clients and the server. Packet rate and hence network bandwidth will scale linearly with this the tick rate.!alpaca-netcodeFunction to send messages to clients. The underlying communication protocol need only guarantee data integrity but is otherwise free to drop and reorder packets. Typically this is backed by a UDP socket.alpaca-netcodeBlocking function to receive messages from the clients. Has the same reliability requirements as the send function.alpaca-netcodeOptional simulation of network conditions. In production this should be E. May differ between clients.alpaca-netcodeThe   works well for most cases.alpaca-netcodeInitial input for new players. Must be the same across all clients and the server. See . !None#$'(/258:<=>?)"alpaca-netcodeStart a client. This blocks until the initial handshake with the server is finished.#alpaca-netcodeRun a server for a single game. This will block until the game ends, specifically when all players have disconnected."alpaca-netcode*The server's host name or IP address e.g.  "localhost".alpaca-netcodeThe server's port number e.g. "8111".alpaca-netcodeOptional simulation of network conditions. In production this should be E. May differ between clients.alpaca-netcodeThe  works well for most cases.alpaca-netcodeInitial input for new players. Must be the same across all clients and the server. See .alpaca-netcode9Initial world state. Must be the same across all clients.alpaca-netcodeA deterministic stepping function (for a single tick). Must be the same across all clients and the server. See .#alpaca-netcodeThe server's port number e.g. "8111".alpaca-netcodeOptional simulation of network conditions. In production this should be E.alpaca-netcodeThe   works well for most cases.alpaca-netcodeInitial input for new players. Must be the same across all clients and the server.$  !"#$#! "   None#$'(/258:<=>?8R$alpaca-netcodeStart a client. This blocks until the initial handshake with the server is finished. You must call . on the returned client to submit new inputs. Think of world as shared state between all clients. Alpaca NetCode takes care of synchronizing and predicting the world state across all clients. Additionally, clock synchronization is done with the server and the "current" tick is decided for you when sampling with .Typical usage looks like this:  main :: IO () main = do myClient <- runClient "localhost" "8111" 30 myInput0 myWorld0 worldStep let myPlayerId = clientPlayerId myClient mainGameLoop $ do myInput <- pollInput -- Poll inputs from some other library clientSetInput myClient -- Push inputs to Alpaca NetCode world <- clientSample -- Sample the current (predicted) world renderWorld myPlayerId world -- Render the world -- You're free to do IO and maintain state local to the client. return (gameIsOver world) -- Return True to keep looping clientStop myClient -- Given data World = World { .. } data Input = Input { .. } deriving (Generic, Eq, Flat) myWorld0 :: World gameIsOver :: World -> Bool myInput0 :: Input worldStep :: Map PlayerId Input -> Tick -> World -> World renderWorld :: PlayerId -> World -> IO () pollInput :: IO Input mainGameLoop :: IO Bool -> IO () %alpaca-netcodeRun a server for a single game. This will block until the game ends, specifically when all players have disconnected.$alpaca-netcode*The server's host name or IP address e.g.  "localhost".alpaca-netcodeThe server's port number e.g. "8111".alpaca-netcode(Tick rate (ticks per second). Typically 30 or 60. Must be the same across all clients and the server. Packet rate and hence network bandwidth will scale linearly with the tick rate.alpaca-netcodeInitial input for new players. Must be the same across all clients and the server.Note that the client and server do input "prediction" by assuming input1s do not change. It is important to design your input0 type accordingly. For example, Do NOT store a Bool> indicating that a button has been clicked. Instead, store a Bool indicating if that button is currently held down. Then, store enough information in the world state to identify a click.alpaca-netcode9Initial world state. Must be the same across all clients.alpaca-netcodeA deterministic stepping function (for a single tick). In practice you can choose to use whatever monad stack within as long as you (un)wrap into a pure function e.g. you can use ST as long as you wrap it in runST=. Must be the same across all clients and the server. Takes:a map from PlayerId to current input. You can use the key set as the set of all connected players.current game tick.previous tick's world state.It is important that this is deterministic else clients' states will diverge. Beware of floating point non-determinism!%alpaca-netcodeThe server's port number e.g. "8111".alpaca-netcode(Tick rate (ticks per second). Typically 30 or 60. Must be the same across all clients and the server. Packet rate and hence network bandwidth will scale linearly with the tick rate.alpaca-netcodeInitial input for new players. Must be the same across all clients and the server. $%%$          !""#$%&'()*+,-./01233456789:;<=>>?@ABCDEFGHIalpaca-netcode-0.1.0.0-inplaceAlpaca.NetCode.AdvancedAlpaca.NetCodeAlpaca.NetCode.Internal.Common!Alpaca.NetCode.Internal.ClockSyncAlpaca.NetCode.Internal.Client runClientAlpaca.NetCode.Internal.Servernetwork-3.1.2.1-75543caf37329a1fa2bf2f3d24fe745947332f4da9bdd59ed55b922b08013e35Network.Socket.InfoHostName ServiceNameNetMsgSimNetConditionssimPing simJittersimPackageLossPlayerId unPlayerIdTick ClientConfig ccTickRateccFixedInputLatencyccMaxPredictionTicksccResyncThresholdTicksccSubmitInputDuplicationClientclientPlayerId clientSample'clientSetInput clientStop clientSampledefaultClientConfigrunClientWith' ServerConfig scTickRatescClientTimeoutdefaultServerConfigrunServerWith' runClientWith runServerWith runServer Msg_HeartbeatMsg_HeartbeatResponse Msg_AuthInput Msg_HintInputmaxRequestAuthInputs debugStrLn toCompactMapsfromCompactMapssimulateNetConditions CompactMapsMsg_SubmitInputMsg_Ack Msg_Connected Msg_ConnectDurationTime bufferTime playCommoncsEstOffsetAndDriftinitializeClockSync ClockSynccsTimingSamples csPingSamples csLastSampleminTimeDilationmaxTimeDilation pingSamples timingSamples csEstPingbase GHC.MaybeNothing