ID:2164254
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
It would be nice to have the ability to create new objects that are processed by the client. The main reason I'm suggesting this is to help shift the cost from HUD elements. If you want to make a completely HUD driven inventory system that includes tool-tips, you'll need to do some processing. If the tool-tips are done on MouseEntered() but are completely dynamic (since the items are dynamic), you have even more processing to do. Not only are you processing this, you're also processing -every- HUD item for the inventory. HUD objects flexibility is much greater than interface elements. screen_loc is an AMAZING variable.

Here is a more in depth example;
Let's say I've created a shop that you need to click the item for sale (HUD object) which will have a glow effect and then ungray the Buy button (if they have the money). The only information I need back to the server is, which object was clicked. I have already stored what item should be what on the players screen, so now I need to do a few calculations on the server for security. Such as, how much money they have, can they buy it, etc. What the server shouldn't really need to handle is how the displays are working. The client should process, "i clicked the item, now i need to ungray the buy button, i need to put a nice glow effect around the item, and i need to update the cost display."


While it might not sound like a big deal, if the objects are stored on the client, it's less objects on the server. It's less CPU cost for the server, and it's less memory needed for the server. There would need to be fail-safes so you can't just overload the clients computer of course. In my opinion, this would help out extremely for larger games. It would also open up the possibility for much better effects on the players HUD.
If we get better mouse movement handling (that for example doesn't use verbs), the performance should be better. The client is what does most of the heavy lifting with determining what you click IIRC and server does a tiny bit of validation. You could also try using a browser overlay on the map.
I made such an object that was controlled serverside recently using mousedrag. It works relatively well for people with low ping, but for people playing cross region it's fairly nonresponsive (people with 100+ms I'd say find it very noticeable when it isn't updating as their mouse moves) which is very unfortunate.

Though it really is questionable with the amount of Byond logic is serverside if this is feasible. I hope such a thing is possible at some point in the future as it would be useful for things I would like to try personally.
The biggest issue is that the only thing the client knows about is appearances, such that atoms with the same appearance would be indistinguishable to the client. (I don't even think the client knows what type these things are) So it would be hard to have client side logic if the client side script can't actually tell what anything is.

If a freeform text value was added to appearances, you could get around that issue, but now appearance churn is much higher.

I think there is some info not attached to the appearance that's per atom thats sent over and maybe it could be added to that to lower on appearance churn, but that would be a non-trivial expansion of the network protocol and footprint, as well as memory footprint on the client.

It would be doable, but i doubt lummox will find the effort worth the reward.
Hard to say, speaking from experience the ability to make clientside logic is basically a requirement for a responsive UI that responds to mouse control. The only question is really how much work such a task involves.

Even without sending any information back other than the regular mouse actions, being able to manipulate information without the delay of ping based on current mouse location is incredibly useful.