An idea on invisibility

ID:132588
 
Apr 10 2010, 12:42 am
Invisibility is like density in which by itself its very limited. If you wanted to make only certain objects pass threw each other using density alone you couldn't without a weird work around. Although because of the procs you can make modifications to make density irrelevant. When invisibility isn't enough there's no proc to override and I believe that is the problem. If there was a proc like Cansee (Name up for debate...) that we could override to make exceptions there wouldn't be a problem.

mob
    Cansee(Saw)
        if(istype(Saw,/mob/Ghost)&&!istype(src,/mob/Ghost))
            return 0
        return ..()
    Ghost


Cansee could be triggered whenever something comes into view. It would only be called if it was overridden though. There are problems with this method such as what to do if something switches from invisible to visible.

The main idea is to add sight procs that can be modified.
Apr 10 2010, 3:15 am
Feature requests belong here now.

Also, you can use the see_invisible variable in conjunction with the invisibility variable to whip up something similar.
Apr 10 2010, 12:05 pm (Edited on Apr 10 2010, 12:43 pm)
In response to Tiberath
Not a feature request as the specifics are up for discussion. Those two vars can't even come close to what is needed. This was just an example not what my situation is. If you want a situation that can't be done now give me a bit...

Edit:
mob
    Players
        var/tmp/list/Party=list()
        var/tmp/DungeonControler/DC
        var/tmp/InDungeon=0
        CanSee(Saw)
            if(DC)
                if(Saw in DC)
                    return 1
                if(Saw in Party)
                    return 1
            return ..()
        verb
            AddPartyMember()
                set src in view(3)
                usr.party+=src
            StartDungeon()
                if(src.InDungeon)
                    return
                for(var/mob/Players/A in Party)
                    if(A.InDungeon)
                        Party-A
                        continue
                    A.InDungeon=1
                    A.Invisibility=5
                    A.loc=locate("Arena")   
    Monsters
        var/Invisibility=5
        Ghost
        Ghoul
        Demon
DungeonControler
    var/tmp/list/ArenaMonsters=list()
    var/list/Players=list()
    New(/list/P)
        Players=P
        ArenaMonsters+=new /mob/Ghost/(src)
        ArenaMonsters+=new /mob/Ghoul/(src)
        ArenaMonsters+=new /mob/Demon/(src)

Here's an example of an arena. Normally you would need a lot of arenas or you would have to create them as needed. This code, if Cansee or similar was implemented, would only require one Arena. Please only post ideas, suggestions, possible alternatives, and problems of this method with a possible solution related to the topic.
Apr 10 2010, 6:16 pm
In response to Chowder
The feature you're suggesting has in fact been suggested repeatedly before, and already exists in the feature tracker (with numerous duplicate issues). Discussion can be done on the existing issue.

Regarding the uses for this feature, I think battle arenas is not one of the better uses. If you're using battle arenas you really should be creating and destroying them on the fly, which is one of the specific tasks SwapMaps was actually designed to handle.

Lummox JR
Apr 10 2010, 7:59 pm (Edited on Apr 10 2010, 8:06 pm)
In response to Lummox JR
The larger the arena the less practical deleting it and remaking it becomes.
If say it was 600 by 600 with 3000 different things on it.
Is it better to make 3000 more objects every time you need another one or just make it so each player can see there set of 50 monsters or so.
I am very well aware that there are issues similar to this. Not only can discussions be done on an existing issue this sort of is one.
Another use I can think of if you really need another one is events that are only shown to specific players.
An example would be if a player completed some odd quest and has to talk to a lost child. Other people cannot see the lost child because they do not have the quest.
If there were multiple lost children each with there own unique quest and each player either seeing them or not depending on the quests they have each done then the current system could not do it without a very weird workaround.
I was really hoping to get some ideas concerning the topic and the trend these replays have is disappointing me. Its kind of when you wait for a response, it finally comes, and it says "First".
Apr 10 2010, 11:08 pm
In response to Chowder
Chowder wrote:
I am very well aware that there are issues similar to this. Not only can discussions be done on an existing issue this sort of is one.

