Josh

1. Drag server.lua onto engine.exe. 2. Drag client.lua onto engine.exe. 3. Go to the client window and hit the tilde "~" key. 4. Type in this in and press enter: connect 127.0.0.1 You should see a connection message and test packet in both windows. 5. In either program, type this into the console and press enter: say Hello You can chat back and forth with both programs. It will work over the real internet if you enter your friend's IP address. Spaces in messages are not supported because the parser is not very good. See console.lua to improve it.

Because the model AABB doesn't encompass the whole object, so the render function gets skipped when you are close. BTW, using the Render function like this will result in an enormous speed increase, because you can have tons of offscreen characters that don't have to be animated.

If you want help, you need to post your files. I examined this issue in the tunnels map. At first I tried capping the max force, but then I noticed the geometry had some one-sided triangles in the corners. This was what caused the controller to get thrown sideways when pushing around the corner. I uploaded a fixed .phy file. It is interesting that another problem we had early on was also due to bad geometry, and the controller was working correctly. This was caused when the player was unable to go up a step, and I looked and found the step was sloped. You can read about it in the old forum.

You can divide the texture up any way you choose, for any number of skins.

After playing a little with a few different systems, I do like this idea. I don't like Torque3D's implementation, but the Unreal implementation is fun to use. I maintain that this won't do anything you couldn't easily do with a few lines of shader code, but I'll make one just because it is fun to play with.

Just divide the texcoord by 2.0, then add a value depending on which skin you want to use: 0.0,0.0 = skin 1 0.5,0.0 = skin 2 0.0,0.5 = skin 3 0.5,0.5 = skin 4 You might use different normal maps for each skin, or you might just use the same one. Fortunately the shader lets you decide.

I will try in the future not to break any code. It seems like people are pretty comfortable running frequent updates as long as it doesn't break their existing code.

This is a minimal example showing how a program can communicate. From here, you can imagine how chatting could work, and then how keyboard input could be used to control a player over a network. If the network commands are not found, just run the updater. 1. Drag server.lua onto engine.exe. 2. Draw client.lua onto engine.exe. I will continue with this, but I hope the community will jump in, too, so we can make a basic program. I will admit I am not an expert at networking. But there's not really that much going on in a networked game, because the server generally controls everything, and the clients just provide keyboard input and get back positions and other information. simplenetwork.zip

That's the point. Where else would I assume it is when I create the project?

The default directory for the 2.3 installation is changed to "C:\Leadwerks Engine SDK" in the installer. There are two reasons for this: 1. Some people have had problems in the past with Windows Vista/7 security features. I do not know all the specifics of how these settings work, but some companies are moving their installation directories to the C: drive to avoid problems. 2. I am adding a lot of vc project examples, and the "Program Files" / "Program Files (x86)" thing causes problems with this. This only affects you if you want to run one of the vc projects I include in a tutorial.

You can add a property for the skin number (with options 1-4) and override the color property with this one. I think the Source engine does something like this.

After that, I can add some grabbing code like Penumbra uses pretty easily to the FPS script, and that will probably help you.

It's not a hacky solution. It's efficient and works really well with the way the hardware works. Non-instanced copies might someday be added, but you should be aware you are asking me to increase bugs and decrease performance.

Make a drawer shape out of 5 boxes. Export an .obj. Run it through phygen. You now have a .phy file that contains five convex hulls forming the drawer shape. This is how concave objects are made. Maybe everything we learn during this process will make a nice tutorial.

You can actually do what you describe using a shader, without losing instancing. Put four different textures on one, and use the entity color to determine the texcoord offset for which texture is used. That's how I would do it.

The reason instancing is used is because right now the engine does this: -Make an array of mat4s for all the visible instances. -Set the material/shader/textures. -Set the vertex buffers -Tell the GPU "take this array of matrices and render N copies of it". This is only one draw call that draws all instances of the object. -Unset the vertex buffers -Unset the material/textures/shader. This makes it very very fast to draw lots of copies of an object.

Having multiple paths is a nice idea. I really like good old Worldcraft, and how they have a million buttons and little windows for everything you do. Something like that with an ability to add paths would be nice.

Generally you won't need to even open Framework.bmx or edit it, so it won't be a problem, hopefully. It's not necessarily something that has to be "fixed". It's more just a bad design decision, in my opinion.

I don't know what format that is, but it isn't .obj.

The lua state byte pointer GetLuaState() returns is the real lua state. The commands I have exposed through the DLL work on it, and they are just the raw lua API.

You CAN have layers of transparent surfaces, just not when they use a refraction effect that reads from a texture and distorts the image.

Right now you can set one path for everything to be loaded from, in Options>Paths>Game path. One quick way to add more paths is you could create a script in the "Scripts/start/" folder and add the lines to register those extra abstract paths. I actually always keep the editor in a separate folder from the engine, because the source code needs to be separate.

Well, it won't stop there. Then we will need one for water, one for emitters, one for refractive materials...and then someone will notice two refractive layers don't work.

Because the refraction shader reads a texture to refract what has already been rendered. Rasterizers can't read an underlying pixel, unfortunately.

Not if they are rendered in the same pass.