[Blender]SlidingDoor OpenClose&EnableDisable NodeTrees

[Deledrius]

Nice colors! For a moment I thought something was wrong when I saw the red nodes, because that happens when I'm working on Korman and break something so badly it can't load any nodes.

That tree looks good to me. There are a couple of things I want to double-check but it's late here for me, so I'll have to come back to it tomorrow if no one else has answered already.

[Sirius]

I'm glad Hoikas and Deledrius could clarify what I was trying to explain
Yes, that last screenshot you provided looks much better as far as I can tell. Also, those colors make the tree MUCH more readable IMHO. (Maybe Korman could provide a similar coloring by default ? Okay, it looks like a xmas garland, but the increased readability might help people learn when they encounter screenshots like these on the wiki.)

Well, I tried to, but the Node Tree doesn't accept the connection between the "Python File" and the Logic's "Exclude Region"...
But if the door collision is enough, it's good to know.

Exclude regions are mostly a way to avoid glitches that might be caused by avatars or kickables being stuck between moving colliders. Think the big doors in Gahreesen's Well - you don't want an avatar squeezed between those, as it would look weird. When an exclude region becomes "solid", it will instantly teleport any avatar away. For thin doors, this is rarely a problem though.
The Python node SHOULD be able to accept an Exclude Region node as input, though. That looks like a bug.

Korman automatically generates notify messages for Python scripts.

Hmm, are you sure ? NotifyMsgs inside responders are supposed to be a bit like AnimEventModifiers - they are placed by the artist at a very specific place in the responder's command/callback chain. Usually at the end or after a TimerCallbackMsg to signal the responder is not running anymore, but not always. When they are triggered, they send a notification to any Python script which holds a reference to the responder (despite the NotifyMsg itself not having a receiver...).
The Python script can receive those events like so (snippet from xStandardDoor):

Show Spoiler

[code]
def OnNotify(self,state,id,events):
print "xStandardDoor: ID notified:", id
if id == -1: # Sirius: -1 comes from an unreferenced object (a responder or another Python script, maybe)
[...]
pass

# reenable clickables after door open/close anim runs
elif ( id==respOpenExt.id or id==respOpenInt.id ):
# Sirius: this is one of the responders notifying us at the end of its event chain
# (it could happen sooner though)
self.UpdateRespStack()
if boolCanManualClose.value and boolEnableOK:
actExterior.enable()
actInterior.enable()
elif ( id==respCloseExt.id or id==respCloseInt.id or id==respAutoClose.id):
[...]
pass
[/code]

Honestly, getting sounds to trigger at the right moment before/during/after an animation is not the easiest thing. Especially during. Timing is hard. Thankfully Korman makes iterating Age Development much faster.

I guess you already know this, but I wanted to mention the Timed Callback message is very useful in this case.

You have the button(s) set up to toggle a variable that's kept stored and synced, your SDL variable that is a simple "is this door open?" sort. [...]
The second part is the xStandardDoor script. You hook that up, and tell it about the SDL variable. It will then get notified anytime that value changes. When it does, the script will "respond" by setting off the Responders you have hooked up to it!

(As for "why should we use the SDL var at all": it's because SDLs are always synchronized between clients, and saved even when no one is in the Age. Unlike animations, which are usually not synchronized with the rest of the server for performance reasons. As a bonus, it means multiple systems can be hooked to the same SDL variable without requiring crazy wiring all over the place - all they need is to have a String Attribute parameter with the correct variable name. It's useful for things like multiple levers opening the same door; or a puzzle where a door opens only when all other doors are closed.)

[Sirius]

(Double post, but I forgot something in the previous one)

I wasn't sure that the python script handles all the logic...
So, if I understand well, I need 4 Responder and 4 Responder States (1 Responder States for each Responder), but I don't have to (and shouldn't, for this Node Tree) link 2 Responder States together because the python script will handle all the other logic.

The important thing to remember is that Python scripts think (take "decisions" by examining SDL variables and listening to objects triggered), while responders execute a list of commands. Responders CAN have multiple "states" for very specific scenarios, but you shouldn't worry too much about this - usually, you will have only one state per responder.

[Maroonroon]

those colors make the tree MUCH more readable IMHO. (Maybe Korman could provide a similar coloring by default ? Okay, it looks like a xmas garland, but the increased readability might help people learn when they encounter screenshots like these on the wiki.)

I agree, a color per kind of node could help readibility (it's why I set them like that, to help you reading the screenshot content); but with the possibility to change them, still with the same color family...
For example, blue color family for the Responders, but if we want to visualy group a 2 of 4 Responders and the other 2, we can set light blue color for the 2 of 4 and sky blue color for the other 2.

Well, I tried to, but the Node Tree doesn't accept the connection between the "Python File" and the Logic's "Exclude Region"...
But if the door collision is enough, it's good to know.

Exclude regions are mostly a way to avoid glitches that might be caused by avatars or kickables being stuck between moving colliders. Think the big doors in Gahreesen's Well - you don't want an avatar squeezed between those, as it would look weird. When an exclude region becomes "solid", it will instantly teleport any avatar away. For thin doors, this is rarely a problem though.
The Python node SHOULD be able to accept an Exclude Region node as input, though. That looks like a bug.

Yes... The connector is disabled on the Python File.

I wasn't sure that the python script handles all the logic...
So, if I understand well, I need 4 Responder and 4 Responder States (1 Responder States for each Responder), but I don't have to (and shouldn't, for this Node Tree) link 2 Responder States together because the python script will handle all the other logic.

