Entering doors isn't working correctly

ID:142318
 
Jun 23 2008, 7:23 pm
Code:
turf //if I try object it totally bypasses the Enter() proc
   door
      icon = 'door.dmi'
      density = 0
      opacity = 1
      Enter()
         .=..()
         flick("open",src)
         usr << "You enter."
      Exit()
         .=..()
         src.icon_state = ""


Problem description:Ok, now if it's a turf that I'm entering through, when the door flicks through it's opening animation, it works fine. Problem is that it doesn't show the floor under it but is instead black where the door was before. Now if I try making the door an object so that the door would be above the turf through the atom concept, the Enter() proc is bypassed completely as if it's not even there ... someone please help I haven't programmed DM in a while and I have no clue wth is going on...?

Jun 23 2008, 7:33 pm
(There can only be one turf on a location on the map at a time, and the icons for turfs on top of it are simply blended on during compilation, so if only a door is on one spot, then you will see the blank blackness underneath it when it opens.)

You can use /obj/door, and it will work fine.
Use the mob/Bump() proc to determined if it's bumped into a door. While in this proc you would use the istype() proc to check if it's a door. Read up on those two procs if you don't know how to use them.
Jun 24 2008, 8:14 am
Ungh. No put usr in proc. Look those procs up and use the argument. Don't use Exit/Enter() for this kind of stuff either, they're only for determining whether movement should be allowed or not. Use Entered/Exited().

As for objs, those procs work the same on them. They're not called when you enter a turf, because that would be the turf's Entered(), not the obj's. If you actually enter the obj itself, the proc WILL be called, just like turfs' procs are called when you enter them. For this, you'd want to override turf/Entered() and look for objs in the turf when a player enters it, but the make-door-a-dense-obj and use Bump() is also a good method to do it.
Jun 24 2008, 8:48 am
In response to Kaioken
Either way works. If you had a building game where there's multiple different kinds of doors, then the coding would be a little more different depending on which method you use, but basically the same. You would want to make the doors dense and opaque, also if you wanted to be able to lock the doors ans such, which could work with the other method, but it's simpler the Bump() proc way, in my opinion. (No point in being complicated if you don't have to...)
Jun 24 2008, 9:22 am
In response to Naokohiro
Thing is, it's 2 different ways creating entirely different situations, but happening to create the same effect, so you can't compare them as if they accomplish the same thing. Considering already one method uses dense doors and one doesn't, that's already a different impact on your game. Example: Common pathfinding AI. If the doors are dense, that route is going to be considered blocked by default, whereas if you use an Entered()-method and have them logically nondense then pathfinding will work properly for them from the get-go, without needing to modify it somehow so it accounts for doors.
Jun 24 2008, 11:13 am
In response to Kaioken
Yeah, but it works the other way around too. You'd have to make the door opaque and check if it's closed or not through the Enter() proc to block movement if it's closed.
Jun 24 2008, 11:58 am
In response to Naokohiro
Nope, because the door is automatically opened, as needed, by simply entering (Entered()-ing) the turf; there is no blocking of movement (as it is it doesn't serve much purpose - only that 2 attempts to enter the turf are needed instead of 1), and you've got everything tying in to how the movement system works by default, and don't need to make any special accounting.
Jun 24 2008, 11:59 am
In response to Kaioken
Kaioken wrote:
Nope, because the door is automatically opened, as needed, by simply entering (Entered()-ing) the turf; you've got everything tying in to how the movement system works by default, and don't need to make any special accounting.
I meant if it was locked/lockable.
Jun 24 2008, 12:01 pm
In response to Naokohiro
Well, we weren't dealing that with this topic. And lock-ability is a whole different state really... but in my suggestion you could do it by simply toggling density when the door is un/locked, mind you.
Jun 24 2008, 4:44 pm
In response to Naokohiro
 
obj/door
   icon = 'door.dmi'
   density = 1
mob/Bump()
   if(istype(/obj/door))
      src.density = 0 
      flick("open",src)
      .=..()
   else
      .=..()

Description: You guys are awesome. But look at this. Would this be what you guys mean or something along the lines of it. I haven't actually tried that in my code yet but just look at it and tell me if that's along the lines of what you guys mean. I've never called the Bump() proc before but I'm pretty sure I've used the istype() proc in the past?
Jun 24 2008, 4:49 pm
In response to DragonMasterGod
Yes, but you need to use Bump()'s argument (and handle the closing).
Look these in the DM Reference: Bump, arguments
Jun 24 2008, 5:04 pm
In response to DragonMasterGod
That's a start, you have to use Bump's argument and it wouldn't be src.density, because that would affect the density of the mob that bumped into it.
Example:
mob/Bump(var/atom/A)
    if(istype(A,/obj/door))
        A.density=0//also include opacity if you'd like
        flick("open",A)
        sleep(10)//or whatever number
        A.density=1
    ..()

Or something like that.
Jun 24 2008, 5:34 pm
In response to Kaioken
Haha, you guys are too good. Yes everything is working now. This is my first experience with the Bump() proc and probably one of my first with the istype() proc as well. Thanks guys. God Bless You.