... except my own machines, classic no? Still consistent reports from the client and others that this scene crashes IE of any 5.x on any windows box he has at home or school. I have been unable to reproduce the crash on any winOS box at home on any IE 5.x, or 6.x browser. Strange no? all using vmp 3.0.8. If you have a moment, please try and post results (sorry for the 'site check'-ish post), relevant though.

http://thecryingpostproject.org/

if you'd like to _really_ help ;p and get in the credits, here's the source:

(xml/js only
http://thecryingpostproject.org/cryingPost_xml.zip

(the whole shebang
http://thecryingpostproject.org/cryingPost_source.zip

the whole shebang is 6MB; the client/artist is aiming for a highband/CDROM situation so he can used high res textures, and perhaps therin lies the problem, but I cannot reproduce/verify.

TIA for any help/suggestions. ~drd

Hi Duncan,

I downloaded your scene and took a look at it and it did indeed crash my IE, but not my Netscape. Question #1: how is this supposed to work and what is it for?

Quite frankly, looking at the code suggests any number of reasons why this is crashing, but I'm sure that the overall cause is that things are way, way too complicated. A byproduct of this over-complication is that items get misreferenced. I found at least twenty misreferenced actions in the MTX. (I won't post them all here, but if you write me, I'll send you the list.) Those MTSActions and a huge number of MTSHandle events were not necessary, or could have been done in a much simpler manner. Sometimes, you rely on javascript to do things that would be much more efficient via the MTX. Also, MTSEventCollection to tell the plugin that loading is done, which in turn tells it to do something. Couldn't you just use Event="AnimationDone" instead? It's only one line of code to do the same thing.

There are about fifty lines like this:
[MTSHandle Event="MTSLoadDone:textureBlue" Action="MTSJavaScript" Target="collectLoadEvents('textures.blue')"/] Can you elaborate on what this does?

Also, CollectPlaneEvents is another example- what is this for?

Also, and this is huge, there are real optimization problems. You have a 500+kb texture for the earth. That's just way, way, way too big for a model like this, especially when there are 40 other external texture images involved. You also have 512x512 px jpg's of solid colors (black, red, etc.) where you can simply use diffuse colors. Also, there are 44 mp3 sound files associated with this. That's kind of a lot (understatement.) Also, there are are at least 30 mesh instances and some of them get repeated in the cryingpost.mtx. Just seems like way too many.

So, apologies if this sounds harsh, but I think this could be simplified to include lowband with zero loss of quality or interactivity and a huge gain in stability. If you can elaborate on what you want to do with this, I think that forum users can give you some great suggestions of streamlining.

Chris

Chris,

thank you for your time and help, check your email for my reply.

(taking the source down, for now)

Problem solved, and it was indeed the excessive js calls:

[MTSHandle Event="MTSLoadDone:textureBlue" Action="MTSJavaScript" Target="collectLoadEvents('textures.blue')"/]

;p probably less to do with the implemention of MTSJavaScript Action than just the differences in speed/stability of the browser js interpreters, which is why 5.x crashed and 6.x did not, etc. The solution was just to have the function loop itself, so it's not being called again before it's done. Obvious now I guess, but learned something new... the hard way ;p

thx for the help Chris, I'll post when done.