App Inventor: Colors change incorrectly when moving items between lists (Ball/Nut Sort game)

Nut_Sort (1).aia (475.5 KB)
I am building a Ball/Nut Sort puzzle game in MIT App Inventor using lists of lists (each rod is a list, stored inside a global rods list).

Each move should:

  • Take the top item (last item) from fromRod

  • Add it to the end of toRod

  • Only allow the move if:

    • toRod is not full
    • AND (toRod is empty OR top color of toRod equals moving color)

The problem

Even though I select a green nut from rod 2 and move it to rod 3:

  • The nut arrives as a different color (e.g. red)
  • At the same time, other rods change colors automatically
  • Sometimes two items appear in the destination rod after one move

It looks like colors are being swapped or corrupted, even though I never change colors directly.

What I have already tried

  • Using copy list for fromList and toList
  • Ensuring remove/add only happens inside if canMove = true
  • Making sure only one place in the code modifies the lists
  • Fixing insert index errors (length + 1)
  • Fixing color comparison logic (topTo = movingColor)
  • Rendering images only from the list values

My current move logic (simplified)

fromList = copy of rods[fromRod]
toList   = copy of rods[toRod]

movingColor = last item of fromList

if toList is full → canMove = false
else if toList is empty → canMove = true
else if topTo = movingColor → canMove = true
else → canMove = false

if canMove:
    remove last item from fromList
    insert movingColor at end of toList
    replace rods[fromRod] = fromList
    replace rods[toRod] = toList
    Render()

Expected behavior

  • Only the selected nut moves
  • Colors remain consistent
  • Other rods are not affected

Actual behavior

  • Colors randomly change
  • Other rods get modified
  • Destination rod sometimes gets duplicate items

Question

Is this caused by:

  • List reference issues in App Inventor?
  • insert list item behavior?
  • Rendering logic?
  • Something else I am missing?

Any guidance or example of a stable list-of-lists move pattern in App Inventor would be greatly appreciated.

1 Like

Thanks :heart:
but i need the nuts move between the rods . how can i do that ?

The video helps understand the puzzle better.

It is similar (but not equal to) the Towers of Hanoi puzzle, with three fixed height rods representing limited height stacks, and different legality constraints.

For list manipulation of stacks, you would typically use two list blocks:

  • add item to list (if stacked vertically like the video) and
  • remove item (length of list) from list

If stacked in the other direction, you would use

  • insert at item 1
  • remove item 1

I'm going back into your code, to see how it works, but if it was me, I would got for a value function based approach, where you avoid doing in-place manipulation of lists, but instead pass around freshly built altered copies of the data structures.

I looked at your graphic files
image

to see which way the rod (bolt) faces, to see how that constrains the stacking.

I can't envision how you could combine these images to show a bolt sticking through a series of nuts.

You might fix them by pasting sections of bolt shaft over their top parts, since the nuts themselves won't appear away from a bolt anyway. The none image would just be a section of bolt shaft, not empty space.

(I am procrastinating to avoid reading your code).

I suggest a far simpler way to internally represent a puzzle state:
a text string, of the form

RRYY|YYRR|---- (the starting state of your video)
RRYY|YYR-|R---
RRYY|YY--|RR--
RRY-|YYY-|RR--
RR--|YYYY|RR-- (the ending state)

The dashes are optional.

This is easier to debug using Do It, since you would see the entire puzzle state at a glance.

Probably need another set of images with a cutout, e.g.

nut_red_slot

1 Like

Setting target nut slot buttons as enabled or disabled is a needless aggravation.
Testing your app, I got stuck with no enabled buttons in my target bolt:
Sample run


You need to keep lists of button components by rod, and infer which rod was selected from the button component index.

Even better, just have one button per rod, since the app will govern which nut moves once the rod is selected.

Here's a sample app that uses generic blocks and components in lists, for you to study.

another...

Just to match the list structure against the rendering ...


Index 1 of each rod is the top of the stack of nuts.
So all the action of moving a nut is going to happen at index 1.


Besides changing indexes of the stack tops to 1, I also found

The else clause should set canMove to true.

The project is better now, though not perfect.


Nut_Sort1 (1).aia (476.2 KB)
Sample run

The invisible button stack approach is finicky.
Also, elevating bottom nuts is still a problem.

Too much of the code is hard wired for 3 rods, along with a stack limit of 3.

That limits reusability of the code for more rods, more colors, and more nuts.

I leave all that to you.