Rick

That's what has been done up until now and it hasn't worked out all that well, if you haven't noticed. The whole point is to get support from Josh and not someone who will leave the community after making their wrapper.

The question on the table is more around trying to get an officially supported .NET version that Josh, not us, doesn't see a problem with. The creator of the library we are trying to bring to another language has some specific requirements that he's asking for in order for him to put his name on the port and officially support the product. His requirements conflict with the C# ideology but can be done with C#. So should we throw our hands in the air and stomp our feet and refuse to meet his requirements or should we take the opportunity to help bring a stable C# community to LE and meet his requirements so he officially supports it?

Elitist community? You are hanging onto this .NET ideal world. If the library was created specifically for .NET then I'd say by all means, but due to documentation constraints, multiple language support, and consistency requirements (real world issues) you have to bend your ideal .NET world to fit this world. You are simply refusing to budge on something so small as properties or get/set methods. Is it really that big of a deal? You have to get your mind out of the classroom and into the world of "things are rarely perfect so you have to bend the rules sometimes". I think it would be a shame to lose you on the .NET side, but you have to be willing to meet 1/2 way with some stuff.

You could learn Lua. It's easier than most languages to learn and LE supports it. It won't give you the networking you desire really, but you could get some functionality yourself if you learn it.

Yes, as a programmer it's one of the easier libraries I've used. As a non programmer it's probably not the easiest but you can still get nice looking scenes which are static. I would use RakNet for the online features you want, but there are other external networking libraries like SDL also. LE's networking commands are kind of green behind the ears. It's a great engine with a great community, but it does require coding a good chunk of your game systems. Pathfinding being one of those for example.

Lazlo, I think you are getting to caught up in .NET politics. Nobody but syntactical .NET snobs are going to care about having get/set functions over properties. Anyone who deals with non .NET libraries knows that whatever you get goes if that library wasn't design specifically in .NET. Josh is telling you that if you make C# look exactly like LE 3, he might sign off on it and you are basically saying no, you won't budge on some design options? Take what you can get so you get something functional. Are you trying to create the perfect library or are you trying to let the .NET community use LE? Pick your battles. You would define a rule. You would define the rule of how you want the C# to look. You could say "we use get/set, deal with it". And people would have to deal with it or make their own wrapper. I promise you the majority will deal with it. They might ask why, but they will deal with it because at the end of the day they are using .NET because it offers so much more that they can now integrate with LE. Do you know why I use .NET? It's not because I give a **** about properties over get/set it's because of it's reflection which helps me create easy and scalable scene loaders. It's because it's threading is so simple that I can do non LE stuff like pathfinding with it. It's because of how easy it is to use databases with it which I will use in my game. It's not about what LE looks like in .NET, it's about just getting it to work the same way as it does in C++ and now I have more/easy options to complement my game.

So if we were able to get a Mono version of C# working you would support it? Mono is not Windows only. You are this week Seriously anything .NET related to LE has people coming and going all the time. No offense to you since we don't know you, but when you see it over and over again, it's hard to think otherwise. Without the proper support from Josh it's always going to be this community effort that just doesn't get much traction.

This is the internet and I've found that you almost always have to put "I think" or "In my opinion" around things that are not generally accepted as fact by the majority of the population otherwise people seem to always read it as if you are stating fact. Probably just human nature when reading comments and disagreeing with the idea. I know. I shouldn't even be getting into this discussion because it's not going to lead anywhere productive For some reason it's just to easy to get into a talk with Mika about his claims being so crazy and off the wall.

Which is generally why nobody makes such a chart. This is fine as long as you don't generally present the chart as fact. You might want to say, "here is what I think" and not give the impression that it's some kind of fact based research.

Sorry, was referring to Josh's script he posted above which had some undefined thing to it yet. @Afke I'm all on board with the if's, switches, etc. That will all be there. About LevelLoaded, OnUpdate and such, that is more higher level than I'm thinking currently. With the tool I'm building you would be able to create those yourself from the more lower level LE commands. Now with hearing how Josh is planning on Lua for LE 3 I think it'll shift into using flowgraphs to generate these actor scripts that you can then attach to entities and then link them via Josh's flowgraph. So for example the script Josh has above could be created in my flowgraph system visually instead of having to know Lua. My flowgraph system goal was always to be LE oriented and if this is the direction Josh is taking for LE 3, I'd really like to get an early jump on helping people make these actor scripts visually. Once you've created an actor script via my flowgraph, you can then use the LE flowgraph to make the links between other actor scripts. I think even programmers could benefit from this because you don't have to worry about the Lua syntax, but instead more focus on the logic you want to create. I was asking if Josh had a more final version of how he wants these actor scripts though so I can actually start with the Lua code generation now.

Do you yet know what a script like you have above is going to actually look like yet?

