fix links

docs/modules/ROOT/pages/jme3/features.adoc

@@ -280,7 +280,7 @@ a|OGG Vorbis music and sounds
 
 == Miscellaneous
 
-*  xref:jme3/advanced/application_states.adoc[Application States] and xref:jme3/advanced/custom_controls.adoc[Controls] to implement xref:jme3/advanced/update_loop.adoc[game logic]
+*  xref:core:app/state/application_states.adoc[Application States] and xref:jme3/advanced/custom_controls.adoc[Controls] to implement xref:jme3/advanced/update_loop.adoc[game logic]
 *  xref:jme3/advanced/cinematics.adoc[Cinematics and motion paths]
 *  xref:jme3/advanced/camera.adoc[Camera System]
 **  Normal or parallel view

docs/modules/contributions/pages/ai/jme3_ai.adoc

@@ -1,6 +1,6 @@
 = jMonkeyEngine Artificial Intelligence
-:revnumber: 2.0
-:revdate: 2020/07/15
+:revnumber: 2.1
+:revdate: 2020/07/24
 
 
 
@@ -84,7 +84,7 @@ CAUTION: Cell size has the greatest impact on your NavMesh. The smaller the cell
 TIP: Selecting the NavMesh node in the SceneExplorer will show the NavMesh in the Terrain Editor or SceneComposer view-port. If it doesn't show, with the NavMesh node selected, change the `Cull Hint` to `Never` in the `NavMesh - Properties` panel.
 
 === Procedural Method
-There are many ways to create a NavMesh. If you look at the constructor for the link:https://github.com/jMonkeyEngine/doc-examples/blob/master/src/com/jme3/examples/jme3ai/Jme3AI.java[Jme3AI.java] file, you will see I use a xref:jme3/advanced/application_states.adoc#baseappstate.adoc[BaseAppState] named link:https://github.com/jMonkeyEngine/doc-examples/blob/master/src/com/jme3/examples/jme3ai/ai/NavMeshState.java[NavMeshState.java] which creates a `generator` object and builds the `NavMesh` new every time the program is ran.
+There are many ways to create a NavMesh. If you look at the constructor for the link:https://github.com/jMonkeyEngine/doc-examples/blob/master/src/com/jme3/examples/jme3ai/Jme3AI.java[Jme3AI.java] file, you will see I use a xref:core:app/state/application_states.adoc#baseappstate[BaseAppState] named link:https://github.com/jMonkeyEngine/doc-examples/blob/master/src/com/jme3/examples/jme3ai/ai/NavMeshState.java[NavMeshState.java] which creates a `generator` object and builds the `NavMesh` new every time the program is ran.
 
 .Jme3AI constructor
 [source, java]
@@ -336,7 +336,7 @@ These are implementation decisions that are left up to you.
 
 === Loading the NavMesh
 
-In this tutorial example, the optimized mesh was exported as a geometry using the jMonkey binary format `.j3o`. Doing so means the loading of your `NavMeshes` is done the same way you load any model, by using the `AssetManager`. Once you load the `.j3o`, you grab its `Mesh` and create the `NavMesh` object to be passed to the link:https://github.com/jMonkeyEngine/doc-examples/blob/master/src/com/jme3/examples/jme3ai/ai/NavigationControl.java[NavigationControl] constructor. This tutorial uses a xref:jme3/advanced/application_states.adoc#baseappstate.adoc[BaseAppState] for model loading so access to the `Application` class is built in.
+In this tutorial example, the optimized mesh was exported as a geometry using the jMonkey binary format `.j3o`. Doing so means the loading of your `NavMeshes` is done the same way you load any model, by using the `AssetManager`. Once you load the `.j3o`, you grab its `Mesh` and create the `NavMesh` object to be passed to the link:https://github.com/jMonkeyEngine/doc-examples/blob/master/src/com/jme3/examples/jme3ai/ai/NavigationControl.java[NavigationControl] constructor. This tutorial uses a xref:core:app/state/application_states.adoc#baseappstate[BaseAppState] for model loading so access to the `Application` class is built in.
 
 [source, java]
 ----

docs/modules/core/pages/app/simpleapplication.adoc

@@ -11,7 +11,7 @@ SimpleApplication gives you access to standard game features, such as a scene gr
 
 [IMPORTANT]
 ====
