So we have the see_invisible var wich works as the maximum level of invisibility the mob can see.
It has some problems because you can't differentiate the level of invisibility of 2 objs of the same type for instance. If one obj is invisible to you, all other objs of the same type are also invisible. That sucks for hiding trees etc.
What I'm requesting is a new var, set_invisible_list, (or any other handle), wich would be an list where the atom that you wanted to turn invisible for the mob would be added to.
This would allow for things like very easy to use roof hiding/hiding trees that you get behind, etc, usign crossed/uncrossed.
It would also be pretty cool if it was an associative list, carrying the alpha value (0 by default) that you wanted to set the obj to, instead of outright turning it invisible.
Thanks :) Hope you consider it.
ID:2489579
 Jul 26 2019, 4:50 pm (Edited on Jul 26 2019, 5:06 pm)
|
|||||||
Not Feasible
| |||||||
Yeah I want to adjust visibility individually and also want to use it together with crossed so none of those suggestions would work out.
| |
You can do that with the second one just fine, though
| |
invisibility needs tuned-up.
| |
Oh definitely, but unless you also want the thing hidden from view(), it is possible. If you do want it hidden from view(), though, it's not possible at all as far as I know.
| |
client.invisible = list( #wishlist | |
That was what I was suggesting xP. But with runtime atoms not type paths, and being an associative list with the alpha as the value.
| |
Example as it would be objects at runtime within the list, but I don't think it makes sense to handle alpha when invisibility is either visible or not.
| |
This would be a performance killer. There are workarounds you can use that would be a better fit for your needs.
| |
Lummox JR resolved issue (Not Feasible)
| |
Since you don't seem to be convinced that the image.override method works:
http://www.byond.com/developer/Kaiochao/HideBehind | |
NSBR wrote:
I love ya. I believed you, just thought that the request would be a better way to do it. The problem is that it would absolutely murder performance. Every time the client renders, it would have to check if every atom it was trying to render was among the list of objects that are marked as invisible. On top of that, the client doesn't receive object instances in the same way you are used to working with them on the server. It receives a series of appearance-related data, so it'd take more grunt work than just sending atoms to the client to ignore. Image overrides are how we do this sort of thing in the parlance of DM. | |
If you only care about hiding things visually, you can attach a blank image to the object with override set to true and only send it to the players you want the thing to be invisible for.