[STCC-121] - Fix conversion of PointToBrick

[Hyderow]

This seems to fix the conversion of the PointToBricks. The program from the ticket still crashes though.

[cfkh]

You would now create a new sprite instance every time there is a PointToBrick.
But the sprite given to the constructor of PointToBrick could already exist at this point.
You'll probably need a register handler. Look in datacontainer if sprite already exists, then use this sprite instance. Otherwise you would need to create a new sprite instance. Somewhere there is a list called upcoming_sprites. It'll need to be added to this list, I think.

[Hyderow]

It should be implemented properly now. Should we think about adding a workaround for pointing towards the mouse cursor?

[cfkh]

What you did seems good to me.

It would be nice if you could include a workaround for Point To mouse.
In Pocket Code the equivalent to the mouse position would obviously be the touch position.
Be aware that in Pocket Code the Point To brick doesn't accept a formula as an argument just Sprites.

Idea (but you might have a better one)
Therefore you will need to use the Point In Direction brick. The workaround will need a bit of math too, because you will need to calculate an "angle between points" (which is obviously not existing).
You could therefore calculate the length of the hypothetical line connecting these two points. Giving you a hypotenuse. You could also calculate the length of the adjacent leg, by simply calculating the absolute x difference. Now you can finally calculate your degrees by acos(adjacent leg/hypotenuse).

Note
Please also include tests for your implementation in the test_converter module.

[Hyderow]

I decided to add a dummy mouse sprite that always updates its position to the last touch position as a workaround. If we do it this way we don't have to insert several blocks into the script, but just have a single new sprite.

[cfkh]

Sounds good to me.

[cfkh]

1. Please make a program in Pocket Code which has two sprites in them and let one point at the other at start.
   Does this work? On my phone nothing happens.

2. When starting a program containing PointTo mouse Pocket Code will crash. When again choosing the mouse sprite as an argument in Pocket Code the program doesn't crash.

3. Please rebase on develop

[Hyderow]

1: This seems to work fine for me. I tried it with 2 sprites that only have a when started script with a single PointTo brick. The result was that both sprites point towards each other.

2: This crash is really weird. It happens even without the mouse workaround being in the program and seems to resolve itself eventually (just by randomly opening scripts touching anything in them). I'll look into it a bit more.

[cfkh]

Okay. Weird. I guess it's a Pocket Code problem. Please update us on your findings per comment right here and/or in discord.

[Hyderow]

After some more testing I managed to reproduce this bug on the master branch. The program I got it with is simply 2 sprites with a when started script and a gotoSprite, pointing at the other sprite(see attached file).

If you look at the converted code of the program, one of the sprites is not in the spriteslist as a sprite, but the entire definition of it is in the destinationSprite field of the goTo brick of the other sprite.
I think the cause of the bug may have to do with the way we add a new sprite to the upcoming sprites map in the register handler.

goto-crash.zip

Update: I think this might also be the cause for STCC-132. It crashes at the same line in both Angry birds! and my example program.

[cfkh]

I have also tested a few programs and can confirm this behaviour.

We don't deal with upcoming sprites any different than with other sprites, we only store the reference for later.
Currently we use some Catroid functionality which does the serialization for us:

def program_source_for(catrobat_program): storage_handler = catio.StorageHandler() code_xml_content = storage_handler.XML_HEADER code_xml_content += storage_handler.getXMLStringOfAProject(catrobat_program)

Could this be a serialization problem on Catroid's side?
If this is the case: What we (possibly) could do to avoid this, is that we reorder the sprites in the scene's spritelist, so that no sprite is used before being referenced. (Of course if we have for instance two sprites referencing each other we can't do anything.)

Please look deeper into this. This is pretty important as it not only affects one bricks functionality, but probably a few. Take the time you need. You can of course also grab other issues in the meantime.

[Hyderow]

Turns out we didn't correctly set the spinner value in the registerhandler for the goTo Block. Changing these values to the correct ones fixed the crashes.

[cfkh]

Please try converting a selfmade Scratch program where the first sprite (Sprite 1) in the scene doesn't have any scripts and the second one (Sprite 2) has a WhenGreenFlag script with only a PointTowards block referring to Sprite1. Deploy the converted project on your phone's Pocket Code folder. Crash at starting the converted program?

[Hyderow]

Doesn't crash for me.

[cfkh]

OK