you can't use anything that you use to normally render in 2D to render in 3D in Q3D. you can place that stuff above or below the Q3D canvas, but thats it.

there's likely a reason it was done that way for optimization reasons.

i don't know off the top of my head, but theres a list of instances which you can get from the js object for a particular type which is passed in from the object param.

here, you weren't quite doing things right.

Mouse example

If your camera is not rotating / zooming in or out, you can just use mouse.x / mouse.y and set the layout scroll to the camera x/y position. You could also use absolute x and absolute y, but you'd have to shift the value. this is still basic vector math.

make two global variable which you set after moving the camera

// camera moving events go here //

q3dmousex = q3d.camx+mouse.absoluteX-windowwidth/2

q3dmousey = q3d.camy+mouse.absoluteY-windowheight/2

//////////////////////////////////////////// any events that need the Q3D mouse position come after.

if you only change the camera x and camera y position this will work, rotating the camera will require the vector math i was talking about, moving the camera will too.

The Q3D.sprite does what it does... its quite self explanatory. Have you tried using it? It's just a billboard for 2D graphics in 3D. it doesn't make 2D graphics 3D, it displays 2D graphics in a way which allows them to be layered with 3D objects in the scene.

you're incorrect, behaviors have access to everything you'd need to write a controller. Calling specific conditions from the physics behavior is not how you'd go about it. you have to call the methods available to the instance / behaviour instance. if you wanted to write a behavior that runs events using conditions / actions / expressions, you're doing things wrong, you can do that in construct itself.

What do you even mean by attribute?

you can make a behavior which modifies an instance. You can make a flag on the instance. you can then check for that flag on the instance, which is effectively what you want to do, you can even make the behaviour control multiple 'attributes' and flags. It's not very complicated.

pushing out of an object requires complex detection routines / memory management to be fast, you're greatly simplifying things.

you'll need to grab those positions before the layout changes. construct doesn't automatically save the previous object positions like that. Make a plugin with an action that has an object type param, and save the positions of all the objects picked into an array or js object, then process them in the next layout by making your object global or saving the array to some global js object.

I'm still confused by what you mean by mouse x y. the coordinate system is fixed while the camera can rotate. You mean the intersection of the mouse position in screen space projected onto the x,y plane formed by the world x,y axis's? You'll need to use a line plane intersection formula:

http://geomalgorithms.com/a05-_intersect-1.html,

You'd have to generate a line using the mouse position / camera orientation/axis. It's a bit involved if you're not comfortable with vector math, but its a simple enough task to start learning with. The ray you generate will depend on the type of camera you're using. I guess i'll eventually add a helper function to do this using the viewport object.

again these aren't specific things to the plugin, you'll need to learn basic 3D maths to do this kind of stuff.

I managed to fix the problem by deleting a multi line comment from within a function...

i had something like:

alert('start')

Act.prototype.function001 = function(){

var do,code;

stuff(true);

code = stuff();

/* bla bla bla

blalblabla

bla bla

this is actually a multiline comment*/

}

alert('1');

...... etc.

if i delete the multi-line comment from within the function, everything works as intended...

There something very wrong with how multi-lines are being handled by the exporter. I think its pretty agreeable that deleting a comment is a very obscure bug-fix. I almost don't believe it's that but after testing quite a bit im 100% sure.

I can send you stuff if you want to investigate but it'll have to be privately.

So far what i understand a little more from more testing.

I have a lot of actions (about 150). From the previous for-in loop i found that there was a chunk of maybe about 30+ actions that come up sequentially in the runtime.js file of my plugin but are missing from the prototype in export. there are actions which aren't missing which come before and after this chunk. My theory is that the 'compiler' - parser- whatever you might call it, which runs during export, is clipping out a big chunk of code from the runtime for some strange reason which i'm not sure of.

I added alerts throughout my code so that i have my runtime.js file set up something like this:

.................... above this point there are lots of actions that weren't missing around where actions started to go missing from acts.proto on export i added alerts.

alert('start')

Acts.prototype.function001 = function(p1,p2,p3){

//code

};

alert('1');

Acts.prototype.function001 = function(p1,p2,p3){

//code

};

alert('2');

Acts.prototype.function002 = function(p1,p2,p3){

//code

};

alert('3');

Acts.prototype.function003 = function(p1,p2,p3){

//code

};

alert('end')

.................. more actions which didn't go missing.

running the project, in preview all the alerts fire as you would expect, but on export only those which come after a certain point, and those which come before a certain point, are firing. theres a block of script which just disappears for no good reason. I've poured over the code and there doesn't "seem" to be anything suspicious which should cause this, but it's happening anyway.

I've made a simple routine to check which functions are being added to Act.prototype

var str = ""

var key

for( key in Acts.prototype) str += key+"\n"

alert(str);

when i call this, in preview all my actions appear, but in export a big block of them are mysteriously gone, but not all of them.