macklebee

the normal will only come back as -1/0/1 if the face is aligned with a global axis

self.window:GetMousePosition().z http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/window/windowgetmouseposition-r455

Strangely enough, if he opens that model into UU3D and then saves as MDL, it will work. UU3D must be able to convert it to the Leadwerks requirements.

Just a fyi, uu3d does have an updated plugin for Leadwerks that saves to mdl.

Not much info on the reasons, but here is a previous post about it: http://www.leadwerks.com/werkspace/topic/8296-lua-sandboxing/page__hl__sandbox

For os or io commands in lua, you need lua sandbox disabled. Go to the Editor's Tools-->Options and uncheck the Sandbox Lua option.

use the 2D draw commands after you have rendered not before or you will just over write them Leadwerks::Time::Update(); world->Update(); world->Render(); context->SetColor(1,0,0); context->DrawLine(0,0,200,200); context->SetColor(0,1,0); context->DrawRect(0,0,100,100); context->Sync(false);

Yeah the option for polymesh physics bodies are great but has its drawbacks. Should probably try to use primitive physics shapes when possible to help avoid issues with small edges.

Aggror wasn't there an issue at one time with the old LE2 controller when used in the tunnels scene? if memory serves it was due to a small edge on a model surface that was angled higher than the allowable controller slope, so the controller would seem to get stuck randomly. That last picture looks to have a bevel on the curb. Maybe if he created his own CSG primitive for the curb physics body it would work?

Yeah it was news to me as well - guess I never looked closely at the Command Reference page that shows the class hierarchy. And with the new changes to Entity:GetCulled(), you have the starting point for a game like Thief where it indicates if the player is in shadows or light.

We are very accepting of new people here but new people have to realize its not about money but more importantly time. Majority of us are just hobbyists and we are working on our own stuff. There are tons of people here willing to help (Aggror's videos should be required viewing for new people), but some effort from the person asking for help is required. That's why I and others have repeatedly said that a person asking for help needs to show us where they are having problems. Posting that you are having trouble getting a character model to play animations in LE is not very specific. There are so many different issues that you could be having - some of which might not even be LE-related. Unfortunately, the community is not made of mind readers. If scripts/models/pics/etc are provided, there is usually at least one person that will take a look at it. Even the best tutorial will not cover everything that could possibly be causing you issues. So if one truly wants help, they typically will need to be very specific about the problem and provide files.

Is it any material or a specific material that causes this for you?

Thats why some people have suggested, myself included, that maybe you are trying to run before you can walk with some things. No one here expects someone to not have questions, but you need to show us that you have tried something and then post what you have so we can at least see where the trouble can be. Let me point out to you that I had taken personal time with you and taken one of your characters and gave you a step by step explanation in a PM with you, which is where this document had come from: Custom Enemy Character with inherent MonsterAI script.pdf And yet I still keep seeing you post comments that suggest people here are not willing to help newbies. That's getting a little old to say the least and honestly makes me not want to help someone.

This is starting to come off as two people that refuse to do any actual studying/work on their own. There are example scripts, tuts, documentation, and posts that go over these things. Actually there is a post just like this from 3 days ago where another person was asking similar questions: http://www.leadwerks.com/werkspace/topic/10472-enemy-ai-and-melee-weapons/#entry76994 There was an attached document in that post as well that showed how yet another person's custom character was changed to be used as a enemy AI.

Add an empty script to that CSG brush and then save it as a prefab. If you load that prefab with App.lua then it will be loaded with its physics body, assuming you set the shape in the Physics tab.

yes, tjheldna has pointed that out in this bug report that it is missing in the LE3 documentation: http://www.leadwerks.com/werkspace/topic/10339-missing-in-documentation/ I'd suggest people add to that list whenever they can.

Yep. Just having one CSG box in the scene with a world size greater than 1024 will prevent the navmesh from being built.

I must be missing some step to make it work. I created a cylinder like the OP shows with texture lock off, switched to 'select faces' and performed a 'Fit' & 'treat as one' for the Justify options. I turned on the texture lock, which prevents lateral movement of the texture. And if I click the 'Rotate' it seems to work properly. But if I simply just picked from the toolbar one of the 'Rotate X/Y/Z' buttons, the texture does not rotate with the CSG face but rather stays in the same direction as previous. The results are the same whether texture lock is on or not.

It can be set in the Root properties in the scene browser: or by using the command World::SetAmbientLight()

to quote Henry Ford: "If I'd asked my customers what they wanted, they'd have said a faster horse."

I would assume it has to do with this error posted in this bug report (assuming you followed the suggestions that Aggror and I have both showed): http://www.leadwerks.com/werkspace/topic/10386-bug-with-included-tutorial-07-ai-and-eventsmap/page__st__20#entry77022 Josh had mentioned he found an issue with emitters being released before its supposed to happen in his previous status. If you comment out the following lines in the fpsweapons.lua script, it should allow you to avoid that crash (at least it does for me): function Script:Release() --self.emitter[1]:Release() --self.emitter[0]:Release() self.emitter=nil end Keep in mind these are bugs and the workarounds I am showing you are not exactly recommended for actual use as I suspect its introducing other problems by not actually releasing these sounds and emitters properly.

I think those are definitely good steps to be applied to any forum or situation where you have an issue and are asking for help. The more specific a person can be by providing information/files/scripts/pictures/etc to demonstrate the issue will increase their chances that the problem can be addressed. Searching the forum for answers and then using the guidelines for posting bug reports basically should be followed when asking for help: http://www.leadwerks.com/werkspace/topic/6125-guidelines-for-bug-reports/ And do not get me wrong, asking broad open questions like 'how would you implement a melee system or inventory system?' are valid questions, but typically those will be ignored or just replied to in generalities.

Not much we can do really other than to report the problem. Something is wrong in the engine itself - Josh will track it down eventually. Josh mentioned he found a problem with emitters freeing themselves, but it appears there are other issues that are associated with freeing sounds in the engine that would also affect the inherent fpsplayer script. http://www.leadwerks.com/werkspace/topic/10471-openal-al-invalid-operation/

For lua, I use these two a lot for reference: http://pgl.yoyo.org/luai/i/_ and http://www.lua.org/manual/5.1/ and of course, this for LE commands: http://www.leadwerks.com/werkspace/page/documentation/_/index/ and specific entity script functions: http://www.leadwerks.com/werkspace/page/documentation/_/script-reference/