Search options (Page 2 of 18)

MRecast
link
Currently does nothing. Just a placeholder for when it does

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

Right, sorry about the delay. I've checked up on the multiple scripts issue. I have an empty project that has three scripts in it, scripts/main.lua scripts/camera.lua and behaviors/camera.lua which, with the exception of main.lua (which also has a single dofile in it) all they do is print their own name. I have a cube with the camera behaviour added to it, and all 3 scripts print. I can't produce a crash at all.

Could you please zip up a sample that crashes for you please?

Edit: I also tried using the script you provided
Update: Updated MScriptableBehaviour to include extended lua API

Whaaaa? I have to admit that I didn't test this, but I didn't think it would be a problem because, I _thought_ it should default to looking in the scripts folder.

Curiouser and curiouser.

Right. I have some use cases to test out. I'll get back to you with this

In other news, I almost have the "extended" MScriptBehaviour working. I have the lua looking like it's working, but the problem is currently that the way I'm embedding the file doesn't null terminate the file, so I'm either going to have to pass a size through to MScript when loading it, or stick a 0 byte at the end. Neither of which are particularly difficult, I just need to decide which. Null terminating would make most sense perhaps, but if I can pass through the size, because I'm using luaL_loadbuffer rather than lua_dostring then it means that I can embed compiled lua scripts in release builds which means smaller executables and (in theory) faster loading times.

The way that the extended MScriptableBehaviour will work is as follows:

MScriptableBehaviour "player" {
    health = 10,
    onBegin = function()
        self.speed = 12
    end,

    update = function()
        move(self.speed)
        if hit then
            self.health = self.health - 1
        end
    end,

    onEnd = function()
    end,
}

The system no longer passes through the object or behaviour IDs. they are stored inside the behaviour and can be retrieved with self.__id.object and self.__id.behaviour The reason behind this is that they shouldn't be used eventually (of course, initially they will be) but I'm hoping that someone will take my code and extend the lua MScriptableBehaviour and add in wrappers for all of these in the embedded script so from a behaviour you could just do something such as

self:setScale({10, 10, 10})

and you wouldn't have to worry about the IDs at all.

Anyway, a few more tests before that one gets submitted, but the script is almost all there. Just need to get the file loading to work

Oops, try again, I forgot to push the changes to github. onBegin was never being called. Sorry

Note: you can't currently use MScriptableBehaviour for multiple objects like this easily. But I had a thought, you could do something like this:

Script1_objects = {}
Script1 = {
    onBegin = function(object, behaviorID)
        Script1_objects[object] = {}
        Script1_objects[object].speed = 3
    end,

    update = function(object, behaviorID)
        -- do something with Script1_objects[object].speed
    end,
}

I'll try and make this a bit "friendlier" but right now there's not much else I can do

MScriptExt
link
Extensions to internal MScript system. Almost no changes have been made at this stage. The one enhancement is that, if run with MEvent it will send the event MScriptInit* which can be used by plugins to extend the lua environment by adding scripts after the base environment has been created but before the main script has been loaded.

*name not consistent with other events. Need to decide what to use

MEvent should now fire off "publish" which will be translated through to lua as "editor.publish". MScriptExt now has an editor script which should be automatically loaded and will allow the following:

local test_publish_event_function = function()
    print("test publish event function")
end

local test_publish_event_table =
{
    publish = function()
        print("test publish event function")
    end
}

editor.publish_event(test_publish_event_function)
editor.publish_event(test_publish_event_table)

Also, MScriptExt will search for all lua files within editor/ and load them (NOTE: currently this does this even when not running in editor, so it might be best to add if isEditor() then ... end around any editor scripts) This means that things such as publish events, which don't need to be published themselves, can be placed in editor scripts. Editor scripts can also be added to plugins to allow for flexibility to package their data however they see best.

Changelog
22.07.13 Added editor scripts and supported publish events
11.07.13 Updated to use luaL_loadbuffer within ::parse and added MResource interface

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

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

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"

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.

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