Flick to Client in Feature Requests

ID:231749
 
Jan 31 2012, 4:07 pm (Edited on Jan 31 2012, 5:11 pm)
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
The ability to flick an object that only a specified client/mob can see could have a major impact on what developers can do and help them improve greatly on performance of their game.

I don't imagine it would be too hard to implement into the language either. I assume the client already has everything that is needed, the server just needs the ability to pick and choose who sees the change. And of course the server's version of the icon changing could still override the client's flick.

Now to the reason why this would be so useful.

I will use one of my games as an example. Feval runs multiple maps on the same server and it has explosions which would normally create and destroy hundreds of objects all the time, which would be fine if it only had to this on each client rather than it all on the server, so I use a method to just hide and show already created explosion objects on each map.

This makes it so the game can support more games going on at once without a major impact on the server, but there's still an issue. Every map brings its own objects, so the problem gets bigger and bigger as more maps are added.

Now if I had the ability to flick icons to specific clients, I could use one set of objects (via the screen) for every map and simply flick the explosions of those objects to the people on each map accordingly.

Another example might be to have a board of global objects that everybody sees, but each one has special mouse over effects and you only want to display them to each player when they mouse over the object themselves.

These are just a couple examples of the benefits, but I assure you there are hundreds more.

So basically what I'm asking for is to add an optional client/mob (or list of) to the end of the current flick() and only they see the flick.

Addendum: If this isn't possible using the current flick proc, add a new one. It's purpose solely being to display an animation of specified object to a specified client. All the server would do is say "hey specified client, display this animation of this object to your viewer" much like the winset proc tells the client to make a certain change to the interface.
#1 Jan 31 2012, 4:17 pm
Supporting flick() for /image objects might also be a way to implement this. Although you wouldn't be able to save as many objects as your method, I think it would be a good way to kill two birds with one stone (poor birds!)
#2 Jan 31 2012, 4:24 pm
+
#3 Jan 31 2012, 4:24 pm
In response to DarkCampainger (#1)
DarkCampainger wrote:
Supporting flick() for /image objects might also be a way to implement this. Although you wouldn't be able to save as many objects as your method, I think it would be a good way to kill two birds with one stone (poor birds!)

I agree that flick() should work for images as well, but what I'm asking for wouldn't be satisfied (not even remotely) with such a change. It's not about only letting players see certain objects/images the server has, it's about using less to show more.
#4 Jan 31 2012, 4:28 pm
In response to Aaiko (#3)
Wait, so are the explosions not destroying things in your example? You just want to be able to flick a state on the "ground" object? I guess I don't understand why you can share a screen object, but not an image.
#5 Jan 31 2012, 4:33 pm
In response to DarkCampainger (#4)
DarkCampainger wrote:
Wait, so are the explosions not destroying things in your example? You just want to be able to flick a state on the "ground" object? I guess I don't understand why you can share a screen object, but not an image.

It can be an object, it can be an image, it doesn't matter. Basically what this change would do is turn any object into a client-sided object (visually). You could use a single object and display different icon_states of it to different players at the same time.
#6 Jan 31 2012, 4:47 pm
Yeah, flick() needs a lot of updating. I find it incredibly frustrating how looping overlays/underlays have their animation sequence messed up during a flick() event.
#7 Jan 31 2012, 4:58 pm
Falacy wrote:
flicking objects should already intelligently take clients into consideration. There are even some bugs due to flicking long animations on people who are out of view and then walk into view.
Regardless, I'm not sure how this could cut down on your object counts. You would still need the objects there to flick, wouldn't you?

You need at least one object in a certain location on the screen, yes. Basically what this allows is a hacky (and easy as far as I know) way to let developers display client-side animations to certain players.

Now, back to my Feval example I used in the request post. Feval has an unlimited amount of maps that can be running at the same time on the same server. Each map has a set of explosion objects, placed at every coordinate, which is shown and hidden when needed, instead of creating and destroying hundreds of objects for every explosion. It greatly reduced lag on the game.

So each map has about 500 objects on it. When you have 10 maps, you have 5000 objects doing something so simple. With this change, you can have only 500 objects displayed on the screen for a million maps, and the explosion animation of them displayed to the people on the proper maps.

This is only one example, though. The whole point is you can pick and choose who sees what animations without the server creating extra objects (and then most likely destroying them) every time you want to display something.
#8 Feb 9, 1:14 pm
Going to bump this. It is very important even more-so now that I'm working on smaller games.

If the above posts were confusing, basically what I would like is for the flick() proc to have an extra optional parameter (a mob or client or maybe even a list of them), so flick(icon, obj, client), and what would happen is instead of it flicking to everybody that can see obj, it would only flick to the specified client(s).