ZioRed

Delete the "." at the end of his link Here

Ok 2 tutorials released (I adjusted their icons to better fit the current layout, a 64x64 icon centered in a 128x128 transparent background). It is a pity that I cannot attach a source to the tutorial #2

I have added 2 tutorials in the C# section but I don't succeed to attach files to them, I'm trying to attach a sample project compressed in a .ZIP to the tutorial "#2 rendering lights" but the links to download don't appear and it doesn't give me any error during save. Q_Q

Here

You could have a hand by the community who use languages different from C++ and Lua. Ok I'm going to convert all your official C++ tutorials to C# and add them to the new tutorial C# section (you missed the image, and if you can change the image for all languages with their own official icons should be nicer and may be "Script Programming" changed to "Lua Programming" is also more intuitive ) and I'll attach also PDF and sample project too. PS: Can I use the same text and images from your official PDF? Of course I'd cut your copyright info.

Clicking UPDATE SDK on LE's group in your "PROGRAMS" start menu you can choose the version to download (you should download any version in its own empty folder).

EDIT: Lumooja already posted the answer...

This option is pretty a standard in any kind of text editor and I agree it, this post should be moved into Feature Requests

Bella lì! Developer (if you need add me to your MSN/Skype), see my signature

Who are not interested in source code may wish to download and use a pre-build library, which you find in the Download section of the project site (the pre-builds are generally updated at each version/revision change).

lol I think to know enough the differences between C# and C++, but since my "LE language" is C# then I could be interested on writing some tutorials for that and I doubt its correct category would be "C++". Well, if I will be interested on writing some C# tutorials I will request a C# category.

Nice, but.. I cannot see C# in the "Programming" section and I think there should be since we have a C# community which seems to be active (at least me and few others Q_Q).

Your name sounds like italian... are you? ..if it is: Benvenuto!

I'd like Klepto to join the Commit Members on our official SVN and works with us and with the same code so he can personally apply updates instead of working on its own control (even if it's the same as that released on SVN)... just to work all together PS: In the download section of the project there is now also a link for a pre-build version of Leadwerks Controls which contains LETKControl (and eventually will contain new controls if any)

Right click on the folder in which you would like to checkout your SVN working-folder and choose this URL as checkout URL: http://leadwerks-csharp.googlecode.com/svn/trunk The solution and projects have Visual C# 2010 format. To succesfully build the solution you should set NO BUILD for the "Test" project in the build configuration or manually copy the engine DLLs and shaders.pak in the "Test" project, else you will have errors during its build.

May be you missed something from macklebee? Try to set the EntityType of the entities to "1", set Collisions(1,1,true) and finally try the EntityVisible with "1" as entitype of raycasting. Collisions(1,1,true); EntityType(ent1, 1); EntityType(ent2, 1); int visible = EntityVisible(ent1, ent2, 0, 1);

