Rick

I think the problem is that Josh did 3.0 with a lower version of OpenGL because he was hearing people say they wanted it (like you are). Then when he built it those people weren't around (ie they didn't buy Leadwerks 3.0). Everyone wants the pretty graphics, and people pay for the pretty graphics. Now, it would be nice to be able to use 3.0's lower OpenGL version and that was the plan. @dude The Steam edition is very capable on it's own. Why would it be tagged as Early Access? Did the Steam store page point out things that weren't true about the engine or are people projecting what they were hoping for?

I don't work for Leadwerks or anything so this is my opinion, but honestly, people dish out $60 for video games without a money back option. I bought Skyrim for $60 or so and I hated it. Yeah, it sucks, but it was a risk I took. I think a demo would be nice, but currently there is none.

Did you try running it from the exe directly vs Steam? There are 2 dependencies with LE. OpenAL and VS runtimes. I've seen it where Steam, for some reason, doesn't run the installers for these 2 all the time. People have said if you run the editor exe it tells you what the issue was.

So we can pass parameters to inputs, and how we get those values are from get type functions. Let me see if I can remember how to do this. Define a get type function in the script that holds the value you want like so: function Script:GetHealth()--arg end Then define your input function to accept parameter(s) like: function Script:UpdateHealth(health)--in end Then when you drag these into the flowgraph, the line should have a dot on it (1 dot for each input parameter). You should also see your get function now. Drag a line from the get to this dot. This means when your input is called, it'll also call the function(s) attached to each parameter to assign their value.

Look at the log file in that Local/Leadwerks path

I did something like this back in LE 2.x. I created a plane which had a bunch of verts to it. Then each frame I would place it well above the ground (which was the terrain). I would then do a raycast down on each vert of the plane, and when it hit the terrain that's the Y position I would use for that vert for the plane. This would make it "hug" the terrain no matter what the terrain looked like. Then I painted it with a selection like texture/material and all was good.

Inputs and outputs are used in the flowgraph. Open the flowgraph editor from the menu (Tools I think) and drag in any entity from your Scene tab that has a script attached and has input/output and they'll show up with little squares next to them. Click and hold these and drag outputs to inputs.

I believe it's an optimization thing so it may not make sense directly, but to speed things up I think it may be needed. If CSG doesn't have a script attached to it then it's really dummy geometry that has no function but collision/visual. That's the idea anyway.

@Clavet Yes, entity:FindChild("bone_name") would be how you get a bone name and SetParent() would be how you attach things to bones.

Good catch. I noticed that recently also. It would probably be best to use that property instead of another variable like I did, and clear it out just like I did the other variable after the map gets loaded.

So how true is that precision of a mouse in a gamepay? I assume you used it at Valve? I have a hard time believing that can honestly be achieved.

http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/camera/camerapick-r199 Use the camera for picking.

Added map switching tutorial

I think it has to do with using the navigation commands myself.

So since App lives beyond maps, you can make variables as part of App and they will be available in all scripts and live between map loads. I would look into how the AnimationManager looks (it's basically a way to make a "class" in Lua). Make one of these Lua "classes" to store the save information you need. Then in App:Start() create an instance of said object and access said object wher ever you want in other scripts. example import "SaveData.lua" -- this would be what you have to create. look at ANimationManager.lua for a way to make these "classes" function App:Start() self.SaveData = SaveData:Create() end Then in entity scripts you can access it via: App.SaveData.PlayerHealth = self.playerHealth

I wouldn't call flowgraphs the "correct" way. It's just one way to do it. The benefits are it helps avoid direct dependencies between scripts. This makes your scripts more component like that people can connect together with the flowgraph. Some people don't care about that and will just make direct dependencies of other scripts. I personally don't like that, but to each their own

Nice tutorial man. You could also put that code in the weapon or player script also since then it would have access directly to some ammo variable and know when the gun is fired to reduce ammo, but putting it in a pivot is also a valid option. If you put it in a pivot you'd want to make some kind of output called from the player/weapon script and connect that output with some kind of input to the UI script and hook those up in the flowgraph so your UI script can be informed when the ammo changes. I know this was more about fonts, but just giving you options and things to think about with your next tutorial on ammo/clips. I personally like the separation of scripts between the UI and the player, but it requires a little more hookups via the flowgraph to work. We used to be able to attach multiple scripts to an entity, which I thought was nice, but that was removed so pivots are the next best way to get this kind of separation. If you want to make easy and reusable scripts separating them is the way to go.

Weapon pickup tutorial added.

I'm on the chat willing to help but you guys aren't looking at it

Learn the Lua basics without Leadwerks first. Variables, functions, tables, etc. That should take a couple days to get familiar with, then start using Leadwerks functions.

If you're a programmer only, then you need to either team up with an artist or buy your models. The promotional forum here has some nice places to buy cheap models/sounds/textures. http://www.dexsoft-games.com/ is a good place also. http://www.turbosquid.com/ as well. Yes, your game might look the same as someone else's. Yes, some players might know these models already, but if you make a good enough game they won't care. You can also pay a freelance artist to make you art, but it'll cost more. .mdl is Leadwerks version and since Leadwerk isn't Quake or HL it's not a popular model format so modeling tools most likely won't have plugins to support it. I use Ultimate Unwrap 3D to convert model formats that aren't .fbx (since Leadwerks only converts from .fbx to .mdl). Don't worry all that much about the art. Use free fillers for now and get the programming done. You'll find that most of the time your idea isn't actually that good (not a slam on you but it's reality) and you'll lose interest while making it. Make prototypes/demos of the core gameplay first and don't worry about polishing things. Basic UI is fine because UI doesn't define if your game is fun or not most of the time. Have fun with it!

Place this in suggestions forum please.

Added some of these to the front page. What do you mean by a truly working light switch?

Because they make for much more realistic terrain than us molding it using the LE terrain editor.

Do you mean the height parameter? I think that does it in the terrain tab.