thehankinator

I have a script that places traps. I don't want to the player to be able to lay the traps on top of each other so I call ForEachEntityInAABBDo in the space the trap would take, if there isn't anything there I place the trap. The problem I am running into is if I place a trap to the left then another to the right I cannot place one in the center because both the left and right trap are returned by ForEachEntityInAABBDo. If I do a IntersectsAABB check in the ForEachEntityInAABBDo callback I can confirm that the AABBs do NOT intersect. I've verified that the parent for the entities is nil. I've tried calling UpdateAABB (with all the options). Is it possible that there is something special about loading a prefab from a script when it comes to hierarchy and ForEachEntityInAABBDo? Check code: world:ForEachEntityInAABBDo(self.entity:GetAABB(Entity.GlobalAABB), "ArrowWeapCheckPosition", self.entity) Callback: function ArrowWeapCheckPosition(entity, extra) if entity:GetCollisionType() == Collision.Trigger then if entity:GetAABB(Entity.GlobalAABB):IntersectsAABB(extra:GetAABB(Entity.GlobalAABB)) then System:Print("Yep") else System:Print("Nope") end extra.script.valid_position = false return end end Spawn code: local trap = Prefab:Load("Prefabs/Traps/arrow_trap.pfb") trap:SetParent(nil, true) trap:SetPosition(pickinfo.position, true) trap:AlignToVector(pickinfo.normal) trap:UpdateAABB(Entity.LocalAABB + Entity.GlobalAABB + Entity.RecursiveAABB) trap:Show()

I think the point is that if you are new to programming, you should have a firm understanding of the lua interface and 3d graphics before jumping into the Leadwerks C++ code. You can do the vast majority of things a game requires in lua. In my opinion if a beginner needs to do something that is not possible in lua, they are biting off more than they can chew. After spending a few weeks/months working with lua, a programmer will have a much better understanding of Leadwerks to base the changes that would require modifying C++ source. Picking up the basics of the C++ language is probably the easiest part in all that.

I understand. I am not looking to check for the intersection with an individual brush, I want to check if an AABB intersects anything. When calling ForEachEntityInAABBDo, the merged CSG has an AABB that covers the entirety of merged brushes so the AABB I am testing will always intersect the CSG. I am looking for a way to check if an AABB intersects the CSG, not the CSG's AABB.

I am trying to check if an AABB would intersect with the walls of my level. When I call ForEachEntityInAABBDo the CSG always collides with my AABB because the CSG has no script and it's all collapsed into one giant entity with no children (I think). I could add a blank script to every wall in my level, but wouldn't that be(in addition to tedious work) a significant performance hit?. Anyone have a better way of doing this check?

In my code all my calls to SetAnimationSequence the endHook argument does not contain "self." For example your code is self.animationmanager:SetAnimationSequence("attack",0.02,200,1,self,self.stopAttack,30) and mine would be self.animationmanager:SetAnimationSequence("attack",0.02,200,1,self,stopAttack,30) Have you tried this?

Are you seeding the random number generator? Try doing the following line of code before your math.random call. math.randomseed(Time:Millisecs()) self.v = math.random(1,4) I remember seeing a thread talking about how Time:Millisecs() wasn't the best way to get a random number but I can't remember where it was now, should work better than no seed though. os.time would create a problem for Game Launcher so I would avoid it.

I've been playing with it a bit more, if I remove SetInput()/Point() and call Stop() and Follow() continously it doesn't look like they are getting stuck (or stuck as often anyway). There really should be some way to figure out if the course Follow() plotted previously has failed so that it can be replotted. Or is it best practice to continuously plot the course with Follow()? Without some way of profiling Follow() it would seem like NPCs continuously calling Stop()/Follow() is a bad idea for performance.

FYI you don't need to check for "entity.script ~= nil", you have the scriptOnly flag set to true in your GetEntityNeighbors call.

For some reason things are still getting stuck. I see you are using a pivot, does it have Character Controller physics? The documentation says Seems like Point is similar to SetRotation (documentation does not provide a full list of functions that will not work with character physics). Perhaps character physics is not good for navigation? Using the Crawler and MonsterAI.lua as a working example says otherwise. Yes, the nav mesh appears correct. Shows the mesh going around but not through the blocks.

Hey Guys, I have been working on implementing my own AI scripts that better fit my use case. I've got things working just about the way I like it but I have some problems with entities getting stuck and it's really highlighted that I don't fully understand the details of Follow, and SetInput. Follow My stuggle with this function is that after I've set my entity to follow the player, sometimes it just stops after moving for no less than 4 or 5 seconds. Not sure if it is all in my head but it almost seems like if one entity is stuck, more than of them get stuck at the same time. There really isn't many obstructions on my map, it's a flat surface with about 6-8 blocks to act as walls and Nav Mesh updated. I think my question here is once a Follow command has been issued and the return value is true(meaning success), what sort of things can break the course(besides Stop)? Is there some way to check if the course is still valid? How expensive in computer terms is this function? If I call Follow multiple times, do I need to call Stop first? SetInput I am not sure of what situations SetInput is designed to be used when utilizing Follow. It seems like my NPCs less often face the player if I remove SetInput but I am not convinced I am calling this function at the right times as it seems like they run toward walls momentarily if I use this function. I know a lot of the example I gave here are wishy washy but so is the behavior I see, 90% of the time everything works as expected. Then every now and then there is some idiot running at a wall. Any insight into the inner workings of these functions would be awesome!

