VRML - EXTERNPROTO and directOutput question

Author

EXTERNPROTO and directOutput question

muaddib

2003-12-04, 1:00 pm

I am having a problem with a Script node in Contact, but not in Cortona
or Cosmo. I would like to know if I am violating the spec, and Cortona
and Cosmo are just letting me get away with it, or if this is an error
in Contact.
In my script, I reference an instance of a protoed node through a
field, and attempt to send it an event. If the proto is in the same
file as the script, it works in all three. If it is referenced through
an externproto then it doesn't receive the event in Contact. Here is
example code:

test.wrl:
EXTERNPROTO TestNode [
eventIn SFInt32 event
] "testnode.wrl"

DEF testNode TestNode {}

Script {
field SFNode testNode USE testNode
directOutput TRUE
url "java script:
function initialize() {
testNode.event = 1;
}
"
}

testnode.wrl:
PROTO TestNode [
eventIn SFInt32 event
] {
Script {
eventIn SFInt32 event IS event
directOutput TRUE
url "java script:
function event(value) {
print( 'event called' );
}
"
}
}

If I am violating the spec, what is the compliant way of doing the above?
Also, is it not true that to directly send an event to a node through a
script, directOutput must be set to TRUE? I find that having it set to
FALSE doesn't stop the example from working.

Thanks,
Rob

Herbert Stocker

2003-12-04, 1:00 pm

muaddib wrote:

quote:

> I am having a problem with a Script node in Contact, but not in
> Cortona or Cosmo. I would like to know if I am violating the spec, and
> Cortona and Cosmo are just letting me get away with it, or if this is an
> error in Contact.
> In my script, I reference an instance of a protoed node through a
> field, and attempt to send it an event. If the proto is in the same
> file as the script, it works in all three. If it is referenced through
> an externproto then it doesn't receive the event in Contact. Here is
> example code:
>
> test.wrl:
> EXTERNPROTO TestNode [
> eventIn SFInt32 event
> ] "testnode.wrl"
>
> DEF testNode TestNode {}
>
> Script {
> field SFNode testNode USE testNode
> directOutput TRUE
> url "java script:
> function initialize() {
> testNode.event = 1;
> }
> "
> }
>

ExternProtos may be delayloaded and you send the
event in the initialize() function.
This means, that when the Script node is initialized,
the ExternProto may not yet be loaded.

Now the Spec says, that if an ExternProto receives an
event before it gets loaded, the Browser can dispose
this event.

Trigger the sending of the event from a TouchSensor then
you will see the event will be received.
Or run the example from the local disk. Then the ExternProto
gets loaded immediately.

IMHO this is bad point in the spec, because it makes
initializing the components of a modularized world with
lots of scripting difficult.

quote:

> testnode.wrl:
> PROTO TestNode [
> eventIn SFInt32 event
> ] {
> Script {
> eventIn SFInt32 event IS event
> directOutput TRUE
> url "java script:
> function event(value) {
> print( 'event called' );
> }
> "
> }
> }
>
> If I am violating the spec, what is the compliant way of doing the above?
> Also, is it not true that to directly send an event to a node
> through a script, directOutput must be set to TRUE? I find that having
> it set to FALSE doesn't stop the example from working.
>

If you set directOutput to TRUE, it means that the browser must deliver
the event.
If you set it to FALSE, it means that the browser need not to send the
event. E.g. for optimization reasons it can overlook the event.

Herbert

--
Herbert Stocker (aka hersto)
http://www.hersto.de
www.bitmanagement.de

muaddib

2003-12-04, 1:00 pm

Herbert,
Thanks, that was very helpful. Perhaps you will be able to help me
with this one as well. Same situation, doesn't work in Contact, does in
the other two. Here I try to set the children of an externprotoed node
in the body of a protoed node:

test.wrl:
EXTERNPROTO TestNode [
field MFNode children
] "testnode.wrl"

PROTO Test [] {
TestNode { children Box{} }
}

Test {}

#TestNode { children Box{} }

testnode.wrl:
PROTO TestNode [
field MFNode children []
] {
Group {
children IS children
}
}

As is, I can't see the box.
If I put the TestNode proto into test.wrl, I can see the box.
If I comment Test {} and uncomment TestNode, I can see the box.

Herbert Stocker

2003-12-04, 1:00 pm

muaddib wrote:

quote:

> Herbert,
> Thanks, that was very helpful. Perhaps you will be able to help me
> with this one as well. Same situation, doesn't work in Contact, does in
> the other two. Here I try to set the children of an externprotoed node
> in the body of a protoed node:
>
> test.wrl:
> EXTERNPROTO TestNode [
> field MFNode children
> ] "testnode.wrl"
>
> PROTO Test [] {
> TestNode { children Box{} }
> }
>
> Test {}
>
> #TestNode { children Box{} }
>
>
>
> testnode.wrl:
> PROTO TestNode [
> field MFNode children []
> ] {
> Group {
> children IS children
> }
> }
>
> As is, I can't see the box.
> If I put the TestNode proto into test.wrl, I can see the box.
> If I comment Test {} and uncomment TestNode, I can see the box.
>

Ah, you are using blaxxun Contact 5.1, right?
This has a bug connected with the initialization values
of Protos.
Use BS Contact 6.1, which is the current version of Contact.
Here this bug is fixed, and you can see the box.

Herbert

--
Herbert Stocker (aka hersto)
http://www.hersto.de
www.bitmanagement.de

muaddib

2003-12-04, 1:00 pm

Yes, I am using Contact 5.1. The example did work after the upgrade to
Contact 6.

R. Russell Kinter

2003-12-04, 1:00 pm

In my experience, I avoid intialize() as much as possible.
In doing multiuser vrml programming in the blaxxun community,
one way to get a user's nickname is use:

function intialize(){ foo = Browser.myAvatarName;}

Problem arose with certain avs (the ones that were most popular!)
that were so performance draining that Contact would be too
distracted to carry out initialize.
What does/did work instead is to ROUTE from myAvatarName exposedField in
the BlaxxunZone Proto (sorry for the blaxxun-ese) so the nick would
be gotten when Contact had time to do it.

It's better for the world to be "warmed up" before trying
to do stuff. If I want to do something at the opening of the world
and make sure it gets done, a looping TimeSensor does the trick.
That way it can double check its work and get feed back from
a script to tell it mission accomplished you can turn off now.
A little slower, but it works.

Herbert Stocker <hst-uzd-nospam@hersto.de> wrote in message news:<3FC12A91.4020606@hersto.de>...

quote:

>
> ExternProtos may be delayloaded and you send the
> event in the initialize() function.
> This means, that when the Script node is initialized,
> the ExternProto may not yet be loaded.
>
> Now the Spec says, that if an ExternProto receives an
> event before it gets loaded, the Browser can dispose
> this event.
>
> Trigger the sending of the event from a TouchSensor then
> you will see the event will be received.
> Or run the example from the local disk. Then the ExternProto
> gets loaded immediately.
>
> IMHO this is bad point in the spec, because it makes
> initializing the components of a modularized world with
> lots of scripting difficult.
>
>
>
> If you set directOutput to TRUE, it means that the browser must deliver
> the event.
> If you set it to FALSE, it means that the browser need not to send the
> event. E.g. for optimization reasons it can overlook the event.
>
>
> Herbert