Josh

I'd be very interested to see a compiled example.

Interesting...and you can even use C++ with this, since Lua can call DLLs.

Yeah, of course that will be instant. I am pretty well satisfied with the design now. Either the client or the server can create an entity and upload it to the network. If you have a fast-paced FPS or racing game, just let each client control their own player entity. If you have a physics-intensive game and are comfortable playing only on low-ping servers, let the server control everything. You might be able to create a controller on both the server and client ends, and do your own comparison, but I am not too worried about it. The point is that once you sync an entity, you can move it around, let physics move it, free it, and it will automatically be updated on all the clients, which is fantastic.

They're really different products. Leadwerks runs great on the laptop 9800M cards, but it won't ever run on your integrated chip. On the other hand, the graphics of Unity free are very limited, and performance is slower on good GPUs. So it's a question of what you value most and who you are making a game for.

What is your ping with the server you are on?

Can someone please create a server for testing?

Sure, but that's not even really a physics problem. The held object doesn't even have to be physically interactive. A much hard problem is if two players push a box in opposite directions. Fortunately, the way I am setting this up allows you to make everything from pure server physics to client-controlled players. What I am aiming for is a means to have both with some glitchy interaction between players and physical objects.

That is exactly how I am handling it right now. The problem is that the interaction between the client-owned controllers and the server-owned drums is not as simple as it might seem. Still, if I can solve that, even with some problems remaining, it will be the best of what we want within the confines of the hardware.

The problem is this leads to instant corrections when the client and server results diverge, which is very often if you have an interesting physics simulation running. This is why multiplayer games rarely have very advanced physics interactions. You can create the player controllers on the client machines and let the clients dictate their orientations. This result would be the same as what you described above. Alternatively, you can let the server control everything, if you are willing to accept lag on servers with bad latency.

My advice is to make the routines based on their hierarchy. If there are ten windows onscreen, each with one button, you should only have to evaluate one button when the mouse is clicked. For both drawing and mouse input commands, the routines should be designed like this: Method Update(x,y) if not self.hidden() if x>self.x and x<self.x+self.width and t>self.t and t<self.t+self.height for child=eachin self.kids... child.update(x,y) next endif endif endmethod

I tried updating the controllers on the client side. The major problem with that is the controllers no longer influence any physics objects. Client-side prediction did not have a good outcome. It resulted in "teleporting", which is something that really bugs me about networked games.

I need someone to create a server with the latest version. I am testing client-side prediction, and can only do it if I have a remote server with some latency.

Reliance on CSG used to be a huge complaint from artists. They wanted to model a building in their own 3D modeling program of choice.

When did you install the SDK? I think there was a problem like this earlier, but it was fixed last month. What program are you trying to run?

To make a game for the consoles, you need to be approved by MS or Sony. To get this, you must already be an established game house with one successful title under your belt. It's much easier to get a game approved for sale on Steam. As I have pointed out before, Penumbra is the best example to model your plan after. So even if our engine was offered on the consoles at this time, it is unlikely anyone here would be able to use it.

This is how I would do it. I will keep an eye on this.

At the moment, nothing useful of note.

I like the snow armor.

Okay, version 17 fixes the synced entity deletion issues that were causing crashes when a client left. I also added a check so the client will be rejected from the game if the network protocol versions don't match.

Version 16 is up. If anyone is on the west coast (US) I could use your help testing.

I am designing a client/server architecture that does a lot more for you than the standard network commands, which are basically just a wrapper around enet. You might want to hold off on this a couple weeks so you can use the advanced/nice commands.

For the benefit of anyone who might find this post in a search... point2 = TFormPoint(point1,src,dst)

I'd add another box for the engine module. This is what the DLL, Engine.exe, and a BlitzMax app all use. Lua actually interfaces directly with the module at the lowest level, so everything that uses the engine module can use Lua.

http://leadwerks.com/wiki/index.php?title=CalcBodyVelocity