nick.ace

I think that is too difficult for us to answer loleczekk, since probably none of us are qualified to provide legal advice on the matter. Unfortunately, you really have to take that work with a grain of salt because of this. Even if you make modifications, the fact that they "may" have been ripped from games would indicate copyright infringement (especially since they were taken illegally). Personally, I would avoid that site, which sucks for users who put in a lot of effort rigging/applying those to models and using them within games. This may even be an international copyright law violation, so idk how you can sue TrueBones, but it might be possible. I don't know how PayPal can refuse a refund even though if the product is illegal to begin with (I guess they don't want to deal with it). I was even looking into that product at one time, so that's crazy! Thanks for pointing that out though gamecreator!

I'm running into a huge issue, I can't wrap my head around it. Whenever I compile the Lua interpreter (Visual Studio Express 2013, Release mode, Windows-32 bit), I get back an exe about 5.5 MB large. The Lua interpreter that comes in each project is only 4.5 MB large. This fact alone wouldn't be a huge issue, but I have a feeling that it is contributing to perfomance issues. Here's the problem: If I create a map with too many entities, my compiled interpreter will exponentially decrease it's framerate until the game basically freezes. The same map used on the Lua interpreted version does not lead to that (the game runs fine at a constant framerate). I don't think it is a memory leak because if I remove instance of the same mesh, the problem goes away (which means it doesn't have to do with batches either, since that is constant). I've even loaded the map without Lua scripts and I still get the same issue. It sounds like some sort of thrashing is going on due to less memory being allocated, but I'm not sure. I'm also only using 2 lights, and about 120k polys (with a similar amount of shadowed polygons). I think I was using between 400 MB and 700 MB of VRAM, but none of these should be the issue here either as I have 2 GB or VRAM. Anyway, any possible solutions or compiler settings/flags that I might be missing here?

That works great, I hope it's documented soon! Of course, the more stats the better. However, what does total memory mean (and what is it measured in)?

I noticed that World:GetPolyCount() doesn't exist. I think it would be beneficial to have various counters as well to help debug performance drops: Just a few thoughts: Number of draw calls Number of surfaces (I guess the same as above or is that materials?) Poly count VRAM used by game Active/total physics bodies etc.

I found this software that can be used to make roads now if you really want to (not as good as the above links, but still should work with Leadwerks heightmaps fairly well): http://www.shapemagic.com/roadmaker/

Is there any status or rough estimate or is this feature being scrapped for now?

Does the beta have a hitbox option for the player (I haven't really been following the updates recently)? Anyway, one easy (but kind of time-consuming) way you can do this (I do this for my traffic system) is to do something like this: --Set self.entity pick mode self.entity:SetPickMode(0) --For each bone that you want box=Model:Box() --scaling, positioning, rotation box:SetParent(FindChild(bone1)) --Then, for picking each child self.entity:SetPickMode(Entity.BoxPick) Then, on each pick, you'll get the hitbox (or I guess the parent, so the bone). Now, you can do what you want with it. Also, it looks like this might be an undocumented command: Entity::SetPickBox() It seems like you can use it to replace all the scaling and rotation stuff, but idk. http://www.leadwerks.com/werkspace/blog/1/entry-1363-say-goodbye-to-hitboxes/

This should work: System::GetProperty("sandbox")

Oh wow, totally did not see that. Thanks for pointing that out! Edit: So after compiling it, I have this issue where the framerate starts at about 3 fps and then decreases to 0 fps in a few seconds upon launching and freezes, and this did not happen with the player that was downloaded with the updates. Is there possibly a compile flag or something like that that might be impacting the interpreter's performance? I am compiling under Release and Win32.

When you create a Lua project, there are two C++ files listed under the Source folder. Suppose I want to recompile these. Does anyone know how I would go about doing this with VS 2013 (like step-by-step)? (I'm new to C++ for Windows, I primarily worked with C++ on Linux )

Oh oops probably should have actually checked the link out! I was under the impression that he/she included the whole DLC and FlowGUI.

Edit: deleted, nvm. I originally wrote something that was criticizing the OP for posting files up that shouldn't be posted up, but I guess I miss interpreted the post.

When you are calling entity:GetKeyValue("name") and getting blank strings, it might mean you are colliding with entities with no unique names (possibly CSG or the terrain or water or something). What you may have more luck doing is to flip the situation around. Instead of constant detection on the player, attach this code to the trigger. Right now you are essentially analyzing collisions every loop, and it introduces errors and unexpected behavior with minor collisions, unimportant collisions. If you perform the GetKeyValue check within the trigger code, then you will likely have better results. Also, what is a tick? Do you have the console open while you are running the game? There is always latency with producing output due to the way your operating system works, and there may be some buffering going on to delay it even more. It's very likely that the data is a little old, since it should be a constant flow of data. But, as Shadmar said, it would be helpful if you could provide a map with code (even if it's just a small map just for this purpose).

Are you sure those are shadows? They look like messed up normals (because of the hard edges and triangles), but I could be wrong.

Textures problem: Open up the model viewer for that character: http://www.leadwerks.com/werkspace/page/documentation/_/user-guide/model-editor-r16 On the right side, go to your director for the materials for that character: http://www.leadwerks.com/werkspace/page/documentation/_/user-guide/asset-browser-r674 Drag the material form the Asset Browser onto where it should go on the model in the Model Editor. Repeat this for each material. Then, save you model in the Model Editor. I find that Blender sometimes handles things weird, so that's probably why you get the texture problem. Animations problem: In the Model Editor, there is a Load Animations option. This only works if the character you have and the animations you are loading from have the same hierarchy (and bone names? - I'm not sure about this last one). Day/Night cycle: There is a third-party made (Shadmar made it) day/night cycle script/prefab, so it isn't built into the engine: http://www.leadwerks.com/werkspace/topic/10334-day-and-night-cycle-shader/page__st__20

You can do this, but you have to update this for every entity. To determine the force that must be applied: http://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gravitation#Modern_form This equation would give you F (the magnitude of the gravity). You can probably just make up a G value though. The direction of F would be just towards the center of the planet. r is just the distance between the center of the planet and the object Then you need to calculate the unit vector of F (I'll call it F_u): http://www.vitutor.com/geometry/vectors/3d_vectors.html Anyway, once you calculate F and the unit vector F_u, here is some pseudocode that should be close to the real implementation: function Script:UpdatePhysics() pos=self.entity:GetPosition(true) --position of object pos_p=planet_entity:GetPosition(true) --position of planet r=pos:DistanceToPoint(pos_p) --Calculate distance to the planet F=G*(planet_mass*self.entity:GetMass())/(math.pow(r,2)) --Calculate the strength of the gravity F_u_magnitude=math.abs(pos.x-pos_p.x)+math.abs(pos.y-pos_p.y)+math.abs(pos.z-pos_p.z) F_u=Vec3(pos-pos_p)/F_u_magnitude self.entity:AddForce(F_u.x*F, F_u.y*F, F_u.z*F) --This is the simulated gravity effect ... end I haven't tested this code, but this should in theory work. A few notes: Gravity should be disabled The character controller will not work with this method since it's a custom physics object that relies on real-life gravity Hope this helps!

Aw ok, that makes sense! I didn't know that instancing was pretty much instantaneous. Very cool though!

The interface and graphics look so crisp! You and Rick have been doing an awesome job so far! Can't wait for a video! @ Rick, are you loading assets at runtime via Lua or C++? And are you streaming them in somehow (possibly on another thread)? Just curious on how you are approaching this.

I'm not sure I follow what's going on here, but I guess it works now? Also, I'm really sorry, but I some things came up and I'm very busy so I can't test it tonight. I think what this is doing is specifying the pick type for the hitboxes (children) and the actual mesh (parent), and then removes the parent from future pick tests to increase performance. I just think it's easier to do it in two lines than to iterate through all of the children.

This would be a dream come true! lol It would also take a load off of Josh for smaller features like additional audio support and other cool but more specific technologies.

I can try it tonight when I get time to work on my computer. One problem I see right now in the AI code is that self.target never gets assigned anything, but idk if that does anything.

It doesn't have any effect. Maybe you aren't being careful with variables? It's hard to tell with the code you provided. Can you post a snippet of the AI code?

I was wondering this too. What's the deal Josh?

I had this issue as well. To solve this, you can surround that code with this: pcall( function() --whatever is causing the error end) This is how you can do exception handling in Lua. Exception handling (idk what your knowledge of this is) means that the code won't raise any errors but will silently fail. Basically, the pcall() method does this, but you have to but an anonymous function()...end inside of it. That part seems to be more of a syntax thing. Don't do this every frame though since it's expensive. You should only do this for the code inside the pick (or I guess on each KeyHit() isn't too bad either). This is useful if you are trying to access something that not everything in the scene has.

That isn't the first problem because you would still be able to see the animations in the animation tab without the shaders. Are you exporting from Blender as .fbx or directly to Leadwerks as .mdl?