Behaviour change going from 1.1 to 1.2.3

Molix · Post by **Molix** » 23 Sep 2009, 17:45

Hello,

I have been using 1.1 for many months, and since we're about to start up a new phase of the project I thought it would be a good time to upgrade to the latest and greatest.

I dropped the 1.2.3 SmartFoxClient.dll in my Plugins folder, fired it up, and things seemed to work fine. However when I tried sending a moderator message (text: "testing1.2.3"), I get:

Code: Select all

[SFS DEBUG] [ RECEIVED ]: <msg t='sys'><body action='modMsg' r='0'><user id='7' /><txt><![CDATA[testing1.2.3]]></txt></body></msg>, (len: 104)
[SFS DEBUG] WARNING! ModMessage received for unknown room. Command ignored!! Roomlist not up to date?

If I roll back to the 1.1 DLL, the message (text: "testing1.1") seems the same, but the client processes it normally without a warning:

Code: Select all

[SFS DEBUG] [ RECEIVED ]: <msg t='sys'><body action='modMsg' r='0'><user id='8' /><txt><![CDATA[testing1.1]]></txt></body></msg>, (len: 102)

I'm guessing r='0' is the problem. The actual room id is 4, and I debugged the extension and confirmed that 4 is being passed to sendModeratorMessage(). Does this mean it is a server issue that was previously being masked? I am running 1.6.2 of SFS (I plan to upgrade that too, but I want to do them one at a time to isolate any issues).

Any help or guidance would be appreciated.

ThomasLund · Post by **ThomasLund** » 24 Sep 2009, 06:29

Hi

Yes - somewhere in between those versions I've added the same checks as the actionscript API has - to help developers find these previously hidden bugs/potential bugs.

The API operates on the assumptions that a user has joined a room and that the roomlist is being kept up to date.

So it will now warn (notice warn - not error) if your code tries to do stuff like sending a message into/from an unknown room, if you try to use the API without being logged in etc.etc.

For 99% of the time it will catch real errors this way (like making your own custom login, but forgetting to send over roomlist) - but sometimes it will wanr you about something that isnt a concern.

So if your admin message otherwise gets send to everyone, then its safe to ignore the warning.

/Thomas

Molix · Post by **Molix** » 24 Sep 2009, 13:22

I may have misunderstood, but I am not sure how I can ignore it. Although it is a warning, it states: "Command ignored!!" -- and that seems to be true; the message does not appear in the client's chat window with 1.2.3 (i.e. it breaks the admin messaging ability). Is there a workaround?

ThomasLund · Post by **ThomasLund** » 24 Sep 2009, 14:56

Ahhh - no. Its me that misunderstood. There are 2 levels of checks - when sending and another when receiving. This one seems to be on the receiving side and cant be ignored then.

The room you send to needs to exist. Sorry!

/Thomas

Molix · Post by **Molix** » 24 Sep 2009, 15:24

The room definitely exists and the client knows about it (I am simultaneously drawing the room name and id during OnGUI), and the server extension passes the room id to sendModeratorMessage(), so there must be a problem with SFS not sending it out. Is it correct that r='0' is the room parameter in the modMsg message?

I'll try going back to 1.1, then upgrading my SFS, and then if that works I'll try 1.2.3 again to see if it is being sent. I'll let you know how it goes.

Molix · Post by **Molix** » 24 Sep 2009, 19:25

No change with SFS 1.6.6 (i.e. API 1.1 works, 1.2.3 does not).

Interestingly, sending an Admin message (i.e. from the Admin Tool) works fine despite a seemingly similar lack of a correct room. e.g.

Code: Select all

[SFS DEBUG] [ RECEIVED ]: <msg t='sys'><body action='dmnMsg' r='0'><user id='2' /><txt><![CDATA[admin message from console]]></txt></body></msg>, (len: 118)

I am assuming, still, that r='0' is the culprit. That is not a valid room number either, but it still works. So perhaps the room value is not needed for the mod message anyway?

For completeness, here are the moderator calls in the extension that are being used:

Code: Select all

helper.sendModeratorMessage(message, user, ExtensionHelper.MOD_MESSAGE_TO_ROOM, fromRoom);

helper.sendModeratorMessage(message, user, ExtensionHelper.MOD_MESSAGE_TO_ZONE, 0);

fromRoom is the room id argument of the handleRequest() method, and it is correct (in my case it is 4). Both types fail at the client (and presumably the zone wide one wouldn't send the room anyway).

In summary:
I have debugged the extension in Eclipse, and the room number is definitely going in. After that it is a black box to me. So it seems that sendModeratorMessage is not passing along the room parameter.
That would lead me to believe that either:
- it is a necessary value and it is a bug in SFS that was masked previously, or,
- it not strictly necessary and the API doesn't need to check for it

How should I proceed?