I would like it if we can create and object on the clients and server and tell it to move somewhere on both the clients and server but it's position won't be updated through packets. Once the object reaches it's destination the server would then update the object's position on the clients and tell it to stop moving on the clients. That would save a lot of bandwidth. I hope that made sense, if not let me know.
Perhaps there can be a way to toggle it between being a client side object and a non client side object
var/obj/o = new(clientside = TRUE)
o.sendUpdateToServer("loc&callFunction(Function(args...))")
Server side:
Function:
on completion if(src.clientside)sendUpdateToClient("loc")
Something to that extent, you can use Topic to listen for messages or some other function.
ID:105473
 Dec 8 2010, 3:38 pm
|
|||||||
Redundant
| |||||||
I don't care how the syntax is. I was just writing something to better explain myself.
| |
Zaltron wrote:
I don't care how the syntax is. I was just writing something to better explain myself. But the syntax doesn't help to explain. If you explain what you'd use these objects for we can figure out what the best syntax would be. If you just provide a sample syntax it's not clear what you'd use these objects for. It sounds like you'd want to use client-side objects for projectiles. Your description of the feature sounds adequate for some uses but not for others (do all projectiles travel in straight lines?). This is why focusing on the actual usage of the feature would be more beneficial. It would let us figure out the scope of the feature - what it should or should not be capable of. | |
What I would use it for would be to ship ships from one planet to another. They can do all the moving and angle changes on the client side and server side separately without sending packets. When the server side ship reaches the planet I'd send a packet to the clients saying it's finished and remove that object if it had not all ready reached the planet. The rate at which I update the ships moving across space looks smooth but takes up more bandwidth than I'd like. The problem is I have a lot of ships moving at the same time. Also, I have planets revolving around the sun which takes up more bandwidth than necessary. They are shaded based on where they are relative to the sun. If they were client side objects I could add in a "year" and determine the angle they should be relative to the sun based on the year. I hope that better explains what I'd use it for.
| |
I'm not sure how a decent solution could work without requiring some type of user-defined code running on the client. If the projectiles move between a fix start and target position it's simple but not very useful. If the end point is a moving target or if the motion is not a straight line then you'd need code to define the behavior.
This would be very useful for conserving bandwidth while boosting frame rates. For example, consider a baseball game. When the batter hits the ball, each client just needs to be notified of the initial position and velocity of the ball. Each client can compute the ball's path given this information. You can achieve a higher framerate because the server isn't broadcasting position updates every tick, each client is responsible for its own updates. | |
BYOND already has missiles as a client-side visual effect, and it has gliding for regular atoms. I think more could be done with gliding, but I don't quite grok what you're suggesting here.
| |
I could see this leading to blatant cheating if it was used for anything other than graphical effects. I also doubt it would have much of an impact on bandwidth, and even further doubt if it would have any at all on frame rates.
| |
Falacy wrote:
I also doubt it would have much of an impact on bandwidth, and even further doubt if it would have any at all on frame rates. Instead of needing one message per tick you need one message overall (perhaps a second when the object reaches its destination). BYOND already has missiles as a client-side visual effect But missile can't be customized so there are very few cases where missile does exactly what you want it to do. | |
Basically you would be able to run functions on the client side telling an object what to do and where to go without it sending updates to the server unless you tell it to.
| |
With this in place, if someone has a bad connection, the server will freeze up while it waits for that one person to return the position of one object. It can get really bad. Ask anyone who's ever played Age of Empires in multiplayer mode.
| |
The Server keeps track of the movements. The server will update the client as needed. The client will never update the server unless someone how it to but that would be a bad idea because that would allow for a lot of cheating. The client run the same functions as the server so it appears as if everything is working normally. If anything it would speed up things for everyone else a significant amount.
| |
Zaltron wrote:
The Server keeps track of the movements. The server will update the client as needed. The client will never update the server unless someone how it to but that would be a bad idea because that would allow for a lot of cheating. The client run the same functions as the server so it appears as if everything is working normally. If anything it would speed up things for everyone else a significant amount. That's how it works right now. The server gets commands from the client, runs the functions of those commands, then gives the client the state of the game. | |
Warlord Fred wrote:
That's how it works right now. The server gets commands from the client, runs the functions of those commands, then gives the client the state of the game. The way I see this feature working is the developer can code up client-side effects and the server only has to send a message to the client to initiate the effect. As Lummox mentioned, the missile proc is a built-in example of this. The important processing is still done on the server but a little bit of client-side scripting could allow for some neat effects without bogging the server down. | |
If moving something from point A to point B is bogging down your server, you're doing it wrong.
| |
Falacy wrote:
If moving something from point A to point B is bogging down your server, you're doing it wrong. The computation for each moving object is simple but does take some measurable amount of time. As you increase the number of objects or the frequency of updates you can easily cause a significant slowdown. | |
Zaltron, I doubt it's going to happen anytime oon, When they want to work on something in particular Everything gets locked down except that. (Isometric, Flash Client)
| |
Ter13 resolved issue (Redundant)
Not feasible without an overhaul of BYOND's current structure. Client-side effects can be handled via image objects. | |
I don't think BYOND needs another awkward pseudo-syntax.
Client-side objects can have many uses. It's hard to figure out what the best implementation is. What might be sufficient for the usage you have in mind might not be sufficient for what I have in mind. I think it would be better to talk about ideas for how client-side objects could be used and we can arrive at implementation details later.