Simply put, our chat system will always be part of our system.
I don't get what you want to express with that. I never suggested to make the chatsystem independant from psserver, did I?
To use your lighting example, you need to know how it actually works.
Well.. Again my "dangerous half-proficient knowledge" coming from the CS devs and the conference..
They are working on shading systems and if I understood it correctly, one is working similiar to what I described. I don't know a lot about it, so I can't give you details, but that's how far I got it.
If it is too CPU intensive to calculate realtime hitbeams (I use your term although I don't know if that is really the correct word) for all items and walls, I can think of two tricks how to reduce that load.
First is to place entities with a relatively big expansion at locations that can be expected to be non-visible for a lot of people, like rooms, or areas behind walls and such. The entity itself is invisible for the player but included in the maps themselves. As an example such an entity is placed in a room, filling it nearly completely, leaving little space at the entrances, as the server needs to react quickly when someone walks out. The client now calculates whether it can "see" the entity or not. If it cannot "see" (i put it in parenthesis as the entity is only visible for the program, not the player) it sends to the server "entity 'exampleroom' is not visible for me". Now the server checks if other entities are actually in the space of entity 'exampleroom' or not. If there are other entities in that space, the client can't see them neither, so the movement data won't be sent to the client.
If any spell or other effect makes one or all entities in that room visible (for the player or relevant for proximity), although they are included in entity 'exampleroom', the server may send the relevant data, although the client doesn't expect any, but that doesn't should produce any problems.
The second idea I have to reduce the CPU load for the proposed system is to place a 3D-grid of "lighters", kind of lightsources but invisible (again). The client would need to check if it can receive light from a lighter (the positions and lightintensity is known to the client of course, they are included in the maps again). If light cannot be received by a defined lighter, because of rain, walls or anything, the client gives back this info to the server. The size and intensity of the lighters probably need to be extrapolated by the lighting maps. The clue is that, if light cannot be received from a defined lighter, it is impossible to see something behind a lighter that can't be seen, if it is of the same or smalller size and/or has a lower light intensity.
I think the first idea is best in cities and dungeons with many edges while the second could be used best in open areas.
That system will minimize the unnecessary packages sent about movement, leaving the problem with the number of necessary packages.
How do network-FPS handle the problem about movement packages?
Oh, an idean just popped up:
I try to explain:
Lag is a big problem in fights of all kinds, PvP and PvC, because some people have shorter ping, thus nearly no latency after hitting a movement button, while others have a long ping, and often don't see the movement of the opponent till it is too late. With mobs it's the same. Trying to evade mobs that actually aren't at the position anymore are really disturbing.
So the idea is to synchronize all movements (of all entities, included players), at the cost of ping. If that works as I imagine, everyone would get lag after hitting a movement key, no matter how much the actual ping time to the server is. The clue is that everyone has about the same latency, included PvC fights, thus no misjudgement of situations due to lag anymore. I think to have a fixed, relatively big overall lag for movements is a good price for fairer/less frustrating fights, more independant on ping times.
How I imagine it could work:
The server checks the ping to the clients, calculates the average ( := averageping).
Now the server adds a synthetic latency before sending movement packages to clients that have a better ping than averageping.
For mob-player synchronisation I think a time synchronisation NTP-like (don't think of outsourcing, think of just taking the code from NTPd and building it into psclient/server) is best. On startup, the client gets sync'ed with the server. The server adds timestamps to the outgoing movement packages and the client can reconstruct the movements.
That's the main principle of the whole idea. Make the clients reconstruct the events, but synchronised on everyone's PC, in logical order.
There's no way to cheat client-sided with this, as it has no effect to change the timestamps for (from the servers side) incoming movement packages, as the client doesn't know the "future" moves from the opponent. Actually I don't think it's of much use to implement timestamps for incoming movement packages at all, at least not for this idea. The unfair advantage given by a different geographical location thus lower latency is minimised this way, also the problem with the mobs (the server can make the mob react on movement of the player while the player has no data yet) should be solved with that.
