0002043: Separation of actor logic between the client and server

Chat on our Discord Server Get the latest version: 3.2
Source Code

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0002043

Zandronum

[All Projects] Suggestion

public

2015-01-02 06:17

2015-01-02 06:38

Reporter

ZzZombo

Assigned To

Priority

normal

Severity

major

Reproducibility

N/A

Status

new

Resolution

open

Platform

OS Version

Product Version

2.0-beta

Target Version

Fixed in Version

Summary

0002043: Separation of actor logic between the client and server

Description

Reference 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.

Additional Information

One 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!".

Attached Files

Relationships

Notes
(0011205) Blzut3 (administrator) 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.

**Issue Community Support**
Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2015-01-02 06:17	ZzZombo	New Issue
2015-01-02 06:38	Blzut3	Note Added: 0011205

Questions or other issues? Contact Us.

Links

Doom and Doom II are the property of id Software.