[Blender]SlidingDoor OpenClose&EnableDisable NodeTrees

Help bring our custom Ages to life! Share tips and tricks, as well as code samples with other developers.

[Blender]SlidingDoor OpenClose&EnableDisable NodeTrees

Postby Maroonroon » Sat Nov 09, 2019 10:31 pm

Hello.
Still in order to solve this problem, I tried to "convert" a copy of one of my real .blend files into Blender 2.79b to use it with Korman 0.9 (I haven't finished converting it yet).
I wanted to try to make my first Node Tree, for my "Door01" ("OfficeDoor" in my real file) and I just finished it, I think (hope), but I can't test it yet...
If you manage to see something in the following screenshot, can you tell me if it looks right, please?

Sliding door NodeTree (with Oneshot moving because of a wall):

office_door_open_close_node_tree.png (1280x960) Show Spoiler
Last edited by Maroonroon on Sun Sep 06, 2020 10:05 am, edited 4 times in total.
User avatar
Maroonroon
 
Posts: 219
Joined: Sun Jul 06, 2014 5:03 pm
Location: France

Re: My first NodeTree

Postby Sirius » Sun Nov 10, 2019 10:02 am

Hmmm, I don't see anything wrong with it, but I do recommend testing it at some point, just in case.
Since you asked, I have a few remarks about it. But keep in mind those are either personal preference, or I may be wrong on the technical side of things. So take it with a grain of salt.
  • I think it's best to avoid sharing responder states between different responders - usually a responder state is attached to only one responder (Korman might be clever enough to figure it out, though). Making duplicate responder states may make the node graph slightly bigger, but I think it would make it slightly more readable due to your responder states triggering each other (also, this ensures you set only one state as the "default state" - otherwise the responder might end up confused as to which one is the correct one). Sharing the same message between two states is fine though.
  • the last node which plays a sound will be played only once every other node has completed - which means it might start playing after the door's animation have ended - I'm not 100% sure. For what it's worth, Cyan usually connects all messages to the responder state directly instead of chaining them with Send On Completion (except when a message really needs to wait for another one to finish).
  • it's probably a good idea to uncheck the "driveable" and "reverseable" boxes from One Shot Mods. Those are meant to be used only when the player can "control" the animation using directional keys (think how ladders work). Leaving those checked will likely have undesirable side-effects for what you're trying to do.
  • a quick check at Teledahn's files reveal that the xStandardDoor script expects responders to send notify messages. They don't seem to be supported by Korman yet ? However I think they are required, so that might mess some things up. If your door clickables stop working after usage, then it's likely a problem with missing notify messages.
  • (unless you're relying on the exact door collision to prevent players from passing through it, setting up an exclude region might be useful. But in my experience, the door collision should be enough.)
  • (you may be able to remove the last four boolean variables from the Python script - they should all be false by default. But I'm not sure, so keeping them around might be safer.)

Again, I'm not sure what I'm saying is 100% correct. You should try your current version of the node tree, and see if it works. If it doesn't, then you might want to see if what I wrote helps.

Also, I'm not sure if you know about it, but you can get PrpShop from this thread (it's included in PlasmaShop 3.0, which has several similar utilities). It allows you to see what Korman exports as XML structures. It's more advanced and less readable than node trees, but it's extremely useful for debugging. You can also use it to open Teledahn_District_tldnSlaveShroom.prp and see how the xSandardDoor script was setup there.

Hope this was useful. Don't hesitate to ask if I was unclear :D
User avatar
Sirius
 
Posts: 1506
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: My first NodeTree

Postby Maroonroon » Sun Nov 10, 2019 1:10 pm

Thank you for your answer, Sirius. :)

Sirius wrote:Hmmm, I don't see anything wrong with it, but I do recommend testing it at some point, just in case.

Of course I will, as soon as I'll have done "converting" the file to match Korman's behavior.

Sirius wrote:I think it's best to avoid sharing responder states between different responders - usually a responder state is attached to only one responder (Korman might be clever enough to figure it out, though). Making duplicate responder states may make the node graph slightly bigger, but I think it would make it slightly more readable due to your responder states triggering each other

I'm not sure to understand your sentence... :oops:
Do you meant that you think that what I've done is best, or that it's less good?


Sirius wrote:also, this ensures you set only one state as the "default state" - otherwise the responder might end up confused as to which one is the correct one

I'm not sure to understand this one too... :oops:
Do you meant that what I've done allow me to set the 4 responder states as the "default state" (so, I'm right)?
Or do you meant that I should change something to have only 2/4 responder states as the "default state" (so, I'm wrong)?
The way I've done, I can't uncheck the "default state" of any of the 4 responder states; it don't uncheck when I click on the case.


EDIT (add):
Tsar Hoikas wrote:Looking at your responders, I am having a bit of trouble figuring out what the intended effect is. Sirius is generally correct in that it's best to not link a Responder State node to multiple Responders. Doing so should work, but it makes things more difficult to understand. That being said, I think you are otherwise generally on the right path. There are four total responders that are required here. For opening the door, you will want your responder to play the DoorButtonTouch animation, just as you have. Then play the door open animation and the door open sound. From there the responder should end, connecting to nothing else. The python script will handle all the other logic. For closing the door, you will, I think, just want to play the closing animation. If you want to be lazy, you can just play the opening animation backwards.

Again, don't link any Responder states together.

/EDIT

Sirius wrote:the last node which plays a sound will be played only once every other node has completed - which means it might start playing after the door's animation have ended - I'm not 100% sure. For what it's worth, Cyan usually connects all messages to the responder state directly instead of chaining them with Send On Completion (except when a message really needs to wait for another one to finish).

Ah, I've done this way because I don't understand the "Callback" option; I was thinking that "(None)" was meaning something like "no waiting, go to 'Send On Completion' now"... :?
So, what are the Callback's "Stop", "(None)" and "End" options for, please?

EDIT (add):
Tsar Hoikas wrote:You are correct! Callback indicates when the "Send on Completion" nodes should be executed--think of it like "wait until". "None" being "wait until nothing, go immediately!", "End" being, "wait until the last keyframe of the animation, then go!", "Stop" being "wait until the animation stops, then go!". Stop and End can be different, especially if you are not playing the entire animation.

Sirius is correct though in that it is probably better to group together the nodes you want to execute at the same time.

/EDIT

Sirius wrote:it's probably a good idea to uncheck the "driveable" and "reverseable" boxes from One Shot Mods. Those are meant to be used only when the player can "control" the animation using directional keys (think how ladders work). Leaving those checked will likely have undesirable side-effects for what you're trying to do.

OK, I'll uncheck them, thanks.

Sirius wrote:a quick check at Teledahn's files reveal that the xStandardDoor script expects responders to send notify messages. They don't seem to be supported by Korman yet ? However I think they are required, so that might mess some things up. If your door clickables stop working after usage, then it's likely a problem with missing notify messages.

If it isn't supported by Korman yet, I'll try to change this part of the Node Tree when it will be supported (if the door clickables stop working after usage -> I will test as soon as I'll have done "converting" the file to match Korman's behavior).

EDIT (add):
Tsar Hoikas wrote:Korman automatically generates notify messages for Python scripts.

/EDIT

But in Blender 2.49b + PyPRP/AlcScript, how to make the responders sending notify messages?
Do I have to change something in my Python file?

"a.py" from the other Topic: Show Spoiler


Sirius wrote:unless you're relying on the exact door collision to prevent players from passing through it, setting up an exclude region might be useful. But in my experience, the door collision should be enough.

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.

Sirius wrote:you may be able to remove the last four boolean variables from the Python script - they should all be false by default. But I'm not sure, so keeping them around might be safer.

The last is false by default, that's right; for the other three, It isn't written in the "xStandardDoor.py" file what their values by default are... When I'll first test, I'll try to remove them. :)

