I'd be more in favor of built-in atom procs that accept witnesses and return TRUE or FALSE. (They'd return TRUE by default.) BYOND could call them automatically and then developers could base the decisions on whatever the heck they want.

atom.CanSee(Witness)
atom.CanHear(Witness)

I believe this should be moved to "On The List" or "Needs Discussion" but as far as the feature suggestion itself is concerned there would be two values related to this.

1.Invisibility
2.See_Invisible

Now Invisibility should probably stay a single number that you'd use as a representation of something you think is important in your determinations of what you want to see or not see.

See_Invisible would be whatever type of data that BYOND sees fit that is easily enough edited & allows for speed but would allow it to determine multiple invisiblity values from it in w/e internal way it wants to so that you can specify in some way each value for Invisibility you want to allow that mob to see.

---Basically I am saying implement this however you want, but just try & keep it simple to work with & try & keep the speed that BYOND has tried to work hard to keep or improve on to make it even faster.

Chowder wrote:

Forum_account wrote:

Images are clumsy to use but if you have a clear definition of what you need to do, you can write some simple functions to abstract out the nasty details.

Images don't have moving states. Do you have a workaround?

No, but that's an entirely separate issue. That's why I said this:

"I agree that images could be improved, but then we should be requesting just those improvements. Instead of saying, "Tom, please do X, Y, and Z for us" we can say, "Tom, if you do X we can do Y and Z." By phrasing it that way I think we have a much better chance of X ever getting implemented."

Rapmaster wrote:

Forum_account wrote:

"I agree that images could be improved, but then we should be requesting just those improvements. Instead of saying, "Tom, please do X, Y, and Z for us" we can say, "Tom, if you do X we can do Y and Z." By phrasing it that way I think we have a much better chance of X ever getting implemented."

so your saying you would rather tom only gives us the mob class/datum and we have to make all the variables and procs for ourself.. versus them coming with some handy inbuilt ones?

Not at all. I am saying that instead of asking for the complete feature that is being requested here, we can ask for one or two simple features that would allow for us to implement the larger feature. I guess I was being too abstract. By adding support for animated images we can create a user-made library that handles this larger feature (the selective hiding of objects). This is a better approach for a few reasons:

1. A simpler feature is easier for the staff to implement and is more likely to be implemented.

2. A user-made solution is more flexible than a built-in solution could be.

3. User-made solutions save the staff's time so they are free to work on features where user-made solutions are not an option.

Feature requests aren't a way to say "Tom, I'm too lazy to implement this, can you do it for me?" If a workaround exists they're much less likely to implement a feature. If a simpler feature would allow for the creation of a workaround, you should ask for the simpler feature.

Changing the way images work would probably be a lot more work for them than changing how invisibility does. Invisibility already exists, they would just be making somewhat minor changes/additions so it could be grouped, instead of all or nothing.
Images would need all new animation and interaction functionality to get the same results, and such changes would quite possibly break existing projects.
And even if an image related workaround was possible, it would probably be highly inefficient.

This would break backwards-compatibility with a lot of games...

Er.. Directed towards Superbike, not the idea.

The only types of data I know of in DM is setting true/false(1/0), an integer/number(as num), and a regular text string(as text), and a list.

So basically the last two are the only ones that can store data for multiple values of something showing or not showing.

As a text string one could handle a text string representing lots of numbers or letters which correspond to certain visible objects.

As a number you could have a value of say 7 where numbers like 1,2,4,8,16,32,64,128, etc.... represent different things to see & depending on which things you want to appear like stuff representing a value of 1 & 3 you can add 1+4 to get a value of 5 meaning it will show those 2.

---I am not sure what way your thinking about doing it considering that your thinking about seriously doing it because I can't think of any other ways BYOND can store any kind of data allowing you to do such a thing.

--That's of course saying your not implementing something special for this because I am only thinking in terms of ways with the way we currently set any values how it might be workable without any new data types or anything.

-I may not have said everything but bit fields was said it will not be done, and lists was said to be unlikely, just trying to voice other methods I thought of to see if any of them might be feasible because I like the idea but I can't think of too many ways to actually set/work with the data of what should be visible or not visible.

The implementation of the list thing is fairly ugly. There is an immutable list type that'd be available for this, but only if the data was always the same type--in this case it'd have to be integers. If I didn't use that type of list I'd have to come up with something else, since the generic user list type is unsuitable. I dunno, maybe using just numbers is good enough.

Ironically bitflags would be the easiest to implement, but they're also so limited that I consider them DOA. If we're gonna have this feature we may as well make it flexible, after all.

I do have to say I like Superbike's idea of reusing the vars we have for this though, just allowing a different format.

Nickr5 wrote:

What type of list is used for the contents var and why couldn't it be used here?

The contents var is one of four custom list types that refers directly to the inventory of the object it references. A reference to mob.contents is literally just a type that says it's the contents for a mob, and the mob's ID. Also using atoms for such a list is far more limiting than just using numbers.

If it makes things any simpler, you don't need to add a var. You could add a proc instead, like I mentioned a while ago. This might give you some freedom as to which data type could be used to store which objects are hidden.

I already rejected the proc idea. Visibility is calculated very frequently, which would make a proc unwieldy, but it also has to be done on the client which means the result of a proc call would have to be stored somewhere and sent specially, and a flag would be needed to know when to recalculate visibility all over again. So a proc would be slower and harder to implement than a list.

Oh, I see what you mean. I think just sticking with a var is probably the easiest for everyone though.