Search options (Page 1 of 18)

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.

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)

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*

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

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

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
    end
}

function onSceneUpdate()
    player.update()
end

with MScriptableBehaviour alone you can then do something like this:

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

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

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
    end,
}

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

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

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

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.

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

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

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.

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.

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.

Thanks! I'll PM you details

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.

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)

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?