macklebee

i can get the collisions to work fine several ways at least with bmax... 1) just use the lua scripts to set the collisiontype and load the collisions.lua file to set the collision response 2) set the scene from LoadScene() to have a collisiontype and then set collision response for the scene and controller (without using the collisions.lua file) 3) parse the scene and set all objects with the name "GeneratedModel" to have a collisiontype of 2 and use the collisions.lua file to set the response... 4) i am sure there are other ways... All three of these methods work fine for me... granted the Lua script might possibly be more useful since you can test inside the editor as well as your game... and also, you don't have to set the same collision response twice... its already built in the engine to take care of that... so instead of this: Collisions(2,3,1); Collisions(3,2,1); you only need to do this: Collisions(2,3,1);

so only in your game is the phy body incorrectly sized? that makes no sense... and the bounding box has nothing to do with collision... its just the max extents of your model... I would have to see an example of what you are talking about... if you got an example wall or something you can post... as for the collisiontype being set and not having to set Collisions... look at your game's log... you will see that it runs some lua scripts in the beginning, one of them being collisions.lua, where common collision responses are set.

nice work around! and you're right, it seems so obvious after you state it.

look at the parameters for the AddVehicleTire()... you are possibly just using the defaults for the spring constant and damping... or perhaps a zero is being written to them... i would try to set it up like the the example vehicle in the editor, the viperscout, where the spring constant and damping is set at 20 and 150, respectively... then make changes from there to get something you like... also... it looks like the suspension length is being set to a -0.4? I would have thought this needed to be a positive number... i dunno... B) and one thing i see different is that the viperscout is using TFormPoint for the position of the tires...

what do you have for the tower's object script? try this and see if it makes a difference... require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) object.model:SetKey("collisiontype","2") end

are you using lua scripts with your program? just curious... because if you are then there's no reason to set the collisions or set the scene's collisiontype in the program because it should automatically load the collisions.lua file... dunno... just out of curiosity, can you load the scene in the editor and run the fpscontroller game script and have collision with the walls?

try it without the Collisions(1,0,1) and the Collisions(0,1,1)... There is no collisiontype zero. (Well there is... but it means whatever is set to that doesn't have a collision type) and you can load PHY files... LoadBody() but as long as the PHY file has the exact same name as the model it will automatically load... if none of that works, you could always just set the collisiontype via the lua object script then you wouldn't have to set the scene's collisiontype... also in LE, I believe controllers are usually collisiontype 3 (COLLISION_CHARACTER)...

not sure exactly if this is the problem, but you have some mat files that do not have a texture associated at all in them... you also have several mat files that are using the diffuse_bumpmap frag shader but just using the diffuse vert shader with them... and you have some mat files that using mesh.vert and mesh.frag... with no diffuse texture being assigned... And this might not be a problem at all, but I have had trouble in the past with other applications using special characters in file names... you have several mat files using the number sign, #, and parenthesis, (), in the names... with this many surface materials, its hard to say what is screwing them up... you might have better luck just exporting a small section of the model that only has a couple of materials/textures associated with them and attempting the material files that way... I would strongly suggest you try using Icare's ADN material editor so you can see the proper way to create material files for your model.

i would at least post the issue in the bug tracker... if you don't, then it will never be resolved and could be possibly an issue for you when 3.0 comes out... i would make note in the bug report everything you have tried and list your drivers as well as a small screenshot...

yeah i knew what you were referring to... I am just not having that problem... have you tried older Editors and see if it occurs with them as well?

well the phygen code is available in older sdk's... like i said you could always write your own app... one that loads the model, determines the bounding box data and convert it to appropriate values, then save the phy file from there... something like that might be useful to the community.

yeah it could probably be done but seems a bit overkill when you can quickly and easily test different PHY bodies from phygen with Show Physics in the editor... granted it would help that the Editor didnt have to be stopped and restarted between different PHY files... worse case you could always just write a small program that lets you load a model and it gives you the bounding box information to use in phygen...

i remember someone else recently complaining about black lines when Show Physics was on... I couldn't reproduce it then either... we have the same graphics card and i am not having this issue... have you updated drivers recently? perhaps a bad download? have you tried a fresh install? how about a screenshot of your problem...

well you can always eyeball it in the editor with the grid on... or just play around with it... a value of 1 in the position or scale setting is equal to 1 meter in the LE editor... or if you can tell your dimensions in your modeling app, then use those... like i said its something that you have to play around with... it would be nice though if the Editor had grids available for the XY and YZ planes so you could easily see the dimensions based on the grids

yeah... thats because you are not trying to load an OBJ file to create your PHY file but make a PHY file based on primitive shapes... set the collision type to box then set all of your settings for position, rotation, scale... then hit the OK button and a dialog window will open up and let you save the phy file to whatever name you want...

where do you get that from when he was asking about phygen in his original post?

yeah they are... collision type set to box... and i am able to change all of the other settings... here's one i just made that has the Yposition offset +10 and the Yscale set at 20... you will need to have Show Physics on in the editor to see it..

you just have to play around with the setting until you get something you like... so create a box phy file using phygen and set the Scale up with setting like 1,20,1... or whatever until it approximates the size of your model

only one problem: how are you going to convert the models to GMF?

try this... require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) --'Create a pivot'-- object.pivot = CreatePivot() --'set its location'-- object.pivot:SetPosition(Vec3(5,1,5),1) --'set the parent'-- object.model:SetParent(object.pivot) function object:Update() --'rotate the parent'-- TurnEntity(self.pivot,Vec3(0,1,0)) end function object:Free() self.model:SetParent(nil) self.pivot:Free() self.super:Free() end end

well it would be interesting to see if there is... and who knows, maybe there would be a demand for it? hopefully it would be more than a 1 linux sale to 100 windows sales... going by rough estimates on the number of developer's here on the forum, that means Josh would have sold only 4 or 5 linux versions if he had it already...

i will take your word for it mumbles... but it still comes down to whether or not there would be much of a demand... 1 linux sale for every 100 windows sales is not much of a return on an investment - the investment being the time that Josh has to spend on creating a linux version... and that was the question Josh (and MG) were both asking... not to be answered by some made up rhetoric simply because someone wanted something.

Mumbles, now that makes sense... thanks for the enlightening point of view and not just prodigy garbage spewing... it would seem that it would be an easier path forward based on what you mentioned.

well idealogy doesn't put food on Josh's table... and considering you yourself have already shown that LE will run in wine on linux, what's the point of Josh spending time on a linux version.

kind of hard to prove something is wrong when its obviously has no basis in facts... its like saying God is a 12 headed teddy bear with lasers for eyes... you're right I cannot prove otherwise, but you cannot prove the statement is correct.