In response to Monster860
+1 ^9001
In response to Monster860
In response to PJB3005
Thanks, PJB. I knew it was a duplicate but couldn't be bothered to hunt for the original. I've merged the threads now.

I have to admit I'm still not sold on this bitflags idea. It's so limited in many ways, even while it's an expansion from (and in some ways complementary to) the old system.
remember my suggestion its less limited, and would be even less limited if you expanded bitflags to 24bits (or 32 bits if you seperated float and int as value types and did some auto conversions =P(ok, its no where near that easy, but i can dream)).
In response to MrStonedOne
That was way too convoluted.
What if we did this: we have an invisibility bit index in appearances. Then, we put a list of numbers in mobs. When we want to test the invisibility of something we divide the index on the invisibility by 16. We get the number in the list from that division and check the bit of the modulo. You could internally store it as a C array to speed it up, and you could use as many invisibility groups as you want
Alternate idea:

C/C++ array of ints/longs/whatever, with the DM interface being an (implicitly ordered) list of integers, ie the value {5, 1, 0, 0} (assuming uint32 values) represents bits 0, 2, and 32, so the DM value is list(0, 2, 32).

DM-side, you do the following (example in the same format as the OP):
// more *integers*; the next groups are 2, 3, 4, ...

name = "Potion of dangersense"

// or |=; they should likely do the same thing
M.see_invis_groups += INVIS_GROUP_TRAPS

M.see_invis_groups -= INVIS_GROUP_TRAPS

name = "Potion of treasuresense"

M.see_invis_groups += INVIS_GROUP_TREASURE

M.see_invis_groups -= INVIS_GROUP_TREASURE

C-side, you're not in list-of-strings or similar, you just have a bit array - with an array of 32-bit values, to check whether the mob can see group 20, you check array[0] & (1<<20), to check group 40 you check array[1] & (1<<8), to check group n you check array[n >> 5] & (1<<(n & 31)).

Probably needs some logic for resizing/expanding the array, or a sensible maximum value that's always allocated (somewhere around 128/256 perhaps? That'd be 4/8 int32s or 2/4 int64s, and should be enough for most games).

Obviously, converting it to a DM value would take a while, but most of the time you would only need to check or change whether x is present, which is only a few operations.

edit: is the forum trying to fix my bitshifts by closing HTML tags at the end?

double edit: i remembered this needs to be on every atom so revised my numbers slightly.
worth noting, for naming purposes, it should probably be named visibility list.

Another solution for this is accepting objs in client.images and having an appearance flag for the object to not be streamed in a normal map send, that way we wouldn't need two objects per phased object. Or perhaps a "map" datum introduced for even more fine grained control, but that might get into another realm of difficulty to implement.
I think at this point this should just be added. Probably for density as well, to be honest.

It's limited, yes, but it is 24x less limited than what we have currently and I don't think there is another feasible solution to that problem in the engine short of BYOND suddenly becoming a 64 bit program which I don't see happening any time soon.
Yes please. And Yes please to the similar density mask too.

(Don't know if this'll help sway you one way or the other, bu Unity's layermasks only leave room for 32 layers out of the box)
The peoples republic of china wrote:
It's limited, yes, but it is 24x less limited than what we have currently.

This. The current system is absolutely horrible, because you can't do non-hierarchal conditional invisibility. Almost anything is better than it.

You could even use an unsigned long here for 32 bits. Can't use u long long due to 32-bit, but even an unsigned long would be an improvement over the 24 float mantissa.
Page: 1 2