ID:2392322
 
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
So, this is somewhat a two-part request, and it's entirely dependent on the first request.

I think it would be nifty if we could have a new file-type that's just like a .dmf, but it's only a standalone window. So, no macro/menu stuff. No multiple windows either. It would be a standalone single interface window. The ideal of this is so that you could have a standalone interface window file and just plug'n'play it into an existing environment or modify just a single window and not have to modify a whole existing .dmf.
The most ideal practice of this would be library creators. Something like this would allow us to make a library that specifically uses interface objects and have it so other users can use the library without the need of trying to copy a library's interface object into their existing .dmf. Hypothetically let's say you make a library for creating custom in-game pixels and you used an array of buttons for the custom colors or even the pixels. Imagine trying to copy every single button object from one interface from a library into another interface.

If that's not feasible, can we at least get an Import Object feature so we can open a .dmf and Import an interface window (with complete objects like maps/grids/buttons/etc. into the .dmf?





Long story short: standalone .dmf window file. Acts exactly like a regular .dmf window (grids, buttons, labels, etc) but imagine that single window was it's own file. Handy for library creators.
This should do what you want.

That code can generate a raw .dm file that can entirely take the place of a .dmf file. The resulting .dm file will generate the entire interface at runtime, so it won't happen instantly, unless world.fps is set very high.

Please test this out when you get the chance. Let me know if you encounter any bugs. I think it's a really cool concept, so I might make it a library if I decide to try parsing .dmf files.
Generating the interface window via run-time was already considered. I'm trying to just remove any "middle-man" workarounds for something that honestly should already be a feature.

The main reason for the request is for library creators that use interfaces for their library. Generating .dmf files via run-time means every library creator would need to do that.
In response to Maximus_Alex2003
That's why I'm moving away from using .dmf files at all. Why do I need to include .dmf files if I can have the flexibility of generating my interface at runtime, whenever I want?