Josh

The script editor and Lua implementation is very close to being a usable programming environment. You can actually see the pointers to the C++ objects you create, and step through code. It's still missing features, but the parts I was worried about are working. I am adding Lua commands like crazy, and it's easy to keep track of them because they all reside in one header file. The function overloading is great, as you can see in my example here, where I use a single float value to set the ambient light color. There's also a new Camera::SetFOV command. I also fired up the editor for the first time in a couple weeks, and it immediately struck me that there should be single texture, shader, model, etc. editors, instead of creating a new one in a window every time an asset is opened. That and I want to make the interface more like 3D World Studio are the two things I will be working on in the editor. I'm nearly ready to start writing the scene editor. That's not an area of new research, so it will go a lot faster. It's just a lot of work and careful planning, but no more crazy unknown parts that I'm not sure will actually work. All in all, the tools I am using now give me complete control to give you the best experience possible, and I am really happy with Leadwerks Engine 3 so far!

I've got a GEForce 480, and I'm not sure what it wouldn't be able to run. It's monstrous.

Something like that. There's a few ways I can do it. I'm a little worried about the potential for a crash to occur during the pack save operation, but it writes to a temporary file, then renames it when finished, so it seems like the probability of corrupting a package is no worse than the risk of saving a zip file.

What country are you in? We probably have someone around who speaks your native language.

While working with zlib, I implemented the package system, and it turned out really cool. Here's some stuff you can do First, let's load the package and register it in the file system: Package* pak = ReadPackage("mystuff.pak"); //Read the package RegisterPackage(pak); //Register package into file system Read a file from a package, just as if it were on the hard drive: Stream* stream = ReadFile("mystuff/new document.txt"); //Read a file straight out of the package! Write a file to a package, just as if it were on the hard drive: Stream* stream = WriteFile("mystuff/new document.txt"); //Write a file straight into the package! To save your changes permanently in the package, make sure you close it before the program ends: pak->Close(); //Close the package when finished to save the changes This should work in the editor, too, so you can store all your files in packages and the editor will automatically save any packages that change. When a file exists both on the hard drive and in a package, the engine will preferentially read from the file on the hard drive. When a file is written, the engine will preferentially write to a package file, if one is available with the directory the file is being written to. Zip folders and file hierarchy are kept intact. The idea is you can register all your packages, probably with a recursive function, and then read files from and write them to the packages, without knowing or caring whether you are dealing with a file on the hard drive or a file in a package. This is different from the abstract file system, because each file has a precise file path. The only ambiguity is when you have a file on the hard drive and in a package file with the same name, in the same directory. The package file names are considered folders. So if I had a model "teapot.mdl" in a package file "Models.pak" I would load it by calling LoadModel("Models\teapot.mdl"). If you want, you can leave all your files on the hard drive during development, and then let Leadwerks automatically package them up for publishing, and you won't have to change any code to load your files. Once a package is registered, all the file system commands will include them in the file hierarchy, and there is no need to worry about packages at all. If you do write to any, you should close them before ending the program so your changes are saved. My idea I mentioned last time about putting shaders in zip packages and calling the .shd files won't work, because that involves packages within packages, and I don't want to do that. So the shaders are simply going to be left as collections of associated .vert, .frag, .geom, .ctrl, and .tess files, which will be easier to keep track of when editing anyways.

That sounds reasonable. Terrain isn't going to be in the initial release, because it's something I want to devote about two months to.

That should work if you attach the texture to a buffer, enable the buffer, then call that command.

math.random()

Quadros are for rendering old CAD programs. They might work with Leadwerks, but they aren't designed for games. The GEForce series is designed for modern graphics.

Ah, I'm so used to using macros in glsl I didn't even think about it.

The vehicle itself is a joint. The chassis is the body, and you should be able to retrieve the velocity with no problem. You can retrieve the velocity in local space to make your job easier.

There was a bug report filed on this that got resolved.

