Canardia

It doesn't really make any sense to use SetPosition with physics objects (except for initial positioning before the game has started). Then you can use meshes as well. SetBodyForce works accurately, and moves the physics object to the wanted position. It doesn't warp it there.

Of course it's not using SetPosition, but SetBodyForce. Else they would warp from place to place and stop, instead of smoothly moving to their place and continuing the movement when no command is given.

The client still does physics, but no collisions and no gravity. So all physics objects in the client always move in a straight line, until they get a new position from the server, then they move in a straight line to that position. With collisions and gravity enabled, they would also move in curves, and probably wouldn't need much corrections from the server at all. The only time they would need corrections from a server is when a player collides with the objects, but the player positions are done currently on a higher frequency network channel anyway, so it wouldn't matter how slow the objects are updated, they just do their own physics mostly.

Yeah, that's what I would improve too. I would also make the oildrums have collision enabled, and sync them not 10 times per sec, but maybe only 1-2 times per sec, or maybe even every 5 secs. That would require that instead of using the character controller, you would replace it with a real physics body also, like a cube or cylinder. Then it would respond to physics forces more realistically, and doesn't need to be manually pushes around so much. The best would be of course to have a ragdoll physics body for the character.

There is a slight delay anyway with the default character controller acceleration settings. I didn't notice any additional delay due to network lag, but only the normal physics acceleration.

At least version 15 worked very smooth with 300ms ping and 8 packets per sec. I have to check if version 17 is different.

A in-memory undo would not prevent you from losing ours of work when your PC or Editor crashes. An autosave would be needed in addition to that, but autosaves don't know when you have a good version to save, so they will save unneccessary versions also. Autosave would also not save the latest version before the crash, so you might lose some work anyway.

Adding a datetime string to the filename would be more effective. Then you can have infinite undo/redo steps without using any memory (except harddisk space). There could be a button and/or key combo to "Save as datetime version", so you could just repeatedly hit that button whenever you got a good snapshot in your design phase.

There is no Lua source, it uses the Lua scripts from the Models.

ClearWorld(fw.background.world); ClearWorld(fw.main.world); ClearWorld(fw.transparency.world); or fw.Free(); fw=CreateFramework(); SetGlobalObject("fw",fw); This is just theoretical code, hasn't been tested

- Engine.exe is not using engine.dll - GameLib is using LEO, not engine.h - LUA API is not using engine.h - BlitzMax, Editor.exe, Engine.exe and engine.dll is using LUA API

BlitzMax uses the same Framework as the DLL version, but it's used in source code form (like earlier when it was called Framewerk). So in BlitzMax you can customize Framework, although there will be also customization options via callback functions in the DLL version.

You can also have dlls in the system path. I have for example "c:\program files\leadwerks engine sdk" in the path, and never need to copy newton.dll, jointlib.dll and engine.dll to those 3 billion folders of my test programs Saves a lot of harddisk space and manual updating each time the engine is updated.

You can upload it on SkyDrive and post a link here.

Instead of parenting you can do just first positioning, then rotating and then moving. It works in many cases better than parenting.

When you rotate the main camera, you need always to rotate the background and transparency camera too. Actually I remember now faintly that Framework does that automatically, as well as the zooming, but if not, then you need to do it. If Framework indeed rotates the cameras, the your parenting might be messing up Framework's camera rotations, and then you need to manually rotate the other cameras, since when the main camera is parented to a pivot, it might look for Framework that the camera is not rotated at all, but only the pivot is rotated.

Rotate them all always, but also zoom them all.

Each world is completely independant of eachother, so the cameras in each are also. When you rotate only the main camera, the reflection camera and skybox camera doesn't rotate. I don't know why your skybox camera rotates, maybe Framework rotates it with the main camera.

You need to rotate all 3 cameras, not just the main camera.

The forum chat seems to have a limit of max 5 users, Josh needs to fix that.

That would work, if Josh publishes the SetLayerWorld() function. You should make a feature request about all features you miss in Framework, since its just the initial version, and needs still more features to be added and exposed.

Yeah, I was just thinking the same, that I should explain more detailed in the PT what the entitykeys mean.

The classname key is used to identify a Player model in a sbx scene. The name key is used to differentiate between different Players.

Well, you have to change at least name="player1" (from the first group tab in Editor), or whatever name you want the player to have. Since in the game code, you ask gamelib for that name with: game.scene.SetCurrentPlayer("player1"); Actually the PT uses name="info_playerstart", but I think that's a bit confusing, since it's the classname also. I will change the PT to use "player1" so it's easier to understand.

That's wierd, but I can check why it would be different, since the info_playerstart should have an ini file which creates the same entitykeys as the sbx has.