[NO CCU LIMIT] Forge Networking now OPEN SOURCE

yeah, i saw that as well ;(

i have no probs with them taking time etc, but there *are* ways of handling that better imo

 

my understanding is that there are issues with unity's networking as well, scalability, bugs etc. most not necessarily because of the networking code itself, but the hacking around crap to get it to work on the platforms and game genres everyone has.

Ideally? we could just focus on making whatever great, but reality dictates adding security or additional functionality for that fringe use case, all of which impacts performance, however minutely.

 

Haha! I am indeed long-winded! We're about a year apart, I remember all of what you mention, and probably the stuff you skipped as well.

Maybe I can re-state my thought a little clearer / differently.

Most people - especially ones with little game development experience - absolutely get hung up the thing they don't have or can't do. Often, we're talking about the things they're most excited for and motivated by. Occasionally it's because it keeps them from having to do the repetitive / hard / less sexy part of development. In this case, we're talking about networking, but it could be any number of features in an engine or product.

Basically, when the asset / engine sells itself as being easy and accessible (or even Superpowered), anybody who doesn't know better is going to assume they'll fire it up and make immediate progress on their Next Big Thing. At least until they loop back to the previous paragraph with regard the next thing they can't continue work without.

My earlier point was that there is a basic level of multiplayer connectivity that could (and I think should) be provided in modern game engines - in a stable, accessible, and ready to use state. Ideally, it would serve as a starting point most for people's needs and hopefully eliminate this sort of cyclic drama. To keep this in context, I'd say that this sort of foundation concept would also apply to Forge.

That's all I was talking about, no more, no less, sort of my 'ideal world'. Beyond that, regarding some of the potential issues you mention, you're absolutely into the realm of project-specific needs / development and it makes total sense that it's not in the base product. That's why you hire programmers.

Of course, all of this is ultimately just a discussion - there are so many biases that come to the conversation and affect expectations. Personal experience, project needs, and on and on - there's no one solution or product for everyone.

Oh - I would also agree that the money on these assets is only wasted if I choose to never look at the code because it didn't work exactly as I imagined. If you take the time to tear it apart, engage the brain, and come away with more knowledge - it's money well spent.

 

That level of basic networking is in Unity right now, in the form of the LLAPI and HLAPI. The problem with most of the new devs, though, is that it is NOT drag-n-drop and built into simple components for graphical usage. I think that is where Forge had its best feature, in the inspector wrapping of low level functions. HLAPI (UNET and such) are too restrictive for most coders that want a customizable system and the LLAPI is too low for most newer developers to grasp how it works.

 

What you said!

 

absolutely, so what has to happen, that in my experience users/customers/marketing folks don't like to do, is to manage not only their own expectations, but those of the developer's as well. For example, customerX, in this case would be a consumer of this middleware offering; a developer of sorts, but not necessarily. Therein lies the first problem. Just like you can't just jump into your car and drive without at least *some* basic knowledge, even if you don't have to know gear ratios, nor can you just buy an asset for 'the next big thing' and click a button and be instantly rich and famous. Problem is, the developers of this particular offering have fallen, however regrettably, into the timeworn trap of trying to be too much to too many people too quickly. He has to manage what he can *actually* do, at the time of doing it, and weigh the cost and issues of adding functionality for customerX that has little to no development experience.

I read this somewhere back when, but it stuck with me:

"To make something easier for a user, makes it exponentially more difficult for the developer"

This probably sums it up for me as both a customer and developer:
I've actually had an application manager actually say this to me during crunch time: "We're on an aggressive timetable here, can't you just download some button code?"

LOL. The not so funny thing? He was serious.

Now while i sound all preachy and developer defensive, this kind of mentality has to change. As does the rock star developer mentality. Somewhere in the middle is where we probably need to be.

Fortunately for me, i can make sense of the code and mebbe do something with it, for others they're at the complete whim of the developer/company etc. There *are* solutions to this, but then both sides would need to accept what their individual responsibilities are, and in again, in my experience, folks don't want to hear that. Not even a little bit. Shrug.


oh, and a couple of things i've already found in my perusal of the code:

Thread.Sleep? seriously? yuck. there's a problem waiting to happen if it's not already happening...

Another? foreach and nested foreach loops.. This goes to my comment before about knowing a little about the accumulated codebase that you're dealing with. AFAIK, the GC is still an issue.. something to the tune of 40 bytes allocated each iteration? (someone please correct me if i'm wrong)

 

