Sorry, but finally that doesn’t work. Like I said, my control have the same name on the server and the client scene and my function and my control are not on the same Game Object. But evrytime I print(touchpad != null), the answer is false, so mapDataStructureToAction() is never calles.
If touchpad stays null then the checkForClient method has not found your control yet (but yet you see the telemetry in the console so it’s there). The two things to check are.
That the control name on the client and the server are exactly the same (case sensitive) the default for touchpads is “Touchpad1” on both the client and the server. If you’ve changed this to something custom make sure they match exactly and don’t conflict with any other of your controls.
If you are sure the control names are the same, then make sure your player number matches what phone is connected. Assuming you are testing currently with just one phone obviously the server side should be marked as “player 1”
If you still have issues/questions don’t hesitate to let me know and I’ll look into it further.
Ah I didn’t realize you ever got it to work intermittently, I thought it was never working. The next version of the product which is going to be submitted in the next few days, is going to update the connection system drastically, which will make it so you don’t need to restart the controller app anymore. Glad you figured it out.
Easy WiFi Controller 1.8 has now been submitted for review and should be live on the store in about a week.
Release Notes:
-Drastically improved connection system. You no longer need to restart the controller app if you have server only changes.
-New “Any Player” option on server controls. This is useful for menus.
-New controller select example. Shows how to do a Super Smash Bros. style player select screen. Also, this example includes two server side scenes to demonstrate that Easy Wifi Controller can keep connections across scenes.
Is there currently a way to allow a wifi client to respond to the host game app being quit?
More concretely i’d like to have different ‘screens’ display on my client depending on the state of the client-host relationship (not yet connected, connected, ‘game joined’). I’ve managed to get these transitions working in a forward direction, but it’s not clear to me how i could transition from connected back to ‘not yet connected’ when the host application quits.
[EDIT] It looks like the new ‘heartbeat’ properties could be used for this. Does the Heartbeat Timeout on the ‘client’ peer type refer to how long it will wait for heartbeats sent by the server before disconnecting? And is there a way to add a callback to the disconnect event on the client, or should i be repeatedly comparing the status of EasyWiFi.Core.EasyWiFiController.clientState to EasyWiFiConstants.CURRENT_CLIENT_STATE.NotConnected? Thanks!
Yes the new connection system has 3 properties (two on server and one on client) that handle the non normal disconnects (things like just quitting the app, forced closes, or network goes down). These are in addition to voluntarily disconnecting properly via the connection widget.
Heartbeat Timeout(client only)-
When you set to something besides 0 this is activated. This is the rate at which the client checks for server heartbeats. If this check fails twice in a row the client assumes it’s been disconnected from the server.
Client Timeout(server only)-
When you set to something besides 0 this is activated. If the server doesn’t hear from a particular controller in this amount of seconds it will mark the controller as disconnected.
Server Send Heartbeat rate(server only)-
When you set to something besides 0 this is activated. This is the rate at which the server will send heartbeat messages to each client. This is how the client controllers will know if it gets disconnected from the server.
You will see that all the example scenes have been updated with values for these. In particular for your case you’d want to set the heartbeat timeout to detect the host app going away. As the documentation states it waits for this check to fail twice and then it sets EasyWiFi.Core.EasyWiFiController.clientState to disconnected and goes back to “discovery mode” to look for another server or if the same server has come back. I have put a callback on the server that passes whether a controller just connected or disconnected and an int for which player number. On the client side there is no callback but there is also no real information it has here so there is no real difference between “connected” and “game joined” here from the client. It either knows it’s in a session with the server or not and doesn’t really know anything else, unless you add some states for your game from the server via backchannels (which would be custom to your game). If you want to display the connection state I would simply query clientstate.
Hope this helps and hope you like the update. Certainly as always if you have any suggestions or improvements don’t hesitate to ask and I’ll try my best to add them.
I’m struggling a bit with getting the colouring system to work in the way I’d like while also gracefully handling host quits and restarts of the game.
What I think would make it easier for me would be a way to send distinct ‘messages’ from the host to the client from time to time, rather than a continually updated stream of data (which the backchannels seem like a perfect fit for). Am i perhaps overlooking a way to do this, or if not are there any plans to implement something like this?
The system is designed around consolidating each machines traffic and is not a per control tuning. So lets say your controller has 8 controls or your server has 8 backchannels. EWC is not spitting out 8 packets it is spitting out 1 with all the 8 controls information in it. This is why if you have 1 out of 8 controls that you’d like to send infrequently there is no option to do so. The option of sending rate is on Easy WiFi Manager but will only give you general options like “cap at 60hz”, “cap at 90hz”, “cap at 30hz”, “send infrequently once per second”, etc. and will effect the sending rate of all controls.
In general, this (consolidating) is much more friendly to not using up all your wifi bandwidth than providing individual tuning per control which would require splitting up packets and is why there are no options to do so. Most people don’t realize that as long as you stay under the typical routers max packet size (512 bytes) that there is virtually no difference in sending 300 bytes vs 400 bytes and that sending two small packets (say 30 bytes) is worse than 1 larger packet. In general this is why the receiving end on bool and string data types (backchannels too) have the option in their inspector for the notify method between “always” and “only_when_changed”. That way you can still write your methods to be more event driven if you want, even though the data is always coming.
In a general purpose network tool you do usually get both styles (rpc’s and every frame sync). However, with EWC it’s obvious that almost all traffic will be sync and that fact is actually used to facilitate the consolidation. It does mean though that it’s not designed for RPC style traffic, though.
HI greggtwep16
I want to buy this plugin for making the video stream share between two device at same time. Do you think it is possible from this plugin ?
Audio/Video is a lot of data, so no this plugin wouldn’t work for that. It’s primarily designed to work as a controller. It can work for general purpose data as well, but in my testing it can handle about 4096 bytes per frame with 2 players, 2048 bytes per frame with 4 players, 1024 bytes per frame with 8 players, and 512 bytes per frame with 16 players on average/poor wifi network. Obviously, with strong wifi it can handle more but 4kb wouldn’t be enough to handle an audio/video stream. Controller data, object data, or most other data requirements are much smaller so the product handles that just fine even up to 16 players on the same network.
There are users that have been successfully been able to “share” their screen by transmitting the Unity object data instead, but an audio/video stream directly won’t be of any use at that small of a size even if you lower the resolution. When application like skype, netflix, or others do it, they use pretty involved compression algorithms and obviously aren’t trying to play a game at the same time.
First of all, Great asset! Help’s me alot with many different projects. It will be great if there will be an option to not send data every frame for the backchannel controls. I always have to find workarounds for this problems.
So my first question is: do you have any advice what is the best way to send out one time data between server and client and vice versa. For example, a button that sends a specific number that makes the server do something… Right now I have to send the number many times every frame instead of just once.
My seconds question: Is there a way for the client to know the player number that was given to him on connection to the server?
One time data transmission is not currently built into the product as it’s designed around continuous data streams (controller data, telemetry data like the spedometer needle back to the controller in the example, etc). On the surface, it’s easy to mistake how major of a change this is to implement. One time data updates, especially on UDP, would require acknowledgements to be built into the product, since you will be only sending it once you need to make sure it got there. When you start down the road of acknowledgements, you also generally need to start building timestamps and the syncing of different machines timestamps. This is in addition to the normal infrastructure around sending variable sized messages and other things that would be required. It essentially would change much at the core of the product.
At least at the current time, I don’t have any immediate plans to add this to the product. You are not the first to want this functionality and I certainly understand the desire. For now I think the simplicity of the current design outweighs the need to put this in. Also, in general in each case that I’ve talked with people in the past about this they were generally unaware of the lack of performance impact of repeated sending of information. In general as long as all your data is under 512 bytes per frame there is virtually no impact to sending the data all the time. When you get above that size routers will break up what used to be one packet into multiple and then it does start to matter (it impacts the number of concurrent players you can have) but until you reach that threshold it is not really making any significant difference in performance. Are you near this threshold?
This information is not known by default by the client (only the server knows the logicalPlayerNumber). That being said you can certainly send this piece of data back to the client via a backchannel.
Could you direct us on how to control the camera via gyroscope? We intend to turn around, look up and down, in a very similar way like head tracking in VR. We have tried to use and customize match orientation script from the controllerskitchensink and steeringwheel example scenes. However, we could not manage to achieve a decent tracking. we have changed the quartenion values from + to minus at some point which got us closer a bit, but still we need a helping hand on this. Maybe an example like a gyro to mouse look script could do the trick. Thx,
The match orientation script would indeed be the closest. Can you elaborate on what wasn’t “decent tracking” at that point? Was it behaving as you intended (turn left looked left, tilted up looked up, etc.) but just wasn’t precise enough? Or was there a fundamental portion that wasn’t mapped how you wanted?
I have tried to send a custom bool value from the controller to the scene, that reflects if the controller is connected or not. So when the controller is on it sends a true boolean, and when the controller is set to off, it sends a false right before disconnecting. The problem is that this does not work, the controller never receives the false value, even though I send it before it actually disconnects.
So how would you go about creating this scene? I want players to be automatically assigned a player number when they press connect, and remove them from the game if they disconnect? In your documentation there is no guide on how to check who is connected and how to reassign player values to them.