You miss the point. The topics mentioned by Lummox JR contain a multitude of arguments that would have to be reiterated here. So, basically, by creating and discussing in a new topic, you're wasting time the developers could take to implement reasonable functionality.


Chowder wrote:
Another use I can think of if you really need another one is events that are only shown to specific players.

In which case you're to use an image object, which fits the description you provided just fine.


Chowder wrote:
I was really hoping to get some ideas concerning the topic and the trend these replays have is disappointing me.

That would be because you are trying to start a topic anew without having bothered to invest the time to read on the replies others have received on it before.
Think about it. If you can't be bothered to put effort into it, can you really expect this of others? Should they have to recompile arguments they already stated a hundred times before?
Apr 11 2010, 6:18 pm (Edited on Apr 11 2010, 6:26 pm)
In response to Schnitzelnagler
"In which case you're to use an image object, which fits the description you provided just fine."
Do I have to make an example for every dam thing... Fine the lost children can all move around, have verbs, shoot fireballs, and can bite you. When caught you can visit the orphanage where you can see all the lost kids you have found. Yes its a plot twist the lost kids are actually dragons. I'm sorry if my example sucked but your entirely missing the point. Most things can be done with very weird workarounds. For example you could state that client side scripting is pointless because you could have a server act as a client. Can it be done? Yes. Is it convenient? No.

"That would be because you are trying to start a topic anew without having bothered to invest the time to read on the replies others have received on it before."

Have you bothered to look over the replies I've made to posts related to this subject? Hell I've made a few of them. None of them have the same implementation that this topic has although they helped me get this idea.

http://www.byond.com/developer/forum/?id=721576
http://www.byond.com/developer/forum/?id=636873
http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=1297
http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=1048

Thank you for wasting my time by making me re-find some of what I have already read. If you can find a list of arguments on the subject of this exact method I have posted I would love to see it. You said arguments on the topic have been stated a hundred times before. Posting a few of them would be a much more effective way to prove your point. Instead of pointing fingers at posts that probably don't exist.

Apr 11 2010, 11:20 pm
In response to Chowder
Chowder wrote:
Do I have to make an example for every dam thing

No, but it would help if you actually considered the possible solutions others present and extend on them.

The image object was meant exactly for the case you are describing, per client visual effects. This is not some weird workaround' but actually was implemented for exactly this situation. Which would leave AI interaction, where I'd argue that you might want to build less on visibility, as that can get rather resource intense and has no benefits over a more straight forward implementation.

Chowder wrote:
You said arguments on the topic have been stated a hundred times before

Which is exactly how Lummox JR pointed out he feels on the topic.
Apr 12 2010, 4:08 am
In response to Chowder
I think the essence of what you're trying to say is that you're making an RPG where, while you want the players to be able to interact, you still want them to be able to do solo quests on their own and interact with objects made just for them that no one else can see. To that end I agree with Snagler that images are the best way to go. Unlike other requests on this general subject which are asking for ways to easily share visibility among certain groups, you're only talking about one player being able to see a certain object. For many of those cases /image makes sense as well, but it's particularly well-suited for this case. But you'll still run into problems with mobs getting in each other's way if you don't take the even simpler SwapMaps approach of just using duplicate maps.

Inasmuch as the implementation presented here may be different from that suggested in the existing feature request, I should point out that it's not workable anyway. DS handles visibility on the client end; a proc that says whether something is visible would require client-side processing, hence it is not possible. Also on the basis of operational speed it's simply a no-go; there's no way you'd want to call the same proc for a potentially huge number of objects every tick.

Other suggestions along these lines have revolved around bit flags, though I don't consider that terribly workable as an option either because ultimately it limits the number of possible groups to 24. My personal feeling is that if we were to consider the feature it would involve something much closer to mob.group in implementation.

Lummox JR
Apr 12 2010, 4:12 am
In response to Schnitzelnagler
"The image object was meant exactly for the case you are describing, per client visual effects."

I'll look into it.