Like Lumooja said LE is actually written in BMax not C++. LE 3 will be C++ so yeah you will be faced with the same thing you had before if you make your own wrapper now. LEO, is again, a community supported C++ object oriented wrapper to the C LE interface. I've never used it because some of it's designs I'm not a fan of. Honestly, I don't know many people who use it. There aren't to many posts about it so it's hard to judge who is using it.

I'll shift my flowgraph design I currently have to be more "actor" oriented where you have an Update and Start method by default but allows you to create other methods and that's where you put your LE specific Lua code (visually of course) and it generates an "actor" script. That "actor" script could then be used in your flowgraph to make the connections. I'll use your above example as a proof of concept and see what I can get. What you have above still seems kind of not global, like your first Lua implementation before you made it so other objects could see each other. The way you have, for example, the movement variable seems global to the Lua state and not to this script, so if anything else used movement it could screw it up. Do you know yet how you are going to handle that? It would seem this script itself would need to be it's own class (table) definition in Lua, so you can have variables that aren't global but local to the class.

Since it's community driven the people who have developed the .NET versions of LE come and go. First it was Tyler and everything looked great. Then he left the community to do other things and it pretty much died. Then I think it was Lazlo who came and took it over and made some modifications I believe. He left the community also at one point so that died. Then Roland came along and wanted to make a 3 layered version. He made LE.NET which was meant to be as close to the C headers for LE as possible. (this is the what I use and I love it because it's very very close to LE in C++). Roland then started on his version of the higher level (more object oriented) version that was to be built on top of LE.NET, but then Lazlo came back and they both started working together but eventually Roland moved on as well. At this point there still is LE.NET but it's not being updated (not sure it needs to though as it seems complete to me, but new LE versions won't get updated by anyone). Lazlo pushes Leadwerks.NET at this point as it's kind of his baby but it's more an object oriented version. I have seen Lazlo around all that much these days but I'm sure he'll try to answer any questions but he could disappear like he did before at the drop of a hat. So that is what I mean by "The .NET environment in LE is not the most stable." I'm sure there are some inaccurate pieces above but that's the main idea. People come and go that create their versions of what .NET for Leadwerks would be. Leadwerks isn't object oriented currently so there is an interpretation that needs to happen to move it to .NET and everyone has their own idea about how to do that.

What compiler are you using? I did this with VS 2005 pro and it worked perfectly once I changed to !empty(). Some implementations of the stl might be slightly different maybe? I assume your entire code is huge? Otherwise post it and we can try it. Might be something going on somewhere else.

Are you sure it's failing on the push_back statement? If I put that code in it fails on States.back()->Destroy(); because I don't think the NULL check you have it the right way to check if the vector has items or not. Do something like if(!States.empty()) instead. Once I do that, this all works for me. I assume you are stepping through your code to see what values are and such?

Interestingly enough the complex behaviors could even be programmed visually, but that doesn't need to be your system. I think that would fit into what I'm doing. It would just generate lua code which could be linked into your flowgraph system then.

That's pretty much programming though. Without taking it to that next step you aren't going to end up with much different then you do now. You'll just have more doors opening and closing which isn't all that exciting. With each LE version you take it slightly further inevitably (the way I see it) ending towards a flowgraph for everything. You should take it there now and not wait until LE 4

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). That seems logical, but sounds like your actor scripts are going to require an output mechanism which at it's core is probably just a table that holds functions (all the inputs tied to an output). Also think about functions that may need parameters and how to handle variables that one might need.

That seems like the way you would do something like this so I don't think it's an idea killer really.

I assume Start() and Update() are called by the engine and that Open() and Close() would be something that the user would have to call from other entities? If that's the case how would we make those calls since this is actor "class" and every script, from what you've described, would be an actor "class". How would we differentiate between scripts attached to specific objects to call their specific functions? Also, possibly off topic but specific to this situation with no physics involved, you might want to get a tweening library built into LE. I worked with iTween which is a library some guy created for Unity which he gives away for free and it makes moving stuff like this, non physics stuff, amazingly simple. I don't think there is any reason it needs to be tightly bound to an engine so you might want to talk with the guy to see if he can convert it to lua for you? http://itween.pixelplacement.com/index.php All that code you have for doing this could be condensed into a few lines (possibly 1 or 2) with such a library. Believe me your users (especially the non programmers and really even the programmers I guess) will love you for doing it, and scripting interactions would be so much easier.

You're delusional Lum!

Sorry, I meant the level editor. Assuming lua is working sort of the same as it does now, when you run the game it executes lua scripts. If we could place break points and step through the main lua script and the attached scripts that we can do in LE3 and see that result in the level editor that would be cool.

Very exciting. Do you think that you would be able to actually see the result in the editor once it's all put together?

Exciting. Is that in an update we can test? Would love to see this in action.