Can I get more info on what messages are being passed?

[servermonkey]

I'd like to get some more info on what messages are being passed from the server to the client. I noticed there was a setting in the Logfile section


<Level>WARNING</Level>

Is there a setting I use here to do this? Or another way if not?

[peterblaze]

Hi,

first, I always run my movies for debugging from Flash IDE. When You have 'omit trace action' in Settings panel set to "false", than You should see messages from ES to client just in the Output Window as plain xml.

Could You post what are You trying to trace from server??? Maybe I can help (a little),

I've noticed 'warning' setting in .xml file too, but there is no deeper explanation for that settings in pubished documentation.

I think Jobe or Mike post answer soon for that matter,

hth,

peter

[servermonkey]

We're making a four-player game where two players each face off against each other and the winner of each match goes through to the next round. Effectively, we're running two two player games at the same time (player1 vs player2 and player3 vs player4). However, when we launch 4 clients on one machine to test this, only have of the messages seem to be being recieved - if we could see which ones are getting lost...

[jobem]

Hi ServerMonkey,

If you are running the SWFs in test mode, then you can set set.setDebug(true) and all messages, inbound and outbound, will be traced.

If you need to see this raw data outside of Test Movie mode in multiple SWFs, then you might consider putting a text field on screen. Then open up the ElectroServer.as class file and look for where the inbound messages come in and have that text get added to the text field. That way you can save the XML history.

That is a start anyway. Depending on what your problems are that might be all you need to do to find out where you are going wrong.

[webgeek]

While there are multiple settings for this tag:


[code]
<Level>WARNING</Level>

we would recomend that you don't change it. The log level setting is used to determine what the server logs to the log file. At lower levels, you will get an amazing amount of information per each connection. With that said, I don't think this will help you at all. It isn't really intended to be useful to debug clients.
Jobe's previous message is the best place to start. Have fun!

[peterblaze]

Hi all,

There is small type error in Jobe post: "set.setDebug(true)",

I think should be:




es.setDebug(value)

or in our case:




es.setDebug(true)

hth,

peter

[jobem]

Ooops, typo...good catch peterblaze :)

Officially it is:
es.setDebug(true)

or

es.setDebug(false)

Where 'es' is a reference to the ElectroServer class.

[peterblaze]

Hi everyone,
ServerMonkey, if You still need tool for monitoring messages sent between swfs and ElectroServer take a look at:
http://www.bbzzdd.com/plugproxy/.
It's a GPL Java based port forwarder/port debugger with GUI.
You must set:
- remote host and IP port (I set current ES settings here: 127.0.0.1 and default 9875) and
- local port (I set default 4000 port here).
Then You must change port number in Your .swf to point local port on plugproxy (i.e. to 4000).
That way using this tool I can debug all network traffic between different .swf and ES.
I love it, :tongue:
I can read all xml messages sent by ES to every .swf (I can read rooms, users, times, type of action, etc), no need for dedicated .swf, extra .as class fie or something like that,

hth,
peter

btw:
Becouse ES doesn't have admin tool yet I think this small Java tool may be extremely usefull for people using ES.

[webgeek]

Not to be a pain, but I question the need for a packet sniffer with the client API? Heck, Jobe and I don't trace the data at that level even when developing new transactions for the server. Other then the wish to reverse engineer the XML protocol to create another client API, then I don't really see much of a use. If anyone does want the XML protocol for any reason, feel free to ask. It isn't in a pretty document, but we can make it available upon request. If you run into a case where you DO need to know the details of the protocol, let us know. It means that the client API isn't good enough in some areas.

For reference, the web based admin tool will not provide any debugging abilities related to the actual message flow of the server. It's primarily a way to configure the server remotely. Let me know if you have any other questions. Thanks!