I really think that I would like to host builds of the community branch and plugins so we can get a wider user base who can't/don't want to compile it all themselves. Unfortunately my only dev machine I have available is my macbook right now, as my other boxes are in various stages of dissolution while I rebuild/reformat/repurpose them.

Would there be anyone interested in supporting me with this by helping to create builds? I can provide an FTP account and the hosting, all that would be required would be the occasional building of the community engine and uploading to the FTP. Anything else, such as posting bugs/issues to github and fixing platform specific issues would be nice, but hopefully can be picked up if more people get access to the builds anyway.

Some other changes:
* MGame also gets ::updateEditor in case you want to process anything in the editor (might be useful for things like showing AI paths and the like maybe?)
* plugin "bug" where it was picking up incorrect plugins should be fixed. Now makes sure the plugin extension (.dll,.dylib,.so) is at the end of the path name
* "fixed" readDirectory to also search for folders within packages, although currently doesn't support the recursive flag
* Added getters for all the C-functions added to the script state as they are needed for properly replacing with an alternative (ie MScriptExt or even maybe a non-lua context)

The use case that I have for this is build a macro for asserts into Maratis which can in debug builds, display a popup which could in theory even trigger an interrupt (INT 3) to give a (possibly) relevant callstack to any attached debugger.

In theory my thoughts would be that it would look as follows:

char* assertOptions =
{
    "Ignore",
    "Break",
    NULL
};

void assertCallback(const char* button)
{
    if(strcmp(button, "Break") == 0)
        __asm int 3;
}

#ifdef DEBUG
# define MAssert(test, msg) \
    if(!(test)) \
        MEngine::getInstance()->displayPopup(msg, assertOptions, assertCallback);
#else/*!DEBUG*/
# define MAssert(test, msg) {}
#endif/*DEBUG*/

Note: not tested this code at all. Just a sample of how I'd imagine it working

we can later expose options/variables in the editor to fine-tweak the behavior

The point I was trying to make was that the "clickable" behaviour was simple and quite generic, but the reaction was not necessarily so easy. As Anaël said though, a linear move is simple enough. Neither the click detection nor the response need any more code, but I agree, it would be the kind of thing that is pretty much generic enough to add built in support for this.

I would go so far as to say procedural anything is exciting. Most of it isn't necessarily useful for release (some is, of course) but it can be a great way to quickly create huge amounts of content with relatively small amounts of effort. There's also the great feature that it would allow people with little to no artistic skill (like me) to create things that are at least vaguely acceptable to populate a game, if the procedural assets then get saved using a standard asset system, artists can then go in and replace the assets, knowing the correct scale, format etc to get dropped into the game and "just work"

There's also the pretty interesting animation system but I think, as that's a standalone application right now, hooking that up might prove more difficult.

Procedural animation is really exciting stuff.
There are some sources in C provided in the archive file, are they for the editor only?

For the pathfinding, like Nistur says, I suggest you look into the Recast lib if you are confortable with c++,
I don't think it would be very hard to use in a game plugin.

If you don't need complex path finding for now (like avoiding obstacles) you can find the 3d coord of the clic with rayHit/getUnProjectedPoint and do a linear move all in lua : http://wiki.maratis3d.org/index.php?tit … ectedPoint

Hope that you can find some time to add it soon, this would seriously leverage the interactivity and possibilities for professional-looking user interfaces.

@Nistur : we can later expose options/variables in the editor to fine-tweak the behavior

With regards to the point and click. The two use cases you gave seem similar but are quite different. They would both use a raycast to find where to move to, but then one relies on path finding, the other just does a simple lerp. Might be worth looking into making a clickable behaviour but then the reaction would have to be bespoke, or at best different for your use cases.

I wanted to add the ability to test a ray using the hand-made raytracing function of MEngine for objects without physics
(I just didn't had time to add it yet), this will solve the previous limitation.

By "Point and click" I was meaning that you use a single click in the scene to move the camera/player to this point (ie target position to reach).

I've been looking into the libs and tools made by Eskil Steenberg during the development of his semi-mmo game Love. Much as I said that it might be best to wait until MGui has been updated, it might be interesting to make a plugin for his "Seduce" GUI system. I realise this does OpenGL rendering directly internally but as the majority of Maratis rendering is done using OpenGL, and ones that don't (ie. iOS) don't support plugins yet anyway, I don't think this is a huge issue Another thing would be to see whether we could leverage the verse support and hook it into the Maratis asset system which would not only get Maratis an asset server system, but also in theory we could then have a more direct connection with all the tools that support the verse protocol. There's also the pretty interesting animation system but I think, as that's a standalone application right now, hooking that up might prove more difficult.

Firstly, I don't really understand what you mean about physics for scene layers. Regarding menus though, I think we should wait to see what can be done with the revamped MGui before trying to do something else along the same lines.

Fullscreen lua function should be pretty simple I believe. I don't see any problem with this.

Point and click, you mean... 3D picking? Like selection in the editor?

Path finding, I think would be best to put this functionality into a plugin rather than having it in the engine itself. I was thinking that Recast might be a good choice for this. We used it successfully for a mobile project a while back. I can look into this if people are interested...

Maybe you could focus on a few very usefull improvements like :

- physics for scene layers, which would allow clickable menus & sub-menus, as well as gamepad emulation
- a fullscreen-non windowed lua function
- a point & click behavior
- path-finding
- ...

Great news for us !

No promises, I'm going to visit my family-in-law. But I don't imagine I can survive 3 weeks without coding so there should be some progress.

I'll have a look at the wish list, but I definitely don't want to step on Anael's toes with regard to things like the the revamped GUI system. The stuff that wasn't mentioned by Anael are predominantly documentation work. I will try to look into updating the wiki, but it doesn't quite have the required things needed to satisfy my code withdrawal symptoms

Anyway, if you have any requests to have their feasibility tested in the community repository, give me a shout. Oh, and feel free to stick issues into github if anyone finds bugs, I'll probably forget about them otherwise