Author Topic: Star Trek... new feature ideas and setup (Read 13871 times)

ACagliano · « **Reply #45 on:** October 12, 2013, 06:43:31 pm »

so the hash is just basically a compression of the data we intended to send anyway?

Sorunome · « **Reply #46 on:** October 12, 2013, 07:12:18 pm »

basically, yes. Even though there are different strings that result in the same hash, it is very unlikley for it to happen

ACagliano · « **Reply #47 on:** October 12, 2013, 07:53:37 pm »

ok. now correct me if im wrong, but the hash cannot be reversed. As in, you can hash something, but you cannot unhash it, at least not without extensive computational power.

Streetwalrus · « **Reply #48 on:** October 13, 2013, 01:48:19 am »

True. That's why the server sends in real time a delta update (is only what has changed). Then the calc and server both compute a hash of the calc's visible area and if the server sees an invalid hash, it'll resend the whole thing. This can reduce bandwidth a lot (although with calcs, well, it's not even a KB per packet

).

Sorunome · « **Reply #49 on:** October 13, 2013, 05:22:38 am »

so maybe to reduce computing power of the hash we should just send the raw data, lol, as it isn't *that* much i guess (or just let the server calc everything and send the coordinates)

Streetwalrus · « **Reply #50 on:** October 13, 2013, 05:29:21 am »

Yeah

probably the best solution. Hashes are kinda overkill here. What'd be cool is if the server could run off a RasPi.

Sorunome · « **Reply #51 on:** October 13, 2013, 05:30:22 am »

it will probably be able to because i'll use python 2.7 for it

ACagliano · « **Reply #52 on:** October 13, 2013, 09:16:14 am »

I thought hashes would be a bit overkill. The entire dynamic doesn't have the time or the computational power to be doing hashes in addition to the normal calculations. At least thats what I think.

What do u think about my refresh rate idea, btw?

Sorunome · « **Reply #53 on:** October 13, 2013, 09:56:10 am »

maybe once every second? I don't know about the calculator part, but the server part could also handle way less

ACagliano · « **Reply #54 on:** October 13, 2013, 10:52:17 am »

Well me me ask you a question... Im gonna implement a cap. 30 players to a world. Assuming the world is maxed out (30 players online), each requesting data, how well could the server keep up? How often could we request data without getting backlogged?

Sorunome · « **Reply #55 on:** October 13, 2013, 10:59:08 am »

I don't see any problem with 30 connections per second, just keep in mind that that way each calc would also recieve 30 coordinates/data per second.

ACagliano · « **Reply #56 on:** October 13, 2013, 11:12:26 am »

thanks fine. could we increase the frequency? to less than a second? like every 1/4 or 1/2 of a second? but give the server the ability to force you to get the data less often if it cant handle it.

Sorunome · « **Reply #57 on:** October 13, 2013, 11:13:44 am »

i guess we could server-side, it also depends on how powerful the server is, but i guess it should be fine

ACagliano · « **Reply #58 on:** October 13, 2013, 11:50:26 am »

Ok. What I'm gonna do, is set default refresh rate to 1 second, but give the user a slider bar, to adjust up or down. Adjusting the refresh rate up gets data from the server more often. adjusting it down gets it less often.

My initial thought was for max refresh rate to be every .1 second and minimum to be 1 second. But I'm thinking to make max .25 seconds and max like 2 seconds or maybe 1.5.

on the server side, you can create variables to keep track of incoming requests for data, and responses to those requests sent. maybe then create a net figure. If we are trending toward a backlog (more incomings than outgoings), the server sends out a broadcast "drop refresh rate" message, that all non-Basic 83+'s will comply with.

ben_g · « **Reply #59 on:** October 13, 2013, 12:25:06 pm »

I don't think you have to worry much about the server not being able to keep up with the calcs, unless you are doing really complex server-side calculations. If the server has to handle so many objects that it starts to cause lagg, the calcs won't be able to handle it either anyway.
And for the request rate: I'd go for 2-4 times per second (standard), and add some kind simplified calc-side object handling to make everything more smooth (eg. send the speed for moving objects to the calc and make the calc cumpute it's movement untill it recieves new data, so that moving objects look like they move instead of 'teleporting' from one place to another).

Author Topic: Star Trek... new feature ideas and setup (Read 13871 times)

ACagliano

Re: Star Trek... new feature ideas and setup

Sorunome

Re: Star Trek... new feature ideas and setup

ACagliano

Re: Star Trek... new feature ideas and setup

Streetwalrus

Re: Star Trek... new feature ideas and setup

Sorunome

Re: Star Trek... new feature ideas and setup

Streetwalrus

Re: Star Trek... new feature ideas and setup

Sorunome

Re: Star Trek... new feature ideas and setup

ACagliano

Re: Star Trek... new feature ideas and setup

Sorunome

Re: Star Trek... new feature ideas and setup

ACagliano

Re: Star Trek... new feature ideas and setup

Sorunome

Re: Star Trek... new feature ideas and setup

ACagliano

Re: Star Trek... new feature ideas and setup

Sorunome

Re: Star Trek... new feature ideas and setup

ACagliano

Re: Star Trek... new feature ideas and setup

ben_g

Re: Star Trek... new feature ideas and setup