[NO CCU LIMIT] Forge Networking now OPEN SOURCE

Yes, I will be home tonight after I see my family and send out the Beta to everyone. I wasn't able to update anyone last night

 

Yes, there is NO WAY we are going to let any of these performance issues or bottlenecks bring the system down. We are moving this issue to the VERY TOP of the list, so the other features requests that haven't already been implemented are going to have to wait for that to be complete. We will have all of these issues ironed out. Our code runs through just fine, I will be critically analyzing the lifespan and work habits of our threads next.

 

Look for V4 and the new lean CPU implementation in your box within the hour. We used virtual machines to feel your pain and we cut out a huge amount of fat. Of course these virtual machines were ran on our main machines so there may be some discrepancies. Please give us your feedback on speed with the new build. We will continue to analyze this throughout the rest of the process.

Thank you! We would hate this too D: we like you around here Please keep leaving your comments!

 

The main gremlin has been slain! Look for it in tonight's V4

 

Hi, we already bought Bolt but haven't used it yet. Can you compare what's better (or lacking) about your asset vs Bolt?

Also, any idea if this is compatible with XBox One? Not sure if multipler games on XBone have to use a certain service or something...

 

Hello!

So I haven't played around enough with Bolt to tell, but some others I know have. I can get with them to see where we compare with Bolt. We actually have the developer of Bolt in our Beta, so we may be able to get some feedback directly from the source

Would you like to be a part of our free on-request Beta? You can hop in, ask questions, play around and watch all the tutorials you can handle (in the works)! If you would like the be a part of the beta just send me an email address either to support@beardedmangames.com or via a conversation message here.

If Unity sockets work the same exact way with XBOne then everything should work just fine. If you have a developer license you can also try our Beta out on it and let us know! We know others with a license for XBOne that we can use but it may take a bit of time to have them test it.

 

Beta V4 released, we have added the documentation to the website and will be doing some new video tutorials on the new features: http://beardedmanstudios.com/documentation/

You will also find that there is a .chm file with the documentation in the V4 build as well. Please leave us your feedback (good and bad) and lets continue to make this system become more powerful!

 

Ok, well until I can get a comparison to Bolt, I don't want to spend any time learning your system. I'm short on time as it is without trying to compare two networking plugins (and I know almost nothing about networking which doesn't help).

Depending on how that comparison stacks up, we might want in on your beta of course! By the way, what's your price going to be?

 

Tried to run the beta on Android and iOS, seems to be crashing from the obfuscation put over the assembly, no real error report just a hard dump back to the home screen.

 

Also it seems like opening your 'ForgeQuickStartScene' will crash the unity editor to the desktop, again I suspect the heavy obfuscation put in place.

Edit: So far after playing around with this for about ~20 minutes, I have not been able to get a single game running in either the Editor or a stand-alone build on any platform: Sometimes I can't even build out the game (not sure what's causing it, just randomly crashing).

 

Hey! Thanks for the response

Actually we just now built to Android right when we saw your post. Also we built to WP8, Win8, and PC. None of these platforms crashed using the same exact beta that was sent out. Did you go through the tutorials? Here are the tutorials to get you started:

http://beardedmanstudios.com/getting-started/step-by-step-example/

We have a Mac, PC, Linux, Android, WP8, Win8, and iOS all in-house so we will continue to test on these platforms

We have tested on 5 different computers here. Can you please give us some specs on the devices you are using?

We will need your computer specs (ram, cpu, graphics, etc.) and for the Android device, can you please send the model?

Thanks!

 

Tested on the following android and ios devices: iPhone 4S (iOS 7), iPhone 5S (iOS 8), Nexus 5 (Lollipop), Xperia Z3 (Kitkat). All crashed on start. Both my PC computers and my OS X computer crashes to desktop when opening the 'ForgeQuickStart' scene in the editor, and if I have it in the build they crash when building also.

 

Hey! Thanks for the response. I would say that since both Bolt and our system are in "Beta" I am not able to truly compare the final differences. Bolt has been in Beta longer, however we do have a few testers that have come from Bolt and are pretty happy with what we offer. Our system is extremely simple but has the ability to be very complicated to suit any of your needs. Either way you seem to have the need to learn a system, so if you could list some of the things you are wanting to do with a networking system I could tell you if our system will suit your needs

 

Do you have the specifications for these? We are actually running the same exact package on our OSX and a PC (working together) as I am typing this now. We are now building to a legacy iOS device to test there!

 

