liam48D wrote:

So basically first class clones. Support, but duplicate. Maybe you should check out http://snap.berkeley.edu?

At least me didn't found the pointer in Snap! sooooooooooooooooooooooooooooo……..

Gustavo6046 wrote:

liam48D wrote:

So basically first class clones. Support, but duplicate. Maybe you should check out http://snap.berkeley.edu?

At least me didn't found the pointer in Snap! sooooooooooooooooooooooooooooo……..

It's kind of weird right now, but they'll be better supported later. For now you can just use first class lists, which you might find interesting (i.e. nesting lists (i.e. putting lists in lists)).

liam48D wrote:

So basically first class clones. Support, but duplicate. Maybe you should check out http://snap.berkeley.edu?

What do you mean by “first class clones”? And I know Snap! so please!

Chibi-Matoran wrote:

Not understanding a suggestion is not a reason to say “no support.” From my experience, whenever someone doesn't understand a suggestion, they say that it's too complicated for beginners. Please make an effort to understand the suggestion before casting your vote, folks.

I disagree with the above statement. I understand the suggestion, but isn't this too far for a basic language?
No support. Slightly confusing for New Scratchers and workaroundable with lists.

Semi-support for clone referencing.

If there is a definitive workaround then please show me in project format. I would be very grateful, I always wish per-clone behaviour with other clones!

Gustavo6046 wrote:

If there is a definitive workaround then please show me in project format. I would be very grateful, I always wish per-clone behaviour with other clones!

I would If I were on a desktop.

ChildCritic wrote:

Gustavo6046 wrote:

If there is a definitive workaround then please show me in project format. I would be very grateful, I always wish per-clone behaviour with other clones!

I would If I were on a desktop.

If you don't have enough resources/information to adequately back up your points, then why post at all?

ChocolatePi wrote:

ChildCritic wrote:

Gustavo6046 wrote:

If there is a definitive workaround then please show me in project format. I would be very grateful, I always wish per-clone behaviour with other clones!

I would If I were on a desktop.

If you don't have enough resources/information to adequately back up your points, then why post at all?

So that one can expect those resources/information.

I think the main problem I have with this suggestion is that the suggested blocks still wouldn't necessarily be that helpful when referencing clones. I can't really see any situation where I would want to have a reference to an arbitrary clone (closest, farthest, etc.) rather than to a specific instance of a clone.

Right now it is possible to do some operations with specific instances of a clone - but it is rather tedious and hacky. I would like to have some way to reference clones, but maybe some sort of identification system would be better.

How about a

(create clone of [sprite name here v] ::control)

block? It would return a reference to the new clone.

TheMonsterOfTheDeep wrote:

I think the main problem I have with this suggestion is that the suggested blocks still wouldn't necessarily be that helpful when referencing clones. I can't really see any situation where I would want to have a reference to an arbitrary clone (closest, farthest, etc.) rather than to a specific instance of a clone.

Right now it is possible to do some operations with specific instances of a clone - but it is rather tedious and hacky. I would like to have some way to reference clones, but maybe some sort of identification system would be better.

Say a team AI; two players of same team in a soccer game and one have the ball. If in front of that one there is an enemy, then it will try to pass the ball to the closest clone that don't have an enemy ahead i.e. player 2. If you have however a lot of players then to what specific clone would you want to pass if their ID won't change with their distance to player 1 or enemy ahead? Also what if the player 1 has many choices to pass to?

BookOwl wrote:

How about a

(create clone of [sprite name here v] ::control)

block? It would return a reference to the new clone.

Great idea! (in Snap! at least, until in Scratch they have clone pointers OR variables :I )

Gustavo6046 wrote:

alexphan wrote:

Good ideas, but can't classes and structs just be lists?
Semi-support.

Structs can be downed into lists, but classes….
As classes hold information of constructors/initializers and functions, this won't work, unless the class in question only holds variables – not noting that classes are initialized, not just stored!

^^
structs can, but not classes, without lambdas

ChocolatePi wrote:

ChildCritic wrote:

Gustavo6046 wrote:

If there is a definitive workaround then please show me in project format. I would be very grateful, I always wish per-clone behaviour with other clones!

I would If I were on a desktop.

If you don't have enough resources/information to adequately back up your points, then why post at all?

Gustavo6046 wrote:

If there is a definitive workaround then please show me in project format. I would be very grateful, I always wish per-clone behaviour with other clones!

TheMonsterOfTheDeep wrote:

I think the main problem I have with this suggestion is that the suggested blocks still wouldn't necessarily be that helpful when referencing clones. I can't really see any situation where I would want to have a reference to an arbitrary clone (closest, farthest, etc.) rather than to a specific instance of a clone.

Right now it is possible to do some operations with specific instances of a clone - but it is rather tedious and hacky. I would like to have some way to reference clones, but maybe some sort of identification system would be better.

You will all want to see this.
It does not cause clone-on-clone interaction, but it is possible with a little bit of distance calculations.