This topic contains 10 replies, has 0 voices, and was last updated by  Bobirov 10 years, 1 month ago.

  • Author
    Posts
  • #5906

    Bobirov
    Participant

    This is a bit odd, and this is surely the result of me not trying to run a beta server with stats logging at all. 😉

    Anyways, for whatever reason, I can’t play on my v41 servers using my old uniqueid. I can connect ok, and I get to the point where I get the MoTD, but when I click OK I never get the tank selection window. It just says ‘Bobirov((Spec)Loading)’ in the score board, and I can’t get tank selection at all. This is using the official v41 release build on both machines. I also get the same thing trying to join the server from the same machine its running on.

    After fiddling around a bit, I had definately narrowed it down to be related to the mysql stats logging. If I disabled it, it gave me the tank selection just fine, if I enable it, it never gives it to me. Fiddled around a bit with changing host in the mysql.txt files from localhost to 127.0.0.1 but it didn’t affect the problem at all. Either way, stats logging seemed to be working fine when enabled.

    After this I decided to just delete my ids.xml tag to see what would happen if I tryed to connect using a fresh id instead of my old one. Sure enough, that did it. After deleting the id, I was able to connect and I got the tank selection after clicking ok. Exited, reloaded old id, same as before, can’t get tank selection.

    Looking at it, I figured it might be somehow related to the fact that my old id is well… OLD. Its not of the current format of XXXXXXXX-XXXXXXXX-XXXXXXXX. Instead, its of the format of #####-#####-####. So I generated myself a new id and replaced my old id in the mysql database with the new one. Still no dice, connecting with that ID = I don’t get the tank selection.

    At this point, I realized I didn’t check to see if there were any new columns in any of the database tables before starting the new series up with v41. Checked the statstables.sql diffs from 40.1 to 41 and noticed there was a new column scorched3d_stats.rank, so I added that into the database. Also noticed this was added to scorched3d_stats as well:

    INDEX uniqueid_index (uniqueid)

    Trying to add that in though, you’ll get:

    Key column ‘uniqueid’ doesn’t exist in table

    Because uniqueid isn’t a member of scorched3d_stats, its in scorched3d_players. Not sure how important that is or if it can/should point to scorched3d_players.uniqueid.

    Anyways, at this point, I can’t figure out exactly why I can’t play on the server if I use my old ID. If I make a new one, it works fine. I suspect it is related to the fact that my database doesn’t contain the index that’s supposed to be created with the command above, but I dunno it works ok with a fresh ID. Figured I would post about it to get some input.

    #45503

    imported_gcamp
    Participant

    Can you connect to the “offical” servers with your ID, did you ever play there before?

    #45504

    imported_gcamp
    Participant

    @gcamp wrote:

    Can you connect to the “offical” servers with your ID, did you ever play there before?

    Does the server lock up during this time?

    #45505

    Thrax
    Participant

    @gcamp wrote:

    @gcamp wrote:

    Can you connect to the “offical” servers with your ID, did you ever play there before?

    Does the server lock up during this time?

    I noticed the same thing.
    However, it only applied to Your servers Gavin, I could still
    connect to Bobirov’s Apoc servers completely.

    I’ve had Stats of both the older and the v41 together for a few months
    now; no-one has been prevented from joining that I know of..

    edit: ok.. must have been the load of new players in and out
    changing thier settings. works fine when it’s less busy.

    #45506

    Bobirov
    Participant

    @gcamp wrote:

    Can you connect to the “offical” servers with your ID, did you ever play there before?

    Yes, I’ve played there, and yes, I can connect to the official servers now just fine, and I get the tank selection screen as expected.

    Does the server lock up during this time?

    No, I haven’t experienced any server hangs at any time as of yet.

    #45507

    imported_gcamp
    Participant

    The format of the ID shouldn’t matter, its just a string to the server.

    Anyways, at this point, I can’t figure out exactly why I can’t play on the server if I use my old ID. If I make a new one, it works fine. I suspect it is related to the fact that my database doesn’t contain the index that’s supposed to be created with the command above, but I dunno it works ok with a fresh ID. Figured I would post about it to get some input.

    If it was the index that is a problem then the server would hang with high CPU.

    Just trying to think of a good way to debug this:-
    What size is your database?
    Or alternatively is it possible to connect to your database remotely?
    Or perhaps even connect to the machine it is running on, is it unix?

    #45508

    Bobirov
    Participant

    For the record, the server is running MySQL 4.1.9-nt at the moment, not the latest version 5.

    @gcamp wrote:

    The format of the ID shouldn’t matter, its just a string to the server.

    I figured as much, just something I tryed during the course of trying to get to the bottom of it.

    If it was the index that is a problem then the server would hang with high CPU.

    Doesn’t do that at all, although I clearly do not have that INDEX tag in the scorched3d_stats table as it throws that error when you supply that command either on an empty database or using an ALTER TABLE command on my current one.

    What size is your database?

    Its gotten to be a bit unwieldy as time goes by, its a little over 3MB dumped and zipped. I tryed to come up with a way in the past to just dump NEW data and upload it to the online database, but I never finished it. So I’m still using the crappy method of just dumping the entire database and uploading/sourcing it into the online database.

    I’ll send you a PM with a link to a dumped version of it if you want to look at it.

    Or alternatively is it possible to connect to your database remotely?

    At the moment, no, but I’ve set it up to be that way in the past, when I first started running the servers actually, before I set them up to be seperate databases I just linked directly to the local database on the server machine, but I’m kind of leary of doing that. I’ll set up a user who can access remotely if the dumped database isn’t enough.

    Or perhaps even connect to the machine it is running on, is it unix?

    Sadly, its not, just an old ‘doze machine.

    #45509

    imported_gcamp
    Participant

    Tried it here, and have the same issue. Been thinking about it and I think playerid 1 is now reserved for the spectator player. Can’t seem to find it anywhere in the code though.

    Can you try copying the row to a new index and see if that works.

    #45510

    imported_gcamp
    Participant

    Yeah found it, that is the case player id 1 was reserved for the single player spectator. I’ll change it to another number.

    In v41 I changed the playerid allocation code so that if stats are enabled the player id in the game is the same as the stats player id. This means that regardless of the name people connect with they will always get the same player id. I was thinking it would help admins keep track of who is actualy who.

    #45511

    Bobirov
    Participant

    @gcamp wrote:

    Yeah found it, that is the case player id 1 was reserved for the single player spectator. I’ll change it to another number.

    In v41 I changed the playerid allocation code so that if stats are enabled the player id in the game is the same as the stats player id. This means that regardless of the name people connect with they will always get the same player id. I was thinking it would help admins keep track of who is actualy who.

    Sounds logical.

    So do I need to move my stats to another row number like you said or do a rebuild?

    #45512

    imported_gcamp
    Participant

    @bobirov wrote:

    @gcamp wrote:

    Yeah found it, that is the case player id 1 was reserved for the single player spectator. I’ll change it to another number.

    In v41 I changed the playerid allocation code so that if stats are enabled the player id in the game is the same as the stats player id. This means that regardless of the name people connect with they will always get the same player id. I was thinking it would help admins keep track of who is actualy who.

    Sounds logical.

    So do I need to move my stats to another row number like you said or do a rebuild?

    A rebuild of your client should fix it.

    #45513

    Bobirov
    Participant

    @gcamp wrote:

    A rebuild of your client should fix it.

    Yup, that did it, thanks. 🙂

    Also added that index under scorched3d_players on the server database.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.