btw, here's a link to the thread about the GC:

http://forum.unity3d.com/threads/unity-5-and-mono-runtime.235079/page-4#post-2503563

 

I was wondering this too. I never looked into Unity's networking solution since I thought it lacked features like no authoritative actions or lag compensation out of the box. It really was unnecessary since I already owned Photon and Forge.

Yet, overtime Unity's networking has changed and it seems decent,

 

I've not got experience with Forge but as far as I know it's quite different to DarkRift. DarkRift focuses on message passing and just that, no synchronized variables or NetworkViews just the concept of clients/servers telling each other "I did something". There's also no built in matchmakers or anything like that out the box, it's designed to be as light as generic as possible therefore it wouldn't just be a drop in replacement, there'd be a bit of work to do to change over.

I really hope the Forge team haven't vanished, they always seemed lovely people and very dedicated to their software

 

Unfortunately, us early adopters (we bought it when it first released) that worked with the developers in the beginning for days, weeks, months trying to sort out the constant disappearing RPC issues, broken buffered instantiations, and other fun bugs (that are all still there) are SOL for refunds according to the developer. Apparently us having bought in the beginning when it was simple and actually worked (mostly) is just our own bad luck for helping the developers iron out issues that should never have been a problem.

 

Ahh! So this is a known issue. Dang it. I guess I'd better start looking into Unity's Unet then. There are no other real options.

 

PM me your email address. We have a low level RPC package getting ready to open source release in the next couple of months. Unity LLAPI based and so far we have NEVER lost an RPC.

 

Still seeing proximity based update issues in V18.

If you run the demo scene with 3 clients or more, the logic of the proximity based updates doesn't make sense. The Auth RPCS get sent erroneously to clients that shouldn't be getting them.

For instance, in the demo scene for ForgeHelloCube with proximity based updates on, load 3 clients. Player A on left, Server in middle (B), and Player C on right. Move player A away from server (B) and keep player C within server proximity.

Once you are out of proximity with Player A notice:
Player A sees B(server) go invisible and no longer gets updates from it: Expected
Player B(server) sees player A go invisible and CONTINUES seeing updates because they are the server: Expected
Player C however, sees Player B(server) erroneously go invisible even though C is within proximity.

Here's what's weird too. If I do the same thing above, but go out of proximity with player C, while Player A is within proximity....the server is still visible. So Player C has different outcome doing the same test than Player A.

In doing more testing, I see that the second player (non server Player C) to join is the only one that gets it.

Unless I'm not understanding what proximity based updates are for, there seems to be a lot of additional unexpected behavior in general. Any clarification would be welcome on what the system is designed for and if there are in fact unintended results.

Are the proximity based updates only for interacting with the server and not when you are in proximity to other players in general?

Thanks guys.

 

This is truly concerning, as much as I don't want to admit. Hopefully this is only temporary, and it seems to be the case that it is.

Personally, Forge has "just worked" for me. I fixed a bug myself in a few minutes because I found the source code to be really easy to read & understand. I added a feature update in a few minutes after that! Loved it, at least that day.

I haven't had any problems with it, but the claims of bugs still being around is concerning, and I am concerned I will run into bugs/issues that I'll have to handle myself (rather than they fix them long before I even encounter any problem.)

However looking at the list of reported bugs, here is what I found that concern me:

http://epicjoin.com/ForgeNetworking/Bugs

