Added a section on determinism

Docs/Architecture.md

@@ -531,7 +531,7 @@ Because of the minimal use of doubles, the simulation runs 5-10% slower in doubl
 
 The physics simulation is deterministic provided that:
 
-* The APIs that modify the simulation are called in exactly the same order. For example, bodies and constraints need to be added/removed/modified in exactly the same order so that the state at the beginning of a simulation step is exactly the same for both simulations.
+* The APIs that modify the simulation are called in exactly the same order. For example, bodies and constraints need to be added/removed/modified in exactly the same order so that the state at the beginning of a simulation step is exactly the same for both simulations ([exceptions](@ref sloppy-determinism)).
 * The same binary code is used to run the simulation. For example, when you run the simulation on Windows it doesn't matter if you have an AMD or Intel processor.
 
 If you want cross platform determinism then please turn on the CROSS_PLATFORM_DETERMINISTIC option in CMake. This will make the library approximately 8% slower but the simulation will be deterministic regardless of:
@@ -569,6 +569,15 @@ When synchronizing two simulations via a network, it is possible that a change t
 
 If you wish to share saved state between server and client, you need to ensure that all APIs that modify the state of the world are called in the exact same order. So if the client creates physics objects for player 1 then 2 and the server creates the objects for 2 then 1 you already have a problem (the body IDs will be different, which will render the save state snapshots incompatible). When rolling back a simulation, you'll also need to ensure that the BodyIDs are kept the same, so you need to remove/add the body from/to the physics system instead of destroy/re-create them or you need to create bodies with the same ID on both sides using [BodyInterface::CreateBodyWithID](@ref BodyInterface::CreateBodyWithID).
 
+# Being Sloppy While Still Being Deterministic {#sloppy-determinism}
+
+If you do things in the same order it is guaranteed to be deterministic, but if you know what you're doing you can take some liberties.
+E.g. doing `BodyA.SetFriction(...); BodyB.SetFriction(...);` or `BodyB.SetFriction(...); BodyA.SetFriction(...);` doesn't matter for determinism,
+the main thing you need to ensure is that when you do a PhysicsSystem::Update that the binary state is the same.
+Also adding body A then B is the same as B then A as long as the BodyIDs of A and B are consistent.
+For constraints, adding A then B or B then A is equivalent as long as ConstraintSettings::mConstraintPriority is unique per constraint so that it defines a consistent ordering (in this case all constraints in the system must have a unique number).
+Note though that PhysicsSystem::SaveState relies on the ordering of constraints, so you'll have to call Constraint::SaveState / Constraint::RestoreState directly yourself.
+
 # Working With Multiple Physics Systems {#working-with-multiple-physics-systems}
 
 You can create, simulate and interact with multiple PhysicsSystems at the same time provided that you do not share any objects (bodies, constraints) between the systems.