Rick

There are 2 steam versions. One that is Lua only and another that is C++ AND Lua.

Nope. GoToPoint() is magic Had some code structure issues but it's "working". Right now he points in the complete opposite direction. Getting closer. [edit] Got it. Thanks for the code mac.

Dammnit I don't want to use SetInput This still didn't seem to work when I changed it to: function Script:FaceEntity(pos2) local pos1 = self.entity:GetPosition(true) local v = Vec2() v.y = pos1.x - pos2.x v.x = pos1.z - pos2.z local angle = Math:ATan2(v.y, v.x) self.entity:SetInput(angle, 0) end Note that my game is a point and click so I don't call SetInput() like in a fps or third person game moving with the keyboard. It's all GoToPoint() driven.

I have the following attached to the character but it doesn't work. the pos parameter is the entity to point at function Script:FaceEntity(pos2) local pos1 = self.entity:GetPosition(true) local v = Vec2() v.y = pos1.x - pos2.x v.x = pos1.z - pos2.z local angle = Math:ATan2(v.y, v.x) self.entity:SetRotation(0, angle, 0) end

Has anyone gotten the Point function to work with a character controller? I have the following call that gets hit once (flags prevent it from getting hit after that) and it doesn't rotate at all. -- where this script is attached to a character model that has the character controller set for it self.entity:Point(self.pointAtEntity, 1, 500)

Via the chat this was the first one we tried. We made larger floor and wall segments now but with still poor results. I guess we'll look at entire room segments and combining those. However, this makes getting texture variations via the atlas a little different or I guess less variant. I think we'll try this and see how it goes. You went offline, but a load/unload option would be handy in the editor.

PM sent with link. Shared geometry and material right? When brought in from the editor anyway.

I'll gather the project up here shortly and send it your way. This is a battle between variety and memory. The one made of models has about 500 some instances. I was thinking instances were very small in memory (only pos/scale/rotation/color/some sort of pointer to base entity). 54 bytes per instance x 500 instances = 27,000 bytes per house x 100 houses = 2.7 MB total (clearly I was wrong ). That was my thought process anyway but apparently there is way more bytes per entity instance.

Interestingly enough the editor crashed after 20 of our instanced house model (non csg). Now when I say instanced house I don't mean the entire house is 1 model. We made wall segments and floor segments and we pieced together a house with multiple instanced of each. However, after 20 of these house instances built this way the editor crashes. This presents a real head scratcher though on how to handle this in the editor (in game I can unload/load instances based on camera position which shouldn't be a problem). It sounds like some engines allow you to turn "off" entities in the editor where memory is released and obviously nothing is drawn, but entity info is still there so you can flip it back on and have the editor load it. This would allow us to have "bigger" areas in the LE editor. This could be a handy flag to have for LE. The entity stays in the scene but this flag tells the editor on map load if it should really load this entity or not and during checking/unchecking of the flag load and unload the entity in the editor. This would allow us to have these large maps with lots of models in them. If the setting propagates down we can make pivots as parents for map sections to unload/load all at once a bunch of entities. This puts managing this into our hands.

Can you elaborate? I'm hearing from some people that some other engines allows you to "turn off" areas of the map. However I'm not sure what that means in terms of memory because it all seems to be memory related here. In game I could look at loading these prefabs at runtime (since 1 instance would already exist it should be "instant" and not pause), but how to setup the scene in the map editor is another issue. A work around could be to place a pivot where the house should be and then load that house when the player is close in the game, but it really sucks because you never see your scene in the editor which is really needed. Anyone have possible LE editor workarounds that they can think of?

Tim and I have a game where we have a small town setting (think 500 ppl). We've made a house prefab (both from csg and from model pieces that we put together to make the house) and wanted to see how many houses we could have in the map. I'm able to get between 90-100 copies of the csg house prefab before the editor crashes. The Leadwerks.exe process is always showing around 1.4 gig when it crashes. Our camera is a top down isometric type camera so the fps when looking down and only seeing 1-2 houses at a time is fine, but the memory is the issue. What can be done about this? I assume this is because the editor is 32-bit and not 64-bit? This is a problem in our game as 90-100 houses isn't even a 500 ppl town. Is there anything I can do to help LE handle this or is LE just not meant for this kind of memory usage?

