Re: Github mirror

I had a quick attempt at this last night, but it occurred to me that any solution is going to be difficult and seem pretty hacked in. There is no real concept of a lua environment that I can add to because the lua_State gets cleared when you start a new scene. In the MScriptableBehaviour component I have sort of worked around this by (re)loading the relevant behaviour script whenever a behaviour of that type is created, which obviously has a number of issues.

I have come up with the following possible solutions:

1. Create an event system that you can subscribe to, so if you get an event of MEventScriptEnvironmentInit then you know to load the scripts at the right time
2. Be able to add to the environment by cacheing the scripts. This is probably the easiest solution, but would require to keep a local copy of all environment scripts in memory, or to write them to temporary files...
3. Use something like lua rings, which will allow multiple states to be active, so we could pretty much have the event system in lua, and the master (environment) state could set up a recreated slave (game) state.

Unfortunately, my "ideal" solution of having a clean environment state that we clone doesn't seem like an option, I haven't found any way of cloning a state (yet)

Last edited by Nistur (2013-06-28 08:39:43)

  • anael
  • Administrator
  • Offline

Re: Github mirror

It's against the current logic to be able to setup lua environment like that,
and the direction of scripting in Maratis was always to stay a simple 'C like' function-based system.
It's still possible to create an interface layer in lua.

Re: Github mirror

Ok, I feel this limits the extensibility of the system though as it won't allow for using lua's more advanced features to make nicer/better/cleaner interfaces for plugins without shipping a plugin with a build for each platform, a header, and the entire lua interface in separate files to be dofile'd in the scene files. Especially for rapid prototyping, I think that's far too much hassle for potentially simple features.

If you're not happy with this kind of thing to be in Maratis, I guess I can quite easily make a plugin to replace MScript that includes an event system, so we can have an "advanced" interface if the plugin's used.

As a side note. I'll be on "holiday" for 3 weeks starting on Wednesday 3rd. I was going to pick up a little freelance work over the time, but I haven't had confirmation from work that they're happy with me doing so, and I don't want to upset the legal department. However, I will want to do some coding, so... if anyone has any requests, I might be able to get it done in the github mirror and ready for testing and to be (potentially) merged into the official repository if successful and relevant.

  • anael
  • Administrator
  • Offline

Re: Github mirror

It just cannot work with a portable oriented virtual system,
a complex implementation will require handling with lua natively,
you will need the lua state to do complex thing.

The only solution I see would be for example to make MScriptContext a dynamic library that can be accessed directly
(or let's say a Common with also bulletContext and few other major implementations)
so the lua context could be used natively.

It will give an "expert" access to the engine implementations, it will just need some security.

The specificity you want to use is anyway not portable and very lua-oriented,
and the use of this common dynamic lib can stay optional for the general use.

But this is a big structure modification, so it need to be planned carefully,
there is things to go before and validated/tested step by step.

Re: Github mirror

anael wrote:

It just cannot work with a portable oriented virtual system,
a complex implementation will require handling with lua natively,
you will need the lua state to do complex thing.

I don't think I understand what you mean by this. I realise that the cloning and rings support in lua is a fairly intensive solution, I'm just throwing ideas out to see if anything makes sense to try to make the engine more extensible.

anael wrote:

The only solution I see would be for example to make MScriptContext a dynamic library that can be accessed directly
(or let's say a Common with also bulletContext and few other major implementations)
so the lua context could be used natively.

I don't see why Common needs to be exposed at all. MEngine::setScriptContext can be accessed outside of Maratis/MaratisPlayer, so, for example, an extended MScript plugin can, on plugin start, replace the MScriptContext within MEngine. If the extended context uses the MResource system, it means you can then access it from within, say, the MSaveFile plugin, doing something as follows

MScriptExtended* script = MScriptExtendedGet(); // this is a macro similar to the MSaveFileGetNew
if(script)
    script->addInitEnvironmentCallback(loadScripts);
//...
void loadScripts()
{
    // this would only be called if we're using MScriptExtended
     MScriptExtended* script = (MScriptExtended*)MEngine::getInstance()->getScriptContext();
    if(script)
        script->parse(embeddedScript);
}

As long as this is documented so developers know of this, that means that you can have a standard 'C-like' interface using the standard MScript, and just allow extended features if the extended script plugin is being used.

anael wrote:

But this is a big structure modification, so it need to be planned carefully,
there is things to go before and validated/tested step by step

I totally agree, that is why I wanted to put some suggestions out there so we can decide on the best solution going forward

Last edited by Nistur (2013-06-28 11:55:23)

  • anael
  • Administrator
  • Offline

Re: Github mirror

Sure you can always use MEngine::setScriptContext,
but you will loose the implementations done by MScriptContext,
and from the complexity you want to extend lua (while keeing it's current state)
you will need the lua state pointer lua_State *

Re: Github mirror

Nistur wrote:

I'll be on "holiday" for 3 weeks ... I will want to do some coding, so... if anyone has any requests, I might be able to get it done in the github mirror and ready for testing and to be (potentially) merged into the official repository if successful and relevant.

Great news for us ! big_smile

I think that the whish list at http://forum.maratis3d.com/viewtopic.php?id=664 is a good start and should appeal to most of us.

Re: Github mirror

com3D wrote:

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 tongue

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 smile

Re: Github mirror

Hey Nistur,

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
- ...

Re: Github mirror

I've had a think about what you've suggested.

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...

Re: Github mirror

After yet more thoughts, I've had a couple more ideas. Still nothing final, just a few more things to throw into the mix.

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.

Re: Github mirror

By "physics for scene layers" I was meaning that :
- you have a main 3D scene
- you put a 2D scene layer on top of it (with menus or gamepad simulator) and its objects are clickable

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).

Last edited by com3D (2013-07-03 08:34:24)

  • anael
  • Administrator
  • Offline

Re: Github mirror

I think what com3d means about physics is a problem linked with having GUI in another scene layer,
because physics is only active for the current scene it's not possible to use isRayHit in lua
to detect if the mouse interact with a GUI object (because isRayHit uses the physics context only to test a ray).

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.

Re: Github mirror

Ok, that makes sense. I still think that for 2D systems we shouldn't bed to do any raycasts at all. We should look into exposing MGui and using mouse positions, or use a different GUI solution.

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.

Re: Github mirror

Yes Anaël, that's exactly the desired goal.

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

Last edited by com3D (2013-07-03 09:32:54)

  • anael
  • Administrator
  • Offline

Re: Github mirror

Ok com3d, it was already in my todo, when I have some time I'll add it.

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

Re: Github mirror

Great news and thanks for suggestion, I think it will do the trick for basic needs. big_smile

Re: Github mirror

Nistur wrote:

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?

Re: Github mirror

com3D wrote:

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.

com3D wrote:

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

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"

Last edited by Nistur (2013-07-04 12:15:54)

Re: Github mirror

While working on the plugins recently, I was thinking that something which is missing from Maratis is an easy way to make popups. Game popups should be done using whatever UI solution is chosen for the main game UI, but in some situations it's both neater, and more reassuring to a user, to provide them with an OS popup.

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

Re: Github mirror

I've just pushed some changes to the github branch. They have been largely concerning adding functionality to extend publishing. MGame will now get ::publish so will allow you to do whatever you want to continue publishing bespoke game functionality. If you also use MScriptExt, you can receive a lua event and I've added some packaging functions to lua.

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)

Re: Github mirror

Random question I'm going to cross post on my plugin thread.

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.