It works like see_invisible, but, you ONLY see mobs on invisibility channel 0 and the channel the var is set to
it works like this
with see_invisible, it's like
IF mob's invisibility level is lower or equal to the other mob's see_invisible level, display it on the screen, etc
HOWEVER, with see_invisible_channel, it's like
IF mob's invisibility level is EQUAL to the other mob's see_invisible_channel level, or if the mob's invisibility level is 0, display it on the screen, etc
This could be used for a variety of features, like having 80+ multiplayer deathmatches occuring on the same map, but you only play with those in your gameroom, etc
Get what I mean? It would be used for a variety of things
ID:260552
 May 9 2008, 8:43 am (Edited on May 11 2008, 2:46 am)
|
|
I've also wanted something like this. The "hard" way would to put everyone on different maps that look the same, use images, HUD, ect...
| |
Although this does seem like a decent suggestion, I'd have to say that this would be redundant. A var to control the behavior of see_invisible, however, would be useful.
| |
This could be very useful, but I'd suggest making it more powerful by using bit flags.
//Mobs can only see others on the same team, except for admins who are invisible to normal players, but can see everyone. If one mob's see_invisible_channel and an atom's invisible_channel overlap (see_invisible_channel & invisible_channel > 0), then the atom is visible to the mob. This wouldn't make your idea of having multiple games going on at once on the same map any easier, but I did have a game I wasn't able to (easily) make because BYOND doesn't have this functionality. | |
Nickr5 wrote:
but I did have a game I wasn't able to make because BYOND doesn't have this functionality. Not out-of-the-box, no, but BYOND does support images which you can use to basically perform the same thing. | |
Kaioken wrote:
In actuality? No. Not really. All you need to do is use the image and keep the icon set to null. Then you simply add/remove the image from a clients' images list if the object is visible or not. So yes, it's possible -- just not as easy as suggested above. | |
Except, it's quite nothing like using something built-in like see_invisible, and is a waste of imagse.
| |
I also find it to be a waste of a limited resource to use images to display atom graphics that already exist. Meanwhile, developers would have to use more resources keep track of things.
That said, I don't like the channel idea because it limits the combinations of views. It has been suggested before, but I'd prefer that atoms had built in procs which would be referenced internally when calculating what can be sensed. By default, they would obey the normal engine rules so backwards compatibility would be insured. Developers could then override them like any other atom proc. Unfortunately, I think that this sort of thing is written in a manner that only Dan fully understands. It would take Lummox JR a while to implement it and he probably has other priorities. | |
Android Data wrote:
Kaioken wrote: 1. It's hell to do, but it's easy to talk about 2. It's even more hell trying to do animations 3. It's a WASTE of Resource space See_Invisible_Channel would do a great part in allowing more types of games to hit BYOND | |
Additionally, and the point I was getting at with 'Data, it's only possible to do it in the 'basic' sense, just like was actually said. But doing it properly so you can do 'everything' like see_invisible is already integrated to the system is either (probably) impossible feasibly, or if it is then it's still bad because it'd be very very messy.
Eg (like you partly said): every time you make a change to the icon or other visual var you need to repeatedly make a new image, and reoutput it. This also means, in the basic sense (:P): -you can't use overlays or underlays -if you really want to you'd be required to maintain a list of them so they can be reused/rebuilt -you can't use flick() -you can't do with just changing the object's icon_state or icon as would be normal <small>(and doing things abnormally is less robust by definition, although by a varying degree depending of course)</small> -you can't [insert more things here?] -you can't not hit the images limit (ok, you can, but it just makes it harder) So, that is just really not a very viable implementation. Not for me, at least, anyway. | |
Kaioken wrote:
Except, it's quite nothing like using something built-in like see_invisible, and is a waste of imagse. You can make your own see_invisible as suggested above using images, so this can be used to accomplish this currently, at least until it's a built-in feature. | |
Likely, the BYOND Staff has already seen it, or otherwise seen this feature request before (it was requested multiple times before). It may be on the List, or just rejected.
| |
Nickr5 wrote:
Also, built-in procs that rely on sight (such as view() and viewers()) wouldn't work properly. A simple fix to that, though would be a third argument for those procs that defaults to zero (all channels) for determining which channel it would see. As has been mentioned also, it would probably be better functionality to see multiple channels, in which case bit flags could be used which would only allow 16 channels, or a list of channel numbers, (eg.list(1,2,3)) text, (eg."1,2,3") or params that are the same as a list modified with list2params() (e.g. "1;2;3"). The list2params() idea is probably the best one, since params2list could be used for easier functionality in checking which channels a given player can see. This is just something I'm pointing out if this does get implemented. Of course, another fix to the problem posted here would just be to have multiple servers hosting it. | |
Also, this isn't 4chan. You don't need to post tl;dr.