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!


Angus Hollands

Member Since 06 Apr 2012
Offline Last Active Jan 27 2015 09:27 AM

Posts I've Made

In Topic: Average user packets per second

04 January 2015 - 12:21 PM

If you're trying to ensure that you don't flood clients with data, then it would be sensible to perform some dynamic throttling. Start with an estimate of what you might consider appropriate. When you start dropping packets, halve the estimated bandwidth, otherwise increase slowly by some constant value.

(Thanks to hplus0603 for this recommendation in a previous discussion)

 

I would also recommend only modifying this value (reduction or growth) after it can be confirmed that data has been received from the client since the last change was made (as there might be n packets dropped before the client receives data at a reduced rate from the server due to the packet loss, so you would actually reduce the bandwidth by 2^n if you did not take this into account).


In Topic: Getting SignalR trip time

30 December 2014 - 05:01 PM

I'm not sure why you need to determine the trip time. Essentially, the client should start a timer - fixed at a constant "good enough value" to cover the RTT + calculation time, and the server should attempt to return any results as fast as possible. The client will simply wait until the timer elapses, then poll a queue for the returned result, apply and discard it.

You don't need to have the result arrive "exactly" on time, unless there is some-how potential for cheating.


In Topic: Chatbot in 18 lines of code (Python) help.

04 December 2014 - 04:26 PM

And a condensed version ;)
 

from __future__ import print_statement
import random
from speech import *

CONVERSING = True

memory = []
greetings = ['hola', 'hello', 'hi','hey!','Hello','Hi']
questions = ['How are you?','How are you doing?']
responses = ['Okay','I am fine']
validations = ['yes','yeah','yea','no','No','Nah','nah']
verifications = ['Are you sure?','You sure?','you sure?','sure?',"Sure?"]

engagement_pairs = (greetings, greetings), (questions, responses), (verifications, validations)

while CONVERSING:
    lang = 'en-US'
    speed = .3
    
    userInput = raw_input(">>>Me: ")
    for triggers, outputs in engagement_pairs:
        if not user_input in triggers:
            continue
            
		random_output = random.choice(outputs)
            
        say(random_output, lang, speed)
        print(random_output)
        memory.append((userInput, random_output))
        break
        
    else:
        if 'sure' in userInput:
            response = "Sure about what?"
            say(response,lang,speed)
            memory.append(('sure',response))
            print response
        else:
            say("I did not understand what you said. Goodbye",lang,speed)
            CONVERSING = False

In Topic: Calculate number sequence

12 August 2014 - 05:50 PM

You're performing a multiple of two, n times, which is the same as one multiplication of (2 ^ (n-1))

 

I.E

 

5 * 2 ^ (6 - 1)  is 5 * 2 ^ 5


In Topic: Smoothing Corrections to Client-Side Prediction?

11 August 2014 - 05:38 PM

I recognise that this is an older post, but I feel there's something else to add.

 

For local players, the most important thing is input responsiveness. For remote players, something like EPIC would be a means of smoothing irregular updates due to packet loss. However, movement packets which are lost before the server receives them (in time) incur miscorrection on the server, for the next move (assuming that the lost packet contained changed inputs).

 

The only means that I can think to correct this is to send redundant previous moves to the server, (I.e 6 moves worth). If the server looses input for T 2, 3, 4 and receives moves for T5 +, it can use the last 3 moves to recover.

 

This will fix the stuttering corrections on the client, for this scenario.


PARTNERS