EDIT (add):
Tsar Hoikas wrote:If you aren't sure what the default is, Korman will show it to you when you connect a node to a Python File. :)

/EDIT

Sirius wrote:Also, I'm not sure if you know about it, but you can get PrpShop from this thread (it's included in PlasmaShop 3.0, which has several similar utilities). It allows you to see what Korman exports as XML structures. It's more advanced and less readable than node trees, but it's extremely useful for debugging. You can also use it to open Teledahn_District_tldnSlaveShroom.prp and see how the xSandardDoor script was setup there.

I have PlasmaShop 2.0 and 3.0, but for now I haven't used them a lot; I used PlasmaShop 2.0 to create SDL and PAK files and to add PY files inside PAK files, and I used PlasmaShop 3.0 to extract PY files from PAK files (creating SDL and PAK files and adding PY files inside PAK files don't work in my PlasmaShop 3.0 :roll: ).
I'll take a look at the "Teledahn_District_tldnSlaveShroom.prp" file.

Sirius wrote:Hope this was useful.

Yes it was, thank you very much! :)
Last edited by Maroonroon on Thu Sep 10, 2020 8:21 am, edited 5 times in total.
User avatar
Maroonroon
 
Posts: 219
Joined: Sun Jul 06, 2014 5:03 pm
Location: France