-For each game, you (directly or indirectly) extend SimpleApplication exactly once as the central class. If you need access to any SimpleApplication features from another game class, make the other class extend xref:jme3/advanced/application_states.adoc[AbstractAppState] (don't extend SimpleApplication once more).
+For each game, you (directly or indirectly) extend SimpleApplication exactly once as the central class. If you need access to any SimpleApplication features from another game class, make the other class extend xref:app/state/application_states.adoc[AbstractAppState] (don't extend SimpleApplication once more).
 ====
 
 NOTE: The SimpleApplication class is undergoing changes. To understand how these changes may affect your projects and how to best prepare for them, see  xref:tutorials:beginner/hello_simpleapplication.adoc#the-future-of-simpleapplication[The Future of SimpleApplication] topic in the "`Hello SimpleApplication`" tutorial for beginners.
@@ -91,7 +91,7 @@ a|Use the xref:input/input_handling.adoc[inputManager] to configure your custom
 
 a|stateManager +
 getStateManager()
-a|You use the Application's state manager to activate xref:jme3/advanced/application_states.adoc[AppStates], such as xref:physics/physics.adoc[Physics].
+a|You use the Application's state manager to activate xref:app/state/application_states.adoc[AppStates], such as xref:physics/physics.adoc[Physics].
 
 |===
 [cols="25,75", options="header"]
@@ -216,11 +216,11 @@ a|SimpleApplication Interface
 a|Purpose
 
 a|public void simpleInitApp()
-a|Override this method to initialize the game scene. Here you load and create objects, attach Spatials to the rootNode, and bring everything in its starts position. See also xref:jme3/advanced/application_states.adoc[Application States] for best practices.
+a|Override this method to initialize the game scene. Here you load and create objects, attach Spatials to the rootNode, and bring everything in its starts position. See also xref:app/state/application_states.adoc[Application States] for best practices.
 
 a|public void simpleUpdate(float tpf)
 a|Override this method to hook into the xref:jme3/advanced/update_loop.adoc[update loop], all code you put here is repeated in a loop. Use this loop to poll the current game state and respond to changes, or to let the game mechanics generate encounters and initiate state changes. Use the float `tpf` as a factor to time actions relative to the _time per frame_ in seconds: `tpf` is large on slow PCs, and small on fast PCs. +
-For more info on how to hook into the update loop, see xref:jme3/advanced/application_states.adoc[Application States] and xref:jme3/advanced/custom_controls.adoc[Custom Controls].
+For more info on how to hook into the update loop, see xref:app/state/application_states.adoc[Application States] and xref:jme3/advanced/custom_controls.adoc[Custom Controls].
 
 a|public void simpleRender(RenderManager rm)
 a|*Optional:* Advanced developers can override this method if the need to modify the frameBuffer and scene graph directly.

docs/modules/core/pages/app/update_loop.adoc

@@ -1,6 +1,6 @@
 = Main Update Loop
-:revnumber: 2.0
-:revdate: 2020/07/15
+:revnumber: 2.1
+:revdate: 2020/07/24
 :keywords: basegame, control, input, init, keyinput, loop, states, state
 
 
@@ -14,12 +14,12 @@ To let you see the main update loop in context, understand that the SimpleApplic
 *  *Main Update Loop*
 ..  Input listeners respond to mouse clicks and keyboard presses – xref:input/input_handling.adoc[Input handling]
 ..  Update game state:
-...  Update overall game state – Execute xref:jme3/advanced/application_states.adoc[Application States]
+...  Update overall game state – Execute xref:app/state/application_states.adoc[Application States]
 ...  User code update – Execute `simpleUpdate()` method
 ...  Logical update of entities – Execute xref:jme3/advanced/custom_controls.adoc[Custom Controls]
 
 ..  Render audio and video
-...  xref:jme3/advanced/application_states.adoc[Application States] rendering.
+...  xref:app/state/application_states.adoc[Application States] rendering.
 ...  Scene rendering.
 ...  User code rendering – Execute `simpleRender()` method.
 
@@ -35,7 +35,7 @@ In a trivial xref:jme3/intermediate/simpleapplication.adoc[SimpleApplication] (s
 
 It's a best practice to modularize your game mechanics and spread out initialization and update loop code over several Java objects:
 
-*  Move modular code blocks from the `simpleInitApp()` method into xref:jme3/advanced/application_states.adoc[AppStates]. Attach AppStates to initialize custom subsets of "`one`" dungeon, and detach it when the player exits this "`dungeon`". +
+*  Move modular code blocks from the `simpleInitApp()` method into xref:app/state/application_states.adoc[AppStates]. Attach AppStates to initialize custom subsets of "`one`" dungeon, and detach it when the player exits this "`dungeon`". +
 Examples: Weather/sky audio and visuals, physics collision shapes, sub-rootnodes of individual dungeons including dungeon NPCs, etc.
-*  Move modular code blocks from the `simpleUpdate()` method into the update loops of xref:jme3/advanced/custom_controls.adoc[Custom Controls] to control individual entity behavior (NPCs), and into the update method of xref:jme3/advanced/application_states.adoc[AppStates] to control world events. +
+*  Move modular code blocks from the `simpleUpdate()` method into the update loops of xref:jme3/advanced/custom_controls.adoc[Custom Controls] to control individual entity behavior (NPCs), and into the update method of xref:app/state/application_states.adoc[AppStates] to control world events. +
 Examples: Weather behaviour, light behaviour, physics behaviour, individual NPC behaviour, trap behaviour, etc.

docs/modules/sdk/nav.adoc

@@ -40,7 +40,7 @@
 //*  <<sdk/attachment_bones#,Animation and Attachment Bones Editing>>
 ***  xref:filters.adoc[Post-Processor Filter Editor and Viewer]
 //*  <<sdk/blender#,Blender Importer>>
-***  xref:ROOT:jme3/advanced/application_states.adoc[Application States]
+***  xref:core:app/state/application_states.adoc[Application States]
 ***  xref:ROOT:jme3/advanced/custom_controls.adoc[Custom Controls]
 ***  xref:vehicle_creator.adoc[Vehicle Creator]
 ** Advanced Usage

docs/modules/tutorials/pages/beginner/hello_main_event_loop.adoc

@@ -1,7 +1,6 @@
 = jMonkeyEngine 3 Tutorial (4) - Hello Update Loop
-:author:
-:revnumber:
-:revdate: 2020/07/06
+:revnumber: 2.0
+:revdate: 2020/07/24
 :keywords: documentation, state, states, intro, beginner, control, loop
 
 
@@ -101,7 +100,7 @@ Here you change their properties to update the game state (repeatedly).
 ====
 Everything in a game happens either during initialization, or during the update loop. This means that these two methods grow very long over time. Follwo these two strategies to spread out init and update code over several modular Java classes:
 
-*  Move code blocks from the simpleInitApp() method to xref:ROOT:jme3/advanced/application_states.adoc[AppStates].
+*  Move code blocks from the simpleInitApp() method to xref:core:app/state/application_states.adoc[AppStates].
 *  Move code blocks from the simpleUpdate() method to xref:ROOT:jme3/advanced/custom_controls.adoc[Custom Controls].
 
 Keep this in mind for later when your application grows.
@@ -136,4 +135,4 @@ Now you are listening to the update loop, the "`heartbeat`" of the game, and you
 
 *See also:*
 
-*  Advanced jME3 developers use xref:ROOT:jme3/advanced/application_states.adoc[Application States] and xref:ROOT:jme3/advanced/custom_controls.adoc[Custom Controls] to implement game mechanics in their update loops. You will come across these topics again later when you proceed to more advanced documentation.
+*  Advanced jME3 developers use xref:core:app/state/application_states.adoc[Application States] and xref:ROOT:jme3/advanced/custom_controls.adoc[Custom Controls] to implement game mechanics in their update loops. You will come across these topics again later when you proceed to more advanced documentation.

docs/modules/tutorials/pages/beginner/hello_simpleapplication.adoc

@@ -1,7 +1,6 @@
 = jMonkeyEngine 3 Tutorial (1) - Hello SimpleApplication
-:author:
-:revnumber:
-:revdate: 2020/07/06
+:revnumber: 2.0
+:revdate: 2020/07/24
 :keywords: beginner, intro, documentation, init, simpleapplication, basegame
 
 
@@ -261,7 +260,7 @@ public class MyGame extends SimpleApplication {
 }
 ----
 
-Then have all logic implemented in xref:ROOT:jme3/advanced/application_states.adoc[AppStates] and your SimpleApplication will never change much, except when you want to add a bootstrap AppState (or maybe you can have an AppState that manages AppStates...), SimpleApplication is just the list of states you are using.
+Then have all logic implemented in xref:core:app/state/application_states.adoc[AppStates] and your SimpleApplication will never change much, except when you want to add a bootstrap AppState (or maybe you can have an AppState that manages AppStates...), SimpleApplication is just the list of states you are using.
 
 In future versions, all the code in SimpleApplication will be refactored in AppStates (InputHandlingState, RenderAppState, whatever) and you will decide what you want to use. However, for legacy sake we kept the code as is for now.
 

docs/modules/tutorials/pages/concepts/best_practices.adoc

@@ -192,7 +192,7 @@ Example: Players have *methods* such as `walk(), addGold(), getHealth(), pickUpI
 *Follow the Best Practice:* In general, use composition over inheritance and keep what an entity does (behaviour system) separate from what this entity is (attributes).
 
 *  Use `xref:ROOT:jme3/advanced/spatial.adoc[setUserData()]` to add custom attributes to Spatials.
-*  Use xref:ROOT:jme3/advanced/custom_controls.adoc[Controls] and xref:ROOT:jme3/advanced/application_states.adoc[Application States] to define custom behaviour systems.
+*  Use xref:ROOT:jme3/advanced/custom_controls.adoc[Controls] and xref:core:app/state/application_states.adoc[Application States] to define custom behaviour systems.
 ====
 
 
@@ -207,7 +207,7 @@ If your game is even more complex, you may want to learn about "real" Entity Sys
 
 === The Smart Way to Access Game Features
 
-xref:ROOT:jme3/intermediate/simpleapplication.adoc[SimpleApplication] gives you access to game features such as a the rootNode, assetManager, guiNode, inputManager, audioManager, physicsSpace, viewPort, and the camera. But what if you need this access also from another class? Don't extend SimpleApplication a second time, and don't pass around tons of object references in constructors! Needing access to application level objects is a sign that this class should be designed as an xref:ROOT:jme3/advanced/application_states.adoc[AppState] (read details there).
+xref:ROOT:jme3/intermediate/simpleapplication.adoc[SimpleApplication] gives you access to game features such as a the rootNode, assetManager, guiNode, inputManager, audioManager, physicsSpace, viewPort, and the camera. But what if you need this access also from another class? Don't extend SimpleApplication a second time, and don't pass around tons of object references in constructors! Needing access to application level objects is a sign that this class should be designed as an xref:core:app/state/application_states.adoc[AppState] (read details there).
 
 An AppState has access to all game features in the SimpleApplication via the `this.app` and `this.stateManager` objects. Examples:
 
@@ -223,7 +223,7 @@ this.app.getRootNode().attachChild( sky );
 
 As your SimpleApplication-based game grows more advanced, you find yourself putting more and more interactions in the `simpleUpdate()` loop, and your `simpleInitApp()` methods grows longer and longer. It's a best practice to move blocks of game mechanics into reusable component classes of their own. In jME3, these resuable classes are called `Controls` and `AppStates`.
 
-*  Use xref:ROOT:jme3/advanced/application_states.adoc[AppStates] to implement _global game mechanics_.
+*  Use xref:core:app/state/application_states.adoc[AppStates] to implement _global game mechanics_.
 **  Each AppState calls its own `initialize()` and `cleanup()` methods when it is attached to or detached from the game.
 **  Each AppState runs its own _thread-safe_ `update()` loop that hooks into the main `simpleUpdate()` loop.
 **  You specify what happens if an AppState is paused/unpaused.
@@ -255,7 +255,7 @@ AppStates and Controls are extensions to a SimpleApplication. They are your modu
 ====
 
 
-Read all about xref:ROOT:jme3/advanced/custom_controls.adoc[Custom Controls] and xref:ROOT:jme3/advanced/application_states.adoc[Application States] here.
+Read all about xref:ROOT:jme3/advanced/custom_controls.adoc[Custom Controls] and xref:core:app/state/application_states.adoc[Application States] here.
 
 
 === Optimize Application Performance

docs/modules/tutorials/pages/concepts/faq.adoc

@@ -42,7 +42,7 @@ You should break down your application logic into components by spreading it out
 
 *Learn more:*
 
-* xref:ROOT:jme3/advanced/application_states.adoc[Application States]
+* xref:core:app/state/application_states.adoc[Application States]
 
 
 === How do I pause/unpause a game?
@@ -51,7 +51,7 @@ You split up your application into several AppStates and implement the setEnable
 
 *Learn more:*
 
-* xref:ROOT:jme3/advanced/application_states.adoc[Application States]
+* xref:core:app/state/application_states.adoc[Application States]
 
 
 === How do I disable logger output to the console?
@@ -472,7 +472,7 @@ Use Controls to define the behaviour of types of Spatials. Use Application State
 * xref:beginner/hello_main_event_loop.adoc[Hello Loop]
 * xref:ROOT:jme3/advanced/update_loop.adoc[Update Loop]
 * xref:ROOT:jme3/advanced/custom_controls.adoc[Custom Controls]
-* xref:ROOT:jme3/advanced/application_states.adoc[Application States]
+* xref:core:app/state/application_states.adoc[Application States]
 * xref:ROOT:jme3/advanced/cinematics.adoc[Cinematics]