Features and Restrictions in the v1.0 Release

1. Use the uLink release included in the LODgame. It includes a critical bugfix for uStream, not published in other uLink releases (yet). If you want to use uStream for another game make sure to copy the included uLink.dll.
2. You have to start uStream at the same time as the game server. The game server will try to connect during 15 seconds (default uLink value that can be configured). But most important: uStream can not cope with a game server restart. If the game server is stopped, uStream will be stopped too.
3. Multicast RPC = sending RPCs to a list of players can be used. This feature is part of uLink 1.2 and works with and without uStream. uStream will handle this kind of network traffic from the game server to the players (clients).
4. AOI-calculations for state synch only, not AOI- RPCs (name includes a plus sign). AOI calculations for RPC will probably be included in the next uStream release. It has top priority.
5. Broadcast is done by sending RPCs to RPCMode.Others.
6. The operator can configure the AOI-radius for all payers = one value. The feature called “track radius” (different AOI for each player) is not included in uLink 1.2 or this version of uStream.
7. You have to use state synch for at least one network instantiated object, otherwise nothing will be sent to clients, not even RPCs. This is usually not a problem as long as the game server does send state synch to the player’s character since this objects is always inside the AOI for the player...
8. Does not handle separate owner state synch. Avoid this feature in uLink.
9. Tracks radius only, no bandwidth per player check or limits has been implemented (yet). If all players enters the same small area in the game, the server will have to work very hard when broadcasting all objects’ states to all players.
10. The client needs to deactivate (or at lest not render) objects outside the tracking radius. And the visible radius for the client need to be smaller than the area-of-interest radius because otherwise objects would be able to disappear or appear inside the line-of-sight. It is important that the client will be aware of objects and get state synch and RPC for these objects a little while before they enter the the line-of-sight.
11. The AOI calculations in uStream runs with a frequency. If a game has fast moving network instantiated objects, this frequency has to be high. But if fast moving objects are not network instantiated, like the snowballs in the Snowbox demo game, the frequency can be a bit lower. Set the frequency value based on the fastest moving network instantiated object.
    A too high frequency will increase the CPU on the hosting server, A too low frequency will make fast moving game objects moving towards a player appear “inside” the line of sight for that player. Please test the game with the two fastest game objects available moving towards each other, this is the best way to ensure that the frequency is high enough.
12. The RPC buffer is sent by uStream to new players without any AOI calculations. Every client will be informed of all “available” objects in this way. This makes it important for the client to keep objects outside the area of interest deactivated (at least not rendered) until the first state synch is received. Otherwise the client would show objects outside the area of interest standing at the wrong (initial) position.
13. Buffered application RPCs will not work (yet). Only the standard internal uLink Instantiate RPCs can be stored in the buffer and handled correctly by uStream. Trying to remove RPCs from the buffer will not work. The buffer is handled by uStream and can only work with uLink internal Instantiate RPCs.
14. NetworkView.SetViewID() will not work. Use ulink.Network.Instantiate() or manual viewIDs instead.
15. Sending RPC from the game server to uLink.RPCMode.server will not work. Maybe it will work after a round-trip to uStream, but this has not been tested (yet). Please avoid it for now.
16. Area of interest calculations can not be turned off completely. But the calculations will be very fast if you set the radius to 0.
17. Handovers of players is not working in this release. This means you can not transfer a player’s server side (character) state between game servers. But P2P connections between game servers using uLink is working and redirecting from another uLink game server to uStream is working (without transferring any server side state).
18. Player UDP ports starts at 22000. This is not configurable at the moment. The firewall of the server needs to be open for UDP port range 22000 to (22000 + max number of players).
19. The default value for maximum number of players is 1000. uStream will send a uLink error code with connection denied to player nr 1001 when he tries to connect. This max value is configurable in the config file for uStream. The true maximum number of players is the number of available ports on the server, since every player gets a unique port number on the server. On a “clean” dedicated server there are around 65000 free ports, but this extreme number of players has not been tested...
20. uLink_OnConnectedToUStream() does not exist in uLink 1.2. It will be included a future uLink version. For now, uStream game server developers will have to cope with using uLink_OnConnectedToPikkoServer(). uStream is not PikkoServer, so this will of course change in future versions on uLink.

Planned Future Features

We are planning to remove all the restrictions listed above and in addition we have a few planned features listed here.

• Layers. Will make it possible to separate teams, invisible characters and fast moving objects. Another use case for layers is the radar image or a mini-map.
  Every player is “listening” to one or more layers. Every layer can have a unique value for update interval and a different aoi_calculation_interval_ms and area_of_interest_radius.
• Two or maybe three different AOI-radius. One for close objects that will be updated with a high frequency, an second for nearby objects with a lower update frequency and a third with a very low update frequency.
• Linux release. Probably after the Unity game server and uLink will be officially released on Linux.
• Script the start of uStream from within the game server. Then it will be possible to write a Start() method in a script in the cell server that start uStream). This will make it easier to start the game server that needs uStream from a boot script in Windows or from uZone.
• Widows installer and exe-file for starting. Remove start.bat.