This forum is read only and just serves as an archive. If you have any questions, please post them on

1 decade ago by jerev

[Edit: Sorry to hijack your post. If you get the newest version of Impact from your git repo, you don't have to modify the weltmeister.js anymore to load plugins. See this post below for the details ~ Dominic]

Thanks to Dominic the "hack" described in this post is no longer required if you work with the latest build from the repo on your download page. Therefor I have removed it. But there still is a version of it on the github page.

My plugins can be found on here and feel free to send me a pull request if you made some yourself.

Some info about my plugins can be found below.

1 decade ago by jerev

You can't always simply extend on the base methods without breaking them open, for this reason I recommend that we think towards the future.

When working on my level-properties plugin, I realized we could have extra data that needed to be saved, so I made a helper inject, so when the base save method would change, we only have to keep the changes to that method up to date in ONE helper file.



	saveExtra: function( data ) { // this we can inject and use to alter the data object. Which is used for saving.

	save: function( dialog, path ) {

        var data = {
            'entities': this.entities.getSaveData(),
            'layer': []
        this.saveExtra( data );



1 decade ago by jerev

When working with new shortcuts, I'd recommend an approach like this:

var found = false;
for(var a in wm.config.binds) {
	if(wm.config.binds[a] == "floodfill") {
		found = true;
if(!found) wm.config.binds.F = "floodfill";

This allows you to set a default key, without having to change the config.js file. And also allows the user to set his own keybind, in config.js

1 decade ago by jerev

Now, to finish this post, I'm releasing some of my plugins, which follow the above approach.


Some may remember I released this before, some months ago. But it was a very messy implementation.

Basically, it allows you to set properties, level based. I used to create an "info" entity for this, but I personally find this a cleaner solution.

I'm sure everyone can find a use for this, for example, the number of lives you get in a certain level. The name you want to show upon load, etc.

A little example usage can be found here:


A simple plugin, which allows you to toggle labels on and off, can be useful.. once in a while.
The default keybind is L but you can alter your config.js to include a new keybind, the action name is labels, example:

'binds': {
'B' : 'labels'


Something I&039;ve needed a lot. The default keybind is #F and actionname is floodfill, can be user modified in the same way as labels above.

Important to note: It'll floodfill on the position of your mouse cursor. Not on the position of your first brush tile.

A basic usage of floodfill can be seen here:

There is also an advanced feature, say that you have a couple tiles you want to iterate between. Well, here comes using a multi-tile brush into use.

If you use a brush like [0] [0] [0] [0] [1], it'll randomize in this proportion. So basically, you'll have 20% tile 1, and 80% tile 0, if a random were completely random.

A brush like [0] [1] would give 50% of both, etc. See usage here:

Also note, this plugin works with the undo/redo history. So you can easily undo/fill/undo/fill until you get a randomization you like. Etc.

Does not link with collision layer, yet.




See first post for more detailed info, but to recap:

1. Comment the two loader lines at the bottom of weltmeister.js
2. Change the weltmeister.html file, to use the loader.js instead of weltmeister.js
3. You can enable and disable plugins by modifying the loader.js


Feedback and suggestions welcome.

1 decade ago by dclowd9901

Actually, thinking toward the future would be considering the usage of decorators and function wrappers. We are working with Javascript after all.

At my day job, we created a classing mechanism that operates a lot like Resig's lightweight Javascript classes (which Impact is based on), only with it, we could also decorate classes before their initialization, immediately after, or even wrap code into parent code (using mechanisms in Underscore/Lodash like _.wrap())

.inject is nice for extending, but true extending means we don't have to blow away the parent function altogether.

When I was recently extending Weltmeister to build a bezier drawing mechanism, I found myself doing many of the things you were doing (duplicating methods for specific purposes), and it didn't feel clean or robust. What if someone wanted to extend on what I had made? It's too brittle.

This is a good start of the discussion, though, and I hope Dom drops by to give his .02

1 decade ago by afflicto

+1 for this.

1 decade ago by Ash_Blue

+1 for this amazing post. Would love to hear on Dominic about future proofing. Particularly what is to come with the next ImpactJS version and 2.0.

1 decade ago by dominic

The current dev version of Weltmeister (from the git repo on your download page) includes a new config var to easily load plugins. You don&039;t have to modify the #weltmeister.js anymore as it is described in the first post.

Simply add the module names for the plugins to the plugins array in lib/weltmeister/config.js. E.g.:


// Plugins for Weltmeister: an array of module names to load
plugins: ['', 'weltmeister.plugins.floodfill'],


1 decade ago by jerev

Quote from dominic
The current dev version of Weltmeister (from the git repo on your download page) includes a new config var to easily load plugins.

Very cool, i have updated my post and github repo to reflect this change.

6 years ago by Joncom

This flood-fill plugin is super useful. Thanks :)
Page 1 of 1
« first « previous next › last »