Re: My first NodeTree

Postby Tsar Hoikas » Sun Nov 10, 2019 1:39 pm

I tried to look at this last night on my phone but couldn't see the image well. It's better today on my PC, but it's still hard to read everything :( . It might take a minute.

Sirius wrote:a quick check at Teledahn's files reveal that the xStandardDoor script expects responders to send notify messages. They don't seem to be supported by Korman yet ? However I think they are required, so that might mess some things up. If your door clickables stop working after usage, then it's likely a problem with missing notify messages.


Korman automatically generates notify messages for Python scripts.
Image
Tsar Hoikas
Councilor of Technical Direction
 
Posts: 2180
Joined: Fri Nov 16, 2007 9:45 pm
Location: South Georgia

Re: My first NodeTree

Postby Deledrius » Sun Nov 10, 2019 2:11 pm

FYI: the red X is because we are abusing Blender's nodes just outside of their comfort level. Blender doesn't want circular node "trees" but Plasma sometimes requires them. So the red wires are unfortunately a bit of a false warning we can't disable.
User avatar
Deledrius
Gehn Shard Admin
 
Posts: 1377
Joined: Mon Oct 01, 2007 1:21 pm

Re: My first NodeTree

Postby Tsar Hoikas » Sun Nov 10, 2019 2:28 pm

Ok, I think I've sort of seen everything. The bad news is that this set of doors is not going to work, I think. The good news is that you have a lot of the right pieces present and are on the right track. Doors in Uru are a bit more complicated than they really need to be. I know Deledrius has been working on a sample age showing how to hook them up in Korman, but it's not quite ready yet. In the meantime, here's what I can say about hooking up door node trees.

The doors in Uru are controlled by SDL and Python. The xStandardDoor script handles the logic behind opening the door, specifically with regard to handling multiple avatars. This script isn't the only one involved though. You need to have a second script, xAgeSDLBoolToggle to actually tell the door to open. You should consider these scripts as being the "brains" of the whole process.

Looking at your tree, I see that you have correctly created the nodes for the clickables on both the inside and outside of the door and have them hooked up correctly to the xStandardDoor script. You also need to create two nodes for the xAgeSDLBoolToggle script. One of those nodes needs to be linked to the outside clickable and the other to the inside clickable. For future reference, you can omit the "Avatar Facing Target" node on your clickable.Korman provides that functionality by default.

Looking at your responders, I am having a bit of trouble figuring out what the intended effect is. Sirius is generally correct in that it's best to not link a Responder State node to multiple Responders. Doing so should work, but it makes things more difficult to understand. That being said, I think you are otherwise generally on the right path. There are four total responders that are required here. For opening the door, you will want your responder to play the DoorButtonTouch animation, just as you have. Then play the door open animation and the door open sound. From there the responder should end, connecting to nothing else. The python script will handle all the other logic. For closing the door, you will, I think, just want to play the closing animation. If you want to be lazy, you can just play the opening animation backwards.

