Using FlashDevelop, a problem with ConnectionEvent, and some API Questions

Hi,

I am building the game using FlashDevelop and the Flex SDK. Your API seems to be mostly compatible, (apart from many functions in NonobaAPI.as not having return types, which I corrected). I have got a game running which two players can join and receive a map from the server. So, the messaging functionality is working great. However, I'm having an issue with hooking onto connection events. I have the following:

m_connection.addEventListener( ConnectionEvent.INIT, onConnectionInit );

private function onConnectionInit( m_event : ConnectionEvent ) : void
{
trace( "Connection Init: " + m_event.Description );
}

When a player logs in, the INIT connection event fires, and I get the following exception:
[Fault] exception, information=TypeError: Error #1034: Type Coercion failed: cannot convert Nonoba.api::ConnectionEvent@181ffc9 to Nonoba.api.ConnectionEvent.

So, it's having trouble casting the received connection event. I couldn't investigate further, as the code which generates that event is not within the API wrapper.

I get a the same exception message if I close the test server app while a player is connected, so I think the problem is global to all ConnectionEvent classes dispatched by your API.

Is any way I can fix this problem? (or are you guys at Nonoba able to correct it?) I don't want the game logic to start running until the player is actually connected to the server, and I'd like to handle the loss of connections gracefully. (The former could be handled in a "welcome" event issued by the server, but I'd prefer to use the built in connection events)

Also, I have two questions with regard to the API:
- Does the system guarantee message delivery? (or do I need to store a recent messages list and require confirmation of receipt?)
- Does the system enforce in order message processing? (or do I need to pass a message number ID of some sort along?)

By the way, a little bug I noticed is that if two players with the same name join a game (a common occurance when testing ;), the players list shows only one player, instead of two with the same name.

For current version you cannot define a handler like you did:

private function onConnectionInit( m_event : ConnectionEvent ) : void
{

instead you need to force a dynamic lookup

private function onConnectionInit( m_event:*) : void
{

this is because the object is created dynamically and for some reason it looses its casting information


what i did for my games is I re create the ConnectionEvent from the dynamic object and continue from there.

As zproxy says the event looses its type and you get a type error if to to define it and a null if you try to cast it. Sadly there is no easy way to fix this except just accepting :* as the value type.

The system is build ontop of TCP/IP which guarantees message order and delivery so no need to do any bookkeeping yourself.

Thanks guys, that sorts matters out nicely. :)

Now there's just the small matter of whacking the game out in a month... I got started a wee bit late. ;p

I came across the same issue and I think it should be solvable... Basically it is because of the ApplicationDomain of the loaded actionscript. It has it's own application domain which means that the e.g. MessageEvent class exists twice - once in your game swf and once in the code swf loaded from Nonoba. These two definitions aren't interchangable.

The solution should be to pass the correct ApplicationDomain when loading the swf from Nonoba. I tried changing line 300 of NonobaAPI.as to the following:

api.load(request, new LoaderContext(false, new ApplicationDomain(ApplicationDomain.currentDomain)));

But it didn't seem to work as expected. Maybe the Nonoba guys can fix it with access to the loaded code as well as the loading code?

More info on the ApplicationDomains on Adobe's livedocs here:

http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/system/LoaderContext.html#applicationDomain

I'd like to appeal for the API code to be cleaned up a bit as well (missing semi colons, return types etc) - I compile with FDT and mxmlc and I get loads of warnings which makes it hard to see real issues...

bump...

Did the nonoba guys see this message? It would be nice if they could take a look so we can have strongly typed events returned from the API...

Its seen and put on the todo, sadley we have not yet had the time to research is further. Stay tuned!

Cool - thanks for the update :)

I am tuned... ;-)

(would be nice to see the warnings go away)