Problem with connection / data saving

[Christina Brunner]

Dear Lucas and Marcus,

I hoped I didn’t have to bother you anymore, but here I am again with some bug. I tried to move my experiment from your server to one I rented on SiteGround (with php 7.4.3), but something is wrong with the interaction between the experiment and the SQL Database and I can’t figure out how to fix it.

Here’s everything I figured out so far:

-          Everything works perfectly in test mode if I use the “start testplayer” button to enter the experiment

-          However, once I try to enter via the “_beginParticipant.php” link the way my participants would, I’m getting problems:

o   Now the data saving/accessing works for the single first participant after uploading my study. However, data in the “decisions” table for all following participants is saved in the same row as the first one (i.e. if I did 5 “testplayer” runs, then ALL following “real participant” runs are saved over each other in row 6 of the decisions table).

o   Additionally, I’m running code which overwrites something on the “core” table right on the first page of my questionnaire. This code also only does what it’s supposed to do on the first ever “real participant” run and – as far as I can tell – doesn’t do anything for all following participants, even though their initial entries are displayed correctly in the “core” table.

o   In the “events” table I initially see that the correct PlayerNr entered the session. But then it usually shows nothing more (no “Connection made pre-lobby”). I assume that I get the the “Connnection made pre-lobby”) always for my very first PlayerNr that’s not from a test run; and my program maintains that connection within the first PlayerNr across various different participants?

o   The problem is robust across various browsers and devices

-          I dug around in your code and am assuming that the “register.php” should work correctly (at least each time I enter a new participant the correct “clientcookie” with the correct PlayerNr is created, saved, and accessed; the “session” table seems correct)

-          I was wondering if it’s something about the saving/accessing of the PlayerNr so I entered insertRecord("decisions","playerNr", "$playerNr"); in line 26 of  “header.php” to check if the correct playerNr is being saved at that point. It works for test players (I get two rows with their playerNr in the decisions table now), but I don’t get any entries for “real” players.  So maybe it’s an issue with correctly reading the “clientcookie” each time “header.php” is called or the way cookies are being processed in “common.php”? Or is it something else entirely which causes my players to not get the “Connection made pre-lobby”?

I’m on a tight schedule for my master thesis and kinda urgently need to start collecting my data soon. If you could point me to the right direction how to fix this, I’d be very grateful!

Also a general estimate: Do you think it’s fixable with the LIONESS code? Or should I simply try the whole uploading procedure on a different server (and if so, are there some you can recommend)?

Thank you so much for your help!

Yours

Christina

[in...@lioness-lab.org]

Hi Christina,

 

This is related to a “cookie” that is sent to a browser when a player registers and the test mode is off. This cookie identifies a unique participant to the experimental program. Within the same browser, only 1 player can then complete the experiment. If you use different browsers (not different tabs within the same browser), the problem should disappear. Note that this will not happen to your participants (as they likely should participate only once, in a single browser).

 

Let me know if this makes sense.

 

Cheers, Lucas

--
You received this message because you are subscribed to the Google Groups "LIONESS Lab help and discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lioness-lab...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/lioness-lab/efa46856-d7b5-42d3-90f2-6a51307fbf68n%40googlegroups.com.

[Christina Brunner]

Hi Lucas,

thanks for the quick reply! I used different browsers to test this, and the problem is exactly the same (I tested with FireFox and Chrome on my Laptop as well as with my phone, which uses a different IP Address). Do you have any other ideas what I can try to fix it? Thanks in advance!

Cheers,

Christina

[in...@lioness-lab.org]

Hi Christina,

 

Did you comment out anything in the registration procedure (e.g., along the lines suggested by Marcus)? Also, do your different simulated players get different playerNr’s at the beginning?

To view this discussion, visit https://groups.google.com/d/msgid/lioness-lab/d5e842eb-beee-42e7-a26f-badefe939146n%40googlegroups.com.

[Christina Brunner]

Hi,

at first I tried a version where something was commented out but switched when that didn't work. I'm now working with exactly the files as downloaded from LIONESS. And yes, my different simulated players get differen PlayerNr's at the beginning.

The simulated players' PlayerNr even match the order as it's supposed to be. For example, let's say my first PlayerNr is a simulated one, then I try three times as a "real" participant (which get saved all in one row in the "decisions" table but get individual entries in the "core" table), and then try again with a simulated player, then that second simulated player will have the correct playerNr = 5.

Thanks for your help!

[Lucas Molleman]

Hi Christina,

Did you also roll back the manipulation of the core table? Changing things manually there can be tricky and interfere with the experimental flow.

Cheers, Lucas

Op do 22 mei 2025 12:50 schreef Christina Brunner <christina...@gmail.com>:

To view this discussion, visit https://groups.google.com/d/msgid/lioness-lab/b5f36917-99af-4297-9896-120062718053n%40googlegroups.com.

[Christina Brunner]

Hi Lucas,

Good news!! It wasn't the manipulation of the core table (I tried commenting that part out, didn't change anything) - but after a very frustrating day I gave up with SiteGround and tried setting up a new server on IONOS. As it turned out, everything seems to work perfectly right away!

I guess the problem had nothing to do with LIONESS after all and something from SiteGround was behaving strangely. At IONOS both my manipulation of the core table and your suggestion to prevent saving of the IP address seem to work, too. I'll keep testing more in detail tomorrow, but it looks very promising so far. Let's hope it stays this way!

As always, thanks a lot for your help!

Cheers, Christina