[ENet-discuss] ENet package broadcasting

[Erik Beran]

I suggest reading the physics, network, and drop-in coop articles on
http://gafferongames.com/  They will give you ideas and point you in the
right direction.
/Erik

On Wed, Feb 25, 2009 at 12:28 PM, Nuno Silva <little.coding.fox at gmail.com>wrote:

> I'm by far not the smart one regarding networking, but i think it's about
> you waiting for players to send their input that's making everything super
> slow. The server should be independent from clients.
>
> On Wed, Feb 25, 2009 at 7:41 AM, Boris <bstih at zootfly.com> wrote:
>
>> Espen Overaae wrote:
>>
>>> Hello, and at the risk of sounding arrogant and condescending,
>>>
>>>
>>>
>>>
>>>> Because of our fixed time step, we wait every client to send its input
>>>> to
>>>> every one. When data arrives, we update next frame.
>>>>
>>>>
>>>
>>> that is a bad idea,
>>>
>>>
>>>
>>>
>>>> But the problem is that it takes way to long for data to arrive from
>>>> client
>>>> to server or vice versa.
>>>>
>>>>
>>>
>>> and that is why.
>>>
>>>
>>>
>>>
>>>> So my question is, what could cause such big lag? The data can take even
>>>> half a second to arrive. When sending text messages, or ping messages it
>>>> appears to work properly. The data arrives with minimal delay.
>>>> The size of input data that we are sending is about 120 bytes depends on
>>>> amount of inputs pressed.
>>>>
>>>>
>>>
>>> I assume you're sending the packets over a LAN, since packets over the
>>> internet often take as long as half a second to arrive. If you are,
>>> then I have no idea what could be wrong, sorry.
>>>
>>>
>>> Espen Overaae
>>> _______________________________________________
>>> ENet-discuss mailing list
>>> ENet-discuss at cubik.org
>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database:
>>> 270.11.3/1968 - Release Date: 02/23/09 18:22:00
>>>
>>> Hellow again, thank you for such quick reply.
>>>
>> Hellow again, thank you for such quick reply...
>>
>> Please elaborate your first statement.
>>
>>  / Because of our fixed time step, we wait every client to send its input
>>> to
>>>
>> />/ every one. When data arrives, we update next frame.
>> /
>> that is a bad idea,
>>
>> Why do you think this is a bad idea, do you have any other idea. I know
>> that
>> our idea is not cheat safe. But we see only this, as a major problem in
>> our
>> idea. And ofcoarse our code is for LAN only. Internet is another story.
>>
>> Thank you in advance...
>>
>>
>>
>>
>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20090225/9a1e041e/attachment.htm>