Github mirror (Page 1 of 2)

Update!

I've updated the github mirror to r203 from svn, and I've also made some more minor changes:

1. I extended MScriptContext::callFunction to be able to take functions within lua tables (so you can call, for example, player.update)
2. I added optional userdata to the registration of MBehavior factories. The reason for this is that you can then use one base class with different options (see #4)
3. I added MScriptContext::addScript which is pretty much the same as MScriptContext::runScript but only will load the script if the state has already been created, and won't clear the state, or do anything if it fails.
4. I made a plugin. It is pretty rough and dirty right now, but it works. If you drop this into the project folder and then create a "behaviors" folder along side it, and populate it with lua scripts, it will add one behaviour to Maratis for each script. It currently expects the script to have a similarly named table within it, with an update function. I haven't yet done the variable translation between lua and C++(/editor) but at least it's a start

Example behaviour script:

player = {
    update = function(object, behaviour)
        
    end
}

Edit: I totally forgot, I also merged in a change from Sponk! Maratis editor is now themable! There are two themes provided (default and grey) although currently there's no way to switch them without recompiling

Let me know what you think

Last edited by Nistur (2013-06-08 16:28:48)

Nistur: You actually can change the theme. Just change the 'default.theme' file in the 'gui' directory and you should be fine.

Nistur,

Sorry, in fact there was a conflict with another plugin.
I've updated my previous post.

In fact it was an incomplete plugin that I renamed 'Game.soZ' to deactivate it.
Your fork seems to load any file containing '.so', that's why wrong files can be loaded.

What is the purpose of the behavior parameter?

I think onBegin function for dealing with constants and initial setup is the top priority.
How can we deactivate/reactivate the behavior from other scripts ?

Just a small update that I've been playing about a bit the last few days on my commute, I present to you:

MSaveFile!

I will admit to have been "inspired" by Unity's PlayerPrefs system a little. At the moment it only reads/writes text files (XML) but I'm part way through adding some very basic binary file support. After that's done (maybe by the weekend) I will probably add some lua hooks in for save data.

For now, you can do as follows:

MSaveFile* save = MEngine::getInstance()->getNewSaveFile("path/to/save/file", M_SAVE_FILE_MODE_TEXT);

save->setString("some.key", "value");
save->setInt("some.other.key", 1);
save->setFloat("yet.another.key", 12.55f);

char testStr[256];
save->getString("some.key", testStr);
int testInt;
save->getInt("some.other.key", &testInt);
float testFloat;
save->getFloat("yet.another.key", &testFloat);

save->destroy();

The class is pretty much an RIIA object, so it will load on construction and save on destruction, you can also call save/load manually if required. When the binary mode is added, it will be pretty much seamless. If you specify binary, but it loads text, when it saves again, it will convert it to binary and similarly the other way around. You can also specify M_SAVE_FILE_MODE_ANY and it will default to whatever it reads in, or binary if making a new file.

This can then be used internally for Maratis Editor to save preferences, such as the last opened project directory. I haven't done this yet... if anyone were to send me a pull request with this added, I would definitely appreciate it *hint hint*

Anyway, let me know what you think.

Anaël, could we at some point discuss about potentially merging some of these changes back into the official repository? I would very much like it if we could continue to maintain this "community" Maratis branch and then I/you/someone could merge back changes that would be suitable for the official repo.

I'm well aware that a full time job can leave with you with no time (oh, very very aware) the reason behind the github fork, as I said was so that potentially "we", the community can try to work on the engine and then when the fixes are stable enough and got your approval, they can be merged up. I don't think anyone is complaining about anything here

I've already had a couple of "bugs" about the plugin system, such as com3D's one where I'm just checking for *.so*/*.dll*/*.dylib* which I think should probably be fixed before I submit it, but that's pretty minor.

With regards to making a plugin for MSaveFile, I can easily do that, but that means that we lose the ability to have editor savedata/preferences, unless I keep MSaveFile in MCore but move MSaveFileImpl to a plugin, but at the same time, that means that we have to have the plugin available both on an editor level (currently, I don't load editor plugins at all... so...)

I definitely agree with an overhaul of MGui because it's currently a bit difficult to extend the editor interface at all. But I think this is perfect for a separate thread.

I think there needs to be a further discussion then before MSaveFile is accepted into the official repository. If you don't see it as a core engine component, then it shouldn't be added. I think it would be a useful thing to have it available for Maratis as standard in some form, so I think we should try to find an agreeable solution. The options I think are:

1. Build it into Maratis/MSDK. The benefits here are that it's easy to integrate with lua, it's available both for game code and editor variables, and also, it's already done. The issues with it are that it is an enforced component in all projects, whether you need it or not.

2. Create it as a plugin. The only real benefit I see in this over #1 is that you can choose whether or not to have the support in your project. The disadvantage is that the editor can no longer access it as it isn't a general solution.*

3. Create it as a static lib. This is a pretty nice all-round solution. It can be linked into the editor executable and any plugins that need it, but the problem is that, for one, it creates extra complexity (having external static lib dependencies for plugins) and that it's no longer possible to easily expose save file functionality to lua without creating a plugin.

* Editor-specific plugins _should_ be a thing. I have intended to add them, but I haven't got around to it yet. But even that wouldn't solve this problem because you would then have two (identical?) plugins for a project that needs save data, which could cause confusion both for users, and for code compatiability (editor plugin is old version, project one is newer)

Anyway, as I said, I'm happy to go with whatever you want for this, but I think it needs a little further discussion regarding what is the best solution.

I've been wrestling with this a little. There is an issue with the plugin system currently. It works great for standalone plugins but if you want to reference them from the game plugin, you have to link against it... but you don't want to use dynamic linking because MPlugin is loading it manually anyway.

The issue is factory functions. I can't find a nice way to call, say MSaveFile::getNew within the game plugin, because it clearly needs to resolve it.

I have an idea, but I'm not sure whether I like it. There could be a base object type:

class MResource
{
public:
    typedef MResource*(objectFactory)();
    static MResource* getNew(const char* type);
    static void addFactory(objectFactory factory);
};

then we can do something like this in the plugin header:

#define MSaveFileGetNew(save, file, mode) \
{\
    save = (MSaveFile*)MResource::getNew("MSaveFile");\
    save->load(file, mode); \
}

and use it

MSaveFile* save = NULL;
MSaveFileGetNew(save, "someFile.sav", M_SAVE_FILE_BINARY);
if(save)
{
//...

Edit: renaming badly named example to what  implemented

Last edited by Nistur (2013-06-26 18:44:07)

MResource is interesting,
but once you registered a resource, how do you cast MResource* (in MSaveFileImpl* for example) ?
You still need a header for the plugin ?

ok, seems nice and it gives a practical approach for plugin extension,
good job.

What is your question ?
What do you mean embedding script ?