invisibility bitflags

Page: 1 2
ID:1870524
 
Jun 10 2015, 5:00 pm (Edited on Nov 22 2015, 8:32 am)
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Right now, invisibility is dumb, it's very restrictive as to what you can do, and to get the level of control really needed for advanced stuff, you're gonna start juggling with images which is a whole different can of worms.

the current invisibility system uses a scale from one to one hundred, I suggest a system that uses bitflags, you could do, for example:

#define INVISIBILITY_TRAPS 1
#define INVISIBILITY_TREASURE 2
(more bitflags)

/obj/item.../dangersense
    name = "Potion of dangersense"

/obj/item.../dangersense/on_use(mob)
    mob.see_invisible |= INVISIBILITY_TRAPS

/obj/item.../treasuresense
    name = "Potion of treasuresense"

/obj/item.../treasuresense/on_use(mob)
    mob.see_invisible |= INVISIBILITY_TREASURE


This works interchangably, only other way to do it is through images, and like I said, that's a whole different can of worms.
Jun 10 2015, 6:52 pm
This kind of thing has come up before, but to be honest I've never found the invisibility groups idea very workable. I don't think I'd do it as bitflags, at least, because that's too limiting which kind of defeats the purpose.

I'm still on the fence about the groups concept. I didn't like the syntax I saw for it before, and I'm unclear on how I'd implement it. Assuming I could get those two aspects resolved, I'm otherwise not opposed to it.
Jun 11 2015, 4:41 am
How would bitflags be too limiting? I mean yeah there's the effective limit of 16 bits, but that's not that bad.
Jun 11 2015, 10:00 am
That's it, basically, is the 16-bit limit. I'm not big on it because even though it's the easiest method to implement (by far!), as long as I'm expanding invisibility anyway I'd rather the expansion be more open-ended.

Maybe that's not practical, though; the idea of invisibility groups would definitely be a lot harder to deal with.
Jun 11 2015, 11:55 am
Well, the other solution would be a list of text strings, atleast that's the simplest I can come up with.
Jun 11 2015, 1:38 pm
Maybe that's not practical, though; the idea of invisibility groups would definitely be a lot harder to deal with.

Maybe you should do something similar to what overlays lists do. They generate a unique list based on contents, except they are sorted before being hashed. That way it's not a list per type, but rather a list per unique visibility combination.
Jun 11 2015, 1:42 pm
The problem with the list approach is that it's way, way less fast than bitflags. At least with bitflags I can quickly compare if a viewer's flags match any of the object flags. With lists, the process is non-trivial.
Sep 15 2015, 11:09 am
This got linked, Then I got high and started think about how to do this, then I got an idea while on the john, so I'm gonna necro this thread to bring it up.

Hybrid of current and bitwise!

Viewables:
invisible_flags //23 bits (16 + 7 more with abuse of \<\< operator) what flags can the viewable be seen on (any one flag must match)
invisible //normal function


Seers:
see_invisible_flags //23 bits (16 + 7 more with abuse of \<\< operator) what flags can the seer see
see_invisible //normal function
see_invisible_mode //set the see_invisible mode of this seer, defaults to INVISIBILITY_SCALE can be any one of:

INVISIBILITY_SCALE = invisible/see_invisible var use only, normal less than or equal comparison
INVISIBILITY_BITFLAG_INCLUDE = like INVISIBILITY_SCALE, but also allows the seer to see any viewables when any of it's invisible_flags are in their see_invisible_flags
INVISIBILITY_BITFLAG_EXCLUDE = like INVISIBILITY_BIT_INCLUDE, but inverse, Don't show matching viewables.
INVISIBILITY_BITFLAG_ONLY = Only show viewables with matching bitflags, ignore invisible/see_invisible
INVISIBILITY_BITFLAG_INVERSE = like INVISIBILITY_BITFLAG_ONLY, but inverse, Don't show matching viewables.



Over all extremely open ended, we can even look at any vs all matching for the flag, but i'm not sure if that should be decided on seer or viewable.
Sep 15 2015, 3:39 pm
too complex imo, you want something that is simple

just have string named sets of invisibility layers, any given mob can see the set of invisibility layers they have in their see_invisible_list, and an icon can exist on one or more of the invisibility layers (so it can been seen under multiple circumstances)
Sep 15 2015, 3:41 pm (Edited on Sep 15 2015, 9:38 pm)
just have string named sets of invisibility layers

Nope, NO STRINGS This has to be checked FOR EVERY ATOM in view FOR EVERY CLIENT.

String operations just aren't feasible.

My system might be the best you can pull off with any sort of performance.

Its complex, but it's flexable and it's fast, 1 comparision, 1 jump table, and a few bit wise operations.
Sep 15 2015, 3:51 pm
numbers then, the actual key doesn't matter because it can be optimized inside byond anyway.

An internal c strcmp should be fast enough
Sep 15 2015, 3:51 pm
In response to Lummox JR
Lummox JR wrote:
The problem with the list approach is that it's way, way less fast than bitflags. At least with bitflags I can quickly compare if a viewer's flags match any of the object flags. With lists, the process is non-trivial.

Nov 22 2015, 8:52 am
whats the feasibility on increasing the bitflag limit and implementing it that way if 16 bits is not enough.
Nov 22 2015, 9:39 am
I'm glad I'm not the only one that dislikes the current invisibility settings!

MrStonedOne's suggestion looks extremely appealing to me. Much better than the current invisibility settings. If his suggestion is still too limiting, you can use images. At least with his suggestion you have a variety of invisibility settings that will work natively without having to resort to using images. I'd imagine it will suit most needs.

As for it being complicated- I don't know about the implementation, but the use of bit flags is not complicated in DM and would be considered extremely easy imo.
Nov 22 2015, 11:31 am
well I know bitflag usage is simple but i was worried on the difficulty of increasing the limit from 16 bits to 24 or 32 bits
Nov 22 2015, 12:37 pm
IEE 754 supports 24 bit mantissa; so thats all the precision that we can get out of it. The numbers need to be cast to integers or the mantissa extracted instead of shorts. There is no difficulty.
May 1 2016, 12:30 pm
Bump!
May 1 2016, 12:47 pm
Bump ++
Aug 3 2016, 8:49 pm
It seems with the advent of plane masters this is now completely possible in a somewhat limited way.
Dec 4 2016, 6:25 am
The current invisibility system is not very flexible, you cannot selectively choose what to display, resulting in some very unwieldy code (see: camerachunk and it's 4000 image objects)

So my proposal is to add a new invisibility bitfield var to the appearances, and a respective var to mobs for controlling what they can see, and making it so that if the var on the appearances contains any bits that the var on the mob doesn't have, then it's invisibile.
Page: 1 2