Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


hplus0603

Member Since 03 Jun 2003
Offline Last Active Today, 12:17 AM

Posts I've Made

In Topic: Client side hit detection vs server side with prediction

22 May 2015 - 02:22 PM

It is easier to write, which is sometimes an important trait.
Also, server rewind may still suffer from dropped/delayed packets, where the server comes to a different conclusion than the client.
If you use client-side hit detection, the client will "never" have the feeling of lag (but may, instead, have the feeling of someone else shooting them when they feel they alread dove into cover.)

In Topic: [HELP] Client not answering back

20 May 2015 - 10:01 AM

Put a breakpoint in the destructor for your class that contains the socket.
FIgure out where that class gets destructred, which will destruct the socket.
Now you know what the problem is.

In Topic: [HELP] Client not answering back

19 May 2015 - 09:00 PM

It's your code, and your Session class.
Perhaps create it with "new" and pass around a pointer instead of a copy?

In Topic: [HELP] Client not answering back

19 May 2015 - 11:13 AM

[code=auto:0]void Server::Start()
{
Session tSession(new SockHandler(IOService));
this->Acceptor.async_accept(tSession->getSocket(), boost::bind(&Server::AcceptanceHandler, this, tSession, boost::asio::placeholders::error));
}[/quote]

The Session dies as soon as Start() returns.

In Topic: [HELP] Client not answering back

18 May 2015 - 11:06 AM

You should set transfer_at_least to 2, not 1. As it is, you may get half of the length of the data.

Is topSocket actually the new socket you created and passed into accept()?

How are you calling io.run()?

PARTNERS