To start with you need to put your random number generation in Start() or something. It also needs to be a variable that will stick around by the time the Use() function gets called so do something like this: function Script:Start() self.v = math.random(1,2) end Put all the checks for v within one Use() function. Something like function Script:Use() if self.enabled then if self.v == 1 then self.component:CallOutputs("Use1") elseif self.v == 2 then self.component:CallOutputs("Use2") end end end

This could turn into a really cool game. Here is a screenshot of the flame problem on my Radeon 6870. https://drive.google.com/uc?export=view&id=0B8AlYY49_v2bd0JoMllOODNud00

Ugggghhh I wish I knew this months ago. I've resorted to wrapping KeyHit() to handle the extra key hit behavior.

I don't know if this applies to this case but in Blender you can paint on objects. Maybe you somehow set that up? My Blender skills don't go beyond making a cylinder and painting it(and I forget how to do it every time). Maybe someone more experienced could speak more to this.

How about Mad Scientist? It could be a modern/military setting, inline with what you talked about on the last hangout.

I know this is planned for paid DLC but, this concept would work really great for the seasonal coopetitions. Just like lego sets, maybe you could have a small set that is free for the coopetition then a larger one that's for sale. Like if the theme is pirates, there could be a set with a few items(that have the basics for a story/theme) for free but also a large set with additional items that are in line with the free set but for a price. I think that could make the coopetitions much more interesting.

Seems a bit late in the game to make such a large fundamental change to Leadwerks. The IDE/Lua isn't the greatest thing in the world but it is far from unusable. Maybe this could be a separate product? Still, given the limited resources of Leadwerks Software I think that the time would be better invested in improving the existing IDE or adding new features to the engine.

It'd be nice if we could do a ctrl+tab to switch between script open script tabs, like notepad++/visual studio. Scintilla supports it and can be enabled by enabling "buffers.zorder.switching" http://www.scintilla.org/SciTEDoc.html Pleeeease!

I really like this feature in Notepad++ and VS2013. According to scintilla's website it should be supported. Feature is called "highlight.current.word". http://www.scintilla.org/SciTEDoc.html

Thanks for your help, using your example I can make a workaround until it's fixed. Buffer class looks much more simple, will it be going away? Will it ever become supported/documented?

Anyone have an idea what I am doing wrong? Better yet, anyone have a working example using render targets?

I had a chance to come up with a minimal script that removes the need for you to download the whole project. This has only one render target but has the same symptoms. You can press T to toggle between the render to texture and a straight render to the screen. Main.lua --Initialize Steamworks (optional) Steamworks:Initialize() --Set the application title title="MyGame" --Create a window local windowstyle = window.Titlebar if System:GetProperty("fullscreen")=="1" then windowstyle=windowstyle+window.FullScreen end window=Window:Create(title,0,0,System:GetProperty("screenwidth","1024"),System:GetProperty("screenheight","768"),windowstyle) window:HideMouse() --Create the graphics context context=Context:Create(window,0) if context==nil then return end --Create a world world=World:Create() local render_target = Texture:Create(512, 512) local dir_light = DirectionalLight:Create() dir_light:SetPosition(0,4,0) local model = Model:Box() model:SetColor(0.0,1.0,0.0) model:SetPosition(0,0,0) local camera = Camera:Create() camera:SetPosition(-1,0,-1) camera:SetRotation(0,45,0) camera:SetRenderTarget(render_target) local rot = 0; local use_render_target = true while window:KeyDown(Key.Escape)==false do --If window has been closed, end the program if window:Closed() then break end --Update the app timing Time:Update() context:SetColor(0,0,0) context:Clear() model:SetRotation(rot, 0, 0) rot = rot + Time:GetSpeed() if window:KeyHit(Key.T) then use_render_target = not use_render_target if use_render_target then camera:SetRenderTarget(render_target) else camera:SetRenderTarget(nil) end end --Update the world world:Update() --Render the world world:Render() if use_render_target then context:SetColor(1,1,1) context:DrawImage(render_target, 0, 0, 1024, 768) end context:SetBlendMode(Blend.Alpha) context:DrawText("Press T to enable/disable render target", 300, 2) --Refresh the screen context:Sync(true) end Edit: Why does the CODE tag always murder code formatting?

This is great! Have you thought about some sort of profiling feature where you could see what function of a script is expensive? Being to see just what the performance hit of say FPSPlayer.lua:UpdatePhysics() really is would be really helpful.

See following post for script.

I am trying to make a split screen effect. For some reason, it appears that the it only renders once to the texture, never updates. Is this a known limitation? If I disable the render targets the FPSPlayer behaves normally so I think everything is in order there. I've created 2 textures, black.tex and green.tex. Then, I assigned a texture to each camera. Inside Main.lua I've done the following: Before the while loop: local player1view = Texture:Load("Materials/RenderTargets/black.tex") local player2view = Texture:Load("Materials/RenderTargets/green.tex") After world:Render() context:SetColor(1,1,1) context:DrawImage(player1view, 0, 0, context:GetWidth(), context:GetHeight()/2) context:DrawImage(player2view, 0, context:GetHeight()/2, context:GetWidth(), context:GetHeight()/2) Edit: I'll also add I've tried setting one of the cameras to Hidden, no effect change in result. Edit2: I've also tried creating a new texture pragmatically and rendering that, same result.