macklebee

I wasn't referring to uu3d but LE... the material system between the two are not the same. like i implied above and as you just shown, you would have to use a texture to get the specular.

huh? can you have specular effect in LE without a texture considering the specular is set from a normal map's alpha channel? and vertex color can be set from converting the material to the vertex itself... i think the option is under 3D Tools... don't have access to LE/UU3D for a week so dont remember offhand exactly where it is...

more likely the artifacts caused by compression will be pretty obvious when the texture is blownup across a sky

LE already supports this and it has always worked just fine for me. i convert a texture/material to vertex colors in uu3d, delete the texture/material reference, then export to gmf with export vertex colors option selected. the sword i used in this example is setup with no texture/material and only uses vertex coloring: http://www.leadwerks.com/werkspace/topic/3460-equipment-attaching/page__view__findpost__p__31610

Like Josh said, you have vertical synch enabled in the editor. So it doesn't matter if you had a computer from 10 years into the future, the fps would still be ~60fps. Go to Tools>Options to open the Options dialog. Open the Configuration tab and you can disable vertical sync.

Go here: http://www.leadwerks.com/werkspace/topic/127-if-you-need-access-to-the-forum/ to enter registration key and to get access to the complete site. Then go here: http://www.leadwerks.com/werkspace/files/file/186-leadwerks-engine-updater/ and download the updater. Run the updater to install the SDK.

Are you using the Evaluation version or are you an SDK owner? If you are an SDK owner, then you need to follow the instructions in this post: http://www.leadwerks.com/werkspace/topic/127-if-you-need-access-to-the-forum/

very nice, NA!

please explain this in detail. are you saying that your model now has individual origins for the individual submeshes or that you were just able to get the exact location of each submesh from blender then used those values to properly set the position of the tires by code?

Despite what others here will tell you, LE can only load a proprietary model format called GMF, but there are several format converters available inherently in the SDK (ie. obj2gmf, fbx2gmf, etc). Also UU3D has a plugin to export to GMF, and a forum member has graciously created an exporter for 3dsmax. Essentially there is a way to basically convert almost any model format to GMF, but the ease of use is dependent on what steps the user is willing to go through.

and no, LE does not have an animation editor. thats the second time ive seen that question and i think its because of this post: http://www.leadwerks.com/werkspace/topic/3507-multitrack/page__view__findpost__p__31863 that is a screenshot of ultimate unwrap 3d which many use here. will update the post to reflect that.

ah sorry... when you said the decal's entity in the first post i thought you meant the pick entity that it was being attached to... not the decal itself. I would suggest that you post your code because i can free a decal just fine... i assume it has something to do with however you are creating an array of them...

are you setting the parent of the decal? if so then it should remove the decal automatically when you free the parent entity.

it is a known bug with the latest ATI drivers. you can try just a version or two before the latest and it seems to work for others...

uu3d does not save the position information. look at your model in the modelviewer and you will see that the positions read 0,0,0... if you have the old windmill model and you view it with the modelviewer, you will see that its submesh has values for position referenced from the main model's origin. no unfortunately im not a 3dsmax owner... and even more unfortunate, it appears they are the only ones that have the ability to save mesh hierarchy correctly in LE.

Assuming that the truck model has the same issue that the jeep model does, then you have ran into the same issue as I have. The mesh jeep model has all of the meshes in the hierarchy but the positions of the separate meshes are lost. All of their origins are the main model's origin, which then screws up the size of the tire radius and the placement of the physics tire. So you would have to offset it to the correct position for each tire as needed from the model's origin and set the tire radius separate from the bounding box. And the conversation with LE/UU3D has taken place concerning saving the mesh hierarchy (including the positions/origins of each separate mesh) but so far has fell on deaf ears. You can hack around it and save the mesh hierarchy from UU3D but it still suffers from the same issue of only one origin.

its an inherent command in LE just not documented anywhere and I assume not exposed to anything other than bmax and lua.

require("scripts/linkedlist") for entity in iterate(fw.main.world.entities) do if entity:GetKey("name")=="light_directional_1" then --Do Something end end

yes, very nice.

Actually by multiplying you are reducing the number of increments between the new value parameter and the old value parameter depending on if vsynch is turned on or not. With vsych on, i get roughly about 1 for AppSpeed. With it off, I get ~0.2. So with vsynch off, you get a choppy rotation which is why i used division so it would always be at least 3 increments. This might just be a poor place to use it but it was pulled from one of the SDK's inherent scripts. Granted that could be resolved by simply just using a value that has nothing to do with AppSpeed. But as megatron said and according to the wiki, movement should be multiplied by appspeed but in this case it might make sense to have more increments at a higher frame rate.

No. Like I said above, the PHY body created by the Editor is ONLY for STATIC models.

Just creating a new PHY body with phygen should resolve your issue. I just mentioned the INI file because it seemed like you were implying that the gravity property was not being checked in the dialog and it made no sense that it would not be.

You do not need to include any other files if you just want the gravity property key checked. The required file i mentioned above is for actually setting the collision type property correctly. If you are referring to it actually responding to physics and falling down, then you need a PHY body created from phygen. I cannot replicate the issue. It works every time correctly even with just the first two lines. You dont happen to have an INI file for that model with the gravity set to 0 by chance? You could also try to set the variable yourself: object.model:SetKey("gravity",1) Other than that, the only thing i would suggest assuming you haven't modified the class.script is to download a clean copy of the SDK. **EDIT - you have edited your post since i commented. Dynamic objects must have their PHY bodies created with phygen. The PHy body created by the editor is for static models ONLY.

there's nothing wrong with the script that I can see concerning SetBodyGravityMode() and the gravity option is checked for me, which it should be since a body's gravity is enabled by default. So even just a script that contains just the first two lines should make the gravity option be checked in the properties. i would try restarting the editor and placing another instance of the model into the scene. The only problems i see in that script is the fact you are using the COLLISION_PROP variable when its not being defined and a key that doesn't exist in the class script. you need to add this line if you are going to use that variable: require("scripts/constants/collision_const") or just set the variable to a 1. and then change the key to match what is being used in the class script: model:SetKey("collisiontype",1)