Again, don't link any Responder states together.

Maroonroon wrote:Ah, I've done this way because I don't understand the "Callback" option; I was thinking that "(None)" was meaning something like "no waiting, go to 'Send On Completion' now"... :?
So, what are the Callback's "Stop", "(None)" and "End" options for, please?

You are correct! Callback indicates when the "Send on Completion" nodes should be executed--think of it like "wait until". "None" being "wait until nothing, go immediately!", "End" being, "wait until the last keyframe of the animation, then go!", "Stop" being "wait until the animation stops, then go!". Stop and End can be different, especially if you are not playing the entire animation.

Sirius is correct though in that it is probably better to group together the nodes you want to execute at the same time.

Maroonroon wrote:
Sirius wrote:you may be able to remove the last four boolean variables from the Python script - they should all be false by default. But I'm not sure, so keeping them around might be safer.

The last is false by default, that's right; for the other three, It isn't written in the "xStandardDoor.py" file what their values by default are... When I'll first test, I'll try to remove them. :)


If you aren't sure what the default is, Korman will show it to you when you connect a node to a Python File. :)
Image
Tsar Hoikas
Councilor of Technical Direction
 
Posts: 2180
Joined: Fri Nov 16, 2007 9:45 pm
Location: South Georgia

Re: My first NodeTree

Postby Deledrius » Sun Nov 10, 2019 3:19 pm

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.

Tsar Hoikas wrote:Doors in Uru are a bit more complicated than they really need to be. I know Deledrius has been working on a sample age showing how to hook them up in Korman, but it's not quite ready yet.

Yeah, just got stuck several months ago trying to finish up the final animation and haven't gotten back to it. Whoops.

Tsar Hoikas wrote:The doors in Uru are controlled by SDL and Python. The xStandardDoor script handles the logic behind opening the door, specifically with regard to handling multiple avatars. This script isn't the only one involved though. You need to have a second script, xAgeSDLBoolToggle to actually tell the door to open. You should consider these scripts as being the "brains" of the whole process.


Basically how it works when it comes to these two scripts is:

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. Pretty simple, the xAgeSDLBoolToggle script handles this for you. You just tell it what the clickable is, and what the variable is to toggle, and it does all the book-keeping for the SDL when it's activated.

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!

The cool thing about this is that you can combine these parts in a lot of really nifty ways, using these or other scripts.

Tsar Hoikas wrote:If you want to be lazy, you can just play the opening animation backwards.

For some doors, this makes sense and isn't lazy at all! For other doors, it would look terrible. :p

Tsar Hoikas wrote:If you aren't sure what the default is, Korman will show it to you when you connect a node to a Python File. :)

IOW, if you connect a little data node and the automatic value is the one you want, it's probably safe to just skip the node. Generally speaking, the defaults for value (when not otherwise specified) are going to be false/empty. False for booleans, "" for strings, 0 for numbers, etc. But as Hoikas said, you can always check that it's what you want by connecting the node. There's no harm in leaving a node connected with a default value if you prefer, except that it can visually clutter things up.
User avatar
Deledrius
Gehn Shard Admin
 
Posts: 1377
Joined: Mon Oct 01, 2007 1:21 pm

Re: My first NodeTree

Postby Maroonroon » Sun Nov 10, 2019 5:02 pm

Woaw, thank you for your answers, Tsar Hoikas and Deledrius. :)

Tsar Hoikas wrote:
Sirius wrote:a quick check at Teledahn's files reveal that the xStandardDoor script expects responders to send notify messages. They don't seem to be supported by Korman yet ? However I think they are required, so that might mess some things up. If your door clickables stop working after usage, then it's likely a problem with missing notify messages.

Korman automatically generates notify messages for Python scripts.

Thanks! :)

