#1 by jkupb
Hi, What is the reason for this function to be at the beginning? To me it sounds much more practical if it wasn't the case, because I want to "create" the groups in my app only when the players have reached a certain page. Should I just comment out the check in the oTree source code? I've tested it locally and don't see any problems at first glance.
#2 by JonasF
Chris is probably the only one who can answer this fully, but I think the reason is that weird things can happen if a group changes mid round. For instance, if you store a variable on the group level and then place a player in a new group during the round, they will no longer be able to access the group variables from their original group. It will also be problematic to see in your data which players were in a group together since there is only one database field to store the group id for a round so you wont be able to see which other players a given player interacted with in both tasks. There will be apps where regrouping mid round is fine and in fact you can do it with the set_group_matrix function but because it can lead to confusing results doing it with "group_by_arrival_time" is disabled. My advice would be not to comment out the check in the source code as this will likely cause issues with your experiment when you deploy to a server or update oTree. Instead, I think the best solution is to just use different rounds. Say you have 2 tasks with different groupings and 2 rounds each, then instead of having 2 rounds with both task and mid round regrouping do task 1 in rounds 1 and 3 and task 2 in rounds 2 and 4 and regroup at the start of each round.
#3 by jkupb
Hi Jonas, thanks for the quick reply. I don't want to change the groups during the experiment. My current problem is that my experiment runs via Prolific and that participants drop out of the experiment at the beginning. The dropouts are already in a group and that leads to active players not progressing. Therefore, I want the groups to be created only after a few individual pages have been completed.
#4 by Phoebe
I think you should add another consent app before you set the arrival_by_time app! I encountered the same confusion and thought of this solution.
#5 by jkupb
@Phoebe Thanks for your advice, but I don't think it will really help me. I would then have to totally split the app and that would be very time-consuming. I have no problem forking oTree and commenting out the check. I'm sure there's a reason for the check, but I don't know what it is.
#6 by gmauter
@jkupb any update on this? Sorry, I know its been a while. I'm having a similar issue where 3 subjects will sign up, start the experiment, and then one subject will leave, resulting in the other getting stuck on a wait page. Then oTree thinks that the subject who left is still in there so keeps their user ID as the 3rd participant, so I can't have another Prolific user take their place