cocopino

Hi, I'm having difficulties with lights in the latest version. To illustrate: Leadwerks 2.31 Leadwerks 2.32 The scene contains 1 ambient light and 1 point light. What's happening in LE 2.32 is that the normal map of the character is being multiplied to the floor and walls. This is on a GeForce 9600M GT with latest drivers. Does anyone else experience these problems?

"It allows for faster development since you don't have to compile. Just hit the run button and see your code at work." Well, I'm used to typing 30+ sentences at once when programming before hitting the run button but this will 9 times out of 10 result in an Editor crash

What strikes me most after my absence, reading several threads here is that so many people are using Lua as the predominant language... Do they have access to other tools than I have or are they just not used to having an IDE?

I disagree about it being messy per se. I think scripting can make code leaner/cleaner: Leadwerks is an entity based engine and now entities can have their own customized scripts. I think that's all it should be used for, at least that's all I'm gonna use it for.

The idea of having HTML as a GUI system is fantastic; many of us can slap together a HTML page in no time while writing a complete GUI system could take forever. I've tried a couple of solutions in the past to make HTML work with LE but none of them supported JavaScript (needed for swapping pictures) and/or CSS. Haven't tried Awesomium, will look into it.

@ Red Ocktober: As I understand you're making a submarine game so water is probably a big concern Over here: http://developer.leadwerks.com/SDK/ you can still download version 2.24, I believe all the old (Blitzmax) water code is in the BMX/Framewerk directory.

I've been busy with real (as in: boring) work for a couple of months but am now using LE again. I personally like the direction LE has been heading towards since 2.3 very much. I didn't see much need for Lua before but it has made the engine really flexible. The Editor already HAS the potential of being a point and click game maker. It's up to the community now to create instantly usable characters/models/scripts: there's nothing stopping it from being as easy to work with as FPS Creator for instance (but much more powerful of course).

In UUnwrap 3D: open your model menu Create->box, make it large enough to be always visible, uncheck replace scene. Create a transparent DDS file (transparent.DDS) Select the box on the right (Groups, box, select) Right click on materials, Add Select transparent.DDS as the diffuse map of the box. Now create the transparent.mat (you probably need some combination of mesh_skin/alphatest) Good luck!

Why not simply create a terrain texture with a border?

1. Maybe your model is not centered in your modeling app. I've seen this behavior before when I used models that are not centered, the engine/camera sometimes thinks the model is out of view when it's not. 2. If not, you could try a workaround of creating a transparent bounding box. (not a very elegant solution though) -- Edit: Your model is probably animated by the looks of it. It could also be the engine is just taking 1 frame of this animation into account, if in this frame the arms are down for instance, they might not show because the model is not in view during that single frame.

I am trying to change the vertex information of a model in LUA, I'm trying this code on the model to try and find out which surface I need: require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) Print ("model") Print (CountChildren(model)) Print (model:GetKey("name")) Print ("ob1") ob1 = GetChild(model, 1) Print (CountChildren(ob1)) Print (CountSurfaces(ob1)) Print (ob1:GetKey("name")) Print ("ob2") ob2 = GetChild(ob1, 1) Print (CountChildren(ob2)) Print (ob2:GetKey("name")) function object:Update() end function object:Free(model) self.super:Free() end end The first child is called "U3D_MESH" which sounds pretty promising. It doesn't have any surfaces though, while loading it with GetChild(LoadMesh("mesh.gmf"),1) in BlitzMax does work. When going deeper into the model it's returning bone names. Any ideas? Thanks!

This is looking really good, nice job! I think the running animation would look better if it was played a little faster.

Since this has turned out to be a feature request thread I'd really, really like an export function of the terrain composite image to a large (4096x4096) DDS. Terrain menu button -> Edit -> Tab composite -> File -> Export should then have a DDS option. Using this image one could effectively mimic having unlimited terrain textures. Thanks!

Just posting here to find this thread again once I have time to test this myself. Really interesting.

It's very cool you're working on vegetation collision Josh When I first saw the new "blend mode" I thought this feature could create a base layer that has the other layers painted on top of it (like http://leadwerks.com/werkspace/index.php?/topic/143-combining-textures). It doesn't seem to do this, but I did notice that terrain->Edit button->Composite does show a composite picture of the current layers. Could you please add an export function for this composite image? (reason being to be able to use unlimited terrain textures) Thanks!

Hi there, I can't seem to find how to interact with LUA using Blitzmax, the function "GetLuaState()" as seen in the tutorial doesn't seem to exist in Bmax... I can see the lua scripts are working fine (my models are being animated for example), but how do I pass arguments from my Bmax program to the current lua "session"? Thanks! EDIT: sorry found it: luastate.L

You have way too much time Marleys Ghost! In all fairness: using the vegetation tool for collidable objects is just for us lazy programmers. A level designer would probably rather place objects manually, giving much more control and yielding no collision issues. But the awesome auto-lod feature is now more or less useless, and that's a pity. Any of the following solutions should work: - having collision + vegetation layer - having a command SetModelBillboardDistance - having a separate auto-lod tool that can turn myobject.gmf into myobjectLOD.gmf

"You would never be able to render 100,000 trees using the conventional entity system." That's highly understandable, but it sure would be nice to have both collision and the automatic LOD function working together, either by using the vegetation tool or by manually placing an object.

"Do we have a fix to support the collisions on trees? this would be very helpful, also is there a work around?" If you can decipher the vegetation.dat file, you could place your collision objects with code. But otherwise, the vegetation tool shouldn't be used for objects that need collision (e.g. trees) "Still working on understanding this but is is not possible to just define the mesh as the collision object?" Not using the vegetation tool. With normally placed models, you can have any collision object you like, created with the phygen tool. When placing a model without a phy file in Sandbox, the engine will try to generate a phy file based on the mesh.

Thanks afecelis!

I know an undo function can be hard to program. On the other hand, it's a real pain not having any kind of undo. My vote would be to have the editor save a version of the sbx every time you switch tools/functions (e.g. switch flatten terrain tool to vegetation tool). Pressing the undo button (or ctrl+z) should then revert to the last save before switching tools. This should be fairly easy to implement.

I've seen similar behavior after trying to save with ctrl+S. When hitting S again and immediately releasing it (or ctrl, can't remember) the editor started working again properly. In that case, the problem probably has to do with keyup() not being registered. But if it only occurs at framerates > 100... Run the editor in 1920x1080, turn on all posteffects and jam more stuff into your scene

Couldn't this be a driver problem, that NVidia isn't updating your card any more? Your card should be better than my NVidia 9600M GT, but that runs the Editor just fine...

The server always should have the final word, eg: People who travel too fast or make impossible shots should be banned. When using 32 controllers you will inevitably encounter differences between players, and then what? Multiplayer gaming must indeed support lag. But I never said/meant to say that a static player should be sending data to the server. Vectors can indeed be sent, many other things as well. However, I disagree the server should send data less often. IMO, the server should send MORE often because you'll be using the UDP protocol and don't know whether players received the data package.

As long as the recommended card remains a 8800, I see no problems there. This has been a recommended card for over two years now for many games. FPS can never be too high though, so any improvement there using multithreading is welcome. If you're talking about a multiplayer game, you won't have 32 players on the same computer so you won't need 32 controllers. You'll probably need each player to send his coordinates/rotation to a server, and the server on each update will return the coordinates/rotation of the 31 other players.