They're run of the mill dev machines, my main workstation is: i7 Haswell-E 8 Core, 32gb ram, 512 x 2 GB SSD and a GTX 980 my other pc is: i5 3570k, 16 gb ram, GTX 770, my mac device is a late 2013 macbook air

 

Awesome! Thank you! We have tested on about 8 devices now. We found the bug with iOS and will be addressing that particular platform via hotfix, we have yet to reproduce the problem on other devices.

Thank you very much for the feedback!

 

here's a 10 sec capture of the editor issue, it's the same on all my computers http://dl.dropboxusercontent.com/u/19877504/capture-31.mp4

looking at the register + stack dump of the error log it looks like it's trying to read an invalid address inside C# code (which is very hard to make happen in C#), which is why I'm suspecting the obfuscation.

 

OOOH! You need to be on Unity 4.6 for that scene . Sorry, I should have said that about the specs. This issue is because the UI in that scene is in Unity 4.6.

What you are seeing is what Unity does when you try to open a Unity 4.6 scene in an older version of unity. It would make absolutely no sense for our DLL to be crashing a scene load anyway because, loading the scene does absolutely nothing with code.

Sorry for the confusion, I've been using unity for quite a long time and recognize that is an issue with the scene itself.

This would explain the crashing on mobile devices too. You are building from an older version of Unity and it is loading up the scene with the UI that is not supported, causing the crash.

 

NOTE to everyone: Please use 4.6 for the beta if you are wanting to use the Quick start scene we have provided

 

Same issue on 4.6.1f1: http://dl.dropboxusercontent.com/u/19877504/capture-32.mp4 (tho the register + stack dump looks way different, so probably another issue that the previous crash to desktop).

Edit: Also my OS X computer was using 4.6.1f1 the whole time.

 

Hmm, you should file a report with Unity as this is an Editor issue. Scene loads do not run code in the editor, so this is a deeper issue. I have had the editor crash on a scene load before too. Have you tried to restart your computer? We will continue to look into this. Are you running Windows 7 (it looks like 8)? Lets try this. Make a scene with a script that just uses the Networking.Host() function. Don't use our Quick start scene because it could very well be corrupted. Please let me know your findings

Also DLL files are loaded up at the beginning of a program (or during compile time I assume for unity). Since assembly is loaded into memory, that means that if there were a problem with the DLL it would crash during import time I would assume. Also we do not have an editor script in that scene so none of our code is executing during that scene.

 

Sorry Farrisarts. I am not having any joy with Beta 4. I am seeing the following error in the console.

I am running 4.6.0f3

Exception: Could not load method '0xa0001a7' from assembly '0x1a6993c8'
System.ModuleHandle.ResolveMethodHandle (Int32 methodToken, System.RuntimeTypeHandle[] typeInstantiationContext, System.RuntimeTypeHandle[] methodInstantiationContext) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System/ModuleHandle.cs:124)
System.ModuleHandle.ResolveMethodHandle (Int32 methodToken) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System/ModuleHandle.cs:84)
⬀.⬗.⬁ (Int32 ⬀, Int32 ⬀, Int32 ⬀, Int32 ⬀)
⬀.⮐..cctor ()
Rethrow as TypeInitializationException: An exception was thrown by the type initializer for ⬀.⮐
BeardedManStudios.Network.SimpleNetworkedMonoBehavior..cctor ()
Rethrow as TypeInitializationException: An exception was thrown by the type initializer for BeardedManStudios.Network.SimpleNetworkedMonoBehavior
BeardedManStudios.Network.NetworkedMonoBehavior..ctor ()

 

Thanks for the log! Working on it now!

 

So, I re-downloaded and re-installed the package, crash seems to be gone. But other issues instead, a little of depending on what I do, in what order, etc. I get anything from the same type of error as Zaddo67 (but not that *exact* one, different ethods) to the mono compiler complaining about Invalid IL:

InvalidProgramException: Invalid IL code in BeardedManStudios.Network.Networking:Host (uint16,BeardedManStudios.Network.Networking/TransportationProtocolType,int,bool,bool,bool): IL_028c: ret

Edit: Scratch that, crash still happens... but not *always* as before. Doubt it's my unity install or anything else since I've never had any issues with scenes crashing the editor, ever, before.

Edit2: Yeah no matter what I do another error seems to turn up at some point, somewhere, I'll wait for the next beta release before testing more.

 

It is around 3:30am here and we will be going to sleep in order to wake up bright and early to continue working with these issues. We expect to come to a solution with the other people in the studio for the Obfuscation problems.

Thank you @Zaddo67 and @fholm for your well received feedback!

 

Thanks Farrisarts. 4.1 works great!!!

