Forums » Impact Engine » static paths

I'm currently integrating impact with Node JS and i'm hitting a lot of painful bumps, which are caused by the static nature of how Impact is currently statically loading files.

To get this to work the right way, I had to modify impact.js:

var scripts = document.getElementsByTagName('script'),
    matchRe = /impact\.js$/,
    match, scriptSrc, i, ln, scriptPath;
for (i = 0, ln = scripts.length; i < ln; i++) {
    scriptSrc = scripts[i].src;
    match = scriptSrc.match(matchRe);
    if (match) {
        scriptPath = scriptSrc.substring(0, scriptSrc.length - match[0].length);
        scriptPath = scriptPath.replace('lib/impact/', '', '');
        break;
    }
}

window.ig = {
    scriptPath: scriptPath,
    /*...*/
      addResource: function (resource) {    resource.path = ig.scriptPath + resource.path;
        ig.resources.push(resource);
    },

I have not started to look at how weltmeister does what it does. Seems that it's using absolute paths too.

On a side note:
Do you guys have a process for adding people as contributors to the project? There is a lot of JavaScript cleanup that can be done to enhance readability and sometimes performance.

FML. I can't edit the thread above to fix the formatting.

Also modified debug/menu.js

	init: function() {
		// Inject the Stylesheet
		var style = ig.$new('link');
		style.rel = 'stylesheet';
		style.type = 'text/css';
		style.href = ig.scriptPath + 'lib/impact/debug/debug.css';
		ig.$('body')[0].appendChild( style );

You should be able to edit. Hover over your name link area and the Edit link should appear.

yes. It seems the formatting does not get resolved .:-\

I'd note that you're not going to be using the dev build in a deployed fashion (it's actually contrary to the licence, AFAIK) and that for production use you're generally supposed to use the bake script to create a minified, single file that contains everything statically loaded and linked...

Have to say I'm not entirely sure I'm seeing what difference the code is supposed to make :/

I'm not deploying it (yet).

The problem is that impact is not smart enough to understand where to really load resources if they are outside of the root of the web server. In server side technologies, often times, you have to place items in a plubic directory.

This fundamental limitation is a problem to those who want to deploy other stuff with impact even in dev. :)

jaygarcia, I am interested in knowing what kind of integration you are planning with node.js. Can you share any details?

The point is, Impact doesn't have to be. The resources by definition MUST be web accessible, because they're all loaded to the client up front. If half the files aren't web accessible, it's going to break regardless of anything else.

@MysteriousStranger

We're working on an Othello-style board game, which will require two-way communication with the server & client side.

@Arantor

I guess what you're not understanding is that even in dev-mode end developers should have the flexibility to place JavaScript where they want to. The framework should not hard-code resource locations.

I'm providing my $.02 because I want to help make Impact better. Not because I'm just bored :).

Want to change the expectation that everything's in lib/? Change the declaration of window.ig.lib much earlier in impact.js. You can't really do anything else since that file ultimately loads everything else, and it's only for the purposes of dev (bearing in mind that you can't expose the unbaked/unobfuscated source publicly anyway)

JS files are resolved based on the required module name, e.g. if the module is game.entities.player, it's going to look in game/entities/ for player.js - within the lib/ path mentioned above. Don't like that path? Rename the module, and the path it looks for will change. You have total control over the path.

As far as resources go like images and sounds, the path they accept is merely the one given to them, which is locally relative to where the script is. Impact doesn't do anything with that, it just hands it over to the browser. When a request asks for 'media/someimage.png', the browser is the one making the assumption that it's in a media subfolder of the current path. If that's not suitable, change it.

But that aside, you're missing my point. I don't know what crazy configuration you're working on, but if you're putting resources outside the web root, the rest of the internet cannot see them. Doesn't matter whether it's production or development at that point, it's still completely broken.

What Impact requests is a standard URL, it's up to the webserver to map that to some local content, but from the above, it seems that there's something more fundamentally wrong in your setup...

(EDIT TO ADD: Oh, and if you stick absolute paths instead of relative ones, that'll work too. Stick your media on a CDN if you prefer, it'll work just fine.)