Sure nifflas, but if that's implemented for MMF3, it can be programmed straight into the SDK, so there will be no need to remake extensions...
Also, porting to java/flash would be a lot easier, since there won't be any access violations or anything.
Sure nifflas, but if that's implemented for MMF3, it can be programmed straight into the SDK, so there will be no need to remake extensions...
Also, porting to java/flash would be a lot easier, since there won't be any access violations or anything.
What? Nifflas is right..Originally Posted by Fimbul
Really not all extension need to have this behavior only those that exchange data.
Regards,
Fernando Vivolo
... new things are coming ...
Well, all extensions with file I/O capabilities then, but I thought that was kind of obvious
I'd love to see a better framework for objects to share data and communicate directly. I've had a lot of interest lately in inter-extension communication, mostly focusing on "glue libraries".
I think there still needs to be some mechanism in the middle that allows the developer to apply appropriate transformations to data if the intention is to share between extensions directly, because in general extension authors can't predict ahead of time exactly what you want to do with their output. I guess the event editor itself technically fills this role but that's not always possible or practical.
Eh, sorry, I made a mess trying to get my point across...What? Nifflas is right..
What I meant to say is: no extensions will have to be updated if the SDK for MMF3 has it from the start. This way, all extensions made will already have that feature.
Unless of course you're talking about porting mmf2 extensions to mmf3, but I know nothing about that.
You don't understand how it works though. If the SDK is updated to support some kind of internal memory storage shared between all extensions (which would be awesome), the extensions must be changed to take advantage of those SDK features. Even an SDK can't be made to catch the extension's file I/O abilities and do something else with them.
I think you're misunderstanding some stuff about how an SDK work. They don't have superpowers.
I'm trying to say it would be easier to leave that for MMF3's SDK instead of yet another update, and yet another mass conversion job (remember clickteam is already converting stuff for java, flash and HWA).
Instead of converting stuff, new extension developers would have to use that function, since it's built into the sdk.
Instead of writing that I just wrote a bunch of weird stuff... guess I was sleepy or something... I understand how an SDK works nifflas.
By the way, whatever happened to MMF3D? Everyone just talks about mmf3!
Ah, okey, that makes more sense. I can't say I disagree though (actually, both my first two posts about this feature mentions that it would make most sense in MMF3).
It's already possible to share memory between extensions, as they all run under the same process.
Posting Permissions
Reply With Quote