Jump to content

nick.ace

Members
  • Posts

    647
  • Joined

  • Last visited

Posts posted by nick.ace

  1. 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.

  2. 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?

  3. 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?

  4. Forgive me, I am ignorant, but is it possible to create the game with LUA and then have the multiplayer components run on C++?

    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.

  5. 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.

  6. 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.

  7. Thanks for teaching me this info tongue.png also that is very nice of you to do that nick.cool.png

     

    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...

    • Upvote 1
  8. 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:

  9. Also, glad to see Josh commenting in in hear. Oh... wait.

     

    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.

  10. 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.

  11. 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()
    

  12. You could even optimize more :

     

    if bullet.x < ship.x - (ship.width) SetColor (Red)

     

    if bullet.x > ship.x + (ship.width) SetColor (Red)

     

    if bullet.y < ship.y - (ship.width.y) SetColor (Red)

     

    if bullet.y > ship.y + (ship.width.y) SetColor (Red)

     

    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.

  13. It was copy/paste.

     

    Googling it pulls up this thread.

    http://newtondynamics.com/forum/viewtopic.php?f=9&t=8732

     

    From looking at Newton Dynamics, it only allows a maximum of 512 faces per a mesh. I assume this is the navmesh generated with "BuildNavMesh" functionality.

     

    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?

  14. Thanks, Now if I can get Josh to help me figure out what I did wrong with the collision hulls! D:

     

    Or, if you guys are feeling nice... Care to enlighten me and the fellow newbies on how to utilize a collisionhull?

     

    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.

    • Upvote 1
×
×
  • Create New...