MantisBT - Zandronum
View Issue Details
0001158Zandronum[All Projects] Suggestionpublic2012-10-30 23:302013-01-21 20:04
Dusk 
Dusk 
normalfeatureN/A
closeddenied 
 
 
0001158: ACS network variables
This has been a little pet project of mine for a while. The idea is to make a standardized way of updating variable information from server to client instead of relying on hacks to call clientside ACS from the server to pass variable data. I've ended up using those hacks.. that stuff really gets REALLY messy, especially when you need to send stuff to newcomer clients.

So what's going on is that you declare a variable as net with:
net int x;

and then change its value in a script, and zandronum would update the clients with the new value. The values are checked every tic against the last values to keep bandwidth use minimal.

I've had the netcode in place for a while and just now got the compiler to stuff the netvar info into the object file. Now I'm piecing this together.

One little concern of mine is that right now you can also declare world and global vars as net. I'm not sure if it's a good idea, as one module could potentially declare a world/global var as net while another would not.. I don't think it'd be adding much anyway and the code would be a lot simpler without them. Would there be need for synchronized world/global vars? I know synced global vars would make GlobalVar/GlobalArray selectors of SBARINFO's DrawNumber actually usable online, but I can't think of anything besides that.

Naturally I'm planning to have this tested throughly with neurosphere when this is completed.
No tags attached.
Issue History
2012-10-30 23:30DuskNew Issue
2012-10-30 23:30DuskStatusnew => assigned
2012-10-30 23:30DuskAssigned To => Dusk
2012-10-30 23:56DuskDescription Updatedbug_revision_view_page.php?rev_id=2877#r2877
2012-10-31 00:24DuskNote Added: 0005261
2012-10-31 00:30DuskNote Edited: 0005261bug_revision_view_page.php?bugnote_id=5261#r2879
2012-11-09 18:12DuskNote Added: 0005341
2012-11-09 18:39DuskNote Edited: 0005341bug_revision_view_page.php?bugnote_id=5341#r2932
2012-11-09 18:39DuskNote Edited: 0005341bug_revision_view_page.php?bugnote_id=5341#r2933
2012-11-09 18:41DuskNote Edited: 0005341bug_revision_view_page.php?bugnote_id=5341#r2934
2012-11-09 18:41DuskStatusassigned => feedback
2013-01-21 20:04DuskNote Added: 0005811
2013-01-21 20:04DuskStatusfeedback => assigned
2013-01-21 20:04DuskStatusassigned => closed
2013-01-21 20:04DuskResolutionopen => denied

Notes
(0005261)
Dusk   
2012-10-31 00:24   
(edited on: 2012-10-31 00:30)
'https://bitbucket.org/CrimsonDusk/neurosphere/changeset/702d9aebd40d502b289195078c4537a9 [^]'
Here's what I have so far, aside from the compiler changes of course.
Again, I'm not sure whether world/global vars should be kept.

EDIT: edited compiler, sources and win32-binary
'https://dl.dropbox.com/u/66055976/acc-netvars-src.zip [^]'
'https://dl.dropbox.com/u/66055976/acc-netvars-bin32.zip [^]'

(0005341)
Dusk   
2012-11-09 18:12   
(edited on: 2012-11-09 18:41)
Update:'https://bitbucket.org/CrimsonDusk/neurosphere/changeset/b8593c94bd3abd7e24bb809ab801eb12 [^]'
Decided not to have net world or global vars because I don't think it's worth the additional trouble to have such things around. Earlier revisions have the code though in case I'm proven otherwise.

Now I guess I just have to update the compiler again. I'll keep dummy world and global sections in the bytecode just in case. They'd just be two bytes anyway (one zero to mark no net world vars and one zero for no globals, this way we'll be future compatible in case we decide to have net world and global again)

EDIT: Compiler diff here:'https://dl.dropbox.com/u/66055976/acc-netvars.diff [^]'

This is pretty much ready for testing. Anything to note here?

(0005811)
Dusk   
2013-01-21 20:04   
I've been thinking about this issue and came to the conclusion that having netcode for ACS variables would be bad design. The current implementation can only do server->client and is restricted to ACS only - this is useless for DECORATE unless hacks are used and we don't want that...

I'll try come up with something better.