Posts by Atom

Hi, i hope your having a great day.

I wanted to let you all know about a new social network like facebook called Please login to see this link. that pays users for content. It's a really great place to promote your indie games and artwork online, plus you earn money the more content you post which is nice. I would love to see some of the great game devs here posting there.

You need a invite to join so just click the following link Please login to see this link. and sign up, if you have already been invited add me as a friend.

It's been a while since i last was here but i have to say V2.5 sounds like it will be great

Quote from James

The edit-time side of extension development is definitely a problem, and it's something we intend to address in MMF3.

That sounds good, i haven't been using MMF2 recently but i have made a few extensions however they didn't really have much in the way of edit-time options so being able to easily make those would be great.

For the edit-time one thing i always thought was missing was sub-folders (Multi layer folders) for objects, hopefully that will be in the next version also.

On the subject of edit-time data it would be nice if we could make edit-time only plugins also. So for example there would be a api which allowed us to get the currently selected objects to an array and then randomize or tile the positions and so on. Unity allows this and i think it gives that editor a lot of power because people make that type of thing and also more complex things like path/curve editors where there is also visual elements so maybe if MMF3 does this also you could have a surface which coders could use to draw/blit geometry and text etc. That would allow coders to make custom tile editors etc in the main program with ease rather than the need for external tools.

That would be good, it should not replace the current exporter however but rather be an additional runtime which is free to everyone who owns the flash exporter.

The reason is as you say for the demo it requires flash player 11 or higher so you could no longer export to older flash player versions.

Quote from Nifflas

Remove support for every image/video/music format that isn't essential (gifs are 1995, mod/xm/it are cool but the player lacks options for setting interpolation algorithm, following song position commands or not cutting the notes when the song loops, why should it be supported at all?

Quote from Simon

To that end I also disagree with the notion of cutting down on number of supported file formats etc. These things can add richness to applications and a clever design need not exclude features such as this. Lots of people use the product in lots of different ways, it is really important to think outside of one's own box when contemplating such a product.

I think having a SDK for file formats and making them similar to the way extensions work would be better. That way everything is modular and usage is optional so if there was a new image format which appeared one day for example and people then wanted support for it the SDK could just be used and people would simply place a file in a folder then the format would be available to use.

Quote from MattEsch

If I were writing MMF3 I would start fresh and ignore everything. It would, as I have already ranted about, be written in HTML5. It would end up on your desktop in a native wrapper, so you would never know. It wouldn't feel like a website, but run like a native application.

Like others here i don't agree with this, HTML5 is good as a export choice and maybe even built in for some things like being able to make custom dialogs based on HTML/canvas. However it's not a good idea to base the whole program and all export modes around HTML5. Something like C++ with SDL/SFML which has OpenGL enabled would be much better for the editime/runtime and the EXE export.

I am not sure why anyone would want them if they had native exporters but as long as HTML5 was a export mode you could have both. Since you can export HTML5 to various wrappers i see no harm in additionally having that with a HTML5 sub menu for Web, Native and all of the PhoneGap/Cordova etc formats. The current system is good though and i would much rather have real native exporters than wrappers any day.

Quote from Nifflas

Yet, Unity dares to focus more on one side and they're doing excellent. I'd say having a better and more focused game dev tool is OK even at the cost of losing some of our users. On the other hand, I'm disposable too, maybe MMF3 should go much more towards software development so those kind of users gets all the features they need and I'll switch to another game platform. Focus on something and try to be excellent. I just don't think it should try hard to be everything, the most successful game platforms clearly does not - and I'm pretty sure that's why they're so good.

I agree that MMF3 should take a more minimal but more low level approach but i think it should at least have a set of standard GUI elements and events for application development still. With GUI controls they should NOT be windows control based as in MMF2 next time around and they should have the option for custom skin images. That way app developers remain happy, controls would port to all platforms and game developers can still make use of them in option menus etc.

The base extensions should all be open-source and as you say 3rd party devs can make other extensions like with MMF2 now while the main developers work on the actual program. Clickteam should maybe hire a few extra coders dedicated to certain tasks like exporters and extension development, this way the base program is enhanced and at the same time so is features and it's not only aimed towards games so everyone remains happy.

With extension development if things are done well next time with the SDK it should mean making things is much less time consuming for developers. Clickteam needs to put a lot of time into the base of the program, the SDKs and try to focus on making things modular and expandable then all of that work will in turn save loads of time later down the line.

With Unity for example you can make additional dialogs, connect to basically everything, get data back from the editor and scene etc and even code extensions in multiple programming languages. So now they have a load of 3rd party developers making things which are so complex such as shader/events editors, model editors etc they are almost like new programs altogether and this is just down to the fact they designed for modularity and the scripting to be very flexible for 3rd party developers. That has definitely worked out well for them and they even have professional game studios which used to make there own custom engines now using it instead because they can design it around the workflows the development team uses and easily create new tools when they are needed.

As long as having MMF3 installed does not mess with the MMF2 installation then backwards compatibility is not important.

