Some Plugins (Page 1 of 3)

MEvent
link
Simple message system for use in Maratis. Overrides MGame so no other "games" can be added, but will send the following messages:
update - when the game gets an update call
lateUpdate - after the game has finished updating
preRender - before the game draws anything each frame
render - during the frame drawing
postRender - after everything else has drawn

To get the messages, create a class that inherits from MEventListener and use the MEventListenerDeclare macro. The event listener should implement void onEvent(const char*). Event listeners will not be fired in a fixed order, so you cannot guarantee which object will receive postRender first.

To broadcast messages, use:

MEventSend("SomeMessage")

TODO:

• Change events to support ints/enums for faster checking

• Lua support

• Allow filtering of events so not every object gets every message

• Support multiple broadcasters maybe?

Changelog
09.07.2013 - Fixed MEventListener so you can actually link to it properly

Last edited by Nistur (2013-07-11 19:48:53)

MSaveFile
link
Simple save file system.

MSaveFile* save = NULL;
MSaveFileGetNew(save, "file.sav", M_SAVE_FILE_MODE_BINARY);
if(save)
{
    save->setInt("some.key", 1);
    save->setFloat("some.other.key", 44.32f);
    save->setString("some.other.other.key", "something");

    int valInt = 0;
    float valFloat = 0.0f;
    char valStr[256];
    save->getInt("some.key", valInt);
    save->getFloat("some.other.key", valFloat);
    save->getString("some.other.other.key", valStr);

    save->destroy();
}

save = saveFileOpen("file.sav", "M_SAVE_FILE_MODE_BINARY")
if save ~= nil then
    saveFileSetInt(save, "some.key", 1)
    saveFileSetFloat(save, "some.other.key", 44.32)
    saveFileSetString(save, "some.other.other.key", "something")

    valInt = saveFileGetInt(save, "some.key")
    valFloat = saveFileGetFloat(save, "some.other.key")
    valString = saveFileGetString(save, "some.other.other.key")

    saveFileClose(save)
end

The file will automatically be loaded when opened and saved when closed. You can force save/loading by using MSaveFile::save/MSaveFile::load or saveFileSave/saveFileLoad
The mode must be specified when the save file is opened. The choices are:
M_SAVE_FILE_MODE_TEXT - will save in text (XML) format
M_SAVE_FILE_MODE_BINARY - will save in binary fomat
M_SAVE_FILE_MODE_ANY - will save in the existing format, or binary if no file exists
Specifying the mode will not affect loading the save file, it is possible to open an XML savefile with M_SAVE_FILE_MODE_BINARY and vice versa. When the file is saved the next time it will be overwritten with the specified format.

Optional libraries: MEvent, MScriptExt
MSaveFile contains embedded lua which it can add to the lua environment if the project contains both MEvent and MScriptExt plugins. It extends the lua functionality.

save = MSaveFile("file.sav")

save:setInt("some.key", 1)
save:setFloat("some.other.key", 44.32)
save:setString("some.other.other.key", "something")

valInt = save:getInt("some.key")
valFloat = save:getFloat("some.other.key")
valString = save:getString("some.other.other.key")

save:close()

Note: you can also use save:set which will allow you to pass any object, if it's a number or a string, it will save it directly as above, but can also save any table by looping recursively through its children. There is no matching working get function as MSaveFile doesn't yet allow iterating through the values

TODO:

• Give a default directory to save in

• Serialise tables in/out in lua

• Add savefile versioning

• Change flat binary files into hierarchical ones

No problem I'm just hoping that other people can start adding to this list soon.

Hrmmm, that's interesting. Can you send me a sample that shows this that I can test? I'm assuming it's something weird with how lua handles scopes. The behaviour doesn't actually have an object (and, therefore, data) associated with it. I haven't yet found how you can use more object oriented stuff when calling lua, although, now I have MScriptExt and embedded scripts working, I can relatively easily do this on the lua side I think...

