Question regarding deprecated use of "module".

richard9 · January 23, 2013, 6:44am

Forgot the return M at the end; otherwise your module doesn’t return any methods… [import]uid: 41884 topic_id: 34775 reply_id: 140071[/import]

ingemar · January 23, 2013, 6:52am

Both textBox.lua and combatBox.lua need a return M at the end of each file

EDIT:
Looks like @richard9 beat me to it [import]uid: 70847 topic_id: 34775 reply_id: 140073[/import]

Aidin · January 23, 2013, 3:28pm

Thanks! It works and I love it!

One thing though, if I want to attach a Display Object to this newly created table (or object), what is the best approach?

I can make a variable inside my object that I will eventually return like:

newObject.visual = display.newImageRect(…)

I can make my newly created object a display group and insert what I want into it:

local visual = display.newImageRect(…)

local newObject = display.newGroup();

– bunch of code assigning several values for this object and then:

local visual = display.newImageRect(…);
newObject:insert(visual);

but I have difficulties doing the second option so it may not work as best I thought but it seems better since I want to attach some texts on this object because I can make several text display objects and attach it to the main object (table) with the same way.

I’m not sure if I can attach text object and display object to a display group but I think it’s possible.

What you guys think of all this? [import]uid: 206803 topic_id: 34775 reply_id: 140129[/import]

Aidin · January 25, 2013, 5:59pm

Is there anything wrong with using metatables? As I read through Lua specific OOP materials, people are using them quite a lot but not that much with Corona crowd. Is there anything specific to this? [import]uid: 206803 topic_id: 34775 reply_id: 140418[/import]

richard9 · January 25, 2013, 8:33pm

Not entirely sure what you mean since all of your posts have inquired into the workings of display objects anyway? But a few pointers…

