ID:92006
Feb 23 2010, 3:24 pm
|
|
Copied from BYOND Features forum by Airjoe
Assuming this hasn't already been added without me noticing.. A way to selectively hide objects from players would be very nice, if not vital for certain things. Example: /mob/ghost This could be done using bitfields, or maybe(though slower) lists. When atom.invisibility isn't enough anymore, something like this would be really necessary. | |
I agree with this as well, for reasons like the presented idea.
| |
Perhaps a new type of object should be made then. An object that is a cross between /obj and /image.
It animates the same as an obj, but is only visible to players who have it sent to them through the << operator. | |
This invisibility list is a great idea & would help a lot, it's not terribly hard for one to use image() to get the desired basic effect but for as long as it takes & the work involved it's terribly hard to think it's effective, most games don't even have a good roof system (to their own standards even) because the lack of such a list.
They are either bugged so everyone sees through the roof or where invisibility is actually used where you see through all roofs even though the developer was only intending for you to see under the roof of the building your currently in only, not every building you can see that has a roof. ---While i'm sure people will still make crappy things that aren't worth the crap coding-wise with or without this at least it gives the oppurtinuty to create good things for the developers who aren't trying to make a crap game. --Of course we can do it other ways already but having to do so much to get it to work discourages & delays us from making our creations, and of course if someone makes something good enough people will come to BYOND to play & if it has benefits likely more BYOND members will come from it. | |
As bit fields would result in a limit of 16 groups, something along the lines of a new proc might be better. For example, world.SetVisibility("humans", "ghosts", 0) would make all atoms in the 'ghosts' group invisible to those in the 'humans' group. Values for the third argument could also be 1, for using BYOND's default visibility calculation (i.e. visible if there isn't an opaque object in the way) and 2, for always visible.
| |
I agree that the invisibility var is useful but not always sufficient, but it seems like this would fall into the category of "features that have so many potential intricacies that no built-in implementation will ever be sufficient so you're better off implementing it in DM so you're guaranteed to have the flexibility you need."
| |
Text lists, instead of bit flags, should be enough to get whats needed out of this. Implementing it yourself is nearly impossible. Images are the best alternative, but they're seriously lacking in functionality. You could instance off your game, but that doesn't provide the same results, and can waste resources.
| |
Images let you display objects to individual players. It might not be efficient but this is certainly possible. Any complexity can be neatly hid in a library.
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. | |
Using images has been suggested before here, but I don't think it can be done well enough to both perform well and deliver all necessary features as you'd basically be re-implementing a big chunk of what BYOND already does for you (see the replies to that post).
| |
Chowder had actually put together an images demo to fill this exact functionality (we were going to use it), but it had a shortcoming: you can't use animated sprites. I'm pretty sure the rest of it worked well though (but I was still unsure of how well it would upscale).
| |
this would save me a whole lot of work ++
| |
After some testing, doing it with images does seem better than I first thought, but there are still a lot of loose ends. You lose movement states, the convenience of changing the icon_state, all of the procs that rely on sight (view(), etc) and therefore all src settings that rely on these, overlays/underlays, and invisibility (though that one's probably not a big deal since you're basically replacing it). It does look doable, but I still think it's worth having this built in so it can be better integrated with BYOND.
| |
I'd much rather have this feature than enhanced image foo -- it feels like this will solve more problems than improving how images can work, but whichever is simpler for the BYOND developers is what I'll opt for, because it'd be better than nothing.
| |
More image features gives you flexibility. Having BYOND add a specific implementation of the feature won't give you as much flexibility.
| |
Maybe it won't be as flexible, but it will provide a much more polished, functional, easy to use, and direct feature. Even if images were fully functional (which they are far from) it would still be quite difficult, and a lot of work to accomplish a similar result through DM. Something like this is probably much simpler on their end, considering the invisibility systems already half exist.
| |
If you can provide a clear description of what you'd like to be possible with this potential feature, I'm sure someone could start working on a library.
| |
Forum_account wrote:
If you can provide a clear description of what you'd like to be possible with this potential feature... Its pretty straightforward, what do you need explained? | |
Can you be in multiple groups? How do you specify that an object can see everyone or be seen by everyone? How do you change these settings at runtime? What would you expect/want the syntax to look like? Would you allow exceptions to these visibility rules? What exactly would you be using this for?
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. | |
Forum_account wrote:
Can you be in multiple groups?Yes. Be in multiple groups and/or see multiple groups. How do you specify that an object can see everyone or be seen by everyone?With some sort of built in groups like "SEE_ALL"? How do you change these settings at runtime? What would you expect/want the syntax to look like?They would just be lists that you edit like any other list... Would you allow exceptions to these visibility rules?Like what? What exactly would you be using this for?I don't have any actual plans at the moment. But take spies for example. To the other team you appear completely invisible, while your team can still see you. Could also go for things like traps, which only the person who planted them can see. EDIT: You could also use it to "instance" cut-scenes, and other things. EDIT 2: Somebody else mentioned roof systems somewhere. 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.Good luck with that. | |
Such as you can make ur own bitfield stuff to use such as GHOSTS as what you have and PLAYERS, maybe LIONS too.
I would use this so only GHOSTS can see GHOSTS and NormalPlayer can't. And such.
I even tried working around stuff like this using image() but it failed because apparentally image() will follow a users direction but it fails to do the walking animation, it does animation in general though but doesn't respond to you moving. Which in itself should be fixed if it allows the icon to change at all, for animation or even otherwise direction then it should technically work for moving animation too.