[Leadwerks Engine 2.43 Released]

No, because

Can the new DrawEach() be used to paint different skins on player vehicles you think?

That won't work. It would be just the same as if you had applied a material outside the render call.

[Leadwerks Engine 2.43 Released]

It's a callback that gets run when the entity is actually culled in the rendering process. Once it is determined this entity is visible, the Draw() and DrawEach() functions will be called. (The Draw() function only gets called once per render, so it won't be called again if an entity is rendered by two cameras or two light sources). This is useful for animation, because you can perform animation only when you are sure an entity is going to be drawn.

[Leadwerks Engine 2.43 Released]

There's an object:DrawEach(camera) function you can declare in Lua. I recommend the object:Draw() function for animation, since it will only get called once per render, and DrawEach() can be called multiple times.

[Leadwerks Engine 2.43, advanced optics, and more...]

very nice. do i haveto run photoshop everytime i want to use color grading or cani do it within the editor too based on somesliders or values?

I don't know yet. Real-time feedback would be nice, but there's also a lot of ways to produce these with Photoshop etc, that might be superior to poking around with color curves. For example, it would be trivial to make a black and white color table in photoshop, but I am not sure how you would do that with RGB curves.

 

How frequently do you think the color grading will need to be adjusted? Is it sufficient to include a dozen or so lookup tables for the most common looks you might want to achieve?

[Lua and C++ Debugger]

Yeah, it's a weird time right now. I'm making a lot of progress, but the finished LE3 is still miles away. This has sort of taught me why software companies usually keep adding to their existing product until they become totally unmanagable, rather than starting new IP. There never really comes a time where starting something new is profitable in the short-term, so it just keeps getting put off.

[Tools and Stuff]

Would be cool when importing assets, if we could set its scale to a fixed size say 1m high, then scale to our desired size before converting to gmf, like a character we just can scale it to 1.8 etc.

Yeah, that is in the design spec.

[Too Cool]

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.

[Small Victories]

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

[Summer Events]

I don't know how the videos should be laid out, so I just left it as is for Tom to do something with. I don't like the big grid of thumbnails, but I don't know what exactly should be done.

[Summer Events]

Advertisements are a big turn off for customers. If I see a web page with ads, I close it. Look for example at Mercedes-Benz, Ferrari, Lamborghini and Yamaha. They don't advertise, they don't need it. Leadwerks should be in the same high quality class, because it is. Sure, they have maybe 1 grand advertisement per year or so, and that's it. No spam.

I'm inclined to agree, for the majority of the site. However, the video gallery and possibly blogs are more of a "consumption" oriented page, so I think that situation is a little different. I'm curious to see how it does, anyways. If it feels wrong or isn't successful, we'll drop it. The only thing I require is that the ads be relevant, which is why Adsense is out of the question.

[Summer Events]

In fact, I have plans beyond this I have not laid out here. In a few months I want to start playing with the games portal idea. If someone made something like this, in 3D, it would be perfect for trying the idea out with.

[A second look at entity scripts]

The idea is we might be writing a rocket script right now, but some time in the future we might come up with an entirely new entity behavior that we want the rocket to interact with, without altering the original rocket script. Maybe I'll want to make a special button you shoot to activate, so it has to detect when a rocket hits it.

 

A good case could also be made for having two scripts attached of the same type. A lot of oscillating and gradual motions might use two or three script attachments of the same type, with various settings adjusted to produce a combined output. For example, my vegetation waver code is the combination of a few different sine curves with different frequencies and amplitudes. You wouldn't want to do that in a script, but that's an example of the idea.

 

Each script could just be appended to the end of an entity.scripts table, in which case you could just do this:

for script in entity.scripts do
if script.Hurt~=nil then
	script:Hurt(5)
end
end

Then you could just call the function for all attached script, without knowing or caring what other scripts are doing.

 

I need to come up with some more usage examples and see how they would work out.

[A second look at entity scripts]

If that were the case, we'd be looking at something like this for the mover script:

function script:Start()
self.movespeed=Vec3(0) end
self.turnspeed=Vec3(0) end
end

function script:UpdateMatrix()
Print(self.entity.position.x..","..self.entity.position.y..","..self.entity.position.z)	
end

function script:Update()
if self.movespeed~=nil then
	self.entity:Move(self.movespeed)
end
if self.turnspeed~=nil then
	self.entity:Turn(self.turnspeed)
end
end

It's not bad, although the extra .entity table is not preferable.

 

Let's say you have a rocket script, and it collides with some entity. If all functions were stored on the entity, you could do this:

function script:Collision(entity,position,normal)
if entity.Hurt~=nil then
	entity:Hurt(5)
end
end

But if all information is stored in script subobjects, you would only be able to interact with some classes:

function script:Collision(entity,position,normal)
if entity.player~=nil then
	entity.player:Hurt(5)
end
end

[A second look at entity scripts]

I considered something like that, but I'm not convinced it's that great::

