[X3D-Public] unreal exporter Error 52: Bad Filename or Number

[steve guynup]

Bringing files over from Unreal 3 into VRML/X3D is proving bothersome.
Has anyone here dealt with "Error 52: Bad Filename or Number"?

(since I don't need much, I wonder if just poaching materials and some static meshes from Dave's and other peoples work might be enough.)

regards
Steve



________________________________________________

Improvement makes straight roads, 
but the crooked roads, without Improvement, 
are roads of Genius.” 

- William Blake


--- On Wed, 6/24/09, Braden McDaniel <braden at endoframe.com> wrote:

> From: Braden McDaniel <braden at endoframe.com>
> Subject: Re: [X3D-Public] Web3D.org Front Page
> To: x3d-public at web3d.org
> Date: Wednesday, June 24, 2009, 10:04 PM
> On Tue, 2009-06-23 at 21:23 -0700,
> Joe D Williams wrote:
> > 
> > >>>  <object data="your.wrl" ...
> >
> > >>> <param name="src" value="your.wrl"
> >
> > >>> </object>
> > >>>
> > >>
> > >> The duplication of data="your.wrl"
> > >> and
> > >> name="your.wrl"
> > >> is just due to the fact that BS didn't
> recognize the src param.
> > >
> > > Presumably you mean "that BS didn't recognize the
> data attribute".
> > 
> > No, @data is standard and everybody accepts that.
> 
> "data" *is* standard; but what Lauren has described
> suggests that it
> doesn't work with Contact.  I don't have Contact here,
> so I can't test
> it myself.  But if this is accurate, I can't say I
> find it *that*
> shocking.  If one were to bolt an NPAPI interface onto
> an ActiveX
> control, it is the sort of thing that could get overlooked
> (because it
> is a way in which ActiveX containers differ in behavior
> from NPAPI
> hosts).
> 
> > The <param> src, or whatever the X3D browsers
> makers decide, is the 
> > one missing last time I checked.
> > In fact, the last time I looked, Flux was the only one
> that accepted 
> > the url via a <param>.
> 
> Flux does so mostly because it is primarily an ActiveX
> control.  I think
> Contact and Cortona are in the same boat there.
> 
> IIRC, the ActiveX container has some special awareness of
> the "src"
> param and it gets some special handling.
> 
> > >> Flux
> > >> did, so we used both to cover all.
> > >> I haven't checked now whether BS or Octaga,
> and Instant will 
> > >> recognize
> > >> the src param.
> > >>
> > >> Anyway in the big view, it is better for a
> plugin to use the 
> > >> <param> and
> > >> drop using @data, if possible. One reasin is
> that the host browser 
> > >> may
> > >> treat the content differently if requested in
> data attr rather than 
> > >> the
> > >> src param.
> > >
> > > Er, no.
> > >
> > > If you don't use the "data" attribute, there's
> nothing to indicate 
> > > to the Web browser that it should start the
> plug-in. .)
> > 
> > Uh no, what actually happens, usually, is that if data
> is empty the 
> > the plugin will be started on the stregth of finding a
> registered 
> > palyer for the mime in @type.
> > 
> > >  Some current and historic implementations
> might use the "type" 
> > > attribute for this purpose; but this is
> unreliable as the "type" 
> > > attribute is technically only a hint. (That is,
> the Web browser 
> > > could opt not to fetch the data at all if the
> media type given in 
> > > "type" were unsupported
> > 
> > http://www.ietf.org/internet-drafts/draft-abarth-mime-sniff-01.txt
> > 
> > is in work now, but they are mostly skipping the hard
> parts.
> 
> If one simply configures the Web server to send the correct
> media type,
> what's described in that draft is rendered moot.
> 
> And note that, should this draft proceed to RFC status, it
> would
> presumably need to update RFC2616 (HTTP/1.1).
> 
> > True, if the media type is not supported the host
> won't even try.
> > There are other problems is the server doesn't provide
> a matching 
> > content type.
> > 
> > >
> > > I haven't tested it yet, but recent
> bugzilla.mozilla.org activity 
> > > leads me to suspect that Firefox 3.5 might
> finally be implementing 
> > > this more-or-less to spec.
> > 
> > Yes, hard to tell what the spec is because they are
> sort of honoring 
> > classid.
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#the-object-element
> > 
> > >
> > >> In particular, the browser may try to 'sniff'
> content type or other
> > >> aspects of the file, as well as download the
> complete file before
> > >> sending it to the plugin when data is used.
> > >
> > > Aside from the "classid" attribute, *the
> server-provided media type 
> > > is the only specified means to indicate what
> plug-in should be 
> > > started*. That means that a correct
> implementation cannot start the 
> > > plug-in until *after* the resource specified in
> "data" has started 
> > > downloading.
> > 
> > Fortunately that is not true.
> 
> It is true as far has HTML 4 is concerned.
> 
> >  Prefereably the host will start the 
> > plugin if it recognizes the mime even if the @data is
> blank and the is 
> > not a <param> with a url.
> > This is desired because then you can wait to see if
> the plugin is 
> > running before sending it a url.
> 
> The problem with this is HTTP/1.1, which specifies that the
> Content-Type
> sent from the server must be honored.  So, in order to
> conform to that
> specification, a Web browser that loaded a plug-in based
> solely on the
> "type" attribute would then have to *unload* the plug-in
> and load a new
> one in the event that the type sent from the server
> differed from that
> specified by the "type" attribute.
> 
> That's a lot of overhead to incur.
> 
> > The progblem is that (and I have to keep checking
> this) is tht IE and 
> > other browsers won't let you send in a new @data value
> via the DOM.
> 
> How is this not a bug? Have you submitted bug reports? (Or
> are you aware
> of existing ones?)
>  
> > You have to rewrite the entire <object> tag to
> change the URL. This is 
> > not ture with a player that accepts a url via the
> <param> (Flux) 
> > because you can always send in a new url via the src
> <param>
> 
> In changing the URI specified in the HTML, you'd need
> effectively to
> restart the plug-in, anyway.  Practically speaking,
> the result isn't
> much different from just replacing the whole "object"
> element.  If you
> want to avoid that, use Browser.loadURL in the SAI.
> 
> > >> On the other hand, if src
> > >> param is used, then the url is sent to the
> plug when it is ready 
> > >> and
> > >> then the plugin asks for the content when it
> is ready.
> > >
> > > A correctly written NPAPI plug-in will be ready
> for an initial 
> > > stream. Period.  There is absolutely nothing
> about VRML or X3D that 
> > > would make implementing this especially
> problematic.
> > 
> > Right, The host gets the plugin running, then when the
> plugin is 
> > ready, the host sends attributes and params. It is
> nice that the 
> > browser can start the plugin without a content file.
> However, unless 
> > the plugin can accept a url cvai a param, the object
> tag si a bit 
> > dificult to program.
> 
> No, that's not what an initial stream is.  The initial
> stream is the
> resource specified by the "data" attribute.
> 
> > >> In the <param>
> > >> case, the host browser is probably less
> involved in the loading 
> > >> process.
> > >
> > > Well, it's not involved at all in that
> case--except potentially 
> > > though its cache.  That is, the browser is
> going to fetch the 
> > > resource specified in "data" *no matter
> what*.  If the plug-in 
> > > subsequently uses NPAPI facilities to fetch the
> resource associated 
> > > with a "src" param, one can hope that this will
> just be a cache hit.
> > 
> > These are separate operations, not the same. The
> process the browser 
> > uses to get content specified with @data is different
> than the proces 
> > when the src <param> is used.
> 
> Please reread above, esp. the "uses NPAPI facilities"
> part.
> 
> >  THis is why it is important that X3D 
> > browser makers get cnsensue on what param to use.
> Since Flux used src, 
> > so should all the rest, I think. Or pick somehting
> else. This is not 
> > important until you understand little details about
> how object works.
> 
> I am very familiar with the details of how object works and
> how it is
> specified.  You seem to be focusing on the strengths
> and weaknesses of a
> particular implementation (Flux) and drawing conclusions
> about how
> things should be standardized based on them.  I fully
> appreciate the
> need to articulate pragmatic solutions that work
> today.  However, the
> specification of future standards needs to take into
> account current
> standards as well recognize what shortcomings in current
> software are
> solvable problems.
> 
> > > Keep in mind, though, that in such a case, the
> NPAPI call will 
> > > provide no different media type information than
> it would have for 
> > > the initial stream.
> > >
> > > As you suggest, it *is* possible for the plug-in
> to provide its own 
> > > resource fetching machinery.  But there are
> a lot of downsides to 
> > > that--and not many upsides as far as I can tell:
> > 
> > Sure, it can run 'standalone'.
> 
> There are better ways to do that: you can abstract the
> resource fetching
> subsystem such that it can be arbitrarily backed either by
> a Web
> browser's facilities or something else.
> 
> > >  * The Web browser's fetch of the initial
> stream becomes entirely
> > >    wasted.
> > >  * You end up writing a lot of code for
> facilities that are provided
> > >    by the host Web browser.  If
> you provide a sophisticated cache 
> > > like
> > >    modern Web browsers do, we're
> talking about *quite* a lot of 
> > > code.
> > >    So, more initial development time,
> more cost to maintain, and 
> > > more
> > >    potential for bugs.
> > 
> > Right, it is just one way to do it. Some X3D browsers
> want to be very 
> > self-sufficient.
> 
> I can appreciate that in some cases pragmatic concerns may
> override what
> is normally the path of least resistance to providing an
> optimal user
> experience.  But those are not the sorts of cases that
> should be catered
> to when establishing standards and conventions.
> 
> > >  * You lose the potential to share cached
> data with other services
> > >    provided by the Web browser. 
> For instance, consider an image
> > >    referenced from an HTML page that
> subsequently gets used as a
> > >    texture in an X3D world.
> > 
> > If the URL is the same, then there may be some chance
> of reusing it.
> 
> Not unless you're talking about some cache that is external
> to all of
> the programs we're talking about (which would miss the
> point entirely).
> 
> > > If the plug-in just uses the NPAPI facilities for
> resource fetching, 
> > > it gets to take advantage of pretty thoroughly
> tested code that 
> > > includes a sophisticated cache.  I'm just
> not sure why a plug-in 
> > > developer would turn that down.
> > 
> > One whose second choice is be be hosted in a web
> page?
> 
> As noted above, you can abstract the resource fetching
> subsystem and
> have the best of both worlds.
> 
> -- 
> Braden McDaniel <braden at endoframe.com>
> 
> 
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>