search

vloup / sgfork

Automatically exported from code.google.com/p/sgfork
GNU General Public License v2.0
0 stars 1 forks source link

Shared variables between client qvms #75

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Overall description of the new feature:
Add shared variables between cgame & ui.qvm to avoid having the same
variables in many copies.
For example, the size used by bg_weaponslist on the client is two times
sizeof( bg_weaponslist ) because it is one time in cgame and another in ui.qvm.

Variables to control the new feature:
N/A

Original issue reported on code.google.com by kikc...@gmail.com on 24 Oct 2009 at 9:46

GoogleCodeExporter commented 9 years ago 
I think of the following way in for the GAME -> CGAME: via config string.
You just send info from the server in the clientBegin (I'm not sure about it) 
with 
all bg_* lists and values.
And once the server has changed any of the bg_* values it sends via config 
string 
only modified string.
I'm not sure about GAME -> UI way of transmitting the lists. But probably you 
are 
right and using of CGAME -> UI way is better, so once the values in CGAME are 
changed 
(and at the initial stage). This way we don't have to use network.
I think current mechanics of CVars can help a bit to solve the trouble. I don't 
mean 
to make it CVar, but to use the similar mechanics to solve the trouble.

So each qvm will have own lists (as it is done now) which will be updated only 
during 
theirs change or at the connection time.
They have to be at each qvm to make the process of reading them fast. If each 
time 
during reading of them we will have to ask server to transmit the variable to 
us - it 
will be overload for network (even between local qvms it is not worth it - we 
lose 
speed).

I set priority to high, since it is vital feature for SGFork.

Original comment by igorpana...@gmail.com on 12 Nov 2009 at 6:38