1. A Display Object is really just a fancy, special table.
It requires some unique methods (.numChildren instead of #, :insert() and so on) but is still just as malleable.

local bird = display.newImage("bird.png") bird.name = "George" bird.horsebets = { 127, 465, 12, 32, 67 } bird.run = function() print("I'm running!) end

2. You can nest display objects but they are not attached.
They are still tables, but you need to add to a displayGroup to unite them.

bird.beak = display.newImage("yellowbeak.png") -- independent of bird! local birdGroup = display.newGroup() birdGroup:insert(bird) birdGroup:insert(beak) -- now the pieces are united under birdGroup -- but bird.beak is still a valid name.

Or you could do it this way as I usually do…

local bird = display.newGroup() bird.beak = display.newImage(bird, "yellowbeak.png") -- now it's both bird[1] and bird.beak -- etc

The only thing you can’t do with display object tables is this:

[code]local hawk = display.newImage(“hawk.png”)
hawk[1] = “something” – you can’t do this!! it’s not an enumerated table

hawk.details = {} – declare a table within the table, and…
hawk.details[1] = “something” – this is fine though[/code]

Metatables are a headache to me, but the basic gist I get from them with regards to OOP is that they are a way to preserve methods without using more memory. That is, if you have a ton of display objects (say, birds, dogs, cats) but all of them do some things the same (they all have names, maybe all move around) you can first generate a single core object that does those shared things, and then create copies of that core object with the specific traits of your animal but also the shared code.

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

ingemar · January 25, 2013, 11:10pm

@aidin: On the contrary!
There’s nothing wrong in using metatables at all. Once you understand how they work, they can be very powerful. If you’re new to Lua it may take some time to grasp the concept, but I recommend that you have a look.

Here’s a link to a tutorial that’ll get you started:
http://nova-fusion.com/2011/06/30/lua-metatables-tutorial/ [import]uid: 70847 topic_id: 34775 reply_id: 140439[/import]

Aidin · January 22, 2013, 8:51am

Hi,

I’m reading more and more and more about object oriented in Lua/Corona and wanted to ask what did you mean by “The key to avoiding module is mostly just proper use of return. :)” ? If you would, please elaborate.

As I Google around, there are lots of ways people are doing OO with Corona/Lua and one just wonders what’s the most proper way to do it.

What I’m trying to do is just create a class that creates a table that has an image attached to it with newImageRect and several various functions and values. I’m not doing inheritance now, what I’m most interested is how to do OO the best way in Lua/Corona.

(I know “best” is defined by opinion but since I want to attach image to my object, I think there are less arguments with that way because as I’ve read you can’t use metatables that way)

I would appreciate any info on this guys.

Thanks. [import]uid: 206803 topic_id: 34775 reply_id: 139945[/import]

Aidin · January 27, 2013, 8:49am

Thanks for the feedbacks. Some more questions:

Does inserting a Display Object into a display group should give you a reference as well via the display group?

In another words, is it possible to do something like this:

visual = display.newImageRect("monster\_purple.png", 116, 314);  
newMonster:insert(visual)  
local Retreview = newMonster.visual

I treid it and it returned nil so I had to do this:

visual = display.newImageRect("monster\_purple.png", 116, 314);  
 newMonster:insert(visual)  
 newMonster.visual = visual;

and store a explicit reference to this visual object. Is there any way not to have two references of the display object on the display group?

2- Does this code:

local bird = display.newGroup()  
bird.beak = display.newImage(bird, "yellowbeak.png")

also make the beak part of the bird display group as well? In another word, if I move the bird, will beak move with it as well?

I’m asking this because I tried this and it didn’t work so I had to write this instead:

visual = display.newImageRect("monster\_purple.png", 116, 314);  
 newMonster:insert(visual)  
 newMonster.visual = visual;

Note the last line that I exposed the recently inserted display object with a pointer. In my honest opinion, when you insert an object into a display group, shouldn’t you be able to access it directly?

Hope I’m clear, didn’t sleep last night so let me know if any of this is not clear and I’ll explain my questions more clearer. [import]uid: 206803 topic_id: 34775 reply_id: 140542[/import]

richard9 · January 27, 2013, 9:07am

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.

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 · January 28, 2013, 9:02am

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 · January 28, 2013, 9:15am

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 · January 23, 2013, 6:19am

Thanks for the code and explanation but when I created a new project and wanted to run your program, apparently “require” statements do not work because after they execute, they are booleans and do not have methods on them. [import]uid: 206803 topic_id: 34775 reply_id: 140069[/import]

richard9 · January 23, 2013, 6:43am

Previous versions of Lua (and thus Corona) used a command called module(..., package.seeall). The short of it is that this approach has some potential for memory leaks and other quirks, so the recommended method changed and that command was deprecated. (Here’s an old blog post about it)

return is a pretty elemental part of programming. If you think of a function as like an equation, return is what gives you the answer. That same logic applies to the modules themselves - you can put almost anything you can think of in a single .lua file, and the only thing the rest of your code will see is whatever is on the return line.

I know there is a good old blog post about OOP but so far I’m not a big fan of metatables. It depends what sort of game you’re making, though.

Here’s a rough example of how I use OOP, I suppose…

[1] A clean base module

[code]-- textBox.lua
– makes a message box with text in it
local M = {}

local function flip(self, newtext)
– flip code goes here
self.string.text = newtext
end

function M.create(blab)
local group = display.newGroup()
group.box = display.newRect(group, 0, 0, 200, 48)
group.string = display.newText(group, blab, 0, 0)

– Add functions it needs
group.flip = flip

return group
end
return M – important!
[/code]

[2] A specific child module

[code]–combatBox.lua
– text box only used for combat
local textBox = require(“textBox”)
local M = {}

local function defend(self)
– some code
end

function M.create()
local box = textBox.create(“FIGHT!”)
– add some combat specific functions
box.defend = defend
return box
end
return M – important![/code]

[3] call from where you want. You don’t need to require textBox since combatBox already does that.

[code]-- fightScene.lua
local cbox = require(“combatBox”)

local combatmsg = cbox.create()
combatmsg:flip(“part 2”)
combatmsg:defend()[/code] [import]uid: 41884 topic_id: 34775 reply_id: 139952[/import]

richard9 · January 23, 2013, 6:44am