nick.ace

What processor do you have? If you have an eight-core, then you are maxing it out (and who knows, there might be other limits imposed by the OS to limit your program's CPU usage). Your GPU usage probably goes down because of this since it's waiting for the CPU to catch up. Anyway, what does your map (if you have one) and code look like?

You can do scrolling text with this: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/context/contextdrawtext-r731 You can just update the position each frame. If you only have a little text though, then AnthonyPython's suggestion is probably best (saving an image of text).

This might be a pretty obscure question, but I just had a thought as to why I might sometimes get crashes randomly. Anyway, do loaded assets get "cached"? If not, then could loading and releasing assets possibly fragment memory to an extent that could cause a game to crash?

Isn't it partially dependent on the character controller? I don't think that the character controller can even go up that slope. I would like to see customization options for the character controller too.

Congrats! I guess they are not into the California rap scene I like YouGroove's suggestion though, maybe even allow other users to be able to edit and add onto tutorials if they are out of date or incomplete?

Yes, you can basically combine C++ and Lua in almost any way you want. That being said, you would have to find a way to efficiently extract variables from your Lua code, and so you could run into transmission speed issues (since you would effectively be taking out large amounts of Lua data each frame or so). If your ultimate goal is to create a multiplayer game, it probably would be best to do the gameplay logic in C++ as well and leave Lua for client-side code (like quest logic, inventory management, etc.). My guess is that you would probably have to pay something to Steam to use their servers. Of course, if you are forcing players to host if themselves, then the cost is on them.

Yeah, Lua is a pretty simple language and in my experience it's similar to a lot of server-based languages (such as Python, Ruby, and PHP). Leadwerks does have certain conventions that you will likely need to follow, but Lua itself is also a pretty popular game scripting language.

The Steam API exposed in Lua only allows for basic Steam stuff that would be useful if you publish a game on Steam. It doesn't contain networking Steam API commands though. With C++, you could expose this yourself fairly easily (you can even bypass the Steam API calls in Leadwerks and just call the commands directly). I would recommend Leadwerks for roleplaying games in general since it has all you need in that regard. TBH, I don't know if it would be an issue to develop most of the game before adding multiplayer for your type of game. If it were just a standard FPS, then I wouldn't think it would be as much of a problem. But choosing how to send vast amounts of data across a network could be problematic. Plus you would likely have other client-side limits that you might face (most notably performance) that you will need to resolve. I would also think that synchronization could be very complicated. I face some of the challenges that you will face. My game has issues with framerates (that I have to keep an eye on) since I have so many assets lying around and in view. I use time-slicing to simulate threading in some ways. Sometimes I also get crashing, and this might be due to my extensive memory usage. The biggest issue with large, populated worlds is that there is no streaming. I probably should have developed in C++ in the beginning so I could try to add streaming myself, but now it's a little late haha.

I'm unfamiliar with both of those, but they sound somewhat like MMOs? If that's the case, then it's probably not a great choice for this engine. There are engines that specifically cater to MMO-type games, so those would be your best option. Leadwerks doesn't have networking at this time built in, so you would need the C++ version to do that (although there might be a Lua wrapper floating around somewhere). I would also guess working on a large scale with networking isn't a trivial task, even for experienced programmers. Also, the world size might be a constraint if you intend to make very large worlds (and especially keeping memory usage low as there is no streaming support built-in). That being said, the type of gameplay involved should be doable in general, but you would need to be prepared to do a lot of work. There are a few "specialty" game types like this that would not be best suited for Leadwerks.

There is built-in crouching. The SetInput command has a parameter for it. You need to specify the camera height though (since not everyone is going to want a camera to change position while crouching).

np! it should be up. I modified only the UpdatePhysics(). IDK how to use the workshop now, so it extracts to the root folder. I'll see if I can fix it though. I commented some code, but it should be fairly self-explanatory. I keep it to like 9 lines I think? Anyway, the only changes are at the top of the UpdatePhysics() section where those 4 points are defined (and redefined) and in the KeyDown() SHIFT conditional. Also, you'll notice that the bottom check is not actually at the bottom of the character. That would generally be a bad idea. It should be around two feet above the character's feet since that's where the character controller ends (mine might not be though). Basically, all I have now is automatic climb/jump on small ledges, so it's very simple. Edit: It's at least in the Addons/Addons/Parkour folder now, I give up trying to make the correct directory...

A few things: Don't do this: castPos = pickInfo.position Picks are expensive, especially when you always call the closest point. Not only that, but you have to do an extra comparison anyway. Instead, use a transform for "near point." Secondly, the normal returned from the PickInfo() object is a Vec3, not a float. Do this instead: 0 * ---- * -|- * -- * / \ where * are transforms (and that's supposed to be a person on the left). Do two picks instead of one between the two transforms. Note that the distance is different between the two, which will allow you to simulate an angle. Since you didn't get a runtime error from the incorrect comparison, that means that your transform is likely WAY too small. You should multiply the range by about 100. Your thread inspired me to change the FPSPlayer.lua script to have a simple parkour system when sprinting. I'll post it on the workshop. Also, for inspiration:

