Posts by Retriever2

Well, it's been a pretty long while since I've been around. I'm curious how this object has aged, what holes have opened up as the fusion platform has changed, etc.

Never, perhaps? I mean, it has effectively been defunct for about 2 years now.

It's too bad, I put a fair amount of effort into putting content on it along with a few other people.

Sure: Please login to see this link.

happygreenfrog: It is the XLua-specific fork of LuaGL, and that project is also on the above GitHub link.

Last I knew, coroutines should have been able to cross the event boundary. That's the main reason I haven't considered upgrading to LuaJIT 2 -- they removed the ability to propagate co-routines across the C API (and thus, across the event boundary). I don't remember if LuaJIT is enabled by default in the extension, but it probably needs to be.

There might be some XLua-specific tutorials floating around somewhere for working with coroutines. Possibly search the file archive.
Try here: Please login to see this link.

IMO it's only viable if you pair it with XLua, and even then it's very far from ideal. Jitted Lua is fast, but it's not exactly a first choice for writing a rendering engine.

Well that's quite curious. Even more curious, I haven't been using local Subversion for a couple years now, so that my workstation's local SVN server is still public and running is astounding.

Anyone is welcome to make use of the code resources in the repo if they wish -- I'm happy to make any of it available under the MIT license as I did with XLua (though apparently I only indicated that in the documentation). XLua is still maintained on my Github account.

Collision support has always been a little bit on the flaky side, especially if you're using the HWA runtime which didn't work, last I checked. Clickteam doesn't actually expose anything warm and fuzzy in the extension API to do collisions like I am, and I had to reverse engineer support for it by observation. If their underlying implementation has changed, then parts of it may no longer work.

Now with that out of the way, backdrop collision detection on layers other than Layer 1 is a very strange animal, because if I recall correctly the backdrop objects themselves are intrinsically different on layers >1. You could also try using the ANY_LAYER constraint to see if it's just a simple bug related to that, which I could fix easily. Otherwise you'll need to fall back to writing MMF functions to do this check for you.

You can PM me if you have other questions about XLua, as I don't regularly browse threads.

Someone reported a significant memory leak in this extension earlier today, if you create a lot of vectors/matrices from value. The download has been updated with a fix.

Sorry for a late response; I have been on vacation.

I could not reproduce your problem. Make sure you have the latest copy of mmfi.dll.

package.cpath = "./?.dll;./ext/?.dll"


require "mmfi"


function dim ()
	local act = mmf.newObject(1)
	act.inkEffect = mmf.INK_SEMI
	act.inkCoef = 64
end

Calling dim results in a half-transparent object.

That's odd. I definitely saw your post. Are we being censored for liking scripts now?

"Extensions written in events" is nothing more than wrapping up a set of events in a function or object.

It's nice organizational sugar, but it can't extend the capabilities of MMF beyond what it provides natively, so it's not a replacement for true extensions. Then again, if these things need to be ported across a dozen exporters, I'm not sure it's realistic to expect being able to add any new (portable) capabilities beyond what MMF provides natively.

Quote from RickyRombo

In my opinion, extension development is the best thing about MMF2

I have to take some issue with this, because of the exporter binge MMF has been going on for the last few years. With a possible exception for csurface manipulators, very few extensions are available for more than one exporter. If exporters are the current hot selling point of MMF, then you've lost the benefit of most 3rd party extension support.

Well, if you know someone willing to help me diagnose exceptions originating deep in the MMF runtime, I may see it through to a proper release.

Why is there anything to be sad about? As I mentioned, XLua is very mature. There have been almost no bug reports in the last year, and it's already feature-rich. I would still fix a bug now if someone found one. I just don't intend on any radical changes at this point.

I'm mainly posting this as a point of interest to other developers, in case they find it useful to developing other extensions.

Hello everyone,

I wanted to let all interested folks know that I have published XLua and all related sub-projects as an open source project. It is available at Please login to see this link.

I've reached a point where it is unlikely I will continue any heavy development on this project, although at this time I am still fully committed to supporting the core extension with bugfixes. There's a couple reasons for this. The first is that I've drifted away from Click as a platform, so there's little incentive to keep working on it (although this project has been an amazing experience for me, both personally and professionally). The second reason is that XLua is stable and mature, and there really isn't a lot that needs improvement.

I'm posting this project to strengthen my promise that it will not just become another abandoned, deprecated plugin, even if I completely disappear. I also hope that the code, which encompasses a couple years of research and experimentation with MMF's core, will be useful to other extension developers. If anyone is interested in contributing changes to XLua or one of its sub-projects, I highly encourage it and I'd love to hear from you.

A brief overview of what's included:

XLua
The core XLua extension. The internal editor is one area that may benefit from improvements.

XLua-Java
A port to the Java (non-mobile) runtime I started some time ago. It's almost totally complete, but suffers from a bug related to immediate events. I think someone close to the Java runtime would need to look at this. Please talk to me if you are such a person and are interested in seeing this finished.

XLua-MMFI
The loadable MMF-Interface which exposes direct access to many parts of MMF's internal object state, and is responsible for the huge speed increases obtainable. This is a place to look if you want to dig into mmfs2.dll in ways that are probably frowned upon. This project would benefit greatly from someone experienced with the HWA runtime (both exposing HWA features, and fixing pieces that just don't work in HWA).

XLua-OpenGL
This is the heavily modified copy of LuaGL for XLua. Only part (albeit a large part) of the OpenGL API is exposed, so someone could come along and continue fleshing that out.

XLua-Surface
This was an experimental helper extension for exposing direct CSurface drawing in Lua code. Development ended up colliding with the Surface extension, so I haven't really done much with it. It's here for completeness.

Everything listed at Please login to see this link. should be correct and up to date.

XLua ships with a help file and several example MFAs. However if you downloaded it via a third party extension manager, I cannot guarantee that those resources are getting passed along.

The editdata structure is indeed a nightmare when you introduce variable data. Especially when you introduce multiple sources of variable data.

Extension development stopped being friendly with the explosion of runtimes.

Are we going to see a physical update to the SDK, which hasn't been [publicly] updated since 2007?

There is no way to create objects directly from an extension. I would have killed for this to be included in the SDK (well, not that extreme).