remove old content

docs/modules/ROOT/pages/jme3/contributions/entitysystem/usage.adoc

@@ -1,6 +1,6 @@
 = JMonkey Entity System Usage
-:author: 
-:revnumber: 
+:author:
+:revnumber:
 :revdate: 2016/03/17 20:48
 :relfileprefix: ../../../
 :imagesdir: ../../..
@@ -24,14 +24,14 @@ EntitySystem entitySystem = new EntitySystem(new DefaultEntityData());
 ----
 
 public class MovementComponent extends Component {
- 
+
     private Vector3f movement;
-    
+
     public MovementComponent(Vector3f movement)
     {
         this.movement=movement;
     }
-    
+
     public Vector3f getMovement()
     {
         return movement;
@@ -47,13 +47,13 @@ public class MovementComponent extends Component {
 
 Component[] components = new Component[6];
 
-components[0] = new VisualRepComponent("Models/HoverTank/Tank2.mesh.xml");     
+components[0] = new VisualRepComponent("Models/HoverTank/Tank2.mesh.xml");
 components[1] = new PositionComponent(v3f,new Quaternion());
 components[2] = new MovementComponent(Vector3f.ZERO);
 components[3] = new InSceneComponent(true);
 components[4] = new PlayerComponent();
 components[5] = new CollisionComponent(5);
-       
+
 entitySystem.newEntity(components);
 
 ----
@@ -127,5 +127,5 @@ entity.destroy();
 Use an EntityControl class which is able to display Entitys with visual components.
 In an AppState with a Map containing Entities and and EntitiyControls they can be merged together and updated.
 
-Have a look at the example:
-link:http://peeeq.de/uploads/ogerlord/EntityTest.rar[http://peeeq.de/uploads/ogerlord/EntityTest.rar]
+//Have a look at the example:
+//link:http://peeeq.de/uploads/ogerlord/EntityTest.rar[http://peeeq.de/uploads/ogerlord/EntityTest.rar]

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

@@ -1,95 +0,0 @@
-= 在Eclipse中集成jME3
-:author:
-:revnumber:
-:revdate: 2016/03/17 20:48
-:keywords: documentation, install, eclipse
-:relfileprefix: ../
-:imagesdir: ..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-我们建议你使用jMonkeyEngine SDK来开发jMonkeyEngine3项目。
-
-或者，你可以使用你喜好的IDE：本教程将介绍如何下载并安装最新版的jMonkeyEngine 3，并与Eclipse IDE集成。jMonkeyEngine 3与<<jme3/setting_up_netbeans_and_jme3#,NetBeans IDE>>同样可以集成。
-
-
-== 下载jME3
-
-下载最新的jMonkeyEngine3稳定版JAR包。
-
-.  从 link:http://updates.jmonkeyengine.org/stable/3.0/engine[http://updates.jmonkeyengine.org/stable/3.0/engine] 下载最新的压缩包(不出意外应该是jME3_2014-06-12.zip)。
-.  将其解压到你的工作目录($HOME)下，保存到`jME3_2014-xx-xx`文件夹中，你将会看到下列文件及文件夹：
-**  `lib/` – 编译好的jMonkeyEngine运行库。(重要！不要移动这个文件夹！)
-**  `opt/` – 可选运行库，包含android、ios、jogl、gluegen、OpenAL、bullet等JAR包和DLL文件，用户自选使用。(可选)
-**  `javadoc/` – jME3 API文档。(可选)
-**  `source/` – jME3源代码。(可选)
-**  `TestChooser.exe` – 运行这个程序，可以预览大量的DEMO。(可选)
-
-
-
-image::jme3/1_jme3_2014_06_12_zip.png[1_jme3_2014_06_12_zip.png,width="800",height="",align="center"]
-
-
-
-== 新建游戏项目
-
-*  在Eclipse的菜单中，选择 File &gt; New &gt; Java Project
-*  项目名：HelloJME3
-*  点击Finish
-
-
-image::jme3/2_create_hellojme3_project.png[2_create_hellojme3_project.png,width="800",height="",align="center"]
-
-项目创建完毕，即可在Package视图中看到这个项目。
-
-
-== 添加jME3依赖
-
-你的项目依赖于jMonkeyEngine库文件，需要知道JME3的JAR包都在什么位置。
-
-*  右键单击项目名，在弹出菜单中选择`Build Path &gt; Configure Build Path..`
-
-
-image::jme3/3_configure_build_path.png[3_configure_build_path.png,width="643",height="",align="center"]
-
-
-*  打开项目配置窗口后，选择`Java Build Path &gt; Libraries &gt; Add External JARs..`
-
-
-image::jme3/4_add_external_jars.png[4_add_external_jars.png,width="751",height="",align="center"]
-
-
-*  在“JAR selection对话框中，打开`$HOME/jME3_2012-xx-xx`文件夹
-*  选中`lib`文件夹中所有的JAR文件，然后点击“Open
-
-
-image::jme3/5_jar_selection.png[5_jar_selection.png,width="563",height="",align="center"]
-
-
-现在所有必要的JAR包都已经添加到了项目的classpath，并显示在在Referenced Libraries中。至于每个JAR文件的详细介绍，请查阅<<jme3/jme3_source_structure#structure_of_jmonkeyengine3_jars,jME3 JAR文件说明>>。
-
-
-== 添加资源
-
-在classpath中创建一个assets文件夹，确保jME3的资源管理器可以正确访问项目资源。
-
-.  打开项目配置(Project Properties)窗口
-.  选择Java Build Path
-.  在Source标签页下点击“Add folder
-.  添加Assets文件夹
-
-
-image::jme3/6_new_source_folder.png[6_new_source_folder.png,width="525",height="",align="center"]
-
-
-
-== 编写一个简单的应用程序
-
-.  在项目中新建一个package，例如“hello
-.  在hello包中新建一个类，命名为“MyGame，继承于`com.jme3.app.SimpleApplication`
-
-
-image::jme3/7_create_mygame.png[7_create_mygame.png,width="556",height="",align="center"]
-
-
-然后你可以接着开发<<jme3/beginner/hello_simpleapplication_zh#,你的第一个jme3应用程序>>了！

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

@@ -1,10 +0,0 @@
-= users_guide
-:author: 
-:revnumber: 
-:revdate: 2016/03/17 20:48
-:relfileprefix: ../
-:imagesdir: ..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-link:http://jmonkeyengine.org/2011/02/25/publishing-deal-signed-with-packt-for-jme3-beginners-book/[Publishing deal signed with Packt for jME3 Beginner’s Book]

docs/modules/ROOT/pages/spidermonkey.adoc

@@ -1,63 +0,0 @@
-= SpiderMonkey (Deprecated!)
-:author:
-:revnumber:
-:revdate: 2016/03/17 20:48
-:keywords: documentation, network
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-
-[WARNING]
-====
-This article covers a deprecated +++<abbr title="Application Programming Interface">API</abbr>+++! See <<jme3/advanced/networking#,networking>> for current documentation. See <<spidermonkey/migration#,migration>> for migration instructions.
-====
-
-SpiderMonkey is a high performance Java networking engine, aiming to provide game developers a stable and efficient networking system. It's also perfectly capable of doing anything other than game networking. SpiderMonkey is part of jME3 and can be found in the src/networking directory.
-*Author:* Lars 'Levia' Wesselius+
-*License:* link:http://www.opensource.org/licenses/bsd-license.php[New BSD license]+
-*Blog:* link:http://codeninja.me/tag/spidermonkey/[http://codeninja.me/tag/spidermonkey/]+
-*Forum:* link:http://jmonkeyengine.org/groups/spidermonkey/forum/[http://jmonkeyengine.org/groups/spidermonkey/forum/]+
-A tutorial trail can be found below, and below that all different aspects of SpiderMonkey are explained. These tutorials are to be updated upon SVN HEAD, so if new features are added in SVN, you should tutorials arriving of them soon.
-
-
-== Tutorial trail
-
-.  <<spidermonkey/tutorial/connection#,Connections>>
-.  <<spidermonkey/tutorial/sending_and_receiving_messages#,Sending and receiving messages>>
-.  <<spidermonkey/tutorial/serializing#,Serialization>>
-.  <<spidermonkey/tutorial/compression#,Compression>>
-.  <<spidermonkey/tutorial/services#,Services>>
-.  <<spidermonkey/tutorial/streaming#,Streaming>>
-
-
-=== Explanation of SpiderMonkey's inner workings
-
-
-== Connection protocols
-
-SpiderMonkey supports both TCP and UDP, and is also extendable to provide others. Possible future protocols may be RUDP, UDP Lite, and SCTP. SCTP will be added in Java 7, and will therefore probably added to SpiderMonkey after it's released. Please note that the language level of SpiderMonkey is 1.5, so it will definitely not be part of the standard +++<abbr title="Application Programming Interface">API</abbr>+++ for a few years.
-
-
-== Clients
-
-SpiderMonkey creates two connections by default. A TCP connection for a reliable connection, and an UDP 'connection' footnote:[UDP is connectionless] for fast message handling. A problem arises here: these two connections mean that even though there are two connections, there's only one client to represent both the connections. In SpiderMonkey you don't have to worry about that. The server has a client manager which deals with this problem. Upon connecting, clients have to send a ClientRegistration message to link their TCP and UDP connections together. Upon receiving those two messages, server combines the clients into one, and provides this client to you. This means you can call both TCP and UDP methods on the client. If you still want to receive the 'local' client of a connection, you can do so by calling the appropriate messages in the Server class.
-
-
-== Serializing
-
-Serializing is an aspect that received a lot of attention. I wanted it to be simple for people to register their own messages, but also be able to register serializers for their own object types. The system works by registering classes to serializers. Generally, a serializer does not exist without a class it can serialize - simply because it doesn't have to: Why have a serializer when there's nothing to serialize. A lot of work has been put into making it as efficient as possible. What can be left out, is left out, and what can optimized, is optimized.
-
-
-=== Field serializer
-
-The default serializer requires some explanation. This serializer serializes all classes that have no (registered) serializer. The field serializer works by saving all fields internally, so it can access them on serialization faster. The fields are taken, and their types are checked. They are put through a serializer again (which serializer depends, of course, on the data type). Then they are ready to be written to the buffer. As you can tell, this is quite a simple serializer, and should be used if your message don't require extra attention. See <<spidermonkey/tutorial/serializing#,this tutorial>> if you want to know how to register your own messages or serializers.
-
-
-== Service system
-
-The service system is in fact a tiny system. It's meant to solve a small, but annoying problem. Imagine you have SpiderMonkey as your networking library, and other people have made extra's for it. Excellent, of course, but they may all require different initialization! Perhaps you have to instantiate one yourself by using new, or maybe another works by calling a factory method; the service system exists to avoid that problem. All extras should use this system. Please see <<spidermonkey/tutorial/services#,the service tutorial>> on how to use this system.
-
-
-== Compression
-
-By default SpiderMonkey supports compressing messages. It's been made to where you have complete freedom over what messages you wish to compress. See <<spidermonkey/tutorial/compression#,this tutorial>> on how to use these special messages.

docs/modules/ROOT/pages/spidermonkey/migration.adoc

@@ -1,244 +0,0 @@
-= SpiderMonkey: Migrating to the Current API
-:author: 
-:revnumber: 
-:revdate: 2016/03/17 20:48
-:keywords: documentation, network
-:relfileprefix: ../
-:imagesdir: ..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-
-[WARNING]
-====
-This article covers how to move away from an older, deprecated +++<abbr title="Application Programming Interface">API</abbr>+++! If you just start with JME3 networking, see <<jme3/advanced/networking#,networking>> for current documentation.
-====
-
-
-This document provides an overview of the new versus  the old SpiderMonkey +++<abbr title="Application Programming Interface">API</abbr>+++, and a path for migrating from the old, now deprecated, +++<abbr title="Application Programming Interface">API</abbr>+++ to the newer version.  Much has changed.
-The <<spidermonkey#,original SpiderMonkey>> implementation was a good concept and a clever implementation but suffered under the weight of rapid patches and some creeping design deficit.  In the end, there were enough small problems, long-term maintenance issues, and limitations that a newer design was warranted.
-Some things will be very similar but others have changed very much. Hopefully for the better.
-
-
-== Overview
-
-Most of the new SpiderMonkey +++<abbr title="Application Programming Interface">API</abbr>+++ now exists as a set of interfaces and helper classes in the 'com.jme3.network' package.  For most users, this package and the 'message' package will be all they need to worry about.  The 'base' and 'kernel' packages only come into play when implementing custom network transports or alternate client/server protocols (_which are now possible_).
-Clients and Servers can be created from the factory methods on the Network helper class.  Once a Server instance is created and started, it can accept remote connections from Clients.  The Client objects represent the client-side of a client→server connection.  Within the Server, these are HostedConnections.  This is a distinct change from the old +++<abbr title="Application Programming Interface">API</abbr>+++.
-[cols="3", options="header"]
-|===
-
-<a| Client      
-<a|         
-<a| Server       
-
-a| com.jme3.network.Client 
-a| ←→ 
-a| com.jme3.network.HostedConnection 
-
-|===
-
-HostedConnections can hold application defined client-specific session attributes that the server-side listeners and services can use to track player information, etc..
-MessageListeners can be registered with either the Client or the Server to be notified when new messages arrive.  As before, these listeners can be registered to be notified about only specific
-types of messages.
-ClientStateListeners can be registered with a Client to detect changes in connection state.
-ConnectionListeners can be registered with a Server to be notified about HostedConnection arrivals and removals.
-
-
-== What's Gone?
-
-All of 'connection', 'events', 'queue', 'service', 'streaming', and 'sync' are now deprecated.  The 'service', 'streaming', and 'sync' packages were too difficult to easily port to the new +++<abbr title="Application Programming Interface">API</abbr>+++ and would have required additional code review for thread-related issues.  Since the service manager model has _not_ been ported and will likely live on in a different way, it was better to let these go until better solutions evolve.  For example, streaming is probably better done more tightly integrated with the core +++<abbr title="Application Programming Interface">API</abbr>+++ and as actual java.io streams.
-
-
-== Migration
-
-
-=== Package/Class Imports
-
-As a first pass, use the following table for conversion and then see specific class notes.
-[cols="2", options="header"]
-|===
-
-a| Old Class 
-a| New Class 
-
-a|com.jme3.network.connection.Client 
-a| com.jme3.network.Client or com.jme3.network.HostedConnection 
-
-a|com.jme3.network.connection.Server 
-a| com.jme3.network.Server 
-
-a|com.jme3.network.event.MessageListener 
-a| com.jme3.network.MessageListener 
-
-a|com.jme3.network.event.ConnectionListener 
-a| com.jme3.network.ClientStateListener or com.jme3.network.ConnectionListener 
-
-a|com.jme3.network.event.MessageAdapter 
-a| no equivalent class, implement MessageListener directly 
-
-a|com.jme3.network.event.ConnectionAdapter 
-a| no equivalent class, implement ClientStateListener or ConnectionListener directly 
-
-a|com.jme3.network.message.Message 
-a| if used as a reference and not a superclass, com.jme3.network.Message.  The base class stays the same for message subclasses. 
-
-|===
-
-Doing all of those changes will certainly break your build… so now let's fix it.
-
-
-=== Client and MessageListener
-
-This class is the hardest migration to perform.  Do not get discouraged.
-The old version used com.jme3.network.connection.Client for both client side and server side.  So, depending on context, these references will either change to com.jme3.network.Client or com.jme3.network.HostedConnection.  In the case where calling code is not client or server specific, then there is also the common com.jme3.network.MessageConnection interface.
-In general, the actual client changes are of one of the following to types:
-
-[source,java]
-----
-
-  Client client = new Client( host, port );
-  ...becomes...
-  Client client = Network.connectToServer( host, port );
-
-----
-
-In the delayed connection case:
-
-[source,java]
-----
-
-  Client client = new Client();
-  ...
-  client.connect( host, port );
-  ...becomes...
-  NetworkClient client = Network.createClient();
-  ...
-  client.connectToServer( host, port );
-
-----
-
-NetworkClient is a Client.  The rest of your code can just refer to Client.
-Those are the easy changes.  The trickier ones are related to the MessageListeners.
-
-
-==== MessageListener
-
-By now you've figured out that all of your MessageListeners are broken because the new method signature is different.  The source of a message is no longer stored with the message and is instead provided to the MessageListener.
-Depending on whether your MessageListener is being added to the Client or the Server, it will need to refer to either com.jme3.network.Client or com.jme3.network.HostedConnection in its messageReceived(), respectively.  The MessageListener interface is generically typed to help make sure the right listener goes where it's supposed to and so the listener implementations don't have to cast all the time.
-
-[source,java]
-----
-
-// An example client-specific listener
-public class MyClientListener implements MessageListener<Client> {
-    public void messageReceived( Client source, Message m ) {
-       ...do stuff...
-    }
-}
-// And example server-specific listener
-public class MyServerListener implements MessageListener<HostedConnection> {
-    public void messageReceived( HostedConnection source, Message m ) {
-        ...do stuff...
-    }
-}
-// A client or server listener
-public class MyGenericListener implements MessageListener<MessageConnection> {
-    public void messageReceived( MessageConnection source, Message m ) {
-        ... do limited stuff....
-    }
-}
-
-----
-
-Your listeners will fall into one of those three categories.
-
-[NOTE]
-====
-Several of the old MessageListener's methods have gone away.  The object-based methods didn't fit with the new +++<abbr title="Application Programming Interface">API</abbr>+++ and messageSent() seemed of little utility.  It could be resurrected if there is demand.
-====
-
-
-
-==== Client method changes
-
-Some of the methods on the old Client class have changed or been removed.  Here is a basic summary:
-[cols="2", options="header"]
-|===
-
-a| Old Method 
-a| New Method 
-
-a| Client.disconnect() 
-a| Client.close() or HostedConnection.close(reason) 
-
-a| Client.kick(reason) 
-a| HostedConnection.close(reason) 
-
-a| Client.getClientID() 
-a| Client.getId() or HostedConnection.getId() 
-
-a| Client.get/setPlayerID() 
-a| no equivalent 
-
-a| Client.get/setLabel() 
-a| no equivalent 
-
-|===
-
-
-==== No IOExceptions
-
-After you've done all of that, the compiler will be complaining about the fact that send(), broadcast(), etc. no longer throw IOException.  So remove all of those try/catch blocks.
-
-[NOTE]
-====
-The truth is that even in the old +++<abbr title="Application Programming Interface">API</abbr>+++, expecting a real IOException from these methods was unreasonable because often times the message was queued and actually sent later by a separate thread.  The new +++<abbr title="Application Programming Interface">API</abbr>+++ assumes that all underlying transports will operate this way and so forgoes the artificial annoyance or sense of security provided by these 'throws' clauses.  It also simplifies the calling code a great deal.
-
-====
-
-Only +++<abbr title="Application Programming Interface">API</abbr>+++ methods that actually perform direct IO (such as the Network.connectToServer() and NetworkClient.connectToServer() methods) will ever be declared to throw IOException.
-
-
-=== Message.getClient() and Message.getConnection()
-
-This is important enough to deserve its own sub-heading because your code *will* break if you use these as they now return null.  Any reason for calling them is now provided directly to the MessageListener in the form of the source Client or source HostedConnection.
-
-
-=== Client ID and Player ID
-
-The ID of the Client and HostedConnection are now the same at both ends of a connection and the ID is given out authoritatively by the hosting Server.  This removes some of the inconsistency on when to use the old player ID and when to use the old client ID as the new client ID serves both purposes.  This leaves the game to be able to define its own player ID based on whatever user criteria it wants.
-
-[NOTE]
-====
-Many of the reasons for accessing the client ID on the server can now be taken care of using the session attributes on HostedConnection.  It seems like a common use-case for these IDs was to look-up player/client-specific information in a java.util.Map.  This information can now be set directly on the HostedConnection.
-====
-
-
-
-=== com.jme3.network.event.ConnectionListener
-
-Along with the shift from not using the same object at both ends of the client connection was a shift in the interfaces that are notified about those ends.
-On the client, there is now com.jme3.network.ClientStateListener which is notified when the client fully connects to the server (including any internal handshaking) and when the client is disconnected.
-On the server, com.jme3.network.ConnectionListener will be notified whenever new HostedConnections are added or removed.  This listener isn't notified until the connection is fully setup (including any internal handshaking).
-[cols="2", options="header"]
-|===
-
-a| Old Method 
-a| New Method 
-
-a| clientConnected(Client) 
-a| connectionAdded(Server,HostedConnection) 
-
-a| clientDisconnected(Client) 
-a| connectionRemoved(Server,HostedConnection) 
-
-|===
-
-
-== Why am I doing this again?
-
-As you've seen above, there are quite a few changes necessary to migrate to the new +++<abbr title="Application Programming Interface">API</abbr>+++.  You might be asking yourself if it's worth the trouble.
-The bottom line is that the old architecture had threading and stability issues that just couldn't be fixed in any reasonable way.  Some were minor, others kind of severe… and they combined to make trouble.  If you've ever wondered why sometimes your clients connect and then the network connection hangs or stops sending data.  Or if you've ever wondered why UDP/unreliable messages get corrupted or somehow won't deserialize properly then you've run into some of these issues.
-Moreover, the lack of thread safety meant that user code sometimes had to do some strange and/or complicated work-arounds.  The goal should be that the +++<abbr title="Application Programming Interface">API</abbr>+++ should just work like it looks like it will with a minimum of hassle.
-The new architecture is built from the ground up for threading stability and for a clean separation between the public +++<abbr title="Application Programming Interface">API</abbr>+++, the message passing layer, and the underlying network transport implementations.  You should be able to throw all kinds of stuff at it that would make the old system fall over and it should just hum along.
-There will certainly be some growing pains as we work the kinks out of the new system but it is already much more stable in even the most basic of stress tests.

docs/modules/ROOT/pages/spidermonkey/tutorial/compression.adoc

@@ -1,37 +0,0 @@
-= Compression
-:author: 
-:revnumber: 
-:revdate: 2016/03/17 20:48
-:relfileprefix: ../../
-:imagesdir: ../..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-
-[WARNING]
-====
-This article covers a deprecated +++<abbr title="Application Programming Interface">API</abbr>+++! See <<jme3/advanced/networking#,networking>> for current documentation.
-====
-
-Now this is going to be a real simply tutorial but still I wanted this in a separate article. Why you may ask? Simply because it's a feature that requires some explanation, since it has some caveats that I'll discuss. Also, I'll cover writing your own compression message.
-
-First off - there are two compression types in SpiderMonkey, they are GZip and Zip. Could've added more, but didn't want to have a dependency for just a compression method. Both are used by wrapping your message in the appropriate compression message:
-
-[source,java]
-----
-
-MyMessage msg = new MyMessage();
-client.send(new GZIPCompressedMessage(msg));
-// or
-client.send(new ZIPCompressedMessage(msg));
-
-----
-
-Really simple, but ZIP requires some explanation. The ZIPCompressedMessage class also has two extra methods; setLevel(int) and getLevel(). These methods are for setting the compression level, where 1 is best compression but slowest, and where 9 is weakest compression but fastest. Please note that 9 is *not* the so called 'store' ZIP method, which simply stores file in the ZIP, instead of compressing it. This 'store' feature is not in SpiderMonkey since otherwise it would not have been called compression.
-
-
-== Writing your own
-
-Now of course I'd love to see more compression methods in SpiderMonkey, so I'll discuss how to write your own. Let's just take GZIPCompressedMessage as example, since that one is the most straightforward. What I've done, is I've just created a GZIPCompressedMessage which extends CompressedMessage. It does not contain any extra messages, so the GZIPCompressedMessage class is practically 'empty'. The magic happens at the serializer, which is called the GZIPSerializer (you can read about writing your own serializer <<spidermonkey/tutorial/serializing#,here>>). Then I just registered the GZIPSerializer to GZIPCompressedMessage and presto - you're done. Don't forget that in the Serializer you need to use writeClassAndObject first and then compress that data, and for read you'd need to use readClassAndObject after you've uncompressed (inflated) the message. For this to be clear, it may be useful to read link:http://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/networking/com/jme3/network/serializing/serializers/GZIPSerializer.java[the GZIPSerializer class].
-
-That's that! Next tutorial we're going to discuss how to use the Service system.

docs/modules/ROOT/pages/spidermonkey/tutorial/connection.adoc

@@ -1,112 +0,0 @@
-= Connecting
-:author: 
-:revnumber: 
-:revdate: 2016/03/17 20:48
-:relfileprefix: ../../
-:imagesdir: ../..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-
-[WARNING]
-====
-This article covers a deprecated +++<abbr title="Application Programming Interface">API</abbr>+++! See <<jme3/advanced/networking#,networking>> for current documentation.
-====
-
-
-This very first tutorial is going to teach you how to open a server and a client, and connect them to eachother. I'll also discuss how connection registration works. Since this is a very simple process in SpiderMonkey, this tutorial will be quite short.
-
-
-== Simple connections
-
-Creating a server is as simple as doing this:
-
-[source,java]
-----
-
-Server myServer = new Server(4040, 5050);
-myServer.start();
-
-----
-
-This initializes and starts a server on TCP port 4040 and UDP port 5050. Now it's time to connect a client:
-
-[source,java]
-----
-
-Client client = new Client("localhost", 4040, 5050);
-client.start();
-
-----
-
-This initializes and starts a client, and it will immediately connect to localhost, TCP port 4040, and UDP port 5050. In the log, you'll get to see this:
-
-[source]
-----
-
-Sep 16, 2010 11:52:16 AM com.jme3.network.connection.TCPConnection bind
-INFO: [Server#1][TCP] Bound to 0.0.0.0/0.0.0.0:4040
-Sep 16, 2010 11:52:16 AM com.jme3.network.connection.UDPConnection bind
-INFO: [Server#1][UDP] Bound to 0.0.0.0/0.0.0.0:5050
-Sep 16, 2010 11:52:16 AM com.jme3.network.connection.Server start
-INFO: [Server#1][???] Started server.
-Sep 16, 2010 11:52:16 AM com.jme3.network.connection.TCPConnection connect
-INFO: [Client#1][TCP] Connecting to localhost/127.0.0.1:4040
-Sep 16, 2010 11:52:16 AM com.jme3.network.connection.UDPConnection connect
-INFO: [Client#1][UDP] Set target to localhost/127.0.0.1:5050
-Sep 16, 2010 11:52:16 AM com.jme3.network.connection.TCPConnection accept
-INFO: [Server#1][TCP] A client connected with address /127.0.0.1
-Sep 16, 2010 11:52:16 AM com.jme3.network.connection.TCPConnection connect
-INFO: [Client#1][TCP] Connection succeeded.
-
-----
-
-As you can see, this is a combined log of the client and server. Even though it looks like only a connection has been made, the Client registration has already happened at this point as well. Client registration is necessary so you can call TCP and UDP methods on only one Client instance on the server. You don't have to worry about client registration, since SpiderMonkey does this automatically on connection.
-
-
-== Connector filters
-
-You can also filter connections (or connectors as I call them) in SpiderMonkey. You can do this by implementing the ConnectorFilter interface:
-
-[source,java]
-----
-
-public class MyConnectorFilter implements ConnectorFilter {
-   public String filterConnector(InetSocketAddress address) {
-      if (address.isLoopbackAddress()) return "I don't like locals!";
-      return null;
-   }  
-}
-
-----
-
-Return null for no filtering, or a String with the reason if you want to filter this person.
-
-
-== Discover hosts
-
-SpiderMonkey Clients are also able to discover hosts running in the +++<abbr title="Local Area Network">LAN</abbr>+++. This is also a very simple process, and can be done as follows:
-
-[source,java]
-----
-
-Client client = new Client();
-List<InetAddress> foundHosts = client.discoverHosts(5050, 5000);
-
-----
-
-This starts the host discovery on port 5050, and listens for servers for 5 seconds. Typically, servers respond pretty fast so a few seconds should be enough. To do something with these hosts it's as simple as doing:
-
-[source,java]
-----
-
-for (InetAddress host : foundHosts) {
-    client.connect(host.getCanonicalHostName(), 4040, 5050);
-}
-client.start();
-
-----
-
-Do note that this would connect to every host found, so this does not work properly, but the idea is that you can configure it the way you want it. Don't forget to start() the client.
-
-This concludes the first tutorial. In the next tutorial, it's time to send and listen for messages!

docs/modules/ROOT/pages/spidermonkey/tutorial/sending_and_receiving_messages.adoc

@@ -1,75 +0,0 @@
-= Sending and receiving messages
-:author: 
-:revnumber: 
-:revdate: 2016/03/17 20:48
-:relfileprefix: ../../
-:imagesdir: ../..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-
-[WARNING]
-====
-This article covers a deprecated +++<abbr title="Application Programming Interface">API</abbr>+++! See <<jme3/advanced/networking#,networking>> for current documentation.
-====
-
-In this tutorial I'm going to cover sending and receiving messages. I'll also explain how to write your own messages. This tutorial assumes you already have a working server-client connection.
-
-Let's start by creating our own message. Later on we'll send this across the network.
-
-[source,java]
-----
-
-@Serializable()
-public class HelloMessage extends Message {
-   public String hello = "Hello!";
-}
-
-----
-
-This is probably the smallest and simplest message you'll find. This is simply the process of creating a class, extending Message, and adding your fields to it. Also you need the @Serializable annotation, but we'll get to that later. Even though you don't *have to* extend Message, you generally should since then SpiderMonkey can add client and connection information on receiving. You can also send separate data, but we'll not go into that here - you should just send Messages.
-
-Now let's send this message across the network. We'll send it from the client to the server.
-
-[source,java]
-----
-
-Serializer.registerClass(HelloMessage.class);
-server.addMessageListener(this, HelloMessage.class);
-client.addMessageListener(this, HelloMessage.class);
-client.send(new HelloMessage()); 
-
-----
-
-First we've registered the class to the Serializer. This needs to happen on both the client and server, I'll explain why in the next tutorial. Then we add the message listeners for both the server and client, this makes sure we're notified when messages are received. Then we send the message. The message is by default reliable, and so it will be sent over TCP. Now we'll handle it on the server:
-
-[source,java]
-----
-
-public void messageReceived(Message message) {
-   // This message is of type HelloMessage, so we don't have to check.
-   HelloMessage helloMessage = (HelloMessage)message;
-   System.out.println(helloMessage.hello);
-   helloMessage.hello = "Hi!";
-   message.getClient().send(helloMessage);
-}
-
-----
-
-This simply receives the message, and changes the Hello! to Hi! and sends it back to the client. The client, can of course handle this message however it wants to.
-
-
-== Serializable annotation
-
-The Serializable annotation is used to determine which serializer you want to use for your message, and which ID you want to register to it. If you specify no ID and no serializer, a ID will be assigned, and the default serializer will be used. The problem with specifying no ID is that you have to have the same order of registration on both the client and server, otherwise serializing will go wrong. It's therefore advisable that you use the id field, if you want to register classes in a different order.
-
-The default serializer is, of course, FieldSerializer, which'll do just fine for just about any message you can throw at it. However, if you wish to serialize your message yourself, all you must do is write your own serializer, and then pass the class to the serializer field in the annotation. For example, this Serializable annotation sets ID to four, and serializer to CustomSerializer (which doesn't exist, mind you).
-
-[source,java]
-----
-
-@Serializable(id=4, serializer=CustomSerializer.class)
-
-----
-
-That was it! The next tutorial explains how the Serializer system works, and how you can register your own serializers!

docs/modules/ROOT/pages/spidermonkey/tutorial/serializing.adoc

@@ -1,96 +0,0 @@
-= Serialization system
-:author: 
-:revnumber: 
-:revdate: 2016/03/17 20:48
-:relfileprefix: ../../
-:imagesdir: ../..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-
-[WARNING]
-====
-This article covers a deprecated +++<abbr title="Application Programming Interface">API</abbr>+++! See <<jme3/advanced/networking#,networking>> for current documentation.
-====
-
-In this lesson you'll learn about a pretty advanced system of SpiderMonkey. Why so early, you may ask; it's because it is an important aspect of SpiderMonkey, that you need to understand to effectively network your games.
-
-Let's start with a general explanation of how the serialization system works. SpiderMonkey's Serializer class is the entry point for everything serializing. Serializing is the act of translating an object into bytes, so it can be transferred over the network. SpiderMonkey does this by having Serializer classes (they extend Serializer itself), and having some static methods available in the Serializer class. A serializer does not exist without a class it can serialize - this means that Serializers need to be registered with a class. For example, the String type is registered to the StringSerializer class. Without the String type being registered, there'd be no instance of StringSerializer. So! Let's get down to business!
-
-
-== Writing your own serializer
-
-There is going to be a situation where you need to serialize something yourself, whether you like it or not. We're going through how you're going to do, by writing a entirely new Serializer - please note that this Serializer is not necessary in SpiderMonkey, since SpiderMonkey can serialize Serializable, and InetAddress4 implements Serializable (though it does save a LOT of bytes by doing it yourself). The field that makes an InetAddress4 an InetAddress4 is the IP address, so that's what we're going to serialize. Let's start by going through the basics of extending the Serializer class:
-
-[source,java]
-----
-
-public class Inet4AddressSerializer extends Serializer {
-   public InetAddress readObject(ByteBuffer data, Class c) throws IOException
-      return null;
-   }
-
-   public void writeObject(ByteBuffer buffer, Object object) throws IOException {
-      InetAddress address = (InetAddress)object;
-   }
-}
-
-----
-
-As you can see, you have to extend Serializer and implement the methods T readObject(ByteBuffer, Class) and writeObject(ByteBuffer, Object). These are the methods that actually do the job. Obviously, writeObject is used when sending, and readObject is used when reading. The next part is just Java coding - you just kind of have to know the +++<abbr title="Application Programming Interface">API</abbr>+++ of those objects you're serializing to convert into bytes. This one's really simple though ;)
-
-[source,java]
-----
-
-public class Inet4AddressSerializer extends Serializer {
-   @Override
-   public <T> T readObject(ByteBuffer data, Class<T> c) throws IOException {
-       byte[] address = new byte[4];
-       data.get(address);
-       return (T)Inet4Address.getByAddress(address);
-   }
-
-   @Override
-   public void writeObject(ByteBuffer buffer, Object object) throws IOException {
-       Inet4Address address = (Inet4Address)object;
-       buffer.put(address.getAddress());
-   }
-}
-
-----
-
-So now you've got this serializer, and you don't know what to do with it. Well, you need to register it to a class, and what other class would you want to register it to, than Inet4Address?
-
-[source]
-----
-
-Serializer.registerClass(Inet4Address.class, new Inet4AddressSerializer());
-
-----
-
-And now you can use the Inet4Address anywhere in a Message! Now we'll test this Serializer, and see if we can get the IP on the other side:
-
-[source,java]
-----
-
-public class AddressMessage extends Message {
-  public Inet4Address addr;
-  public AddressMessage(Inet4Address addr) { this.addr = addr; }
-}
-...
-client.send(new AddressMessage(Inet4Address.getByName("google.com")));
-
-----
-
-Results in a message being received, which prints out as:
-
-[source]
-----
-
-/66.102.13.106
-
-----
-
-And there you go, that's the end of this tutorial!
-
-Next tutorial you'll learn about a simple, but powerful feature - compression.

docs/modules/ROOT/pages/spidermonkey/tutorial/services.adoc

@@ -1,48 +0,0 @@
-= Service system
-:author: 
-:revnumber: 
-:revdate: 2016/03/17 20:48
-:relfileprefix: ../../
-:imagesdir: ../..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-
-[WARNING]
-====
-This article covers a deprecated +++<abbr title="Application Programming Interface">API</abbr>+++! See <<jme3/advanced/networking#,networking>> for current documentation.
-====
-
-
-The service system is meant to create a common way of using plugins. It is a tiny system, on Server and Client level. In this tutorial I'll tell you how to use services, and how to create your own.
-
-
-== Creating services
-
-Creating services is really easy - you just have to implement the Service interface. *Make sure you don't do anything time consuming* since the developer may not be expecting it. Services can choose to support Server, Client, or both. To implement this, use the appropriate constructors:
-
-[source,java]
-----
-
-public class MyExampleService implements Service {
-   public MyExampleService(Server server) {
-      // By adding the constructor with the Server as argument, this service
-      //  now supports servers.
-   }
-
-   public MyExampleService(Client client) {
-      // Same goes for client. I could just leave this constructor out, and
-      //  SpiderMonkey would determine this service does not support client mode.
-   }
-}
-
-----
-
-
-== Using services
-
-The Server and Client class both have a method called getService(). It retrieves a service based on class name, and instantiates it if necessary. From there you can use the service.
-
-The Service system is not a terribly powerful system, neither does it do safety checks and service management - it just provides a way to commonly manage extensions.
-
-That's it! Next tutorial we're going to have a look at how to use the streaming +++<abbr title="Application Programming Interface">API</abbr>+++.

docs/modules/ROOT/pages/spidermonkey/tutorial/streaming.adoc

@@ -1,60 +0,0 @@
-= Streaming service
-:author: 
-:revnumber: 
-:revdate: 2016/03/17 20:48
-:relfileprefix: ../../
-:imagesdir: ../..
-ifdef::env-github,env-browser[:outfilesuffix: .adoc]
-
-
-
-[WARNING]
-====
-This article covers a deprecated +++<abbr title="Application Programming Interface">API</abbr>+++! See <<jme3/advanced/networking#,networking>> for current documentation.
-====
-
-
-The streaming service is meant for situations where you want to transfer files, or other types of data to clients. In this tutorial we'll discuss how it works, and how to use it.
-
-Let's start off with how it works; streaming service uses messages to transfer data. This is done so it doesn't block other messages from being sent, while transferring. First a message is sent the describes the stream. The peer can now choose whether to accept or reject the stream. When the peer accepts, the data will be sent. You have to handle this data yourself. At the end of the stream you get the same message as when the stream was offered, to indicate the end of the stream.
-
-Let's transfer a file to a client:
-
-[source,java]
-----
-
-StreamingService sService = client.getService(StreamingService.class);
-sService.addStreamListener(this);
-
-sService = server.getService(StreamingService.class);
-Client receiver = server.getConnectors().get(0); // Note that you can't use 'client' here, since it's not a connector.
-sService.offerStream(receiver, new StreamMessage(), new FileInputStream("test.txt")); // StreamMessage used here as start and end message, but can be anything to describe the stream on the other end.
-
-----
-
-As you can see, this system uses the Service system. First, we get the client's StreamingService, and register ourselves as a listener. Then we get the server's version of the StreamingService, from which you can stream things. Then we get a connector client (the first one), and send the file via an InputStream.
-
-Now to receive this stuff is simple;
-
-[source,java]
-----
-
-public boolean streamOffered(StreamMessage message) {
-   // Here you'd normally check the message what this stream is all about, and 
-   // base your acception criteria on that.
-   fileStream = new FileOutputStream("test.txt");
-   return true; // Sure, we'll just accept this message.
-}
-
-public void streamDataReceived(StreamDataMessage message) {
-   fileStream.write(message.getData());
-}
-
-public void streamCompleted(StreamMessage message) {
-   fileStream.flush();
-   fileStream.close();
-}
-
-----
-
-That was all; simple right?