Question regarding deprecated use of "module".

[richard9]

1. Variable names are just references (links) so they aren’t preserved in a displayGroup.

[code]local group = display.newGroup()
local monster = display.newImage(group, “dude.png”)
– you can now refer to this object as either “monster” or “group[1]”.

– if you want to keep the name you have to do this…
local group = display.newGroup()
group.monster = display.newImage(group, “dude.png”)
– in this example both “group.monster” and “group[1]” work, but “monster” does not.[/code]

The method you used works also, but it’s another step and arguably is more work to deal with.

2. display objects are both displayObjects and tables {}. This includes displayGroups.

[code]local bird = display.newGroup()
bird.beak = display.newImage(“yellowbeak.png”) – this object is not part of the displayGroup!
bird.wing = display.newImage(bird, “bluewing.png”) – this object IS part of the displayGroup!

bird.x = 300 – both bird and bird.wing will move here, but beak will not[/code]

This is because the (optional) first argument of (almost) any displayObject is the group to insert it into. You have to be somewhat careful in that there are a few basic .words that are inherent to displayGroups (visual might be one of them? not sure) but generally speaking you can treat displayGroups as tables.

Keep in mind, though, that displayGroups don’t really have a position until they have objects in them (the size and position is determined by everything it contains, as if you drew a giant box around the contained objects). So usually what you would do is (1) insert all of the objects you want into bird, (2) move the bird components to the right relative positions, and finally (3) move the bird. [import]uid: 41884 topic_id: 34775 reply_id: 140543[/import]

[Aidin]

Thanks Richard, you are so kind on helping my on several topics with your thorough explanations.

I had to let go of the display groups because Corona or Box2D has this problem that physic does not work on physic bodies belonging on different display groups. [import]uid: 206803 topic_id: 34775 reply_id: 140639[/import]

[bjsorrentino]

Hi Aidin,
Just to clarify: you can place physics objects in different display groups, but you just can’t shift those display groups around independently of each other (X and Y position) if you need collision detection. I might have already mentioned that to you in a previous post, but in case I didn’t, that’s the clarified answer.

Thanks,
Brent [import]uid: 200026 topic_id: 34775 reply_id: 140642[/import]

[Aidin]

Thanks Brent,

My problem was that I wanted to check collision between physic bodies that belong to different display groups and apparently Corona (and box2D) have problem with this, as I’ve read in Corona documents. [import]uid: 206803 topic_id: 34775 reply_id: 141402[/import]

[Aidin]

@richard9:

I’ve been reading more about OOP and in this post http://www.coronalabs.com/blog/2011/09/29/tutorial-modular-classes-in-corona/ if you check the dog (the man’s best friend) example you can see that he used metatables and in the description mentioned that if you do not use this technique, you will not get an actual new object reference but with the method you taught me, I think I have created actual new objects rather than references to old one.

And ideas?

Is it better if I use metatables? [import]uid: 206803 topic_id: 34775 reply_id: 141418[/import]

[richard9]

In that example basically the metatable is used to pass certain data defaults. It’s very good when you want to assign default behaviours; ie, if you’re making enemy “bullets”, you could use metatables to always assign defaults for stuff like damage, move speed, functions for movement, etc, but then write code later to assign variant-specific stuff. It sort of works like onion layers:

1. base object (assign HP, physics, etc)
2. the bullet species
3. fast bullet / slow bullet / etc

The problem is, there’s a fair amount of setup, so certain things just don’t make sense. For example, if I’m building UI objects, I don’t need the objects to inherit anything. So that’s where you want to use the table stuff he describes, just not the metatables.

[code]-- coolmenu.lua
local M = {}

local function makeShiny()
print(“shiny!”)
end

function M.create(details)
local object = display.newRect(0,0,32,32)
makeShiny()
return object
end

return M[/code]

That’s a bare-bones lua file that doesn’t use module but also doesn’t need/use metatables. All you have to do is require in the file local coolmenu = require("cool menu") and then call the function ( coolmenu.create()) Only the functions attached to the table (M) are visible.

(And you can still stack here too, like requiring in other lua files to help)

2. You’re right in that metatables can be used to make a new table as opposed to just a reference to an existing one, but the above example should make something new every time you use create(). As I said the metatable system described in the link is meant for objects where inheritance matters, like a game where you have a bunch of different objects that follow (some) of the same rules. (ie: all of the chess pieces in chess would use it, whereas the board would not)

[import]uid: 41884 topic_id: 34775 reply_id: 141419[/import]

[Aidin]

Thanks Brent,

My problem was that I wanted to check collision between physic bodies that belong to different display groups and apparently Corona (and box2D) have problem with this, as I’ve read in Corona documents. [import]uid: 206803 topic_id: 34775 reply_id: 141402[/import]

[Aidin]

@richard9:

I’ve been reading more about OOP and in this post http://www.coronalabs.com/blog/2011/09/29/tutorial-modular-classes-in-corona/ if you check the dog (the man’s best friend) example you can see that he used metatables and in the description mentioned that if you do not use this technique, you will not get an actual new object reference but with the method you taught me, I think I have created actual new objects rather than references to old one.

And ideas?

Is it better if I use metatables? [import]uid: 206803 topic_id: 34775 reply_id: 141418[/import]

[richard9]

In that example basically the metatable is used to pass certain data defaults. It’s very good when you want to assign default behaviours; ie, if you’re making enemy “bullets”, you could use metatables to always assign defaults for stuff like damage, move speed, functions for movement, etc, but then write code later to assign variant-specific stuff. It sort of works like onion layers:

1. base object (assign HP, physics, etc)
2. the bullet species
3. fast bullet / slow bullet / etc

The problem is, there’s a fair amount of setup, so certain things just don’t make sense. For example, if I’m building UI objects, I don’t need the objects to inherit anything. So that’s where you want to use the table stuff he describes, just not the metatables.

[code]-- coolmenu.lua
local M = {}

local function makeShiny()
print(“shiny!”)
end

function M.create(details)
local object = display.newRect(0,0,32,32)
makeShiny()
return object
end

return M[/code]

That’s a bare-bones lua file that doesn’t use module but also doesn’t need/use metatables. All you have to do is require in the file local coolmenu = require("cool menu") and then call the function ( coolmenu.create()) Only the functions attached to the table (M) are visible.

(And you can still stack here too, like requiring in other lua files to help)

2. You’re right in that metatables can be used to make a new table as opposed to just a reference to an existing one, but the above example should make something new every time you use create(). As I said the metatable system described in the link is meant for objects where inheritance matters, like a game where you have a bunch of different objects that follow (some) of the same rules. (ie: all of the chess pieces in chess would use it, whereas the board would not)

[import]uid: 41884 topic_id: 34775 reply_id: 141419[/import]