(4 replies, posted in Off-Topic)

You rang m'lord?

I'm sorry I've been silent for so long, I've had a LOT of things on my plate. As both zester and BitPuffin have mentioned, I'm regularly on IRC (but don't be upset if I don't reply straight away, as I said, I'm busy sad)

I'm still using Maratis a little for some samples I've been doing, and I fully intend to come back to the forums properly and restart my project properly once I've freed up some more time.

I'm sorry I misunderstood then. Yes, it's all possible. I've been working into moving game specific stuff (like the behaviours) into lua to allow easier/quicker development.

I think the issue with lua is how dynamic the language is. If we remove it and make the MVariables static types then that reduces the issues significantly. Exposing lua variables in the editor will be possible.

With regards to the example you gave. If the movement is straight line, I could have that working for you before the end of the weekend if you really wanted using MScriptableBehaviour. If you want proper path finding, you'll have to wait for MRecast to be hooked up.

anael wrote:

- be able to change the variables in-editor to fine-tune the game

I really don't see the editor variables being a huge issue (although I am expecting a few perculiarities when trying to access the base class stuff from the editor)

anael wrote:

- the entities interactions should be updated automatically

I'm not entirely sure what you mean by this. MScriptableBehaviour currently gives you onBegin update and onEnd callbacks. If you would want collision callbacks then it _should_ be fairly easy*

anael wrote:

- I'd like to call special actions triggered in lua

Again, not entirely sure what you mean by that. MScriptableBehaviour is entirely in lua. It uses the same lua state as the scene script, so you have the same environment. If you want to call actions yourself, it is possible.

If you have a specific use case, like the one above, I'd be very happy to know because it can help me make the system more well rounded and gives me test cases to make sure it works smile

* There is currently nothing like this in MScriptableBehaviour, but I can make a MEntity table in lua that will handle things like physics callbacks and behaviour lists. It can then call onCollision on any behaviours that implement that function...


(64 replies, posted in Plugins)

yes, it will. Until I get time to push to github again, you'll need MScriptExt and MEvent, but it will.

To store any variables you'll need to do something similar to post #9 or the second example above (post #45)


(64 replies, posted in Plugins)

If you let us know which OS you're running on, we can try and supply you builds of the community branch of Maratis that you will need, as well as the plugins to test.

Without any plugins, you can assign lua values to objects as follows:

player = {
    obj = getObject("player"),
    speed = 3,
    update = function()
        -- use player.obj and player.speed here

function onSceneUpdate()

with MScriptableBehaviour alone you can then do something like this:

local player_vals = {}
player = {
    onBegin = function(object, behaviour)
        player_vals[object] = {
            speed = 3,

    update = function(object, behaviour)
        -- do something with player_vals[object].speed

Note: update gets called automatically and you get the object ID passed in onBegin, update and onEnd functions

If you add MScriptExt and MEvent to the project, you can then do this (which is arguably a little nicer)

MScriptableBehaviour "player" = {
    speed = 3,

    update = function(self)
        -- do something with self.speed

Note: if you need the object ID, it's stored in self.__id.object but I'm hoping to remove the need for that soon.

With regards to accessing a specific enemy. It depends on which method of the above you're using, but assuming the latter you can do something like this:

local enemy = getObject("enemy01") -- or some other way to get an object ID
local behavior = player.get(enemy)
local speed = behavior.speed

Hope that all helps in some way smile

I'm familiar with how Unity's Entity/component system works (also, I think I have that book somewhere). I think I was just a little confused by you splitting the data (component) from the functionality (behaviour).

The Maratis behaviour system currently uses an XML format for all the data. There is no way (yet) to reflect this properly in the script using MScriptableBehaviour but it's something I am working on. It is possible to use the standard lua API to access behaviours in C++ behaviours currently (GetBehaviorVariable, SetBehaviorVariable)

I'm still not entirely sure what your "ideal" design is for this, but my current plan is:
- define 'types' in lua such as MVariableString which are tables with :get and :set functions and, if invoked with parameters, set a default value ( MScriptableBehaviour "player" { speed = MVariableInt(3), } )
- from the C++, the class can query the definition with things such as script->callFunction("player.getVariablesNumber") and then initialise an internal list of the data (which can then be removed from the lua side completely) for exposure through MScriptableBehaviour::getVariable
- the lua "MVariable" table can then be used with :get and :set functions which will automagically call through to the standard getBehaviorVariable/setBehaviorVariable function (no data stored in lua, no chance of going out of sync)

I haven't even begun to implement this, so I have no idea if there are any hidden gotchas yet. But it looks (to me) to be a workable solution. Any thoughts?

heartseed wrote:

I thought you liked grapple a bit, at least enough to base something off of ?

I did quite like grapple, but it hasn't been maintained for 4 years (not a problem if it mostly works but looks like there are no grapple experts to quiz if things go wrong) and I could never get Windows support working, although, to be fair, I didn't try _overly_ hard. It's an option, but it's not really ideal.

There's no networking support in Maratis yet, it's another of the things I've looked into, but I've not yet found a nice library to base any work off, and I've not had the time or energy to write the system from scratch. In theory writing a bespoke networking library for a specific task is relatively easy, writing a generic one to suit an engine is considerably more difficult, so it might be that you're better off rolling your own and/or enlisting someone to help with your specific case. If you're feeling kind, the work could be rolled back into Maratis and made more generic for the community to use tongue

I would be interested to know precisely what the plan is for the component/behavior system you have in mind. I think it should be possible to leverage MScriptableBehavior to do what I think you're wanting


(29 replies, posted in Showcase)

It's looking really good Sponk! I can't wait to see more smile


(64 replies, posted in Plugins)

Hi marval. The plugins need to be compiled first. I'm using a build system called premake 4. You can view some basic instructions on how to use it just before the second screenshot in my tutorial. It will then require Visual Studio to build the plugin (assuming you're running Windows).

com3D has offered to provide builds of the plugins so users won't have to go through the above steps (the plugins such as MScriptableBehaviour.dll can just be copied into the project folder) but we have still got a couple of bugs to iron out first.

Hi Kirilz,

Welcome to Maratis!

I was looking into trying to implement require recently but I never got around to it. I think there are some assumptions about what it does, regarding setting up modules and so on, which I haven't quite figured out yet.

About the behaviour system, I've recently been working on a couple of plugins one of which provides scriptable behaviours like you suggested. It's still pretty early on but it more or less works. The multiple plugin framework is currently only available through a build of the community branch of the engine, but I'm hoping to find the time soon to go through and test it fully so I feel confident enough to push it to the official repository.

Most of the stock lua API is very c-like, not reflecting objects at all. This, I believe, is done to keep the API simple. I have also been trying to make an optional object oriented API on top of this with the plugins, but using an automatic reflection thing I think might complicate the simple API a bit, plus, the system as-is, is pretty detached from the scripting system, adding automatic reflection would more heavily couple it to pretty much all the classes in the engine.


(64 replies, posted in Plugins)

That's a file generated from MScriptableBehaviorPublishEvents.lua by bin2c.lua when premake is called.

Oh! I know why! It's because I implemented os.dir for *nix in the build scripts but I didn't have a working Windows box to write and test it. It just returns an empty list. Great. Sorry about that.

Edit: for now, we could probably just hard code the scripts to be embedded rather than try to list the directory. I'll take a look at it tomorrow


(64 replies, posted in Plugins)

Sounds like you're using premake 4.3. It should work with premake 4.4 smile


(64 replies, posted in Plugins)

Great, the Windows builds should be more or less the same as the Linux ones (setting environment variables etc) just, you can't symlink the engine nicely (at least... doing so is a little more difficult) so you probably will have to manually create the correct folder structure.

I'm just home now, and have to make food before I can look at any coding, but I'm struggling to think of a nice solution as they all pretty much rely on knowing when the lua state has been cleared to reinitialise things, so I guess I'm going back to the hacky solution of every instance will reload the lua script.

For reference, you can still use the "normal" method (using player { update = function(obj, bh) --[[ ... ]] end, } ) using MScriptExt and MEvent, they will just ensure that the scripts are run at the right time and only once, and allow for the more object oriented approach if you wish to go that route.


(64 replies, posted in Plugins)

It does when run alongside MEvent and MScriptExt, if those are missing it crashes as you said. I will try and add a marginally less hacky solution later tonight


(64 replies, posted in Plugins)

Right, I realised what this is. It's the error I mentioned before, that it can't find the relevant table 'cause the script isn't loaded. At this stage, MScriptableBehaviour depends on MScriptExt and MEvent because it relies on the MScriptInit event to be fired so it knows when to load the correct scripts.

At some point I'd like to try to make fallback for if you're not using MScript and/or MEvent, but I've got no idea how we can really get around this apart from the pretty hacky solution I had before.


(64 replies, posted in Plugins)

post cut off sad


(64 replies, posted in Plugins)

com3D wrote:

However, since I've udpdated Maratis fork, MScriptableBehavior doen't work anymore.
I get the following error:
PANIC : unprotected error in call to Lua API (attempt to index a nil value)
Same error when I apply a script and then remove it.

Can you please check that you've definitely updated everything. The issue is currently that MScript{,Ext}::startCallFunction will throw this error if you try to call something like player.update when no player class exists. I _thought_ I fixed when this occurs, but I really need to find how I can do error checking on lua_getglobal and lua_getfield, which are the cause of this.

If it's still occuring, can you let me know which plugins you're using to make sure I've got the same configuration loaded to reproduce it and any scripts you're using that are causing the problem.

com3d wrote:

Sure, I'd be pleased to contribute in some way. I can provide builds for Linux (Ubuntu).

Thanks! I'll PM you details


(64 replies, posted in Plugins)

Random question I'm going to cross post on my github mirror 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 plugins 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.


(46 replies, posted in General)

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.


(64 replies, posted in Plugins)

Ok, I'll look into making MExtensions later. Shouldn't be a problem at all.

Right, I've tried to make things simple for this, but it's ended up being a bit weird. My build scripts all expect a folder layout similar to the binary distribution, which unfortunately isn't how scons builds maratis. My setup is as follows (on OSX right now, but the principle's the same)

Harpy:dev pgeyer$ cat ~/.profile 
# other stuff...
#set up Maratis
export MSDKDIR=${HOME}/dev/Maratis-dev/
Harpy:dev pgeyer$ ll ~/dev/Maratis-dev/
total 8
lrwxr-xr-x  1 pgeyer  staff   68  6 Jun 08:14 Bin -> /Users/pgeyer/dev/maratis/trunk/dev/prod/darwin/release/Maratis/Bin/
drwxr-xr-x  4 pgeyer  staff  136  7 Jul 17:27 Plugins
drwxr-xr-x  4 pgeyer  staff  136  6 Jun 08:16 SDK
Harpy:dev pgeyer$ ll ~/dev/Maratis-dev/SDK/*
total 16
lrwxr-xr-x  1 pgeyer  staff  56  6 Jun 08:16 Includes -> /Users/pgeyer/dev/maratis/trunk/dev/MSDK/MCore/Includes/
lrwxr-xr-x  1 pgeyer  staff  61  6 Jun 08:17 Libs -> /Users/pgeyer/dev/maratis/trunk/dev/prod/darwin/release/MSDK/

total 16
lrwxr-xr-x  1 pgeyer  staff  58  6 Jun 08:15 Includes -> /Users/pgeyer/dev/maratis/trunk/dev/MSDK/MEngine/Includes/
lrwxr-xr-x  1 pgeyer  staff  61  6 Jun 08:17 Libs -> /Users/pgeyer/dev/maratis/trunk/dev/prod/darwin/release/MSDK/
Harpy:dev pgeyer$ ll ~/dev/Maratis-dev/Plugins/*
total 40
lrwxr-xr-x  1 pgeyer  staff  49 23 Jul 11:09 MEmbedFile.h -> /Users/pgeyer/dev/MEmbedFile/include/MEmbedFile.h
lrwxr-xr-x  1 pgeyer  staff  49  7 Jul 17:26 MEventListener.h -> /Users/pgeyer/dev/MEvent/include/MEventListener.h
lrwxr-xr-x  1 pgeyer  staff  45  7 Jul 17:26 MGameEvent.h -> /Users/pgeyer/dev/MEvent/include/MGameEvent.h
lrwxr-xr-x  1 pgeyer  staff  47  7 Jul 17:26 MSaveFile.h -> /Users/pgeyer/dev/MSaveFile/include/MSaveFile.h
lrwxr-xr-x  1 pgeyer  staff  49  7 Jul 17:27 MScriptExt.h -> /Users/pgeyer/dev/MScriptExt/include/MScriptExt.h

total 80
lrwxr-xr-x  1 pgeyer  staff  49 23 Jul 11:10 MEmbedFile.dylib -> /Users/pgeyer/dev/MEmbedFile/bin/MEmbedFile.dylib
lrwxr-xr-x  1 pgeyer  staff  41  7 Jul 17:27 MEvent.dylib -> /Users/pgeyer/dev/MEvent/bin/MEvent.dylib
lrwxr-xr-x  1 pgeyer  staff  47  7 Jul 17:28 MSaveFile.dylib -> /Users/pgeyer/dev/MSaveFile/bin/MSaveFile.dylib
lrwxr-xr-x  1 pgeyer  staff  49  7 Jul 17:29 MScriptExt.dylib -> /Users/pgeyer/dev/MScriptExt/bin/MScriptExt.dylib
lrwxr-xr-x  1 pgeyer  staff  69  8 Jul 19:19 MScriptableBehaviour.dylib -> /Users/pgeyer/dev/MScriptableBehaviour/bin/MScriptableBehaviour.dylib
lrwxr-xr-x  1 pgeyer  staff  48 23 Jul 11:10 libMEmbedFile.a -> /Users/pgeyer/dev/MEmbedFile/bin/libMEmbedFile.a
lrwxr-xr-x  1 pgeyer  staff  40  7 Jul 17:27 libMEvent.a -> /Users/pgeyer/dev/MEvent/bin/libMEvent.a
lrwxr-xr-x  1 pgeyer  staff  46  7 Jul 17:28 libMSaveFile.a -> /Users/pgeyer/dev/MSaveFile/bin/libMSaveFile.a
lrwxr-xr-x  1 pgeyer  staff  48  7 Jul 17:28 libMScriptExt.a -> /Users/pgeyer/dev/MScriptExt/bin/libMScriptExt.a
lrwxr-xr-x  1 pgeyer  staff  68  8 Jul 19:19 libMScriptableBehaviour.a -> /Users/pgeyer/dev/MScriptableBehaviour/bin/libMScriptableBehaviour.a

Basically I have my maratis root directory outputting to ~/dev/maratis/trunk/dev/prod/... and then ~/dev/Maratis-dev symlinking to the relevant parts of that. And to allow plugins to use plugins, they're all present within ~/dev/Maratis-dev/Plugins. The only environment variable needed is $MSDKDIR which then points to the current binary distribution root.

Hope that helps.

In other news, I've made a couple of additions to MScriptExt and MScriptableBehaviour.
- MScriptExt - Changed dofile to check a relative path first against the current directory the script is being run in, then against the project root.
- MScriptExt - moved editor script loading into the script rather than being done in C++, which makes it cleaner and less error prone
- MScriptExt - added the following table extensions: table.copy table.compare table.compare_deep table.concat table.contains
- MScriptableBehaviour - fixed getClone bug (wasn't copying the behaviour name across properly)
- MScriptableBehaviour - load behaviour scripts once, and from the plugin script, similar to how the editor scripts are loaded
- MScriptableBehaviour - Used table.copy to copy variables when initialising new behaviours, before if you set a table as a behaviour variable, it was shared between all instances of the behaviour.
- MScriptableBehaviour - added a helper function to get a behaviour assigned to an object ID (ie for a player: local player_bh = player.get(getObject("player")))


(46 replies, posted in General)

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)


(64 replies, posted in Plugins)

Hmmm, I think I know what that will be. It's something I've been meaning to fix for a while anyway, I think the issue is that when you start a new behaviour, it will automatically try to reload the script file (because up until recently, there was no way to get a callback when to add to the script state) That probably means that it's steamrollering over something important. It's an easy fix, but it's going to require MScriptableBehaviour depends on MEvent and MScriptExt to make it work.

In other news... I've added publish events! It requires an update of the community Maratis branch to support it, but games, and plugins, can add scripts to dictate how their data gets published. I'll update the MScriptExt post, and maybe write a short doc on the wiki about it.

Edit: I was thinking, as there are a number of plugins which pretty much depend on each other (or, their function is greatly reduced without each other) I might roll MEvent, MScriptExt and MScriptableBehaviour into one MExtensions plugin (basically what I've done with Mage) I'm not sure whether I want to add MSaveFile and MEmbedFile to that yet.


(5 replies, posted in Plugins)

That sounds like it would work. I've got a couple of other things to sort right now, but I can take a look at sample scenes soon.

There's no way to upload to this forum, but any file host should do. Possibly the best might be a shared folder on a Dropbox account?


(5 replies, posted in Plugins)

Yeah, I guess that would probably work. I was just a bit cautious of making something without "real world" use cases I would potentially be working on something that would only work in the lab and not in the wild. But it would serve as a start, I guess smile


(2 replies, posted in Plugins)

Introducing... MAGE!
The Maratis Adventure Game Engine.

Note: Mage is very very much in progress and doesn't do much itself now other than load sub-plugins. It is only being shared at this early stage to demonstrate how to combine plugins so you don't have to ship a game with thousands of tiny DLLs

The design of MAGE is to make it as easy as possible to design and create 3D adventure games. A lot of the functionality will be created by making and loading more generic plugins, but it will be brought together with lua scripts and code API that will be tailored towards making adventure games.

There are a lot of things to figure out how to do for an adventure game, and I've yet to decide exactly how much of that can, and should be done in MAGE and how much will be done on the game side.

- Inventory system
- Point and click movement
- Point of Interest
    - Comment or action
    - Actor conversation
    - Pickup
- Events