The important thing to remember is that Python scripts think (take "decisions" by examining SDL variables and listening to objects triggered), while responders execute a list of commands. Responders CAN have multiple "states" for very specific scenarios, but you shouldn't worry too much about this - usually, you will have only one state per responder.

Thank you for this clarification.

[Aloys]

All this just to hook up a regular door? This is slightly scary...

[Tsar Hoikas]

OK, the tree looks really good now. Just two changes to make, I think. On the two xAgeSDLBoolToggle nodes, you need to set the "Extra Info" socket to be either fromInside or fromOutside so that the door knows how to open. Aside from that, this should work correctly!

All this just to hook up a regular door? This is slightly scary...

Better than all that crazy AlcScript from before

Responders CAN have multiple "states" for very specific scenarios, but you shouldn't worry too much about this - usually, you will have only one state per responder.

This is a good framework to operate from.

Hmm, are you sure ? NotifyMsgs inside responders are supposed to be a bit like AnimEventModifiers - they are placed by the artist at a very specific place in the responder's command/callback chain. Usually at the end or after a TimerCallbackMsg to signal the responder is not running anymore, but not always. When they are triggered, they send a notification to any Python script which holds a reference to the responder (despite the NotifyMsg itself not having a receiver...).
The Python script can receive those events like so (snippet from xStandardDoor):

Show Spoiler

[code]
def OnNotify(self,state,id,events):
print "xStandardDoor: ID notified:", id
if id == -1: # Sirius: -1 comes from an unreferenced object (a responder or another Python script, maybe)
[...]
pass

# reenable clickables after door open/close anim runs
elif ( id==respOpenExt.id or id==respOpenInt.id ):
# Sirius: this is one of the responders notifying us at the end of its event chain
# (it could happen sooner though)
self.UpdateRespStack()
if boolCanManualClose.value and boolEnableOK:
actExterior.enable()
actInterior.enable()
elif ( id==respCloseExt.id or id==respCloseInt.id or id==respAutoClose.id):
[...]
pass
[/code]

Very sure. The most common use case is wanting to be notified at the end of each state, so that's what Korman does. I figured that if a builder wanted notifications at specific points in a responder during a script, that builder would have the know-how to trigger a new state from Python to continue execution

The Python node SHOULD be able to accept an Exclude Region node as input, though. That looks like a bug.

I just looked and there is some kind of bug here. I can't even make the connection manually.

[Sirius]

Agreed, less scary than the equivalent AlcScript... And much easier to learn. But yeah, I also agree that at first glance, it's dense and all over the place, no matter whether you understand it or not.

Believe me though, once you get familiar with the Plasma way of doing things, node trees are quite readable and Korman avoids a LOT of pitfalls that are usually caused by the PRP format in general. It's also relatively flexible too.
(Writing custom Python scripts is even more powerful, but also has its own fair share of pitfalls. Fortunately in most cases reusing existing scripts should do the job.)

Very sure. The most common use case is wanting to be notified at the end of each state, so that's what Korman does. I figured that if a builder wanted notifications at specific points in a responder during a script, that builder would have the know-how to trigger a new state from Python to continue execution

Duh, now that you put it this way it makes completely sense. Thanks for the clarification !

[Tsar Hoikas]

Very sure. The most common use case is wanting to be notified at the end of each state, so that's what Korman does. I figured that if a builder wanted notifications at specific points in a responder during a script, that builder would have the know-how to trigger a new state from Python to continue execution

The Python node SHOULD be able to accept an Exclude Region node as input, though. That looks like a bug.

I just looked and there is some kind of bug here. I can't even make the connection manually.

This bug will be fixed in the next release of Korman.

[Maroonroon]

OK, the tree looks really good now. Just two changes to make, I think. On the two xAgeSDLBoolToggle nodes, you need to set the "Extra Info" socket to be either fromInside or fromOutside so that the door knows how to open. Aside from that, this should work correctly!

I wasn't sure of what to write there... So: "fromInside" or "fromOutside"; good! I'll update my Node Tree.
Now I have to finish converting my Blend file to Korman, and finaly testing the Node Tree in game.

The Python node SHOULD be able to accept an Exclude Region node as input, though. That looks like a bug.

I just looked and there is some kind of bug here. I can't even make the connection manually.

This bug will be fixed in the next release of Korman.

Good! I'll add the Exclude Region Node and wait for the new release of Korman to connect it to the Python File Node.

Thank you everybody!

EDIT: Attachment removed

[Aloys]

All this just to hook up a regular door? This is slightly scary...

Better than all that crazy AlcScript from before

Definitely.
Still it shows how good tutorials and templates are always welcome. For my christmas vacation I'm planning some much needed Uru time, not sure those two weeks will be enough to achieve more than a door.