MSaveFile is actually the only plugin that doesn't actually need Maratis, so I've added a small testsuite to it. This doesn't mean it's bug free by ANY means, but if you find any bugs, it'd be good to be able to reproduce this in the testsuite so we can make sure it doesn't happen again. I'll also try to add testsuites to the other plugins at some point maybe, but it will require stubbing out a lot of Maratis functionality to even get them to link.

Haha. I actually did half of this stuff before my holiday, and half on the journey here. I've been doing this thing called "relaxing" this week mainly

As a slight aside, most of the plugins have two different build targets, a dynamic lib (so it can be used as a plugin directly) and a static lib which I am currently fiddling with linking into a über-lib, but would also (in theory) work for non-dynamic platforms, such as iOS. The plugins will have to be initialised/destroyed manually though from within the game

Of course. I've tested with the SponzaFPS demo and the following Script1.lua file put in the behaviors folder:

Script1 =
{

    ----------------------
    -- SetUp Once / Constants
    ----------------------

    onBegin =

    function(object, behaviorID)

        speed=3

    end,

    ----------------------
    -- Scene Update
    ----------------------

    update =

    function(object, behaviorID) -- NB: behaviorID is currently inactive

        if isKeyPressed("A") then addCentralForce(object, {-speed, 0, 0}, "local") end
        if isKeyPressed("Z") then rotate(Head, {1, 0, 0}, 1, "local") end

    end

}

The behavior is applied onto the Player.

If I put the "speed=3" in the main lua script (joystick or mouse) or in update then it works.

Thanks

Many thanks, I'll check if everything is OK now.

Not sure if MScriptableBehaviour is robust enough, but currently it can handle objects from other scripts (like Head in SponzaFPS) without any problem. I'll check more extensively a little later, but for now it looks almost perfect!

First tests look really promising & work fine.

However I found a little issue with how the script names are handled.

Even if scripts are put in 2 different folders (scripts & behaviors) and the script from scripts folder is not called with a dofile, you cannot use the same name for both, it makes the editor crash.
So I renamed the script in the behaviors folder with a "_Nistur" (for example Script_Nistur.lua) to fix this.

Then I did the same with a second new script (ZZZ_Nistur.lua) and it makes the editor crash again. If I remove the "_Nistur" then it works fine.

Last edited by com3D (2013-07-09 07:10:22)

Update: deleting the script in the scripts folder doesn't improve the situation, I still cannot use the original name. And if in place of _Nistur I rename by _N for both scripts then it works.

I've found another small issue : cloning an object (using the getClone function) onto which a behavior has been applied makes the editor crash.

Take your time, Nistur, and don't forget to have fun !

Thanks, a zip might not be necessary.

Try creating a file named Hero.lua with no active script in it (just a blank update function or even an empty table) and apply it to the Player in Jules demo. With this name it crashes in any project I test, but if I name it for example Hero_N then no crash.

I'll test your new version immediately!

By the way, did you try the getClone function ?

Last edited by com3D (2013-07-12 05:52:42)

Just a quick thing I remembered. It's possible in lua to have an implicit self parameter. So if it suits your programming style, you could do the following instead for MScriptableBehavior:

MScriptableBehavior "player" = {
    -- variables go here
    speed = 3,
}

function player:update()
    -- can use variables here
    move(self.speed) -- the self parameter is passed because we declared the function with a :
end

It does mean that you have to specify variables separately from functions, not sure how much I like that. But it's up to you

MEmbedFile
link
This wraps up embedding files within code, which means that plugins can more easily provide their own data. Other plugins already sort of support this manually for some of their API scripts, which get loaded when MScript initialises. MEmbedFile will allow optional scripts, which can be loaded only when required with dofile as well as embedding images, or any other data.

To use:

MEmbedFile* file = NULL
MEmbedFileGetNew(file, "file/name", fileData, fileDataSize);

if(file)
{
    file->destroy();
    file = NULL;
}

The file is kept in the virtual file system until it is destroyed and can be accessed by any of the standard Maratis file IO functions.

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.

Last edited by Nistur (2013-07-23 07:15:08)