Rick

Are we talking water planes that we can place multiple in our map for ponds as well as oceans or just 1 big ocean plane like in LE 2?

So here is a question. Our interior (1 solid interior model NOT made up of smaller models) of the house is a separate model from the exterior (again this is changed now to be 1 solid model), and a separate roof model. If I'm looking directly down on the house so the camera can't "see" the interior (roof and exterior are in the way) I assume in LE the interior is still drawn because it's bounding box is visible to the camera? In other words, if a bounding box is inside another bounding box, that interior bounding box will be drawn?

Well that's certainly a new way to do that . I didn't know lua didn't require ()'s when calling functions and then returning a table and calling a function on that without needing ()'s is a pretty neat trick to make it look like a normal OO language. Would be cool if you didn't have to pass the class name as a string but could as a variable that would be nil (obviously) but could some how get the sending variable name and use that. While the underlying way of doing this is fairly messy and not as neat as the method Josh uses in some of this scripts, the usage is much closer to other OO languages so I love that. Also, when you instantiate the class you shouldn't have to refer to it as a string right? Because you create a table from the string when you define the class so you can have a much more OO way by just using the table directly at that point like: myInstance = new MyClass With that I guess an alternative approach to using string class names when defining your class could be something like class Person = {} class NPC = {} : extends Person

The only thing, that probably doesn't affect you since you are using a Lua project, would be to get the context via Context:GetCurrent() instead of App.context as C++ projects don't have the App object so the script won't work in a C++ project. By having Context:GetCurrent() to get the context it'll work on both projects. That's obviously detailed but it's something that we all found out early on with scripts in the Workshop after the C++ projects were released in LE (Lua only was the first project type released in LE so everyone just used the App object without understanding the issues with it in C++ projects that would come later on).

Yes, but draw a rectangle with the context commands instead of an image so you don't require an external resource.

I believe the main issue is via the editor itself. We already do our own optimizations during run-time. It seems that view range does help the editor (and should our game a little but it's a top down view so you don't see much anyway) but you are then limited in your overall view of your map and can't get a really good overview of it.

Nice code, mind if I add it to the wiki?

1 line, no loops, simplifies the code. I like that!

So this works for ALL entities because this isn't for the camera but just any entity.

No offense was taken. I was simply showing you my laziness and content with how it already was But this is why I made the wiki. I am by no means the gatekeeper of the wiki and I encourage people to get in there and share some code. I welcome you to make a page and add a link to it in the page I made as an alternative approach.

This function is a simple modification of the original Josh has already with the engine. The radius is actually the bounding box check done around the entity to get entities that lie within it to check and see if they are inside the vision cone. For this particular function you can think of it as the distance to check for the cone. I made the parameters to match the existing function and I just extended it by the 1 parameter which is why I put it at the end, and those 2 params aren't related so they don't need to stay together. When you make the call to GetEntityNeighborsViewCone() everything is done right then and there. Using it for players or mobs won't make a difference as the function is ran in 1 cycle. If you wish to make a version that is does what it does over multiple cycles (threaded) then you are free to do so in the wiki. For me, this does what I need it to do and I'm not really building a library on the wiki so I'm not all that concerned with it atm. You should be able to call this on the player and any number of mobs and it should still work. Are you thinking the callback is done over multiple cycles? The callback is fired as many times as there are entities right when we call ForEachENtityInAABBDo(). That is ForEachEntityInAABBDo() won't come back until the callback has been fired for every entity in the bounding box.

Oh so you aren't trying to just resize the csg object but adjust the grid. I see now. Yeah [ ] keys do it I think as well as the menu probably.

Are both of those csg objects? If so look at your other views with the white squares and click and drag those to resize. If anything is a model then select that model in the scene tab and there is a general tab where you can change it's scale.

wiki has been edited for the changes you noted above. thanks

Intended as far as I know. I usually run into this more with mouse hit so I generally create a bool value to indicate if it's down or not and use MouseDown() with. Probably easier with mouse vs keys though since I generally only look at left/right buttons. if MouseDown(1) == true && leftDown == false then -- left mouse click and will only come in here once per click leftDown = true else if MouseDown(1) == false and leftDown = true then -- left mouse released so reset leftDown = false end

Added http://leadwerks.wikidot.com/wiki:vision-cone Thank you so very much Ma. If you have any sort of optimizations that you add you can change on the wiki or let me know here.

lol the joys of refactoring. That did it! I'll add it to the wiki. Of course the model I'm using was exported 180 on the y axis so visually this model has to look like it's facing me, but that's an export issue. Will make an entry in the wiki.

So trying to refine this and take advantage of the existing GetEntityNeighbors.lua file. I must have screwed something up as the "Inside cone" isn't displaying. Still looking at it but thought I'd post it here for anyone else to take a look. function GetForwardVector(entity) local forward_vec4 = Vec4(0,0,1,0) local mat = entity:GetMatrix():Transpose() --transform local ret = Vec4(0) for i = 0,3,1 do ret[i] = 0 for j = 0,3,1 do ret[i] = ret[i] + mat[i][j] * forward_vec4[j] end end forward_vec4 = ret return forward_vec4 end function GetEntityNeighborsViewCone(entity, raduis, scriptOnly, angle) local entities = GetEntityNeighbors(entity, raduis, scriptOnly) local e = {} local k, v local forward_vec4 = GetForwardVector(entity) for k, v in pairs(entities) do --The following should actually be done for all entities, not just self.ent local diff_vec = v:GetPosition() - entity:GetPosition() local forward_vec = forward_vec4:xyz() --calculate angle local dot = diff_vec:Dot(forward_vec) local l1 = math.sqrt(diff_vec:Dot(diff_vec)) local l2 = math.sqrt(forward_vec:Dot(forward_vec)) local angle = Math:ACos(dot / (l1*l2)) local name = v:GetKeyValue("name") System:Print("GetEntityNeighbors = "..name) if(angle < angle) then -- in cone System:Print("Inside cone") table.insert(e, v) end end return e end The player is in the AABB and it's name is displayed so I know it's looping over it.

Not a problem as using 1 entity is all that's really needed in my mind. Looping over entities can be done in various different methods so that's not really the issue at hand and this can be applied to whatever looping method we pick. Thanks for this. Will check it out. That seems crazy that this is what it takes to get a forward vector. I assume this is a universal angle (for width as well as height where 35 is the angle value?)

Ma-Shell have you translated that to LE by chance? This is off the forward vector, like all examples I find online, but not sure in LE how to get the forward vector. Some of these other examples are OK, but I'm just looking for a non picking method. My approach was to get entities in an AABB (this determines the length to look at) and then looking through those entities to see if they are in the cone.

Has anyone done a vision cone in LE before? Trying to see if another entity exists in front of an entity inside a cone area? Not interested in attaching a cone csg shape to all entities. If we can get this it would be perfect for the wiki. When looking online people are talking about dot products of forward vectors. Is there a way to get a forward vector in LE? Added the functions and explanation to the wiki. http://leadwerks.wikidot.com/wiki:vision-cone

Josh did experiment with this once (he posted screenshots) but nothing has come of it. I'm not sure why honestly because I agree this would be great.

When following I always do my own distance check to the target it's following and when within a range explicitly stop it (otherwise you tend to get that strange back and forth turning effect). Then in my sig is the wiki and I believe there is a face entity page. I seem to recall Point() doesn't work on character controllers or something.

Those shouldn't be in there but these forums love putting them in for us automatically for some reason.