Rick

I haven't seen any. Speedwise it runs great. The one big catch with doing this, which reminds me I should create a request for this, is that currently bodies that you create via lua code, you have no way of getting a collision function called on them. They will collide and act on physics, but you can't link to a callback on them to do certain things when something collides. An example with this is creating area/volume triggers. I have a thingoid that is just a physics body. You can change the size of it by the settings and it recreates a new physics body when you do, because you can't scale physics bodies and have them work correctly. This works create, because it's much faster to do it in the editor where you can size things up and resize on the fly to create any size body where you want it. The issue is when something hits it, say like the player, there is no way to know that because you can't get a function called in lua. Currently that only works when you drag an actual model into your scene, then that lua classes collision method is called.

Mostly yes. I know VicToMeyeZR started the topic but he's playing off the character thingoid I made and improving on it, and all I'm doing these days is lua based. My goal is to make a bunch of different useful thingoids so a full game can be made. My current platform game that I'm making will be lua based with a possible dll loaded from lua for anything that is very speed sensitive. But ultimately it's ran from lua. Basically my goal is to prove that with some modifications to how some lua stuff is done, it's possible to make an entire game from lua using LE.

You'd have to parse the ini file yourself then though. The way this Thingoid is setup is that it's just one generic Thingoid in the editor. You place it in your scene and it creates a character controller. Via a setting is where you assign what mesh you want to use. That mesh would have it's own animation information which could be different from another mesh. The reason I do characters this way instead of the way Josh was thinking, which would be that you actually place each model into your scene from the tree view on the right in the editor, is because characters all share common code they need to do. So instead of copying and pasting that code into each character model lua file, I have 1 lua file that runs the character code and I select which mesh to assign it to. It's kind of like an object oriented way of thinking. If I was programming this in an OOP language I would make a Character class. That class holds all the code and it has properties. One of the properties would be what mesh to use for this character, and another would be that meshes animation information. The ini file system he has setup will be auto populated for that model. In this case the model that's being used when I drag my character thingoid into the scene is a circle model. The only purpose of it is to allow me to move the position of the controller and the mesh I assinged to it in the editor. The real model being used in the game is the mesh you assign via a property. So given that information you have to parse out a file that has stored data, if it's ini or xml or some other protocol you come up with. Xml is just very common and there are tons of already premade libraries and code out there that allows you to easily parse complex xml files.

To be honest when I suggested using an xml file I was more thinking that you could assign an xml file for each instance of the model and it would have the animation information for that instance. I wasn't thinking that they would all share the same names and number of animations. With indie developers getting models from all over the place they most likely won't have the same number of animations at the same frames so each different character model would needs it's own animation information file, which would be custom to that instance of the character object. VicToMeyeZR was thinking slightly differently than I was. In the example he put together then yes using the ini would make sense. In the way I was thinking an ini wouldn't work the same way.

xml is just a little more structured and standard than an ini file these days.

I agree. If an API was over XNA it would be good. I didn't enjoy working directly with XNA 2.0. Things were still a little to raw for me. Animation support was horrible too.

for anyone wanting to host servers and don't have a static ip address, noip is a good service to look into. It gives you a domain name and a small program that runs on your machine that updates your ip address to their servers so it can reroute people who request the domain name to your ip address. When testing this could save you from having to change you ip address in the program every time it changes.

I don't think you want to go that route. Changing the class.lua file will cause portability/resyncing issues. You should be able to do that in the Thingoid lua file and it'll be much more portable and won't get overwritten when Josh changes the class.lua file and people resync. Try: string.lower(StripExt(objecttable[model].class.modelreference.path)) or local cls = objecttable[model].class string.lower(StripExt(cls.modelreference.path))

One of your versions wasn't that way. One of them I noticed a slight input lag on the controller even when I was the server. Either way, do you have a final version of this for us to test out? Is this final chat version that?

I 2nd this idea. It would be really amazing to see what we can come up with. Of course it would be behind getting a collision function to work on bodies we create in lua

Yeah, if you release the code I'll be happy to make a Thingoid of it.

ah, look at the class.lua file in scripts. Right under the first CreateObject() function. The path is getting taken out and the file is assign to the class.name like I posted above. You should be able to get the full path.

Very cool man. Are you thinking of leaving it so people have to code it like that or was there no way to set it up where they just set a property for the mat file?

It was a server I created.

For chat16 the movement seems instant, and the interaction with the barrels seems perfect.

