MArcomage

The main reason why the system for calculating the free slots was changed is the following - it was flawed. A player could take advantage of the low strictness of the system and could exceed the free slots limit. Since exceeding of the limit was never meant to happen, it allowed a player to have unlimited game slots.

In the new version of this system this exploit should be impossible but even if somehow the player would succeed and went trough the limit, it will not result in the unlimited game slots exploit, without exceptions.

So, the main reason why this exploit was available, was the exception when accepting challenges. I'm aware that when you accept a challenge you don't change number of occupied game slots, but exactly this was responsible for the exploit. If the free slots constraint must be hold, then it must be hold at all times.

To check weither I understand:
1*Previous system looked to max only, so once you got to 16 (wich _should_ not be possible) you could easily go to 17 since 16+1~=(is not)15. Repeating the proces to infinity...

2*Previous system _did_ work perfectly, as long as noone exeeded his/hers max.

3*So what I suggest in my previous post should work too, since it always checks wiether the result is bigger then max or not.

Well, I got the feeling while typing this that I apparently don't understand it (or perhaps you?), so I hope that this makes you understand what I don't understand. ;-)

It's not that easy as it may seem. For further understanding you would need to look at the source code. I will try to find a solution for this. A solution that is both safe, strict and contains an exception when accepting challenges.

I took a fresh look at the challenge accept function, and, as I suspected earlier, there IS a off-by-one error there, of sorts.

The bug is caused by a leftover artifact from the earlier system. There, incoming challenges did not count towards your free slots. So, if you had say, 15 active games, and we didn't block you, you could start game number 16, 17, 18 and so on. It was a perfectly correct constraint.

Now that each incoming challenge occupies a slot already, and consequently you cannot have more than 15 of anything, this constraint has lost its purpose. What it actually causes now is what was mentioned earlier in the topic - if you have 0 free slots, you cannot accept a challenge, even though it's occupying 1 slot already.

I will wait for Mojko to confirm my thoughts. If I'm right, fix will be applied right afterwards.

PS: Thanks for Progressor for poking me about this.

Mojko talked to me and clarified it. Seems that he was not actually going to change the "old" system, so you are still supposed to be able to have an infinite amount of incoming challenges. So the operation that counts your free slots needs to take this into account...

Edit: Whoops, didn't see there was a second page >.>

I would suggest to not allow to challenge a person that has no slots available.

Here is what happened to me today:
- having all slots in game I lost a game :-)
- I challenge someone (A)
- before that person answer my challenge (A) I was challenge by someone else (B)
- I broke my previous challenge (A) to be able to accept the new one (B)
- I was not able to accept the challenge (B) :-(
- I win a game
- I was now able to accept the challenge (B)
- and I could challenge someone

any idea?

This is how current system works. It counts incoming challenges as active games. After some discussion we decided not to count incoming challenges to the total count. This change will be applied in the next update.