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...
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...
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
Replace "Door01Closed" by "OfficeDoorClosed" to match the Node Tree...
- Code: Select all
from Plasma import *
from PlasmaTypes import *
gPages = [
'FemaleSwimDockExit',
'MaleSwimDockExit']
# Note: Change all "ptResponder" to "ptModifier" for a Modifier class
class a(ptResponder):
def __init__(self):
ptResponder.__init__(self)
self.id = 281000
self.version = 1
PtPageInNode(gPages)
def OnFirstUpdate(self):
pass
def OnServerInitComplete(self):
sdl = PtGetAgeSDL()
sdl.setFlags('Door01Closed', 1, 1)
sdl.sendToClients('Door01Closed')
sdl.setNotify(self.key, 'Door01Closed', 0.0)
def OnNotify(self, state, id, events):
pass
def OnSDLNotify(self, VARname, SDLname, playerID, tag):
if SDLname != 'a':
print 'SDLname =', SDLname, ', not a'
elif VARname == 'Door01Closed':
ageSDL = PtGetAgeSDL()
getSDL = ageSDL[VARname][0]
def __del__(self):
for page in gPages:
PtPageOutNode(page)
### Python Glue ###
[...]
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
).
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!