XLua, MMF2 Extension

Up to this point I've been bantering about the CCC about this. With bugging from Xgoff, I've created yet another lua object for MMF2 standard and dev - the XLua object.

The intention is that this object is more stable than the other two Lua objects available. So far it seems to be holding up. The feature set is also a little richer.

You can download the extension at: http://hocuspocus.taloncrossing.com/rii/xlua-dist.zip

Documentation is included

This post has been edited by Retriever II on Mar 1 2009, 11:02 PM

so will you still be taking requests for interface functions

You can request them as you see fit, although collision items are on hold for now. Also don't forget with this built to call "Enable MMF Interface".

nah just things like set/get objects' z-index and set objects' layer

... eventually setting/getting HWA-related things but obviously that's a little ways off

but damn this extension is so much nicer than lua+ because it's stable... and not broken

EDIT: when are you supposed to call the mmf interface enable function... because i don't think my objects are exporting correctly with this build

previous version this version

no script changes between those

EDIT2: also in the help file, you forgot to change SetFlag to SetPosition on the latter's page

This post has been edited by Xgoff on Feb 25 2009, 12:41 AM

It should be called before you use any interface functions, but it shouldn't affect exports. Perhaps you could send me an example?

trying to reproduce it atm but i can't

so i dunno, unless you fixed some bug i was unknowingly taking advantage of

EDIT: that floating mario is like 22 overlapping objects that are still in the same place/default anim frame as they were created, so SOMETHING is ignoring them

This post has been edited by Xgoff on Feb 25 2009, 11:10 AM

Well your speed test works fine and a test I composed works fine. It didn't matter if I enabled the interface before or after loading the lua script. I guess try scrubbing it a bit more.

EDIT: nvm

yeah somehow one of my actions in mmf got deleted and multiple objects ended up being exported at one time. fff

why the behavior of that would change (especially when calling an irrelevant function) is beyond me

This post has been edited by Xgoff on Feb 25 2009, 12:36 PM

i'm really going to use this sometime and learn Lua


it'd probably be useful for the thing i'm working on now

My ability to manipulate objects is a little more limit than I first perceived. In the next build I'm going to remove the SetString functions for globals and alterable strings since I've discovered (by browsing the real SDK ... rSDK didn't include a lot of critical documentation) that the current methods are dangerous.

Speaking of rSDK, the type of documentation it stripped from the real SDK are things like "The runtime structure will not call your C++ constructors" and "MMF will free the string memory at the end of your expression".

Also it appears there's no way for me to get the current Z Order, let alone set it (the one place with a Z Order field only applies to edit-time order). I feel horribly teased because there's DLL functions sitting in front of me that correspond to all the standard actions, like "MoveSpriteToFront", "MoveSpriteBehind", and "SpriteCol_TestSprite" (sprite-sprite collision test). However, the SDK doesn't expose any method to get the necessary sprite handles to use these functions.

And as far as Clickteam is concerned, the SDK structures are sacred and we shouldn't be sticking our noses there to begin with.

Maybe at least for Z Order there is still something I'm missing. After all, there is the Layer Object, and it can do all those manipulations. I haven't found it yet.

Oh holy crap I overlooked an alternative typedef of the Sprite entry (I dunno why clickteam defines like .. 3 equivilent typedefs of things). This could be interesting.

Edit: Well, I'm finding a lot of things just not working. I was expecting to add a full suite of reordering functions, but the To Front / To Back plain don't do anything, Move Below works, but Move Above crashes if you try to move the lowest object .. so I've excluded all of them. Swap Objects crashes under the same condition. Set Layer also does absolutely nothing. The most I can give you is Object.IsAbove" and Object.IsBelow, which actually work, unless I learn something new about these DLL functions.

I've updated the release. In addition to the two aforementioned functions, I've added Object.GetZOrder, Object.GetVisibility and Object.SetVisibility. I've removed Object.SetString and Global.SetString. The documentation has been updated.

This post has been edited by Retriever II on Feb 26 2009, 03:43 AM

well hopefully all that is possible to do in some fashion... i'd rather have an extension that's less efficient than it could be but still much faster than a workaround implemented in mmf or lua, especially when you get into collisions

i'm not too worried about z-ordering atm since i'm not going to use that a whole lot

like i've said before, i'm trying to avoid calling functions in mmf, because that's 60 function calls per object per second per 'interface faking' function; not fun

sorry if i'm being really naggy about some of this, but if i'm forced into using SDL or SFML for mpuz before getting an mmf2 version done, there's no way in hell i'll be able to finish it

EDIT: are the removals of string setting temporary? i likely won't use them myself but who knows

EDIT 2: actually what i'm going to do right now (and by 'right now' i mean over development time) is just finish the engine, make a few test levels, and see where i'm standing as far as performance is concerned... right now i'm worrying over things that might not even be an issue (except for really obvious realtime stuff); however i do know object collisions will be annoying to deal with for now

This post has been edited by Xgoff on Feb 27 2009, 12:38 AM

I will have to experiment with object collisions. But once I release XLua on Clickteam, you may need to gun for some of the interface information because right now I'm obviously missing something that's causing the majority of these DLL functions to be useless. Problem is the Clickteam community in general is opposed to this stuff.

Removal of string setting is quasi-permanent, unless I learn that I can safely change or reallocate the pointer. Stomping MMF's memory management is only going to stomp me back in the end.

oh god don't get me started

Once I'm done with my level editor, I'll probably have a deeper look at this!

Released a new distribution (http://hocuspocus.taloncrossing.com/rii/xlua-dist.zip)

This distribution is built with LuaJIT sources, although the engine is off by default. I still have the non-JIT extension on hand in case this turns out to be a bad idea, but it could also be a big help to applications that want to offload AI processing or other significant crap that MMF is flat-out miserable at.

Other changes include better error reporting. When running a string or file, runtime errors will now be caught and reported, rather than just syntax errors. Before, errors were only caught when doing a lua call.

The "print" statement is now overridden to act just like error reporting, as in there is an "on print" condition and "get print string" expression.

This post has been edited by Retriever II on Feb 28 2009, 12:49 AM

... how'd i forget about suggesting something for print

seeing as i make mmf functions that basically duplicate it

The native method isn't really any faster, but it lets you run existing lua code that already uses native print.

no but it saves me the 2 seconds of registering a function

although the print faking function i'm using now can take a string color argument so

Discovered some new information while scrubbing the SDK docs. I've now been able to add all the functions that I previously had to disable because they were dangerous or didn't work. They include:

Global.SetString
Object.MoveAbove
Object.MoveBelow
Object.MoveToBack
Object.MoveToFront
Object.SetLayer
Object.SetString
Object.SwapOrder

Basically the layer object embedded into the interface. This is encouraging for maybe adding more collision routines (although I don't think I can give you exactly what you want).

I think I'm also safely setting strings now. But if they end up causing crashing or other funny stuff again, they'll be axed for all eternity.

Link updated: http://hocuspocus.taloncrossing.com/rii/xlua-rc.zip
Documentation updated

This post has been edited by Retriever II on Feb 28 2009, 04:48 AM