adding links

website/docs/developers/development-basics/networking.md

@@ -132,11 +132,11 @@ if (!hasComponent(world, Owned, eid)) return;
 ## Simple example
 
 Let's write a simple networked component example. You need some additional
-works to let your [component](<(./gameplay.md#prefab)>) support
+works to let your [component](./gameplay.md#entitydef-jsx-prefab) support
 network.
 
 Assume `Foo` component is defined with some properties, an
-[inflator](<(./gameplay.md#prefab)>) for it is written, and the
+[inflator](./gameplay.md#entitydef-jsx-prefab) for it is written, and the
 inflator is registered in the built-in
 [jsxInflators map](./gameplay.md#entitydef-jsx-prefab).
 
@@ -185,9 +185,9 @@ const jsxInflators: Required<{ [K in keyof JSXComponentData]: InflatorFn }> = {
 ...
 ```
 
-First, write a [prefab](./dev-client-gameplay.html#prefab) for `Foo` component
-with `networked` key, [which will be explained later](#entitydef-jsx-prefab),
-and register it in the built-in [`prefabs`](#prefab) map. This prefab is used
+First, write a [prefab](./gameplay.md#entitydef-jsx-prefab) for `Foo` component
+with `networked` key, [which will be explained later](./gameplay.md#entitydef-jsx-prefab),
+and register it in the built-in [`prefabs`](./gameplay.md#entitydef-jsx-prefab) map. This prefab is used
 to set up entities with associated components in both local and remote clients.
 
 ```typescript
@@ -250,7 +250,7 @@ component. Hubs Clients make their components data synched with remote clients.
 
 ### Prefab
 
-[Prefabs](./gameplay.md#prefab) for networked entities must be
+[Prefabs](./gameplay.md#entitydef-jsx-prefab) for networked entities must be
 registered in the built-in `prefabs` map defined in
 registered in the built-in `prefabs` map defined in
 [`src/prefabs/prefabs.ts`](https://github.com/mozilla/hubs/blob/master/src/prefabs/prefabs.ts),

website/docs/fundamentals/reskin-avatars.md

@@ -54,7 +54,7 @@ Hubs avatars are meant for VR, which means that you should work in real world un
 
 ![avatar height diagram](/img/avatarHeight.jpg)
 
-Files with the suffix _\_base_ refer to the most barebones, basic robot avatar template that can be used as a reference when creating new avatar models. Typically, the Blender workflow would be to either 'Link' or 'Append' the objects from [AvatarBot_base_for_export.blend](/Blender/AvatarBot) in order to use the existing armature (skeleton) and any animations that go along with it, using them as a basis for your own model that you would attach to it.
+Files with the suffix _\_base_ refer to the most barebones, basic robot avatar template that can be used as a reference when creating new avatar models. Typically, the Blender workflow would be to either 'Link' or 'Append' the objects from [AvatarBot_base_for_export.blend](https://github.com/j-conrad/hubs-avatar-pipelines/tree/master/Blender/AvatarBot) in order to use the existing armature (skeleton) and any animations that go along with it, using them as a basis for your own model that you would attach to it.
 
 The armature is based largely upon the same hierarchy and naming conventions of the skeleton provided by [High Fidelity](https://docs.highfidelity.com/en/rc80/create/avatars/avatar-standards.html#skeleton). This also happens to have a similar structure to VRChat in terms of bone orientations.
 However, in our current implementation in Hubs, we have eliminated some of the bones within the hierarchy, namely the lower body and arm joints since we are not using any sort of inverse kinematics (IK) at the moment. This may change in future iterations.