Distributed network

programming/networking/distributed/distributed-object.rst

@@ -14,6 +14,9 @@ when created, they will automatically be distributed to other clients.
 To define who will see DOs, they can be set in specific zones. Zones are just
 numbers that have to be set on a DO and a client needs to show interest in them
 to be able to see objects in them.
+In addition, Objects that a client doesn't own can't be updated by that client.
+Only the objects owner can change fields in it. Except if they are specially
+marked with the clsend keyword in the DC definition file.
 
 Most DOs will have a basic class definition for example Foo and an AI definition
 which can be called FooAI.

programming/networking/distributed/index.rst

@@ -17,20 +17,15 @@ you when using the system. To not repeat them every time or for you to look up
 whenever you stumble upon one, we'll list them here.
 
 | DO = Distributed Object
+| DOG = Distributed Object Global
 | doId = Distributed Object Identifier
 | AI = Artificial Intelligence
-| UD = Uber Dog
+| UD = Uber DOG
 | OV = Owner View
 | DC = Distributed Class
 | SR = Server Repository
 | CR = Client Repository
 
-.. note::
-   The following parts which are rarely used are not documented yet.
-
-   * Uber Dog servers and objects
-   * Owner View objects
-
 .. toctree::
    :maxdepth: 2
 
@@ -42,7 +37,10 @@ whenever you stumble upon one, we'll list them here.
    dc-definition-files
    client-created-objects
    ai-created-objects
+   uber-dogs
+   owner-view
    time-manager
+   related-object-manager
    distributed-object
    distributed-node
    distributed-smooth-node

programming/networking/distributed/owner-view.rst

@@ -0,0 +1,16 @@
+.. _owner-view:
+
+Owner view
+==========
+
+.. note::
+   Currently this type of object is not directly available in Panda3D. It is
+   implemented in the former prject developed by Disney and can also be used
+   with available open source extensions like the Astron suite.
+
+Owner view (OV) objects are special implementations for DOs that are created and
+used on the clients. OVs are very similar to AIs in that they handle game logic
+but instead of being implemented on the server, they are introduced on the
+client side. That way clients can directly update fields in these objects.
+To do so, the respective calls must be marked with the ownsend tag in the dc
+definition file.

programming/networking/distributed/related-object-manager.rst

@@ -0,0 +1,27 @@
+.. _related-object-manager:
+
+Related Object Manager
+======================
+
+The related object manager is a handy class that can be utilized to wait for the
+creation of multiple DOs. You simply pass the IDs of the objects you want to
+wait for as a list and a callback method. If all objects are successfully
+created, the callback method will be called.
+This manager is readily available in repository based classes like the
+Client Repository.
+
+
+.. code-block:: python
+
+   # Use the client repositories manager
+   cr.relatedObjectMgr.requestObjects(
+       [
+        playerDoId,
+        levelDoId,
+        someOtherObjectDoId
+       ],
+       allCallback = self.allObjectsManifested)
+
+   def allObjectsManifested(self, allObjects):
+       # allObjects now contains the DOs for the player, level
+       # and someOtherObject

programming/networking/distributed/uber-dogs.rst

@@ -0,0 +1,21 @@
+.. _uber-dogs:
+
+Uber DOGS
+=========
+
+The uber distributed object globals are special objects which are used for game
+global objects. These are similar to AI ones but are not dedicated to specific
+zones, have a hardcoded doID and with that are directly acessible in the client
+without the need for discovering them first like you'd have to do for other DOs.
+
+Compared to other DOs, the DOGs do not store persistent data. Instead, they are
+usually used for sending calls to request a server to run specific procedures.
+These calls, done through the DOGs, usually also don't require the user to be
+authenticated. This way public RPC like APIs can best be implemented using them
+as well as them being a good choice for implementing the client authentication
+request logic.
+
+The setup of a generic UD server is similar to that of an AI one. It only
+differs in the used abbreviation (UD instead of AI) and the applications
+specific implementation. Due to that, check the :ref:`ai-repositories` chapter
+for further information.

programming/networking/index.rst

@@ -8,9 +8,6 @@ stream based API, and a higher level distributed object API. The documentation
 in this section assumes some familiarity with the basic concepts of networking
 in general, and the IP protocol in particular.
 
-The documentation on these features is still in development. Read the forums
-for the most up-to-date information.
-
 
 .. toctree::
    :maxdepth: 2