macklebee

you must live in a nice fantasy world... its always amusing how you make things up and say them as facts just because you want something to be that way...

so with that logic, you should charge 100 times more for linux apps

granted this was not what NA wanted to find out... his original question was to just see how well it worked on different platforms/cards... I am sure NA has already taken care of this lil "glitch"... just it wasn't part of his requirement for testing purposes...

or just rotate the emitter around a point/object... require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) SetWorld(fw.transparency.world) object.emitter=CreateEmitter(500,5000,Vec3(1,0,1)) object.emitter:SetParent(object.model) object.emitter:Paint(LoadMaterial("abstract::smoke.mat")) object.emitter:SetColor(Vec4(1,0,0,1)) object.emitter:SetRadius( .3, .01 ) object.emitter:SetPosition(Vec3(model.position.x+2,model.position.y,model.position.z),1) SetWorld(fw.main.world) function object:Update() TurnEntity(object.model,Vec3(0,-10,0)) end function object:Free() object.emitter:Free() self.super:Free() end end EDIT--- added radius setting to allow you to see the emitter

i meant the controller as being the first node/starting point which would require that it be separate from the grid... but w/e... we are suggesting the same thing just different way to achieve it... but having it pick the node closest in the direction of the intended path would definitely resolve the issue.

eh... needs fine tuning, but this might work for your purpose... require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) SetWorld(fw.transparency.world) object.circlevalue = 0 object.emitter=CreateEmitter(5000,10000,Vec3(math.cos(object.circlevalue),0,math.sin(object.circlevalue))) object.emitter:SetParent(object.model) object.emitter:Paint(LoadMaterial("abstract::smoke.mat")) object.emitter:SetColor(Vec4(1,0,0,1)) object.emitter:SetRadius( .3, .01 ) object.emitter:SetRotationSpeed( .5 ) object.emitter:SetWaver( .5 ) object.emitter:SetPosition(object.model.position,1) SetWorld(fw.main.world) function object:Update() object.emitter:SetVelocity(Vec3(math.cos(object.circlevalue),0,math.sin(object.circlevalue)) ) object.circlevalue = object.circlevalue +.5 end function object:Free() object.emitter:Free() self.super:Free() end end EDIT-- parented the emitter to model to remove the need for the UpdateMatrix function

well coco, for that the easiest fix would seem to just increase the number of grid points. or just make it so the starting point is always the location of the character.

NA, i think he is referring to the character always moving back to the starting point... so if you click a point for the character to walk towards... wait for the character to start walking, then click another point right next to where you originally selected, the character will turn around and walk back to the starting point then continue to go the selected point. I assume this could be easily taken care of by just increasing the grid mesh to allow for more points in between... or just use grid points that are actually between the controller and the end point, removing the previous start point...

well, actually... now that the GMF2OBJ converter by masterxilo exists, you could try converting the monstertruck gmf back to OBJ and then creating the dynamic PHY file using phygen...

thats because the oildrum has a dynamic physics body created by phygen or obj2phy... the monstertruck is using an older PHY file that will not work with 2.4, and since the OBJ file is not available, you cannot create the new PHY.

nice NA...

uh-huh... thats what i thought...

thats strange... considering that it appears that you have 2.4?

No, I completely understand. Especially at your stage of development, upgrading the project is a daunting task since moving up from 2.31 will require you to have to reserialize all of your physics bodies. Its little things like this in the versions that can drive people crazy, and having to upgrade is not truly an option. That is why I have been trying to find as many bugs as possible lately and post anything that remotely looks like a bug. Once 3.0 goes into full scale production, getting previous issues resolved may be an impossibility.

Have you sent your information to Josh so he can get you into the forum as a developer?

1) data for road creation 2) built into engine from what it looks like. Also, since you have 2.4, you should probably request access to the forum by following the directions in this post: If you need Access to the Forum

some models are just going to be high poly no matter what... but in any case, i am not too convinced that this isn't just a bug in newton that Julio isn't aware of and could possibly make better or even resolve...

That is not an ADN error. You are using a version of ADN that doesn't have the parallax option built in... try downloading the one that was released today.

+8 months from when it was originally brought up...

Edit--- sorry... i see you are talking about 2.31...

and as long as none of those 1000 raycasts hit an object with a high poly count... well, it doesn't affect the fps, it just completely pauses the game for a second...

pretty slick, MG...

Post your computer specs to see if it meets the requirements for LE. Also always remember that you need to update your drivers.

terrain painting issue is resolved now with latest editor (and shader.pak?) update... but my script issue still remains. Has something changed with scripts/property dialog recently?

also, something else thats been added to the 2.4 editor is now when the Show Physics option is turned on the physics body for the terrain is showing. Only problem is that it drops the fps to single digits making the editor basically useless. Before 2.4, turning on the Show Physics just applied to everything except the terrain, which actually made it a useable option.