macklebee

where is this? and in any case this is something thats changed since 2.4 came out. Like I said, if I use the editor that you can currently download for 2.4, terrain painting and my scripts fail. If I use the editor that came with the original 2.4 download, everything works correctly.

Actually along with this new editor, I get the same crash as gordon does with mouse up on painting the terrain... along with my script not changing a material texture via the property dialog. If I use the editor from 7/31/10, then everything works fine. So I guess the question is: What was the latest change that Josh made to the editor? because whatever it was it farked ****e up...

setting a value from the properties dialog doesn't work anymore with the new editor... if i replace the current editor with the editor from July it works just fine...

Just noticed something as well with the new Editor... scripts that work just fine with the Editor from the end of July but now do not behave correctly with the latest editor... Josh what was changed in the editor???

Try using SetMaterialShader. It has a parameter for setting if the shader is for the shadow shader.

Mousewheel events do not appear to work on window gadgets but seem to be working fine for me on any other gadget... as for mixing KEYDOWN events with MOUSE events, you could always toggle a logic point Import maxgui.Drivers Local My_Window:TGadget = CreateWindow("MaxGUITest", 0, 0, 300, 200, Null, WINDOW_TITLEBAR | WINDOW_CENTER) Local My_Canvas:TGadget = CreateCanvas(0, 0, ClientWidth(My_Window), ClientHeight(My_Window), My_Window) ActivateGadget(My_Canvas) Repeat WaitEvent() Select EventID() Case EVENT_WINDOWCLOSE Select EventSource() Case My_Window End End Select Case EVENT_MOUSEWHEEL Select EventSource() Case My_Canvas DebugLog "MouseWheel detected: " + EventData() + " Mouse Wheel clicks" End Select Case EVENT_MOUSEDOWN Select EventSource() Case My_Canvas If EventData() = 2 Then rmousedown = 1 End Select Case EVENT_MOUSEUP Select EventSource() Case My_Canvas If EventData() = 2 Then rmousedown = 0 End Select Case EVENT_KEYDOWN Select EventSource() Case My_Canvas If rmousedown = 1 Then DebugLog "The Right mouse button is down and a key has been hit: " + EventData() Else DebugLog "a key has been hit: " + EventData() EndIf End Select End Select Forever

detection of the mousewheel is EVENT_MOUSEWHEEL, i believe... and couldn't you just perform a check for the keydown event inside the right mouse button's event?

So just to get back on topic, why wouldn't you use luajit for this? Its already a common language being used by bmaxer's and c++'ers, not to mention the users that are already solely using lua for LE. And you do not have to use the Android SDK? Where's the problem?

wasn't responding to your initial post, shard... but to ryao

hehe... and the masses here already freak out about paying $50 for an upgrade... so how many people here are actually going to buy the developer license for xbox? very few i would say... to the point that it makes no sense for josh to spend time on it unless he charges the same for the xbox version of leadwerks as well...

why not lua? it seems to be the common ground between your user base already and if it can be done without even touching the Android SDK, it makes no sense to only give this ability to only the c++ users...

1) Its FramewOrk now since 2.31, not framewErk... so maybe thats part of your problem? 2) Post this in the programming language forum that you use to get help. These kind of questions shouldn't be posted/answered in the public forums. No reason to give support to pirates and the such.

it works after converting the model to gmf, converting the texture to dds, creating a mat file for the texture, and giving it an object script.

How did you convert your model to GMF? require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) object.framebegin = 70 --first frame of animation-- object.frameend = 130 --last frame of animation-- function object:Draw() self.frame = AppTime()/100 self.frame=math.fmod(self.frame,self.frameend-self.framebegin)+self.framebegin Animate(self.model,self.frame,1.0,0,true) end end

not sure i follow but: 1) Do you mean this as your model's lua script? require("scripts/class") local class=CreateClass(...) That gives you the standard properties for a model, and one of the options in the Appearance tab in the properties dialog is material. 2) Unless you get real creative with using the alpha color to assign the texture coordinates for a particular image on one texture that has multiple images, then you can only have one material per model. So if you assign a material to cube.gmf, then the next cube.gmf will have this texture as well. But if you are talking about a cube that you are creating via CreateCube() then you can paint it whatever you want for each instance.

download the evaluation demo and take a look at it yourself on how lua scripting can be used.

it might help to post your code...

thats only part of the features it supposedly performs. What I am asking can we get the precalculated raycast data without optimizing the mesh? I realize this means that the existing converters might need to be updated to support this, but it really is crazy to expect people to have to perform picks on every high poly model loaded into a scene before gameplay. And maybe this would only help a small amount if it was doable, but anything would be an improvement than the stutter/pause effect that occurs now. This is not a new feature request in this aspect, I was just trying to see if it was possible to use any part of the GMF Processor's supposed abilities on high poly count animated meshes.

hehe... if the first pick is on a high polygon object it will do that... if its a static mesh, then you can use the GMF processor on it, and it appears to help a little... if its a animated mesh, youre screwed... Ive gotten around it by causing the camera to do a pick on the high polygon animated mesh while the game is starting...

yeah i noticed... in any case, a solution would be nice. Any way the newton raycast data could be calculated already in the GMF file? Or is it already doing this and this is the best we can get?

no problem, i was asking because you had stated above that you had licensed the engine and then you were asking about a bug that was fixed in an earlier version. I don't believe the demo is current with alot of the fixes. Also, if you are a licensed SDK owner then you should asked for forum access by following the steps lined out here. you are missing out on alot of good info thats located in the SDK owners' forums.

You are doing it wrong. According to Josh: The default FOV is 90 degrees, meaning you have a width of view that sees 90 degrees. Zoom zooms in, so zoom=2.4 should give a 45 degree FOV. Then the zoom for any FOV can be calculated as follows: zoom=1.0/Tan(fov/2.0) so a FOV of 115 would be CameraZoom(camera, 0.637)

you didnt do the first link... and if you did, you still have to wait until you get forum access from Josh, who currently is on vacation. Notice that your Group just says Member and not SDK Developer...

This has been resolved in the actual SDK already. Do you actually have a licensed version or are you using the Evaluation Demo?

long ago? you must keep time different than the rest of the world...