It’s an extension of the existing property system where you will be able to do things like:
go.property("my_atlas", resource.atlas("/atlas.atlas"))
function init(self)
go.set("#sprite", "image", self.my_atlas)
end
In the properties view of the editor you would get a file browser button next to the “My Atlas” property. There will be a number of different resource types that you can set as a property: material, font, atlas, texture, tile source etc
We will start small and release an alpha. We would initially aim for a system where you can hook in your custom scripts for various kinds of triggers within the editor: on file change, on menu interaction, on right clicking an item in the asset view, pre/post build and bundle and so on. You will get some context specific input, run your code and produce some output. For certain hooks you’ll be able to generate menu items. It is very likely that the scripting would be done using Lua (with possibility to run other processes using os.execute()).
So setting the texture property at runtime (go.set() and properties list in factory.create()) would allow changing the texture resource (different resource path) and not just copy from the property texture into the current texture pixel data?
Great, really excited about a roadmap 
few questions ofc: What platform did you mean? Would it be Switch? Or PS4/XBO? How the iOS simulator will work? Will it be a standalone program? Windows/Linux support? Will resource properties be applied to particlefxs too?
We have looked at two different consoles but we have not decided on anything. We would really like to add a console to our range of target platforms, but it all depends on our other priorities for the Defold product as a whole. No promises can be made so please consider it a great bonus if it will happen, do not count on it!
It will be a separate bundle target. @sven knows more.
What do you mean by this? For the iOS simulator?
Not sure. I’d have to check that on Monday and get back to you.
Yes, you would be able to update the resource path of a sprite with a new texture, defined as a script property.
I will!
Yes, as I was imagining it as a separated program, but it will come with editor then, right? I would like to thank you in advance for it, because it allows many people, like me, to try to test a project like on Apple’s devices before investing 
Very noble
Love love love!!!
No this is referring to the Xcode iOS simulator. You will still need an osx machine to use it.
This is still super useful for example to test your app at different resolution if you don’t have the physical device.
Is the possibility for localized UV space for sprites on the radar? Currently if I apply a gradient effect based on UV space it goes over the entire area of the atlas and not just the area of the sprite.
We would need to expose atlas size and Sprite texture size via vertex attributes due to batching. individual Atlas images can be rotated so i guess that information is needed aswell. Is this a common feature that people would find useful?
+1
Yes, it would be extremely useful for all kinds of shading effects. There are a variety of common shader effects that are possible in Godot or Unity but not so easily in Defold. You should ask your technical artists about it…
Consider too the problem of applying normal map to sprites to light them like with http://www.snakehillgames.com/spritelamp/ I’ve tried hacky ways of doing it but nothing good enough especially with rotation of sprites.
Alright, case and point 
Not sure if we can allocate time for it soon, but there’s an exploration friday next week so maybe I’ll dig into it then!
Yeah, there have been many moments when I needed localized UV space. I would just send the center of the sprite as a uniform and compare the vertex positions with that to determine which corner is which.
@jhonny.goransson You don’t need all that information. Just a vertex attribute that is (0,0) in the bottom-left corner of the sprite and (1,1) in the top-right corner of the sprite, regardless of the actual UV coordinates in the atlas. The rest can be inferred from these values, if needed.
Usage example: Masking or gradient-ing a texture for a HP bar
Yeah, you’re right, you wouldn’t use those coordinates to sample the texture anyway.
I think, what we’d really like (and we’re also getting closer to) is custom vertex formats.
I think it’s better we work towards that, instead of adding another specialised solution?
We’d have to discuss it of course, maybe the two features doesn’t collide codewise, but we also have to consider our bandwidth.
I’ve been thinking… 
Now that we have local vertex space support, you can get that number that I mentioned by dividing the vertex positions by the sprite’s size, then adding 0.5.
Worth mentioning is that local space is currently only available for models, iirc! (And it will break batching!)