Bitflags are out of the question.
| |
Maybe the way I was suggesting is too similar to the way bit flags work anyways as to where what I suggested doesn't matter but considering I basically said that using text values is out of the question(the string would be really long to store & probably read) & probably integer values(the way I said was apparentally too much like bit-flags.), then there is no bit flags & apparentally not lists(lists would contain too many items even if you only had 100 different numbers of invisibility for this), I am out of ideas for this.
However I did make my own code inside BYOND to check all the values from a given integer to spit out what objects should be shown, and it completed instantly(with no lag) even from within DM, & it should be faster internally than through DM code & it had no lag determining the values from DM code itself. ---This was even when I was trying to determine for 1000 different values of invisibility, cpu on my personal PC for this test project I made in DM only shot up to 5% cpu for <1 sec while it determined & spit out the numbers in which it should show to you.) | |
May I suggest something similar to images, only completely opposite? The trick we use now to selectively show objects to players is to attach an image to them, and add the image to client.images. I propose a list that you can fill with atoms that should not be visible to the client. If stored internally as a binary tree of object IDs, I'd imagine look-up time would be extremely brief.
The sight stuff we have now, invisibility, infrared, are all pretty situation-specific. Even bit flags would have the limitation of how ever many bits can be tracked precisely with single-precision floats. (23 at most, I think.) | |
I have to agree with Yut Put here. This can be done already, it's just not something that happens 'out of the box'. Since it's so easy to do, I don't see any reason why this should change.
| |
I created an example of how you can handle this. It gives every mob a list of visibility groups they are members of and a list of each group they can see. If an object is a member of a visibility group that you can see, you can see that object.
http://www.byond.com/developer/Forum_account/ VisibilityGroups | |
BYOND has come a long way since this post especially when it comes to giving us control over rendering, but in my opinion this functionality still doesn't actually exist in the engine.
To justify that statement (if it needs it), here's a scenario: You want to hide all objects in the world from a player. How do you do it? You can use the invisibility variable, easy enough right? Except we all know invisibility in BYOND is not a sanely designed feature since it has no way to selectively hide something without also hiding everything that has a higher invisibility value. It's always been terrible. How about planes? Just put all objects on their own plane and hide it from the player. This too does not work as it overrides layers completely, if your objects are on plane 3 and your player is on plane 4 you'll never be able to layer an object overtop of a player. (Also doesn't solve verb accessibility.) /image objects? Let's be real, that approach is clunky as all hell, has overhead issues and was a joke even back in 2011. It's fine if all you're doing is selectively showing very specific things to a player (roofs, chests) but if you want to do something like hide all objects in the world from a player, good luck making that work sanely- even with image override. You can do it but it performs like ass and trying to undo it and unhide objects from a player performs even worse. PS: http://www.byond.com/forum/post/1870524 should be marked as duplicate of this thread IMO, as even though the specifics of that request are different it's basically the same feature. Either way I wish to link it here for the sake of compilation. By the way actual best way to hide all objects from a player (which is still bad) would be to set everything's invisibility to a value higher than the player's see_invisibility, then turn everything on individually through mob.sight and remove the SEE_OBJS bitflag when necessary. Or at least it would be the best way if mob.sight worked properly which it doesn't; And obviously it's still not a solution to this problem- only my specific example- since it's only applicable to entire atom types. (It also makes invisibility useless.) | |
My main idea is make it be an integer & we could even replace see_invisible if we wanted or use it in conjuction with if wanted or make it a variable of its own, anyways, to use it in conjuction with see_invisible we could figure out what number we need & offset it an X amount(maybe 101 it looks like since thats the max see_invisible currently goes to) & then any value higher than 101 would make it so only certain levels of invisibility become visible.
---In going with my method (when re-using the see_invisible variable, making invisibility 80 & 90 visible would be a value of 271(101+80+90) & yea, the max value of the integer would be around 5151 with all 100 different visibility numbers seperately set to show with this new method & given it's using the same old variable.
--However a big game might use all these if they use them for stuff like individual quest chests, etc....so each one shows opened once you opened them.
The main thing is if BYOND is fast enough to figure out all the values from this number that should be visible & actually make it happen, and what they would be limiting it too as i said 100 maybe low(however depending on what you use it for & how you use it.)
The chest thing would have to be for each chest considering you don't open multiple chests at once ever I would think, but people could use this for other things instead.
-Anyways, unless there's a new var for this one may want a value of 102 be the 'default' or a new settable default so when you go adding invisibility numbers you want to see then you can just add to that whatever number you want to become visible, because then otherwise you need to keep track of that 101 as you go changing things & keep track of not needing it after the first time, otherwise people might use 102 as the default anyways wasting invisibility #1 so they can have another "default" number to work with the invisibility numbers easier.
This would come out to 5152 instead as the greatest possible value, however 100 maybe low so if it were to become higher things mostly come down to how fast things can be calculated on what to show & how fast it is on networking when things actually go to show.
Anyways as for storing this value, even if it was 1000 numbers to work with it would come out to be a value of 500, 602 (if adding 101 to re-use that one var & another 1 for another "default" to use so calculations made for which ones to show can be made easier without worrying about the other 101 values that you only need to carry through the first change(unless you want to hide & not show any invisibility numbers).
So, 6 characters long storage if it had 1000 numbers to work with & all were visible.
A text string would be over 1000 characters because you need spaces/commas between each, so easily like 1999 if all were visible this way, one less space/comma needed than there are numbers, so I am now not sure that way is viable...
Too much text I know i'll try & edit it down before too long trying to find what was important.