Guild of Writers

I've been trying to figure out a realistic way for doors to open in an age I'm working on, and I remembered the 'kickable' bridge in Teledahn (You kick it, then pull the lever). I was wondering, is that possible to implement in a fan age? Without the lever of course. The idea is that the door is very old and hard to open so you have to jump at it to open it up.

As a side note, I also tried making the door literally kickable. The avi jumps at it and if falls down (due to overly rusted hinges). However whenever I link in the door has completely vanished. This has happened to me with other kickables as well and is quite a conundrum.

As a side note, I also tried making the door literally kickable. The avi jumps at it and if falls down (due to overly rusted hinges). However whenever I link in the door has completely vanished. This has happened to me with other kickables as well and is quite a conundrum.

I suspect this is caused by the kickable (almost) intersecting the floor/a wall, so that it just falls through because it already collides.

Oh, and I doubt the bridge in Teledahn is an actual kickable... I didn't look at the files, but I'd expect something like a region triggering the animation, with the region being up so high that it can only be reached by jumping.

That sounds about right, I checked it out in blender and it's just as you said, a higher region by the bridge. My question then would be, is it possible to make doors open like this? I guess it's the same thing as the Ahnonnay Cathedral then. If it is possible then how? I noticed that Andylegate implemented a similar door in his Pahts shell, so it's got to be possible somehow, even if it's just a hack.

Edit: I just moved my kickable door somewhere where it's not touching anything, and when I exported it still wasn't there.

Justintime9 wrote:Edit: I just moved my kickable door somewhere where it's not touching anything, and when I exported it still wasn't there.

Delete the .sav file for your Age. Once the door fell, the game saved it's position. Every time you link there, it is put back in that fallen position.

With Max and Cyan's plugin, this is very easy to do:

Create the region area, assign the plasma components to it (PageInfo, and Region Sensor).
Then create a Logic Responder, making the Detector the region you just made. Have the responder trigger the animation of the door, and the sound effect (IE you don't make it a "kickable", you make it an animated object).

You can do the samething in Blender with ALCScripting using Quickscripts I think if I remember right. Set up a responder and have the trigger be the region is all.

Are you referring to this quickscript: http://www.guildofmaintainers.org/Forum ... f=74&t=792
if so, by "having the trigger be the region" would I simply make the "clickable object" my region?

No, that post is for a clickable to be used. I suppose there might be a way to make it to where it looks at your region as the "clickable".

Here's a post here that is more of what I'm talking about, however it's a older version of the gow plugin, so I don't know:

http://www.guildofmaintainers.org/Forum ... =142&t=875

If you were using Max and Cyan's plugin, it would take you just a few clicks and you'd have it done.

Ok, I followed that tutorial and it worked great! However the end result wasn't quite what I wanted for this particular door (it's fine for another one). The one in the tutorial opens when in the region and closes when not in the region.

Is it possible to make two regions, so that it opens when in one region and closes when in another? Plus, it shouldn't re-open if someone goes in the "open" region a second time after it's already open. Here's my AlcScripts:

Code: Select all

LDoorReg:
    logic:
        modifiers:
          - name: Enter_Door_Rgn
            flags:
              - multitrigger
            activators:
              - type: objectinvolume
                triggers:
                  - enter
            conditions:
              - type: volumesensor
                satisfied: true
                direction: enter
            actions:
              - type: responder
                ref: :DoorOpen
          - name: Exit_Door_Rgn
            flags:
              - multitrigger
            activators:
              - type: objectinvolume
                triggers:
                  - exit
            conditions:
              - type: volumesensor
                satisfied: true
                direction: exit
            actions:
              - type: responder
                ref: :DoorClose
   
Door1:
    animations:
        - name: DoorAnime
          autostart: 0
          loop: 0
    logic:
        actions:
          - type: responder
            name: DoorOpen
            responder:
                states:
                  - cmds:
                      - type: animcmdmsg
                        params:
                            receivers:
                             - 006D:Door1
                           animname: DoorAnime
                           cmds:
                            - setforewards
                             - continue
                        waiton: -1
                    nextstate: 0
                    waittocmd: 0
          - type: responder
            name: DoorClose
            responder:
                states:
                  - cmds:
                      - type: animcmdmsg
                        params:
                            receivers:
                             - 006D:Door1
                           animname: DoorAnime
                           cmds:
                            - setbackwards
                             - continue
                        waiton: -1
                    nextstate: 0
                    waittocmd: 0
                curstate: 0
                flags:
                  - detecttrigger

I assume it'll just take some tweeking and an SDL variable. Hopefully nothing too drastic.

Several ways to accomplish what you are talking about. Unfortunately it's easier to say how I would do it with Cyan's plugin, than with ALCScripting, however, the principle is still the same:

First, obviously you are designing the Age for Multiplay, which is outstanding, as many people (including myself) have a tendency to make Ages with only single play in mind.

What you can do is this: Have more than one responder for the door, one opens it, the other responder closes it (IE sets the animation backwards and then plays it).

What I would do is create 2 regions that extend on either side of the door, and the avatar entering one region is what triggers the first responder. The 2nd region is the trigger when the avatar exits it. Have the first responder enabled, but the 2nd responder disabled.
The first responder will open the door, once it does, it also disables itself, and enables the 2nd responder.
The 2nd responder closes the door, then disables itself, and re-enables the first responder (again, this is how I did my lever puzzle in Neolbah).

So let's look at a scenario: 2 people are walking towards the door, one is about 20 feet back let's say. The first Avatar enters the "Enter" region. This triggers the first responder since it is enabled (the 2nd region has no effect because the detector for it is on Exit and not Enter, also, the 1st region is set for Enter detection, and not Exit).
The first responder will open the door (setting and playing the animation forward) and then disables itself, and also enables the 2nd responder (which will close the door when triggered).
If the 2nd avatar catches up to the first, before the first one exits the regions, there will be NO effect by that 2nd Avatar, because the first responder has already been disabled by the 1st avatar.
If the 1st avatar exits before the 2nd avatar catches up, the door will close (due to the 1st avatar exiting the "Exit" region), and that 2nd responder that closed the door will disable itself and re-enable the 1st responder. This sets the door up so that when the 2nd avatar get's there, it will start the sequence again, and open the door.

In either case, this will prevent the region from triggering either responder out of sequence and making the door "magically" reappear and suddenly open or close.

Sounds complicated, but it's not really (and again, I apologize for not knowing the ALCScripting for all this, but again, with Cyan's plugin, it's a snap to do).

You can also do it with one region, again making the trigger both Enter and Exit, but still making 2 different responders, each disabling themselves after the door animation and Enabling the other when complete.

You can also set up using Python to check the SDL state of the door.

There is also another way to do it using the python files (star trek doors) but I only know how to use those with Cyan's plugin. Someone here might know how to use it with the ALCScripting.

andylegate wrote:There is also another way to do it using the python files (star trek doors) but I only know how to use those with Cyan's plugin. Someone here might know how to use it with the ALCScripting.

Those doors never worked properly which is why Cyan has ripped them out of MOUL.

I am not sure if you can directly disable a responder but if you mean its activator then use this AlcScript snippet:

Code: Select all

                      - type: enablemsg
                        params:
                            receivers:
                              - logicmod:Enter_Door_Rgn
                            cmds:
                              - physical
                              - disable
                        waiton: -1


I often use this for clickable activators, but there is no reason why it shouldn't work for region activators.

And yes, for full multiplayer compatibility you need SDL states.