Deledrius wrote:FYI: the red X is because we are abusing Blender's nodes just outside of their comfort level. Blender doesn't want circular node "trees" but Plasma sometimes requires them. So the red wires are unfortunately a bit of a false warning we can't disable.

Thanks! :)

Tsar Hoikas wrote:The doors in Uru are controlled by SDL and Python. The xStandardDoor script handles the logic behind opening the door, specifically with regard to handling multiple avatars. This script isn't the only one involved though. You need to have a second script, xAgeSDLBoolToggle to actually tell the door to open. You should consider these scripts as being the "brains" of the whole process.

Looking at your tree, I see that you have correctly created the nodes for the clickables on both the inside and outside of the door and have them hooked up correctly to the xStandardDoor script. You also need to create two nodes for the xAgeSDLBoolToggle script. One of those nodes needs to be linked to the outside clickable and the other to the inside clickable. For future reference, you can omit the "Avatar Facing Target" node on your clickable.Korman provides that functionality by default.

OK, I think I understand.

Tsar Hoikas wrote:Looking at your responders, I am having a bit of trouble figuring out what the intended effect is. Sirius is generally correct in that it's best to not link a Responder State node to multiple Responders. Doing so should work, but it makes things more difficult to understand. That being said, I think you are otherwise generally on the right path. There are four total responders that are required here. For opening the door, you will want your responder to play the DoorButtonTouch animation, just as you have. Then play the door open animation and the door open sound. From there the responder should end, connecting to nothing else. The python script will handle all the other logic. For closing the door, you will, I think, just want to play the closing animation. If you want to be lazy, you can just play the opening animation backwards.

Again, don't link any Responder states together.

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.

Tsar Hoikas wrote:
Maroonroon wrote:Ah, I've done this way because I don't understand the "Callback" option; I was thinking that "(None)" was meaning something like "no waiting, go to 'Send On Completion' now"... :?
So, what are the Callback's "Stop", "(None)" and "End" options for, please?

You are correct! Callback indicates when the "Send on Completion" nodes should be executed--think of it like "wait until". "None" being "wait until nothing, go immediately!", "End" being, "wait until the last keyframe of the animation, then go!", "Stop" being "wait until the animation stops, then go!". Stop and End can be different, especially if you are not playing the entire animation.

Sirius is correct though in that it is probably better to group together the nodes you want to execute at the same time.

OK :)

Tsar Hoikas wrote:
Maroonroon wrote:
Sirius wrote:you may be able to remove the last four boolean variables from the Python script - they should all be false by default. But I'm not sure, so keeping them around might be safer.

The last is false by default, that's right; for the other three, It isn't written in the "xStandardDoor.py" file what their values by default are... When I'll first test, I'll try to remove them. :)

If you aren't sure what the default is, Korman will show it to you when you connect a node to a Python File. :)

Where do Korman shows it?
Edit: Ah yes, of course... Forget this question... ;)

Thank you very much, guys!
I'll upload the screenshot of my new attempt as soon as possible.
Previous post edited.
User avatar
Maroonroon
 
Posts: 219
Joined: Sun Jul 06, 2014 5:03 pm
Location: France

Re: My first NodeTree

Postby Tsar Hoikas » Sun Nov 10, 2019 6:51 pm

Maroonroon wrote: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.


That's right. We'll be glad to look at your revised node tree when you get it ready :)
Image
Tsar Hoikas
Councilor of Technical Direction
 
Posts: 2180
Joined: Fri Nov 16, 2007 9:45 pm
Location: South Georgia

Re: My first NodeTree

Postby Maroonroon » Sun Nov 10, 2019 7:58 pm

Here we go: Attachment removed
Last edited by Maroonroon on Mon Nov 11, 2019 9:15 pm, edited 1 time in total.
User avatar
Maroonroon
 
Posts: 219
Joined: Sun Jul 06, 2014 5:03 pm
Location: France

Next

Return to Scripting

Who is online

Users browsing this forum: No registered users and 4 guests