Yeah that's true. Video formats tend to have a lot of licensing issues with decoders/encoders and codecs, etc. but video support would be pretty cool.

I think you still need to purchase the BINK license. This post is a few years old, but unless the pricing has changed a ton, you're going to have to pay at least $8500: http://bitsquid.blogspot.com/2012/05/playing-with-video.html

A lot of the Newton functionality isn't exposed in Leadwerks, specifically the Ragdoll class (I think it might be deprecated though?) and other controls over joints, notably stiffness. http://newtondynamics.com/wiki/index.php5?title=API_Database#Common_Joint_Functions

First of all, I think he took some time off recently. Second of all, why does he need to comment? Also, what exactly do you want him to say? Most of this is bug reports. It's not like he needs to post his opinion on this stuff. It's pretty objective.

I'm actually working on rag dolls right now, but as shadmar said, the joints are way to elastic and unstable. Also, I'm not sure some of the joint limits are working right, so I might file a big report once I have a time to test them more vigorously. Apparently you can compile Lua wrappings to c++ commands, so I wonder if it's possible to provide access to some of newtons other functions this way.

I'm not sure what you are asking as the code block you posted should work, although you should exit the loop somehow. This is not the right syntax though since you need to clear effects from the camera: self:ClearPostEffects()

YouGroove, that code actually wouldn't be any more optimized and would likely be LESS optimized because there are more interpretation steps, at least in Lua (even in C++, you would be guaranteed to run 4 checks each time, whereas gamecreator's code would do at most 4 checks). You should be using elseif for the second, third, fourth, etc. if statements. That way, you don't have to run through all the conditionals for all of the entities.

I haven't used LE for about a week or so, but I have found that the editor performance has gotten a lot worse. I only get like 8 fps in the perspective view, whereas I was getting much more (about 60 fps) before. On a positive note, my game seems to have a speedup, so this seems very strange. Is anyone else having this problem?

Isn't that topic for convex shapes? I'm pretty sure I've generated NavMeshes with many more faces than that. Maybe you are generating a huge convex hull mesh? What does your map and/or meshes look like?

This changed a bit since a few months ago I think, so I don't know how the naming works. Anyway, the easiest way to apply a collision hull is to click on the crate, go the scene tab, then go to the physics tab under it. You'll then have a few collision shapes you can select from (one of them is a collision hull, although I would recommend just using a box for this model, since the collision hull will be the same shape). Convex decomposition is a new feature. I don't understand how to operate it, but the purpose of it is to break down a concave model into convex pieces. For a simple crate, this isn't really necessary.

I think that is actually expected behavior, at least for your framerate. Is that your actual framerate or are you slowing it down? Anyway, Leadwerks does not render meshes that aren't in view (I guess all 3D engines do this as well?), so when you turn the view quickly like that, specifically coupled with a low framerate, these issues become more obvious. There is some delay, like maybe a frame, so that's why they aren't showing up.

I'm not really sure why you are getting a black box, but it may have something to do with other code that you may have (like if you edited App.lua code or something) or maybe the image doesn't exist or something like that. Try a different image instead. These tutorials explain how to make a collision trigger ("zone") effect: The second link shows code on how to do this, but the first one gives a little bit of background.

This does a picture instead: Script.ObjectDescription = "test" --String "Object Description" Script.DisplayTimeMax = 5000 --Int "Display time" Script.Used = "0" Script.DisplayTime = 0 Script.DisplayEnabled = false Script.image=Texture:Load("Materials/Effects/bloodspatter.tex") function Script:Use(context) self.Used = "1" self.DisplayTime = Time:GetCurrent() + self.DisplayTimeMax self.DisplayEnabled=true end function Script:PostRender(context) if self.Used == "1" then context:SetBlendMode(Blend.Alpha) self.DisplayEnabled = true if self.DisplayEnabled == true then if self.DisplayTime > Time:GetCurrent() then context:DrawImage(self.image, 100, 100,100,100) else self.DisplayEnabled = false self.Used = "0" end end App.context:SetBlendMode(Blend.Solid) end end Collision trigger: Are you talking about if the player enters a certain zone this script gets played? Or is it if the player selects an object like with this script?