macklebee

its in the Bug Tracker and is supposedly solved a month ago... but apparently the fix hasnt been released

not looked at the problem completely... but where in this lua script do you have the keycodes set (require("Scripts/constants/keycodes"))? are they set elsewhere? or did you just forget for your example? Edit- I just tried your lua code loaded by a bmax program along with adding to the top of the lua script require("Scripts/constants/keycodes") , and it works just fine. As long as you are sure that the target you are accessing in bmax is the same target you are getting in lua, it responds correctly.

wow.. simply amazing... and thanks for the tip... good info to know...

hehe... are you just using the fpscontroller.lua file? open up the driver.lua file and press play. it will load the viperscout and you will be able to drive it with the arrow keys

well there is an example in the wiki, but i do not know how much is actually exposed to lua yet... this may be still a wip

has the pointentity command changed parameters? I thought it was: PointEntity( TEntity entity1, TEntity entity2, int axis=3, flt rate=1, flt roll=0 )

np, as long as you are using the code from the monstertruck script, you just need to fix the line that uses the lowercase "clamp" function... it should be "Clamp"... and also just make sure you have all of your models being loaded in the script for the tires... then just use a modified version of the driver.lua that loads your vehicle gmf... you might have to change which tires control the steering though in the driver.lua... the monstertruck script has the tires in a different order than the viperscout script...

You cannot "play" object scripts... you can only play gamescripts in the editor (like fpscontroller.lua or driver.lua). Object scripts will return those errors any time you press the play button.

its already been shown here in the general discussion forum board. and maybe this was a mistake, but are you asking this to be a feature of LE?

according to this post he is using the vertex colors for both, which is why I asked the question...

just to get off topic slightly, but why are you adding a texture to your wall when you are dictating the color by the vertex color? Are you doing something in particular in the mat file like adding a bumpmap or adding specular that requires a texture... just curious...

As a simple test, I created a 5x5 grid plane, and attached a simple black-to-white gradient texture to it. Then using uu3d, I converted the texture to vertex colors. Then I changed the gradient texture to another texture and saved it as a gmf. After creating the mat file with the sway shader, I placed the model into an editor scene. The edge of the plane that had the black vertex colors did not move, while the opposite edge with the white vertex color made it move the maximum amount dictated by the sway shader. The gradient vertex colors in between varied in movement with the lighter colors moving more than the darker colors. Also, since I had a texture actually assigned in the gmf/mat file, it didn't show a black-to-white gradient but the texture that I had assigned. Also, I agree that black may be too much in some instances as well as the white would be... but for a grass root, I would assume one wouldn't want that to move at all.

very tron-like!

np... glad to help

I mean for the KEY_E to be recognized you will also need this in either the beginning of the gamescript or the MygameFunctions.lua: require("Scripts/constants/keycodes") or require("Scripts/constants/engine_const") which has the keycodes in it as well along with other info concerning entities, buffers, etc...

If I am following you correctly then this is inside the MygameFunctions.lua: function UpdateMission() if KeyHit(KEY_E)==1 then do all kinds of stuff... end end and then to call the function in your game script you are doing this in the beginning: require("scripts/whereever/MygameFunctions") and have this in your main loop: UpdateMission() If thats what you are doing it should work, as long as the gamescript or MygameFunctions.lua has the keycodes included... its essentially what all of the other separate standard scripts are doing as well.

Change the vertex colors of the models. To get sway working, make sure the vertex color of the parts you want to sway is white and I believe the roots' vertex colors should be black.

take a look at CameraProject()

how did you create the PHY file? edit-- since you edited your comment above to state that you are using 3dws to create the model, then my only suggestion is that you use the collisiontype box option in phygen. This will require you to determine position, rotation, and scale values of your model to create an accurate physics file. other than that I could only suggest that you get something like uu3d which allows you to convert almost any model format to another... so you can create a OBJ file

A CHOICE_EDIT selection for the collisiontype returns the index number selection of the pulldown list. So your collision constants should be numerically from 0 to 19. The numbering should match the order that the collisiontypes are listed inside the Choice_Edit, with 0 = None and NeutralFF = 19. (Well, depends... you only have 15 items listed in the InitDialog() but have 19 listed in your collision constant file...) Also, I see no reason at all why the standard SetKey() that comes with the normal class.lua should have been changed at all. These lines should still work: elseif key=="collisiontype" then self.model:SetCollisionType(value,1) but you will probably need to set the Collisions() relationships up inside C++ to get these new ones to react the way you want them to react. Note that the collision_const.lua file is for just relating the naming of the collisiontypes (like COLLISION_CHARACTER) to a number that a game script's SetCollisionType() would recognize. And for a lua gamescript, you would need to also edit the start/collisions.lua file for these new collision relationships.

How was your box created? Do you mean you made a GMF model or do you mean you used CreateCube()? If you made a GMF model, then that means you need to create a dynamic PHY file for the model. The PHY files created when placed into an Editor scene are automatically created as a static PHY model. So create an OBJ version of your model then use the phygen tool to create the dynamic PHY file. If you used CreateCube(), then you have to create a bodybox for the box and parent the box to the bodybox. and a mass=1 can really be any units you wish, since it will all be relative... but I think the community response at one time was a mass of 1 was equal to 1 kg.

I thought this was already possible? well not loading a specific motion filetype like bvh, but as separate gmf files...According to the Intro to Animation pdf:

yeah good point... sorry i forgot all about that! but in any case, until he gets access of a registered owner he cannot get to that either...

in the Downloads section under the Tools and Utilities