As true as that is, I also think there is a reason very few networked games use physics to a large degree. I think lag hiding tricks are inevitable. That's all client-side prediction is. You are hiding the input feedback lag.

You are correct, but I think that when neat little hiding tricks come into play. Look at something like Tomb Raider. When she's about to start moving she plays a small animation to get down into position and move. That 1/4 of a second would be enough time to do that. It would cause issues if say you have the force (star wars style) and you wanted to push someone with your hand in a given direction. There would be a visual feedback delay, but again it might be avoided by animation trickery.

I can only guess that the controllers were controlled server side and had to client-side prediction. Once you introduce that it opens up other issues to deal with, but it's a door that has to be opened. Every modern (and even older, back to QuakeWorld http://en.wikipedia.org/wiki/Quake) networked game will have it. http://developer.valvesoftware.com/wiki/Lag_compensation This is also interesting for things like shooting. The server rewinds itself the amount of time it took for this client to get a message like shoot. By doing this the server can "see" the scene from the eyes of that client and would be able to tell if the client hit another client visually on their screen, which would make it a hit on the server as well.

With the way I was describing this would work. The client is updating it's position on one controller on the server, and because the other is moving with it and has physics enabled it would push other physics objects. The same for the other client would do the same on the other side of the object. The object would go nowhere and that would be updated on the clients. But I'm interested to see what you have going on Josh.

You are correct, but visually it wouldn't be noticed by the client. The position of the barrel on the client will always be behind the server. So when the server see's the collision and sends the details to the client, the client then gets the barrel position followed by the collision information to react on it's local controller. When the server gets the collision it sends a barrel position along with the force of the hit. The client then does the interpolation of the barrel and applies the force at the same time the barrel is at it's final "hit" position on the client side. I think my nose just started bleeding Now I want to try this out

So how would the reaction of a player throwing a barrel at another player play out with this? Who owns the barrel? At what point does the ownership change to make it work on the client getting hit by the barrel that was thrown by the other client to give a proper reaction? With the way I was describing the server would be able to recognize the collision and know the point of collision, force, etc. It would send that information to the client, who would then have that same force applied to give the proper reaction. The barrel would have the proper reaction on the server and update it's position to the clients accordingly because it has a working physics body for each client attached to the non working physics body that is getting it's position updated.

Right, but when you bought it did you think "This is going to be a killer gaming machine"? I'm guessing not because there just aren't that many games out there for macs. There are games, I'm aware, but the quantity is much lower. I think most people get their macs for different reasons than gaming, where there are a ton of people who get PC's specifically for gaming. I'd say if it's not a big hassle then supporting macs is no skin off my back, but if it causes any sort of issues I don't think it would much be worth it. Most people with macs run that boot camp thing anyway so they can boot into windows.

I think this would work if one of the issues could be solved. When setting position of things collisions still occur. What if we make 2 controllers on the server side. Fixed joint them together on top of each other. One controller get it's position set from the clients position (and hence loses it's physics ability) while the other which has a fixed joint causing it to move with the first controller, can still react to physics events. That will give you the ability to have things show their effect on the player, but still not have the player get effected by the physics. But if you drop a barrel on a players head it'll react correctly for everyone. If a player runs into a barrel it'll move, but if something hits the player which would normally cause it to react via physics it wouldn't. So that would still need to be solved. [EDIT] Well if something should cause a client to apply physics the server would know about it because the collision would occur right? That message could be sent to the client and run locally on the client.

Oh, you got me thinking now. Another Thingoid is bouncing around in my head. A GUI Thingoid that you drag into your scene. You give it an xml file that describes all the GUI elements you want in your scene and it displays it. Also allows you to send messages to it to pass along information to the GUI elements. Work must begin instantly!

I wouldn't even say bad latency. I had 110ms which is far from bad and the delay was noticeable. Adding this to a fast twitch game would only amplify the sluggish felling. I couldn't agree more. We just can't have our cake and eat it too. I would be curious to see extrapolation and interpolation ran on the barrels dropping to see how the clients handle it though. At 8+ times a second I wouldn't think it would be all that bad. With that you could have the physics happening on the server, it's just that the client's wouldn't really be able to have advanced interactions with it. They could perhaps start a physics effect, but interacting with the objects would be an issue. It could lead to some cool gameplay stuff though. Say you shoot a ring holding a draw bridge. The joint breaks on the server and the bridge comes crashing down via physics that is being ran on the server.