I don’t use composer also and using display.groups won’t solve the problem. the code needs to be independent of any other code, so I can integrate it, like a plugin. For now, I resolved the problem with the runtime solution, but I really don’t like it (i hate runtime code)
@Carlos, why won’t display groups solve your issue?
If you had say 2 groups, lets call them sceneDG and overlayDG. You create sceneDG first and then overlayDG second.
Objects you want “above” your game insert into overlayDG and all other objects insert into sceneDG. Anything inserted into overlayDG will always on top.
if I press a button to go sceneDG2 overlayDG will be behind scenceDG2. (i will remove sceneDG1 from memory and create sceneDG2 only when it is called. I can’t create all groups in advance…that’s not the proper way to do scenes).
my only hope is having a hidden “top layer” that I could use it for cases like this. ofc I could put all my other groups on level 2 layer, but if I shared my code it would not work with anyone else because everybody else was creating groups from layer 1.
so my question still remains, is there a way to put an object on a “super group” that would be on top of everything, regarding of other groups are creating after.
toaster plugin does exactly that, so I guess its possible, my only concern is that is only possible with native code.
nick_sherman, scenes are independent and they don’t know that overlayDG exist. only 1 scene happens 1 at a time, but if you know what a toaster is…it will prevail even if you close that scene.
i know to resolve the problem (and i did if you read my posts) i’m just curious to know if there is a hidden or better way to do what i asked. a “super group”.
sphere, with toaster plugin, i just call the plugin, it will prevail on top of any other group or object i will create after. i don’t need to insert it on any group after to still work. it works alone and independent. it’s that what I’m after.
still thx for trying to help (all are included)
ps. please don’t insist on display groups (workarounds or ways how I could create my groups I already know them). my question was really simple if you don’t know the answer don’t try to give me alternatives.i already know them.
Assign the display groups in drawing order bottom to top
Then add and remove children and manipulate the display groups to your liking, but never remove them!!
That is perhaps your issue.
I know how groups work
I don’t have an issue with that.
all my scenes, I create different files in each file they will be inside a closed group, that group can receive arguments so I can pass information from one scene to another. I’ ve an “ultimate delete function” that will remove any of my objects inside that group including that group. so I’m creating groups and deleting them as I need. I don’t have a group and put all inside. I could pass as an argument the
overlayDG from one scene to another. and put it on top on the second scene. my curiosity is that toaster already does what I want without this additional steeps and I already managed to do that without bothering of adding more code to make sure the code is independent and works alone (like it should). I’m just curious to know if there is another method of doing that without runtime. all your suggestions are worst because they are not independent and the other code needs to know the snackbar/toaster exist.
that description was easier to understand for me at least and i am not sure if this is will help, but its the only thing that springs to mind at this point.
If you are referring to the “toast” plugin (rather than toaster), the reason this is always on top is because it is a native Android object and not part of Corona’s OpenGL layout. You are not going to be able to create objects in Corona that perform in exactly the same way as this, because any objects created in Corona are always going to be part of the OpenGL layout.
The only way to do something like this is with the method everyone else has suggested but that has been rejected, with layered groups (controlled via a module or something to keep them persistent and in the correct order).
Back again. I’ve given this a quick re-read and I’m puzzled. Why are you passing objects between scenes? There isn’t any rule against it, but it seems weird to me.
Also, if you’re passing objects between scenes, you can just go on step further…
Make a group hierarchy like I (and others) suggested above.
Use the hierarchy to maintain layering order.
Pass the hierarchy group parent between scenes.
Insert the hierarchy group parent into the current scene.
Done. Unless I’m completely not getting this.
Of course you won’t be able to use any sexy transitions at this point, but then I’m still confused about this use of composer.*
Maybe a small video would help clarify what’s being done here?
Alan QuizTix, respond to what I was looking and what iI already suspected (but with a little hope that someone had some hidden gem to share with everyone).
Thanks to all that tried to help.
p.s. (roaminggamer, i’m not using composer like I already told, and I will not answer your post because I already have my answer. thanks anyway for trying to help)
p.s.2 (anaqim, same, but thanks again for trying to help )
maybe its only me picking up on this but you could probably work a little on both how you initially described your question, as well as how you adress people trying to help.
Took a while just to understand what you were after, and it seems I wasnt the only one.
@carloscosta - Cool. I guess I assumed composer.* because of the word ‘scene’ being used. My bad. I guess it’s at least partly right what they say about assuming. (I’m talking about me here…)
display groups would solve the problem… but only if you could “know” something about how “others” are using them (in particular, how any scene manager is doing its job, whether composer or something else) so that you could counter any negative side-effects of the “other’s” use.
there is no built-in group that is permanently above all other groups – in fact there’s only one built-in stage group, so it obviously can’t be above itself! (although any native object will always display above the opengl canvas, so Enterprise could do what you want)
for example, if you “knew” it was to be used with composer, then simply create your group outside of composer *after* composer has been required (at which time it creates it’s own group to house all scene groups). then your group should forever remain above anything/everything that composer does in its own group.
otoh if instead you “knew” it was to be used with DIY “scenes” that the end-user is creating as groups at the stage group level, then you could (probably) monkey-patch display.getCurrentStage().insert so as to preserve your group’s ordering within it. (and/or monkey-patch display.newGroup, etc)
in short, if you cannot “know” anything about the “environment” you’ll be running in, then there might not be any “better” solution than your current approach of just forcing your group to the front on a runtime event.
)