[PLUGIN] Network v0.3a update***

This forum is currently in read-only mode.
From the Asset Store
Fantasy Game includes more than 600 sound effects inspired by hit computer games like World of Warcraft and Diablo.
  • Other than that, I'm having some fun with this... it has huge potential and the speed seems fine! I had a friend from Malaysia connect (and his internet is pretty slow) with a ping of only 112ms! :D

    I've noticed it works great long-distance as well =]

    *EDIT*

    Also I have discovered that if you have conditions on an event "On packet type X" it does not seem to work.

    Example:

    On Packet Type X   -   Do something (this works)

    On Packet Type X

    PlayerObject.Count = 0   -   Do something (does not work)

    <font color=red> It seems I solved this by using SUB EVENTS</font>

    ~Sol

    Hmm, Pixel People Online uses many of these and works fine. However, I often do comparisons to data from the network packet data.

    Edit: Just checked and there is one event where it checks against a non-packet value, and it still works as expected. The Network plugin gets really weird with objects being created and destroyed it seems.

  • Thanks for the reply Jayjay.

    I have also noticed when making calls from packets, I get varied results.

    Example:

    On Connect -> Send Packet "RemoteJoin" & ":" & global('PlayersConnected') & ":" & global('PlayerName')

    Sends a packet when a player connects...

    Then to receive the packet

    On packet type -> "Remote Join" Set Text.text "global('PlayerName')"

    This works fine

    however...

    On packet type -> "Remote Join" Set Text.text "GetToken(Network.PacketData,1,":")"

    This does not. It returns a "0" for some reason.

    What the hell crap?

    ~Sol

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Thanks for the reply Jayjay.

    I have also noticed when making calls from packets, I get varied results.

    Example:

    On Connect -> Send Packet "RemoteJoin" & ":" & global('PlayersConnected') & ":" & global('PlayerName')

    Sends a packet when a player connects...

    Then to receive the packet

    On packet type -> "Remote Join" Set Text.text "global('PlayerName')"

    This works fine

    however...

    On packet type -> "Remote Join" Set Text.text "GetToken(Network.PacketData,1,":")"

    This does not. It returns a "0" for some reason.

    What the hell crap?

    ~Sol

    It sends that when it connects itself as well, so when it first sends it the value of PlayersConnected is 0. However, when another player joins they also send this message out. So rather than the server saying how many people are online, the clients are telling everyone they don't know who's online.

    At least, that's what I think is happening.

    Edit: Ah! Also, token 1 is the PlayersConnected, 2 is the name of the player.

  • It sends that when it connects itself as well, so when it first sends it the value of PlayersConnected is 0. However, when another player joins they also send this message out. So rather than the server saying how many people are online, the clients are telling everyone they don't know who's online.

    At least, that's what I think is happening.

    Edit: Ah! Also, token 1 is the PlayersConnected, 2 is the name of the player.

    Oh my bad, I meant to have PlayersConnected in the example to match the top call. I must have copy/pasted the wrong line.

    The weird thing is though, about what you mentioned first is that in the server events I can make that call either way, and it works fine. In the client, if I don't use the direct call (global command), and try to use the GetToken call... it fails.

    I am pulling my damn hair out. D:

    ~Sol

  • Hey SOL, can you post or PM me a .cap that shows the problem? The example you showed seems odd since one of them has nothing to do with Network data..it is just a global variable kept local to the client. Also highlight the difference between which server events and client events are different.

    One of the challenges with a network plugin is that we are piecing together all of these code parts and some might not be meant to use together (as I've written it now). Sounds like I have a few bugs to workout. :-)

  • It's ok scidave I have figured it all out now, thanks to Jayjay's help.

    I have not had a repeat of the issues, pairing network conditions with other conditions. I'm not sure what the problem was at the time but I must have had something so arse-backwards it just failed to work as expected.

    If I come across any more problems like this I'll be sure to send it your way though.

    Big thanks, lastly... to Jayjay for giving me some much needed guidance on his knowledge of the plugins functionality and usage to date. I now have a nice working model for multiple connections and data flow control.

    Thumbs up.

    ~Sol

  • Big thanks, lastly... to Jayjay for giving me some much needed guidance on his knowledge of the plugins functionality and usage to date. I now have a nice working model for multiple connections and data flow control.

    No problem SoldjahBoy, glad to help <img src="smileys/smiley1.gif" border="0" align="middle" /> Can't wait to see what you make of your game though <img src="smileys/smiley17.gif" border="0" align="middle" />

    Edit: Hey SciDave, if you ever want to make a condition/action of your plugin highlighted, I think you just need to put a * at the start of its name.

  • OK so, I know this plugin is still in early stages etc, but I just wanted to ask some questions regarding performance, scidave.

    I notice that with only a handful of players connected (4-6) that there is a fair bit of lag when transmitting x,y position and angle of each player, as well as a Name and UID for each player.

    Distance doesn't seem to be a HUGE issue, though internet speed seems to play a larger part... but even then it seems to get super laggy after only a minute of people being connected, and that lag seems to stack.

    Am I doing something wrong or is this just the way it works as of now?

    If the former, what is the best way to send packets? Is an always command a bad thing?

    If the latter, can we expect to see performance increases over time? How do you plan on tackling this (if at all)?

    Cheers in advance :D

    ~Sol

  • : Sending a couple of values every tick is something i wouldnt recommend, its better to send it, maybe every 5 ticks or even 10 and use lerp to smooth out the movements. It all depends on how fast the game is, so for a fast-paced game, say a shooter, you'd need to send a lot more packets in a short time, but for a slower game, less packets and more lerp.

    I'm pretty sure there are other people who have said the same as me, and im sure there are people with better methods than me, but those are my recommendations ;)

  • Sounds like what you need is something like timedelta for lag.

  • The only problem I can see with that is my game will require some pretty exact information, partially to cut back on server/client checks (for sync and anti-cheat) but for accuracy of movement.

    My game will not be an "action game" but will have a lot of moving objects, so network traffic will probably be pretty hefty.

    Thanks for the suggestion though. I did think of it but have not actually tried it yet, so I may still give it a go.

    newt

    This. This exactly... I would rather it slows down the movement of everything, and "lag" the server to compensate for the slowest connection, in order to maintain integrity.

    ~Sol

  • Hey SOL..

    To answer your questions:

    1. Sending x,y angle, UID, and name every game tick is fine for a LAN game. Other than that, it causes too much network traffic for internet clients that don't support lots of bandwidth. There are a couple of solutions:

    a. Send updates less often and then use a lerp to smooth movement. I show a simple example of this (lerp) in the netshooter .cap. Either way, over the internet with more than a couple clients..definitely need to send data less often. Valve's engines send updates every 3-4 frames and interpolate (lerp) to smooth the difference.

    b. Use the RoundTripTime expression combined with player's speed/angle to "predict" their path/location. For example, send a packet that says "player 1 pressed the up arrow at angle X w/ velocity Y". Knowing that you can predict how fast he will be traveling and path is will take without ever getting new updates (i.e. if you know the player is traveling in a straight line then it makes no sense to send updates every tick for a path along that line). Having the RoundTripTime you will know what the lag is and can compensate (took 100 ms for packet to get to you so player is already moved further along that initially. If the remote peer takes their hand off of the up button then you immediately get that message and can predict based again on lag where the player stopped. Every few ticks the server can send the TRUTH out to everybody and everyone will get synchronized again. CAUTION: prediction does have it's shortfalls with games where movement can change rapidly so you have to send out the truth synchronization more frequently

    c. Combine sends together vs sending lots of little ones out at a time..not sure if this applies in your case. However, try not to let your packets get bigger than MTU (1500 bytes).

    d. Reduce the size of the packets through serialization. * This is not implemented in the plugin currently so I should be able to reduce bandwidth consumption by about 25% or so. Only problem with this method is that the way network data is constructed must change. Instead of being able to do a: playernum & : & angle &... I would have to define parameters that you would add like: param1 = int with playernum....kinda like the function object. This is a massive change to the plugin and I probably would fork the source and build up a new version.

    2. Laggyness building over time. I'm not sure if it is a memory leak in the plugin as the core library ENET supports games with hundreds of players. Here is my guess with what is happening...you are sending out packets every tick..at first clients are able to handle things ok, but after a while packets start stacking up, ENET's automatic load handling takes over and starts dropping unrealiable packets (your x,y position packets) to help guarantee the reliable ones make it through. The more packets stack up the more that ENET will drop to maintain bandwidth levels.

    Try doing an experiment and only send data once every 5 game ticks. See if the laggyness increases the same over time.

  • Well I did write a large reply, but the forum ate it since Tom hasn't increased the idle timeout beyond 4 seconds.

    I will summarize by saying:

    • Thank you!
    • OK I will try those things

    and

    • You're awesome

    ~Sol

    PS. Tom if you see this, PLEASE increase the idle timeout to like, 2 hours... It timed me out between logging in and writing a 200 word post... and I type around 60wpm.

  • scidave, can i take new version and replace it with the old version in \plugins and in \runtime? Will my projects work? And when version 0.4 will br ready? <img src="smileys/smiley4.gif" border="0" align="middle" />

  • scidave, can i take new version and replace it with the old version in \plugins and in \runtime? Will my projects work? And when version 0.4 will br ready? <img src="smileys/smiley4.gif" border="0" align="middle" />

    Yup. That worked for me at least.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)