Hmm, it should be mass. You shouldn't even really have to play around with the collision shape settings for csg. They automatically get shapes that match their "shape".

Have you looked into 3rd party libraries that maybe would make a window on top of LE's? It might be hacky but if you could have this video window on top of LE's then they would be completely separate. You could launch this window from LE before map loading and then after map loading you kill the window. Could be a possible workaround. You could even probably hide the task bar part of the window so it doesn't really look like it's 2 separate processes and could probably make the video window always on top.

So csg/primitives get collapsed and aren't treated like normal models UNLESS they have mass OR they have a script attached to them. This is a gotcha and people have asked for a flag in the editor per item that would prevent the collapse when checked. Josh has said he thinks it's a good idea, but hasn't implemented it yet.

Yeah seems to work for me on Win 8. What model are you using? I used the default barrel.mdl that comes with new projects. Have you tried that to see if it works? Just curious as the only other thing I can think of is the model you are using (besides you using Linux but trying to eliminate everything else first). My steps: 1) Create new project (beta branch) 2) Add terrain 3) Add directional light 4) Add camera 5) Create a new script I named Test.lua and copy/pasted your script above 6) Add pivot and attach Test.lua 7) Add barrel to map 8) Drag camera over Target Camera parameter and drag barrel over Click Tester parameter on script

Can you show a rough example. I would think many others would have had this problem already (even on Linux) so my first thought i always user error but until we see what you are doing it's hard to tell.

Do we have AO? I wonder if another light source that is like ambient light (hits everything) but with direction is valuable? I mean when you have indoor and outdoor settings it's hard to get the indoor setting that doesn't have a light source of it's own to look good. I guess this wouldn't work either huh. It's just hard to get darker indoor scenes without a direct light source to look decent. [edit] Looks like if you place a bunch of point lights and play with color/lighting you can simulate darkness while getting model normals to make the model pop. Just requires some 3 point lights per house object which I hope doesn't kill performance later when there are a ton of houses.

If the only light in your scene is ambient lighting everything looks flat compared to other types of lighting. My question is why? And does it need to be that way? Can't ambient light run similar code as the other lighting to give the models some pop? I ask because we have a game where you have a house and when you go into the house the roof goes away so you can see inside but we want both the lighting to be realistic and models inside the house to look good. To make the lighting realistic we block the directional light from entering the house (discard pixel shader) and have the ambient light be darker gray but the inside of the house is so flat and boring then. To me it seems normal map data isn't considered with ambient lighting. Can it be? Otherwise I don't know why we'd ever want ambient lighting because it looks so bad.

I don't think there is a multi-select list. http://www.leadwerks.com/werkspace/page/documentation/_/user-guide/object-scripts-r631

That's part of the puzzle. I have to wonder if you know the answer if you don't know which ones to light What do you think the answer is? [edit] Just tested and it works

It's been awhile since I've played this but you should be able to use left click for fireball and right click for iceball. Shooting a fireball at the torch should light it. If it doesn't then something strange happened. See if you can start over and just frostball to turn out torches. I remember this version of LE had some pretty big physics performance issues so it didn't run the best.

It's a puzzle you just have to think about

Mine is the same way. I noticed this happen last weekend. I had LE up all day and was on and off it all day and then in the evening it just randomly crashed.

And that doesn't fail? It's interesting because it used to because if you think about it, your Script:Collision is an entity stored in C++ that has it's function being called (collision in this case)and inside there you are calling a function that is clearing the world, effectively removing all entities (even the entity your script is attached to which should destroy the script object as well that your stack call is currently in). Josh must have added some better error checking in to handle that because generally deleting an object from inside its own function, which is what you're doing, would cause it to crash. This is the reason Josh has the variable.

I have the same problem actually. So this is how I got it working which makes no sense. I have the Lua editor open. I press play on the Lua editor. The window starts but it's all white for mins. I click the Lua editor behind the window then click back to exe and then it works. I also notice now that if I get an error in the app that would result in a messagebox showing up, I don't get that messagebox right away. The window closes and I have to click the Lua editor to get the messagebox with the error. Something if for sure going on here. So when I run the game in the Output window all I see at first is: Executing "E:\pathhere"... And that's it. Then when I click the lua editor all the other output info starts showing up like Initializing OpenGL graphics driver, OPenGL version 440 loading the map, etc.