Initial testing shows performance issues have been addressed. CPU drops to zero after stopping the app and I see no CPU difference between a Smartfox network implemention or a Forge network implementation.

 

Awesome! Love to hear that things are working out. Day 1 supporters have recieved a hotfix for some of the issues addressed! We are still looking into the iOS side to have a solution for that.

Thanks everyone.

 

awesome,
early this morning wokeup and saw both v4 and v4,1 hotfix
so i went straight to the hotfix and seems to have smashed the nasty cpu hog gremlin for good,
awesome work, my pc is now a happy camper

i have tested on windows OS only and standalone builds, so you guys took care of the issue at least for the mentioned specs for good which is where i am testing with.


OK, now that i am able to test forge networking, i have to ask:
not sure if i read something about it in the early past posts or maybe was a different issue,
but when i try to connect more than 1 client to a server in the same pc or local testing multiple clients connections, the server refuses it, it only lets connect the first client.

is this a bug?

reason i am asking is that with other networking plugins ie: ulink, massivenet,unity default networking etc... i am able to multiple client connections in same pc hardware or locally . using udp, and even verified the builds in player settings "run in the background" box is checked.

or am i missing a step to allow multiple client connections.


thanks again for the cpu load fix.

happy Sunday everyone

 

Yeah. Others have asked about this. I am actually going to work on this today. As for now you can have 1 client and 1 server on the same machine (on UDP). If you really need to test with multiple players today, you can temporarily switch to TCP and have multiple players through that.

Of course! Happy Sunday to you too!

 

Have you guys tested on Unity 5 yet?

I can start a server, according to your basic example, but I can't connect a client.

I get the following error message...

NullReferenceException: Object reference not set to an instance of an object
BeardedManStudios.Network.CrossPlatformUDP.DisconnectCleanup ()
BeardedManStudios.Network.CrossPlatformUDP.Disconnect ()
BeardedManStudios.Network.Unity.NetWorkerKiller.OnApplicationQuit ()

I can run the example and connect fine with Unity 4.6.1

 

Ah! yes we have 5.0 Beta. We haven't tried it lately on this version. Thanks for the heads up, I didn't know it would work differently. We will hop on testing this out asap! Thanks for the stack trace.

 

So we found the iOS build bug. Basically it is related to AOT not playing nice at all with threaded events. Since we moved our connections to be threaded so that they do not freeze up your games when connecting to a server, the events dealing with connecting were working with threads. We are developing a system of wrapping our event driven code in a way that plays nice with iOS. If anyone is having issues with building to iOS this is the cause. We will have it fixed soon!

EDIT: We just tested our fix for the events on iOS and had a successful build, connection and demo we have developed.

 

Ok that will be sweet, I've updated my racing game to Unity 5 now so in order to test your library with the vehicles etc that will help!

I was using the Forge Beta 4.1.

 

Are you on Unity 5 v 5.0.0b9? I just loaded up my simple project and it seemed to work fine.

Looking over this error again I remember fixing this issue last night. I can't remember if it was before or after the V4.1 (it was in 4.6 though).

I'm going to take another pass at this trace to see if I can't come up with a solution for tonight's release of Beta V5

Edit: Also, do you mind letting me know what type of connection you are making?

 

I'm using 5.0.0b19.

I can try on Beta 20 too if you wan, I'll need to download it though.

I'm using the simple example scene you provide with the package, and just added a new scene called game and added a cube with a networked monobehaviour. That's it, I didn't change anything else.

 

I will try both Beta 18 and Beta 20 (I don't see 19 there unless they have a version history). Hopefully I can reproduce. . If not I may ask you to try out 20

 

Ok I upgraded to Unity 5 Beta 20. I created a new project, and imported your asset package. And the basic example with a cube worked!

However, when Unity 5 asked me if I wanted to upgrade (as the package contains obsolete APIs), I clicked yes, and the editor showed the following error...

This didn't stop the scene from working, but you might want to check it out anyway...

So to replicate...

1) Create new project in Unity 5 Beta 20
2.) Import 4.1 Beta package
3.) Observe error in editor

Note : I remember having this on Beta 19 as well.