As well as a better SDK next time around what i would like to see is a way to code the GUI like Unity allows, so for example i add in a script which gives me a new right click menu option or add in a custom menu tab which opened a custom dialog and so on...

These days i am not using MMF2 much and just directly code everything now (AS3, AIR and Java mainly) however so i am just waiting to see what MMF3 does differently and if it will be of use to me.

Thanks

My guess is that Crysis2 would use something like OpenGL or DirectX so try using HWA or different runtime options and things will go faster. Even if you are coding with C++ etc you can have slowness with games just the same if you don't optimize so rather than blame the tool try and learn how to use it better instead.

Rather than 3D Mesh with a updated Irrlicht it would probably be better to just remake it with a modern multi 3d import library like Open Asset Import Library which uses D3D9 for rendering.

From the sourceforge project page:

"Importer library to import assets from different common 3D file formats such as Collada, Blend, Obj, X, 3DS, LWO, MD5, MD2, MD3, MDL, MS3D and a lot of other formats. The data is stored in an own in-memory data-format, which can be easily processed"

Reads more than 30 3D file formats, including Collada, X, 3DS, Blend, Obj
Converts them to a hierarchical in-memory data structure
Provides 'post-processing steps' to improve the input data, i.e. generate normals and tangents or fix import issues.
Provides APIs for both C and C++
Imports skeleton animations and skinning weights
Supports complex multi-layer materials
Windows-based model viewer, the library itself is portable

Yes

Apparently it will go into beta testing very soon.

The bitmap.smoothing and stage quality settings in AS3 can lower the FPS depending on whats being done so it should have a property also.

However if a line of code makes the graphics nicer clickteam should just update the code rather than people having to use that .dat decompiler program.

I think this can only be a good idea myself, surely the more languages supported the bigger the possible user base for MMF2...

Since this is a Clickteam made object you could include this with future versions of MMF2.

I guessed you could somehow, i don't know how to though. If it's easy i would appreciate it if you could add some quick examples with DarkEDIF. I mainly wanted to use them with the JSON setup you were adding though like i suggested in post #14 which would be great if it's possible.

ok no problem, well if you ever have some free time to add these features that would be really useful, thanks.

It wouldn't directly, if you wanted the program communicate the results with the extension you could for example make it generate a string which you would then copy and paste in for a input in the event editor etc.

Edit - The programs programs could do anything you wanted though so they could for example read and modify local files from MMF2 folders like langauge INI's or text presets etc, it would just be a nicer and much quicker way of running helper programs that do certain tasks.

For a really simple idea of what i mean add the XLua object to the frame, go to the first page of it's Properties and there should be a button that says "Edit", click that and it will make a window appear where you can then code with LUA. Other objects to test that have custom windows which either after getting added, double clicked or pressing a "Edit" button in the About pages are Flame Object, Active Gradient object, Color Selector and the Blowfish Object but i am sure there are others also.

Put simply my idea is rather than built in windows appearing it would be a .exe that loads instead.

Quote from LB

I can do one better; make it an action that you click in the action menu that runs the program and when the program finishes the action is already set up to load the map

That is a great idea, running exe's directly from the action menu will be really great also and that is the main part where this type of feature would be most useful but for some reason i had not even thought of doing that before. Being able to launch a exe from the object properties would still be useful also if you just wanted to quickly launch something for whatever reason. If you could give some quick SDK examples for doing both of these when you release the SDK that would be helpful.

Thanks Phi, this SDK is going to be the best yet.

Thanks Phi that sounds great

For my first point i basically just mean in the JSON you would add some code to add a edittime button that appears in the properties (which sounds like the current plan), however when pressed it would then launch a EXE you had in a Data\Runtime extension folder or some other MMF2 folder which the SDK would be able to find.

I am not sure how you will be doing the GUI controls in the JSON code but with a quick guess for the button to run a exe you could maybe have something like this -

"Editor Properties":
[
[0, 'Value Input' , 'Name:Test 001', 'Min:0', 'Max:100', 'Default:0'] // Some other control
[1, 'Value Input' , 'Name:Test 001', 'Min:0', 'Max:100', 'Default:0'] // Some other control
[2, 'Button' , 'Name:Run Map Editor', 'OnClick: Load('Data\Runtime\ExtName\MapEditor.exe');'] // The button that loads the EXE you want
]

Then with MapEditor.exe (or any other exe you wanted) you would just use it for whatever you needed like a helper tool, in this case to make a map file that could be saved and loaded with the extension actions etc.

I guess my idea would just be a way of running helper apps that would normally be external tools but if you added in a way for extensions to load properties from files also they could get saved data back also and work together as if the EXE was a dialog from the extensions properties.

With my second suggestion i mentioned a external TXT/INI file based preset system which would be great but another useful thing you could do with the EXE launching would be to directly manage those TXT/INI files to add.remove a preset etc. It sounds like you wanted Multi-linguistic INI's so i guess you could do basically the same thing same again with that and launch a EXE tool to directly manage them also.