I'm currently in the same boat with java. Makes me wonder if theres an issue with the java test-checker.

Hello @Tonio31

Using the input you provided I think the result should be [0, 1, 2, 3, 4, 3, 2, 1, 0, 2, 4, 0]

Maybe you found a problem.

What language are you using?

I'm having the exact same problem and I really can't understand why the lift stops at floor 3 at the end.

SO the case is:

Capacity: 4

4: [2]
3: [4, 1, 0, 4]
2: [3, 4, 4, 4]
1: [0, 4]
0: [4, 3]

Lift Stops at 0 - [4, 3] in the lift
Lift Stops at 1 - [4, 3, 4] in the lift (queue at floor 1: [0])
Lift Stops at 2 - [4, 3, 4, 3] in the lift (queue at floor 2: [4, 4, 4])
Lift Stops at 3 - [4, 4, 4, 4] in the lift (queue at floor 3: [1, 0])
Lift Stops at 4 - [2] in the lift (queue at floor 4: [])
Lift Stops at 3 - [2, 1, 0] in the lift (queue at floor 3: [])
Lift Stops at 2 - [1, 0] in the lift (queue at floor 2: [4, 4, 4])
Lift Stops at 1 - [0, 0] in the lift (queue at floor 1: [])
Lift Stops at 0 - [] in the lift (queue at floor 0: [])
Lift Stops at 2 - [4, 4, 4] in the lift (queue at floor 2: [])
************* WHY IS IT SUPPOSE TO STOP AT FLOOR 3 HERE ****************
Lift Stops at 4 - [] in the lift (queue at floor 4: [])
Lift Stops at 0 - [] in the lift (queue at floor 4: [])

Can someone tell me why my logic above is wrong. I'm going crazy on this

It is a carboned chain like any other else from the chemist/molecule point of view, yes. But what I call branches in the kata are the chains that are defined through the brancher method only. From the coding point of view there is a huge difference: you cannot access the atoms of the lateral chains (C-C-C-Mg-Br, for instance), but you can access any atom (even mutated ones) that are considered "branches", meaning, "were defined using branher(...).

Clear enough?

avoid string concatenation

Seems you're using the java version. There is already an issue about that just below and, yes, the translation is inconsistent for now (mostly about the work passes). There is a translation waiting for approval that should resolve the troubles. Closing here to avoid a useless duplicate issue (note: please read the discourse before posting issues and document it: language, and various data as I did below)

I mean, you can just change them yourself ;p

Hi @joshua082390. I'll message to the translation author. Thanks for the feedback.

Well, that's a an hour of my life I will never get back... (but cheers for reporting back that all is ok now)

The moral is: If your solution does not work but you are convinced it should, first thing to check is how many people solved if for that language already. If there are many, then the problem (or misinterpretation) is almost always going to be at your end.

@joshua082390

You told me

4: [2]
3: [4, 1, 0, 4]
2: [3, 4, 4, 4]
1: [0, 4]
0: [4, 3]

Answer says it's 0, 1, 2, 3, 4, 3, 2, 1, 0, 2, 3, 4, 0 but I'm getting 0, 1, 2, 3, 4, 3, 2, 1, 0, 2, 4, 0

For following input (with lift capacity 4) I agree with your answer

    final int[][] queues = {
      new int[]{4,3}, // G
      new int[]{0,4}, // 1
      new int[]{3,4,4,4}, // 2
      new int[]{4,0,1,4}, // 3
      new int[]{2}, // 4
    };

But chances of Java tests being wrong are low. I wrote this Kata 1st in Java, and 59 others have solved OK already.

Then I tried with your queues reversed

    final int[][] queues = {
      new int[]{3,4}, // G
      new int[]{4,0}, // 1
      new int[]{4,4,4,3}, // 2
      new int[]{4,1,0,4}, // 3
      new int[]{2}, // 4
    };

but for this input it gave the expected result!

So I am suspicious about the input you said:

• Are you sure you showed those input queues correctly?

• Are you sure you are using queue iindex [0] as head of the queue as in description?

Queue index [0] is the "head" of the queue

@joshua082390 - Which languge you solving here? Perhaps there is a bug if you are working with a recent translation.

If order DOES matter

I don't know why you keep saying "if" order matters... It matters, believe me. Or if you don't want to believe me, then believe the other 193 people who already solved the Kata.

Just like in the real world, you wouldn't wait behind somebody wanting to go the other way...

You can imagine there being 2 lines of people (those going up and those going down) if that helps you.

If the order of the people in the queue matters how does testTrickyQueues only visit the 6th floor once when there are 2 6th floor people on the 5th floor behind 3 0's? It would have to visit the 6th floor at least twice to get these people at the end

This part is badly explained. The people are entering according to the queue, but you should consider only those who are going in the current direction, not every person in line. It stops once at the 6th floor in the first example because at the 5th floor everybody who's going up enters the lift, not only the first person in the queue.

Does the order of the people matter in the queue matter or not?

Yes! From Kata description:

Only people going the same direction as the Lift may enter it, and they do so according to their "queue" order

Also, the capacity is 4 so there's no capacity issues encountered

Are you sure about that?

Some languages have signed bytes and some don't, a negative byte is just a byte with a value from 128 to 255 when unsigned. Add 2^8 to it and use it as an integer if your language doesn't have unsigned bytes.