Rick

Yeah, I don't understand what any of this means

In my sig there is a wiki page and there is some vision cone code in there. This returns all entities inside this cone and then you can loop over those and do raycasts to see if you can "see" them (as the vision cone itself see's through everything). So this would give a nice effect for AI. I kind of wish something like this was just part of the engine itself really. I think it would add a lot.

I guess I left off directional light as I don't think thief type games generally use that kind of light. @shadmar, Yeah, I would think a shader would be ideal but we all rely on you for that .

I personally don't want anything with this . I just did a test some months ago and now there is this new person who made a post about trying to do this same thing and it made me think about my test. For my test I just did a simple (in the dark or in the light). I can see if you wanted to do shades of gray in there how you'd have to think of another approach, but for something simple it would be cool to make this csg matching easier to lights, specifically spot.

This is what I'm saying. I found it painful (for pointlights anyway as there was different sizes and you'd have to scale it manually for all various sizes) to get it just right in LE myself. Maybe I'm just an idiot but would be nice to have a collision function called for spot and point lights.

I wouldn't think you'd need to iterate over all the lights. You should be able to do the raycast from inside the csg light collision function the player is colliding with. The csg matching should handle the falloff then too with good enough precision so nothing to do there as the shape itself is the falloff distance I would think. I haven't played much of thief so don't recall the different light intensities it had. But yes, a raycast then is needed once the player collides with the light csg shape. Either this OR just give lights a Collision function! Easier for us

Someone posted about a Thief like game and I recall I tried messing around with being detected in light before and found it sort of a pain to try and match up csg cone with a spotlight so was thinking for those types of games it might be handy to have a way to easily have something in the editor where if you have csg as a child to a light and check a button it could exactly become the shape of the light cone or sphere in the case of point light. Just remember I forgot to make a request like this. I had a hard time manually shaping the csg to the point light and it wasn't matched up perfectly.

For sound you can just do a bounding box check where the size of the box is based on the noise value. For visible in light you can do csg collision checks. For a game like Thief most of the game you are hidden and only when in the light could it cause an issue. So you can make csg shapes that mimic the light shape, paint it with the invis material and check for the player entering it's collision function. Different footsteps per surface is possible but you have to code that. Again if you are using csg for the ground (I'd recommend for a game like Thief) then you again can check for collision with the csg and assign each csg which sound to play for the player. Not sure on swimmable water as it's new but I think some people have done that. Climeable ropes for sure. Distinguishing light sources not sure what you mean and why but sounds doable.

How does allowing file i/o via Lua violate this though? I get it does with C++ projects, but Josh can enable file i/o via Lua and it shouldn't cause any issue. Maybe don't allow deletion or creation, but allow reading/writing which would allow us to save. I guess security is the issue and even if you allow reading/writing someone could make an app that just fills up the harddrive? I don't know. These games will be fairly limited. I guess they would really just be demos.

If Sandbox mode is only allowed then yes.

Having file access would be ideal.

No it doesn't. You are going to make me find that post aren't you *sigh*

I think this has more to do with the gfx card than LE.

I guess make a small demo and post in bugs forum for Josh to check out.

I believe picks are done on the mesh not the physics object. Then this is where someone says it doesn't, then I find the post where Josh says it and everyone is shocked This should be posted on the front page in bold

I can only assume you had something there, then generated the nav mesh, then removed it and didn't regenerate the nav mesh again. Or you have something there with the invisible material on it.

Are you getting any entity with the pick? Do you move your pick up Y value a little (since positions will be at the feet vs say midway up or even at eye level)? Have you tried a different radius in the pick?

Of course not. You are making a line between 2 points and anything it hits (given collision type I guess) will be registered. Make sure you aren't hitting the character itself if you are using it's position since it's position will be "inside" itself and would hit itself. Put some debugging in. Are you hitting anything? If so print it's name out and find out what.

I didn't examine your code much but to me it looked like when the player was looking at the enemy the enemy would move, but if I would look away then the enemy would stay still. But if I'd turn the player just slightly then the enemy would come at me again. This for sure has something to do with your code and not an LE issue. You just have to work it out man. Welcome to programming where it's not about creating things it's about fixing issues. That's really what programming is and in the process of fixing issues you end up making something I think this is why some people don't like it. If you don't enjoy constant problem solving and fixing things then you won't last long enough to get to a point where you can just make something work without too much trouble. That takes experience though and you have to last that long and not give up out of frustration of constantly fixing of things

Hmm, just tried and he started moving towards me. I also think I know why you are getting crazy AI movement. You need to play around more with some of the values to the nav functions. Use a higher acceleration value than 1 (3rd param to GoToPoint()). Very low ones make a rubberbanding effect like you are seeing in your other post. Try 10, or 100 even to remove that effect.

I think YouGroove forgot the return statement after setting the color to red for each if statement. At that point you'd have exclusion statements so that best case scenario after the first if fails (which means it couldn't possibly be hitting the ship) you bail out so as to not do any other of the if statements.

YouGroove, that looks like the old thing that was happening. I recall Josh fixing this so it looks more like Olby's pictures. You are sure you have updated your project to the most current version? If you have then post the project for Josh in a bug report.

I wouldn't count on it. If you already know C# then you have a leg up on C++ already as they are similar. Lua is a great language too. Very flexible.

self.target might be nil. That's generally why things crash.

I find it to turn into wall of files and be a mess