Printable View
Hello,
I'm having problem with Bluewing. I just need to send/receive a message, so I did these events:
Button "B1" clicked
>> Send text "R" to channel on subchannel 0
Bluewing: On text message from channel on subchannel 0 (sent)
>> (List Object) Add line "Hi";
But I don't receive anything :/ Am I doing something wrong? Does Bluewing work on Windows 10 x64?
Best regards.
Are you connecting to a server, setting a name, and joining a channel first?
Yes, I am.
You're running two copies of the game/application, right?
(I can't think of anything that would cause Lacewing/Bluewing to misbehave like this unless there is some form of user error, so I'm trying to figure out what it is that could be happening.)
Also, if you could upload this basic test MFA you made, then it could be useful for figuring out the exact issue...
You were right LOL I was thinking that the action "Send text to subchannel" sends a string to all users in the channel, including to whom send the text. But I noticed that this action only sends a string to other users, the person who sends the string doesn't receive the string.Quote:
unless there is some form of user error
I have another problem now... If I need to read a message that I sent to channel, how can I do this?
In the expression editor: Received$( "Lacewing Relay Client" )
It can be found under the "received" section of the Lacewing object's expressions.
Thank you for answer, happygreenfrog. If I use Received$( "Lacewing Relay Client" ), I can't read the message that I sent.
Probably I did not explain well (sorry for my english). I wanted to read a message sent by myself. I need to send a string for all users and I need to receive this message too.
Uh... just store the string that you're sending through Lacewing elsewhere? Online code rarely actually sends the message to the person who sent it themselves, because that can VERY easily get in the way of coding an online mode in a game (e.g. picture a player sending position updates... and then the game trying to figure out who to update the position of every time a player moves themselves, just because it sent themselves a position update). Besides, sending a message from a user to themselves would be a bit of a waste of bandwidth.
Actually, receive the same message I sent is the key to my game. Summarizing the operation:
I push the button A and I need to send this information ("Hey, look, I push the button A") for all users. When I push the button A, the function "A" should be triggered in the program, for all users. I have, so, two situations:
(a) I trigger the function in my application and I send to other users the information that I pushed the button in order to they trigger the same function in your applications;
(b) I send to channel that I pushed the button A. This message will to server and then it will be send to the users and me. The users and me receive the information and we trigger the function A;
As you can see, in (b) the function A will be triggered for all users with less delay between them. In (a) on the other hand the function A will be triggered in my application much earlier than for other users. It's a problem for me.
(a) *Push button A in my computer* --> Call function A in my computer --> Send this information to server --> Server sends this information to other users --> Users call funcion A in their computers;
(b) *Push button A in my computer* --> Send this information to server --> Server sends this information to other users and me --> We call function all almost at the same time;
As you can see, there is a delay (T1 + T2) in situation (a), where T1 is the time to server receive the information from me and T2 is the time to other users receive the information from the server.
Maybe calculate the average ping as a part of the startup process of your game, and then add in a delay of some kind before triggering the action without receiving it? I don't think that what you want to do is possible with the exact way you are trying to go about it (especially given the flawed logic of "everyone will receive it close to the same time"... the person sending the message themselves would likely receive it at LEAST a bit sooner anyways), but there ARE ways to potentially get it working anyways.
P.S. To try to calculate the ping time of each player, one way you could go about it is that, before the game properly starts, you set it so that each player sends each other player a message, and then, after each player receives the message, they send back how long it took for them to receive the message compared to when the process started, which could then all be added to a list so you can calculate an average ping time. Not sure how effective this method is, but I think it should work for the most part...
Thank you for you reply, happygreenfrog. :D
If I use fixed delays for each player, I can get into the situation of accumulating errors (unless I update the table of delays periodically) because the situation of players connections are likely to vary during the match. Waiting for response from the server, in the way I thought, IMO minimizes errors automatically. Moreover, this would simplify a lot (does not have the need to maintain a table that is updated periodically).
Some MMO's work in the way you've described in B. Resulting in slow moving on laggy connections and the inability to move when the connection is lost. That is a down side to this method but is still preferred as the server can easily detect cheating/hacking using this method and prevent the player from moving outside of bounds. This does mean you'll most likely need to invest in local servers for the player base as latency becomes unbearable.
Thank you for your contribution, danworth. Timing is essential in my game, so I can't see (a) as a good solution for my case. If I need to configure the server to process and broadcast these messages, I'll add at least two steps in the communication, creating more lag.
In the past its been said that for movement and such UDP is recommended. UDP is faster than TCP so will have less latency. The issue with UDP is that the order that the packets arrive can't be guaranteed. So if you were to implement encryption to your packets with key rotation UDP wouldn't work.