• Proximity based updates may not be working.
• Some possible issues with players not disappearing on disconnect.

These aren't big issues at all. I could easily code my own proximity system (LOL, I didn't even know this was a feature. I was going to anyway, lol.) and the disconnect problems are easily resolved.

There's some other reported bugs, but nothing serious, and I've experienced little problem myself. So far "it just works". I haven't done an extensive amount in my game, but I do have players connecting, syncing, and correctly messaging the server (running around the world, interacting with things, picking up and dropping items, etc.) Authoritative server. Server only, player as host, and singleplayer offline mode all working as intended.

So although fear of abandonment is real given past assets, I hate Unet (and any new Unity feature, really. They do shoddy work and it takes a very long time for unity to make their features acceptable, if ever. I waited for 4+ years for some fixes.) and Forge has been amazing so far. Support is fantastic when all is well, although the vacations do suck, I imagine, when they are taking personal time. Still better than Unity/Unet support and updates though! Unity is so slow in updates, it's hard not to be better even when you disappear.

Having the source code with Forge though means you don't lose your investment. If a closed source solution were abandoned? Ugh. Unet? I don't trust Unity, and they are still worse than a developer who sometimes disappears for a month. You re at the mercy of Unity, a very slow developer who is perfectly fine releasing systems that are dead on arrival. I switched to Forge because UNET was broken when it first released. Even months after, the bugs were ludicrous. Typical Unity stuff, and that is NOT a good compliment. Forge took me 5 minutes to success, in what UNET took 40 hours to fail. IDK the current state of UNET, but I imagine it is still infuriating. I'd rather invest my time fixing tiny bugs in Forge and building on it, if problems even arise, than rely on Unity/UNET where problems are certain and solutions far away. At least with open source [Forge), the only problem is MY incompetence and speed, not Unity's.

edit: Mind you, most of my experience with 'it just works' was early on in Forge's life, so it has always been stable for me. Forge has had tons of updates since, and still 'just works'. I cannot say the same with UNET. But I'm just me. I'm not you. I have long since been with Unity even before it was popular and have very harsh criticisms of Unity as a company/engine (closed source, slow fixes, weird decision for engine direction, feature abandonment, horrible performance, lack of support for tons of very important features, and consistently awful 'early access' new features.) While I have significant praise for high quality third party unity assets. YMMV.

 

What issues still exist? From my understanding, all your bug reports are for Linux? This is important for others to know. Maybe this is great for Windows, but not so much for Linux?

 

I found this in the forge community discussion, on February 14th.

http://epicjoin.com/ForgeNetworking/Conversations/Benefits-over-base-unity-networking??p=373

 

The only bug I ever sent for linux was on the master server. Everything else is Win86/64.

 

Guys, there is no need to worry. Forge will still be around for awhile. I found the announcement on Slack.

