[11.3] AdMob support for Android + EU Consent

[bio1712]

There's also https://github.com/love2d/love-android/tree/0.11.x if you prefer GitHub. Also that's the most up-to-date repository.

You can try to create new git repository of your current fork then merge to it. Make sure to resolve any merge conflicts (in your case there would be much).

I can't even use Github
Do you think it's a laborious process? I think I'll wait for the next release.

[pgimeno]

Since I'm totally new to Bitbucket and Git, is there any way to update only the interested files, without starting over?

I think you want to do a rebase. Rebasing a branch on top of another consists of taking that branch's commits and applying them on top of the second branch, so that the final branch includes the code that was specific of that branch, but applied to the newer one. There's lots of documentation online on how to do it. In formatted ASCII:

Code: Select all

What you had

                LÖVE version at the time you created the patch (master)
                |
... A - B - C - D
                 \
                  X - Y - Z
                          |
                          your branch with all of your changes (let's call id loveads)

Now LÖVE evolves:

                LÖVE version at the time you created the patch
                |
... A - B - C - D - E - F - G - H
                 \              |
                  X - Y - Z     latest LÖVE version (master)
                          |
                          your branch with all of your changes (let's call id loveads)

The difference between D and your version lies in commits X, Y and Z, which you created. Therefore, if you can apply X, Y and Z on top of H, you will have an updated version of your library. That's what rebase does. After rebasing loveads on top of master, you will have this:

Code: Select all

                                master
                                |
... A - B - C - D - E - F - G - H
                                 \
                                  X'- Y'- Z'
                                          |
                                          new loveads rebased on top of master

where X', Y' and Z' are new commits with the same changes as X, Y and Z (possibly modified to resolve conflicts, if any arise), which I believe is what you want. Now I'm not sure if you can do that in Mercurial without losing the version previous to the rebase. In git you certainly can, because in git, X, Y and Z are not immediately deleted, they just become unreferenced, but you can easily keep them ready to be accessed just by creating a branch in the same place as loveads right before rebasing.

So for example, if you were in a git repository of LÖVE, you can run these commands:

Code: Select all

# Switch to your branch

git checkout loveads

# Create a new branch that we won't move or switch to, just to be able to return to it

git branch loveads-11.2

# We're still in loveads ('git branch' doesn't switch to the new branch).
# Rebase it on top of master.

git rebase master

# Here, conflicts may arise, if there are commits between 11.2 and current master
# that modify code that you have also modified. If that doesn't happen, you're done.
# Otherwise, you need to resolve the conflicts (integrate the upstream changes with
# your own changes into a coherent version). Modify each conflicting file and then
# use 'git add <the-file>'; finally do 'git rebase --continue'.

Note however, that LÖVE in Bitbucket is in Mercurial form, not in Git form. Mercurial has a few advantages and a lot of inconveniences over git, for doing repository manipulation of this kind. In particular, with Git you don't lose your previous commits when you rebase, but I believe you do with Mercurial. Besides, in Mercurial you need to activate an extension if you want to rebase, it doesn't come active by default.

I advise you to learn git. It's hard but it pays off.

[bio1712]

I think you want to do a rebase. Rebasing a branch on top of another consists of taking that branch's commits and applying them on top of the second branch, so that the final branch includes the code that was specific of that branch, but applied to the newer one. There's lots of documentation online on how to do it. In formatted ASCII:

Code: Select all

What you had

                LÖVE version at the time you created the patch (master)
                |
... A - B - C - D
                 \
                  X - Y - Z
                          |
                          your branch with all of your changes (let's call id loveads)

Now LÖVE evolves:

                LÖVE version at the time you created the patch
                |
... A - B - C - D - E - F - G - H
                 \              |
                  X - Y - Z     latest LÖVE version (master)
                          |
                          your branch with all of your changes (let's call id loveads)

The difference between D and your version lies in commits X, Y and Z, which you created. Therefore, if you can apply X, Y and Z on top of H, you will have an updated version of your library. That's what rebase does. After rebasing loveads on top of master, you will have this:

Code: Select all

                                master
                                |
... A - B - C - D - E - F - G - H
                                 \
                                  X'- Y'- Z'
                                          |
                                          new loveads rebased on top of master

where X', Y' and Z' are new commits with the same changes as X, Y and Z (possibly modified to resolve conflicts, if any arise), which I believe is what you want. Now I'm not sure if you can do that in Mercurial without losing the version previous to the rebase. In git you certainly can, because in git, X, Y and Z are not immediately deleted, they just become unreferenced, but you can easily keep them ready to be accessed just by creating a branch in the same place as loveads right before rebasing.

So for example, if you were in a git repository of LÖVE, you can run these commands:

Code: Select all

# Switch to your branch

git checkout loveads

# Create a new branch that we won't move or switch to, just to be able to return to it

git branch loveads-11.2

# We're still in loveads ('git branch' doesn't switch to the new branch).
# Rebase it on top of master.

git rebase master

# Here, conflicts may arise, if there are commits between 11.2 and current master
# that modify code that you have also modified. If that doesn't happen, you're done.
# Otherwise, you need to resolve the conflicts (integrate the upstream changes with
# your own changes into a coherent version). Modify each conflicting file and then
# use 'git add <the-file>'; finally do 'git rebase --continue'.

Note however, that LÖVE in Bitbucket is in Mercurial form, not in Git form. Mercurial has a few advantages and a lot of inconveniences over git, for doing repository manipulation of this kind. In particular, with Git you don't lose your previous commits when you rebase, but I believe you do with Mercurial. Besides, in Mercurial you need to activate an extension if you want to rebase, it doesn't come active by default.

I advise you to learn git. It's hard but it pays off.

Thank you, your explanation was clear.
I will definitely try to learn git, it is certainly a useful tool.

[Donut-Dezz]

Can you drop a banner ad snippet code for us. who have problems getting ads in there games. in love2d

[bio1712]

Can you drop a banner ad snippet code for us. who have problems getting ads in there games. in love2d

You can download this game.love.

[Donut-Dezz]

Can you do a tutorial on how to put admob banner ads in love2d games. bro for others

[bio1712]

Can you do a tutorial on how to put admob banner ads in love2d games. bro for others

I think that my first post and the example game.love are a good starting point.

[Donut-Dezz]

bio where do you put the. love.ads.createBanner() code. in the love.draw() or the love.update() or the love.load() which function. you put it in

[yetneverdone]

bio where do you put the. love.ads.createBanner() code. in the love.draw() or the love.update() or the love.load() which function. you put it in

In load.

[bio1712]

bio where do you put the. love.ads.createBanner() code. in the love.draw() or the love.update() or the love.load() which function. you put it in

I agree with yetneverdone. Since you have to call createBanner() only once, you may put it in your love.load().