Zombie problem and global database


#21

To connect with the 1.3 client you might have to add -l (or -1? Both looks the same on tremulous.) or -g to the end of the ip. (Connect manually with the ip.)

For example:
/connect 127.0.0.1:12345 -l (This is usually for 1.1 clients if I recall well.
Whilst 1.2 should look like this:
/connect 127.0.0.1:12346 -g

You might want to try using both these variables. (For some reason 1.3 won’t auto-change protocol when connecting to 1.1 servers and I think it was the case for 1.2 servers as well.)


#22

I see the servers now with my 1.3 client, and can connect to them now without issue :slight_smile: .

@avarthar , when you were having that problem with connecting to a 1.1 server locally, did you name that servers with a single letter, or did it have a longer name? At least for “non-lan” 1.1 and gpp servers (provided they have a name longer than one character) I don’t have an issue with automatically connecting to them.


#23

Any name was giving me this problem personally.

Even names with nothing but regular white letters


#24

Hmm, yeah that sounds like it might be an issue with recognizing 1.1/gpp servers on lan.


#25

Yeah, as for non-lan servers I usually don’t have the problem, but I just wanted to make sure to let people know that it might be a good idea to try those commands before saying it doesn’t work.


#26

Hello everyone, as we are all aware there is a problem with clients being counted as bots. Until this bug is fixed, I have found a way to fix it (clientside). Using /seta password [password] will no longer cause you to be recognized as a bot.

Example: /seta password aaaaaaaa

Type this in before you connect to the server, connecting then doing this will not work. If you do connect to the server and use this, /reconnect does not fix the problem either. Disconnect from the server and reconnect back to it.


#27

Possible fix (Serverside) Add a password to the bots.
image

Bots use the privateclients slots. (Unless the code was changed which in such case would surely be better to be set back to use privateclients :slight_smile: )


#28

Wow it just fixed the bug! Thanks god!

Thank you so much for the help! :slight_smile:
Really appreciate!

If you wanna play on zombie server, it’s now playable!


#29

Nice :slight_smile: ! What approach was taken to fix that Z bot bug?


#30

See post #27.


#31

Update: Z now has an additional 121 maps. (Currently has 141 maps, previously had 20).


#32

Also, coming back to say that we’ve got another problem with the database. Sometimes the stats of players save and sometimes don’t.

And when the stats aren’t stored on database here’s an error in console :

I already tried to remove the primary key of the id column but nothing changes.

Thanks!


#33

I know that this is a little off topic but the xserver tremded.exe is coming along nicely. I know that this will help people like @Sayori since they are windows users and it will allow for more flexibility when hosting their own test servers to muck about with rather than running it through the linux sub system.


#34

Should probably add in addition to @Zkimi’s last post, the stats seem to save less often if excessive amounts of zombies are killed in the round.


#35

Make sure your code checks for duplicates. If the key exists just update it instead of trying to create a new one.


#36

As you can see here :

That’s an UPDATE instead of an INSERT. That’s why I don’t understand why this message pop up…


#37

Maybe because you have set up the column so that the data cannot be directly updated?