Error -4 running AssemblyUpdater. Its output is: `Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Runtime, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0
at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x00000] in <filename unknown>:0
at Mono.Cecil.DefaultAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x00000] in <filename unknown>:0
at Mono.Cecil.MetadataResolver.Resolve (Mono.Cecil.TypeReference type) [0x00000] in <filename unknown>:0
at Mono.Cecil.ModuleDefinition.Resolve (Mono.Cecil.TypeReference type) [0x00000] in <filename unknown>:0
at Mono.Cecil.TypeReference.Resolve () [0x00000] in <filename unknown>:0
at Mono.Cecil.Mixin.CheckedResolve (Mono.Cecil.TypeReference self) [0x00000] in <filename unknown>:0
at Mono.Cecil.SignatureReader.ReadCustomAttributeEnum (Mono.Cecil.TypeReference enum_type) [0x00000] in <filename unknown>:0
at Mono.Cecil.SignatureReader.ReadCustomAttributeElementValue (Mono.Cecil.TypeReference type) [0x00000] in <filename unknown>:0
at Mono.Cecil.SignatureReader.ReadCustomAttributeElement (Mono.Cecil.TypeReference type) [0x00000] in <filename unknown>:0
at Mono.Cecil.SignatureReader.ReadCustomAttributeFixedArgument (Mono.Cecil.TypeReference type) [0x00000] in <filename unknown>:0
at Mono.Cecil.SignatureReader.ReadCustomAttributeConstructorArguments (Mono.Cecil.CustomAttribute attribute, Mono.Collections.Generic.Collection`1 parameters) [0x00000] in <filename unknown>:0
at Mono.Cecil.MetadataReader.ReadCustomAttributeSignature (Mono.Cecil.CustomAttribute attribute) [0x00000] in <filename unknown>:0
at Mono.Cecil.CustomAttribute.<Resolve>b__2 (Mono.Cecil.CustomAttribute attribute, Mono.Cecil.MetadataReader reader) [0x00000] in <filename unknown>:0
at Mono.Cecil.ModuleDefinition.Read[CustomAttribute,CustomAttribute] (Mono.Cecil.CustomAttribute item, System.Func`3 read) [0x00000] in <filename unknown>:0
at Mono.Cecil.CustomAttribute.Resolve () [0x00000] in <filename unknown>:0
at Mono.Cecil.CustomAttribute.get_ConstructorArguments () [0x00000] in <filename unknown>:0
at Mono.Cecil.ImmediateModuleReader.ReadCustomAttributes (ICustomAttributeProvider provider) [0x00000] in <filename unknown>:0
at Mono.Cecil.ImmediateModuleReader.ReadModule (Mono.Cecil.ModuleDefinition module) [0x00000] in <filename unknown>:0
at Mono.Cecil.ModuleWriter.WriteModuleTo (Mono.Cecil.ModuleDefinition module, System.IO.Stream stream, Mono.Cecil.WriterParameters parameters) [0x00000] in <filename unknown>:0
at Mono.Cecil.ModuleDefinition.Write (System.IO.Stream stream, Mono.Cecil.WriterParameters parameters) [0x00000] in <filename unknown>:0
at Mono.Cecil.AssemblyDefinition.Write (System.IO.Stream stream, Mono.Cecil.WriterParameters parameters) [0x00000] in <filename unknown>:0
at Mono.Cecil.AssemblyDefinition.Write (System.IO.Stream stream) [0x00000] in <filename unknown>:0
at AssemblyUpdater.Application.Program.UpdateAssembly (AssemblyUpdater.Application.CommandLineSpec config, APIUpdater.Framework.Log.ConsoleUpdateListener logger) [0x00000] in <filename unknown>:0
at AssemblyUpdater.Application.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 `
UnityEditor.Scripting.AssemblyUpdaterHelper:Run(String)

 

Woah! This may be an issue with the unity beta as it seems they are using Cecil. I'll look into it on 20 and if I find its something with Unity 5.0 beta, ill cut a bug report to Unity describing the problem. Hopefully I is an error we can fix though. Maybe the scene upgrade from 4.6 to 5 is initializing this problem, hmm.

 

I am looking forward to getting this feature. I have done some reading on UDP and I now have a better understanding of the problems running UDP on same port for more than one application on the same computer. (But still only a rudimentary understanding)

it would nice nice to get a technical explanation of your solution, If you don't mind explaining how this is going to work.

Ideally, when you connect a client to a server on UDP, that connection becomes fully bi-directional. I understand the problems of doing this on the same computer. Will the solution you implement be along the lines of:
- Server listens on the specified UDP port
- When the client initiates a connection on UDP, it finds a free port and sets this as the source port (Can be different to servers UDP port)
- The client listens on this source port
- The server saves the source port for that client and sends all packets for this connection over this port


Another question. Since a Forge connection only supports UDP or TCP. A game will typically communicate on both protocols, you will need to setup 2 connections. Will the server know that the 2 connections are for the same player?

 

So basically here is what we are doing. The server listens on the port that was input as the binding port to the connection. When a UDP client connects, it will check to see if the port is already bound, if so it will become Port + 1, then checks that one. It will continue this until it finds an iterative port that is open. Once it has found its port it will communicate this to the server upon sending a message to the servers port. Once the server gets this communication, it will map that port to that particular instance of the NetWorker. So every communication it does from then on with that NetWorker will use the port that was specified.

We will be adding in a function later for you to specify an array of ports to not allow connecting to, that way you can keep it from binding to well known ports. Once the system reaches the max port number (ushort) it will reset to 0 and continue its work. If it miraculously goes all the way around and hits the same port it started with (the server port) then it will throw an exception.

This is an extremely good question! Since you can start up both TCP and UDP at the same time in our system, it would be very important to associate these players. Currently there is no way (in our system) to associate the socket on TCP with the UDP socket. However, now that you bring this up I can think of a few ways to make these be able to know of the players cross communication. They will not be able to share sockets or NetworkingPlayer references, however I think we will implement a way for you to be able to get a UDP player from a TCP player socket and vice versa!

 

We are continuing to crank this machine! Beta V5 is out and we are ready for some more feedback (off to tutorial land for us!).

Those who did not receive Beta V5, please respond in a message letting us know you are still alive and wanting to test and we'll get Beta V5 to you!

EDIT: We used a new build process so please let us know if you have hit any errors with the new version! Thanks!

 

For the documentation, i think video and source format is a good idea but, you should add also some text documentation under video, like a summary of what you said in the video.
Text documentation is easier when you do the implementation in the same time, no need to press pause, go back in the video etc .. and probably easier for an non english speaker.

Personally i like the RailsCast of Ryan Bates ( http://railscasts.com/ ), every toturial has a video and a text format.

 

Good idea! I will take a look at that site and see how I can emulate them

 

Notes on what is coming to V6:

AuthoritativeRPC (for server) - The ability for the server to send RPC calls to particular players. This can be combined with the new player position tracking that happens on the server to send position based events to each player
OwningPlayer (for server) - The NetworkingPlayer that is associated with this particular SimpleNetworkedMonoBehaviour (or derivitive)

These are already worked into the system, we will be continuously going through our feature requests, feel free to send tons more!

 

i am waitting for it nice

 

i just saw that the NetworkingPlayer has a ping functionality ?
It is call automatically or do we have to call this method by our self ?
It will be nice to have a TimeSpan for the respond time of the last ping

 

I am going to be cheeky and make a suggestion.

It would be fantastic if the Networking.Host and Networking.Connect functions were changed to look like:

public static NetWorker Host(ushort portTCP, ushort portUDP, int maxConnections,
bool winRT = false, bool allowWebplayerConnection = true, bool relayToAll = true)

and

public static NetWorker Connect(string ip, ushort portTCP, ushort portUDP, bool winRT = false)

A game will always need the TCP protocol. The UDP protocol should be optional and passed as null or 0 if unwanted.

I believe that it is easier to make a single connection to the server and have the networking package handle all the underlying vagaries of this.

At the moment, SimpleNetworkedMonoBehaviour and NetworkedMonoBehaviour only use the primary socket. So you have no way to set some objects to send their behaviour over TCP and others over UDP (There is the option for UDP and UDP Reliable).

WriteCustom would also just accept the Networker and protocol.

I have started writing a wrapper class to do this for me in my project.

Just a thought I wanted to share with you. If you don't like it, a brief "no" will suffice (i.e. no need to defend your current design)

PS: Also might be beneficial to have IP as a parameter on the Host function. Some systems may be multi-homed and this will allow you to specify which IP to attach to.

 

I don't know what will be the target of people who will use the library, but if u are targeting beginner, this library has be as simple as the unity3d networking embed library.

For me with this implementation it start to be too complicated

 

Talking about TCP and UDP it will be nice also to have documentation for beginner about :
- Differences between TCP, UDP and Reliable UDP (Reliable, Ordered message, performances, etc ...)
- Advantage and Diadvantage of the 3 choices
- When do i have to use TCP, UDP or Reliable UDP ?
- When do i have to use RPC and WriteCustom features ?

 

question: what ever happened to the mmo features you were planning to add next, like:

-Area of interest (AOI/network LoD)
-server to server seamless player handovers for mmo zones seamless worlds

those feature implementation you talked before were going to be added to beta v3 before you gave priority to the cpu threads fix?

did you push them back for later or decided not to anymore?
or are they already in it in the current build?

just checking and making sure you wont forget

regards