How is it wrong?

You can't display an order, because the outputs can be called from different place in the script, in a different order: function actor:Activate() CallOutputs("DoSomething") CallOutputs("DoSomethingElse") CallOutputs("MakeMeACake") end function actor:Whatever() CallOutputs("MakeMeACake") CallOutputs("DoSomethingElse") end I am guessing if the flowgraph gets too complicated to understand, you are probably using it to do stuff that should be handled in script code. The flowgraph is for the interaction of objects, not really for coding a single object's behavior.

They would get called in the order the script calls them in: function actor:Activate() CallOutputs("DoSomething") CallOutputs("DoSomethingElse") CallOutputs("MakeMeACake") end

It sounds like you don't have a modeling and animation pipeline, and you are asking me to provide it, but listing a lot of conditions that are dependent on other programs. I would eventually like Leadwerks to take over the whole art pipeline from start to finish (while still allowing external art production programs). If I were to do this, someday, and probably not written by me, it would be a standalone program, not an attempt to improve someone else's product.

If you did it that way, it would be a value you can set in the properties editor. If the Platform has a member "targetentitytomoveto" this would appear in the properties dialog, and you could drag an entity onto it. The flowgraph controls actions, not values. I supposed you could have a "targetentitytomoveto" member in the Platform script that can be edited in the properties dialog, and then the optional argument in the flowgraph could be used to change this. The possibilities are endless. It's just a matter of laying out a foundation of scripts that works consistently and predictably.

GEForce GTX, for sure.

Here's an "If.lua" logical script: function actor:Evaluate(condition) if condition==true then self:CallOutputs("IsTrue") else self:CallOutputs("IsFalse") end end

Visually, with arguments, yes. Then you have a bunch of abstract game logic scripts that move platforms around, open and close doors, perform logic, turn lights on and off, etc. So to make something like a Mario 64 level, you drop in some pre-coded AI , make some moving platforms with the flowgraph, and execute a script that makes a little guy run around. There's your game. Select the File>Publish menu item, package it up, and submit to Steam, the App store, or upload it here. And if you need to modify code at any time, you can always drill down to the script level or even C++ code. So it's super easy and visual without crippling it. flachdrache, your example could be done in script like this: function actor:Update() if onfire==true then health = health - 1 if health < 1 then self:Explode() end end end function actor:Explode() local emitter = CreateEmitter() --do stuff to make an explosion delete self end I don't know if you would want to make flowgraphs for reusable behavior like that. I see it as a per-scene visual script that controls gameplay logic. Remember in the original Unreal Tournament, there is one map that has a room with a weapon inside, and there's a button outside the door that will seal the room and incinerate anyone in it? That's a good example of what I have in mind.

Ladies and gentlemen, here's the money shot. Arguments can be added to the link between actors. In the example below, activating the button will call the platform's MoveTo() function, passing the Marker's property member and the Constant's value member to it. The platform script will then use that position as the target it is moving towards, and move to it until it reaches that point, at the given speed. And that is my idea for how gameplay will be made in Leadwerks Engine 3. The code side of this is actually working. I can set up outputs, arguments, and actor scripts can provide either members or functions that return a value for the arguments. This is only possible because of the flexibility of Lua. It is very adaptable with differing numbers of function parameters and return values, so you can adjust these nodes without worrying about perfectly matching argument types and count.

I don't know about their business plan. I can't even figure out how much anything would cost.

And here's what a flowgraph for the above sequence would look like:

This will reset everything. The shocks bounce a bit, but I don't know if that is an issue: require("Scripts/constants/keycodes") require("Scripts/linkedlist") require("Scripts/filesystem") require("scripts/math/math") require("scripts/constants/engine_const") FlushKeys() HideMouse() local camera = fw.main.camera chassis=LoadModel("abstract::vehicle_viperscout.gmf") carobject=objecttable[chassis] car=carobject.vehicle if car==nil then Notify("Vehicle object not found.",1) chassis:Free() return end chassis:SetPosition(TFormPoint(Vec3(0,-1,10),fw.main.camera,nil)) chassis:SetRotationf(0,camera.rotation.y+180.0,0) --Variables local dx=0.0 local dy=0.0 local camerapitch=camera.rotation.x local camerayaw=camera.rotation.y local move=0.0 local strafe=0.0 local steering = 0.0 local torque = 0.0 local steerlimit = 30.0 local steerrate = 2.0 local steerangle=0.0 MoveMouse(Round(GraphicsWidth()/2),Round(GraphicsHeight()/2)) while KeyHit(KEY_ESCAPE)==0 do --Camera look gx=Round(GraphicsWidth()/2) gy=Round(GraphicsHeight()/2) dx=Curve((MouseX()-gx)/4.0,dx,3.0/AppSpeed()) dy=Curve((MouseY()-gy)/4.0,dy,3.0/AppSpeed()) MoveMouse(gx,gy) camerapitch=camerapitch+dy camerayaw=camerayaw-dx camerapitch=math.min(camerapitch,90) camerapitch=math.max(camerapitch,-90) fw.main.camera:SetRotationf(camerapitch,camerayaw,0,1) local tirespeed=-(KeyDown(KEY_UP)-KeyDown(KEY_DOWN))*2.0 car:AddTireTorque(tirespeed,0) car:AddTireTorque(tirespeed,1) car:AddTireTorque(tirespeed,2) car:AddTireTorque(tirespeed,3) steermode=0 if KeyDown(KEY_RIGHT)==1 then steermode=steermode-1 end if KeyDown(KEY_LEFT)==1 then steermode=steermode+1 end if steermode==1 then steerangle=steerangle+4.0*AppSpeed() elseif steermode==-1 then steerangle=steerangle-4.0*AppSpeed() else if steerangle>0 then steerangle=steerangle-4.0*AppSpeed() if steerangle<0.0 then steerangle=0.0 end else steerangle=steerangle+4.0*AppSpeed() if steerangle>0.0 then steerangle=0.0 end end end steerangle=Clamp(steerangle,-25,25) car:SetSteerAngle(steerangle,0) car:SetSteerAngle(steerangle,1) fw:Update() local campos=TFormPoint(Vec3(0,1,0),chassis,nil) fw.main.camera:SetPosition(campos) fw.main.camera:Move(Vec3(0,0,-10)) local t=TFormVector(Vec3(0,0,1),camera,chassis) a=-math.deg(math.atan2(t.x,t.z))+180.0 carobject.turret:SetRotationf(0,CurveAngle(a,carobject.turret.rotation.y,10.0/AppSpeed()),0) chassis:Hide() local pick = LinePick(campos,camera.position,0.5,COLLISION_PROP) chassis:Show() if pick~=nil then camera:SetPosition(pick.position) end if(KeyHit(KEY_SPACE)==1) then chassis:SetPosition(Vec3(0,0,0)) chassis:SetVelocity(Vec3(0,0,0)) chassis:SetOmega(Vec3(0,0,0)) end fw:Render() Flip(0) end chassis:Free() chassis=nil camera=nil ShowMouse()

Here's a C++ example that makes a button open a door after a delay. I don't recommend setting these relationships up in code, but it does show what's going on under the hood: //Create the button Model* buttonmodel = LoadModel("button.mdl"); Actor* button = LoadActor("button.lua",buttonmodel); //Create a relay. Since no entity is defined, it will just create a pivot Actor* relay = LoadActor("relay.lua"); //Create the door Model* doormodel = LoadModel("door.mdl"); Actor* door = LoadActor("door.lua",doormodel); //Set outputs new Output(button,"Activate",relay,"Activate"); new Output(relay,"Activate",door,"Open"); //Set the delay relay->SetInt("delay",5000); //And now to set off the sequence: button->CallOutputs("Activate");