Discussion: Subapps as Widgets and the Future

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.
  • Thanks for posting that, DragonMC.

    And thanks for your thoughts on the usefulness of Widgets, BREK.

    There is certainly a future in them and as we continue to see new Widgets that will cement the idea in.

    I am envisioning a future where, like extensions, Widgets will become more predominant, (and powerful) in future versions. It just seems logical and I am even surprised it has taken this long to get to the stage we are at and this forum area.

  • I wish widget creators were able to define a menu to control their widget, instead of passing parameters via alterable values and flags. If we could "code" a simple menu (more like cascading menus) to do simple things, like grouping the values together (such as "Position --> set x position to" would set Alterable Value A to whatever the user types there. Also, some "set glowing to on" would set flag 1 to on)... another cool thing would be an option in said menu to call a loop, or just inform the widget it has been selected so we could make functions.

    And a more efficient way to do "multi-widgets" (group many objects into one that is customizable with the menu I said). That way we could use widgets as functions, and even call some neat "click-scripts" to do stuff for us...

    That would really help remove clutter during programming... And it's real easy to code (I believe the menu could be coded into MMF in one day... maybe multi widgets in a week)

  • We have been pushing the Widget idea for a while and it is moving forward.

    Thanks to users who are creating them, it is slowly starting to sink in. It takes time and patience.

    Thanks for your ideas. I really hope that we will see some of the Widgeteers suggestions for making this easier to do, (and native in MMF) will make it into MMF3, at least.

  • I'm going to respond to the first question.

    Quote

    Also, now that we see that Widgets can be as useful as extensions are, what might we consider for the future? Should a future version of MMF allow for more specific ways to create Widgets that users can just plug into their apps and games? Do you have any ideas about the way you would like to see that implemented?


    It's pretty obvious what the optimal way to achieve this would be really. It's going to be slightly complicated to explain, but it's with no doubt the best solution.

    Instead of just "Objects", I'd like to split those up in two separate parts. "Components" which are grouped into "Objects".

    For example, the alterable values should be a component. The function of an Active object to display animations and store graphics should be a separate component too. All extensions should also be components. Then, if you e.g. group together an "Active" component with an "Alterable Values" component, you get an active object with alterable values. However, you'd also be able to group together an "Active" component with an "Array" component to create an active object with an array to hold it's values. You should be able to combine loads of components, e.g. several "Actives", into more complex objects.

    Of course, it would be relatively easy this way to customize an object with behaviours to serve as advanced widges, since you can really pack as many different features you want into an object.

    The main point of this is however how incredibly easy object selection with linked objects would be. If I'd mysteriously have to link an Active to an Ini, I could filter the entire object by an Ini related condition, and still perform the actual change to the Active component.

    This basically gets rid of all fastloop usage that you have to use today to link objects together, and although I know that a few people who have figured out fastloops will go "use fastloops, they're really powerful", they're in fact really slow, particularily when a lot of them needs to be used, or when you need to iterate through a large number of objects. Imagine the uses, group a string over a active to get text with a graphical background (e.g. speech bubble) that can be treated as a single object, or group a bunch of body parts together to create a single enemy object.

  • Alterable values position editor -

    If you have alterables it's really annoying if you want to move them around or have values require notes etc. What i think would be nice is if there was a window/panel you could open via the 'values' with a edit list button that basically gave you the list of alterables for the object etc. Then you would click a alterable from the list and you could click a move up/down button or better yet just drag and drop it to change it's position. You could also name them all but without it showing in the main Values list so this way you could see the name when using events. For example your alterables list would be only values the user would need to edit but others you could use for maths and value storage etc.

    Another useful thing would be to be able to give them a description, it would show where you see the title and then 'click to edit' and this way if you were making widgets you could describe what the value was doing. You could also describle to the user what value ranges to use or what a int vlaue would change etc. If this was added working with widgets would be really simple and much faster to make or edit them.

  • Also, furthering nifflas' idea, it would save memory for MMF, since some times you create actives as storage holders, and while they need arrays and alt. values, they don't need animations.

    Same goes for collision detectors, health bars, bullets, and many other things actives are used for. A person will rarely use all the functions of all the active objects in their game. Stripping the unneeded functionalities depending on what you want from the object would save a ton of memory!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!