Forms_Test are not more part of SVN and the control has been renamed under the Leadwerks.Controls namespace. However don't count on the test projects, since they are only test. I say: rename your current solution folder to ".BAK" and download from SVN (may be you had your solution file changed so TortoiseSVN didn't update it). There is only a "Leadwerks_Console_Tests" as test project (haven't tried it. All the Leadwerks.Game, Leadwerks.AI and Leadwerks.UI are still in development status (or better in "project" status) and are unusable at this moment. If you're looking at the Control than it has not been modified since our bug reports. We could create specific version folders inside "branches" when we release a new version and that should contain only what effectively we're releasing (for now only the wrapper and the Control, which according to me is still more unuseful due to severe bugs).

@Rick: How do you create a GUI panel which must have 2 or more buttons since all the buttons have type "ComponentGuiButton"? I think that the Component itself should decide if it cannot be attached multiple times. Another example is the chain of "use ability" which I talked about, like "Dark Age of Camelot" in which you hit on some buttons from the quickbars to perform some ability action and the game add every action in a queue and do in sequence.

It's a component itself and each component can own more components into it.

Storing only one component per type is not so flexible... i.e. how could I create a chain of actions (cast abilities or also more animation sequences) to my toon? Or group more meshes? I would consider into turning to component's name as key for the Components.

Nice you are mostly done, these are some suggestions from me if you like.. Optional owner parameter in the Component.Component constructor to avoid "new Component.Component(null)" in favor of "new Component.Component()". You could save the developer from having manually add a component to its owner after creation, since you are passing it in the constructor than you can automatically add this to the owner's Components directly from the constructor itself. What are the keys you used in your Components dictionary? I thought it was the name of the component, but you haven't assigned "Component.GUIButton" as name of "button". For the loading from DLLs and reflection I generally use the following class to allow plugin management in my programs: namespace PluginManager { public class PluginManager { private Dictionary<String, PluginInfo> mLoadedPlugins = new Dictionary<String, PluginInfo>(); public PluginManager( String pluginDirectory, String interfaceName) { ScanDirectory(pluginDirectory, interfaceName); } private void ScanDirectory( String directoryName, String interfaceName) { foreach (String fileName in System.IO.Directory.GetFiles( directoryName, "*.dll")) { AnalyzeAssemblyFile(fileName, interfaceName); } } private void AnalyzeAssemblyFile( String fileName, String interfaceName) { try { System.Reflection.Assembly asm = System.Reflection.Assembly.LoadFrom(fileName); foreach (Type Ty in asm.GetTypes()) { if (Ty.GetInterface(interfaceName) != null) { mLoadedPlugins.Add(Ty.Name, new PluginInfo(Ty.Name, Ty)); } } } catch (Exception Ex) { System.Diagnostics.Debug.WriteLine(Ex.Message); } } public IEnumerable<String> GetPluginNames() { return mLoadedPlugins.Keys; } public object CreateInstance( String pluginName) { return mLoadedPlugins[pluginName].CreateInstance(); } } } Its use (IPlugin is only an interface which you create as you need): PluginManager.PluginManager mPluginManager = new PluginManager.PluginManager(".\\Plugins", "IPlugin"); List<String> plugins = mPluginManager.GetPluginNames(); IPlugin plugin = (IPlugin)mPluginManager.CreateInstance("IPlugin"); Hope could be useful to you.

The best for a 1:1 commands would be if you plan 3.0 as managed library so we don't need any wrapper, as we already talked with Mika and Tyler, and since you're planning to go for C++ I think this is not really a hard task

@Josh: regarding the class properties in C# it works as Roland said, that is a simple assigning of a value and of course you cannot specify more than one value in an assign statement. For your example of modifying Position and for the "presumed" split of a "command", I can agree with the wrapper way of dividing Position from GlobalPosition because I think they are conceptually separate both as values and as mean. This however involves only class implementation and structure due to different point of view. The Position and GlobalPosition properties are defined in this way: public Vector3 Position { get { float[] position = new float[3]; Core.EntityPosition(this.Pointer, position, 0); return new Vector3(position); } set { Core.PositionEntity(this.Pointer, value.ToFloatArray(), 0); } } public Vector3 GlobalPosition { get { float[] position = new float[3]; Core.EntityPosition(this.Pointer, position, 1); return new Vector3(position); } set { Core.PositionEntity(this.Pointer, value.ToFloatArray(), 1); } } To modify the position it works as C++ (more/less): // This way entity.Position = new Vector3(1,1,1); // or this way entity.Position.X = 1; entity.Position.Y = 1; entity.Position.Z = 1; As you see they however call the core EntityPosition with different global parameter, because as you have C++ and LEO way of programming also here you can use only the Core (yes we can rename this class as we like [with Refactoring we can do something like this with a single replace on all the project files automatically] but Engine is already a defined class which handles the Process and Terminate commands) methods (as C++) or OOP way (as LEO). I find the OOP way of the current wrapper very convenient and well organized in its structure even if the commands are not equals to LEO implementation (many things are named and organized in a more human readable form so anyone can easily find what he's looking also without any manual). What first I generally see and try to achieve for first in the code is elegance and readability and not only a bunch of functions to do everything. That's why I generally prefer too (as who first wrote the wrapper) to add an easy to remember and understand named property than remember that one function with a different valued parameter change its scope.

Core is the static class which wraps all the C headers (as I said, there is not procedural programming in C#), any C functions is called statically through the Core class (it contains and exposes all the procedural C functions with same names). For the SetPosition method or property method generally the C# programmers like more the OOP way, that is avoid get/set functions and prefer properties more for code elegance/aesthetics than other, and of course I like this way much more than functions. For pointers question, IntPtr is the pointer type we use to pass to any C function, like Core.EntityPosition(yourValueIntPtr). I thing there is not the pointer concept exactly as C/C++, or at least I never checked/used it

One can ever use Core.PositionEntity / RotateEntity if he doesn't like the OOP way. Personally I almost like properties much more than methods when possible