MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002043Zandronum[All Projects] Suggestionpublic2015-01-02 06:172015-01-02 06:38
ReporterZzZombo 
Assigned To 
PrioritynormalSeveritymajorReproducibilityN/A
StatusnewResolutionopen 
PlatformOSOS Version
Product Version2.0-beta 
Target VersionFixed in Version 
Summary0002043: Separation of actor logic between the client and server
DescriptionReference quote:
<ZzZombo> I was thinking about having actor class structure being separate and different between client/server.
<ZzZombo> Example: I have a tracking missile that constantly spawns ParticleFountain as a trail. The latter is +CLIENTSIDEONLY currently.
<ZzZombo> It could be rewritten like, on server, it's a tracking missile that doesn't spawn the particles at all; on clients, it doesn't call the homing codepointer.
<ZzZombo> Win-win for both parties and less bandwidth usage.
<ZzZombo> It's how it's done in Source, and gives great possibilities.
<ZzZombo> More complex example: I have monsters that use extensively CustomInventory giving as a mean to avoid copy-paste. But online the client doesn't predict item giving so it causes major freaking out. I could instead split the monsters in two, on client I'd replace such places with whatever, the server will do the rest.

I suggest to allow separate logic between client and server for actors. It would address several problems:
* Jumping handling: the client online ignores any jumps it can't handle n its own and continues execution of states; it often is not desirable. With this modders could make the actor stay on the frame (with the wait keyword) until the server tells the client to change it.
* Reduce bandwidth and CPU usage: see the examples in the quote.
Steps To Reproduce
Additional InformationOne way to implement this is introduce a new "ClientStates" block (opposed to the "States" block) and make the client use it if exists. Another is to have a class literally split into two versions, for each party, and somehow linked together. There are some issues to resolve first tho:
* how the server will tell the client to change state of an actor?
* if the client performs an action resulting in destroying of an actor, but not the server, what to do? We can just consider this "don't do that!".
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-01-02 06:17ZzZomboNew Issue
2015-01-02 06:38Blzut3Note Added: 0011205

Notes
(0011205)
Blzut3   
2015-01-02 06:38   
Your scenario could be solved in other ways. Some notes: First, movement functions which rely on the server's information are no-op on the client any way so not calling it won't help much at all. Secondly, having the client run different states would cause issues since the server needs to instruct about jumps, which in order to conserve bandwidth is transmitted in an encoding that relies on the state sets (including those without labels) being the same. If we haven't already we have plans to condense the encoding even further which will increase this dependency.

Your more complex example could probably be fixed outright. I'm guessing it's a case of the server sending redundant state changes.