Brett will solely focus on development for Forge, [he needs] to get caught up in the codebase to understand where it was left off at for future development. It will take him some time to catch up. He is only one man and has to wear many hats. Even more now until he is caught up and can switch to one big hat (Forge's full time main developer).

Then back to weekly updates. Forge, along with Bare Metal and the Cloud are alive and well. The reason for the change in main developers sounds like a GOOD (profitable reason) for their company as a whole. That means more longevity; More security for Forge's future.

 

Forge has an error event that is raised on the client and the server. The reason it takes time for the client to be seen as disconnected is the nature of UDP being a connection-less protocol. Once the player "times out" (which you can set the timeout time length) then it will be disconnected.

 

This is a bug and will need to be added to our bug tracking. Are you a part of the team on GitHub, if not send me or @Cranick a PM on Slack for access.

 

The best way to communicate is through Slack. Our inbox is a bit flooded and will need to be sifted through, I am sorry about this. When you purchased or registered Forge through the website you should have been invited to Slack as well

 

I am sorry about this, if you saw our announcement in Slack #news then you may already know why, I'll be making a formal post soon on this, probably a clone of the Slack chat.

 

If you purchased through the website, then you were invited to slack. If you registered your Asset Store invoice on the site then you were invited to Slack as well. Just head over to https://slack.com/signin/find and input the email you used to register on the Forge developer site

 

Very sorry to hear this, we are still developing as noted in the Slack #news, we have just been working very hard on building the business.

 

I would like to note, just because we are away doesn't make Forge useless. It is a product that anyone can buy and use right now in their games. Though we are back in the development bus, we don't have to be present or even exist for games to work with Forge. I believe the power of Forge comes from the code that has made it up, not from my or @Cranick existence. There is plenty of software, tools, games and everything else that are still around today that work great even without a single new line of code in years or decades. Either way, we have a developer actively working on Forge now, not to mention the 50+ developers that have GitHub access who are sending their pull requests, suggestions and updates (obviously not all developers are committing, but the few who do are making great updates!) .

 

We have disocontinued EpicJoin to continue with more widely used software like GitHub, wiki, etc. The main developer of that system is no longer with us.

 

Glad to see you are back. However, the disappearances without letting us know really is disturbing. We are halfway through a custom system by now that works quite well. I defended you at first, but you know, it gets hard to do when there is no response. I do have a developer on your Slack system but he says nothing was said there either.

Anyway, good luck to you! I like you guys a lot but recommend that you at the very least spend 5 minutes posting a....We are busy with something else but will return soon. I am sure you had the time to do that.

A bit of motherly advice....

 

And perfect advice that is! Good luck with your system and we can't wait to check out your game when it is ready !

We understand that it can be hard to figure out a system without full support 100% of the time. We should have done better to make a post and as humans in little to no sleep do, we fumble. I've spend a complete year developing and supporting Forge Networking and the system is a shining example of what we achieved last year, all of us who gave feedback and worked with me on developing the system. We have a system that has been continuiously battle tested, improved and updated. Our Christmas (December/January) month missing was a result of over working to mitigate expectations of those who are looking to take a risk in our teams efforts. I know that many developers are upset (and with good reason) by missing support, but everyone reading must realize that just because we are not there for a short time period doesn't mean the system doesn't work. Code will work the way it was written without the presence of the developers. We are working right now to improve documentaion to help everyone get caught up with the system.

 

Announcements - Forge Networking = not dead!

Moar development! We have had many things come up since Christmas and they are amazing and will push our efforts as a business far beyond what we would have hoped! What does this mean? You get @Cranick as the new full time developer of Forge Networking as well as the knowledge that our studio is funded (albeit from Forge and other things). This frees me up to do more video tutorials - as seen here and other sorts of documentation.

GitHub access for all registered developers! Are you using Forge Networking? Did you register on the developer site? You are eligible to get GitHub access! As we develop on GitHub you will get the latest commits and can test out things before they go out. Check out bug fixes, check out others pull requests, collaborate with other developers, report issues and use the wiki there. GitHub has tons of tools that help everyone out and we have decided that this will be our public issue tracking instead of EpicJoin. We just enabled all of that on our repo! We currently have about 41 developers who are a part of our GitHub so lets push that number to the hundreds! *Can you say mega-feature sets and pull-request fixes? Of all of the networking systems we are the only from scratch one with the developer network and willingness to give full source code and GitHub repository access, you just won't find that from a third party anywhere else! Come join the party!

New twist on old angle! For us it has always been about building a community, and with hundreds of people registered on our Slack that has been a great feat for any system. Seeing everyone collaborating and communicating with each other has been such an awesome experience for the team here. We wish nothing more than to build the community further, we will be less controlling with our GitHub Access (outside of requiring to be registered with Forge), we will use more open communication tools like MediaWiki and GitHub issues/wiki rather than pushing our own "EpicJoin" agenda. We will also encourage everyone to contribute to the wiki, to GitHub issues, via code pull requests, and more! After all, thousands of brains are better than 2 no - at least in most cases (hiveMind--) XD?

Note: Our support email is severely backed up and we may move to only go through critical emails or request those still interested or still having problems to re-iterate. This way our email doesn't become an infinitely growing old response system.

Thank you so much to the huge amount of you who stuck through the silence and continued to make great things!

 

Do you realize how many networking systems have disappeared over the last year? So many, and a few left and returned and then left for good.

When you go away, and don't let people know you are coming back, they assume the worst. The track record is that they leave and the system is gone.

It isn't just about support. We were okay without the support. But we did not want to keep going with a system that might stop being developed. We did not want to put in the time.

Better to admit you goofed then to try to justify it. No sleep simply isn't the reason, sorry, Farris. Again, I don't mean this personally.

I just am not fond of young folks making excuses. Honestly, that makes me less likely to use their product.

 

Hi! Thanks for the reply, but the link you gave me says my email is invalid. I've checked my email and searched and never got any email about slack or anything, in spam folders or anything else.

 

I found your comment pretty condescending and rude. While I realize you are upset, his response was very professional and he did not give any excuses. In fact, he admitted he should have made an announcement, acknowledged the mistake, and then stated why (He is a human being, and thus not perfect, not to mention overworked) not as an excuse, but as a form of communicating understanding. At worst he emphasized he has went above and beyond to make sure Forge is a great product and that he is only one person so try to have some understanding in this one unfortunate scenario. (It's not like the product is closed source or low quality. It works very well already and IMO is very high quality.)

I thought your response was pretty entitled too. What other choice do you have? Forge is incredibly cheap for what it delivers (an entire networking solution, fully working, unlimited, open source, clean code, for only $75). Forge is the only open source package. If it gets abandoned, any remaining bugs can be fixed. This is not at all like Bolt or any other networking solution that goes abandoned. Forge also works right out of the box. The bugs are very minor, and even if it were abandoned you could fix them. I'm skeptical the bugs are even that big of a deal though, as I haven't encountered any myself and I assure you there will be plenty more in UNET (Unity is notorious for numerous bugs and slow fixes.).

Also your alternatives are close-sourced networking assets (often with CCU/Messaging costs/limits) where you are at the mercy if there are any bugs or issues. You can rely on them 100%, but the problem is relying on them 100%. You could go with them, but what if they were abandoned or bugs ignored? You'd have to implement a workaround or abandon them entirely.

With Forge, you never have to abandon it because you have full source, it already works great, clean code, etc.

With Forge, there are no CCU limits. No messaging costs. It's pay once, own source code for life; UNLIMITED! What networking solution is better than this?? Open Soucre + No Limitations. No other competitor has that.

And if you want to add a feature? You can sometimes only do that with Open Source. That means you can only do it with Forge. Not any closed source solution (UNET, Photon, Bolt, etc.)

If your answer is to write a custom solution, I don't really see the point if Forge already works. Forge's code is very easy to read & understand. So you could more readily build on Forge, given that it's open source, than to rewrite your own from scratch.

My question to help you is, "What problem did you have with Forge, that forced you to switch to a custom solution?" If there was no problem outside of support disappearing, why did you switch then? Forge worked + Open Source.

If Forge gets stopped being developed right now, and you find no bugs, why would you be upset and abandon it? Is a certain feature missing? If nothing is broken/bugged, and you have no feature request, then why does it need further development?


As a consumer, I fully understand you want your assets and unity systems to have continuous development, love the constant addition of features, etc. You want that security in knowing you won't have to fix bugs yourself or even learn networking programming. That's all wonderful, but for $75 we sure as heck are asking a lot on developers. I love the ASset Store, but at the same time, it's crazy how little we pay for so much support, so many hours worked on an asset, etc. All I ask is that the asset works, is open source, and works without horrible bugs. Forge fulfils that, so anything extra (like their continued development) is just bonus.

After all, all we really need is a netwoking solution that "just works" enough for gamers to play our game without problem. It seems to do that already, and extra features are just icing on the cake.

In the future, don't make the same mistake I have in the past, where I abandon assets/systems needlessly (when it works fine/great) just because support disappears, tuts dry up, or I find something possibly "better". (I know I've done that many times just because I was scared for no reason, thought the grass was greener on the other side, or thinking that no more support somehow means the code becomes broken, lol). It sets back development time when you abandon things to chase something new over and over. I'd know, that type of attitude set me back YEARS in development

If it works, stick with it. Reinventing the wheel is bad, but changing your tire every 10 miles is far worse.

 

there is lot of things wrong here:
-unet have source code availlable: https://bitbucket.org/Unity-Technologies/networking/src
-unet is free, you are not tied to use cloud, you can host it yourself

 

Ah! I see, do you mind sending a support email asking for a slack invite using the email address you used to sign up at http://developers.forgepowered.com/? I will make sure you get invited, our email inbox is a bit crazy at the moment but if you subject it as "Registered User Slack Invite" I'll set a filter for it

 

That's good to hear, although it should be noted it is not the complete source code.
In fact, it is indeed limited. Seemingly quite significantly.

Make special note what the NetworkTransport is. You might be thinking "That is just one thing, I can live without it!"

That NetworkTransport is the LLAPI.

So what is open source?

Not the LLAPI.

Simplified: What is closed source (LLAPI - Low Level stuff) is what you'd WANT open sourced. It's better than nothing, but if LLAPI is closed source, I wouldn't go around bragging that UNET is open source. Certainly not the same as Forge, anyway.

Also I'm not sure how well documented or easy to understand it is, although I am curious to be able to see some of Unity's work.

As for the second part, I don't think anyone would dispute UNET is free. It's part of Unity. Of course it's free. It's just that it brings with it all the weaknesses of being part of Unity.

There is a reason Unity relies so heavily on the Asset Store, and a reason why I consistently tell others that the Asset Store is one of, if not THE greatest strength of using Unity Engine. And that reason is NOT because Unity's systems are of high quality, hehe It's because of third party developers like Forge. Perhaps UNET has gotten a lot better since it was first released entirely broken, but why bother with the risk when you have this? That's my opinion, anyway.

 

Could we use a php master instead of the one provided?
Also I would like to get on github please

 

Yes, we have a simple HTTP library built into Forge Networking so you can do REST requests for use with PHP and other web setups.

Woot! Do you mind sending me a PM message on Slack or here on the Unity Forums with your GitHub username as well as the email you used to register on the developer site so I can get you added?

 

Sent

 

You have been invited.

PS to everyone else, if you would like to be invited please do the same (note that you have to be registered on the developer website and have purchased through the Asset Store or through the website)

 

Hi, does this have MMO features such as automatic network LOD/culling and seamless server to server hand over? If it's not then is it in your roadmap?

 

Thank you so much! Will do.

 

Hey Farris,
Does Forge Networking have an integration with Steamworks and PSN networking api - matchmaking, friendslist etc. ?

 

I never received any information for Slack. Trying to find a group there with my email address(es) came back empty.
My main concern (for the past 2 months) has been RPC's just failing to talk to each other. That gets fixed, I'm a happy camper.

 

I am having similar problems.

The client always sends the RPC, but the Server seems to intermittently receive the RPC. Sometimes it works, sometimes it doesn't. The Server just doesn't seem to get the RPC sent from the Client. I'm wondering if this is happening due to the order it's loaded in. (Had problems in the past with this exactly issue. The way I resolved it was to make it update later.)

I did a test, by putting in a 10 second delay before I sent my problematic RPC.

The result is that it works every time. Problem solved. It's a load order issue.

Code (csharp):

1. bool didItOnce = false;
2. float StartTime = 0;
3. void Update()
4. {
5.   StartTime += Time.time;
6.  
7.   if (!IsOwner && NetworkingManager.IsOnline)
8.   return;
9.  
10.   if(StartTime >= 1000 && didItOnce == false)
11.   {
12.   RequestServerToSetupMyCharacter();
13.   didItOnce = true;
14.   }
15. }

 

In doing some experimenting, and may have come across something pertinent.
Originally, my progression through the scenes is laid out as below:

CLIENT: Connection Scene --> Login Scene --> Client Game Scene
SERVER: Connection Scene --> Server Game Scene

With this setup, clients are able to connect, are able to log in, but are unable to communicate via RPC to the server (though, clients can see RPC communication with other clients).

On a whim, I added a scene on the server side, between the Connection Scene and the Server Game Scene. So the new layout is as below:

CLIENT: Connection Scene --> Login Scene --> Client Game Scene
SERVER: Connection Scene --> Load Scene --> Server Game Scene

The new "Load" scene is just a 2-3 second delay, then automatically loads the next scene (Server Game Scene).

When running a test with this set up, the server runs fine. The client is able to connect, but when the Client goes to log in (the client sends an RPC to the server), that part is failing: the RPC doesn't reach the server.


So, my guess is that there is some sort of paging or something....the client and server can only communicate only if they're "on the same level", ie they must be on the same scene numerically. If that's the case, is there any way to address this to keep the NetworkingManager / state "on the same level"???


Original:

SERVER -------------------- CLIENT #1 --------------- CLIENT #2
====================================================
Connection Scene ------Connection Scene -----Connection Scene
Server Game Scene --- Login Scene ------------ Login Scene
------------------------------ Client Game Scene --- Client Game Scene


Delta 1:

SERVER -------------------- CLIENT #1 --------------- CLIENT #2
====================================================
Connection Scene ----- Connection Scene ---- Connection Scene
Load Scene --------------- Login Scene ------------- Login Scene
Server Game Scene --- Client Game Scene --- Client Game Scene


When I change my code to have two scenes in both the server and the client (ie, Client has a Connection Scene, which transitions to a connection scene when the connection is made, and then the user logs in and eventually plays the game when log in is complete) (ie, the Server has a initialize connection scene which transitions to the server scene).....everything works fine. They're in the same number of scenes. This method works, but it seems like a kludge to get over an inherent problem, and detracts from the design of my application.

 

I'm having an really hard time trying to get Forge Networking to connect to or from a public IP. I want to be able to implement a simple 1 on 1 multiplayer on cross platform mobile device. Pick a list from your contacts, start a server, your friend gets an invite and connects to your server. I thought everything was here in Forge to do this and it looks pretty straightforward. I've tried everything in the docs however there is no example that I can find that shows a public IP, only local LAN etc...
I'm stuck spending way too much time trying to figure out how to connect over the internet with mobile. I did get it to work over LAN and between devices and to the computer. So The wind is out of my sails, does anyone have any suggestions, tricks, tips, or can point me to a demo scene or some docs I would be terribly gr8ful.

Thanks in advance

 

Sounds too simple but.. did you really check your open Ports? I have not problem connecting to "online hosts" when thier firewall is correctly set up.

maybe try this : http://www.yougetsignal.com/tools/open-ports/

 

Another issue I'm finding (and I believe I've seen comments about this before):

If the client starts up and there is no server online, it cannot connect. If the client is running in the Unity Editor, Unity locks up solid. If the client is a stand alone EXE, the EXE locks up (cannot quit).

 

Are you on the latest version of Forge. The latest version is not currently on the asset store, it can only be downloaded from the developer website. If you purchased through the asset store then you will need to register on the developer site to get Slack access and access to the latest download. Note, you will automatically be invited to Slack once you register on the developer site.

This was an issue that people had in previous versions, I haven't head much about it in the latest versions as we did bug fixes for this.

 

Thanks for this, I'll make sure that @Cranick see's this post so that he can look into it.