function door:Open()
self:Turn()--Oh wait, we can not do that, because this is the door...

--What if we say "entity" is a value in "door"?  It would be entity.door.entity:
this.entity:Turn()--Okay, this works alright
end

function door:Update()
this.health --wait, that does not work, unless you want the value contained within "door", in which case GetString("health") would not return it
this.entity.health = 100--okay...
end

It seems like a lot of mess for something that is supposed to be as simple as possible. I really do not like the infinite recursive loop of tables.

 

I suppose you could do something like this in C++:

entity->SetInt("door.openstate","1")

Which doesn't look too bad.

 

Of course, you could simple add a prefix to all your functions and attributes you don't want messed with, and achieve the same exact outcome with a lot less complexity:

function entity:Door_Open()
this:Turn(1,0,0)
this.door_openstate=1
end

[A second look at entity scripts]

I've got iterators working, so you can do this:

for child in entity.kids do
Print(child.name)
end

Unfortunately, the Entity returned by the iterator does not match the lua object the main program uses, and so you can't set attributes from the main program and detect them elsewhere. This is pretty complex stuff.

[A first look at entity scripts]

That would be really cool.

[A first look at entity scripts]

I know you like the idea of programming with a visual designer, and it's a cool idea, but I don't think the outcome would be as good for my users. I think complex behaviors should be programmed and then combined and linked visually. I'm sure we'll learn more as time goes on and we see these systems in action.

[A first look at entity scripts]

So your scripts would require input/output. Like your button would require to fire an event (which I assume would be checked inside it's Update() method), which you can then attach to the doors Open() method (for example).

It might be possible to make Lua automatically execute all outputs when a certain function is called. Otherwise, you'll just have something like this at the end of the Open() function:

CallOutputs("Open")

 

This can be extended in the future to take function arguments.

 

The flowgraph isn't really about programming though, it's about connecting objects to make events occur.

[A first look at entity scripts]

You could call Open() and Close() from other scripts, or from a C++ program (something like entity->CallActor("Open")) but I think we've found none of those approaches really make game interactions very easy. You generally don't know what functions other script objects have, and making generic "Activate" and "Enable" functions for each one doesn't seem to yield very good results, either.

 

My primary concern for Leadwerks Engine 3 is that historically, with every 3D engine or game creation system, only about 10% of the users can successfully create game interactions with them. Then there are ones that make it easy to do a few pre-programmed interactions, but very few can make anything of their own and most end up with very few changes to the original. This is a huge problem.

 

So keeping that in mind, the main way to access the script functions of an entity is through the flowgraph, which I will show as it develops. You script your behavior, attach it to an entity, and then you can control the way things interact visually. There's no guessing what the door's functions are, or checking the script, because it appears right in the flowgraph editor, so it's obvious. So you have a scripted button, and this scripted door, and they can be combined without even looking at the scripts. So right off the bat, a non-programmer can control interactions in a way that's beyond what most programmers currently do, including myself. It's not like it's hard to program that specific behavior, but without a general interactions system, it's just so much trouble that you generally don't bother to do it. The idea in LE2 was that the script function for SetEntityKey() could be used for this kind of functionality, but I think without a visual display of everything you have access to, it's not much fun.

 

This also opens up Leadwerks Engine to a new category of users: designers. They can take place objects in a scene, attach scripts, and set up their interactions without looking at one line of code. This is actually pretty efficient because a script programmer can design different behaviors, and then give them to the designer to produce a level. I think this will also facilitate code sharing. Sure, I can program my own stuff, but it would be cool to just download a useful script and play with it, knowing I'm not going to have a bunch of incompatibilities or requirements.

 

I plan on providing some generic "mover" scripts that handle movement interpolation. You just set a few values in the editor the script handles the rest.

[Leadwerks dedicated server]

It doesn't need a domain at all, I can just go to the ip address of the server.

[Louie, Lua]

You can download a test with the lua debugger here:

http://leadwerks.com/werkspace/topic/3193-le3-lua-debugger/

[Louie, Lua]

Something like that. Right now it is like this:

Message* Client::Update(const int& timeout=0)

 

But a callback might be added, or you can add your own and run this command on a separate thread.

[Louie, Lua]

It should appear in a message, where the message ID is something like MESSAGE_CREATEENTITY and an extra parameter gives you the entity that was created.

[Louie, Lua]

You only need to call sync once, and thereafter it is automatic:

 

Entity::Sync(Server* server);

 

Then you can do whatever you want, even delete the entity, and it will be automatically updated in regular intervals.

[Louie, Lua]

What's sync'd about an entity? Postion, rotation, scale? Anything else? There is generally more to what you'd want sync'd than that. Ammo count, health, etc. These are generally things that would be stored in a class. If we wanted to use this syncing method you have would we have to use entity keys for this data and have that get sync'd?

Position, material, color, keys, etc. One way to sync info would be using entity keys. As far as syncing entire classes, the best bet is to send a raw data packet.