Rick

What would be the harm to just make all headers pre-compiled?

I have been asking for this for a long time. As far as I know it doesn't. Unless Josh added this in the last 3 months. Not having this functionality hurts because it makes triggers in Lua very static. ie. you can't create a body in Lua directly and get collision notification via a callback.

Yeah, I just thought that headers were only compiled if they changed by default too. I guess not.

I thought VS handled only compiling files that have changes in them by default?

If you are using C++ then it's a nice feature to use SetEntityData and GetEntityData, where you assign your class to the entity so you can retrieve it in the collision method.

Like Pixel said, if you implement this so you can use it to create a C++ version of LE 3, then you might miss some C++ advantages over BMax (because it seems clear that that's the syntax you are leaning towards in your example). From my understanding there are certain features that C++ has that BMax doesn't. I don't think it was a large list but there could be something of use in there that might not be considered because of this BMax like syntax. Clearly you've made up your mind though. Good luck. It'll be interesting to see how it plays out. My fear is that this new language turns into a monster of it's own and starts influencing the engine design. I haven't either, but I haven't heard that about Lua either, but Josh mentioned that he was removing ini files eventually meaning that all those configurations for the objects in the editor have to have Lua files in them to work correctly in the editor. Is it mandatory, no, but unless you want to write your own editor you will be stuck with it. Lua started out with this same idea of being optional, but slowly over time it starts taking over certain aspects. If Josh ends up loving this new language are we really to believe that it won't work its way into being (realistically) mandatory at some point to some degree? Given past record I'd say at some level around the tools, it'll be "required", just like Lua is "required". That's my fear.

OK, if Josh could describe the point of this new language we can better decide on what we think about it. My first reaction to a new language is almost always don't do it since there are very efficient languages out there already. Just learn those. Creating another language that will compile to another language just says to me that someone doesn't like working with said language.

Interesting enough, the tools could BE the engine.

I think it's a bad idea and you should just use C++. My first reaction to your example in your blog post is that clearly you are more comfortable with BMax and so you are trying to make a converter for yourself so you can code things in a BMax like syntax. If there is any validity to that, then honestly just learn C++. You are a smart guy and C++ offers a ton of flexibility and you would benefit yourself by learning it inside and out. The time it would take to write a converter would better be spent learning C++. As far as less typing, on the users side (us) the amount of typing we do depends on how the API is setup. This can be seen in the way you setup the current API (very easy to use and not much typing) vs something like the DirectX API (complex and a ton of typing). My thought is that introducing something like this is really going to lead to more trouble than it's worth. It might not look like it at first, but I think there are a ton of hidden issues that will come from this and that'll take time away from what's important. [EDIT] Your example doesn't seem to really show any sort of benefit also. I know it's just and example, but if you are trying to show us why this new language would be better, you should have an example that really shows this. [EDIT2] Also if you were to do something like this, which I don't agree with, then really make it shorter, something like: Cls Vec3 { pub flt x, y, z; } Then again most of this stuff can be accomplished with Macros in C++

Hence why not taking the startup capital was a bad idea. If he had, there would be more people to support stuff like this.

The short answeris No, you can't do this. To see instant results in the editor it needs to be in Lua.

Yeah the locomotion system is amazing. Since the guy gave it away for free with Unity, does anyone know if there is a C++ version of this? Would be sweet to bring this into LE.

I think you can use a buffer. Gamelib does something like this for name tags over players heads. You might want to check that out because I seem to remember you not having to save it to disk in order to see your drawings.

As I'm thinking about this, and messing around with memory sniffers, I think one would have to someone add the TEntity value that gets normally returned, to some kind of list on the main thread. I assume the main thread has a list of these that point to the internal storage so it can act on the data. Not sure how one could do that.

I know at it's heart it's a character pointer, but is it basically an ID that the API uses to track objects? If so I assume that ID is stored somewhere by the API so it can easily find these objects when we call API functions and it needs to do something on them?

Ideally, it would be nice if we could get a pointer for any loaded entity. Some kind of function like, GetEntityPointer() so we have the memory address to start with. Then if we could get a detailed description of the memory structure for each entity. If we had that we should be able to do some cool things. You could get the entity for texture and/or material on a loaded model. Then from that you could call this GetEntityPointer() method to get the memory location of it. Then use that types memory layout to copy it. There has to be a way to get this information, with some kind of memory sniffer and some trial and error.

There must be a way to hack around this, so we can have access to all objects created (without storing it ourselves).

I agree with this, and honestly it should be as easy as copying the memory from one thread to another. This must be possible. If someone knew how to sniff around memory they should be able to figure out the structures of these entities and be able to get this going. I would assume one you knew the memory structures of say a Mesh and all the related memory structures needed around it, you would be able to copy that memory from one thread to another.

Technically, this is an entity test, and not all entities are blocking. It could be a pivot, which doesn't have any blocking thing. Could be a light source, or other non blocking entities.

Yeah, it's done in Lua code. It can be done, but it's not as easy as in Unity. Yes, you can display 2D images.

I actually meant in any generic .NET application. There must be a way to get all and any objects create since the garbage collector knows when to free an object, it must have a list somewhere.

It's easy to use the given post-processing effects. Implementing your own will be more difficult. Yes, but this is basically true for most engines. LE doesn't have prefabs in the sense of Unity. You would have to create your own prefab system. Not very long. The API is very easy and fun to use. No it's not. LE doesn't have built in GUI like Unity. There are a few, what I would call incomplete, community GUI's out there, but most people here roll their own. There is a level editor, so not everything is from code. The learning curve is very easy with Leadwerks. However the development cycle is higher than most other engines because most systems are left up for you to develop. They aren't given to you like in the other engines. Prefabs & GUI being examples. Leadwerks is probably one of the best looking engines out there. It's easy to program with, but the tools aren't very mature when compared to other engines. If you are a programmer who likes to create their own tools or an artists who likes to have nice looking scenes, then Leadwerks is great. If you are a game designer who wants to get a game up and running fast then Leadwerks probably isn't the best choice when compared to the others. The price is hard to beat though.

Which is why it wouldn't be done that way The methods won't have to be static. They will be able to be part of an instance, and the programmer will have to assign an attribute to that method and derive that class from a specific class in order for it to be callable. RPC is basically hiding message sending (the "normal" way of game networking) with some setup. The parameter will be a RakNet BitStream object and the ip address of who sent it.

You are right, but if a library encapsulates all the hard UDP stuff for you, then why not just use 1 library for everything? That's my thought on it anyway. Either way, I'm trying to make it even easier by being able to "call functions" on the remote machine instead of sending messages directly. That should make things slightly easier. Also need a replication system too. .NET should help a ton with both of these with reflection.

Does anyone know if there is a way to get all created objects? Like let's say for example I instantiate a class, instead of me storing it off, is there a way with the framework to get a list of objects that are created and in scope? Ideally I want to be able to loop through a list of all created objects and see if they are of a certain type. I just don't want to have to store this list myself and if there is a way to get the data with the framework them that would be ideal.